Subject: [Tsvwg] FW: FW: SCTP multihoming and INIT

From: <[email-masked]>
Date: Mon, 25 May 2009 16:43:25 +0400

Sorry for inconvenience, I can't explain the problem correctly.

So, one more time.

We have next situation.
Endpoint A (ip source = A1) sends INIT to peer Z (ip destination = Z1) and starts timer T1. When timer T1 is expired (because primary ip backbone failed) and no INIT ACK was received, endpoint A (ip source = A1) sends INIT again to peer Z (ip destination = Z1) and starts timer T1 again. And over and over again.

So, endpoint A never sends INIT from its ip source A2 to peer Z (ip destination = Z2). But I think it should send.

RFC2960 doesn't comment this situation for CONTROL chunks although in this RFC is wrote for DATA chanks:
"   Furthermore, when its peer is multi-homed, an endpoint SHOULD try to
   retransmit a chunk to an active destination transport address that is
   different from the last destination address to which the DATA chunk
   was sent."
So, endpoint A should try to send DATA chunks to all peer destination addresses. But what about CONTROL chunks?

BR/Sergey

-----Original Message-----
From: Randy Stewart [mailto:[email-masked]] 
Sent: Monday, May 25, 2009 4:28 PM
To: Смирнов Сергей
Cc: [email-masked]
Subject: Re: [Tsvwg] FW: SCTP multihoming and INIT

Sergey:

No such equipment would NOT be in compliance with either RFC2960 OR  
RFC4960(its successor).  The
equipment manufacture really needs to attend an inter-op session next  
time one
is planned and find out where they are NOT in compliance... at least
my guess is they have never attended one. Since this is one of the tests
we always do... i.e.

PEER-A (IP-A1/A2)                          PEER-Z (IP-Z1/Z2)
    from A1-------INIT(A1/A2) ---> to Z1
       to A2 <----INIT-ACK(Z1/Z2)-- from Z2

The PEER-A must be able to handle the above INIT-ACK and recognize
it has part of the association that it is forming. Likewise when
Peer Z gets back the cookie-echo it too must recognize the cookie
from either network IP address A1 OR A2.

R

On May 25, 2009, at 7:46 AM, <[email-masked]> <[email-masked] 
 > wrote:

> Thanks!
>
> It's clear. But we have an equipment which initiate association only  
> by primary ip address of peer end. So, if we have problem with  
> primary ip backbone, association will never be established. I think  
> it's the disadvantage of the equipment.
> Unfortunately I didn't find any comments about this problem in  
> RFC2960. Moreover, vendor thinks it's equipment is fully agreed with  
> RFC2960.
>
> BR/Sergey
>
> -----Original Message-----
> From: Michael Tüxen [mailto:[email-masked]]
> Sent: Monday, May 25, 2009 3:35 PM
> To: Смирнов Сергей
> Cc: [email-masked]
> Subject: Re: SCTP multihoming and INIT
>
> Hi,
>
> you can send the INIT to any of the addresses of the peer.
> The notion of primary/secondary is only relevant to the
> data transmission.
>
> Please send further questions regarding to [email-masked].
>
> Best regards
> Michael
>
> On May 25, 2009, at 11:51 AM, <[email-masked]> <[email-masked]
>> wrote:
>
>> Hello!
>>
>> As wrote in RFC2960(4960) <A) "A" first sends an INIT chunk to "Z".>
>> Must “A” sends INIT message to primary and secondary destination
>> addresses at peer end when we use multihoming?
>> In other words, must be association initiated by secondary path only
>> (so, primary path is not available)?
>>
>> BR/Sergey
>> NSS engineer OJSC “Megafon”, Russia
>>
>> _______________________________________________
>> Ietf mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ietf
>

-----
Randall Stewart
[email-masked]

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 25 May 2009 14:58:28 +0200

Hi Sergey,

the crucial point here is: Does endpoint A at the time it sends an  
INIT chunk
already know that the peer Z has two addresses Z1 and Z2?

Looking at the socket API, described in
http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-19
you can see that if the client uses a connect(Z1) call to establish
the association, he has no indication that the server is multihomed,
but if the client uses sctp_connectx(Z1,Z2) it knows about both
addresses and the SCTP implementation can already use both addresses
for setting up the SCTP association. The FreeBSD SCTP implementation
would succeed in the scenario you are describing.

Best regards
Michael

On May 25, 2009, at 2:43 PM, <[email-masked]> <[email-masked] 

> Endpoint A (ip source = A1) sends INIT to peer Z (ip destination =  
> Z1) and starts timer T1. When timer T1 is expired (because primary  
> ip backbone failed) and no INIT ACK was received, endpoint A (ip  
> source = A1) sends INIT again to peer Z (ip destination = Z1) and  
> starts timer T1 again. And over and over again.
>
> So, endpoint A never sends INIT from its ip source A2 to peer Z (ip  
> destination = Z2). But I think it should send.
>
> So, endpoint A should try to send DATA chunks to all peer  
> destination addresses. But what about CONTROL chunks?
>
>
>
>
> BR/Sergey
>

---

From: <[email-masked]>
Date: Tue, 26 May 2009 12:21:50 +0400

Thank you very much!

BR/Sergey

-----Original Message-----
From: Michael Tüxen [mailto:[email-masked]] 
Sent: Monday, May 25, 2009 4:58 PM
To: Смирнов Сергей
Cc: [email-masked]; [email-masked]
Subject: Re: [Tsvwg] FW: FW: SCTP multihoming and INIT

Hi Sergey,

Best regards
Michael

---

From: Randall Stewart <[email-masked]>
Date: Mon, 25 May 2009 08:53:59 -0400

On May 25, 2009, at 8:43 AM, <[email-masked]> <[email-masked] 

> destination addresses. But what about CONTROL chunks?

But the above does NOT suggest what the source address should be.

And yes, a good solid implementation would use all addresses it knows  
about for
the peer to try retransmissions. Note that I say all it knows about.  
In some
cases the implementation may only know about the Z1 address. For  
example if
you were using the socket API and you did

  ret = connect(sd, IP-Z1);

The implementation now only knows about Z1. Once the INIT-ACK returns it
then knows about Z1 and Z2.

This is why the sctp specific connect mechanism

sctp_connectx()

was added to the socket api.. so the application could do:

  ret = sctp_connectx(sd, [IP-Z1, IP-Z2]);

So if connectx were being used AND both Z1 and Z2 were listed, then a  
good
implementation SHOULD retransmit the INIT alternating between Z1 and  
Z2. I believe
there are even some implementations that transmit the INIT to both  
addresses every
time... not that I am advocating this behavior.

There is no violation of the specification however if the  
implementation does not
support this ability.. It SHOULD do it.. but it is not required....

R

>>> https://www.ietf.org/mailman/listinfo/ietf

------------------------------
Randall Stewart
803-317-4952 (cell)
803-345-0391(direct)