RE: multi-homing association

Hi,
Sorry for the delay, comments in-line.
BR, Santi.

> -----Original Message-----
> From: Michael Tuexen [mailto:[email protected]] 
> Sent: viernes, 05 de mayo de 2006 17:53
> To: devayya
> Cc: Santiago Muñoz (E2/EEM); [email protected]
> Subject: Re: [Sigtran] 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?
[santi] That's what SCTP RFC said. 
> 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.
[santi] Another way, that's more effective in case of an address not responding. 
> > What if, the first destination Ip address responds with INIT or INIT
> > ACK? Should we accept it after T1?
> Yes. Why not?
[santi] Of course, the initiator is in state cookie-wait after sending INIT, so in principle it can accept any INIT-ACK, futhermore given that the INIT sent to IP address 1 is identical to the one sent to IP address 2, and thus the corresponding INIT-ACK.
In case of reception of INIT from the remote end, this is also covered by the collision of simultaneous associtation establishment.
> > 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.
[santi] Agree, initiator is in state cookie-wait, waiting for INIT-ACK. Otherwise if the state is different from cookie-wait then the INIT-ACKs are discarded
> >> 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
> 
>