Subject: [NSIS] Feedback from the "mobility in NSIS" meeting

From: Jukka MJ Manner <[email-masked]>
Date: Mon, 10 Nov 2003 16:53:03 +0200 (EET)

Dear all,

Here a list of issues that I collected from the various NSIS+mobility
drafts, and which we agreed on during our meeting on Sunday evening.
There were roughly ten people present.

This list IS NOT
  a) an extensive list of all issues,
  b) a table of contents for a future working group draft, 
  c) a proposal for a new protocol to be designed and/or to compete with
     the NSIS NTLP/NSLP work, and 
  d) a proposal to split the work done in NSIS into some basic functions
     and mobility-specific functions.

The list MAY be used to write a draft that 

 a) analysis the implications of mobility/routing/multihoming (MoRoMu) on the
    work within NSIS,
 b) gives guidelines on how to include support for the MoRoMu issues into
    NTLP/NSLPs,
 c) helps in deciding how functions should be split between NTLP and NSLPs,
 d) documents the current understanding of the interactions of mobility and
    resource signaling, and
 e) gives guidelines for designers of new NSLP protocols.

Now that the background for the list is made clear (?), here is the
list. This could be used as a list of items to discuss during the
timeslot on Thursday. The people present during the Sunday evening
meeting agreed to meet Wednesday morning at 8.30 AM around the
registration desk and see what have been the comments on the NSIS
mailing list and what should be done for the Thursday NSIS meeting.

Regards,
Jukka

--------------------------------------------------------------------------------

Basic Issues
------------

- Differences between the general route change (not related to mobility)
  and mobility-caused route change, when
  a) when IP addresses change (end host or next peer)
  b) when IP addresses do not change

- How to discover crossover router, when
  a) the cross-over router exists by the definition in RSVP, that is, the same 
     session is identified on a new interface
  b) the cross-over router does not exist in the previous way, that is, new 
     messages for an existing session arrive from a new peer through the old 
     interface
  c) other nodes than the cross-over router affect the signaling
(The cross-over router discovery is most important when the mobile node is receiver)

- How to set up states on the new path and teardown old states on the obsolete
  path? When is the "old" path not needed?

- State update on the common path after handover

- Interactions with mobility protocols such as MIP and LMM protocols

- Interactions with CT and CARD, e.g. 
  a) to perform a make-before-break handover with resource set up
  b) to query (not reserve) for resources on a possible new path from a CAR

- Dependencies between the NTLP and NSLP and split of functionality between 
  layers

- Security issues: implications of the authorization model

- Dead peer and dead cross-over router discovery

Not in the initial scope aka. "Grey area"
-----------------------------------------

- Refresh timer decisions hop-by-hop? Are these any different from
  individual "ordinary" hop-by-hop timers?

- Issues with mobility protocols using tunneling? Is this any different from 
  "common" tunneling elsewhere in the network?

- Multicast: (single) source-specific with homogeneous receivers? Is
  this so much different from multi-homing support?

- Optimized support for specific topologies, e.g. symmetric routes and
  bi-directional reservations?

- Support for mobile networks? This sounds like a specific optimization?

- Session modifications caused by changes in the network, e.g.
  pre-emptive QoS allocation, re-routing leading to charging issues?

Out of scope of this work
-------------------------

- Specific implementation details (generic guidelines for making
  something work would be in scope)

- Mobility (routing) management

- Handover management (NTLP/NSLP state management in scope)

- Evaluating the movement of end hosts and finding candidate access
  routers/access points

- Multicast without limits (this is why RSVP is so complex)

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

---

From: Marcus Brunner <[email-masked]>
Date: Mon, 10 Nov 2003 21:49:28 -0600

> Basic Issues

So what is the difference?

> - How to discover crossover router, when

First question: what do you need the crossover router for? What 
functionality is special on the crossover router?

>   a) the cross-over router exists by the definition in RSVP, that is, the
> same       session is identified on a new interface
>   b) the cross-over router does not exist in the previous way, that is,
> new       messages for an existing session arrive from a new peer through
> the old       interface

I would assume this is NSLP dependent

> - Interactions with mobility protocols such as MIP and LMM protocols

IMHO there is no interworking needed with MIP except that MIP might want to 
use NSIS.

[...]

> - Dependencies between the NTLP and NSLP and split of functionality
> between    layers
>

Can you an example where the split might be different when looking into 
mobile versus static networks.

> - Security issues: implications of the authorization model

What is different in the mobility case.

> - Dead peer and dead cross-over router discovery

again why do you need to discover these? I assume peer maintance is part of 
the NTLP anyway.

Marcus

--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
Phone: +49 (0) 6221 905 11 29
Mobile: +49 (0) 163 275 17 43
personal home page: http://www.brubers.org/marcus

---

From: "Charles Q. Shen" <[email-masked]>
Date: Tue, 11 Nov 2003 00:47:58 -0500

Hi Marcus, a few brief comments inline (marked with [cs]):

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Marcus Brunner
> Sent: Monday, November 10, 2003 10:49 PM
> To: [email-masked]
> Subject: Re: [NSIS] Feedback from the "mobility in NSIS" meeting
> 
> 
> 
> > Basic Issues
> > ------------
> >

[cs] My understanding of the difference is:
1) the different causes of route change (eg. routing adaptation or
mobility) 
2) whether IP address change is associated with the route change or not
 
> functionality is special on the crossover router?

[cs] IMHO crossover router may at least help in optimizing the handling
of route change events, e.g. certain local repair messages may initiate
from or terminate at crossover routers.

> >   c) other nodes than the cross-over router affect the 
> signaling (The 
> > cross-over router discovery is most important when the 
> mobile node is 
> > receiver)
> >

[cs] It could be helpful to define cross-over router as NSLP dependent.
(instead of a pure topology-wise cross-over router)

> IMHO there is no interworking needed with MIP except that MIP 

[cs] I suppose it is still a good idea to analyze the scenarios of
MIP-NSIS working together, at least to ensure "
NSIS won't break in the presence of mobility". 

> mobile versus static networks.

[cs] IMHO this is one potential area we might want to examine further. 

Thanks and regards,

Charles

---

From: Jukka MJ Manner <[email-masked]>
Date: Tue, 11 Nov 2003 16:16:08 +0200 (EET)

Hi Marcus, replies inline.

Jukka

> So what is the difference?

[JM] Nothing, if you do things right, e.g. the session states are not 
identified with IP addresses (as in RSVP), but a generic ID as seems to be 
the case in the NTLP and NSLP design already.

> functionality is special on the crossover router?

[JM] Read the line in paranthesis... when you are the receiver and you 
move, the new path starts at the cross-over router. This is where the 
local repair starts.

> I would assume this is NSLP dependent

[JM] May be, may be not... don't know the clear answer, yet

> IMHO there is no interworking needed with MIP except that MIP might want to 

[JM] To me NSIS and MIPv6 and Fast Handovers have something in common, as 
CARD and CT have. Also, how would MIPv4 work with NSIS with CoAs and 
CCoAs, tunneling, and possible triangular routing. What if CN and MN are 
actually in the same network? Any changes to make things more efficient 
aka. optimize? (yes, I know, someone will soon tell not to focus on 
optimizations at this stage... but it might we worthwhile to at least 
document some 
ideas?)

> mobile versus static networks.

[JM] No, not yet. Probably some issues related to who triggers who and
when and why and what messages are then send, when a mobility event occurs
and states need to be managed.

> What is different in the mobility case.

[JM] A more dynamic environment, not all peers remain, who is who, who is 
the signaling initiator?

> again why do you need to discover these? I assume peer maintance is part of 

[JM] Already answered to the cross-over router issue, discovery of dead
peers is also related to mobility and path changes.

---

From: Xiaoming Fu <[email-masked]>
Date: Tue, 11 Nov 2003 15:24:19 +0100

Hi,

A few comments inline:

> 2) whether IP address change is associated with the route change or not

Note there are some topology change cases, even with mobility, the IP 
address does not change. For example, in HMIP, it is possible the source 
address of a packet sent from the MN to the CN can be RCoA, even its 
LCoA is changed.

> (instead of a pure topology-wise cross-over router)
Basically, if one wants to refresh the NSLP state in the common path, 
for example from the cross-over router to the CN (for the upstreaming 
direction), there are two possibilities: either the cross-over router is 
NSLP aware, and let its NSLP to refresh along the path; or let NTLP to 
refresh along the path, while triggering associated NSLP(s) in each NSIS 
hop while the NTLP refresh. However, the implication needs to be further 
studied. One issue concern with the first way is possible multiple 
NSLPs, then it may need several times of NSLP refresh upon a mobility 
event; the second way needs a clear NTLP/NSLP interface.

Cheers,
Xiaoming

---

From: Xiaoming Fu <[email-masked]>
Date: Tue, 11 Nov 2003 15:47:48 +0100

Hi Jukka,

Great we have something going on. Nice work!

These issues IMO is quite well summarized in the list (actually most, if 
not all, issues we've discussed in various ocassions: NSIS-list, I-Ds, 
etc.:-); it is now a good time for the WG to decide whether/how to have 
a working group document on these issues), and I do think this list 
would be helpful for studying the implications of mobility on the work 
within NSIS. Can you tell how mobility matters from normal handling of 
general routing/multihoming elsewhere in the sense of NSIS?

Cheers,
Xiaoming

---

From: "Seong-Ho Jeong" <[email-masked]>
Date: Wed, 12 Nov 2003 04:18:08 +0900

Hi Marcus, 

A few more comments inline [SHJ]

Regards,
Seong-Ho

----- Original Message ----- 
From: "Jukka MJ Manner" <[email-masked]>
To: "Marcus Brunner" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, November 11, 2003 11:16 PM
Subject: Re: [NSIS] Feedback from the "mobility in NSIS" meeting

> the case in the NTLP and NSLP design already.

[SHJ]One of the main reasons why we included the differences in the list is the fact 
that the mobility-caused route change may have some impact on the flow identifier (although
it may be possible that the flow identifier does not change in the micro-mobility case). 
The change in the flow identifier may cause state update.

> move, the new path starts at the cross-over router. This is where the 

[SHJ]To minimze the impact of mobility-caused route change, it is desired
to limit the state re-establishment and old state removal to the affected path segment. 
In this case, the crossover router is an appropriate node to initiate this local path repair. 
This is particularly important when the mobile node acts as a receiver to avoid 
a long delay for state re-establishment.

> [JM] May be, may be not... don't know the clear answer, yet

[SHJ] IMHO,  it may be NSLP dependent, but there could be NTLP states involved. 
I think iIt depends on  how to define states in the NTLP and NSLP.

> peers is also related to mobility and path changes.

[SHJ] This will be particularly important when one of the peers is the crossover router
because the crossover router is one of the key components in state re-establishment and
old state removal. If the crossover router is found to be dead for some reason before 
the state re-establishment and old state removal, a new crossover router should be 
discovered in a fast manner.
>	ìŠÉšŠX§‚X¬¶{"²'~Šà†Ûi³ÿðÃ
bz×è®æj)fjåŠËbú?žÈ¬

---

From: Marcus Brunner <[email-masked]>
Date: Tue, 11 Nov 2003 13:20:53 -0600

> it is now a good time for the WG to decide whether/how to have a
> working group document on these issues), and I do think this list would
> be helpful for studying the implications of mobility on the work within
> NSIS.

I think it is far to early to talk about mobility (even when interesting 
from a research point of view.) Let's first get the work on the table done. 
I do not have problem when the directions of NTLP and NSLPs are carefully 
reviewed checking the impact on mobility. And I think John already 
mentioned mobility is not part of the charter.

Marcus

---

From: "Charles Q. Shen" <[email-masked]>
Date: Tue, 11 Nov 2003 14:23:21 -0500

Xiaoming,

> address of a packet sent from the MN to the CN can be RCoA, even its 

That's correct. I did not mean one case in point (1) is tied with one
specific case in point (2). These two points should be examined in
parallel. 

Regards,

Charles

---

From: Jukka MJ Manner <[email-masked]>
Date: Tue, 11 Nov 2003 21:46:46 +0200 (EET)

Marcus,

A snapshop from the NSIS charter:

"The work produced in this Working Group should work with existing IETF
mobility and AAA protocols, including (but not limited to) Mobile IP,
SeaMoby Context Transfer, etc."

Now, it depends on the definition of "should work", whether if meant that 
"it should ,but it is not a problem if it doesn't" or rather "SHOULD 
work" as defined in RFC2119:

"3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course."

Thus, unless you have some clear and good reasons to disregard mobility,
the charter RECOMMENDS to work on those issues, too. You seem to be the
only one that argues against doing this type of work... as Robert already
mentioned, this most probably will not bring out any major issues compared
to the wired network operation.

Regards,
Jukka