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

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 27 Jul 2007 06:37:05 -0600

Chen,

³ÂÐñ wrote:                                  (Fri, 27 Jul 2007 16:45:12)
> 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. 

That sounds rather foolish.  What I do is as follows:

  When sending to IP3, choose the best route (metric) to IP3.
  If no route to IP3 exists, don't send to IP3, send to another
    destination for the association.
  If a route to IP3 exists, and the source address of the outbound
    interface of this route includes a local address for the
    association, use that as the source address when using the route.
    Otherwise, use the first source address of the association.

  When sending to IP4, choose the best route (metric) to IP4.
  If no route to IP4 exists, don't send to IP4, send to another
    destination for the association.
  If a route to IP4 exists, and the source address of the outbound
    interface of this route includes a local address for the
    association, use that as the source address when using the route.
    Otherwise, use the first source address of the association.

This only results in IP1-IP3 and IP2-IP4 if the only route to IP3 is
from an interface with IP1 and the only route to IP4 is from an
interface with IP2.

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

Yes, it is possible to set up your routing tables on two host so that
the cannot communicate.  This is even possible with TCP.

If the problem is not merely routing table, I suggest you choose another
vendor or work with your existing vendor to correct the deficiencies in
their implementation.

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

Well, no, not in the reasonable implementation.  When SACKs are being
sent to a destination and are not reaching the peer endpoint, a
retransmission timeout will result in duplicate TSNs being sent.  The
peer receiving duplicate TSNs should realized that their SACKs are
likely being sent into a black hole and begin sending SACKs to a
different destination.  This is already in RFC 2960:

6.4 Multi-homed SCTP Endpoints

   ...

   When a receiver of a duplicate DATA chunk sends a SACK to a multi-
   homed endpoint it MAY be beneficial to vary the destination address
   and not use the source address of the DATA chunk.  The reason being
   that receiving a duplicate from a multi-homed endpoint might indicate
   that the return path (as specified in the source address of the DATA
   chunk) for the SACK is broken.

   ...

If your current vendor does not implement this, I suggest that you
request them to do so.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Ankit Kumar Sharma" <[email-masked]>
Date: Fri, 27 Jul 2007 18:17:34 +0530

chenxu,

On 7/27/07, 陈旭 <[email-masked]> wrote:
>    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  )
>
> 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
> 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.
>

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

I don't see any problem in SCTP RFC for above mentioned scenario.
As per RFC 2719, following is the defination of "SHOULD":

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
  may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and

   carefully weighed before choosing a different course.

Now please look at following excerpt from section 6.4(Multi-homed SCTP
Endpoints) of SCTP RFC:
"

"

So as per your scenario, if SOURCE address of sender is not reachable then
our SACK would be lost. After RTO expiry at sender, sender would again try
to send the DATA chunk. Now, receiver could behave as per above mentioned
excerpt.

Best Regard
> Chen Xu
> China Mobile
> [email-masked]
>
>
>
>
>
>
>
> ======= 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:
> >
> >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
> >> [email-masked]
> >> _______________________________________________
> >> Sigtran mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/sigtran
>
>
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
>
>

---

From: "Ankit Kumar Sharma" <[email-masked]>
Date: Fri, 27 Jul 2007 18:21:34 +0530

chenxu,

Best Regard
> >>  Section 1.4.8 .  'SCTP Client/Server Model'.

---

From: "陈旭" <[email-masked]>
Date: Fri, 27 Jul 2007 16:45:12 +0800

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  )   

    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. 

>    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
[email-masked]

>>  China Mobile imports multi-vender’s products. The compatibility
>>  between different vender’s products is important.
>>  two nodes in Section 5  ‘Association Initialization ’.
>>  ‘Acknowledgement on Reception of DATA Chunks ’.
>>
>> (That's all for SCTP)
>>
>>
>>  M3UA specification doesn’t  define signaling network  management
>>  function
>>  therefore network level management function isn’t required.
>>  IPSTP interface in Section 1.5  ‘Sample Configuration ’.
>>  1.4  ‘Functional Areas’.
>>  Section 1.4.8.  ‘SCTP Client/Server Model’.
>>  4）Extend the DUPU message code in Chapter 3 ‘M3UA Protocol
>>  Elements’.
>>  4’procedure’.
>>  SCTP Application in Section 1.4.7 ‘ SCTP Stream Mapping’.
>>
>> (That's all for M3UA)
>>
>>
>>  procedures in different ways ,for  there’s difference between MTP2
>>  T7 isn’t defined and given the range, which makes IPSTP providers
>>  How to fill in and process FSN and BSN in M2PA Header isn’t
>>  defined clearly.
>>
>>

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 27 Jul 2007 14:07:05 -0500

Dear 陈旭,

Dear Michael Tuexen,

You can easily do your "unionize" by using ASCONF to set the primary
destination at both endpoints. In other words, this extension is
already provided by draft-ietf-tsvwg-addip-sctp-22.txt (which is in RFC
editor's queue).

The "SHOULD" is meant to say that when possible (meaning your path is
healthy), you always send the SACK back to the source address of the
DATA chunk. When the path to the source address of the DATA chunk is
unreachable, you are of cause allowed to send the SACK back to other
address(es). In other words, what you want to do is already perfectly
allowed in SCTP.

regards,

-Qiaobing

---

From: Randall Stewart <[email-masked]>
Date: Sat, 28 Jul 2007 06:42:03 -0400

Chen:

I pretty much agree with Brian here..

Most implementations will follow the steps that
Brian lists for source address selection. Yes its completely
possible to setup routing tables that will not work... but
this is a configuration error.. not a deficency in the protocol.

As to sacks, I think most all implementations that I know of attempt
to switch sacks to an alternate destination when they start
seeing duplicate data. I will discuss this item with all the developers
going to Kyoto for the SCTP-Interop (in 2 weeks)... and I will see if
anyone does not do this.. I would be quite surprised to see anyone not
using the duplicate data (as Brian mentions below) as an indication
to move to an alternate address to send the SACK back to.

R

-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)

---

From: <[email-masked]>
Date: Mon, 30 Jul 2007 04:02:25 -0500

Hi,

Won't this association have a serious problem with Heartbeats if you cannot send a Heartbeat Ack to the address the Heartbeat came from?

>From RFC 2960bis
	3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5): 

	An endpoint should send this chunk to its peer endpoint as a response to a 	HEARTBEAT chunk (see Section 8.3). A HEARTBEAT ACK is always sent to the source IP 	address of the IP datagram containing the HEARTBEAT chunk to which this ack is 	responding.

We also need to take into account that the source address of duplicate data may NOT be the source address used for the original data if the sending end has changed paths when the data wasn't acked.

If this is a routing problem which has been in place since the association was started then the sender should never send data to an unconfirmed address.  If the Heartbeat mechanism is broken the address will never be confirmed.

Ronnie
---
Ronnie Sellar			Emerson Network Power, Embedded Computing
Tel: +44 131 475 7015		Suite 4, 2 Anderson Place
Fax: +44 131 475 7001		Edinburgh EH6 5NP
mailto:[email-masked]	http://www.emersonembeddedcomputing.com

> -----Original Message-----
> From: Randall Stewart [mailto:[email-masked]] 
> Sent: 28 July 2007 11:42
> To: ³ÂÐñ
> Cc: Michael Tuexen; [email-masked]; SIGTRAN; TSWG
> Subject: Re: [Tsvwg] Re: [Sigtran] The requiremntsand 
> proposalsforM2PA/M3UA/SCTPExtension from China Mobile
> 
> Chen:
> 
> Most implementations will follow the steps that Brian lists 
> for source address selection. Yes its completely possible to 
> setup routing tables that will not work... but this is a 
> configuration error.. not a deficency in the protocol.
> 
> As to sacks, I think most all implementations that I know of 
> attempt to switch sacks to an alternate destination when they 
> start seeing duplicate data. I will discuss this item with 
> all the developers going to Kyoto for the SCTP-Interop (in 2 
> weeks)... and I will see if anyone does not do this.. I would 
> be quite surprised to see anyone not using the duplicate data 
> (as Brian mentions below) as an indication to move to an 
> alternate address to send the SACK back to.
> 
> R
> 
> > If the problem is not merely routing table, I suggest you choose 
> > another vendor or work with your existing vendor to correct the 
> > deficiencies in their implementation.
> > 
> > 
> >>        
> >>
> >>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 30 Jul 2007 08:39:56 -0600

Ronnie,

That's interesting.  I don't actually do that.  I send the HEARTBEAT-ACK
to the Source IP in the HEARTBEAT, provided that I have a usable route to
that address, I have no retransmissions that were originally sent to
that address outstanding, and I have not received duplicate TSNs when
SACKs were sent to that destination.  Otherwise, I send them to the
current primary.

--brian

[email-masked] wrote:                    (Mon, 30 Jul 2007 04:02:25)
> Hi,
> 
> Won't this association have a serious problem with Heartbeats if you
> cannot send a Heartbeat Ack to the address the Heartbeat came from?
> 
> >From RFC 2960bis
> 	An endpoint should send this chunk to its peer endpoint as a
> response to a 	HEARTBEAT chunk (see Section 8.3). A HEARTBEAT
> ACK is always sent to the source IP 	address of the IP datagram
> containing the HEARTBEAT chunk to which this ack is responding.
> 
> We also need to take into account that the source address of duplicate
> data may NOT be the source address used for the original data if the
> sending end has changed paths when the data wasn't acked.
> 
> If this is a routing problem which has been in place since the
> association was started then the sender should never send data to an
> unconfirmed address.  If the Heartbeat mechanism is broken the address
> will never be confirmed.
> 
> Ronnie
> ---

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 31 Jul 2007 21:09:14 +0200

Hi Ankit,

comments in-line.

Best regards
Michael

On Jul 27, 2007, at 2:47 PM, Ankit Kumar Sharma wrote:

> chenxu,
>
> On 7/27/07, 陈旭 <[email-masked] > wrote: Dear Michael Tuexen,
>
>
>    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  )
>
>     one multi-homed SCTP endpoint has two local IP addresses(IP1/ 
> IP2) and two remote IP address(IP3/IP4) within an association.
> endpoint2 use IP3-IP2 as the primary path, use IP4-IP1 as the  
> second path.
I would consider it the following way:
The first end-point (owning IP1 and IP2) has two paths, one towards  
IP3 and
another one towards IP4.
When sending a packet towards the peer SCTP choses IP3 or IP4 as the  
destination
address and normally the source address is selected based on the  
routing table.
The peer will accept the messages as long as the source address is  
either IP1
or IP2. The pairing IP1/IP2 and IP3/IP4 is not enforced by the SCTP  
implementation.
> 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.
>
> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that  
> there may exist valid reasons in particular circumstances to ignore a
> Now please look at following excerpt from section 6.4(Multi-homed  
> SCTP Endpoints) of SCTP RFC:
> " When a receiver of a duplicate DATA chunk sends a SACK to a multi-
> So as per your scenario, if SOURCE address of sender is not  
> reachable then our SACK would be lost. After RTO expiry at sender,  
> sender would again try to send the DATA chunk. Now, receiver could  
> behave as per above mentioned excerpt.
>
> Best Regard
> Chen Xu
> China Mobile
> [email-masked]
>
>
>
>
>
>
>
> >>  the interface between IPSEPs——M3UA
> >>  the interface between IPSTPs——M2PA
> >>  the interface between IPSEP and IPSTP——M3UA
> >>
> >>  Problem description
> >>