Re: Re: Can SUA Layer encapsulate MTP L3 layer/functionality?

Stanislav,

Adaptation modules are defined as in RFC 2719 Section 3.1, and
*NOT* ATM SAAL specifications.

--brian

Stanislav Ivanovich wrote:                                       (Thu, 26 Jan 2006 10:11:26)
> 
>    In  addition to the last mail I want to add that it seems that SUA RFC
>    provides  SCCP  alike  relay  (GT)  since this relay is not managed by
>    management  messages  thus  no need for DUNA, DAVA messages what makes
>    SUA RFC complkiant with the idea of having only SCCP relay in SUA.
> 
> 
> 
>    / Stanislav Ivanovich
> 
>    Stanislav Ivanovich <[email protected]> wrote:
> 
>    Hello SIGTRAN community,
> 
> 
> 
>    The reason why I am writing this is because I have recently found very
>    contradictory  statements  in  this  forum  which seem to collide with
>    relevant specifications. So I would like to hear some comments.
> 
> 
> 
> 
> 
>    There  is no doubt that there is a very sharp distinction between M3UA
>    and SUA.
> 
> 
> 
>    M3UA is r! eal adaptation/coordination function which does not contain
>    any  MTP  functionality but like all the other adaptation/coordination
>    functions  just  provides access to functions provided in a substitute
>    component.
> 
> 
> 
>    Thus  for  example  in  case  of  ITU-T  SAAL  one  can find MTP-alike
>    functions  in  ATM layer, SSCOP (retransmission etc...) so he/she just
>    needs  a coordination function in SSCF (Q.2140) which does not contain
>    real  functionality but only coordinates (maps) services expected from
>    user to corresponding services in the new component which replaces the
>    old ones.
> 
> 
> 
>    So  like  in this ITU-T example M3UA also does not essentially contain
>    any  MTP  functions  (that's is why it is called adaptation layer) but
>    provides access to MTP-alike functions in new components which replace
>    MTP.  Thus  one  can  find functionality similar to MTP L3 relay in IP
>    layer  or  data  error detection and correction functions of MTP L2 in
>    SCTP.  So  M3UA  just  pr!  ovides  access  for MTP-users to MTP-alike
>    functions in new component (SCTP+IP+Physical layer) which replaces MTP
>    layer. M3UA essentially behaves as SSCF of SAAL by coordinating access
>    to MTP alike functions in the substitute component.
> 
> 
> 
> 
> 
> 
> 
>    However  this  SUA  thing is really not adaptation layer of this kind.
>    Does SIGTRAN provide us with substitute for GT, CL, CO... functions of
>    SCCP? NO!
> 
>    Can one find GT alike function in IP or SCTP? NO!
> 
> 
> 
>    So what does SUA adapt?
> 
> 
> 
>    It  is  therefore  clear that SUA "adaptation" layer must contain SCCP
>    functions.
> 
> 
> 
>    However  the  question  is  should it contain MTP functions? E.g. MTP3
>    relay?
> 
> 
> 
>    Looking  into SUA RFC it looks like that SUA layer cannot support MTP3
>    relay.  (e.g.  sec.  3.4.1. DUNA is sent only as N-STATE or N-PC-STATE
>    indications, and many other similar references...).
> 
> 
> 
>    I  have also recently heard from people here at the SIGTRAN forum that
>    MTP3 relay does not make sense since we have corresponding function in
>    IP  relay...  (when  we  spoke  about  SGP-SGP protocol which is being
>    developed  for  M3UA  to  enable  it  to  contain  and  use MTP3 relay
>    functions).
> 
> 
> 
>    If  MTP3  functions  do  not  make sense within M3UA how can they make
>    sense for SUA?
> 
> 
> 
>    thanks for the comments!
> 
> 
> 
>    kind regards/ Stanislav Ivanovich
> 
> 
>      _________________________________________________________________
> 
>    Do you Yahoo!?
>    With a free 1 GB, there's more in store with [1]Yahoo! Mail.
>      _________________________________________________________________
> 
>    Bring words and photos together (easily) with
>    [2]PhotoMail - it's free and works with Yahoo! Mail.
> 
> References
> 
>    1. http://us.rd.yahoo.com/mail_us/taglines/mailstorage/*http://mail.yahoo.com/
>    2. http://us.rd.yahoo.com/mail_us/taglines/PMHM3/*http://photomail.mail.yahoo.com

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


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