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

["ext Murray Philip" <PMURRAY@dera.gov.uk>]

I agree with that
Phil
(sorry about the disclaimer nothing can be done apparently)

-----Original Message-----
From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com]
Sent: 18 April 2001 22:44
To: mip-qos@research.nokia.com
Subject: [MIP-QOS] An attempt to glean some requirements


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.


-- 
The Information contained in this E-Mail and any subsequent correspondence
is private and is intended solely for the intended recipient(s).
For those other than the recipient any disclosure, copying, distribution, 
or any action taken or omitted to be taken in reliance on such information is
prohibited and may be unlawful.