Re: multi-homing association

Hi,

comments in-line.

Best regards
Michael

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

> Hi ,
>  Please find my inline comments
>
> regards,
> devayya
>
> Santiago Muñoz (E2/EEM) 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 protected]] Sent: viernes, 05 de  
>> mayo de 2006 14:25 To: devayya Cc: [email protected] 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 protected] https://www1.ietf.org/mailman/listinfo/sigtran
>> _______________________________________________ Sigtran mailing  
>> list [email protected] https://www1.ietf.org/mailman/listinfo/sigtran