Subject: Re: [Tsvwg] Multihoming during SCTP 4-way handshake?

From: Randy Stewart <[email-masked]>
Date: Sun, 4 Jan 2009 09:03:36 -0500

Just saw this... sorry for the delay..

On Nov 21, 2008, at 6:36 AM, Tim Stevens wrote:

> Dear Randy,
>
> Thanks alot for your help!
>
> Considering scenario 2, see my comments below.
>
>>> Scenario 2:
>>> Consider that both hosts support RFC5061. Is the following  
>>> sequence of
>>> events correct?
>>> 1) C1 sends INIT to S1
>>> 2) S1 receives the request, but prefers to use interface S2
>>> 3) S2 sends INIT ACK + ADDRESS PARAMETERS S2,S1 + SET PRIMARY  
>>> ADDRESS
>>> S2 to C1
>>> 4) interface S1 becomes unreachable (due to some network event)
>>> 5) C1 sends COOKIE ECHO + HEARTBEAT to S2 (because S2 is  
>>> UNCONFIRMED?)
>>> 6) S2 sends COOKIE ACK + HEARTBEAT ACK to C1
>>> 7) connection ESTABLISHED
>>
>> When S2 sends the INIT it is not legal for it to bundle a
>> Set-Primary in it. The INIT and INIT-ACK chunks are specifically
>> prohibited from having any other chunks bundled with them.
>>
>> S2 could send the INIT-ACK (remember it has no state either)... and
>> when the cookie arrives it could send
>>
>>
>> COOKIE-ACK, SET-PRIMARY.
>>
>
> I think I must have misunderstood RFC5061 in this case... The last  
> paragraph in Section 4.2.4 reads:
>   "Valid Chunk Appearance
>
>   The Set Primary IP Address parameter may appear in the ASCONF, the
>   INIT, or the INIT-ACK Chunk Type.  The inclusion of this parameter  
> in
>   the INIT or INIT-ACK can be used to indicate an initial preference  
> of
>   primary address."
>
> How should I interpret this paragraph?

Sorry, my bad, I was thinking in terms of bundling an ASCONF. Of course
the sender of an INIT or INIT-ACK can validly include a SET-PRIMARY  
parameter
in the INIT/INIT-ACK.

But as it states in RFC5061 the set-primary is a "suggestion", the
receiver of a set primary is NEVER under any obligation to do it. They
should, at least try, if they can. However when a set-primary is done
on an UNCONFIRMED address then the receiver MUST NOT honor it since
it violates a MUST NOT in the 4960 base spec... i.e. you cannot
send data to a unconfirmed address.

I suppose if the implementation wanted, it could hold a "flag" if you  
will, on the
destination and AFTER it is confirmed change that to be the primary..  
but this of
course is an implementation detail.

R

> Best regards,
> Tim

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