Subject: RE: [NSIS] RE: nsis mobility interactions

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 30 Oct 2002 17:06:15 -0000

hi hemant,

see below:

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 30 October 2002 16:57
> To: [email-masked]
> Subject: RE: [NSIS] RE: nsis mobility interactions
> 
> 
> Hi Robert:
> 
> See below as [HMC]:
> 
> -----Original Message-----
> From: ext Hancock, Robert [mailto:[email-masked]]
> Sent: Tuesday, October 29, 2002 6:04 PM
> To: Chaskar Hemant (NRC/Boston); [email-masked]
> Subject: RE: [NSIS] RE: nsis mobility interactions
> 
[snip]
> > 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?
> 
[snip]
[reh] This is a good additional point. Are there examples of such APIs in existence? (Jukka, are you out there?)
Maybe the same API could be used by [M]IP to tell the signalling process "you are using this packet classifier, but you should probably use this one instead" (although this would imply [M]IP inspecting each packet for this condition, which seems a bit unpleasant; seems nicer to have the signalling daemon get it right first time, i.e. a query capability would be better.)

cheers,

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

---

From: Jukka MJ Manner <[email-masked]>
Date: Thu, 31 Oct 2002 08:31:59 +0200 (EET)

> [reh] This is a good additional point. Are there examples of such APIs
> in existence? (Jukka, are you out there?)

[JM] "Mr. reh calling?" :) Well, currently I have such a thing implemented
and running as we speak. Actually, I have an LMM process signalling
applications, which in turn trigger the daemon, but you could do it (with
more effort :) with your MIP process towards the daemon. Still, some could
argue that applications might also want to know about changes in network
state (=handovers), especially vertical ones.

Regards,

Jim