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

[Coene Lode]

Comments below.

> -----Original Message-----
> From: Xiaoming Fu [mailto:fu at ee.tu-berlin.de]
> Sent: Tuesday, May 07, 2002 11:04 PM
> To: Lode.Coene at siemens.atea.be; bidulock at openss7.org
> Cc: end2end-interest at postel.org; tsvwg at ietf.org
> Subject: Re: [e2e] RE: [Sigtran] Routing for multi-homed host traffic
> 
> 
> Lode and Brian,
> 
> Thanks for your clarification. Our intention was not to override
> the routing selection in gateways, but to use some kind of routing
> selection (if applicable) only in hosts. More comments inline:
> 
> Coene Lode wrote:
> >
> > A few comments below.
> >
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:bidulock at openss7.org]
> > > Sent: Tuesday, May 07, 2002 4:45 AM
> > > To: Xiaoming Fu
> > > Cc: end2end-interest at postel.org; sigtran at ietf.org; tsvwg at ietf.org
> > > Subject: Re: [Sigtran] Routing for multi-homed host traffic
> > >
> > >
> > > Xiaoming,
> > >
> > > Your question should be posted on tsvwg at ietf.org rather 
> than sigtran.
> > >
> > > The Strong ES model has to do with routing, not source
> > > address selection
> > > for multhomed hosts.  The Strong ES model determines the 
> gateway by
> > > considering the source address.  Under Linux you can turn on
> > > a number of
> > > advanced routing options which takes the source IP address into
> > > consideration when routing a packet.  This has nothing to 
> do with 2)
> > > which is selecting a source address to place in the packet.
> 
> Sure, we have been thinking about routing in hosts. Such advanced
> routing option in Linux, if applicable (which we will check it later),
> should be an example of Strong ES model and a nice feature for
> investigation.
> 
> >
> > RFC3257 describes the multihoming address selection from 
> the transport
> > viewpoint(=SCTP).
> > Another draft describes the impact this might have on the 
> network layer.
> > See
> http://search.ietf.org/internet-drafts/draft-coene-sctp-multih
> ome-03.txt
> >
> > This draft is in IESG review/AD review. It expands a bit on 
> the problem
> and
> > is actually the companion (RFC to be) to RFC3257 going more 
> into detail on
> > multihoming.(it has some nice pictures in it, making the 
> problems more
> > visible)
> 
> My question is, in Figure 2.1.1 (copied as follows) of this 
> draft, is it
> possible to have only one address for endpoint B? Which way can
> endpoint A send packets via 1.2->1.1->...->3.2(4.2) while keeping
> active connection in 2.2<->2.1<->...<->3.2(4.2)? You will have only
> one destination and will be routed (via interface related to IP2.2) to
> same first hop 2.2, in Weak ES model, no matter how you specify
> your source address, I think!
> 
>       +------------+           *~~~~~*            +------------+
>       | Endpoint A |          *   Cloud   *           | Endpoint B |
>       |      1.2   +---------+ 1.1<--->3.1 +----------+ 3.2        |
>       |            |         |             |          |            |
>       |      2.2   +---------+ 2.1<--->4.1 +----------+ 4.2        |
>       |            |          *           *           |            |
>       +------------+           *~~~~~*            +------------+
>             Figure 2.1.1: Two hosts with redundant networks.
> 

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).
This solution is provided by SCTP and can be completely hidden from the
application, but the application will then live under the impresssion that
it is singled homed. So a option for selecting the alternate path may be a
good idea(be it by specifying the source or some other mechanism: it's
implementation dependant). 

A better solution(to me) is to do as in figure 2.1.4 and assign symmetric
addresses.

> > >
> > > What you are looking for, I believe is really as follows:
> > > SCTP provides
> > > in the ULP interface a mechanism whereby the ULP can provide a
> > > destination address associated with a given transmission. 
>  The sockets
> > > sendmsg(2) interface supports this.  The OpenGroup STREAM 
> XTI/TPI also
> > > supports this with the T_OPTDATA_REQ.  Therefore, one can 
> associate a
> > > destination address with your QoS message in some implementations.
> > > Also, IP_OPTIONS can be specified with sendmsg(2)  and 
> t_optdata() to
> > > provide for constrained routing or at least to provide 
> the first-hop
> > > gateway address (not generating any options in the 
> outgoing packet).
> > > So, by specifying the destination address and first-hop
> > > gateway address
> > > in the sendmsg(2) call an implementation could be made to 
> do what you
> > > want it to do: select the first gateway address and route 
> a specific
> > > packet to its destination via that address.
> > >
> 
> Thanks, I don't mind specifying a source address in my 
> signaling message,
> but
> want to have it passing thru a secondary path. This could be
> either:
>   e.g., using a routing header in IPv6, or IP_OPTIONS in IPv4 as you
> suggested,
> both of which are costly: packet becomes a bit larger; 
> first-hop gateway has
> to
> check and process the option in such an IPv4/6 (signaling) packet.
> or:
>   bypassing the gateway selection rules (and specify a 
> first-hop gateway)
> in the host totally (which was not intended)
> 
> 
> This was my major concern here. A Strong ES model should therefore be
> an ideal solution to this case but I'm not sure whether it is 
> supported by
> hosts.

it is a implementation dependant feature.

> 
> > What you are trying to do is to override the gateway 
> selection(which is
> > normally based on the destination address). This could lead 
> to specifying
> a
> > gateway IPg1 while the destination address(Src-IPx2,Dest-IPy2) would
> > normally route to gateway IPg2
> > It looks inconsistent but might work if IPg1 has a routing entry for
> > Dest-IPy2.
> 
> Exactly, that's what I meant by "the same destination".
> 
> > It is then up to the routing in the gateway to route the msg(and
> > hope that it can). But it would also mean that the source 
> address of the
> msg
> > would not correspond to the source address of the interface 
> on which the
> msg
> > was transmitted out. (if you want to send to IPg1, then you 
> take interface
> > 1, so you should have a msg with addresses Org-IPx1, 
> Dest-IPy2, under the
> > assumption that IPg1 will be able to route a msg with Dest-IPy2.
> >
> > There might be a point in using this but giving the 
> application a extra
> > choice in specifying which gateway to use might be for most 
> applications a
> > bit of overkill.
> > It looks dangerous to me.
> 
> This might be useful for some cases, e.g., in mobile 
> environment, when a
> mobile
> node enters into an area where coverage of two access router 
> overlap, it
> would
> be nice to check the resource availability in the new path. Here a QoS
> signaling
> through the new path (via the new access router) ASAP would 
> be beneficial,
> if a
> mobile user desires QoS at all. We have submitted an I-D 
> based on this idea
> in:
> http://search.ietf.org/internet-drafts/draft-tkn-nsis-qosbindi
ng-mipv6-00.tx
t .

Well, then this is a application who can use this. If the SCTP
implementation does support this , then you can do it.
I'll have a look at your draft. 


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