Re: [netext] New Version Notification for draft-liebsch-netext-pmip6-qos-01.txt

Hi Yiu,

good comment! Please let me add to Hidetoshi's feedback.
I don't think the mobility session should be broken just because the MAG
cannot enforce the QoS rules as provided by the LMA.

There are different cases: the MAG may propose QoS rules in the PBU and the LMA
may accept or adjust (e.g. downgrade) them, then notify the MAG in the PBA.
We should assume that the MAG can enforce the QoS policy it proposes to the LMA
in the PBU.

The other case is that the MAG does not include QoS, but receives QoS policies
from the LMA in the PBA. In case it cannot enforce the provided rules but all other
requirements are met to enable the mobility session state as result of the received
PBA, the mobility binding should be accepted while QoS can be re-negotiated in the
background. In such case, the traffic is forwarded, possibly using a default or BE QoS,
and the MAG proposes alternative QoS to the LMA in an updating PBU.

Could that be a satisfying solution? We may even consider an administrative
setting for loose or strong QoS support. Loose support would follow the
above operation, whereas strong support may allow accepting a
mobility binding at LMA and MAG only when the negotiated QoS
can be enforced.

What do you think?

marco

From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com]
Sent: Sonntag, 29. April 2012 21:59
To: Sri Gundavelli; Marco Liebsch; netext@ietf.org
Subject: Re: [netext] New Version Notification for draft-liebsch-netext-pmip6-qos-01.txt

Hi,

I read this draft and I think is an important aspect missing in PMIPv6. I think the WG should seriously consider to work on it.

In the current version, I have a concern. For example: Fig 3.5.1 shows the LMA will include the QoS option in PBA. If the MAG can't satisfy the QoS, what will the MAG do? Dereg the session? PBA is an acknowledgement to the PBU. It looks odd to me to use it for carrying QoS request.r  Perhaps a better way to handle it is to create a new set of QoS request/response rather than embedding the QoS request in the PBA.

Thanks,
Yiu

From: Sri Gundavelli <sgundave@cisco.com<mailto:sgundave@cisco.com>>
Date: Wednesday, April 25, 2012 7:31 PM
To: Marco Liebsch <Marco.Liebsch@neclab.eu<mailto:Marco.Liebsch@neclab.eu>>, "netext@ietf.org<mailto:netext@ietf.org>" <netext@ietf.org<mailto:netext@ietf.org>>
Subject: Re: [netext] New Version Notification for draft-liebsch-netext-pmip6-qos-01.txt

Folks:

Please comment on this draft. Lot of efforts went in to this from all the Authors, please review and comment.

http://www.ietf.org/id/draft-liebsch-netext-pmip6-qos-01.txt

Regards
Sri

On 3/13/12 8:40 AM, "Marco Liebsch" <Marco.Liebsch@neclab.eu> wrote:
Please find an update of our draft about a QoS option for PMIP6 on the IETF repository, which
addresses comments from last meeting. The current version includes more details about the
proposed operation and QoS attributes.

Marco

Filename:            draft-liebsch-netext-pmip6-qos
Revision:              01
Title:                      Quality of Service Option for Proxy Mobile IPv6
Creation date:   2012-03-12
WG ID:                  Individual Submission
Number of pages: 32
Link: http://www.ietf.org/id/draft-liebsch-netext-pmip6-qos-01.txt

Abstract:
   This specification defines a new mobility option that can be used by
   the mobility entities in the Proxy Mobile IPv6 domain to exchange
   Quality of Service parameters associated with a subscriber&#39;s IP
   flows.  Using the QoS option, the local mobility anchor and the
   mobile access gateway can exchange available QoS attributes and
   associated values.  This enables QoS policing and labeling of packets
   to enforce QoS differentiation on the path between the local mobility
   anchor and the mobile access gateway.  Furthermore, making QoS
   parameters available on the MAG enables mapping these parameters to
   QoS rules being specific to the access technology which operates
   below the mobile access gateway.  After such mapping, QoS rules can
   be enforced on the access technology components, such as an IEEE
   802.11e Wireless LAN controller.

________________________________
_______________________________________________
netext mailing list
netext@ietf.org
https://www.ietf.org/mailman/listinfo/netext