Subject: [Sigtran] Re: Can SUA Layer encapsulate MTP L3 layer/functionality?

From: Stanislav Ivanovich <[email-masked]>
Date: Thu, 26 Jan 2006 10:11:26 -0800 (PST)

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-masked]> 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 real 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 provides 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 Yahoo! Mail.  

---------------------------------
Bring words and photos together (easily) with
 PhotoMail  - it's free and works with Yahoo! Mail.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 26 Jan 2006 11:25:32 -0700

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
> 
>    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.
> 
> 
> 
> 
> 
>    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!
> 
>    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).
> 
> 
> 
>      _________________________________________________________________
> 
>    Do you Yahoo!?
>    With a free 1 GB, there's more in store with [1]Yahoo! Mail.
>      _________________________________________________________________
> 
>    [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

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

---

From: Stanislav Ivanovich <[email-masked]>
Date: Thu, 26 Jan 2006 10:48:17 -0800 (PST)

Brian, and other SIGTRAN community memebers,
   
  I have read that RFC many years ago and do understand it quite well. I think you haven't understand my point with SAAL specifications which I used just as a refference to show what I mean.
   
  Could you please answer this very simple question in very simple way (with YES or NO), which I copy/paste from my previous mail.
   
  "It is clear that SUA adaptation layer must contain SCCP functions. However the question is can SUA layer contain MTP functions? E.g. MTP3 relay?"

  If YES how is the MTP3 functionality supported by SUA protocol if I read:
   
  SUA RFC: sec. 3.4.1. DUNA is meant to replace N-STATE and N-PCSTATE indications...
   
  / Stanislav Ivanovich

"Brian F. G. Bidulock" <[email-masked]> wrote:
  Stanislav,

--brian

> Stanislav Ivanovich wrote:
> 
> Hello SIGTRAN community,
> 
> 
> 

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 26 Jan 2006 12:38:04 -0700

Stanislav,

Stanislav Ivanovich wrote:                                                       (Thu, 26 Jan 2006 10:48:17)
>    I have read that RFC many years ago and do understand it quite well. I
>    think you haven't understand my point with SAAL specifications which I
>    used just as a refference to show what I mean.
> 
> 
> 
>    Could  you  please answer this very simple question in very simple way
>    (with YES or NO), which I copy/paste from my previous mail.

Well, no, I cannot: because your question proceeds from a false premise.  SUA
does not have to contain SCCP functions.  Also, M3UA may contain MTP3 functions.

--brian

> 
> 
> 
>    "It  is  clear  that SUA adaptation layer must contain SCCP functions.
>    However the question is can SUA layer contain MTP functions? E.g. MTP3
>    relay?"
> 

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

---

From: Stanislav Ivanovich <[email-masked]>
Date: Thu, 26 Jan 2006 11:53:00 -0800 (PST)

In addition to the last mail I want to draw attention to very significant difference between "primitives" as used in RFC 2719 and messages of an peer-to-peer protocol.
   
  For example primitives of SCCP API are certainly not part of any peer-to-peer protocol but are exchanged between different type of entities (in this case SCCP and SCCP user). For this reason we have ASP-SGP protocol which models this kind of communication.
   
  However in xxUA specifications there are also peer-to-peer protocols (IPSP-IPSP in two flavors) and these protocols do not fit into the reference Brian pointed to! If one wants to talk about IPSP-IPSP or Relay or anything peer-to-peer then he must privude the functions needed!
   
  My very particular SUA question is related to these!
  SUA RFC talks about "relay" thing and there is no such thing in between SCCP and SCCP-user (i.e. ASP-SGP) but only between peer entities (SCCP-SCCP, MTPL3-MTPL3...)
   
  / Stanislav
   
  P.S: I do not have any problems with SGP-ASP in SUA! It is perfectly clear!

   

   
   
  / Stanislav Ivanovich

--brian

> contradictory statements in this forum which! seem to collide with
> So like in this ITU-T ! example M3UA also does not essentially contain
! > thanks for the comments!

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

---------------------------------
  Do you Yahoo!?
With a free 1 GB, there's more in store with Yahoo! Mail._______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: Stanislav Ivanovich <[email-masked]>
Date: Thu, 26 Jan 2006 12:07:16 -0800 (PST)

Brian,
   
  Please read my last mail I have recently sent with clarififcations on my last question.

  Here I react to this statement:
   
  ---------------------------------------------------
  [Brian]
  Also, M3UA may contain MTP3 functions.
---------------------------------------------------
   
  No! Certainly not!
  Anyway why would anyone need any SIGTRAN paper (like M3UA) to develop something that already exist??? Is it because we can say"We have developed new xxUA thing which is the same thing ITU-T developed 20 years ago"???
   
  M3UA certainly does specify something what is not specified in ITU-T specifications (messages for MTP3 API primitives + AS redundacy support). However this is not MTP functionality!
  Neither two M3UA instances can communicate like two MTP3 instances!
   
  Why would one use M3UA as replacement for MTP external protocol if these already exisit??? M3UA does contain peer-to-peer protocol but it is certainly not replacement for MTP external protocol!
  Two MTP3 instances can communicate with TFP, TFA... while DUNA, DAVA are not supported on IPSP-IPSP interfaces with very good reason!
   
  / Stanislav

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 26 Jan 2006 13:24:25 -0700

Stanislav,

You are still confused.  In the multiple SG as STP configuration, the
ASP needs to provide some MTP3 functions in the M3UA layer (namely
routing and route status).  Also, please read RFC 2719 section 4.1.

--brian

Stanislav Ivanovich wrote:                    (Thu, 26 Jan 2006 12:07:16)
>    Anyway  why would anyone need any SIGTRAN paper (like M3UA) to develop
>    something  that  already  exist???  Is  it because  we can say"We have
>    developed  new  xxUA  thing which is the same thing ITU-T developed 20
>    years ago"???
> 
> 
> 
>    M3UA  certainly  does specify something what is not specified in ITU-T
>    specifications  (messages  for  MTP3  API  primitives  +  AS redundacy
>    support). However this is not MTP functionality!
> 
>    Neither two M3UA instances can communicate like two M! TP3 instances!
> 
> 
> 
>    Why  would  one  use  M3UA as replacement for MTP external protocol if
>    these already exisit??? M3UA does contain peer-to-peer protocol but it
>    is certainly not replacement for MTP external protocol!
> 
>    Two  MTP3  instances can communicate with TFP, TFA... while DUNA, DAVA
>    are not supported on IPSP-IPSP interfaces with very good reason!
> 
> 
> 
>    / Stanislav
> 

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