From nobody Fri Oct 10 06:41:12 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECDE1A031C; Fri, 10 Oct 2014 06:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9_fZI3QryYf; Fri, 10 Oct 2014 06:41:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 44EC11A03A4; Fri, 10 Oct 2014 06:41:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141010134108.12247.37155.idtracker@ietfa.amsl.com> Date: Fri, 10 Oct 2014 06:41:08 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/xQcWcrev8zzu71Aepj92gmSxlgg Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmip-qos-wifi-02.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 13:41:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF. Title : Mapping PMIPv6 QoS Procedures with WLAN QoS procedures Authors : John Kaippallimalil Rajesh Pazhyannur Parviz Yegani Filename : draft-ietf-netext-pmip-qos-wifi-02.txt Pages : 19 Date : 2014-10-10 Abstract: This document provides guidelines for achieving end to end QoS in a PMIPv6 domain where the access network is based on IEEE 802.11. RFC 7222 describes QoS negotiation between a MAG and LMA in a PMIPv6 mobility domain. The negotiated QoS parameters can be used for QoS policing and marking of packets to enforce QoS differentiation on the path between the MAG and LMA. IEEE 802.11-2012, WMM-AC describes methods for QoS negotiation between a Wi-Fi Station (MN in PMIPv6 terminology) and an Access Point. This document provides a mapping between the above two sets of QoS procedures and the associated QoS parameters. This document is intended to be used as a companion document to RFC 7222 to enable implementation of end to end QoS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmip-qos-wifi/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pmip-qos-wifi-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-pmip-qos-wifi-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 10 07:06:37 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A472B1ACE15 for ; Fri, 10 Oct 2014 07:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9RN_DbFc_F8 for ; Fri, 10 Oct 2014 07:06:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2E631A0171 for ; Fri, 10 Oct 2014 07:06:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKK43559; Fri, 10 Oct 2014 14:06:17 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Oct 2014 15:06:16 +0100 Received: from DFWEML703-CHM.china.huawei.com ([10.193.5.130]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Fri, 10 Oct 2014 07:06:10 -0700 From: John Kaippallimalil To: "Sri Gundavelli (sgundave)" , "netext@ietf.org" Thread-Topic: Review Comments on I-D: draft-ietf-netext-pmip-qos-wifi-01 Thread-Index: AQHP0XGdq6lR2CqF9kq32SrRu7DxUZwpfPww Date: Fri, 10 Oct 2014 14:06:09 +0000 Message-ID: <6561EABF52675C45BCDACA1B4D7AA1171DA241E5@dfweml703-chm> References: <6561EABF52675C45BCDACA1B4D7AA1171D9BF77E@dfweml703-chm.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.191] Content-Type: multipart/alternative; boundary="_000_6561EABF52675C45BCDACA1B4D7AA1171DA241E5dfweml703chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netext/Q50Xw8chN2inQkFKO_PwAZ67lsk Subject: Re: [netext] Review Comments on I-D: draft-ietf-netext-pmip-qos-wifi-01 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 14:06:30 -0000 --_000_6561EABF52675C45BCDACA1B4D7AA1171DA241E5dfweml703chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We just posted a new revision of the draft-ietf-netext-pmip-qos-wifi with S= ri's comments addressed: - Description of LMA initiated QoS reservation with IEEE 802.11aa - MN and session parameter descriptions, security text and other r= evisions for references, etc. The draft is ready for WGLC in our opinion. Regards, John Link to new version: The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmip-qos-wifi/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pmip-qos-wifi-02 From: netext [mailto:netext-bounces@ietf.org] On Behalf Of Sri Gundavelli (= sgundave) Sent: Tuesday, September 16, 2014 12:47 AM To: netext@ietf.org Subject: [netext] Review Comments on I-D: draft-ietf-netext-pmip-qos-wifi-0= 1 Hi Authors: I've reviewed the -01 version of Wi-Fi QoS document. Its is well written. I= ts in a good shape. Few comments below. Major Comment: > Section 3: "However, there are no standards defined way for the AP to ini= tiate a QoS service request to the MN." I'm bit disappointed to see the removal of the support for network initiate= d QoS set-up. John, Rajesh and myself had several offline discussions on t= his few months back; Here is my comment from earlier discussions. I'm not a= sking the Authors to add the support for network-initiated dynamic QoS, but= I thought it will be good to get some feedback from others. "I do not understand the 802.11 guys thinking on this entire StreamId busin= ess. When I first looked at it this, I thought this is just a identifier us= ed in Application signaling. But, when this is tied to .1Q, even the basic = semantics on the StreamId length or how its used in the network is not clea= r to me. Their view that the tag is global and can be enforced in the entir= e network seems bit broken. But, that spec is not my area of expertise and = so may be I missing the real intent here. However, when I look at this from PMIP QoS point of view and with the goal = of realizing end to end QoS, the QoS enforcement in this context is on the= MAG/AP. QoS enforcement on the rest of the network (MAG to LMA) is PMIP is= sue. If that is the baseline requirement, my point is what stops the UE or = the MAG implementation to ignore the StreamId completely ? MAG and UE repre= sent the two end points of the air interface and they both have the TFT. S= o, this entire streamId business is total non-sense, specially the key prot= ocols such as SIP have no mapping. So, even if there is public OUI allocati= on, I fail to understand how it fits in the overall scheme of things. So, m= y initial suggestion was to workaround the StreamId and make the spec work. " Additional Comments: > Introduction: "STA" Please add a reference or explanation on "STA" term - Station; In general, = please add references/explanations to all Wi-Fi terminology. > "The Mean Data Rate does not include the MAC and PHY overheads [WMM1.2.0]= " Some explanation can help. > However, this document does not exclude various deployments including those where AP and WLC are separate nodes, or the MAG control and data planes are separate." Should there any guidance on how the QoS parameters are negotiated/exchange= d between AP and WLC in the split mode ? > Section 1.2: TSPEC Add a reference to TSPEC > GBR, AMBR Terminology You may want to add a reference to RFC 7222 Terminology section. There is e= xplanation for GBR, AMBR and other parameters > PMIPV6 Should be PMIPv6 > Handovers ? I did not see much text on what happens to the QoS states after a MN's inte= r-MAG handovers. > Section 4.1 Please use "Traffic Class" in the table, instead of "DSCP" > Error Code Mapping RFC7222 defines couple of error codes. Its not clear how those error codes = map to the Cause Codes in ADDTS Response. I saw just one Cause Code. Is tha= t all ? > Scope: Per-MN, Per-Session, No discussion on the scope. Its unclear how the Per-Session, Per-MN attribu= tes map to different Wi-Fi QoS elements > Security Considerations You may want to add some text on how WLAN security architecture can protect= the integrity of the QoS signaling messages on the air interface. The curr= ent text may not be sufficient. > References Informative Reference to RFC 5213 and 5844 as the PBU/PBA messages are used= in call flows Add a reference to UPN/UPA spec (RFC7077) as its used in call flows --_000_6561EABF52675C45BCDACA1B4D7AA1171DA241E5dfweml703chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

We just posted a new revi= sion of the draft-ietf-netext-pmip-qos-wifi with Sri’s comments addre= ssed:

- =          Description of LM= A initiated QoS reservation with IEEE 802.11aa

- =          MN and session pa= rameter descriptions, security text and other revisions for references, etc= .

 <= /span>

The draft is ready for WG= LC in our opinion.  

 <= /p>

Regards,

John

 <= /p>

Link to new version:=

The IETF datatracker status page for this draft i= s:

https://datatracker.ietf.org/doc/draft-ietf-ne= text-pmip-qos-wifi/

 

There's also a htmlized version available at:

http://tools.ietf.org/html/draft-ietf-netext-pmip-= qos-wifi-02

 <= /p>

 <= /p>

 <= /p>

From: netext [= mailto:netext-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Tuesday, September 16, 2014 12:47 AM
To: netext@ietf.org
Subject: [netext] Review Comments on I-D: draft-ietf-netext-pmip-qos= -wifi-01

 

Hi Authors:

 

I've reviewed the -01 versi= on of Wi-Fi QoS document. Its is well written. Its in a good shape. Few com= ments below.

 

 

 

Major Comment:

 

> Section 3: "Howev= er, there are no standards defined way for the AP to initiate a QoS se= rvice request to the MN."

 

I'm bit disappointed to see= the removal of the support for network initiated QoS set-up.  John, R= ajesh and myself had several offline discussions on this few months back; Here is my comment from earlier discussions. I'm not asking t= he Authors to add the support for network-initiated dynamic QoS, but I thou= ght it will be good to get some feedback from others.

 

"I do not understand t= he 802.11 guys thinking on this entire StreamId business. When I first look= ed at it this, I thought this is just a identifier used in Application signaling. But, when this is tied to .1Q, even the basic semantics on the = StreamId length or how its used in the network is not clear to me. Their vi= ew that the tag is global and can be enforced in the entire network seems b= it broken. But, that spec is not my area of expertise and so may be I missing the real intent here. 

 

However, when I look at thi= s from PMIP QoS point of view and with the goal of realizing end to end QoS= , the QoS enforcement  in this context is on the MAG/AP. QoS enforcement on the rest of the network (MAG to LMA) is PMIP issue. If = that is the baseline requirement, my point is what stops the UE or the MAG = implementation to ignore the StreamId completely ? MAG and UE represent the= two end points of the air interface and they both have the TFT.  So, this entire streamId business i= s total non-sense, specially the key protocols such as SIP have no mapping.= So, even if there is public OUI allocation, I fail to understand how it fi= ts in the overall scheme of things. So, my initial suggestion was to workaround the StreamId and make the spec work.<= o:p>

" 

 

 

 

Additional Comments:

 

> Introduction: "ST= A"

Please add a reference or e= xplanation on "STA" term - Station; In general, please add refere= nces/explanations to all Wi-Fi terminology.

 

> "The Mean Data&nb= sp;Rate does not include the MAC and PHY overheads [WMM1.2.0]"

 Some explanation can = help.

 

> However, this doc= ument does not exclude

   various deploy= ments including those where AP and WLC are separate

   nodes, or the = MAG control and data planes are separate."

 

Should there any guidance o= n how the QoS parameters are negotiated/exchanged between AP and WLC in the= split mode ?

 

> Section 1.2: TSPEC

Add a reference to TSPEC

 

> GBR, AMBR Terminology<= o:p>

You may want to add a refer= ence to RFC 7222 Terminology section. There is explanation for GBR, AMBR an= d other parameters

 

> PMIPV6 

Should be PMIPv6 =

 

> Handovers ?=

I did not see much text on = what happens to the QoS states after a MN's inter-MAG handovers.=

 

> Section 4.1=

Please use "Traffic Cl= ass" in the table, instead of "DSCP" =

 

> Error Code Mapping

RFC7222 defines couple of e= rror codes. Its not clear how those error codes map to the Cause Codes in A= DDTS Response. I saw just one Cause Code. Is that all ?

 

> Scope: Per-MN, Per-Ses= sion, 

No discussion on the scope.= Its unclear how the Per-Session, Per-MN attributes map to different Wi-Fi = QoS elements

 

> Security Consideration= s

You may want to add some te= xt on how WLAN security architecture can protect the integrity of the QoS s= ignaling messages on the air interface. The current text may not be sufficient.

 

 

> References<= /span>

Informative Reference to RF= C 5213 and 5844 as the PBU/PBA messages are used in call flows

Add a reference to UPN/UPA = spec (RFC7077) as its used in call flows

 

 

 

 

 

--_000_6561EABF52675C45BCDACA1B4D7AA1171DA241E5dfweml703chm_-- From nobody Tue Oct 14 08:03:53 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC441A8791 for ; Tue, 14 Oct 2014 08:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kg5Jomm5dq2n for ; Tue, 14 Oct 2014 08:03:41 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D4AC1A88CC for ; Tue, 14 Oct 2014 08:03:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id B32C31083AB for ; Tue, 14 Oct 2014 17:03:39 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jFSArFHOyj5 for ; Tue, 14 Oct 2014 17:03:39 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 9383610839F for ; Tue, 14 Oct 2014 17:03:37 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.93]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.03.0210.002; Tue, 14 Oct 2014 17:03:37 +0200 From: Marco Liebsch To: "netext@ietf.org" Thread-Topic: comments to draft-ietf-netext-pmip-qos-wifi Thread-Index: Ac/nuHxofJ1lKyptQieRHXagCdp7jQ== Date: Tue, 14 Oct 2014 15:03:37 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D91A96295@PALLENE.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: multipart/alternative; boundary="_000_69756203DDDDE64E987BC4F70B71A26D91A96295PALLENEofficehd_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/EHbRqiQm5sLL4rx3fXGlAIgBjlI Subject: [netext] comments to draft-ietf-netext-pmip-qos-wifi X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 15:03:49 -0000 --_000_69756203DDDDE64E987BC4F70B71A26D91A96295PALLENEofficehd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear authors, please find some observations during review summarized below. Sorry for pos= ting my comments late, they are still based on revision 01 and may be obsolete with the rece= nt update. The draft is written well and provides guidelines about operation when comb= ining WiFi QoS with a PMIP QoS backend. I try to provide a few hints how the 'guideline'-aspects could be emphasize= d. It's up to the authors whether or not to adopt them. Some limitations, often constrained by WiFi/WMM, are analyzed, but few reco= mmendations or guidelines are provided how to tackle certain situations. Clarification = is not mandatory, but may help implementations. In general I see some implementation impact to the AP, so it's not simply a= configuration issue or even plug and play :) The fact to have two policy decision points with strong dependencies now br= eaks the WiFi QoS state machine. It may be useful to state this in the draft. Impact of the described WiFi admission control may be clarified, so I do no= t assume that a failed QoS request results in broken connectivity. But a hint about how t= o treat that case can be useful. I suppose no QoS state will be set up but tr= affic is treated BE, correct? Taking the operation in sec 3.1.1, the LMA may revise the requested QoS and let the MAG/AP know in the PBA. Is there support in WiFi/WMM to not= ify the MN about a successful QoS request but with adjusted (downgraded) QoS va= lues? Or is this treated as failed QoS request as per the WiFi specification? Sec. 3.2.1 describes the case when the LMA initiates a QoS setup and correc= tly points to the lack of support for network initiated QoS setup in WLAN. The current descri= ption is clear, but some recommendations how to tackle this may be given to meet a reader's expectat= ions on guidelines. E.g. how could a MAG accept or re-negotiate an LMA-initiated= QoS setup? It should not accept the LMA's request when the AP has not sufficien= t resources. So, the MAG may have knowledge about a resources budget from the AP (aggreg= ated or per MN). Providing such information is of course optional and up to author= s' decision. 1.2 Definitions >From sec. 3.1.1 I understand that terms peak and mean data rate are per-flo= w, correct? This may be stated in sec. 1.2 if it's the general assumption for the refer= red WMM procedure. I am not so clear about the statement that WMM-AC specs do not consider a T= CLAS (sec 3.1.1). Missing this attribute does not allow the description of a flow using the T= raffic Selector in PMIP. Sec. 3.1.1 indicates that in such case only a single reservation per AC is = possible. Are there default configurations then to identify best effort, video, voice, etc. tra= ffic? Or is that case even limited to a single reservation per MN/MAC address, hence all traffic of that MN is= assigned to the AC? How is that limitation reflected on the PMIP QoS; should per MN, per mobili= ty session aggregates be used? This could be clarified. Hope you find these comments useful. Best regards, marco --_000_69756203DDDDE64E987BC4F70B71A26D91A96295PALLENEofficehd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear authors,

 

please find some observations during review summariz= ed below. Sorry for posting my comments
late, they are still based on revision 01 and may be obsolete with the rece= nt update.

 

The draft is written well and provides guidelines ab= out operation when combining
WiFi QoS with a PMIP QoS backend.

 

I try to provide a few hints how the ‘guidelin= e’-aspects could be emphasized. It’s up to
the authors whether or not to adopt them.

 

Some limitations, often constrained by WiFi/WMM, are= analyzed, but few recommendations
or guidelines are provided how to tackle certain situations. Clarification = is not mandatory, but may
help implementations.

 

In general I see some implementation impact to the A= P, so it’s not simply a configuration
issue or even plug and play J<= o:p>

The fact to have two policy decision points with str= ong dependencies now breaks
the WiFi QoS state machine. It may be useful to state this in the draft.

 

Impact of the described WiFi admission control may b= e clarified, so I do not assume that
a failed QoS request results in broken connectivity. But a hint about how t= o
treat that case can be useful. I suppose no QoS state will be set up but tr= affic is
treated BE, correct?

 

Taking the operation in sec 3.1.1, the LMA may revis= e the requested
QoS and let the MAG/AP know in the PBA. Is there support in WiFi/WMM to not= ify
the MN about a successful QoS request but with adjusted (downgraded) QoS va= lues?
Or is this treated as failed QoS request as per the WiFi specification?

 

Sec. 3.2.1 describes the case when the LMA initiates= a QoS setup and correctly points to the
lack of support for network initiated QoS setup in WLAN. The current descri= ption is clear, but some
recommendations how to tackle this may be given to meet a reader’s ex= pectations
on guidelines. E.g. how could a MAG accept or re-negotiate an LMA-initiated= QoS
setup? It should not accept the LMA’s request when the AP has not suf= ficient resources.
So, the MAG may have knowledge about a resources budget from the AP (aggreg= ated or
per MN).  Providing such information is of course optional and up to a= uthors’ decision.

 

 

1.2 Definitions

From sec. 3.1.1 I understand that terms peak and mea= n data rate are per-flow, correct?
This may be stated in sec. 1.2 if it’s the general assumption for the= referred WMM procedure.

 

I am not so clear about the statement that WMM-AC sp= ecs do not consider a TCLAS (sec 3.1.1).
Missing this attribute does not allow the description of a flow using the T= raffic Selector in PMIP.
Sec. 3.1.1 indicates that in such case only a single reservation per AC is = possible. Are there
default configurations then to identify best effort, video, voice, etc. tra= ffic? Or is that case even limited
to a single reservation per MN/MAC address, hence all traffic of that MN is= assigned to the AC?
How is that limitation reflected on the PMIP QoS; should per MN, per mobili= ty session aggregates
be used? This could be clarified.

 

 

Hope you find these comments useful.

 

Best regards,

marco

 

 

 

 

 

 

 

 

 

--_000_69756203DDDDE64E987BC4F70B71A26D91A96295PALLENEofficehd_-- From nobody Tue Oct 14 09:46:57 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657291A8A94 for ; Tue, 14 Oct 2014 09:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkLlmGl2GT0I for ; Tue, 14 Oct 2014 09:46:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51DB51A895D for ; Tue, 14 Oct 2014 09:46:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNQ38382; Tue, 14 Oct 2014 16:46:50 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 14 Oct 2014 17:45:57 +0100 Received: from DFWEML703-CHM.china.huawei.com ([10.193.5.130]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0158.001; Tue, 14 Oct 2014 09:45:51 -0700 From: John Kaippallimalil To: Marco Liebsch , "netext@ietf.org" Thread-Topic: comments to draft-ietf-netext-pmip-qos-wifi Thread-Index: Ac/nuHxofJ1lKyptQieRHXagCdp7jQAEOXCg Date: Tue, 14 Oct 2014 16:45:51 +0000 Message-ID: <6561EABF52675C45BCDACA1B4D7AA1171DA24914@dfweml703-chm> References: <69756203DDDDE64E987BC4F70B71A26D91A96295@PALLENE.office.hd> In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D91A96295@PALLENE.office.hd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.238] Content-Type: multipart/alternative; boundary="_000_6561EABF52675C45BCDACA1B4D7AA1171DA24914dfweml703chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netext/6AmayovWCujiO9ElkjiX-FUR6Fg Subject: Re: [netext] comments to draft-ietf-netext-pmip-qos-wifi X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 16:46:56 -0000 --_000_6561EABF52675C45BCDACA1B4D7AA1171DA24914dfweml703chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Marco, Thank you for the detailed review. The comments and suggestions are very us= eful to clarify operation and improve readability - especially since this d= raft contains guidelines. Will revise with input from these comments in the next few days. Some notes on planned revision inline below. Best Regards, John From: netext [mailto:netext-bounces@ietf.org] On Behalf Of Marco Liebsch Sent: Tuesday, October 14, 2014 10:04 AM To: netext@ietf.org Subject: [netext] comments to draft-ietf-netext-pmip-qos-wifi Dear authors, please find some observations during review summarized below. Sorry for pos= ting my comments late, they are still based on revision 01 and may be obsolete with the rece= nt update. The draft is written well and provides guidelines about operation when comb= ining WiFi QoS with a PMIP QoS backend. I try to provide a few hints how the 'guideline'-aspects could be emphasize= d. It's up to the authors whether or not to adopt them. Some limitations, often constrained by WiFi/WMM, are analyzed, but few reco= mmendations or guidelines are provided how to tackle certain situations. Clarification = is not mandatory, but may help implementations. In general I see some implementation impact to the AP, so it's not simply a= configuration issue or even plug and play :) The fact to have two policy decision points with strong dependencies now br= eaks the WiFi QoS state machine. It may be useful to state this in the draft. >> will revise. Impact of the described WiFi admission control may be clarified, so I do no= t assume that a failed QoS request results in broken connectivity. But a hint about how t= o treat that case can be useful. I suppose no QoS state will be set up but tr= affic is treated BE, correct? >> correct. Revision 02 has some updates to clarify this, but will look ove= r again. Taking the operation in sec 3.1.1, the LMA may revise the requested QoS and let the MAG/AP know in the PBA. Is there support in WiFi/WMM to not= ify the MN about a successful QoS request but with adjusted (downgraded) QoS va= lues? Or is this treated as failed QoS request as per the WiFi specification? >> This would be a failed request per WiFi. Can add text to clarify this. Recommendations beyond that would perhaps be = beyond the scope of this draft. Sec. 3.2.1 describes the case when the LMA initiates a QoS setup and correc= tly points to the lack of support for network initiated QoS setup in WLAN. The current descri= ption is clear, but some recommendations how to tackle this may be given to meet a reader's expectat= ions on guidelines. E.g. how could a MAG accept or re-negotiate an LMA-initiated= QoS setup? It should not accept the LMA's request when the AP has not sufficien= t resources. So, the MAG may have knowledge about a resources budget from the AP (aggreg= ated or per MN). Providing such information is of course optional and up to author= s' decision. >> will revise. 1.2 Definitions >From sec. 3.1.1 I understand that terms peak and mean data rate are per-flo= w, correct? This may be stated in sec. 1.2 if it's the general assumption for the refer= red WMM procedure. >> will revise. I am not so clear about the statement that WMM-AC specs do not consider a T= CLAS (sec 3.1.1). Missing this attribute does not allow the description of a flow using the T= raffic Selector in PMIP. Sec. 3.1.1 indicates that in such case only a single reservation per AC is = possible. Are there default configurations then to identify best effort, video, voice, etc. tra= ffic? Or is that case even limited to a single reservation per MN/MAC address, hence all traffic of that MN is= assigned to the AC? How is that limitation reflected on the PMIP QoS; should per MN, per mobili= ty session aggregates be used? This could be clarified. >> updated in current revision. Hope you find these comments useful. >> definitely useful - appreciate the review. Best regards, marco --_000_6561EABF52675C45BCDACA1B4D7AA1171DA24914dfweml703chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Marco,

Thank you for the deta= iled review. The comments and suggestions are very useful to clarify operat= ion and improve readability - especially since this draft contains guidelin= es.

Will revise with input= from these comments in the next few days.

 

Some notes on planned = revision inline below.

 

Best Regards,

John=

 

 

From: netext [= mailto:netext-bounces@ietf.org] On Behalf Of Marco Liebsch
Sent: Tuesday, October 14, 2014 10:04 AM
To: netext@ietf.org
Subject: [netext] comments to draft-ietf-netext-pmip-qos-wifi

 

Dear authors,

 

please find some observations during review summariz= ed below. Sorry for posting my comments
late, they are still based on revision 01 and may be obsolete with the rece= nt update.

 

The draft is written well and provides guidelines ab= out operation when combining
WiFi QoS with a PMIP QoS backend.

 

I try to provide a few hints how the ‘guidelin= e’-aspects could be emphasized. It’s up to
the authors whether or not to adopt them.

 

Some limitations, often constrained by WiFi/WMM, are= analyzed, but few recommendations
or guidelines are provided how to tackle certain situations. Clarification = is not mandatory, but may
help implementations.

 

In general I see some implementation impact to the A= P, so it’s not simply a configuration
issue or even plug and play J<= o:p>

The fact to have two policy decision points with str= ong dependencies now breaks
the WiFi QoS state machine. It may be useful to state this in the draft.

 

>> will revise.<= o:p>

 

Impact of the described WiFi admission control may b= e clarified, so I do not assume that
a failed QoS request results in broken connectivity. But a hint about how t= o
treat that case can be useful. I suppose no QoS state will be set up but tr= affic is
treated BE, correct?

 

>> correct. Revi= sion 02 has some updates to clarify this, but will look over again.

 

Taking the operation in sec 3.1.1, the LMA may revis= e the requested
QoS and let the MAG/AP know in the PBA. Is there support in WiFi/WMM to not= ify
the MN about a successful QoS request but with adjusted (downgraded) QoS va= lues?
Or is this treated as failed QoS request as per the WiFi specification?

 

>> This would be= a failed request per WiFi.

Can add text to clarif= y this. Recommendations beyond that would perhaps be beyond the scope of th= is draft.

 

Sec. 3.2.1 describes the case when the LMA initiates= a QoS setup and correctly points to the
lack of support for network initiated QoS setup in WLAN. The current descri= ption is clear, but some
recommendations how to tackle this may be given to meet a reader’s ex= pectations
on guidelines. E.g. how could a MAG accept or re-negotiate an LMA-initiated= QoS
setup? It should not accept the LMA’s request when the AP has not suf= ficient resources.
So, the MAG may have knowledge about a resources budget from the AP (aggreg= ated or
per MN).  Providing such information is of course optional and up to a= uthors’ decision.

 

>> will revise.<= o:p>

 

 

1.2 Definitions

From sec. 3.1.1 I understand that terms peak and mea= n data rate are per-flow, correct?
This may be stated in sec. 1.2 if it’s the general assumption for the= referred WMM procedure.

 

>> will revise.<= o:p>

I am not so clear about the statement that WMM-AC sp= ecs do not consider a TCLAS (sec 3.1.1).
Missing this attribute does not allow the description of a flow using the T= raffic Selector in PMIP.
Sec. 3.1.1 indicates that in such case only a single reservation per AC is = possible. Are there
default configurations then to identify best effort, video, voice, etc. tra= ffic? Or is that case even limited
to a single reservation per MN/MAC address, hence all traffic of that MN is= assigned to the AC?
How is that limitation reflected on the PMIP QoS; should per MN, per mobili= ty session aggregates
be used? This could be clarified.

>> updated in cu= rrent revision.

 

 

Hope you find these comments useful.

 

>> definitely us= eful – appreciate the review.

 

Best regards,

marco

 

 

 

 

 

 

 

 

 

--_000_6561EABF52675C45BCDACA1B4D7AA1171DA24914dfweml703chm_-- From nobody Tue Oct 14 10:13:46 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6337A1A902B for ; Tue, 14 Oct 2014 10:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcIeG033pBwy for ; Tue, 14 Oct 2014 10:13:22 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB0AA1A9027 for ; Tue, 14 Oct 2014 10:13:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11550; q=dns/txt; s=iport; t=1413306798; x=1414516398; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Hu9n257EJ1+LjYA4Ki0xU3UQm2Uo9PUkOkJ7nh10gro=; b=LQUuE94W39kIg+rAG+1EzYxCj45+mnKegPjTKYTwRRDWhB6jyfwXYSKb ZUYQyHRFdbiLob3CjYyTWJLwfur/biiTdIE/pE3d1fAXZCyMAzG0Qa9TC JQ2HBGNE6TMeK0WOVfU0ROF8ZzrdrryyEYUrBEcVoDDw8YgEvpG7kbhIs 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFALVYPVStJV2R/2dsb2JhbABRCoJIRoErBNQBAoEVFgF9hAIBAQEDAX4LAgEIEQQBAQskMh0IAQEEARIIiC4IxnUBAQEBAQEBAQEBAQEBAQEBAQEBAQEXj2kEJziDLYEeBZF5jQCDRooHhxaDd2yBBkKBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,718,1406592000"; d="scan'208,217";a="363288672" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-4.cisco.com with ESMTP; 14 Oct 2014 17:13:17 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s9EHDHbj030321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Oct 2014 17:13:17 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.28]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Tue, 14 Oct 2014 12:13:16 -0500 From: "Rajesh Pazhyannur (rpazhyan)" To: Marco Liebsch , "netext@ietf.org" Thread-Topic: comments to draft-ietf-netext-pmip-qos-wifi Thread-Index: Ac/nuHxofJ1lKyptQieRHXagCdp7jQAF1w25 Date: Tue, 14 Oct 2014 17:13:16 +0000 Message-ID: <4ED2E36A22261145861BAB2C24088B4321809B12@xmb-aln-x09.cisco.com> References: <69756203DDDDE64E987BC4F70B71A26D91A96295@PALLENE.office.hd> In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D91A96295@PALLENE.office.hd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.35.68.199] Content-Type: multipart/alternative; boundary="_000_4ED2E36A22261145861BAB2C24088B4321809B12xmbalnx09ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/AahMnAy6ENYszQGMhHSAlLm889U Subject: Re: [netext] comments to draft-ietf-netext-pmip-qos-wifi X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 17:13:38 -0000 --_000_4ED2E36A22261145861BAB2C24088B4321809B12xmbalnx09ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Marco Thanks for the comments. Some responses inline regards Rajesh ________________________________ From: netext [netext-bounces@ietf.org] on behalf of Marco Liebsch [Marco.Li= ebsch@neclab.eu] Sent: Tuesday, October 14, 2014 8:03 AM To: netext@ietf.org Subject: [netext] comments to draft-ietf-netext-pmip-qos-wifi Dear authors, please find some observations during review summarized below. Sorry for pos= ting my comments late, they are still based on revision 01 and may be obsolete with the rece= nt update. The draft is written well and provides guidelines about operation when comb= ining WiFi QoS with a PMIP QoS backend. I try to provide a few hints how the =91guideline=92-aspects could be empha= sized. It=92s up to the authors whether or not to adopt them. Some limitations, often constrained by WiFi/WMM, are analyzed, but few reco= mmendations or guidelines are provided how to tackle certain situations. Clarification = is not mandatory, but may help implementations. In general I see some implementation impact to the AP, so it=92s not simply= a configuration issue or even plug and play :) The fact to have two policy decision points with strong dependencies now br= eaks the WiFi QoS state machine. It may be useful to state this in the draft. Impact of the described WiFi admission control may be clarified, so I do no= t assume that a failed QoS request results in broken connectivity. But a hint about how t= o treat that case can be useful. I suppose no QoS state will be set up but tr= affic is treated BE, correct? Taking the operation in sec 3.1.1, the LMA may revise the requested QoS and let the MAG/AP know in the PBA. Is there support in WiFi/WMM to not= ify the MN about a successful QoS request but with adjusted (downgraded) QoS va= lues? Or is this treated as failed QoS request as per the WiFi specification? > Yes, ADDTS response can provide success/failure status code. It does not = admit flows with "downgraded" QoS values. Sec. 3.2.1 describes the case when the LMA initiates a QoS setup and correc= tly points to the lack of support for network initiated QoS setup in WLAN. The current descri= ption is clear, but some recommendations how to tackle this may be given to meet a reader=92s expect= ations on guidelines. E.g. how could a MAG accept or re-negotiate an LMA-initiated= QoS setup? It should not accept the LMA=92s request when the AP has not suffici= ent resources. So, the MAG may have knowledge about a resources budget from the AP (aggreg= ated or per MN). Providing such information is of course optional and up to author= s=92 decision. 1.2 Definitions >From sec. 3.1.1 I understand that terms peak and mean data rate are per-flo= w, correct? This may be stated in sec. 1.2 if it=92s the general assumption for the ref= erred WMM procedure. I am not so clear about the statement that WMM-AC specs do not consider a T= CLAS (sec 3.1.1). Missing this attribute does not allow the description of a flow using the T= raffic Selector in PMIP. Sec. 3.1.1 indicates that in such case only a single reservation per AC is = possible. Are there default configurations then to identify best effort, video, voice, etc. tra= ffic? Or is that case even limited to a single reservation per MN/MAC address, hence all traffic of that MN is= assigned to the AC? How is that limitation reflected on the PMIP QoS; should per MN, per mobili= ty session aggregates be used? This could be clarified. >> Yes, we will clarify but briefly what we are saying is the following. I= EEE 802.11 has a information called TCLAS (which as the name indicates prov= ides flow classifiers). However, TCLAS is an optional field. However, WMM-A= C (from the Wi-Fi Alliance) which is a certification specification for admi= ssion control does not include TCLAS in the signaling. So WMM-AC compliant = devices are unlikely to have this field. Hope you find these comments useful. Best regards, marco --_000_4ED2E36A22261145861BAB2C24088B4321809B12xmbalnx09ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hello Marco

Thanks for the comments. Some responses inline

regards

Rajesh
From: netext [netext-bounces@ietf.org] on= behalf of Marco Liebsch [Marco.Liebsch@neclab.eu]
Sent: Tuesday, October 14, 2014 8:03 AM
To: netext@ietf.org
Subject: [netext] comments to draft-ietf-netext-pmip-qos-wifi

Dear authors,

 

please find some observations during review summariz= ed below. Sorry for posting my comments
late, they are still based on revision 01 and may be obsolete with the rece= nt update.

 

The draft is written well and provides guidelines ab= out operation when combining
WiFi QoS with a PMIP QoS backend.

 

I try to provide a few hints how the =91guideline=92= -aspects could be emphasized. It=92s up to
the authors whether or not to adopt them.

 

Some limitations, often constrained by WiFi/WMM, are= analyzed, but few recommendations
or guidelines are provided how to tackle certain situations. Clarification = is not mandatory, but may
help implementations.

 

In general I see some implementation impact to the A= P, so it=92s not simply a configuration
issue or even plug and play J<= /p>

The fact to have two policy decision points with str= ong dependencies now breaks
the WiFi QoS state machine. It may be useful to state this in the draft.

 

Impact of the described WiFi admission control may b= e clarified, so I do not assume that
a failed QoS request results in broken connectivity. But a hint about how t= o
treat that case can be useful. I suppose no QoS state will be set up but tr= affic is
treated BE, correct?

 

Taking the operation in sec 3.1.1, the LMA may revis= e the requested
QoS and let the MAG/AP know in the PBA. Is there support in WiFi/WMM to not= ify
the MN about a successful QoS request but with adjusted (downgraded) QoS va= lues?
Or is this treated as failed QoS request as per the WiFi specification?


> Yes, ADDTS response can provide success/failure= status code. It does not admit flows with "downgraded" QoS value= s.

 

Sec. 3.2.1 describes the case when the LMA initiates= a QoS setup and correctly points to the
lack of support for network initiated QoS setup in WLAN. The current descri= ption is clear, but some
recommendations how to tackle this may be given to meet a reader=92s expect= ations
on guidelines. E.g. how could a MAG accept or re-negotiate an LMA-initiated= QoS
setup? It should not accept the LMA=92s request when the AP has not suffici= ent resources.
So, the MAG may have knowledge about a resources budget from the AP (aggreg= ated or
per MN).  Providing such information is of course optional and up to a= uthors=92 decision.

 

 

1.2 Definitions

From sec. 3.1.1 I understand that terms peak and mea= n data rate are per-flow, correct?
This may be stated in sec. 1.2 if it=92s the general assumption for the ref= erred WMM procedure.

 

I am not so clear about the statement that WMM-AC sp= ecs do not consider a TCLAS (sec 3.1.1).
Missing this attribute does not allow the description of a flow using the T= raffic Selector in PMIP.
Sec. 3.1.1 indicates that in such case only a single reservation per AC is = possible. Are there
default configurations then to identify best effort, video, voice, etc. tra= ffic? Or is that case even limited
to a single reservation per MN/MAC address, hence all traffic of that MN is= assigned to the AC?
How is that limitation reflected on the PMIP QoS; should per MN, per mobili= ty session aggregates
be used? This could be clarified.


 >> Yes, we will clarify but briefly what= we are saying is the following. IEEE 802.11 has a information called TCLAS= (which as the name indicates provides flow classifiers). However, TCLAS is= an optional field. However, WMM-AC (from the Wi-Fi Alliance) which is a certification specification for admission contr= ol does not include TCLAS in the signaling. So WMM-AC compliant devices are= unlikely to have this field. 


 

Hope you find these comments useful.

 

Best regards,

marco

 

 

 

 

 

 

 

 

 

--_000_4ED2E36A22261145861BAB2C24088B4321809B12xmbalnx09ciscoc_-- From nobody Thu Oct 16 13:25:24 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0ABA1A8993; Thu, 16 Oct 2014 13:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j79nZfmxtDsF; Thu, 16 Oct 2014 13:25:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 095491A8997; Thu, 16 Oct 2014 13:25:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141016202509.12549.53184.idtracker@ietfa.amsl.com> Date: Thu, 16 Oct 2014 13:25:09 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/k-tmMUg_w37evVkdELvmsW2mZzM Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmip-qos-wifi-03.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 20:25:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF. Title : Mapping PMIPv6 QoS Procedures with WLAN QoS procedures Authors : John Kaippallimalil Rajesh Pazhyannur Parviz Yegani Filename : draft-ietf-netext-pmip-qos-wifi-03.txt Pages : 20 Date : 2014-10-16 Abstract: This document provides guidelines for achieving end to end QoS in a PMIPv6 domain where the access network is based on IEEE 802.11. RFC 7222 describes QoS negotiation between a MAG and LMA in a PMIPv6 mobility domain. The negotiated QoS parameters can be used for QoS policing and marking of packets to enforce QoS differentiation on the path between the MAG and LMA. IEEE 802.11-2012, WMM-AC describes methods for QoS negotiation between a Wi-Fi Station (MN in PMIPv6 terminology) and an Access Point. This document provides a mapping between the above two sets of QoS procedures and the associated QoS parameters. This document is intended to be used as a companion document to RFC 7222 to enable implementation of end to end QoS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmip-qos-wifi/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pmip-qos-wifi-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-pmip-qos-wifi-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 24 10:56:10 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 171B91A8A1A; Fri, 24 Oct 2014 10:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dgIAjP-kJ0B; Fri, 24 Oct 2014 10:55:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C70611A8A0F; Fri, 24 Oct 2014 10:55:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141024175557.18664.47616.idtracker@ietfa.amsl.com> Date: Fri, 24 Oct 2014 10:55:57 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/vKXnH3syGY6AV72zHvpigpI-sQ0 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-13.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 17:56:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF. Title : EAP Attributes for Wi-Fi - EPC Integration Authors : Ravi Valmikam Rajeev Koodli Filename : draft-ietf-netext-wifi-epc-eap-attributes-13.txt Pages : 18 Date : 2014-10-24 Abstract: With Wi-Fi emerging as a trusted access network for service providers, it has become important to provide functions commonly available in 3G and 4G networks in Wi-Fi access networks as well. Such functions include Access Point Name (APN) Selection, multiple Packet Data Network (PDN) connections, and seamless mobility between Wi-Fi and 3G/4G networks. The EAP/AKA (and EAP/AKA') protocol is required for mobile devices to access the mobile Evolved Packet Core (EPC) via trusted Wi-Fi networks. This document defines a few new EAP attributes to enable the above-mentioned functions in trusted Wi-Fi access networks. The attributes are exchanged between a client (such as a Mobile Node) and its network counterpart (such as a AAA server) in the service provider's infrastructure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-wifi-epc-eap-attributes/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-wifi-epc-eap-attributes-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-wifi-epc-eap-attributes-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 30 17:16:15 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B431A8988; Thu, 30 Oct 2014 17:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qj1eZsKKe4ff; Thu, 30 Oct 2014 17:16:11 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id F25E21A88C5; Thu, 30 Oct 2014 17:16:10 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 97F80181C7D; Thu, 30 Oct 2014 17:15:21 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20141031001521.97F80181C7D@rfc-editor.org> Date: Thu, 30 Oct 2014 17:15:21 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/netext/So5MDywPHKCpDHkF-GuZs4yKTIY Cc: drafts-update-ref@iana.org, netext@ietf.org, rfc-editor@rfc-editor.org Subject: [netext] RFC 7389 on Separation of Control and User Plane for Proxy Mobile IPv6 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 00:16:13 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7389 Title: Separation of Control and User Plane for Proxy Mobile IPv6 Author: R. Wakikawa, R. Pazhyannur, S. Gundavelli, C. Perkins Status: Standards Track Stream: IETF Date: October 2014 Mailbox: ryuji.wakikawa@gmail.com, rpazhyan@cisco.com, sgundave@cisco.com, charliep@computer.org Pages: 12 Characters: 26217 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netext-pmip-cp-up-separation-07.txt URL: https://www.rfc-editor.org/rfc/rfc7389.txt This document specifies a method to split the control plane (CP) and user plane (UP) for a network infrastructure based on Proxy Mobile IPv6 (PMIPv6). Existing specifications allow a mobile access gateway (MAG) to separate its control and user plane using the Alternate Care-of Address mobility option for IPv6 or Alternate IPv4 Care-of Address option for IPv4. However, the current specification does not provide any mechanism allowing the local mobility anchor (LMA) to perform an analogous functional split. To remedy that shortcoming, this document specifies a mobility option enabling an LMA to provide an alternate LMA address to be used for the bidirectional user-plane traffic between the MAG and LMA. With this new option, an LMA will be able to use an IP address for its user plane that is different than the IP address used for the control plane. This document is a product of the Network-Based Mobility Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC