Subject: RE: [Sigtran] multi-homing association

From: Santiago Muñoz (E2/EEM)<[email-masked]>
Date: Fri, 5 May 2006 14:57:22 +0200

Hi,
In the RFC2960 clause 10 it is suggested a upper layer to SCTP layer interface (API), in fact clause 10.1 B) is about the establishment of an association, and there it is said that a list of possible destination IP addresses can be specified.
Though the API method is just a suggestion and the list of destination addresses may only consist of one, so to know several destination IP addresses by the upper layer is just optional, though I dare say desirable (at least two for the case you describe).

If the SCTP upper layer knows several destination addresses, the most optimal implementation of the API should be to specify them all in the ASSOCIATE method to SCTP so it is in charge of trying all specified addresses in the establishment, off loading of such task to the upper layer.

In case only one is indicated to SCTP, if it is down then the association is never established.

How the upper layer knows about the destination addresses, I think it depends on the upper layer implementation, local manual configuration, DNS resolution, any dynamic discovery procedure are valid methods through which the SCTP can knows the destination IP addresses.

Best regards, Santi
-----Original Message-----
From: Michael Tuexen [mailto:[email-masked]] 
Sent: viernes, 05 de mayo de 2006 14:25
To: devayya
Cc: [email-masked]
Subject: Re: [Sigtran] multi-homing association

Hi,

see my comments in-line.

Best regards
Michael

On May 5, 2006, at 1:59 PM, devayya wrote:

> Hi,
>
> I have question, Is it possible or mandatory for the upper layer to 
> know that the SCTP endpoints(source and destination) are multi- homed? 
> and also the list of destination ip address available with the SCTP 
> multi-homed destination?
The interface between SCTP and its upper layer is not specified in an RFC. However, there is an ID describing the socket API which is implemented by some SCTP stacks like the one in *BSD, Linux (LKSCTP), and Solaris.
>
> Consider if the SCTP layer is multi-homed(source and peer end) and the 
> upper layer knows only about a single address, through which the upper 
> layer asks the SCTP to initiate a association. Suppose during this 
> initiation if the peer end address through which initiation is 
> happening, is down. Is there any approach where the upper layer knows 
> the list of multihomed destination ip addresses, and it tries to 
> initate the through the other destination ip addresses?
If the initiating endpoint knows more than one address of the peer, it can use the
connectx() or sendx() call to make use of this knowledge. It is up to the implementation how to make use of it.
> If not possible,  is it that the association between these to 
> endpoints will never come up untill the known destination ip address 
> comes up?
If the endpoint knows only one address of the peer and that address is not reachable, than the association can not be setup.

However, in the SIGTRAN environment is is pretty common (at least from my experience) that an endpoint knows all the addresses of the peer in advance (by
configuration) and can
make use of it even during associations setup.
>
> Please clarify...
>
> Thanks and regards,
> devayya
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
>

_______________________________________________
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: devayya <[email-masked]>
Date: Fri, 05 May 2006 19:24:19 +0530

Hi ,
 Please find my inline comments

regards,
devayya

>If the SCTP upper layer knows several destination addresses, the most optimal implementation of the API should be to specify them all in the ASSOCIATE method to SCTP so it is in charge of trying all…
Does this mean that the if SCTP sends a INIT on first IP address and 
upon not getting the response from destination within the T1 timer, SCTP 
tries with the second destination IP address?
What if, the first destination Ip address responds with INIT or INIT 
ACK? Should we accept it after T1? And what about OOTB INIT ACK 
processing?  Doesnt it mean that we are entering a endless loop.

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 5 May 2006 17:52:47 +0200

Hi,

comments in-line.

Best regards
Michael

On May 5, 2006, at 3:54 PM, devayya wrote:

>> Hi, In the RFC2960 clause 10 it is suggested a upper layer to SCTP  
>> layer interface (API), in fact clause 10.1 B) is about the  
>> establishment of an association, and there it is said that a list  
>> of possible destination IP addresses can be specified. Though the  
>> API method is just a suggestion and the list of destination  
>> addresses may only consist of one, so to know several destination  
>> IP addresses by the upper layer is just optional, though I dare  
>> say desirable (at least two for the case you describe).  If the  
>> SCTP upper layer knows several destination addresses, the most  
>> optimal implementation of the API should be to specify them all in  
>> the ASSOCIATE method to SCTP so it is in charge of trying all  
>> specified addresses in the establishment, off loading of such task  
>> to the upper layer.
> Does this mean that the if SCTP sends a INIT on first IP address  
> and upon not getting the response from destination within the T1  
> timer, SCTP tries with the second destination IP address?
That is how the *BSD implementation handles it. The sctplib sends out  
(limited to max.burst)
several INITs simultaneously. But how you make use of them is  
implementation specific.
> What if, the first destination Ip address responds with INIT or  
> INIT ACK? Should we accept it after T1?
Yes. Why not?
> And what about OOTB INIT ACK processing?  Doesnt it mean that we  
> are entering a endless loop.
You have an endpoint. So none of the INIT-ACKs sent in response to a  
sent INIT would be OOTB.
>> In case only one is indicated to SCTP, if it is down then the  
>> association is never established. How the upper layer knows about  
>> the destination addresses, I think it depends on the upper layer  
>> implementation, local manual configuration, DNS resolution, any  
>> dynamic discovery procedure are valid methods through which the  
>> SCTP can knows the destination IP addresses. Best regards, Santi  
>> -----Original Message----- From: Michael Tuexen  
>> [mailto:[email-masked]] Sent: viernes, 05 de  
>> mayo de 2006 14:25 To: devayya Cc: [email-masked] Subject: Re:  
>> [Sigtran] multi-homing association  Hi, see my comments in-line.  
>> Best regards Michael On May 5, 2006, at 1:59 PM, devayya wrote:
>>> Hi, I have question, Is it possible or mandatory for the upper  
>>> layer to know that the SCTP endpoints(source and destination) are  
>>> multi- homed? and also the list of destination ip address  
>>> available with the SCTP multi-homed destination?
>> The interface between SCTP and its upper layer is not specified in  
>> an RFC. However, there is an ID describing the socket API which is  
>> implemented by some SCTP stacks like the one in *BSD, Linux  
>> (LKSCTP), and Solaris.
>>> Consider if the SCTP layer is multi-homed(source and peer end)  
>>> and the upper layer knows only about a single address, through  
>>> which the upper layer asks the SCTP to initiate a association.  
>>> Suppose during this initiation if the peer end address through  
>>> which initiation is happening, is down. Is there any approach  
>>> where the upper layer knows the list of multihomed destination ip  
>>> addresses, and it tries to  initate the through the other  
>>> destination ip addresses?
>> If the initiating endpoint knows more than one address of the  
>> peer, it can use the connectx() or sendx() call to make use of  
>> this knowledge. It is up to the implementation how to make use of it.
>>> endpoints will never come up untill the known destination ip  
>>> address comes up?
>> If the endpoint knows only one address of the peer and that  
>> address is not reachable, than the association can not be setup.  
>> However, in the SIGTRAN environment is is pretty common (at least  
>> from my experience) that an endpoint knows all the addresses of  
>> the peer in advance (by configuration) and can make use of it even  
>> during associations setup.
>>> Please clarify... Thanks and regards, devayya  
>>> _______________________________________________ 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: Michael Tuexen <[email-masked]>
Date: Fri, 5 May 2006 17:48:52 +0200

Hi Santi,

see my comments in-line.

Best regards
Michael

On May 5, 2006, at 2:57 PM, Santiago Muñoz (E2/EEM) wrote:

>  Hi,
> In the RFC2960 clause 10 it is suggested a upper layer to SCTP  
> of possible destination IP addresses can be specified.
> Though the API method is just a suggestion and the list of  
> destination addresses may only consist of one, so to know several  
> destination IP addresses by the upper layer is just optional,  
> though I dare say desirable (at least two for the case you describe).
>
> If the SCTP upper layer knows several destination addresses, the  
> most optimal implementation of the API should be to specify them  
> all in the ASSOCIATE method to SCTP so it is in charge of trying  
> all specified addresses in the establishment, off loading of such  
> task to the upper layer.
That is why there are connectx() and sendx() calls in the socket API  
in addition to the
connnect() and send() calls.
> association is never established.
>
> How the upper layer knows about the destination addresses, I think  
> it depends on the upper layer implementation, local manual  
> configuration, DNS resolution, any dynamic discovery procedure are  
> valid methods through which the SCTP can knows the destination IP  
> addresses.
There is one problem with the DNS. If you get multiple IP-addresses  
from DNS, you
do not know if they belong to one host.
> connectx() or sendx() call to make use of this knowledge. It is up  
> to the implementation how to make use of it.
> If the endpoint knows only one address of the peer and that address  
> is not reachable, than the association can not be setup.
>
> from my experience) that an endpoint knows all the addresses of the  
> peer in advance (by
> configuration) and can