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

Tue May 7 03:04:55 PDT 2002

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.

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-multihome-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)

> 
> Now, RFC3257 considers only a Weak ES model.  This is because,
> regardless of RFC1122, our A-D deflected Strong ES model 
> considerations
> for SCTP stating that they were "the stuff of research".  So, in
> RFC3257, when it talks about source address selection, it is 
> indicating
> that the source address in the outgoing packet should be an address of
> the interface resulting from the Weak ES Model routing algorithm
> (subject to binding constraints: meaning that the address must be a
> valid source address for the association).
> 
The strong or weak ES model did not take centerstage in our discussions when
writing both drafts(or I must be seriously be mistaken).
However trying to answer the question:
If I have read(and understood) RFC1122 correctly, I think we are doing the
weak ES model. The strong ES model seems to imply source routing of some
kind and as such make things harder and easier to break.  

> 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.
> 
> The short of it is, I believe, that you don't want to specify 
> the source
> address, you want to specify the destination and gateway address.  You
> can still select the source address of the outbound interface selected
> to the Weak ES Model, it is just that you bypass gateway selection by
> specifying the first-hop gateway address.

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

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

> 
> --brian
> 
> 
> Xiaoming Fu wrote:                                       
> (Mon, 06 May 2002 01:31:07)
> > Hi all,
> > 
> > I'm wondering how a multi-homed host can deliver such "special" data
> > through an alternative path while "normal" data through a 
> default path
> > toward the same destination. This has been originated by 
> the following
> > problems:
> > 
> > 1)	how to send a QoS signaling message (to check/re-establish QoS
> >	status) through a potential path while the normal data traffic
> >	of the mobile node is still through the old path (suppose the MN
> >	already obtains a new Care-of-Adress from the new subnet). With
> >	our trial based on MIPL Mobile IPv6 for Linux, specifying the
> >	source IP address proved unable to achieve this. Our
> >	(temporary?) way was to use a routing header (first destination:
> >	the new Access Router - nAR) but apparently it introduces
> >	certain overhead;
> > 
> > 2)	how to send a heartbeat message in SCTP.  It is stated in
> >	RFC3257 that "When the endpoint chooses a source address, it
> >	should always select the source address of the packet to
> >	correspond to the IP address of the Network interface where the
> >	packet will be emitted subject to the binding address
> >	constraint." However the routing rule in the endpoint (which is
> >	not explicitly indicated in SCTP specs), may not support this.
> > 
> > RFC1122 sugests implementors may use either of two different
> > conceptual models for multihoming host (without preference):
> >
> >    Strong ES Model:
> >                          route(src IP addr, dest IP addr, 
> TOS) -> gateway
> >    Weak ES Model:
> >                          route(dest IP addr, TOS) -> 
> gateway, interface
> > 
> > It seems to me the Strong ES model holds as a (default) 
> assumption for
> > 2).  But I don't understand why 1) doesn't work that way. Could some
> > one clarify me, is the Strong ES Model ever the best practice /
> > solution to routing for multi-homed host traffic?
> > 
> > Thanks,
> > Xiaoming
> > 
> > 
> > 
> > _______________________________________________
> > Sigtran mailing list
> > Sigtran at ietf.org
> > https://www1.ietf.org/mailman/listinfo/sigtran
> 
> -- 
> Brian F. G. Bidulock
> bidulock at openss7.org
> http://www.openss7.org/
> 
> _______________________________________________
> Sigtran mailing list
> Sigtran at ietf.org
> https://www1.ietf.org/mailman/listinfo/sigtran