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

From: Jacob Heitz <[email-masked]>
Date: Thu, 22 Mar 2001 14:44:14 -0800

"Brian F. G. Bidulock" wrote:
> 
> 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.

No. If an IP interface goes down, the IP address of that interface
becomes unreachable, even if the host has other interfaces. The
host remains reachable, but not through the address of the down
IP interface. The host can only be reached through the IP address
of an up interface.

You can do tricks with static routes to avoid the problem.
However, making SCTP have to rely on static route tricks is
distasteful, even if this is the "suitably configured network"
you refer to above.

Another trick is to add an internal "pseudo" IP interface that
is always up. The host will act as a router and advertize the
IP address of this pseudo interface through all others, thus making
it always reachable. Then you use this address as your primary
SCTP address. However, you MUST use the real interface addresses
as secondary addresses to ensure no delays while waiting for routing
protocols to converge when a real interface goes down.

However, not all hosts support such internal pseudo IP interfaces,
so SCTP should not be made to rely on that either.

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

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 22 Mar 2001 18:44:07 -0600

Jacob,

What broken OS is this that won't allow the same IP address
to be assigned to more than one interface?  And that won't
accept an IP packet over a specific interface without the IP
address of that interface being the destination address?

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