Subject: RE: [NSIS] Proposed draft "Mobility Support in NSIS"

From: "Charles Q. Shen" <[email-masked]>
Date: Sun, 6 Jul 2003 20:09:11 -0400

Hi,  

I think having such a draft discussing mobility issues with NSIS is
helpful and inline with the WG charter. I started a similar effort in an
earlier draft last July
http://www.ee.columbia.edu/~charles/publication/draft-shen-nsis-mobility
-fw-00.txt.  

Fu's draft incorporated some recent issues including NSLP/NTLP
interaction, Discovery, peer-to-peer addressing etc. It would be good to
elaborate those parts when they become clearer in the WG discussion. 

Disscussion of tunneling/non-optimized routing is also useful, but it
would be beneficial to refer to RFC2746 which provides a very good
example of solving tunneling issues in the case of RSVP. 

Some issues may also be grouped together. Basically there are cases of
sender mobility and receiver mobility (The protocol itself could be
either sender initiated or receiver initated). Handoff causes
appropriate signaling actions in three segments of the network: the
intact path, the new path and the obsoleted path. (This applies to both
optimized/non-optimized routing, and possibly involves tunneling.) The
handoff process would further impact subsequent regular soft-state
refresh which has to be considered.

Best regards,

Charles

---
Charles Q. Shen
Department of Electrical Engineering
Columbia University
Email: [email-masked]
Phone: +1 212 853 8475
http://www.ee.columbia.edu/~charles

-------- Original Message --------
Subject: [NSIS] Proposed draft "Mobility Support in NSIS"
Date: Sat, 28 Jun 2003 23:43:09 +0200
From: Xiaoming Fu <[email-masked]>
To: [email-masked]

Hi all,

Here is a new Internet Draft that we propose as a problem statement and
proposed mechanisms to extend NSIS for mobility support:
http://www.ietf.org/internet-drafts/draft-fu-nsis-mobility-00.txt or
http://www.ietf.org/internet-drafts/draft-fu-nsis-mobility-00.pdf

Following previous work (Michael Thomas, Cedric Westphal/Hemant Chaskar,
Charles Shen, and many others), this Draft aims to provide an extensive
view on mobility support related issues that will be of broad general
use.

We welcome your comments. We are also especially interested in other
open issues and studying how they may be addressed by future versions of
the Draft.

Regards,
Xiaoming

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

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

---

From: Xiaoming Fu <[email-masked]>
Date: Mon, 07 Jul 2003 10:22:05 +0200

Hi,

Thanks for your insightful comments. My comments inline:

Charles Q. Shen wrote:
> http://www.ee.columbia.edu/~charles/publication/draft-shen-nsis-mobility-fw-00.txt.  

I read this draft and found it helpful. For example, your draft 
identified the necessity to soft-state refresh even for the _intact 
path_ (I find this term looks more appealing than _common path_ :)) 
before and after a handoff happens. This has also been summarized in 
issue 3 and section 4.1 in our draft.

> elaborate those parts when they become clearer in the WG discussion. 

Yes, to my understanding a concrete conclusion has not been drawn so far 
on whether end-to-end or peer-peer addressing will be used in NTLP. 
That's why the draft discusses both peer-peer and e2e addressing issues 
there, in align with framework draft. It is also my belief that with the 
further development of framework/protocol work, discovery and NSLP/NTLP 
issues would be clearer and we'll be able to look into these issues in 
depth.

> example of solving tunneling issues in the case of RSVP. 

You're right! This is related to the addressing mode of NTLP messages. I 
think RFC2746 scheme would probably be most useful for at least e2e 
addressing approaches such as RSVP. For peer-peer addressing, it looks 
to me discovery component would help to identify next peer and IP-in-IP 
tunneled signaling message can be avoided, as long as the MIP tunnel 
endpoints support NTLP.

> optimized/non-optimized routing, and possibly involves tunneling.) 

Thanks for your suggestions, such restructuring looks fine to me.

> The handoff process would further impact subsequent regular soft-state
Regarding the two types of soft-state timers: the mobility management 
timer (let's assume "only" one mobility management, or minimal value of 
timers of all mobility management schemes) and the NSIS timer (let's 
assume NTLP would do some basic state management), there are a few open 
issues (have not explored in our draft yet):

- Shall we use a smaller value for NSIS timer than mobility management 
timer? my conjecture would be "yes", to ensure NSIS signaling actually 
reflect mobility signaling.

- How can we know this comparision at all? This could be through an API, 
or, say, a mobility routing interface issue. If this knowledge is 
unaware to NSIS at all, a simplest way presumably can be NSIS signlaing 
directly after each moibility management.

Cheers,
Xiaoming

---

From: "Charles Q. Shen" <[email-masked]>
Date: Mon, 7 Jul 2003 15:53:48 -0400

Hi Xiaoming, 

Thanks for your reply. Please find comments inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Xiaoming Fu
> Sent: Monday, July 07, 2003 4:22 AM
> To: Charles Q. Shen; [email-masked]
> Subject: Re: [NSIS] Proposed draft "Mobility Support in NSIS"
> 
> 
> Hi,
> 

Thanks :-)

> issue 3 and section 4.1 in our draft.

Yes, I think it is very appropriate to include this issue into the
draft. When we did our RSVP-Mobile IP implementation we found it
actually causes many complexities as detailed in our implementation
draft. 
http://www.ee.columbia.edu/~charles/publication/draft-shen-nsis-rsvp-mob
ileipv6-00.txt

As to the terminotlogy, we can always think about better ones :)

> issues would be clearer and we'll be able to look into these 

That would be very helpful because those aspects differentiate the
protocol from original RSVP and require new efforts that are different
from existing work on RSVP mobility.

> tunneled signaling message can be avoided, as long as the MIP tunnel 

Yes, you are right, the two addressing modes should be treated
differently on this issue.

1) in e2e mode like RSVP, RFC 2746 describes three possibilities of the
(logical) link. That seems to me is a more generic description. You are
certainly correct in pointing out the requirement for the two tunnel end
points to be NSIS aware to achieve a true e2e signaling.

2) in p2p mode, if the discovery is done properly with the help of NSIS
aware tunnel endpoints, you are probably right that such tunneling could
be avoided. (Do we have the path-coupled assumption here? )

> Thanks for your suggestions, such restructuring looks fine to me.

Thanks.

> 
> > The handoff process would further impact subsequent regular 
> soft-s  tate

I think there is always a trade-off here in terms of signaling overheads
and promptness of response. Upon handoff, trying to achieve an
"on-demand" adjustment (i.e., movement triggers both MIP and NSIS) is
probably appropriate. During normal refresh, I agree that generally the
NSIS timer should not be larger than the mobility timer. After all, why
should the specific NSIS signaling (e.g. QoS) be still there if the
mobility entry has expired? Of course there might be more details to
look at. 

Cheers

Charles

---

From: Xiaoming Fu <[email-masked]>
Date: Tue, 08 Jul 2003 12:22:22 +0200

Charles,

> be avoided. (Do we have the path-coupled assumption here? )

True. RSVP signaling uses RSVP-in-RSVP encapsulation to support IP-in-IP 
tunnels in the data path. In the p2p mode, due to the seperation of 
discovery from signaling, an NTLP hop (either in the (MIP) tunnel 
entrance or inside the tunnel) can discover the next NTLP hop along the 
path anyway, thus avoiding NTLP-in-NTLP.

With p2p mode, signaling can be extended to be somehow path-decoupled, 
but we may look at path-coupled first only.

> "on-demand" adjustment (i.e., movement triggers both MIP and NSIS) is
                                -------->"route change"? (the node can
                                         be mobile host, home agent,...)
> probably appropriate. 

This is another possibility one can do. IMO NSIS signaling after MIP 
signaling might be less complex, as it can happen MIP fails but NSIS 
succeeds if a handoff triggers both (then you need additional signaling 
to release NSIS states). Since the places where a route change takes 
place after a handoff differ, we have to coordinate these events (see 
some discussions in our I-D).

Cheers,
Xiaoming

---

From: "Charles Q. Shen" <[email-masked]>
Date: Wed, 9 Jul 2003 01:33:59 -0400

Xiaoming, a few comments inline.

> From: Xiaoming Fu [mailto:[email-masked]] 
> Sent: Tuesday, July 08, 2003 6:22 AM

I think the path-decoupled case is different in that signaling message
itself may not care about optimized/non-optimized path, but the related
actions (e.g. QoS allocation) performed will still involve the routing
path used. I agree that we may look at path-coupled case only at this
time.

> > I think there is always a trade-off here in terms of signaling 
> > overheads and promptness of response. Upon handoff, trying 
> to achieve 
> > an "on-demand" adjustment (i.e., movement triggers both MIP 
> and NSIS) 
> > is

Usually I refer to "movement" as mobile node changing its points of
attachment at network edge. But there is a close relationship between
this and route change inside the network. I remember that is exactly how
we came up with using "RSVP local repair property" in the RSVP-mobility
framework. 

> to release NSIS states). 

Yes, you are right. By loosely saying "trigger both", there are actually
still possibilities of "triggering both in parallel" or "triggering both
in sequential". Again there is a tradeoff of choosing either of them. 

> Since the places where a route change takes 

Not crystally clear about what you mean in this senstence, appreciate it
if you could elaborate.

BR/ Charles

---

From: Xiaoming Fu <[email-masked]>
Date: Wed, 09 Jul 2003 16:19:23 +0200

Charles,

> path used. I agree that we may look at path-coupled case only at this

Independent of optimizated/non-optimized path, NSIS signaling can have 
minimum influence with MIP signaling - we may only need the "completion 
of MIP signaling" event (such as a mobility route change in the MN, HA 
and/or other nodes) to trigger/notify NSIS signaling. Then the latter 
will be following the data path and deliver signaling services (thru 
various NSLP messages) as needed.

...(snip)
> Not crystally clear about what you mean in this senstence, appreciate it

Meant "several nodes (such MN, HA and/or FA, possibly ARs in FMIP/CTP 
case) will have to change the routing entries for the data forwarding of 
flows sent to or received by the MN. As these events happen 
subsequently, one has to take care of a reasonable sequence of NSIS 
signaling process which will also go along these nodes." Some of such 
situations are discussed in issue 7 and section 4.1 of the I-D.

Best regards,
Xiaoming

---

From: "Charles Q. Shen" <[email-masked]>
Date: Thu, 10 Jul 2003 00:56:40 -0400

Xiaoming,

> > Not crystally clear about what you mean in this senstence, 
> appreciate 
> > it if you could elaborate.
> 

Ok, so you are talking about the Synchronization/out of sequence
problem. Usually it is solved by some kind of messages ID/sequence
number (e.g., in related routing protocol updates, RSVP refreshes, and
our RSVP-MIP test-bed). I am not very sure what is the difference
between the Branch ID you mentioned in your draft from the message ID
approach. 

Cheers/Charles

---

From: Xiaoming Fu <[email-masked]>
Date: Mon, 14 Jul 2003 09:30:37 +0200

> between the Branch ID you mentioned in your draft from the message ID
Yes, the following terms sound similar:
Epoch (RFC2961) ~ Session ID
Message ID (RFC2961) ~ Branch ID
However, they are not quite the same.

To my understanding, Message ID (together with Epoch) concerns with 
signaling messages between _peering neighbers_, where out-of-order 
problem can come from retransmission/refresh. (Correct me if I'm wrong).
While talking about Branch ID, I meant it (together Session ID) can be 
used for avoiding syncronization of signaling messages along different 
branches (each can consist of multiple hops). This can be generally 
useful for determining end of (explicit) teardown message to forward on 
along the common path.

Thanks,
Xiaoming

---

From: "Charles Q. Shen" <[email-masked]>
Date: Wed, 16 Jul 2003 13:11:03 -0400

Xiaoming, comments followed.

> Xiaoming Fu wrote:
> problem can come from retransmission/refresh. (Correct me if 
> I'm wrong). While talking about Branch ID, I meant it 
> (together Session ID) can be 

My understanding is: a Message ID/Sequence Number approach can be used
to detect out of order messages (carrying refresh information either QoS
or mobility related). Whether it is of hop-by-hop (_peering neighbers_)
significance or end-to-end significance depends on how it is used. We
used Sequence Number in Mobility Update objects in our RSVP-MIP
framework, which I guess might be similar to the branch ID you
mentioned.

Thanks and regards,

Charles