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

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 6 May 2002 21:44:57 -0500

Xiaoming,

Your question should be posted on [email-masked] 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.

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

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.

--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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

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

---

From: Coene Lode <[email-masked]>
Date: Tue, 7 May 2002 12:04:55 +0200

A few comments below.

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, May 07, 2002 4:45 AM
> To: Xiaoming Fu
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Sigtran] Routing for multi-homed host traffic
> 
> 
> Xiaoming,
> 

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)

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

> 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: [email-masked]
Tel: +32-14-252081
Fax: +32-14-253212

---

From: "Xiaoming Fu" <[email-masked]>
Date: Tue, 7 May 2002 23:04:03 +0200

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:

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

> See
http://search.ietf.org/internet-drafts/draft-coene-sctp-multihome-03.txt
> multihoming.(it has some nice pictures in it, making the problems more

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.

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

> 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

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

--
Xiaoming Fu
[email-masked]
http://www-tkn.ee.tu-berlin.de/

---

From: Coene Lode <[email-masked]>
Date: Wed, 8 May 2002 13:32:01 +0200

some more comments.
> From: Xiaoming Fu [mailto:[email-masked]]
> Sent: Tuesday, May 07, 2002 11:14 PM
> To: [email-masked]; Bob Braden
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [Tsvwg] Re: [e2e] Re: [Sigtran] Routing for multi-homed
> host traffic
> 
> 
> Hi, 
> 
> Brian wrote:
> > SCTP multihoming does not
> > support the Strong ES model, and in fact can be shown to break
> > in a number of ways related to congestion if Strong ES is used.
> 
> Lode wrote:
> > The strong ES model seems to imply source routing of some
> Can you elaborate why things become so hard by using Strong ES? 

some stuff is already mentioned in the other post.
The fig 2.1.3 and surrounding explanation show that is it harder to make it
happen. It also shows that it is not the only solution(figure 2.1.4 show an
alternative). I am just favouring(what I think is) the more simpler one.

Hopes this clarifies things a bit.
> Thanks

yours sincerly,
Lode

Siemens atea

---

From: Coene Lode <[email-masked]>
Date: Mon, 13 May 2002 16:36:41 +0200

Hello Xiaoming,

a few comment below.

> Sent: Sunday, May 12, 2002 8:59 AM
> To: Coene Lode
> Cc: [email-masked]; [email-masked]
> 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.

yours sincerly,
Lode
 
Siemens atea