[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.