[e2e] RE: [Sigtran] Routing for multi-homed host traffic
Xiaoming Fu
fu at ee.tu-berlin.de
Tue May 7 14:04:03 PDT 2002
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-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)
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.
> >
> > 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.
> 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-qosbinding-mipv6-00.tx
t .
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
>
> >
> > --brian
> >
> > > _______________________________________________
> > > 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
>
>
--
Xiaoming Fu
fu at ee.tu-berlin.de
http://www-tkn.ee.tu-berlin.de/
More information about the end2end-interest
mailing list