[Tsvwg] Re: [e2e] RE: [Sigtran] Routing for multi-homed host traffic

[Coene Lode]

Hello Xiaoming,

a few comment below.

> -----Original Message-----
> From: Xiaoming Fu [mailto:fu at ee.tu-berlin.de]
> Sent: Sunday, May 12, 2002 8:59 AM
> To: Coene Lode
> Cc: end2end-interest at postel.org; tsvwg at ietf.org
> Subject: [Tsvwg] Re: [e2e] RE: [Sigtran] Routing for multi-homed host
> traffic
> 
> 
> Hi Lode,
> 
> > you can have only a single address for B but then you fall 
> into the case of
> > figure 2.1.3(a bit below 2.1.1). With having 2 routing 
> entries in the host
> > routing table of A (instead of one), you will be able to 
> use it. And the
> > source address can be one of the 2 interfaces, provided you 
> then send it out
> > on the interface with that particular soure address. The 
> selection of the
> > particular source address must be done by SCTP or the 
> application above. The
> > network layer has a choice in selecting any of the 2 
> links(they both goes to
> > 3.2), so use a default (eg always use upper link) or using 
> the source addr
> > provided by the transport (and then the network layer has 
> to honour this
> > choice by sending it out over that particular link 
> associated with the
> > source IP).
> 
> Sure, the problem stays, if SCTP or any application above 
> would specify
> a source address, the network layer would have to replace the default 
> routing selection anyway. 
> 
> > A better solution(to me) is to do as in figure 2.1.4 and 
> assign symmetric
> > addresses.
> 
> Agreed. However it may not work for mobile IP, where a 
> correspondent node 
> is expected to use a same IP address while a mobile node moves.
> 
> > > 
> http://search.ietf.org/internet-drafts/draft-tkn-nsis-qosbindi
ng-mipv6-00.txt
> 
> Well, then this is a application who can use this. If the SCTP
> implementation does support this , then you can do it.
>
>Thanks. Actually we didn't intend for SCTP in this context, but
>I think the same idea could be applicable to extend SCTP in 
>mobility scenarios: e.g., establishing an alternative association 
>ASAP while a MN (as an SCTP endpoint) reachs overlapping 
>area.

Well, A somewhat better looking solution might be to do it inside the
association, as the application has otherwise handle the "handover". And
that is the way it is now pursued with SCTP. This is done using the
ADD/delete IP address for adding and deleting a IP address to a
association.(first foreseen for adding/removing  NIC cards on the fly, then
it hit us that this was equally applicable for solving the mobility problem
via the transport layer, just as you point out.) Things sometimes get out of
hand....

See :
Addip SCTP draft
http://search.ietf.org/internet-drafts/draft-ietf-tsvwg-addip-sctp-04.txt
Mobile SCTP draft
http://search.ietf.org/internet-drafts/draft-riegel-tuexen-mobile-sctp-00.tx
t

And there are interoperable implementations of this around.

>
>Regards,
>Xiaoming
> 
> 
yours sincerly,
Lode
 
Siemens atea
atealaan 34          2200 Herentals, Belgium
E-mail: lode.coene at siemens.atea.be
Tel: +32-14-252081
Fax: +32-14-253212