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

["ext Xiaoming Fu" <fu@ee.tu-berlin.de>]

good for me,

Xiaoming

Hemant.Chaskar@nokia.com wrote:
> 
> Hi,
> 
> After going through discussion and reading comments from the list
> participants, the following requirements are more clear to me than others.
> This in no way is a complete list and please let me know what is missing
> (with justification if possible). It may also be useful to stare at this
> list and see if the missing requirement that we have in mind is already
> covered, albeit at a high level, in the following list. If need be, the
> items in the high level list could be expanded to cover those missing
> requirements.
> 
> In case there is a consensus that this list can be used as a core to build
> upon, then we have made a good progress.
> 
> 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.
> 
> 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 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.
> 
> 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.
> 
> 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 ##)
> 
> Obvious requirements
> -------------------------------
> 
> Scalability, security, saving wireless bandwidth and being gentle on mobile
> terminal as regards processing.

-- 
----------------------------------------
Dr. Xiaoming Fu
Telecommunication Networks Group
Technical University Berlin
Einsteinufer 25, 10587 Berlin
Tel: (0049-30)31423827
Fax: (0049-30)31423818
Email: fu@ee.tu-berlin.de
----------------------------------------