Re: ????: Re: FW: LS on Clarification of M3UA usage in3GPP networks
"Asveren, Tolga" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <[email protected]> |
Could the reason be that some people want to replace traditional STPs with their SIGTRAN equivalents? And they don't want to use M2PA because they think it is heavyweight for their purposes? (Some people do have faith in SCTP ;-) ) So, I guess, there is the practical, operational side of the coin as well as the purely theoretical/technical one. I am also aware of cases, where people needed to build IPSPs proxying remote PCs to overcome this problem. Thanks, Tolga > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Brian F. G. Bidulock > Sent: Wednesday, February 27, 2008 3:21 PM > To: wuhongjian > Cc: [email protected] > Subject: Re: [Sigtran] ????: Re: FW: LS on Clarification of M3UA usage > in3GPP networks > > wuhongjian, > > The reason for not pursuing M3PA (SG-SG) or whatever you want to > call it has been that there is no network functionality that it can > provide that cannot already be provided by standard M3UA in > conjunction with an STP. > > So for example, for Scenario 1, the equivalent standard M3UA > approach is as follows: > > .---------. ,---------. > | | | | > | ASP | | ASP | > | | | | > | RK=DPC1 | | RK=DPC2 | > | | | | > `----v----' `----v----' > | | > | ^ X > | | > | | DUNA X > | | | > | | > | MTP-PAUSE AS INACT | > | / \ | > .----^----. ,----^----. > | /| |\ | > | SG1 / | | \ SG2 | > | / | | \ | > |- - - - -| |- - - - -| > | | <-- TFP | | > | | | | > | STP :>-----------<: STP | > | | C-links | | > | | | | > `---------' `---------' > > - Communications is lost with the ASP serving RK=DPC2. > > - The corresponding AS moves to the AS-INACTIVE state in SG2 and > SG2 unbinds the MTP-SAP from the SS7 stack in the STP resulting > in an unavailable SS7 destination and the transfer-prohibited > procedures are invoked for the destination (unavailable routeset). > > - TFP is sent on C-links (which can be M2PA, narrow-band, broadband > or carrier pidgeon links). > > - The STP at SG2 receiving the TRP delivers the corresponding > MTP-PAUSE indication primitives to user parts with a route to the > unavailble destination per standard SS7 and standard RFC4666 M3UA > procedures. > > - The M3UA NIF translates this to a DUNA according to standard RFC > 4666 M3UA procedures and delivers it to the ASP serving RK=DPC2. > > - The MTP user withholds traffic for DPC2 per SS7 standards. > > > Scenario 2, simple replace RKs. > > .---------. ,---------. > | | | | > | ASP | | ASP | > | | | | > | RK=DPC1 | |DPC2,SI=3| > | | | | > `----v----' `----v----' > | | > | ^ X > | | > | | DUPU X > | | | > | | > | MTP-STATUS AS INACT | > | / \ | > .----^----. ,----^----. > | /| |\ | > | SG1 / | | \ SG2 | > | / | | \ | > |- - - - -| |- - - - -| > | | <-- UPU | | > | | | | > | STP :>-----------<: STP | > | | C-links | | > | | | | > `---------' `---------' > > - Communication is lost or the ASP serving DPC2/SI=3 becomes > otherwise inactive for the AS. > > - The corresponding AS moves to the AS-INACTIVE state in SG2 and > SG2 unbinds the MTP-SAP from the SS7 stack in the STP resulting > in an unavailable user part. > > - Per standard SS7 procedures, when the STP receives messages for > the unavailable user part, say from DPC1, it responds with UPU. > > - At SG1, the UPU translates to an MTP-STATUS primitive indication > to concerned users according to standard SS7 procedures. > > - At SG1 the MTP-STATUS primitive is converted by the NIF into a > DUPU message and is delivered to ASP serving the AS corresponding > to DPC1. > > - The user at the ASP serving DPC1 starts periodic test procedures > (e.g. UPT or SST) per SS7 standards. > > > So, the scenarios presented so far do not require M3PA. Can you > think of a need that would actually require an M3PA? These > scenarios simple do not require M3PA, standard RFC 4666 M3UA is > sufficient. > > --brian > > > > wuhongjian wrote: (Wed, 27 Feb 2008 18:28:07) > > > >  > > > > Hi,brian: > > > > > > > > I agree with you that what those drafts describe is a > different > > protocol in some sense,supposed that it can be named as M3PA,not > M3UA. > > But that is really what those scenarioes such as IPSEP-IPSTP- > IPSEP > > needed, and these kind of application are very popular in IP- > based > > signalling network deployment recently. > > > > > > > > So, shall we have to focus on the name of the protocol, or on > the > > functions or mechanisms which the protocol provieded to us? I think > We > > just need a protocol to meet our need,and solve our problem, > whaterver > > it is called as M3PA or extended M3UA, though I understand there > is > > some difference between "User adaptation" and " Peer-to-Peer > User > > adaptation". > > > > > > > > In the scenario mentioned above, M3UA does not so qualify in a > large > > IP-based signalling network, While M2PA maybe can meet our need. But > I > > don't think M2PA is a good choice. Compared with OSI/RM, M2PA > is > > something like a duplicated stack with SCTP. Network > elements > > implemented MTP3/M2PA/SCTP can not work efficiently compared > with > > those implemented M3UA/SCTP. > > > > > > > > There is one question I am interested in is that why IETF did > not > > develop M3PA six years ago?Sigtran used in a large IP-based > signalling > > network maybe is a new requirement for us, M3PA or extended M3UA > may > > be needed this time,I think. > > > > > > > > Thank you. > > > > -- > Brian F. G. Bidulock > [email protected] > http://www.openss7.org/ > _______________________________________________ > Sigtran mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sigtran