Subject: Re: [mobile-ip] draft-tkn-mobileip-qosbinding-mipv6-00.txt

From: "Hemant Chaskar" <[email-masked]>
Date: Thu, 19 Jul 2001 14:36:00

Hi Xiaoming:

The addition of resource allocation status bits and the two levels of QoS - 
desired and acceptable, to QoS object are good additions to the scheme. You 
have mentioned that this scheme has low signaling overhead. I would also 
like to add that it has less latency in QoS re-establishment along the new 
path. Also it is possible to use more optmized procedures for refreshing the 
QoS state.

Regarding D bit: The natural question is what happens if the two way paths 
are assymetric?

I think there is a more efficient way to refresh the QoS states if any, 
after QoS object is included in the first BU. One can assign a small ID to 
QoS object calculated as, for example, the hash of QoS object by MN-specific 
(and private) key such as password. Then we only send this ID as h-b-h 
options in some data packets at regular intervals. That way it will refresh 
the state and not waste wireless bandwidth for refresh.

You draft says that the QoS object can be transferred from old AR to new AR 
by context tranfer framework. In that case, who sends BU to MAP? In other 
words, it is not possible that the MN sends BU and AR "fills in" the QoS 
object h-b-h option as it changes IP packet length and disturbs the 
authentication calculation.

Hemant

>From: Xiaoming Fu <[email-masked]>
>Reply-To: [email-masked]
>To: "[email-masked]" <[email-masked]>
>Subject: [mobile-ip] draft-tkn-mobileip-qosbinding-mipv6-00.txt
>Date: Thu, 19 Jul 2001 13:09:46 +0200
>
>Hi,
>
>Recently we have proposed a new idea on QoS for MIP. This
>work is based on HMIPv6 and follows the concept of the QoS
>option presented by draft-chaskar-mobileip-qos-01.txt
>(H. Chaskar, etc). The difference lies on that we update a
>binding status only when QoS requirements are met,
>i.e., QoS-conditionalized.
>
>We also compared it with the WG draft "Requirements of a
>QoS Solution for Mobile IP".
>
>Any comments, suggestions, or critics are welcome.
>
>Xiaoming Fu
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>
>
>         Title           : QoS-Conditionalized Binding Update in Mobile
>IPv6
>         Author(s)       : A. Festag et al.
>         Filename        : draft-tkn-mobileip-qosbinding-mipv6-00.txt
>         Pages           : 29
>         Date            : 16-Jul-01
>
>Abstract
>    This draft presents a scheme for QoS support in Mobile IPv6 based on
>    the architecture of Hierarchical Mobile IPv6.  A QoS option, a hop-
>    by-hop header extension option first presented by Chaskar et al.
>    [6], is carried in the message containing the Binding Update (BU)
>    option to the mobility anchor point (MAP).  Handoffs are
>conditionalized
>    upon the availability of sufficient resources in the route between MN
>    and MAP to meet QoS requirements.  When sufficient resources are not
>    available and there is more than one new access router, the procedure
>    can be reiterated.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-tkn-mobileip-qosbinding-mipv6-00.txt

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

---

From: Xiaoming Fu <[email-masked]>
Date: Fri, 20 Jul 2001 09:32:26 +0200

Hi Hemant,

> Regarding D bit: The natural question is what happens if the two way paths
Though the case of assymetric paths are not studied in this draft
(see goals & assum. 6- "provided that both uplink and downlink data
travels 
along the same route"), we think it may possible to use a
non-MIP-specific 
QoS mechanism for uplink data traffic, since it does't involve MIP-based 
re-routing. However this needs further investigation.

> the state and not waste wireless bandwidth for refresh.
Yes, we agreed that using ID as the refreshing option may reduce the
size of 
message size, as this refreshing won't bring up QoS change in the
existing path. 
And this may introduce new option type (so we keep the current version
for
the moment.)

> authentication calculation.
The nAR should be now responsible for sending BU (to be more exact,
re-assembling 
it by adding QoS object getting from the oAR). Hereby the AR should be 
aware of CT and able to assemble a QoS-aware BU.

--