Subject: [Tsvwg] Re: SCTP multi-homed fault-tolerance.

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 22 Mar 2001 15:49:06 -0600

Robert,

I'm sure you will get other answers, but let me venture an
answer to your concerns:

An SCTP association can be formed with a list of destination IPs.
The existing API does not require the ULP to know what that list
is, only to know a primary IP address.  SCTP supports multi-
homed hosts not multiple hosts.  A multi-homed host has multiple
interfaces.  Just because one interface which serves the primary
IP address is unavailable does not mean that another interface
willing to serve the same IP address is not available.  With a
suitably configured network, if the host is refusing the primary
address it is because the host is unavailable on all addresses.

I believe you may be considering such a case as when two
endpoints are connected by multiple disjoint networks.  This is
the only time that it is possible that a destination IP address
might be unavailable when the other is available.  The answer
to your problem is "don't do that": join those networks with
a router (or two!).

If networks to multi-homed hosts are not disjoint, your question
might become: "What is the use of SCTP's multi-homed feature?"
The answer is that the association with the multi-homed hosts
may be able to more quickly deal with configuration changes and
failures within the network by attempting alternate routes based
on alternate destination transport addresses.

The existing API nicely relieves the ULP (client at least) from
the burden of knowing which additional addresses the server has
available.  It nicely hides the multi-homed nature of the
asssociation from the client-side ULP.

--brian

On Thu, 22 Mar 2001, Fairlie-Cuninghame, Robert wrote:

> 
>    Hi everyone,
>    
>    I'd like to hear your opinions on SCTP Association fault-tolerance
>    w.r.t multi-homed SCTP endpoints. I believe that the recommended ULP
>    protocol interface is making full fault-tolerance more difficult and
>    in any case more comment is needed in the spec (IMO). For this
>    discussion, let us assume that all transport addresses of a remote
>    multi-homed SCTP endpoint are known in advance.
>    
>    The SCTP ULP interface recommends that the ASSOCIATE function accept
>    only one remote transport address in its arguments. Normally, the INIT
>    ACK will then contain the full set of transport addresses thereby
>    enabling the fault-tolerant behavior. However, if that interface
>    happens to be out-of-service at the time that the INIT is sent then
>    fault-tolerance is not achieved. [That is, the failure situation is
>    induced if the association must be established while the primary
>    interface is out-of-service.]
>    
>    Now the application can provide this redundancy itself but this is far
>    from optimal. For instance, the application can attempt to INIT
>    address-by-address. However, you don't want the SCTP stack to retry
>    the INIT 'n' times before reporting failure to the application - you
>    want to round-robin the INIT addresses just as you would for a normal
>    address. For the application to be able to accomplish this properly,
>    the implementation must allow you to configure the retransmit of the
>    initial INIT separately to the retransmit value for other control
>    chunks. The responsibilities of the application for fault-tolerance
>    should at least be discussed in the spec.
>    
>    The application also has to handle the case where multiple or
>    inconsistent INIT ACK's are received (for instance if
>    mis-configuration occurs and the set of transport address actually
>    refers to multiple SCTP endpoints). [Whether or not to accept the
>    association must be up to the application but the SCTP stack can still
>    assist.]
>    
>    I think the API should be extended to remove a lot of this burden for
>    fault tolerance from the application. As it stands, SCTP is only
>    providing full fault-tolerance when the association is already
>    established which in my opinion is not sufficient. At the very least
>    this needs to be discussed.
>    
>    I'm sure this is not new but I am surprised that it is not addressed
>    at all.
>    
>    Robert.
>    ---
>    You are currently subscribed to sigtran as: [email-masked]
>    To unsubscribe send a blank email to
>    [email-masked]

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Thu, 22 Mar 2001 18:20:59 -0500 (EST)

We have added support for sctp into tcpdump. We have not yet sent our
updates to the tcpdump maintainers, because we want to give everyone a
chance to test it. So, we have temporarily given it the version:
tcpdump3.4-sctp0.02, where 3.4 is the tcpdump version we modified and 0.02
is our revision number.

You may download it from either:
	netlab.cis.temple.edu/SCTP
	www.cis.udel.edu/~acaro/research

Please send comments, bug reports, etc to the authors:
	Jerry Heinz II <[email-masked]>
        John Fiore <[email-masked]>
	Armando Caro <[email-masked]>

-----------------------------------------------------------------------
Armando L. Caro Jr.                                  [email-masked]
University of Delaware                   http://www.cis.udel.edu/~acaro
-----------------------------------------------------------------------