Subject: [Tsvwg] SCTP Addresses as upper layer ids

From: Mark Butler <[email-masked]>
Date: Mon, 23 Jan 2006 21:52:35 -0700

The SCTP socket draft currently describes the behavior of  recvmsg(2) as 
having msg_name set to the "source transport address of the user data".  
This complicates applications that use addresses instead of association 
ids to identify peers.

There is draft layer 3 multihoming support for IPv6 based on the idea 
that upper layer applications should only need to know about the primary 
address or "upper layer id" of each peer.  The shim6 draft (*) describes 
a shim for IPv6 that does this translation in layer 3.

I think the general idea behind this concept is useful for SCTP as 
well.  To implement this, recvmsg(2) would always return the 
address/port used to initiate the association with (if initiated 
locally) or the initial source address/port (if the association was 
initiated by the peer).  This address/port would be the "upper layer 
id". Applications could use the upper layer id as a stable identifier 
for the peer during the life of the association, allowing them to 
largely be transparent to multihoming / path failover at the SCTP 
layer.   The primary advantage of doing this over using association ids 
is protocol portability, of course.

Comments?

 - Mark

(*) http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-03.txt

See also 
http://www.apnic.net/community/presentations/docs/ietf/2005/20050802-shim6-arch.pdf

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

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 24 Jan 2006 10:09:27 +0100

Hi Mark,

see my comments in-line.

Best regards
Michael

On Jan 24, 2006, at 5:52 AM, Mark Butler wrote:

>
> The SCTP socket draft currently describes the behavior of  recvmsg 
> (2) as having msg_name set to the "source transport address of the  
> user data".  This complicates applications that use addresses  
> instead of association ids to identify peers.
>
> There is draft layer 3 multihoming support for IPv6 based on the  
> idea that upper layer applications should only need to know about  
> the primary address or "upper layer id" of each peer.  The shim6  
> draft (*) describes a shim for IPv6 that does this translation in  
> layer 3.
>
> initiated by the peer).  This address/port would be the "upper  
> layer id". Applications could use the upper layer id as a stable  
> identifier for the peer during the life of the association,  
> allowing them to largely be transparent to multihoming / path  
> failover at the SCTP layer.   The primary advantage of doing this  
> over using association ids is protocol portability, of course.
The association id is exactly used for that. The problem with the  
addresses is, that they can change
over time and they could even move from an association to another  
when ADD-IP is used. So it is a bad
idea to use something, which is not constant over the lifetime of an  
association for identifying an
association.

> See also http://www.apnic.net/community/presentations/docs/ietf/ 
> 2005/20050802-shim6-arch.pdf
>

---

From: Mark Butler <[email-masked]>
Date: Tue, 24 Jan 2006 14:05:03 -0700

Michael Tuexen wrote:

>> id". Applications could use the upper layer id as a stable  
>> identifier for the peer during the life of the association,  allowing 
>> them to largely be transparent to multihoming / path  failover at the 
>> SCTP layer.   The primary advantage of doing this  over using 
>> association ids is protocol portability, of course.
>

I left out something important - sendto(2) would always translate from 
the specified address (the "upper layer id") to the active address.  
Those two translations are adequate to handle the multihoming aliasing 
problem.

For mobile SCTP, sendto()/recvfrom() programming style does not work 
correctly without handling address change events. The only change that 
matters here is when the peer has vacated the original address, 
requiring a new upper layer id assignment (to prevent conflicts with 
other clients occupying the old address).  Other address changes can be 
ignored, because the stack would translate in both directions in the 
same manner as shim6.

More to the point, mobile SCTP applications generally require a session 
oriented programming style, with the session initiated by the remote 
client.  So session identification by association id on the server is 
just fine.   However, if you have a large number of UDP style clients, 
association autoclose and a non-session oriented sendto()/recvfrom() 
style programming is a practical necessity, because associations come 
and go and association ids get arbitrarily reassigned to new peers.

- Mark

Aside: A protocol extension to allow associations to restart after 
shutdown would allow light weight, authenticated virtual associations 
that last indefinitely, even with address mobility.   A proper design 
would allow ULPs to save association cookies and shared keys in 
persistent storage, so that associations could be shutdown and restarted 
days or weeks later.  The ULP should be able to specify its own 
persistent association identifier, and have it returned with every 
incoming message.  That would solve the typical session orientation 
requirement of mobile SCTP applications.

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 24 Jan 2006 22:24:10 +0100

Hi Mark,

see my comments in-line.

Best regards
Michael

On Jan 24, 2006, at 10:05 PM, Mark Butler wrote:

>>> I think the general idea behind this concept is useful for SCTP  
>>> as  well.  To implement this, recvmsg(2) would always return the   
>>> locally) or the initial source address/port (if the association  
>>> was  initiated by the peer).  This address/port would be the  
>>> "upper  layer id". Applications could use the upper layer id as a  
>>> stable  identifier for the peer during the life of the  
>>> association,  allowing them to largely be transparent to  
>>> multihoming / path  failover at the SCTP layer.   The primary  
>>> advantage of doing this  over using association ids is protocol  
>>> portability, of course.
>>
>> idea to use something, which is not constant over the lifetime of  
>> an  association for identifying an
>> association.
>
> I left out something important - sendto(2) would always translate  
> from the specified address (the "upper layer id") to the active  
> address.  Those two translations are adequate to handle the  
> multihoming aliasing problem.
Yes, I assumed this. But the assoc_id just does what you want...
>
>
> For mobile SCTP, sendto()/recvfrom() programming style does not  
> work correctly without handling address change events. The only  
> change that matters here is when the peer has vacated the original  
> address, requiring a new upper layer id assignment (to prevent  
> conflicts with other clients occupying the old address).  Other  
> address changes can be ignored, because the stack would translate  
> in both directions in the same manner as shim6.
I do not get the point here. The stuff is not mobile SCTP related. It  
is just that an IP-address does not identify
an association during the lifetime of the association. The  
association id is exactly designed for it.
>
> More to the point, mobile SCTP applications generally require a  
> session oriented programming style, with the session initiated by  
> the remote client.  So session identification by association id on  
> the server is just fine.   However, if you have a large number of  
> UDP style clients, association autoclose and a non-session oriented  
> sendto()/recvfrom() style programming is a practical necessity,  
> because associations come and go and association ids get  
> arbitrarily reassigned to new peers.
>
> - Mark
>
>
> shutdown would allow light weight, authenticated virtual  
> associations that last indefinitely, even with address mobility.    
> A proper design would allow ULPs to save association cookies and  
> shared keys in persistent storage, so that associations could be  
> shutdown and restarted days or weeks later.  The
> ULP should be able to specify its own persistent association  
> identifier, and have it returned with every incoming message.  That  
> would solve the typical session orientation requirement of mobile  
> SCTP applications.
>
>
>
>

---

From: Mark Butler <[email-masked]>
Date: Tue, 24 Jan 2006 17:02:35 -0700

Michael Tuexen wrote:

>> correctly without handling address change events. The only  change 
>> that matters here is when the peer has vacated the original  address, 
>> other clients occupying the old address).  Other  address changes can 
>> be ignored, because the stack would translate  in both directions in 
>> the same manner as shim6.
>

Well, if there is no mobility, then converting to only one address on 
receive (and the reverse if no association id is specified) ULP has all 
benefits and no downside.  The main benefit would be improved 
portability of UDP applications to SCTP.  That said, association ids 
would be much more useful if you could pre-allocate them.  Something like:

   int sctp_get_assoc_id(int sd, uint32_t * assoc_id);

Then you would not have to send the first message, wait for a matching 
COMM_UP event, and extract the association id for later use. 

 - Mark

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 25 Jan 2006 01:49:17 +0100

Hi Mark,

one comment in-line.

Best regards
Michael

On Jan 25, 2006, at 1:02 AM, Mark Butler wrote:

>>>>> I think the general idea behind this concept is useful for  
>>>>> SCTP  as  well.  To implement this, recvmsg(2) would always  
>>>>> return the   address/port used to initiate the association with  
>>>>> (if initiated   locally) or the initial source address/port (if  
>>>>> the association  was  initiated by the peer).  This address/ 
>>>>> port would be the  "upper  layer id". Applications could use  
>>>>> the upper layer id as a  stable  identifier for the peer during  
>>>>> the life of the  association,  allowing them to largely be  
>>>>> transparent to  multihoming / path  failover at the SCTP  
>>>>> layer.   The primary  advantage of doing this  over using  
>>>> The association id is exactly used for that. The problem with  
>>>> the   addresses is, that they can change
>>>> over time and they could even move from an association to  
>>>> another   when ADD-IP is used. So it is a bad
>>>> idea to use something, which is not constant over the lifetime  
>>>> of  an  association for identifying an
>>>> association.
>>>
>>>
>>> I left out something important - sendto(2) would always  
>>> translate  from the specified address (the "upper layer id") to  
>>> the active  address.  Those two translations are adequate to  
>>> handle the  multihoming aliasing problem.
>>
>>> change that matters here is when the peer has vacated the  
>>> original  address, requiring a new upper layer id assignment (to  
>>> prevent  conflicts with other clients occupying the old  
>>> address).  Other  address changes can be ignored, because the  
>>> stack would translate  in both directions in the same manner as  
>>> shim6.
>>
>> I do not get the point here. The stuff is not mobile SCTP related.  
>> It  is just that an IP-address does not identify
> Well, if there is no mobility, then converting to only one address  
> on receive (and the reverse if no
My point is that usage of ADD/DEL IP does not imply mobility. It is  
invented for reconfiguration... but
can be used for mobility too.
> association id is specified) ULP has all benefits and no downside.   
> The main benefit would be improved portability of UDP applications  
> to SCTP.  That said, association ids would be much more useful if  
> you could
> pre-allocate them.  Something like:
>
> Then you would not have to send the first message, wait for a  
> matching COMM_UP event, and extract the association id for later use.
> - Mark
>
>
>
>