Subject: [Tsvwg] multihoming issues via SCTP

From: Coene Lode <[email-masked]>
Date: Mon, 10 Sep 2001 14:26:20 +0200

Folks,

Recently, the following draft was released:

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Multihoming issues in the Stream Control
Transmission 
                          Protocol
	Author(s)	: L. Coene et al.
	Filename	: draft-coene-sctp-multihome-00.txt
	Pages		: 
	Date		: 31-Aug-01
	
This document describes issues of the Stream Control Transmission
Protocol (SCTP)[RFC2960] in regard to multihoming on the Internet. It
explores cases where through situations in the internet, single
points-of-failure can occur even when using multihoming and what the
impact is of multihoming on the host routing tables.

A URL for this Internet-Draft is:
<http://www.ietf.org/internet-drafts/draft-coene-sctp-multihome-00.txt>

We ar not quite sure where the home of this draft is(which WG it belongs to)
but the ultimate goal for this draft is to identify  and find solution(s)
for the issues described in the draft. Once that is done, then this draft
will expire.

I would much apperciate if you have suggestions concerning:
- does it belong in these WG's(presently I have send it to the TSV WG(=home
of SCTP now) and to the multi6 WG) or in another WG.
- Are there errors in it?
- Are there things omitted that should be in.
- should some stuff be taken out.
- any other suggestion.

You can send them to me([email-masked])  or can be discussed on
the mailing list.

yours sincerly,
Lode Coene

Siemens atea ICN D CS D
Software development
Atealaan 34
B-2200   Herentals    Belgium
Tel: +32-14-2-52081   Fax: +32-14-2-53212
E-mail: [email-masked]

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 10 Sep 2001 17:17:12 +0200 (CEST)

> impact is of multihoming on the host routing tables.

The main problem is the idea of paths from an interface on one host to an
interface on another host. This could work if the hosts are both connected
to two networks that are not interconnected, but not on anything
resembling the Internet.

For instance, consider host A having interface 1 connected to ISP X and
interface 2 to ISP Y. By coincidence host B it is communicating with, is
connected to the same ISPs, but the other way around: interface 1 to Y and
interface 2 to X. So now host A tries to connect to host B over interface
1, ISP X, ISP Y and interface 1 of host B (A1->X->Y-B1) and also
A2->Y->X->B2. This should work just fine, although two ISPs instead of one
in each path may not give the best possible performance.

But now there are three ways in which the connection can fail: either of
the ISPs may fail, or the connection between them.

This means there have to be more paths:

A1->X->Y->B1
A1->X->B2
A2->Y->B1
A2->Y->X->B2

However, this assumes both that the output interface stays the same over
the life time of a connection and that the end host is the one making the
decision how packets are routed to the outside. Both are unlikely. If an
output interface fails, hosts may simply reroute outgoing packets over the
other interface. And in most cases, routers will reroute packets over
another path if a connection to an ISP fails. So the other side will often
still see incoming traffic from a remote address that is no longer
reachable for outgoing packets.

Also, I don't like the idea of a protocol sending keepalives over a path
it is otherwise not using. This is a waste of resources and can trigger
inefficient use of different kinds of caches. Also, it won't do much good
unless there are three or more paths of which at least two fail, a
situation that is not likely to be very common.

Iljitsch van Beijnum

---

From: Andreas Jungmaier <[email-masked]>
Date: Tue, 11 Sep 2001 17:20:38 +0200

Iljitsch,

routing is done on a per destination address basis, so that 
your endpoints routing table will determine the interface
depending on the address that the packet is sent to.

> 1. A1->X->Y->B1
> 2. A1->X->B2
> 3. A2->Y->B1
> 4. A2->Y->X->B2

So either your will choose either 1. or 3. to reach address B1, and your OS
will choose either 2. or 4. to reach address B2. In any way, your routing will
take care that in this case there are only 2 paths !!
It is your responsibility as network engineer to install your routing in 
a way that it works effectively if you rely on the multihoming features
of SCTP, if you use it, say, for Signalling Transport (for which it was
originally said to be developed).

Since 2. and 3. are desirable routes, you should make sure inside your
example network, that anything attached directly to X (such as B2) is
reached via the interface A1, and anything directly attached to Y (such
as B1) is to be reached via (your) interface A2.

We tried to address that in the SCTP applicability statement draft.

Best regards,

Andreas

- -- 

- ------------------------------------------------------------------------
Dipl.-Ing. Andreas Jungmaier              |                         _
Computer Networking Technology Group      | ASCII ribbon campaign  ( )
University of Essen                       |  - against HTML email   X
http://www.exp-math.uni-essen.de/~ajung   |              & vcards  / \