Re: multi-homing association

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?
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.

>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
>
>  
>

_______________________________________________
Sigtran mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/sigtran