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

[rajeev.koodli@nokia.com]

Hi,

These look good. Few comments in-line.

Regards,

-Rajeev


> -----Original Message-----
> From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com]
> Sent: Wednesday, April 18, 2001 2:44 PM
> To: mip-qos@research.nokia.com
> Subject: [MIP-QOS] An attempt to glean some requirements
> 
> 
> Performance requirements
> --------------------------------------
> 
> 1. Minimize the interruption in QoS at the time of handover: 
> Interruption in
> QoS would occur if the MN's packets arrive at the 
> intermediate node in the
> new end-to-end path without that node having information 
> about their QoS
> forwarding requirement. Such QoS interruption SHOULD be 
> minimized. A good
> metric for this performance aspect is the time difference between the
> instant MN's packet may potentially arrive at a node and the 
> instant that
> node is supplied with sufficient information to perform 
> appropriate QoS
> forwarding.
> 

Another way to capture the metric is by the number of packets that get
served with "default" QoS. The number of such packets should be minimized. 

> 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 ?

> volume of QoS
> signaling traffic (if any) as well as decrease the QoS interruption.
> However, it need not be limited to local QoS realignment. In 
> other words, if
> the end-to-end path changes at large after handover, the 
> programming for QoS
> forwarding MAY be done on end-to-end scale.

Agreed.

> 
> 3. A QoS mechanism SHOULD release the QoS state (if any) along the old
> end-to-end path, after handover.
> 
> Interoperability requirements
> ----------------------------------------
> 
> 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". 

> 
> 2. Interoperability with heterogeneous QoS schemes: The new 
> end-to-end path
> of MN's packet stream may encounter network domains employing 
> a variety of
> QoS mechanisms, such as IntServ, DiffServ and MPLS. The QoS 
> mechanism MUST
> be able to program appropriate QoS forwarding treatment for 
> the MN's packet
> stream in these QoS-heterogeneous network domains in the 
> end-to-end path.
> 
> Exception requirements
> ----------------------------------
> 
> 1. The new end-to-end path may not support the old QoS 
> agreement because one
> or more routers or links are already at capacity. The QoS 
> mechanism MUST
> have provisions to handle this situation. It MAY also be 
> required to inform
> the MN about the impending QoS degradation. The action taken 
> in response to
> this situation (adapt, gracefully degrade, re-negotiate or 
> tear down) and
> the decision point (MN or service provider policy) of the action are
> solution specific issues.
> 
> 2. Robustness against topology changes unrelated to handover (open for
> discussion).
> 
> 
> Miscellaneous requirements
> -----------------------------------------
> 
> 1. After MN is handed off from one AR to another, 
> potentially, there could
> be multiple paths over which MN's packet propagate. Examples 
> of these path
> are: route optimized path between the MN and its CN, triangle 
> route via HA,
> temporary tunnel between old and new ARs etc. A QoS mechanism 
> SHOULD be able
> to support QoS along the different potential paths. However, 
> whether all
> paths are supported or only a subset of them is supported 
> will be determined
> by external mechanisms such as, say, mobility management, policy etc.
> Further, the same QoS mechanism may not be able to support 
> all the three
> alternatives.
> 
> (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. 

> Obvious requirements
> -------------------------------
> 
> Scalability, security, saving wireless bandwidth and being 
> gentle on mobile
> terminal as regards processing.
>