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

["ext Vinod Kumar Choyi" <vinod.choyi@usa.alcatel.com>]

Hemant,

Overall, it looks fine. I have a few comments below, though.

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

Minimize the interruption in QoS. Not only when handing-off.


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


I am not sure if it is definitely going to decrease QoS interruption, but
MAY.


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

Release it by explicitly sending a "release" or let a timer (absence of
refresh messages) do it ?

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

regards
vinod