RE: [Seamoby] RE: [NSIS] Re: draft-westphal-nsis-qos-mobileip-00. txt

["Gary Kenward" <[e-mail]>]

Ruediger:

  Concerning the comment that CT use the "original NSIS parameters":

	- CT is not a service establishment protocol; it tranports
       forwarding context, not service description parameters. Some
       of the forwarding context *may* be the original service description
       parameters, but many *may* be derived values that allow a more
       representative description of the AR forwarding context.

     - The issue is rather moot, because neither Seamoby nor NSIS are
       chartered to define what the signalling parameters or forwarding
       context are. To say that there should be some commonality is 
       of little import, as neither group can analyze the feasibility and
       impact of such a statement.

     - For the two groups should discuss the common parameters would be a
       violation of the respective charters. I think that this is an
excellent
       idea, but I believe it will have to take place outside of the
NSIS/Seamoby
       wgs, and I suggest that it would be best if we knew what the CT/NSIS 
       protocols were - at the very least, we can proceed with the
definition 
       of the protocols.

Regards,
Gary

> -----Original Message-----
> From: Geib, Ruediger [mailto:[e-mail]]
> Sent: July 11, 2002 04:24
> To: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; [e-mail]; [e-mail]
> Subject: RE: [Seamoby] RE: [NSIS] Re:
> draft-westphal-nsis-qos-mobileip-00. txt
> 
> 
> Hi James
> 
> > The point I was trying to make is that given CT of QoS 
> > context succeeds, NSIS signaling at the new access subnet is
> > unnecessary. Thus, it could be viewed as a kind of 
> > optimization. If CT fails, then signaling would be needed.
> 
> [RG] If this means "QoS related CT replaces MN signaling during 
> [RG] handoff", given that the related resource reservation
> [RG] doesn't change.
> 
> > I did not mean to imply that any changes were required in the 
> > generic CT requirements (though perhaps there would need to be
> > some changes in the QoS specific context definition).
> 
> [RG] QoS CT should use the NSIS resource reservation parameters
> [RG] as basic input for its own QoS parameters. Whether the 
> [RG] original NSIS parameters are copied or derived 
> [RG] technology or domain specific parameters are used for CT 
> [RG] doesn't matter if the result is as if the original NSIS 
> [RG] parameters were used to establish resources at the new AR.
> 
> > Is this accurate, from the NSIS viewpoint? One case where I 
> > could see it not being accurate is if there were some changes
> > required behind the access router in order to obtain QoS for 
> > the mobile on the new router, but perhaps there are others.
> 
> [RG] This may have to be clarified. I wouldn't expect an MN
> [RG] to get involved into tunnel set up and release, should
> [RG] this be the way an access network supports QoS and 
> [RG] mobility. A local NSIS solution may be used within 
> [RG] the access network to provide the required signaling.
> [RG] But I'd expect this to be invisible to the MN. 
> 
> [RG] I think NSIS and SEAMOBY must agree how both interwork.
> [RG] Besides the QoS parameter issue, an MN should be aware
> [RG] of the fact whether CT is supported and whether it is 
> [RG] succesful (or whether it wasn't).
> [RG] To me this seems to be a loose cooperation. If NSIS and
> [RG] SEAMOBY conclude to ignore each other, I'd regard both
> [RG] as a waste of time with regard to wireless mobility 
> [RG] combined with QoS. 
> 
> Regards, Rüdiger
>