Re: RE: [Sigtran] The requiremnts and proposals forM2PA/M3UA/SCTPExtension from China Mobile

"chenxu" <chenxu@chinamobile.com> Thu, 26 July 2007 02:22 UTC

Return-path: <sigtran-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDt07-00028N-UU; Wed, 25 Jul 2007 22:22:51 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDt07-00028D-Am for sigtran@ietf.org; Wed, 25 Jul 2007 22:22:51 -0400
Received: from [221.130.253.133] (helo=cmccmta) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDt06-0001JK-2e for sigtran@ietf.org; Wed, 25 Jul 2007 22:22:51 -0400
Received: from 6f-chenxu ([10.1.5.152]) by mail.chinamobile.com (Lotus Domino Release 6.5.5FP1) with SMTP id 2007072610221728-36513 ; Thu, 26 Jul 2007 10:22:17 +0800
Date: Thu, 26 Jul 2007 10:22:07 +0800
From: chenxu <chenxu@chinamobile.com>
To: "Gomes, _Rui_Filipe_Efigénio, _V" <Gomes>, _Rui_Filipe_Efigénio, rui.gomes@vodafone.com, Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
Subject: Re: RE: [Sigtran] The requiremnts and proposals forM2PA/M3UA/SCTPExtension from China Mobile
X-mailer: Foxmail 5.0 [cn]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.5FP1 | April 14, 2006) at 2007-07-26 10:22:17, Serialize by Router on cmccmta/servers/cmcc(Release 6.5.5FP1 | April 14, 2006) at 2007-07-26 10:22:50, Serialize complete at 2007-07-26 10:22:50
Message-ID: <OFFC8632AB.5A75783C-ON48257324.000D06E1@chinamobile.com>
X-Spam-Score: 2.9 (++)
X-Scan-Signature: 200d029292fbb60d25b263122ced50fc
Cc: 'sigtran' <sigtran@ietf.org>
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2102854479=="
Errors-To: sigtran-bounces@ietf.org

Dear all,

     Sorry to submit the rar file! And thanks Rui Gomes!

The contents of the attachments are as follows:
     
  =============================
  for SCTP of China Mobile.ppt
 =============================

 The Requirement and Proposal
  for SCTP Specification Extension
  of China Mobile

 Chen Xu , Zhang Hao
 China Mobile

 Content

 Background
 Problem description
 Requirement for Supplement of RFC4460
 Proposal for Supplement of RFC4460

 Background

 The world trend of IP bearer for signalling will make SIGTRAN  
 standard widely used in signalling network.
 Traditional and new Telecom carriers implement signalling over IP to
 Reduce  cost for extended capacity
 Removes the links/linkset limitation imposed by traditional TDM  
 linksets for traffic growth
 Avoid major network re-engineering when traffic grows
 SCTP is the basis of signalling over IP

 SCTP is also important to China Mobile
 Applying to the Nc interface to transport BICC messages
 Applying to the Mc interface to transport H.248 messages
 Applying to the interface between MSC Server and the embedded SG to  
 transport access network signalling
 Applying to signalling network
 the interface between IPSEPs
 the interface between IPSTPs
 the interface between IPSEP and IPSTP
 

Problem description
 
China Mobile has a large number of subscribers and has built the  
 largest soft-switch network in the world. The signaling traffic  
 between two nodes is very large.
 China Mobile imports multi-vender’s products. The compatibility  
 between different vender’s products is important.
 The illegibility of Multi-homing mechanism in SCTP protocol brings  
 on compatibility problems
 SCTP did not define the mechanism how the SACK is send back to  
 endpoint by other path when one path fails.
 SCTP defines multi-homing, but it did not define how the primary  
 path can be unionized between two nodes.
 Requirement for Supplement of RFC4460
 Define the mechanism that SACK is send back to endpoint by the  
 secondary path if the primary path fails .
 Define  the mechanism how the primary path can be unionized between  
 two nodes.


 Proposal for Supplement of RFC4460


 1)Add the mechanism how the primary path can be unionized between  
 two nodes in Section 5  ‘Association Initialization ’.
 2) Add the mechanism that SACK is send back to endpoint by the  
 secondary path if the primary path fails in Section 6.2   
 ‘Acknowledgement on Reception of DATA Chunks ’.

(That's all for SCTP)


 =============================
 for M3UA of China Mobile.ppt
 =============================

 The Requirement and Proposal
  for M3UA Specification Extension
  of China Mobile

 Chen Xu
 China Mobile


 Content
 
Background
 Problem Description
 Requirement for Extension of RFC4666
 Proposal for Extension of RFC4666



 Background

 The application of SIGTRAN standard for SG has ever solved the  
 problems of  No.7 Signalling System Interworking IP and   
 transmission of  access network signalling  in  R4 CS core network.
 The world trend of IP bearer for signalling will make SIGTRAN  
 standard widely used in signalling network.
 Traditional and new Telecom carriers implement signalling over IP to
 Reduce  cost for extended capacity
 Removes the links/linkset limitation imposed by traditional TDM  
 linksets for traffic growth
 Avoid major network re-engineering as traffic grows

 SIGTRAN is also important to China Mobile
 Applying to the Nc interface of BICC network to transport BICC  
 messages
 Applying to the interface between MSC Server and embeded SG to  
 transport access network signalling
 Applying to signalling network
 the interface between IPSEPs――M3UA
 the interface between IPSTPs――M2PA
 the interface between IPSEP and IPSTP――M3UA

 Problem description

 M3UA specification doesn’t  define signaling network  management  
 function
 M3UA is designed for SG-IPSEP and IPSEP-IPSEP applications,  
 therefore network level management function isn’t required.
 SSNM messages defined in M3UA are only used for interworking with SS7.
 China Mobile has a large number of subscribers and has built the  
 largest soft-switch network in the world, its signaling network  
 will be the multi-level and multi-area mode.
 It will has two signalling routeing  scene:IPSEP-IPSTP-IPSTP-IPSEP  
 and IPSEP-IPSTP-IPSEP
 The interworking  function with MTP3 in M3UA can realize the  
 signaling network  management for  IPSEP-IPSTP-IPSTP-IPSEP scene;
 Current M3UA  can not  realize the signaling network  management  
 for  IPSEP-IPSTP-IPSEP scene.

 Requirement for Extension of RFC4666

 Define the Application for IPSTP-IPSEP interface.(Still uses SGP- 
 ASP procedures)
 Define the signalling network management function,messages ,and  
 procedures.(Describe how to use SSNM messages to support signaling  
 network management for IPSEP-(M3UA)-IPSTP-(M3UA)-IPSEP scene. )

 Proposal for Extension of RFC4666

 1)Add different kinds of routing scenes applications for IPSEP- 
 IPSTP interface in Section 1.5  ‘Sample Configuration ’.
 2)Add the M3UA signalling network management function in Section  
 1.4  ‘Functional Areas’.
 3) Add the Client/Server Model for IPSTP-IPSEP interface in  
 Section 1.4.8.  ‘SCTP Client/Server Model’.
 4)Extend the DUPU message code in Chapter 3 ‘M3UA Protocol  
 Elements’.
 5)Add the signalling network management procedure in Chapter  
 4’procedure’.
 6) Add the requirement of Multi user data streams for M3UA over  
 SCTP Application in Section 1.4.7 ‘ SCTP Stream Mapping’.

(That's all for M3UA)


 =============================
 for M2PA of China Mobile.ppt
 =============================

 The Requirement and Proposal
  for M2PA Specification Revision
  of China Mobile

 Chen Xu
 China Mobile

 Content

 Background
 Problem Description
 Requirement for Revision of RFC4165
 Proposal for Revision of RFC4165


 Background

 M2PA protocol is a peer to peer protocol, it not only supports  
 seamless management operation of MTP3 protocol peers over an IP  
 network connection, but also removes the links/linkset limitation  
 imposed by traditional TDM linksets for traffic growth.

 The Standardization of M2PA is behind the application of it.
 Although the RFC edition is released in 2005, M2PA is widely used  
 in the  Signaling network rebuilding over IP for traditional  
 operators and in the Signaling network construction for  new  
 operators  since 2002.

 Various draft editions and the major differences between them make  
 problems when one  IPSTP provider interworking with another.

 Problem Description


 RFC4165 needs to be supplemented and revised :
 Some  procedures  are  described a little bit simply and referred  
 to MTP2 directly ,  which  makes IPSTP  providers realizing the  
 procedures in different ways ,for  there’s difference between MTP2  
 and M2PA in some aspects.      .
 Some IPSTP providers use the same idea as MTP2
 Others take the relation between M2PA and SCTP into account.

 T7 isn’t defined and given the range, which makes IPSTP providers  
 realizing it in different ways.

 How to fill in and process FSN and BSN in M2PA Header isn’t  
 defined clearly.


 Requirement for Revision of RFC4165

 Supplement the description of the whole idea for Link Alignment  
 procedure and Processor Outage procedure.
 Supplement the definition and range of M2PA Timers.
 Supplement the rules of usage of FSN and BSN in M2PA Header.


 Proposal for Revision of RFC4165

 1)Supplement the whole idea , the phase division , the correlated  
 messages and Timers of Link Alignment procedure in Section 4.1.3.
 2)Supplement the whole idea of Processor Outage procedure, and  
 describe the rules of LPO and RPO processing separately .
 3)Supplement the rules of usage of FSN and BSN in M2PA Header in  
 Section 4.2.1
 4)Supplement the definition and range of M2PA Timers in Appendix.

(That's all for M2PA)

Chen Xu
China Mobile
chenxu@chinamobile.com
_______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran