Re: Multihomed SCTP end point

Ambika,

Ambika Tripathy wrote:                        (Sat, 07 Oct 2006 13:45:09)
> 
>    During  data communication it was found that the IP2 is un-plugged and
>    after  some time IP1 also get failed. Should the endpoint-A retransmit
>    data from IP2???
> 
>    In  the current scenario the IP2 does not exist in the system. and the
>    association does not have latest information about the IP2.

What you describe sound rather implementation-specific.

If the implementation at B is following the IG (RFC 4460), then it will
not be able to verify address IP2 and will not send to it (other than
maybe the odd verification heartbeat).  But, I think your question is
about the other end.

SCTP at Endpoint A may or may not have knowledge about the viability of
IP2 or any IP address or outgoing interface for that matter.  I think
that most implementations of SCTP track the viability of an outgoing
interface using indications from the IP layer below, however, it is not
a requirement.

For example, both the OpenSS7 STREAMS and Sockets implementations for
Linux register with the kernel for interface change notifications and
know when an interface is down and when an IP address is no longer
viable.  The same information can be used to trigger the ADD-IP
extension automatically (i.e.  automatic request to delete an IP address
from the association).  Also, if no viable route is discovered, the SCTP
implementation can make the choice to abort associations, or not.

Consider that if one is hot-swapping interface cards, the fact that
there is no viable interface at one moment in time does not necessarily
mean that a usable interface will not become available in the near
future.  Therefore, a policy that aborts associations when interfaces
turn down might be too severe in that it aborts associations that could
have survived when replacement interfaces were swapped in.

Therefore, whether SCTP has information about the viability of
interfaces or not, it might be a better policy to continue to attempt
retransmissions (or take the steps as though a retransmission was
performed) hoping that an interface is restored before the association
peg counts take the association down.

I thought that it was always a nice feature of TCP that one could remove
RJ-45 cords, fiddle with them, and then plug them back in an not loose
any of the network connections provided that you switch them promptly.
This works even though may TCP implementations are fully aware that no
viable route exists and that, through carrier loss, that the interface
is down.  I think that a policy that permits SCTP to behave in a similar
manner is more useful than one that aborts associations the moment
carrier is lost for even a short duration.

Perhaps this is why there is little or no mention of SCTP interpreting
IP level interface events in the specifications.

Now, for SIGTRAN applications, one might want the reverse for some UAs.
For M2PA there is the T7 timeout that will detect if the link is
experiencing excess delay and the link will be taken out of service
anyway (but the SCTP association will not be dropped).  For M2PA the
persistent policy is ok.  The abortive policy would be ok for M2PA
unless the administration does not want network configuration changes to
disrupt signalling links.

For M3UA, the abortive policy might be best.  Unlike M2PA, M3UA has no
means other than SCTP for deciding whether an association is viable from
the standpoint of delay.  If the M3UA implementation is not using a
mechanism like SCTP lifetimes, or is not closely controlling SCTP
protocol parameters to ensure that QOS requirements are met or
associations dropped, a persistent policy could be disastrous: M3UA
could queue a large number of messages to an otherwise failed
association that could seriously degrade service to MTP users.  SUA
and M2UA are similar to M3UA.  Therefore, from the standpoint of an
SCTP implementation in support of SIGTRAN, it might be worth making the
selection of persistent or abortive policy a per-association option.

So, in general, yes, I think that it is fine that Host-A persists in the
association with the hope that either the interface with IP1 or that
with IP2 will be restored at some time in the near future, but perhaps
it is not what you would expect an SCTP implementation supporting
SIGTRAN to do.

It would probably be nice to collect some best common practises with
regard to the use of SCTP for SIGTRAN somewhere, but I suppose that both
SCTP and some SIGTRAN protocol actually has to make it past Proposed
Standard to start a BCP.

Sorry for the long winded answer.

--brian

-- 
Brian F. G. Bidulock
[email protected]
http://www.openss7.org/