[netext] draft-ietf-netext-pmip6-qos-03
John Kaippallimalil <John.Kaippallimalil@huawei.com> Fri, 13 September 2013 14:57 UTC
Return-Path: <John.Kaippallimalil@huawei.com>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A21521E80D0 for <netext@ietfa.amsl.com>; Fri, 13 Sep 2013 07:57:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrtKOZE7z-L9 for <netext@ietfa.amsl.com>; Fri, 13 Sep 2013 07:57:30 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A02B721E80AD for <netext@ietf.org>; Fri, 13 Sep 2013 07:57:25 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AXH35049; Fri, 13 Sep 2013 14:57:24 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 13 Sep 2013 15:57:03 +0100
Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 13 Sep 2013 15:57:20 +0100
Received: from DFWEML511-MBB.china.huawei.com ([169.254.4.189]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0146.000; Fri, 13 Sep 2013 07:57:14 -0700
From: John Kaippallimalil <John.Kaippallimalil@huawei.com>
To: "liebsch@neclab.eu" <liebsch@neclab.eu>, "pierrick.seite@orange.com" <pierrick.seite@orange.com>, "yokota@kddilabs.jp" <yokota@kddilabs.jp>, "jouni.nospam@gmail.com" <jouni.nospam@gmail.com>, "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
Thread-Topic: [netext] draft-ietf-netext-pmip6-qos-03
Thread-Index: Ac6wkYeZhEjuaLqrTnCIQZjZIVR69g==
Date: Fri, 13 Sep 2013 14:57:13 +0000
Message-ID: <6561EABF52675C45BCDACA1B4D7AA11725DA07@dfweml511-mbb.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.142.48]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "netext@ietf.org" <netext@ietf.org>
Subject: [netext] draft-ietf-netext-pmip6-qos-03
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Sep 2013 14:57:35 -0000
Hi, My comments on draft-ietf-netext-pmip6-qos-03. Overall, I think the draft is in very good condition and these comments should be relatively easy to consider. John Comments: -- 01) chapter 1. Introduction Last para explains some details on how the parameters in PMIP QoS apply. E.g.,to mobile node, mobility session or per flow, etc. Also, in section 3.5, it is stated that, "....at minimum there is a need to convey the following additional QoS parameters ....". On the other hand, some dynamic parameters from PCF (e.g. revised QCI, PDB) are not conveyed at this time. Any guidance on what parameters can be considered/should not be considered in future? It would be good to add a sentence or so in chapter 1 on the basis the parameters were selected, and where it can be used: - is it to establish parity with GTP? - required by MAG/router for enforcing QoS on IP path between MAG and LMA? - QoS in a radio access network, backhaul? - or some other basis? 02) chapter 2.2 Terminology Add Policy Control Function (PCF), relation to PMIP QoS, reference to 23.203? + Add text on Mobility Session, relation to IP flow 03) chapter 3.1. Technical Scope and Procedure "Non-cellular access technologies are not yet considered for per-flow QoS policing under control of a common PCF. ....." Is this sentence needed? Maybe confusing since TS 23.402 section 16.x considers WLAN and mobile network including session continuity and uses existing GTP mechanisms (QoS between TWAG (~MAG) and PGW (~LMA). 04) chapter 3.4. Use Case C -- Dynamic Update to QoS Policy "..The application on the mobile node initiates the communications via a dedicated network function (e.g. IMS Call Session Control Function). Once the communication is established, the application network function notifies the PCRF function about the new IP flow. The PCRF function in turn notifies the LMA about the needed QoS parameters identifying the IP flow and QoS parameters. LMA sends a Update Notification message [I-D.ietf-netext-update-notifications] to the MAG with the "Notification Reason" value set to "Force REREGISTER"..... 4A) PCRF - new term for Policy server introduced. Maybe better to stick with PCF, or explain the term PCRF. 4B) UPDATE-SESSION-PARAMETERS for Notification Reason seems like a better choice in this case. 4C)This example shows a model where policy updates are "pushed". In some cases, such as for WiFi networks, it may be better for the MN to trigger the sequence and have the policy "pulled" from the policy node - as in chapter 3.6 where the MN is "pulling" policy. In chapter 4, where the MAG (4.1) and LMA (4.2) behavior is described, the behavior describes the "pushing" of policy. Currently missing behavior to describe, for example the MAG encoding QoS Attribute in PBU to LMA, or how the LMA is encodes PBA if it receives a PBU with QoS attribute. 05) chapter 3.5. Relevant QoS Attributes " This is the GSMA/3GPP mapping for EPC/LTE: QCI Traffic Class DiffServ PHB DSCP 1 Conversational EF 101110 2 Conversational EF 101110 3 Conversational EF 101110 4 Streaming AF41 100010 5 Interactive AF31 011010 6 Interactive AF32 011100 (Not approved) ......." AF32 is now included in GSMA IR.34 version 9.1. 06) 10.2. Informative References Revise GSMA IR 34 reference to latest: [GSMA.IR.34] Guidelines for IPX Provider networks (Previously Inter-Service Provider IP Backbone Guidelines Version 9.1, May 2013.
- [netext] draft-ietf-netext-pmip6-qos-03 John Kaippallimalil