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

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 28 Jul 2003 16:27:28 +0100

hi xiaoming,

more clarifications (I hope):

> I followed up your previous mail regarding universe flow id 
> because this 
> is also (for both you and I) meant how to route the NSIS messages. 
> Actually, in a previous version of fw draft it stated either way of 
> using flow-id:
>      *) Use a flow identification based on low level IP 
> addresses (e.g.
>     the Care of Address) and other 'standard' fields in the IP header.
>     This makes least demands on the packet classification 
> engines within
>     the network. However, it means that even on a part of the 
> flow path
>     which is unchanged, the reservation will need to be modified to
>     reflect the changed flow identification (see section 5.3.3).
> 
>      *) Use a flow identification that does not change (e.g. based on
>     Home Address); this is the approach assumed in [23]. This 
> simplifies
>     the problem of reservation update, at the likely cost of 
> considerably
>     complicating the flow identification requirements.

[reh] and what we are assuming is the first approach and not the
second.

> 
> This can also answer some discussions. My worry, however, is that 
> flow-id might be insufficient to address the NSIS messages in 
> mobility 
> scenarios, not talking about the mobility-coupled issue; I 
> was trying to 
> discuss in the context of decoupling NSIS signaling from MIP 
> signaling.
> 
> Hancock, Robert wrote:
> > *) I'm not really sure what Xiaoming is suggesting in terms 
> of routing
> > NSLP messages *other* than on flow-id. The flow-id is essentially
> > defined as 'the thing which characterises the data path', so routing
> > on anything else is morally equivalent to off-path signalling. 
> 
> At least I can tell, if we use some on-path LMM schemes (e.g., fast 
> handover, HMIP), this flow-id could be insufficient to route NSIS 
> messages. In such cases, data path in the new segment(s) may not be 
> fully characterized by the flow-id (3/5 tuple?).

[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.]

r.

> Cheers,
> Xiaoming

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

---

From: "Charles Q. Shen" <[email-masked]>
Date: Wed, 30 Jul 2003 14:22:45 -0400

Hi Robert, a few comments.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Hancock, Robert
> Sent: Monday, July 28, 2003 11:27 AM
> To: 'Xiaoming Fu'
> Cc: 'Charles Q. Shen'; 'Paulo Mendes'; [email-masked]
> Subject: RE: [NSIS] mobility-related requirements from nsis-req-08
> 
> 
> hi xiaoming,
> 
> > I followed up your previous mail regarding universe flow id because 
> > this is also (for both you and I) meant how to route the NSIS 
> > messages. Actually, in a previous version of fw draft it stated 
> > either way of using flow-id:
> [reh] and what we are assuming is the first approach and not
> the second.
> 

Since the second approach seems to be referring to our RSVP-MIP draft, I
would like to make a slight clarification. The key point in that draft
is the necessity to keep a unique Identifier (which I called Flow
Identifer back then) during mobility, so that handoff signaling overhead
may be minimized. Using Home Address is one possibily to achieve that.
But the draft also mentioned other possibilities, such as using IPv6
flow label. 

A breif summary of my understanding so far is: 

1. The identifier that should not change during mobilily (if there is
one) is called the Session Identifier, while its detailed structure is
still open. 
2. The flow identifier is the low level identifier that is used to
acutally route the packet at the NTLP level, its structure could contain
IP 5-tuple, IPv6 flow label, or related IP fields. 
3. The association of the two (layer split functionality, etc.) is still
open.

I think the framework draft already contains very good descriptions of
the two IDs, but it would be helpful to document explicitly what are
still open issues, either in that draft or somewhere else. 

Thanks and regards,

Charles