Subject: Re: [NSIS] mobility-related requirements from nsis-req-08

From: Xiaoming Fu <[email-masked]>
Date: Mon, 11 Aug 2003 15:43:44 +0200

Robert,

Sorry for the delay in answering your mail - I just came back from a few 
days of vocation. Some comments inline:

Hancock, Robert wrote:
> hi xiaoming,
(snip)
> [reh] the fundamental question is: how are the data packets themselves
> being routed? whatever is making them follow the route they follow
> should be invoked to make the signalling packets follow the same route.
> (*how* to make that invocation is another issue; one approach is to
> make the signalling packets look like data packets, another is to 
> make the nodes which do some forwarding which is not-purely-IP-DA
> NSIS-aware and have them route signalling packets at the NTLP level
> on the flow-id directly. see numerous other emails on that subject.)
> 
> [if the data packets are being routed on something other than 3/5 tuple
> and possibly routing header, I suspect we are in deep trouble.]

I totally agree with you that signaling packets should follow exactly 
the same route as data packets (I believe this is part of the NSIS 
requirements regarding mobility and any other things). Now let's go to 
the problem of "how the data packets are routed in mobile IP?" and look 
at CN-->MN in basic Mobile IPv6 protocol first:

- For Mobile IP without route optimization: the data packets will stay 
as normal IP packets (src: CN, dst: HoAddress) before arriving at the 
HA. The HA uses IP-in-IP encapsulation to assemble these packets towards 
the MN's CoA, i.e., the tunnel entry is HA address and the tunnel exit 
is MN's CoA. In the MN, CoA --> HoA is done inside OS. To route these 
data packets, per Melina's NTLP proposal we may have to rely on 
NTLP-in-NTLP tunnel while according to Henning's NTLP proposal, we can 
add some functionalities to NTLP (in this case, for basic Mobile IPv6, 
routing per flow-id works.)

- For Mobile IP with route optimization: very unfortunately, the data 
packets will be destinated to CoA but with a routing header (containing 
MN's HoA). As the CoA can still be seen from the IP normal header, we 
probably don't need special care to routing header, if CoA is used to 
route signaling packets.

Second, may we look at MN-->CN in basic Mobile IPv6 protocol:

- For Mobile IP without reverse tunnel: the data packets will be 
assembled as IP packets with a home address option. We only need CN's 
address to route these packets, not a problem for both proposals.

- For Mobile IP with reverse tunnel: the data packets sent by the MN 
will be encapsulated within a tunnel (entry CoA, exit HA address), with 
the original IP packets destined to CN. In order to address signaling 
packets inside this tunnel, we may either add another NTLP object which 
is similar to SESSION_ASSOC in RFC2746 and map the SESSION object into 
tunnel object (for Melinda's NTLP proposal), or rely on a 
discovery/routing component which locates in NTLP (for Henning's NTLP 
proposal), let it be aware of tunnel entry and exit and determine which 
next NTLP hop to go.

Third, let's go to a bit more complicated case - fast handover and hmipv6:

- As my draft states, these LMM proposals add one or two tunnels in the 
path where data packets traverse in basic Mobile IP. It becomes 
problematic if we re-apply RFC2746 every time when a data packet goes 
into a tunnel (and exits) - imagine how things work if we handle 2+ 
levels of tunnels each by a SESSION_ASSOC object and mapping between 
SESSION <--> tunnel SESSION object (each level the same object type? yet 
another new type for another level?). In this case, Henning's NTLP 
proposal seems to be more appealing, - if we even need to signal into 
such tunnels. On the other hand, I think this holds as long as QoS NSLP 
  demands - Hemant's draft "Requirements of a QoS Solution for Mobile 
IP" states "QoS mechanism for Mobile IP SHOULD have provisions to handle 
such heterogeneity as regards the QoS mechanisms deployed along 
different packet paths. ... A QoS mechanism SHOULD be able to support 
QoS along the different potential packet paths. "

In a short summary:
- 3/5-tuple flow-id could be insufficient to address NTLP messages; some 
additional views are needed for mobility scenarios.
- Mobility is more about an NTLP issue, not only an NSLP issue (although 
NSLP might be necessary to be aware of mobility).

Cheers,
Xiaoming

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