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

From: "Hancock, Robert" <[email-masked]>
Date: Sun, 17 Aug 2003 23:59:04 +0100

Hi Xiaoming,

You'll have to forgive me for being dense, but I'm unable to follow your
argument. So far as I can see, all the scenarios and packet flows you 
list can be signalled for correctly and safely using 'ordinary' NSIS 
signalling, possibly supplemented by some special tunnel support. (BTW, 
nobody has ever proposed NTLP-in-NTLP tunneling, so far as I can tell;
I'm not even sure what this would mean.)

Specifically:
*) a route optimised data flow from CN->MN can be treated like any
flow from CNaddr --> MN-CoA (the type 2 routing header can be ignored)
*) a non-reverse tunneled data flow from MN->CN can be treated like any
flow from MN-CoA --> CNaddr (the HoAO can be ignored)
*) non-route-optimised traffic from CN->MN can be treated like any flow
from CNaddr --> MN-HoA, supported by additional signalling from 
HA --> MN-CoA (the HA has to be NSIS aware)
*) reverse tunneled traffic from MN->CN can be treated like any flow from
MN-HoA --> CNaddr, supported by additional signalling from MN-CoA --> HA
(the MN has to run 2 signalling sessions).
*) In the edge tunneling case, traffic and existing signalling messages
will be hidden in a bidirectional tunnel between PARaddr and NARaddr; the ARs
can carry out signalling for that tunnel. In the FMIP6 case, this is just a
single level tunnel, since the ARs only ever see traffic as addressed to
and from the MN-CoA (but in any case, I'm not aware of why multiple levels
of 2746-style tunneling would not work).

It might be helpful if you could say if you think
either: a traditional 2746-like solution really would not work 
(and if so why), 
or: if you think it just would not work very well
(and if so what - in simple terms - you propose in its place.)

Handling an addition signalling session at the tunnel endpoints is clearly
additional work; however, the 2746-like solution can be made very robust
to conditions like the remote endpoint being NSIS-unaware, whereas more
integrated solutions would either have to detect this and fall back to 2746
anyway, or [worse] proceed blind and run the risk of black-holing the end-to-end
signalling. Both those cases strike me as unattractive, given that we will
need to have 2746-like support for many other scenarios anyway.

cheers,

r.

> -----Original Message-----
> From: Xiaoming Fu [mailto:[email-masked]]
> Sent: Monday, August 11, 2003 14:44
> To: Hancock, Robert; [email-masked]
> Cc: 'Charles Q. Shen'; 'Paulo Mendes'
> Subject: Re: [NSIS] mobility-related requirements from nsis-req-08
> 
> 
> 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

---

From: Xiaoming Fu <[email-masked]>
Date: Mon, 25 Aug 2003 00:33:22 +0200

Hi Robert,

Thanks for your extensive comments, which are very helpful to review the 
mobility scenarios for NSIS.

Yes, it is true that we are currently not discussing (I agree it needs 
to be considered in NSLP) what happens for the data packets (which are 
signaled for) inside an IP-in-IP tunnel, but the tunnel endpoints. In 
addition, I believe there might be something being overlooked:
==> Signaling should reflect the data being signaled upon the update of 
the tunnel. As some other interested people might also have noticed, the 
mobility registration itself is also soft-state based. The mobility 
registration phase does not occur only at t0, or during re-registration 
after a timeout, in the operation of mobile IP. Once a first binding 
cache is associated, it is possible for more than 1 tunnels segments to 
be added to the data path. Therefore, while the post-registration phase 
in ongoing in one part of the system the pre-association phase can be 
ongoing in another.

Hancock, Robert wrote:
> argument. 
==> I think both of us have been trying to clarifying things complementally.

> So far as I can see, all the scenarios and packet flows you 
==> Thanks, these are also my hope. (Also thanks for your 
acknowledgement of possibile necessity of special tunnel support).

> I'm not even sure what this would mean.)
==> One can think of a way (although not enough efficient), to add an 
NTLP header to the NTLP message when it enter into a tunnel, and remove 
the additional NTLP header after leaving.

> flow from CNaddr --> MN-CoA (the type 2 routing header can be ignored)
==> Yes, excluded its difficulty already.

> flow from MN-CoA --> CNaddr (the HoAO can be ignored)
==> Yes, also discussed.

> HA --> MN-CoA (the HA has to be NSIS aware)
==> We're also almost agreeing to each other here. Are you suggesting to 
signal twice into the segment between HA and MN? Otherwise, I'm afraid 
whether a unified (for a single message at one time) 3/5-tuple flow-id 
would work.

> (the MN has to run 2 signalling sessions).
==> Signaling by 2 sessions looks a bit wired/complicated to me: how to 
coordinate both, eg., should they be performed subsequently one after 
another, or parrallelly? if some error happens to one of them, should we 
skip another, or special notification/decision should be made?

> can carry out signalling for that tunnel. 
==> It has been identified during the MIP-QOS mailing list discussions 
that a scenario can be possible: while the ARs are physically locating 
close to each other, data packets can be traversing rather long, even 
into the core, and it would be desireable in such scenarios to also 
signal into these path.

> In the FMIP6 case, this is just a
> and from the MN-CoA 
==> If the PAR receives data packet arriving at PCoA, they will be 
tunneled to NCoA, I see this as a 2-level tunnel case (correct me if I'm 
wrong).

>(but in any case, I'm not aware of why multiple levels
==> Not "would not work", but a little bit difficult in case of multiple 
levels of tunnels, as it seems each level has to introduce a different 
object type in the NTLP header (and process them).

> (and if so what - in simple terms - you propose in its place.)
==> My understanding is that RFC2746 might needs some neat work. RFC2746 
discusses possible solutions to two types (type #2 and #3) of tunnels. 
It looks to me mobile IP tunnels most likely will be of type #3. 
RFC2746, essentially, recursively re-applies RSVP inside a tunnel by an 
additional object to help the one-to-one mapping between the tunnel 
session and the corresponding e2e session (the mapping is done in the 
tunnel entry and exit points). However, in the perspectives of the soft, 
possibly multiple tunnels created by mobility protocols, we might look 
into some technical details.

> need to have 2746-like support for many other scenarios anyway.
==> I also think RFC2746 would be a good start for looking at NSIS 
mobility. Any additional comments, views would be more than appreciated.

Thanks,
Xiaoming