Subject: FW: [Sigtran] The requiremnts and proposals for M2PA/M3UA/SCTPExtension from China Mobile

From: Gomes, Rui Filipe Efigénio, VF-PT <[email-masked]>
Date: Wed, 25 Jul 2007 14:41:00 +0100

Hi,

I do not know if this help, but you have freeware readers:  http://www.7-zip.org/ (windows); http://www.unrarx.com/ (mac osx); unrar (unrar-3.40-1plf.i586.rpm) (linux)

The attachment has three powerpoint files.
There were no pictures in files, I just did simple text copy+paste:

=============================
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 ’.

=============================
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’.                                                       

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 ’.

=============================
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.

Melhores Cumprimentos / Best regards,
Rui Gomes
Core Integration and Design
Cellular Design
Tel: +351919191393

Fax: +351210915882
Address: Avenida D. João II, lote 1.04.01, Parque das Nações, 1990-093 Lisboa, PORTUGAL

-----Original Message-----
From: Michael Tuexen [mailto:[email-masked]] 
Sent: quarta-feira, 25 de Julho de 2007 13:01
To: 陈旭
Cc: zhaoyuyi; zhanghao; sigtran
Subject: Re: [Sigtran] The requiremnts and proposals for M2PA/M3UA/SCTPExtension from China Mobile

Dear Chen,

at least my computer is not able to read a format with  
extension .rar. Please
use plain ASCII to describe what you are talking about. Once the IDs  
have been
submitted, I can comment on them.

Best regards
Michael

On Jul 25, 2007, at 9:02 AM, 陈旭 wrote:

> Dear Chairman and experts，
>
> I am Chen Xu from China Mobile. We have some requirements and  
> proposals for extensions of M3UA/M2PA/SCTP after widely using those  
> protocols.
>   As you may know, China Mobile has built the largest soft-switch  
> network in the world. More than 80 percent long-distance  voice  
> traffic of our subscribers which is more than 300 millions are  
> migrated to this network.
> In this network, SIGTRAN is very important to China Mobile for it  
> is not only widely used in the Nc interface to transport  BICC  
> signaling and in the interface between MSC Server and embedded SG  
> to transport access network signaling, but also used to the  
> interface between IPSEPs/IPSTPs  in the signaling network.
>
> For M3UA（RFC4666）,our requirement is to add the M3UA signalling  
> network management function and procedure for using  in   IPSTP- 
> IPSEP interface.
>
> For M2PA（RFC4165）, our requirements are to supplement the  
> description of the whole idea for Link Alignment procedure and   
> Processor Outage procedure，to give the definition and range of  
> M2PA Timers, and to Supplement the rules of usage of FSN   and BSN  
> in M2PA Header.
>
> For SCTP（RFC4460）,our requirement is to supplement some rules  
> for Multi-homing mechanism.
>
> I have prepared the slides to describe the requirements and  
> proposals of extensions for M3UA/M2PA/SCTP. Any advises and    
> comments would be appreciated. At the same time, I will finish the  
> drafts within weeks.
>
> If you have further question, just send me ([email-masked])  
> an e-mail. Also, My colleague, Mr. Duan Xiaodong   
> ([email-masked]) is in the IETF69th meeting this  
> week , maybe you’d like to talk with him face to face.
>
> Wish you a nice week!
> Looking for your reply!
>
>
> Yours sincerely
> Chen Xu
> [email-masked]
>
>
>
> <from China Mobile.rar>_______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran

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

---------------------------------------------------------------------------
This message may contain confidential information or privileged material, and is intended only for the individual(s) named. If you are not in the named addressee you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.

Vodafone (Portugal)

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

---

From: "Duan Xiaodong" <[email-masked]>
Date: Wed, 25 Jul 2007 10:23:24 -0500

Sorry to submit the rar file. I have resent the attachment as three PPT
files for my colleague. And also, I cannot paste plain ASCII in the slides
for the limited of sizes of the message body.

We will finish the IDs as soon as possible. Now just for some comments
before that.

Xiaodong Duan
China Mobile
[email-masked]