Re: FW: LS on Clarification of M3UA usage in 3GPP networks
"wuhongjian" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <016a01c879dd$a4b29740$6000a8c0@wuhongjian1> |
Hi, brian: First,thank u for your patient in giving your explanation again and again. In scenario 1, Provided that the figure changes into IPSP1--IPSTP--IPSP2, when IPSP2 becomes inactive, does RFC 4666 specify clearly that IPSTP has to send DUNA to IPSP1? I don't think so. You have told us, IPSP-IPSP is a point to point configuration, in which IPSTP is excluded. But IPSP1--IPSTP--IPSP2 and IPSP1--IPSTP1--IPSTP2--IPSP2 are the most needed network configurations in large IP-based signalling network. We can't slide over this issue. In scenario 2, according to your explanation, one MSCserver shall populate 2 ASs: AS1 with RK=DPC1+SI3(SCCP), AS2 with RK=DPC1+SI13(BICC). And how many associations will MSCserver establish with one SG, one common association or two separated associations? IMHO,if the answer is the former, it is really complex; If the latter,I think it is a kind of waste of resources. Furthermore, after reading the scenario 2 described in the Statement from 3GPP, I notice that it is quite different from the one you mentioned in your letters. thank u again. Wu Hongjian ----- Original Message ----- From: Brian F. G. Bidulock To: wuhongjian Cc: [email protected] Sent: Thursday, February 28, 2008 4:21 AM Subject: Re: [Sigtran] ????: Re: FW: LS on Clarification of M3UA usage in 3GPP 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