RE: [MIP-QOS] An attempt to glean some requirements

["ext Michael Thomas" <mat@cisco.com>]

rajeev.koodli@nokia.com writes:
 > > 2. Localize the QoS (re)programming to the affected parts of 
 > > the network
 > > path: In many cases, handover affects only a small segment 
 > > (typically close
 > > to the AR) of the end-to-end path of MN's packet stream. Then, the QoS
 > > mechanism SHOULD limit the extent of QoS (re)programming to 
 > > the affected
 > > segment of the end-to-end path only. This will reduce the 
 > 
 > Localizing the effect of signaling to only those parts affected by mobility
 > appears to be a MUST to me. Otherwise, how would mobility-aware signaling be
 > different from non-mobility-aware signaling ? Comments ?

   I think that the requirement needs to be qualified. In the
   CN->MN path, if you want fast/seamless handover you need to
   set up a forward tunnel from the old AR to MN to capture
   in flight packets. As such, the localization requirement
   is not important because it can be solved in a different
   (but currently available standard) way. Since
   in flight packets from the CN will be routed to
   ARold during this period, I question why it is
   that you'd want to impose new requirements for
   QoS reestablishment for packets that won't take 
   that path anyway.

   The MN->CN direction is the one that's
   problematic. Unless we use reverse tunneling
   through ARold for the duration of the handoff (which may actually be the
   right solution), RSVP as currently formulated suffers
   from the need to go clear back to the CN first before 
   reestablishing RESV state along the new path.

 > > 1. The QoS mechanism MUST seamlessly integrate with mobility 
 > > protocols such
 > > as basic mobile IP [MIPv4, MIPv6], fast handover, regional 
 > > registrations and
 > > context transfer.
 > 
 > This may be re-worded to say " The QoS mechanism MUST inter-work with
 > mobility protocols such as ..". "It MUST NOT impose changes to existing
 > protocols". 

   How can we make a requirement for protocols
   that don't currently exist? RR and CT are still
   sort of squishy. I think we need to be more 
   explicit here. After all, it may be these
   protocols that have it wrong wrt QoS (ie, they
   didn't take QoS requirements properly into
   account).

 > > (2. ## Some people think that pre-handover QoS negotiation should be
 > > included as a requirement. But I am not sure about this. I 
 > > think it is a
 > > part of bigger problem of service discovery ##)
 > > 
 > 
 > I agree that pre-handover QoS issue must be dealt with separately elsewhere.
 > I understand Seamoby MM effort would consider target AR selection. That may
 > be one place where such negotiation may be appropriate. 

   That sounds pretty orthogonal to both MM and MIP. I
   do think that we should bring up general issues
   with mobility though. Cross realm operation is
   a big problem right now, IMO. If we don't raise
   the issue, who will?

	 Mike