[MIP-QOS] Re: MIP-QOS -- Scope of discussions

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

Hemant,

A few comments below,

Hemant.Chaskar@nokia.com wrote:
> 
> Let me start with a partial list of requirements that I have in mind:
> 
> 1. Minimize the interruption in QoS at the time of handoffs

> 2. Localize the QoS (re)programming to the affected parts of the end-to-end
> path
I would place this item into "solution" part, rather. End-to-end v.s.
locally is an issue of different QoS provisioning ways, not our
requirements directly.

> 3. Ability to automatically perform QoS (re)programming end-to-end or
> locally depending upon the difference between the old and the new packet
> paths
Are you mean "QoS signaling"? Locally the best, if possible.

> 4. Interoperability with fast handover, micro-mobility and context transfer
> mechanisms
Sure. (4.5?) Support for IETF QoS mechanisms, e.g., Diffserv,
intserv/rsvp, mpls.

> 5. Ability to work with heterogeneous Qos domains that may be encountered in
> the end-to-end path, e.g., what if MN is handed off from IntServ to DiffServ
> access network and vice-versa
We have to look into Authentication/Policy between adjacent domains as
well.

> 6. Optimized to unicast streams. It the unicast scheme is automatically
> optimized for multicast, that is great. If not, they need to be separated.
For our scope I would favor a "unicast"-oriented streams as the first
step. To my knowledge the Seamoby group doesn't concern for multicast
for the moment as well.

7. Ability of QoS (re-)negotiation. A potential problem of
mobility/handoff is the traffic pushing on ARs/Access Networks will
change more dynamically. 


Xiaoming