Re: Re: [Sigtran] The requiremnts and proposalsforM2PA/M3UA/SCTPExtension from China Mobile

" 陈旭 " <chenxu@chinamobile.com> Fri, 27 July 2007 08:45 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 1IELRz-0005Xp-GM; Fri, 27 Jul 2007 04:45:31 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IELRx-0005UO-N1; Fri, 27 Jul 2007 04:45:29 -0400
Received: from [221.130.253.133] (helo=cmccmta) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IELRu-0005q7-4O; Fri, 27 Jul 2007 04:45:27 -0400
Received: from 6f-chenxu ([10.1.5.152]) by mail.chinamobile.com (Lotus Domino Release 6.5.5FP1) with SMTP id 2007072716452278-50842 ; Fri, 27 Jul 2007 16:45:22 +0800
Date: Fri, 27 Jul 2007 16:45:12 +0800
From: 陈旭 <chenxu@chinamobile.com>
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
Subject: Re: Re: [Sigtran] The requiremnts and proposalsforM2PA/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-27 16:45:22, Serialize by Router on cmccmta/servers/cmcc(Release 6.5.5FP1 | April 14, 2006) at 2007-07-27 16:45:26, Serialize complete at 2007-07-27 16:45:26
Message-ID: <OF24565732.6AADA0AB-ON48257325.00301996@chinamobile.com>
X-Spam-Score: 2.9 (++)
X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07
Cc: SIGTRAN <sigtran@ietf.org>, TSWG <tsvwg@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="===============0219425738=="
Errors-To: sigtran-bounces@ietf.org

Dear Michael Tuexen,

	
>    1. What does "unionize of the primary paths between nodes" mean?
   It means,for one multi-homed SCTP endpoint,the primary path(source IP address=IP1---destination IP=IP2) shall be the same as the remote endpoint's ( source IP address=IP2---destination IP=IP1  )   
   
   Many venders implement Multi-homing in the following way:

    one multi-homed SCTP endpoint has two local IP addresses(IP1/IP2) and two remote IP address(IP3/IP4) within an association.
    There's two paths within an association:IP1-IP3,and IP2-IP4.not 4 paths. 
   
    For example, endpoint1 has two local IP addresses(IP1/IP2), and endpoint2 has two local IP addresses(IP3/IP4).

if two endpoints' primary path isn't the same,that is endpoint1 use IP1-IP3 as the primary path, use IP2-IP4 as the second path;  endpoint2 use IP3-IP2 as the primary path, use IP4-IP1 as the second path. 

    These two endpoints can't  send data to each other successfully.  
        

>     2. Not sure about the SACK issue: You are currently allowed to
>    send the SACK back to an addresses different from the source
>    address of the corresponding DATA chunk. As far as I know
>    it is only a SHOULD describing that you send the SACK back
>    to the source address of the DATA chunk.

     You are right,it is only a SHOULD describing that you send the SACK back
   to the source address of the DATA chunk in RFC2960.
      That's why we get in trouble in multi-homing situation. 
      If the  path to the source address of the DATA chunk is unreachable,the sack can't send to the remote endpoint for ever although the other path is available.Soon the other path will be failure.

Best Regard
Chen Xu
China Mobile
chenxu@chinamobile.com







======= 2007-07-26 22:23:20 您在来信中写道:=======

>Dear all,
>
>I'm sending this also to TSVWG, since the SCTP discussion has to be
>done the that WG.
>
>Addressing the SCTP statement:
>
>1. What does "unionize of the primary paths between nodes" mean?
>2. Not sure about the SACK issue: You are currently allowed to
>    send the SACK back to an addresses different from the source
>    address of the corresponding DATA chunk. As far as I know
>    it is only a SHOULD describing that you send the SACK back
>    to the source address of the DATA chunk.
>
>Best regards
>Michael
>
>On Jul 26, 2007, at 4:22 AM, chenxu wrote:
>
>> 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


_______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran