RE: [NSIS] RE: nsis mobility interactions

Hi Robert:

See below as [HMC]:

-----Original Message-----
From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk]
Sent: Tuesday, October 29, 2002 6:04 PM
To: Chaskar Hemant (NRC/Boston); nsis@ietf.org
Subject: RE: [NSIS] RE: nsis mobility interactions

hi hemant,

see below:

> -----Original Message-----
> From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com]
> Sent: 29 October 2002 21:07
> To: Hancock, Robert; nsis@ietf.org
> Subject: RE: [NSIS] RE: nsis mobility interactions
> 
> 
> Hi:
> 
> The "draft-ietf-ipv6-flow-label-03.txt" recommends 
> classification based on triplet (src adr, dest adr, flow 
> label). We should not deviate from it unless it is essential.

[reh] Broadly, I like the current flow label draft, having read it several times. However, I think it's specifically about the flow label scope issues, rather than trying to restrict possible flow classifiers. (Would we ban classifiers that included the DSCP, for example?) I'm certainly not in favour of using lots of higher layer fields, and I'd personally be happy for NSIS to restrict itself in this area.

> 
> Also, what are those interesting implications on host 
> implementations that you were referring to?

[reh] This is based on conversations I have had with people who have implementation experience with MIP and RSVP. As I understand it (and I pre-emptively claim simple ignorance as a defence if I have got it wrong), an assumption that underlies several RSVP implementations is that the application on the host conveys its opinion on the packet classifier to some user space RSVP daemon which then uses them directly in RSVP protocol messages. (draft-shen-rsvp-mobileipv6-interop-00.txt described precisely this behaviour.) The filter spec in these messages then doesn't match MIP-processed packets.

So, what is needed instead is for the RSVP daemon to know *exactly* how user-space visible packets are going to be re-encapsulated as they go over virtual interfaces (MIP,IPsec,L2TP,...), which probably requires more knowledge of IP-layer internals than may be trivially available. 

[HMC] RSVP daemon has to be triggered when MN's point of attachment changes, in order to create reservations along the new path. The process that has the knowledge of change in point of attachment is Mobile IP (other than link layers of course). So, MIP process has to create trigger for RSVP daemon. In other words, in mobile environment, RSVP daemon cannot be receiving triggers only from applications, but has to receive them from IP stack as well. Hence, an API between IP and RSVP is needed anyway. What do you think?

The RSVP daemon can't just take the application's view of the flow identification, wrap it in some headers, and chuck it at the host IP stack.

OK, maybe it wasn't that interesting. But it seems worth keeping in mind. The framework alludes to these points (in 4.1 and 5.3.1, IIRC), but only briefly.

> 
> Hemant  

cheers,

robert h.

> 
> -----Original Message-----
> From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk]
> Sent: Sunday, October 27, 2002 6:35 PM
> To: PIECHOCINSKI, MACIEJ; nsis@ietf.org
> Subject: [NSIS] RE: nsis mobility interactions
> 
> 
> hi all,
> 
> i discussed these issues with Charles (Shen) at Yokohama. He 
> (& colleagues) have produced newer drafts:
> draft-shen-nsis-rsvp-mobileipv6-00.txt
> draft-shen-nsis-mobility-fw-00.txt
> which I think change some of the previous conclusions or at 
> least emphasis.
> 
> since this is now effectively a framework discussion, i can 
> recommend the second of these, as well as (I hope) section 
> 5.3 of draft-ietf-nsis-fw-00.txt.
> 
> with the momentum behind the discussion, i'd like to 
> highlight some of the more general questions:
> *) can we agree the assumption that flow identification 
> should be based on 'normal' header fields (i.e. not the HA 
> e.g. in HAO). Note: this has some interesting implications 
> for host implementations.
> *) is the HA a suitable value to use as the basis of a 
> reservation identifier (basically, does the way it gets 
> secured provide sufficient protection from the point of view 
> of devices which aren't the MN & CN)?
> *) should we restrict the scope of NSIS considerations to 
> MIP, or consider other mobility scenarios (e.g. SIP-based 
> mobility solutions, or stuff as in 
> draft-westberg-rmd-cellular-issues-01.txt) - where there 
> wouldn't be a constant HA anyway?
> *) actually, what are the re-authentication/re-authorisation 
> requirements in such mobility scenarios? how much authority 
> can be devolved to the interior nodes in the network?
> 
> plenty of others, of course...
> 
> cheers,
> 
> robert h.
> 
[snipped]
_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis
_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis