Re: M3UA and SUA recommendations

Siu,

Siu Chai Tho wrote:                                                    (Fri, 20 Jan 2006 00:03:11)
> 
>    Hello Stainislav,
>    Stanislav Ivanovich <[email protected]> wrote:
> 
>    [Stanislav  Ivanovich] The specifications do much more than that. They
>    essentialy   define  a  concept  of  application  redundacy  which  is
>    controlled by ASP SM/TM messages.
> 
> 
> 
>    [Siu  Chai  Tho]  I  not  understand  this.  Isn't  it just signalling
>    transport  redundancy  that  is  managed  and  it  is  an  option  for
>    applications  to  use  it for application redundancy or not ? RFC 2719
>    does not mention anything on SIG-user redundancy.

You are correct.

> 
>    [Stanislav  Ivanovich]  What  specifications do tell you is how should
>    signalling  processes  behave on the external protocol and what is the
>    functionality  the  prcesses  should  contain.  Internal  structure of
>    signalling processes is irrelevant for specifications.
> 
> 
> 
>    [Siu  Chai  Tho]I  feel that you have misunderstood my question. I was
>    trying  to  reassure  that  there are boundaries of a layer defined as
>    mentioned in chapter 1.6 of RFC 3868 and also in chapter 3.1 RFC 2719.
>    I  understand  that  implementations can do whatever they like and are
>    not  forced  to  use layers. However, what is the purpose of using the
>    word layer when there is no layer intended ?

What would you call it then?  We refer to all of these UA as SS7-User
Adaptation Layers.  You don't like the word 'layer'?  (You will find
it on every page.)

> 
>    [Stanislav  Ivanovich]  No! ASP and IPSP are processes wh! ich contain
>    user  functions  what  is  not  the  case for SGP. For example SGP-ASP
>    protocol is designed to model communication between MTP3 and MTP3-user
>    function  for  M3UA  or SCCP and SCCP-user function for SUA. So ASP is
>    container  into which you load your user function. The essentce of the
>    AS  concepts  (which make 80% of specifications for both M3UA and SUA)
>    is  that  it  supports  application  redundancy  by means of ASP SM/TM
>    messages.
> 
> 
> 
>    [Siu  Chai Tho] ASP and IPSP contains user functions but SGP doesn't ?
>    Isn't  it  just  that  any  signalling process is just a communication
>    endpoint  for  SUA/M3UA  ? The  user  functions at the ASP or SCCP/MTP
>    functions  at  the SGP reside in their own components or am I mistaken
>    here ?

Implementation dependent.  Also see, for example, last paragraph of RFC 3332
Section 1.4.2.4 [Page 13].  An SGP can even host an ASP of its own (and thus
a User Part).

> 
>    [Sta! nislav Ivanovich] Application granularity (ie. AS representation
>    in  SS7  language)  is  implementation  choice  thus  not  subject  to
>    specifications.  But  the  specifications  allow  you  to  define your
>    applications  very flexibly (e.g. ISUP + BICC for DPC=2-100 shall be 1
>    AS).
> 
> 
> 
>    [Siu  Chai  Tho]  I  was trying  to ask  if  it is possible to map one
>    MTP/SCCP-SAP  (or  AS)  into  multiple ASPs (inside the same node). If
>    this  is  an  implementation option as you indicate I'm happy with the
>    answer.

Implementation dependent, however, the protocol supports multiple ASPs on
the same host, even with dynamic port assignment using the ASP Identifier.

--brian

> 
>    6) Is the recommendation of a layered implementation seen as a benefit
>    or best current practice ?
> 
> 
> 
>    [Stanislav Ivanovich] Again. This is implementation. You cannot answer
>    thuis  queston  by  looking  into  xxUA  specifications but instead by
>    looking  into  your  current  SS7 implementation product descriptions,
>    sequence diagrams etc...
> 
> 
> 
>    [Siu Chai Tho]I have again the feeling that you understood me wrong. I
>    was  asking  for  a  reasoning  of the layer recommendation inside the
>    RFCs. How do others implement it ?
> 
> 
> 
>    Thank you,
> 
>    Joe
> 
>    Send instant messages to your online friends
>    http://au.messenger.yahoo.com

> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran


-- 
Brian F. G. Bidulock
[email protected]
http://www.openss7.org/