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

["ext James Kempf" <James.Kempf@sun.COM>]

Hemant,

Look good to me...

		jak
>From: Hemant.Chaskar@nokia.com
>To: mip-qos@research.nokia.com
>Subject: [MIP-QOS] An attempt to glean some requirements
>Date: Wed, 18 Apr 2001 16:43:39 -0500
>
>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.
>