[MIP-QOS] An attempt to glean some requirements

[Hemant.Chaskar@nokia.com]

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.