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

From: [email-masked]
Date: Mon, 14 Jul 2003 22:03:12 +0300

Hi Xiaoming,

I think it is premature to do this at the moment - the framework
document & the analysis document cover some mobility issues - 
you should contact the author of those doucments to see what
overlap, if any, there is between your proposal and those
documents.

John

> -----Original Message-----
> From: ext Xiaoming Fu [mailto:[email-masked]]
> Sent: 14 July, 2003 21:14
> To: [email-masked]
> Subject: [NSIS] mobility-related requirements from nsis-req-08
> 
> 
> Hi all,
> 
> As John suggested, I tried to sort out requirements (out of 
> nsis-req-08) 
> which are related to mobility and hope they helpful for 
> related discussions:
> 
>     5.2 Signaling 
> Flows...............................................10
>     5.2.2 NSIS MUST support path-coupled and MAY support 
> path-decoupled
>     
> signaling.........................................................11
> ==>  relates to different handling of MIP IP-in-IP 
> encapsulation (tunnel).
> 
>     5.3 
> Messaging.....................................................11
>     5.3.1 Explicit erasure of state MUST be 
> possible..................12
> ==> related to explicit teardown of obsoleted branch. Maybe a flag to 
> indicate whether to do explicit teardown.
> 
>     5.4 Control 
> Information...........................................13
>     5.4.3 State MUST be addressed independent of flow 
> identification..14
> ==> mobility support may make use of this requirement.
> 
>     5.5 
> Performance...................................................15
>     5.5.1 
> Scalability.................................................15
> ==> NSIS "MUST be scalable in number of hand-offs in mobile 
> environments." This can be related to, e.g., capability of 
> dealing with 
> pingpong, fast movement.
> 
>     5.6 
> Flexibility...................................................16
>     5.6.2 Flexibility in the placement of the NSIS 
> Initiator/Responder16
> ==> somehow related to the issue of either MN or CN as data sender.
> 
>     5.8 
> Mobility......................................................19
>     5.8.1 Allow efficient service re-establishment after 
> handover.....19
> ==> effectively establish states in new path due to handover.
> 
>     5.9 Interworking with other protocols and 
> techniques..............19
>     5.9.1 MUST interwork with IP 
> tunneling............................19
> ==> IP-in-IP encapsulation is one type of IP tunnels
> 
>     5.9.2 MUST NOT constrain either to IPv4 or 
> IPv6...................19
> ==> should be able to work with both Mobile IPv4 protocols and Mobile 
> IPv6 protocols.
> 
>     5.9.5 SHOULD work with seamless handoff 
> protocols.................20
> ==> e.g., CTP
> 
> Cheers,
> 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, 14 Jul 2003 22:18:15 +0200

John,

> document & the analysis document cover some mobility issues -
Yes, I was following your suggestion to complete my comments from these 
requirements' point of view which can help later mobility discussions, :-)

> overlap, if any, there is between your proposal and those

I looked into these docs before submitting the I-D: they did cover 
general state management (e.g., session ID) and local repair issues; 
I'll talk with the authors on latest versions and their plans.

Thanks,
Xiaoming

---

From: "Charles Q. Shen" <[email-masked]>
Date: Wed, 16 Jul 2003 15:12:43 -0400

John, 

You are certainly right that it is pre-mature to make any conclusive
arguments about NSIS-mobility details at this time. However, since the
framework document is approaching its completion, while work from
RSVP-mobility to NSIS-mobility is probably still in its early phase, I
do not feel you can fit everything into the framework/requirement
document. 

My personal view is: aside from puting matured framework level mobility
issues into the framework document, keeping a separate disscussion
regarding ongoing NSIS-mobility details would be beneficial. 

Regards,

Charles

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Monday, July 14, 2003 3:03 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [NSIS] mobility-related requirements from nsis-req-08
> 
> 
> Hi Xiaoming,
> 
> I think it is premature to do this at the moment - the 
> framework document & the analysis document cover some 
> mobility issues - 
> overlap, if any, there is between your proposal and those documents.
> 
> John
>

---

From: Paulo Mendes <[email-masked]>
Date: Thu, 17 Jul 2003 10:28:33 +0200

>regarding ongoing NSIS-mobility details would be beneficial. 
I agree with Charles's opinion. Some discussion is needed to reflect on 
some issues already mentioned in the Framework, but that need a more 
detailed analysis, such as seamless handover support for mobile 
real-time data transmission.

Cheers,
Paulo

>>>==> related to explicit teardown of obsoleted branch. Maybe 
>>>      
>>>
>>a flag to 
>>    
>>
>>>==> should be able to work with both Mobile IPv4 protocols 
>>>      
>>>
>>and Mobile 
>>    
>>
>>>IPv6 protocols.
>>>

---

From: Marcus Brunner <[email-masked]>
Date: Thu, 17 Jul 2003 11:27:14 +0200

Paulo,

Sure, go ahead with discussions based on what stands in the framework. I 
think Robert would be glad to get some input on mobility aspects.

Marcus

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 17 Jul 2003 13:41:12 +0000 (GMT)

> think Robert would be glad to get some input on mobility aspects.

Yes please, and do it sooooooon (and/or catch me this week).

Actually, there was a more detailed discussion of some of the issues
you mention in the -00/-01 versions (i can provide them if you don't
have access). We took it out, partly because it seemed that no-one
apart from the author was interested in the subject.

A tiny summary of the proposed way forwards for those who are
interested (in fact, the following - along with a potted summary
of the overall analysis - might be the basis of the eventual
framework content, with all the detail moved to another document):

The framework layer split concept is that the NTLP works in terms
of packet streams ("flows") which are identifiable by nodes inside
the network. This is reflected practically in the fact that the
NTLP universe revolves around "flow-ids" (3/5 tuple etc. - see other
emails). The NTLP knows how to route (and re-route) signalling
messages along the path corresponding to a flow ID, but it
doesn't know anything about any relationships between different
flows (i.e. with different flow IDs).

An IP-visible mobility event (MIP/SIP/HIP/...) results intrinsically
in a new flow ID and also an update of the packet classifiers and
so on. The NTLP doesn't know how the new flow relates to the old;
NSIS-aware nodes which see both flows handle the interactions
between them at the signalling application level (i.e. in the NSLP).
Essentially, the same reasoning applies to the multihoming case, i.e.
it's an NSLP issue.

The NTLP has a greater proportion of the responsibility for
simple re-routing events (actually, the same responsibility, but
the re-routing problem is much simpler for several reasons). Those
people interested in the general problem of seamless handover
support would first have to consider whether that is done by
re-routing (i.e. there are updated host routes in the network)
or by changing IP address. That's a nice subject.

cheers,

robert h.

---

From: Paulo Mendes <[email-masked]>
Date: Mon, 21 Jul 2003 15:37:12 +0200

Hi Robert,

Below, I wrote  some comments about the framework doc.

>apart from the author was interested in the subject.
I'm interested in reading these two previous versions, and I do not have 
access to them :).

>framework content, with all the detail moved to another document):
I also agree with this division, as I already mentioned before: a 
complete description of the problems and possible solutions is too dense 
for the framework doc.

>flows (i.e. with different flow IDs).
The need for a session ID is already understood as a basic need for 
NTLP.  How can such session ID give support to other issues besides the 
discovery of the cross router, is another matter. For instance, should 
the session ID be tight related with the IP address of the old access 
router? The importance of this issue can depend on the way the protocol 
operates, namely if the release of resources in the old-path is done 
from the cross router or from the old access network.

>Essentially, the same reasoning applies to the multihoming case, i.e.
Besides the session ID, the need for an implementation-neutral way of 
dealing with encapsulation is of major importance. This is already 
mentioned in the -03 version of the framework.

>or by changing IP address. That's a nice subject.
The subject of seamless handover is of great importance, because in a 
mobile environment a signaling protocol should avoid the disruptions of 
the quality level of multimedia sessions during or after a handover. As 
mentioned in the framework (section 5.2) "The main issues for a resource 
signaling application are limiting the period after handovers during 
which the resources are not available along the path". Hence, in what 
concerns resource signaling, the quality level of a mobile session 
depends on two main factors:
a) the capacity of the new access network
b) the capacity of the new e2e path

These two issues are of importance since the time available to setup 
resources in the new path are constrained by the time available for the 
handover.
The problem of the capacity of the new access network is somehow 
mentioned in the framework, where in section 5.2.5, it is referred the 
work being done on the Seamoby WG.  It is referred how NSIS can trigger 
context transfer and how NSIS can be used to transport such context 
information. However, there is no reference about the influence that 
CARD or other discovery protocols can have in the operation of NSIS. For 
instance, should/must NSIS be triggered by route advertisements of a 
mobile protocol such as MIP, or should/must NSIS wait for the 
information about the best access network provided by a CARD-like protocol?

Even if the best access network can be provided by a CARD-like protocol, 
there is no insurance that the new e2e path can support the quality 
level required by the session. As said in section 5.1.2 "It is not 
guaranteed that the new path will be able to provide the same 
characteristics that were available on the old path".
On the one hand, if NSIS tries to setup the new path but the minimum 
quality level required by the session is not support, the session is 
disrupted. On the other hand, if the minimum quality level is support, 
but not the desired quality level, some re-negotiation process is 
required, which can take longer time than the time available for the 
handover. In this case, the seamless desired characteristic of the 
handover can not be accomplish.
Therefore, to enhance the support that NSIS can give to seamless 
handovers, it should be mentioned on point 5.2.5 the need to understand 
the relationship between NSIS and some kind of policy-based routing to 
avoid the dependency upon the capacity of the new shortest-e2e path. 
Since section 6.1.3 already mention that any QoS-NSLP has to be able to 
handle QoS-aware  routing, only a pointer to 6.1.3 is needed in section 
5.2.5.

In what concerns section 6.1.3, two approaches are mentioned to make BGP 
QoS-aware. However, from the Router Area Meeting that happened in 
Vienna, it seems that there is no consensus about continuing to extend 
BGP or to use a new protocol to provide the extra required routing 
functionalities. Hence, section 6.1.3 should also consider other future 
options, such as the use of other protocol to signal "QoS-reachability" 
to BGP routers. Probably NSIS can be a candidate for this job, similar 
to the transport of context information between access networks, as 
mentioned in section 5.2.5. To avoid some of the BGP problems, namely 
the convergence time, probably this use of NSIS can be more efficient if 
done decoupled from the data path.

Cheers,
Paulo

>--
>Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell,
>Berkshire. RG12 8FZ
>
>The information contained in this e-mail and any attachments is confidential to
>Roke Manor Research Ltd and must not be passed to any third party without
>permission. This communication is for information only and shall not create or
>change any contractual relationship.
>
>  
>

-- 
Paulo Mendes
DoCoMo Communications Laboratories Europe GmbH
Landsberger Str. 312
80687 Munich, Germany
Tel. +49-89-56824-226
Fax. +49-89-56824-300
E-mail: [email-masked]
http://www.docomoeurolabs.de/

---

From: Xiaoming Fu <[email-masked]>
Date: Thu, 24 Jul 2003 20:25:11 +0200

Hi,

> flows (i.e. with different flow IDs).

Local repair/re-routing + host addressing (routing header and Home 
Address option) might be insufficient. Consider an example: an MN just 
moves from an foreign network to another, than non-route-optimized MIP 
may change a binding entry in the HA at the (mobile) IP level, and the 
common path (before and after a handoff) ends somewhere between the HA 
and MN. In this case, the NTLP instances in routers locating between the 
HA and the Crossover Router (CR) will be unable to route the NSIS 
signaling message according to universal flow-ids, without introducing 
new NTLP functionalities/objects.

IMO mobility is more than an NSLP issue; it also involves with NTLP. One 
possible way is to distinguish NTLP instances by session ID, but let 
NSIS messages routed according to some object in NTLP independent of 
flow-id and allow NTLP instances be aware of mobility-caused route 
changes also in the middle of the network (not only route changes for 
hosts). Of course, NSLP needs certain neat work to reflect a signaled 
flow' traffic selector.

Cheers,
Xiaoming

---

From: "Charles Q. Shen" <[email-masked]>
Date: Thu, 24 Jul 2003 21:42:27 -0400

Hi all, 

We have had a long debate on whether reliable transport (if applicable)
should reside in NSLP or NTLP. It seems here comes another topic: should
mobility-awareness be built in NSLP only or also in NTLP? I noticed that
Robert and John have explicited said it should be an NSLP issue only.
This sparks my curiousity to ask: "Is it already a WG consensus or is it
true that many people still haven't got time to think about it?" 

IMHO it would be good to make it an NSLP issue only, if possible.
However, I would like to see more proof as details being worked out.
(Although it might still be arguable how detail about NSIS-mobility we
should get into at this time).

Xiaoming, frankly I do not completely understand your example yet. Does
Robert mean that the flow-id (which very likely contains IP addresses)
will change after the handoff (and the presumed session ID will be
retained)? 

Thanks and regards,

Charles

> 
> Hancock, Robert wrote:
> > 
> > The framework layer split concept is that the NTLP works in 
> terms of 
> > packet streams ("flows") which are identifiable by nodes inside the 
> > network. This is reflected practically in the fact that the NTLP 
> > universe revolves around "flow-ids" (3/5 tuple etc. - see other 
> > messages along the path corresponding to a flow ID, but it doesn't 
> > know anything about any relationships between different flows (i.e. 
> > with different flow IDs).
>

---

From: Paulo Mendes <[email-masked]>
Date: Fri, 25 Jul 2003 09:34:40 +0200

Hi Xiaoming,

Some comments below.

Xiaoming Fu wrote:

> and MN. In this case, the NTLP instances in routers locating between 
> the HA and the Crossover Router (CR) will be unable to route the NSIS 

What do you mean by "universal" flow-ids?

> IMO mobility is more than an NSLP issue; it also involves with NTLP. 
> One possible way is to distinguish NTLP instances by session ID, but 
> let NSIS messages routed according to some object in NTLP independent 
> of flow-id and allow NTLP instances be aware of mobility-caused route 

It is clear to me that we need a session-ID in the case of mobility. But 
it is not clear to me what is the goal in "distinguishing" NTLP 
instances by session ID. If you mean the need to map the session-ID of a 
mobile session with the different flows-ID that the session can have 
before and after handover, I agree with you. However, I do not 
understand what you want to say with "NSIS messages routed according to 
some object in NTLP independent of flow-id". Are you suggesting that 
NSIS messages should be routed/transported based on something else than 
the flow-id?

Cheers
Paulo

---

From: Xiaoming Fu <[email-masked]>
Date: Fri, 25 Jul 2003 09:56:35 +0200

Hi Paulo,

> What do you mean by "universal" flow-ids?

I was following what Robert used in his context. :)
> NSIS messages should be routed/transported based on something else than 

This issue has been explored in various ways (e.g., in fw draft and 
maillist discussions). Session-ID can be useful, in my point of view, to 
distinguish from other sessions (note they may even have same NI/NR 
pair), and to determine the CR and avoid double reservations. My point 
was: even if one can have a universe flow-id, routing of NSIS messages 
is not as simple as expected. In the HA, for example, you can route NSIS 
messages towards the MN following the same rules as in MIP; for the 
nodes after HA, however, you have no knowledge of changes in MIP - how 
can you route them per flow-id?

Cheers,
Xiaoming

---

From: Paulo Mendes <[email-masked]>
Date: Fri, 25 Jul 2003 10:06:10 +0200

Hi Charles,

Charles Q. Shen wrote:

>should reside in NSLP or NTLP. 
>
Reliable transport in a session protocol, instead of a transport protocol?!!

>It seems here comes another topic: should
I think that avoiding redundant functionalities is a good goal. Having 
this in mind,
I think that only makes sense to include within NTLP functionalities 
that are common
to different NSLPs.
In the specific case of mobile session IDs, as said in the framework 
draft, it is desirable
to update the flow:session mapping during the session lifetime. If this 
mapping
is only needed to manage resources of mobile sessions, then it makes 
sense to be the
QoS-NSLP protocol to keep the mapping info. If this mapping is required 
by other NSLPs,
the state should be kept by the NTLP: Henning's NTLP proposal already 
mention a forwarding
state table that includes the session-ID and the destination address.

>will change after the handoff (and the presumed session ID will be
In the framework draft you can read  "A flow is defined by a packet 
classifier
(in the simplest cases, just the destination address and topological 
origin are needed).
In general we assume that when discussing only the data flow path, we 
only need
to consider 'simple' fixed classifiers (e.g. IPv4 5-tuple or equivalent)."
Hence, this clarify that a flow-ID contains IP addresses, and so the 
flow-ID changes
when the care-of address of the mobile device changes.
In what concerns the session-ID, it must *not* change due to a handover: 
only this
way the cross router can be found, the state related to the flow in the 
old path (old flow-ID)
can be released, and resources in the common path (from correspondent 
node to cross router)
can be used more efficiently.

Robert, this lead me to a comment to the QoS-NSLP draft, where section 
4.3 pays some attention to
the need of using session-ID to allow resources to be shared over the 
network region where
different flows of a mobile session share the path. But, this section is 
lacking some reference
to the need of a session-ID to identify the cross router and to release 
resources in the old path.

Cheers,
Paulo

---

From: "Charles Q. Shen" <[email-masked]>
Date: Fri, 25 Jul 2003 04:14:35 -0400

Xiaoming,

> I was following what Robert used in his context. :)

But as I understand, in Robert's context, the flow-id is the one that
could change due to change of IP addresses, and Session ID is not. So
why universal flow-ID?

Snip ..
> can you route them per flow-id?

Again I am a bit confused about the notion of universe flow-id and the
(supposed to be unique) session ID here. Also are you talking about
tunneling?

Best regards,

Charles

---

From: "Charles Q. Shen" <[email-masked]>
Date: Fri, 25 Jul 2003 04:46:17 -0400

Hi Paulo, comments inline.

> Reliable transport in a session protocol, instead of a 

I was referring specifically to the comments such as " [Robert] However,
even if we agree that a signalling application
needing reliability needs it between (say) adjacent NSLP peers rather
than simply end-to-end, there is still the 
question of which layer it should be provided at (NTLP or within each
application)." But I have no intention to create more debate on this
topic :)

> >mobility-awareness be built in NSLP only or also in NTLP? I noticed 
> >that Robert and John have explicited said it should be an NSLP issue 
> >only. This sparks my curiousity to ask: "Is it already a WG 
> consensus 
> >or is it true that many people still haven't got time to think about 
> >it?"
> >

I think Robert's opinion (from his comments dated 7/17/03) is to let
NTLP handle "re-routing" only while the association of n flow-id to
possibly one session id is left to NSLP. The question is then "is this
association a common function to different NSLPs?" If it is, then it
seems make sense to me to consider puting it into NTLP as well. Another
comment is, maybe we should call the topic "the association of flow-id
with session-id", instead of "mobility", before the former covers more
than mobility, (eg. Multi-homing?). 

> to consider 'simple' fixed classifiers (e.g. IPv4 5-tuple or 
> equivalent)." Hence, this clarify that a flow-ID contains IP 
> addresses, and so the 
> flow-ID changes

Thanks. I apologize. I should have used "Doesn't" instead of "Does"
because that is also my understanding.

> resources in the old path.

As one possible reference, we tested and proved the concept in our
RSVP-MIP test-bed 
http://www.cs.columbia.edu/~charles/publication/draft-shen-nsis-rsvp-mob
ileipv6-00.txt

Regards,

Charles

---

From: Xiaoming Fu <[email-masked]>
Date: Fri, 25 Jul 2003 12:19:03 +0200

Charles,

> (supposed to be unique) session ID here. 
I think Robert's concept on *universe* flow-id doesn't need to be 
unchanged during a session; if I understand correctly, he only meant 
"universe" for signaling session at one time.

> Also are you talking about tunneling?

So far in this thread, not yet. However, in my view, IP-in-IP tunneling 
is an important issue for NSIS-mobility to work out. Re-routing and 
local repair issues in the data path changed by mobile IP may introduce 
problems other than (routing header + destination option in case of 
MIPv6) - imagine what if a message is encapulated into tunneled :-); 
reverse tunneling could be more complicated. My ideal model is that NTLP 
should be aware of any tunnel entry and exits, and route NSIS message 
when entering and inside a tunnel differently from the case outside the 
tunnel.

Cheers,
Xiaoming