From internet-drafts@ietf.org Thu Dec 5 14:10:09 2013 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 587521AE1C8; Thu, 5 Dec 2013 14:10:09 -0800 (PST) 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 jfyxzpgFVUYo; Thu, 5 Dec 2013 14:10:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B43461AE1EE; Thu, 5 Dec 2013 14:10:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131205221006.26057.44936.idtracker@ietfa.amsl.com> Date: Thu, 05 Dec 2013 14:10:06 -0800 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmip6-qos-08.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, 05 Dec 2013 22:10:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Working= Group of the IETF. Title : Quality of Service Option for Proxy Mobile IPv6 Author(s) : Marco Liebsch Pierrick Seite Hidetoshi Yokota Jouni Korhonen Sri Gundavelli Filename : draft-ietf-netext-pmip6-qos-08.txt Pages : 61 Date : 2013-12-05 Abstract: This specification defines a new mobility option, the Quality of Service (QoS) option, for Proxy Mobile IPv6. This option can be used by the local mobility anchor and the mobile access gateway for negotiating Quality of Service parameters for a mobile node's IP flows. The negotiated QoS parameters can be used for QoS policing and marking 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 mobile access gateway enables mapping of these parameters to QoS rules that are specific to the access technology and allows those rules to be enforced on the access network using access technology specific approaches. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmip6-qos There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pmip6-qos-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-pmip6-qos-08 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 internet-drafts@ietf.org Sun Dec 8 14:00:38 2013 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 81FBD1AE136; Sun, 8 Dec 2013 14:00:38 -0800 (PST) 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 FHgtd-yMymdB; Sun, 8 Dec 2013 14:00:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A28E1AE12D; Sun, 8 Dec 2013 14:00:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131208220036.16660.32574.idtracker@ietfa.amsl.com> Date: Sun, 08 Dec 2013 14:00:36 -0800 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pd-pmip-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: Sun, 08 Dec 2013 22:00:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Working= Group of the IETF. Title : Prefix Delegation Support for Proxy Mobile IPv6 Author(s) : Xingyue Zhou Jouni Korhonen Carl Williams Sri Gundavelli Carlos J. Bernardos Filename : draft-ietf-netext-pd-pmip-13.txt Pages : 27 Date : 2013-12-08 Abstract: This specification defines extensions to the Proxy Mobile IPv6 protocol for allowing a mobile router in a Proxy Mobile IPv6 domain to obtain IP prefixes for its attached mobile networks using DHCPv6 prefix delegation. Network-based mobility management support is provided for those delegated IP prefixes just as it is provided for the mobile node's home address. Even if the mobile router performs a handoff and changes its network point of attachment, mobility support is ensured for all the delegated IP prefixes and for all the IP nodes in the mobile network that use IP address configuration from those delegated IP prefixes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pd-pmip There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pd-pmip-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-pd-pmip-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 sgundave@cisco.com Mon Dec 9 14:24:21 2013 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 5C7131AE604 for ; Mon, 9 Dec 2013 14:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, 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 KlV5HZTi_syh for ; Mon, 9 Dec 2013 14:24:19 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE641AE5FF for ; Mon, 9 Dec 2013 14:24:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3626; q=dns/txt; s=iport; t=1386627855; x=1387837455; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=wJe/pVEj1jWbDuT5z268ThGxLTj+oLDbwll5lAup5Z4=; b=dsnDfQsYjRaRzPuX3SgbwWsTetpfuoBjIbXaLY74KcwWRH8AX4gOQXcx BY2pF5/RU8zAB1ni/EcQyNhOJBIwb4w9+Ck49hqr+rX5O+Q+Wr0uZZ3mo BnD5rcxJ97To45vERjZW7QUmQxeMqXhZb0NaLvmQbmt7R4lplr+vsdn0u E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQFAEFCplKtJXG+/2dsb2JhbABZgweBC7kWgSwWbQeCJQEBAQQ6OBkBCBIGHkIXBAEGAwIEE4gCohyeTBePF4QzA5gUkhODKYIq X-IronPort-AV: E=Sophos;i="4.93,860,1378857600"; d="scan'208";a="5522884" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-4.cisco.com with ESMTP; 09 Dec 2013 22:24:14 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rB9MOEGp005191 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 9 Dec 2013 22:24:14 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.155]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Mon, 9 Dec 2013 16:24:14 -0600 From: "Sri Gundavelli (sgundave)" To: "netext@ietf.org" Thread-Topic: [netext] I-D Action: draft-ietf-netext-pmip6-qos-08.txt Thread-Index: AQHO9QjPPJ+LDjo/rE2Wb/q20TzQLJpMTywA Date: Mon, 9 Dec 2013 22:24:14 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.212] Content-Type: text/plain; charset="us-ascii" Content-ID: <24799A0EE1A9F2429B7037A9312D596D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [netext] FW: I-D Action: draft-ietf-netext-pmip6-qos-08.txt 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: Mon, 09 Dec 2013 22:24:21 -0000 FYI > >On 12/9/13 9:04 AM, "Brian Haberman" wrote: > >>All, >> Here are my comments on this draft... >> >>1. Somewhere in the front matter of the draft, there should be some >>discussion as to why existing QoS signaling mechanisms are not used >>(e.g., RSVP). > > >Ok. We can add some considerations. > >1. In mobility deployments, access and core network can be in two >different operator domains. Assumption of Int-serv based architecture >will not work >2. The QoS signaling and the models that we support have a tight relation >to the subscriber policy and charging, in the context of QoS policy >negotiation and so explicit signaling tied to mobility signaling is needed >3. In general RSVP/Int-serv based models in SP network will not scale > >Agree. We need a motivation statement, summary of features supported and >the architectural model. Will add few lines of text at the beginning. > > > >> >>2. Section 2.2 refers to the Allocation and Retention Priority option as >>ARP and AARP. I assume AARP is a typo (but ARP is also an unfortunate >>overload...). > > >Agree.=20 > >Better not to confuse this with the ARP term. Will add some explanation >around this, > > >> >>3. Is there any expectation for infrastructure devices between the MAG >>and LMA to provide QoS services for these flows? If so, how? With the >>QoS information embedded in PMIP messages, how would these intermediate >>devices know anything about these QoS parameters and any associated >>Per-Hop-Behaviors? This needs some discussion in the draft to ensure a >>consistent deployment view. > > >There are some considerations here: > >1.) MAG and LMA apply rate-limiting and other features based on the >negotiated QoS policies >2.) MAG and LMA apply proper DSCP marking/re-marking on the user flows >based on the negotiated QoS policy >3.) Transit network honoring the QoS markings on the tunneled flows >(tunnel peers copy the DSCP marking from inner payload to outer GRE >header) > > >> >>4. Section 4.1 says that if M=3D1, D=3D0, but there is no discussion of w= hat >>to do if M=3DD=3D1 occurs. Is the option ignored? > > >It should be considered an error. May be as Carlos suggested, we will use >a two-bit field instead of flags. > > > > >> >>5. I am curious as to why a 5-bit Service Request ID is sufficient. You >>have bits available in the Resvd field... Wouldn't an 8-bit field make >>operations/comparisons easier? > > >Typically in QoS architectures, differentiated flow treatment is >provisioned for "N" DSCP flows. In 3GPP this is the QCI groups. These >have to be in single digit count, else the network cannot scale. > >When a MAG makes a QoS service request for a subscriber flow(s), it will >create unique service requests, each request identifying a set of flows, >unique DSCP marking and some QoS properties (MBR, GBR ..etc). The number >of requests cannot be more than 64 groups (given that DSCP is a 6-bit >field). We are tying the QoS service request to a unique DSCP value. So, >32 QoS flow groups should be sufficient. > > > > >> >>6. Section 4.2 only describes bit-rate-based attributes. Is this due to >>use cases described in other SDOs? > > >Yes. To be consistent with the 3GPP and Wi-FI QoS attributes. > > >> >>7. What is the handling if there is a conflict between a per-node QoS >>attribute and a set of per-flow QoS attributes associated with that node? > > >Its an error condition. Will add some text in the LMA processing rules. > > > >Regards >Sri > > From sgundave@cisco.com Mon Dec 9 14:29:15 2013 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 6A98C1AE60D for ; Mon, 9 Dec 2013 14:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, 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 HSj0VjJb8_Zp for ; Mon, 9 Dec 2013 14:29:13 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id B95991AE601 for ; Mon, 9 Dec 2013 14:29:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1517; q=dns/txt; s=iport; t=1386628149; x=1387837749; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Fu8yj1eodlraouICXQAFZMhlPJkxVSKqel3sQ3NXkmI=; b=eO5EJ22s/oEErMgkDzgsUpI1A/tT/6n1zvgDsemY2vA1Nfd8njgJurQU BS8TiAiWqd7hkZd1Y+iolrqAmTIVRvFbal4HQco6Z/2OwzyozGPI2bsiB OOjhKalj/+tqwa91dwzojGv51NcH7+85iP+iPkqwQI1ESyLDDahA0hw9i A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMFAGlDplKtJXG+/2dsb2JhbABZgweBC7kWgSwWbQeCJQEBAQQ6UQEIGB5CJQIEE4gCohueTheOXTqEMwOYFJITgymCKg X-IronPort-AV: E=Sophos;i="4.93,860,1378857600"; d="scan'208";a="5525326" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-5.cisco.com with ESMTP; 09 Dec 2013 22:29:08 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rB9MT815011204 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 9 Dec 2013 22:29:08 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.155]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Mon, 9 Dec 2013 16:29:08 -0600 From: "Sri Gundavelli (sgundave)" To: "netext@ietf.org" Thread-Topic: Brian's review comments on draft-ietf-netext-pmip6-qos-08.txt Thread-Index: AQHO9S0rDL1xVF1YCUiw4/NdtdZNYppMUEIA Date: Mon, 9 Dec 2013 22:29:08 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.212] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netext] Brian's review comments on draft-ietf-netext-pmip6-qos-08.txt 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: Mon, 09 Dec 2013 22:29:15 -0000 FYI > > >On 12/9/13 9:04 AM, "Brian Haberman" wrote: > >>All, >> Here are my comments on this draft... >> >>1. Somewhere in the front matter of the draft, there should be some >>discussion as to why existing QoS signaling mechanisms are not used >>(e.g., RSVP). >> >>2. Section 2.2 refers to the Allocation and Retention Priority option as >>ARP and AARP. I assume AARP is a typo (but ARP is also an unfortunate >>overload...). >> >>3. Is there any expectation for infrastructure devices between the MAG >>and LMA to provide QoS services for these flows? If so, how? With the >>QoS information embedded in PMIP messages, how would these intermediate >>devices know anything about these QoS parameters and any associated >>Per-Hop-Behaviors? This needs some discussion in the draft to ensure a >>consistent deployment view. >> >>4. Section 4.1 says that if M=3D1, D=3D0, but there is no discussion of w= hat >>to do if M=3DD=3D1 occurs. Is the option ignored? >> >>5. I am curious as to why a 5-bit Service Request ID is sufficient. You >>have bits available in the Resvd field... Wouldn't an 8-bit field make >>operations/comparisons easier? >> >>6. Section 4.2 only describes bit-rate-based attributes. Is this due to >>use cases described in other SDOs? >> >>7. What is the handling if there is a conflict between a per-node QoS >>attribute and a set of per-flow QoS attributes associated with that node? >> >>Regards, >>Brian >> > From sgundave@cisco.com Wed Dec 11 16:25:34 2013 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 D2F541ADFBC for ; Wed, 11 Dec 2013 16:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 tI4kdEooZnyO for ; Wed, 11 Dec 2013 16:25:33 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id EABB81ADE85 for ; Wed, 11 Dec 2013 16:25:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3861; q=dns/txt; s=iport; t=1386807927; x=1388017527; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=O8rwlnfzkEqge4puUJeh5FCZvOUlwvCGSRrN6b69GGo=; b=i6QwMrcQRdxbQzMw2br3VRwweeDMy2kR0dwh2k+qnX0ODBA2Sgd8JdrT XHXT36pufsbyrrKhH6V1Xws67V/V7d9FwFsEtpJicp2VdotIABZ3Xg0Vn jmUemWADN/Tf56JfnHMN+3mCLaNzV5jneU0/A5BsiDtrbNeHM0p8ofgt3 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFACIBqVKtJXHA/2dsb2JhbABZgweBC7lOgRsWdIIlAQEBBGcFCg8GAQgRBAEBKDkUBwEBBQMCBBOIAqMvnwMXjl0yAgSELgSYFJITgymCKg X-IronPort-AV: E=Sophos;i="4.93,874,1378857600"; d="scan'208";a="290933223" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 12 Dec 2013 00:25:27 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rBC0PRQ2027836 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 12 Dec 2013 00:25:27 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.155]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Wed, 11 Dec 2013 18:25:26 -0600 From: "Sri Gundavelli (sgundave)" To: "netext@ietf.org" Thread-Topic: [netext] I-D Action: draft-ietf-netext-pmip6-qos-08.txt Thread-Index: AQHO9tCnyIlc3+UlN0iqDkXQxCaKyA== Date: Thu, 12 Dec 2013 00:25:26 +0000 Message-ID: In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D637782C5@Hydra.office.hd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.212] Content-Type: text/plain; charset="Windows-1252" Content-ID: <2B3775320581C145B7AEA03EC0151DF5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [netext] FW: I-D Action: draft-ietf-netext-pmip6-qos-08.txt 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: Thu, 12 Dec 2013 00:25:35 -0000 Response to Brian's review =8A On 12/11/13 3:13 AM, "Marco Liebsch" wrote: >Brian, thanks a lot for your review and valuable comments. > >All, please see inline for some considerations to address the comments, >adding to Sri's feedback. > > >>-----Original Message----- >>From: Brian Haberman [mailto:brian@innovationslab.net] >>Sent: Montag, 9. Dezember 2013 18:04 >>To: Sri Gundavelli (sgundave) >>Cc: Hidetoshi Yokota; jouni korhonen; Marco Liebsch; >>pierrick.seite@orange.com >>Subject: Re: FW: [netext] I-D Action: draft-ietf-netext-pmip6-qos-08.txt >> >>All, >> Here are my comments on this draft... >> >>1. Somewhere in the front matter of the draft, there should be some >>discussion >>as to why existing QoS signaling mechanisms are not used (e.g., RSVP). >> >>2. Section 2.2 refers to the Allocation and Retention Priority option as >>ARP and >>AARP. I assume AARP is a typo (but ARP is also an unfortunate >>overload...). > >Good point. I don't see an issue with deviating from the 3GPP term and >gain >advantage of the typo :-) to avoid confusion. What about naming the >attribute >AARP instead of ARP to abbreviate Allocation And Retention Priority? > >> >>3. Is there any expectation for infrastructure devices between the MAG >>and LMA >>to provide QoS services for these flows? If so, how? With the QoS >>information >>embedded in PMIP messages, how would these intermediate devices know >>anything about these QoS parameters and any associated Per-Hop-Behaviors? >>This needs some discussion in the draft to ensure a consistent >>deployment view. > >The expectation is to prioritize traffic according to the DSCP, which is >the >only carried per-packet classifier being understood by transport network >routers. Sect. 6 provides some clarification, but I agree that's a bit >late. >We could clarify in the introduction already what's the expectation from >LMA, MAG and transport network infrastructure to enable QoS >differentiation >by using the specified option and attributes. Will add this. > > >> >>4. Section 4.1 says that if M=3D1, D=3D0, but there is no discussion of w= hat >>to do if >>M=3DD=3D1 occurs. Is the option ignored? > >The spec mandates D to be cleared when M=3D1. We can treat M=3DD=3D1 as >violation >of the spec and reject QoS enforcement using the >CANNOT_MEET_QOS_SERVICE_REQUEST >status. Description of how to set the status to this value is solely >about failure in >supporting the requested QoS. If we adopt the above mechanism, the >protocol >operations section 6 must add description to set this status code in case >of >unambiguous flag settings. > > >> >>5. I am curious as to why a 5-bit Service Request ID is sufficient. You >>have bits >>available in the Resvd field... Wouldn't an 8-bit field make >>operations/comparisons easier? > >That would leave no space for additional flags in case such extension is >needed. >So far the format has a good packing style. If we want to align fields to >8 bit, e.g. to >enable easier decoding, we can consider 8 bit for flags (two are used), 8 >bit >for a Traffic Class field (6 used for the DS code point) and add the >service request >ID to another line of 32 bit, which gives us more space for the ID, but >implies >much reserved fields. >Sri, all, what do you think? According to your description 5 bit are >sufficient. >Preferences to keep the packing style? > >> >>6. Section 4.2 only describes bit-rate-based attributes. Is this due to >>use cases >>described in other SDOs? >> >>7. What is the handling if there is a conflict between a per-node QoS >>attribute >>and a set of per-flow QoS attributes associated with that node? > >We'll add clarifying text according to Sri's feedback, > >Thanks, > >marco From sgundave@cisco.com Wed Dec 11 16:27:32 2013 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 12CA01ADFB4 for ; Wed, 11 Dec 2013 16:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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.001, 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 fvcdeX9WRuRD for ; Wed, 11 Dec 2013 16:27:29 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 22CB61A16F0 for ; Wed, 11 Dec 2013 16:27:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25281; q=dns/txt; s=iport; t=1386808044; x=1388017644; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=iQYxUCjeQhfkpW8SwtkUZSDjYIkBK1m1ilFKvgBXC2Q=; b=DA7m+6kTvX2pzbCbrdflixxW2Af3IGUU/OP8Xfm0MHIMZWu8m2/L4+tP YuerHwejUd3W9GtZgQ6mBx+IOU93k9wxB43spDjEX2jkzkJevawr4DjGY cGz/lSWkPirTD1jKOnnwN+UTiM0gcNV0ey8D1DkBLSGKldp6Im16AKN12 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FANMBqVKtJXG//2dsb2JhbABZgkNEgQu5ToEbFnSCJQECBGwKFQEIEQMBAiEHKBEUBwEBBQMCBBOHcAMPozCXZA2HEheMdYICFwGENASWKYFrjFqFOYMpgio X-IronPort-AV: E=Sophos;i="4.93,874,1378857600"; d="scan'208,217";a="290996698" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 12 Dec 2013 00:27:23 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rBC0RMpK023745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 12 Dec 2013 00:27:22 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.155]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Wed, 11 Dec 2013 18:27:22 -0600 From: "Sri Gundavelli (sgundave)" To: "netext@ietf.org" Thread-Topic: [netext] I-D Action: draft-ietf-netext-pmip6-qos-08.txt Thread-Index: AQHO9tBP2K4bMyNxjUWlf15Bp+XbfJpPkq4A Date: Thu, 12 Dec 2013 00:27:22 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.212] Content-Type: multipart/alternative; boundary="_000_CECE4282F6E17sgundaveciscocom_" MIME-Version: 1.0 Subject: [netext] FW: I-D Action: draft-ietf-netext-pmip6-qos-08.txt 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: Thu, 12 Dec 2013 00:27:32 -0000 --_000_CECE4282F6E17sgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Additional response to Brian's feedback. From: Sri Gundavelli > Date: Wednesday, December 11, 2013 4:22 PM To: Marco Liebsch >= , Brian Haberman = > Cc: Hidetoshi Yokota >, jouni= korhonen >, "pierric= k.seite@orange.com" > Subject: Re: [netext] I-D Action: draft-ietf-netext-pmip6-qos-08.txt Marco/Brian Inline =85 On 12/11/13 3:13 AM, "Marco Liebsch" > wrote: Brian, thanks a lot for your review and valuable comments. All, please see inline for some considerations to address the comments, adding to Sri's feedback. 2. Section 2.2 refers to the Allocation and Retention Priority option as AR= P and AARP. I assume AARP is a typo (but ARP is also an unfortunate overload...)= . Good point. I don't see an issue with deviating from the 3GPP term and gain advantage of the typo :-) to avoid confusion. What about naming the attribu= te AARP instead of ARP to abbreviate Allocation And Retention Priority? We had the typo in the Terminology section as well, keeping it consistent a= cross, but Yokota-san fixed it :) 4. Section 4.1 says that if M=3D1, D=3D0, but there is no discussion of wha= t to do if M=3DD=3D1 occurs. Is the option ignored? The spec mandates D to be cleared when M=3D1. We can treat M=3DD=3D1 as vio= lation of the spec and reject QoS enforcement using the CANNOT_MEET_QOS_SERVICE_RE= QUEST status. Description of how to set the status to this value is solely about = failure in supporting the requested QoS. If we adopt the above mechanism, the protocol operations section 6 must add description to set this status code in case o= f unambiguous flag settings. Its a pain to define error codes for this flag combination and document the= m. May be as Carlos suggested, we combine the D and M flags into a 2 bit numbe= r. 1 - Create 2 - Delete 3 - Modify 0 - Reserved - Receiver will ignore; Or allow the sender to set to 0 when r= e-negotiating a QoS proposal with a counter proposal 5. I am curious as to why a 5-bit Service Request ID is sufficient. You ha= ve bits available in the Resvd field... Wouldn't an 8-bit field make operations/comparisons easier? That would leave no space for additional flags in case such extension is ne= eded. So far the format has a good packing style. If we want to align fields to 8= bit, e.g. to enable easier decoding, we can consider 8 bit for flags (two are used), 8 b= it for a Traffic Class field (6 used for the DS code point) and add the servic= e request ID to another line of 32 bit, which gives us more space for the ID, but imp= lies much reserved fields. Sri, all, what do you think? According to your description 5 bit are suffic= ient. Preferences to keep the packing style? I think this is a good suggestion. Works for me This should address Brian's= concern. Yokota-san/Jouni/Pierrick/ ? OLD: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |D|M|Resvd| ID | DSCP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ QoS Attribute(s) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NEW: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | ID | TC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D|M| Resvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ QoS Attribute(s) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6. Section 4.2 only describes bit-rate-based attributes. Is this due to us= e cases described in other SDOs? 7. What is the handling if there is a conflict between a per-node QoS attri= bute and a set of per-flow QoS attributes associated with that node? We'll add clarifying text according to Sri's feedback, We can define a new QoS error code and handle this. Brian - We are going to this last update and hopefully we got a head-start = here with respect to your reviews. We hope to see this doc in IESG by Jan. Regards Sri --_000_CECE4282F6E17sgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5EA047750D10CA4797354709CB343D8A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Additional response to Brian's feedback. 



From: Sri Gundavelli <sgundave@cisco.com>
Date: Wednesday, December 11, 2013 = 4:22 PM
To: Marco Liebsch <Marco.Liebsch@neclab.eu>, Brian Haberm= an <brian@innovationslab.net= >
Cc: Hidetoshi Yokota <yokota@kddilabs.jp>, jouni korhonen <= jouni.nospam@gmail.com>, &= quot;pierrick.seite@orange.com= " <pierrick.seite@orange.com= >
Subject: Re: [netext] I-D Action: d= raft-ietf-netext-pmip6-qos-08.txt

Marco/Brian

Inline =85


On 12/11/13 3:13 AM, "Marco Liebsch" <Marco.Liebsch@neclab.eu> wrote:


2. Section 2.2 refers to the Allocation and Retention Priority option = as ARP and
AARP.  I assume AARP is a typo (but ARP is also an unfortuna= te overload...).

Good point. I don't see an issue with deviating from the 3GPP term and= gain
advantage of the typo :-) to avoid confusion. What about naming the at= tribute
AARP instead of ARP to abbreviate Allocation And Retention Priority?


We had the typo in the Termin= ology section as well, keeping it consistent across, but Yokota-san fixed i= t :)



4. Section 4.1 says that if M=3D1, D=3D0, but there is no discussion o= f what to do if
M=3DD=3D1 occurs.  Is the option ignored?

The spec mandates D to be cleared when M=3D1. We can treat M=3DD=3D1 a= s violation
of the spec and reject QoS enforcement using the CANNOT_MEET_QOS_SERVI= CE_REQUEST
status. Description of how to set the status to this value is solely a= bout failure in
supporting the requested QoS. If we adopt the above mechanism, the pro= tocol
operations section 6 must add description to set this status code in c= ase of
unambiguous flag settings.



Its a pain to define error co= des for this flag combination and document them.
May be as Carlos suggested, w= e combine the D and M flags into a 2 bit number. 

1 - Create
2 - Delete
3 - Modify
0 - Reserved - R= eceiver will ignore; Or allow the sender to set to 0 when re-negotiating a = QoS proposal with a counter proposal




5. I am curious as to why a 5-bit Service Request ID is sufficient.&nb= sp; You have bits
available in the Resvd field... Wouldn't an 8-bit field make
operations/comparisons easier?

That would leave no space for additional flags in case such extension = is needed.
So far the format has a good packing style. If we want to align fields= to 8 bit, e.g. to
enable easier decoding, we can consider 8 bit for flags (two are used)= , 8 bit
for a Traffic Class field (6 used for the DS code point) and add the s= ervice request
ID to another line of 32 bit, which gives us more space for the ID, bu= t implies
much reserved fields.
Sri, all, what do you think? According to your description 5 bit are s= ufficient.
Preferences to keep the packing style?


I think this is a good sugges= tion. Works for me This should address Brian's concern.

Yokota-san/Jouni/Pierrick/ ?<= /b>


OLD:

 0             &= nbsp;     1               &nbs= p;   2                   = 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2= 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+
|      Type     |   L= ength      |D|M|Resvd|    ID   |   DSCP =    |
+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+
~               =     QoS Attribute(s)             &n= bsp;              ~
+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+


NEW:

 0             &= nbsp;     1               &nbs= p;   2                   = 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2= 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+
|      Type     |   L= ength      |       ID      | &= nbsp;     TC      |
+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+
|D|M|             &nb= sp;           Resvd         &n= bsp;                   | =
+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+
~               =     QoS Attribute(s)             &n= bsp;              ~
+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+







6. Section 4.2 only describes bit-rate-based attributes.  Is= this due to use cases
described in other SDOs?

7. What is the handling if there is a conflict between a per-node QoS = attribute
and a set of per-flow QoS attributes associated with that node?

We'll add clarifying text according to Sri's feedback,


We can define a new QoS error= code and handle this.

Brian - We are going to this = last update and hopefully we got a head-start here with respect to your rev= iews. We hope to see this doc in IESG by Jan.


Regards
Sri




--_000_CECE4282F6E17sgundaveciscocom_-- From internet-drafts@ietf.org Wed Dec 18 14:21:37 2013 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 A102F1AC4A3; Wed, 18 Dec 2013 14:21:37 -0800 (PST) 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 x9wSNxbp0BJK; Wed, 18 Dec 2013 14:21:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6B31A1F19; Wed, 18 Dec 2013 14:21:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.84 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131218222132.12571.32621.idtracker@ietfa.amsl.com> Date: Wed, 18 Dec 2013 14:21:32 -0800 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pd-pmip-14.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: Wed, 18 Dec 2013 22:21:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Working= Group of the IETF. Title : Prefix Delegation Support for Proxy Mobile IPv6 Author(s) : Xingyue Zhou Jouni Korhonen Carl Williams Sri Gundavelli Carlos J. Bernardos Filename : draft-ietf-netext-pd-pmip-14.txt Pages : 27 Date : 2013-12-18 Abstract: This specification defines extensions to the Proxy Mobile IPv6 protocol for allowing a mobile router in a Proxy Mobile IPv6 domain to obtain IP prefixes for its attached mobile networks using DHCPv6 prefix delegation. Network-based mobility management support is provided for those delegated IP prefixes just as it is provided for the mobile node's home address. Even if the mobile router performs a handoff and changes its network point of attachment, mobility support is ensured for all the delegated IP prefixes and for all the IP nodes in the mobile network that use IP address configuration from those delegated IP prefixes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pd-pmip There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pd-pmip-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-pd-pmip-14 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 internet-drafts@ietf.org Thu Dec 19 09:22:19 2013 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 F2B6A1AE1D5; Thu, 19 Dec 2013 09:22:18 -0800 (PST) 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 MyDubTVBXaGb; Thu, 19 Dec 2013 09:22:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E97661AE1CB; Thu, 19 Dec 2013 09:22:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.84 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131219172215.14002.34972.idtracker@ietfa.amsl.com> Date: Thu, 19 Dec 2013 09:22:15 -0800 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmip6-qos-09.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, 19 Dec 2013 17:22:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Working= Group of the IETF. Title : Quality of Service Option for Proxy Mobile IPv6 Author(s) : Marco Liebsch Pierrick Seite Hidetoshi Yokota Jouni Korhonen Sri Gundavelli Filename : draft-ietf-netext-pmip6-qos-09.txt Pages : 67 Date : 2013-12-19 Abstract: This specification defines a new mobility option, the Quality of Service (QoS) option, for Proxy Mobile IPv6. This option can be used by the local mobility anchor and the mobile access gateway for negotiating Quality of Service parameters for a mobile node's IP flows. The negotiated QoS parameters can be used for QoS policing and marking 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 mobile access gateway enables mapping of these parameters to QoS rules that are specific to the access technology and allows those rules to be enforced on the access network using access technology specific approaches. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmip6-qos There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pmip6-qos-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-pmip6-qos-09 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 sgundave@cisco.com Thu Dec 19 15:14:40 2013 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 244EC1AEC15 for ; Thu, 19 Dec 2013 15:14:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.038 X-Spam-Level: X-Spam-Status: No, score=-15.038 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.538, 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 6NvWkIjZlCfs for ; Thu, 19 Dec 2013 15:14:37 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4791A9313 for ; Thu, 19 Dec 2013 15:14:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9109; q=dns/txt; s=iport; t=1387494876; x=1388704476; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=USHstl15EXb/uMSF1ydl4my9JQzsEdnHN9GlqQRbfDI=; b=JpgtNBLC2qurOTgJORb8bmTvXKgQ4VAcUQtpdNdvpCS0s0VeDXQTgID4 C1sFFFU8XReOjSgyRIACxKf4HUcpnKukv0pdkYCj7/Tu/iCZdAZGaJBcu 2kSWrYGh1YZ+hxPEaMEYxuI34Zih5nRTyX2co3FglYesVg8icL/4uzhc/ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAId9s1KtJXG9/2dsb2JhbABZgkdEOFW5MIEWFnSCJQECBIELAQgSZhcEAQYDAgQBG4d7Dcp5F48ZhDYEmBaSFIMrgio X-IronPort-AV: E=Sophos;i="4.95,516,1384300800"; d="scan'208,217";a="292784738" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 19 Dec 2013 23:14:23 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rBJNEMKt002757 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Dec 2013 23:14:22 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.155]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Thu, 19 Dec 2013 17:14:22 -0600 From: "Sri Gundavelli (sgundave)" To: "netext@ietf.org" , Brian Haberman Thread-Topic: [netext] I-D Action: draft-ietf-netext-pmip6-qos-08.txt Thread-Index: AQHO9tBP2K4bMyNxjUWlf15Bp+XbfJpQrGEAgAAUbwCAAYGsgIAE/80AgABeKACAAiuoAIAB5RQAgABfwYA= Date: Thu, 19 Dec 2013 23:14:22 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.211] Content-Type: multipart/alternative; boundary="_000_CED8BCF9F99D9sgundaveciscocom_" MIME-Version: 1.0 Subject: [netext] FW: I-D Action: draft-ietf-netext-pmip6-qos-08.txt 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: Thu, 19 Dec 2013 23:14:40 -0000 --_000_CED8BCF9F99D9sgundaveciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Brian, We have posted the 09 version of the document. Based on your review feedbac= k and discussion, we have updated the draft. Please let us know if you hav= e any further comments. http://www.ietf.org/internet-drafts/draft-ietf-netext-pmip6-qos-09.txt Regards Sri 1. Somewhere in the front matter of the draft, there should be some discussion as to why existing QoS signaling mechanisms are not used (e.g., RSVP). [Authors] We have added some text on the overall QoS architecture, base li= ne assumptions and the scope of the work. 2. Section 2.2 refers to the Allocation and Retention Priority option as ARP and AARP. I assume AARP is a typo (but ARP is also an unfortunate overload...). [Authors] We now use the term AARP consistently 3. Is there any expectation for infrastructure devices between the MAG and LMA to provide QoS services for these flows? If so, how? With the QoS information embedded in PMIP messages, how would these intermediate devices know anything about these QoS parameters and any associated Per-Hop-Behaviors? This needs some discussion in the draft to ensure a consistent deployment view. [Authors] Captured in the intro section on the end-to-end DiffServ architec= tural assumption 4. Section 4.1 says that if M=3D1, D=3D0, but there is no discussion of wha= t to do if M=3DD=3D1 occurs. Is the option ignored? [Authors] We got rid of the flags and used a opcode int field. 5. I am curious as to why a 5-bit Service Request ID is sufficient. You have bits available in the Resvd field... Wouldn't an 8-bit field make operations/comparisons easier? [Authors] We also re-worked the QoS option per your recommendations/comment= s 6. Section 4.2 only describes bit-rate-based attributes. Is this due to use cases described in other SDOs? [Authors] No change. 7. What is the handling if there is a conflict between a per-node QoS attribute and a set of per-flow QoS attributes associated with that node? [Authors] The peer can renegotiate the QoS proposal, by sending a downgrade= d profile. --_000_CED8BCF9F99D9sgundaveciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <6AECFB37082ED346B16F18B642AB71A3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Brian,

We have posted the 09 version of the document. Based on your review fe= edback and discussion, we have updated the draft.  Please let us know = if you have any further comments.


Regards
Sri






1. Somewhere in t= he front matter of the draft, there should be some
discussion as to = why existing QoS signaling mechanisms are not used
(e.g., RSVP).

[Authors] We have= added some text on the overall  QoS architecture, base line assumptio= ns and the scope of the work.


2. Section 2.2 re= fers to the Allocation and Retention Priority option as
ARP and AARP.&nbs= p; I assume AARP is a typo (but ARP is also an unfortunate
overload...).

[Authors] We now = use the term AARP consistently


3. Is there any e= xpectation for infrastructure devices between the MAG
and LMA to provid= e QoS services for these flows?  If so, how?  With the<= /div>
QoS information e= mbedded in PMIP messages, how would these intermediate
devices know anyt= hing about these QoS parameters and any associated
Per-Hop-Behaviors= ?  This needs some discussion in the draft to ensure a
consistent deploy= ment view.

[Authors] Capture= d in the intro section on the end-to-end DiffServ architectural assumption<= /div>


4. Section 4.1 sa= ys that if M=3D1, D=3D0, but there is no discussion of what
to do if M=3DD=3D= 1 occurs.  Is the option ignored?

[Authors] We= got rid of the flags and used a opcode int field. 


5. I am curious a= s to why a 5-bit Service Request ID is sufficient.  You
have bits availab= le in the Resvd field... Wouldn't an 8-bit field make
operations/compar= isons easier?

[Authors] We= also re-worked the QoS option per your recommendations/comments


6. Section 4.2 on= ly describes bit-rate-based attributes.  Is this due to
use cases describ= ed in other SDOs?

[Authors] No chan= ge. 


7. What is the ha= ndling if there is a conflict between a per-node QoS
attribute and a s= et of per-flow QoS attributes associated with that node?

[Authors] The peer can renegotiate the QoS proposal, by sen= ding a downgraded profile. 



--_000_CED8BCF9F99D9sgundaveciscocom_-- From internet-drafts@ietf.org Wed Dec 25 11:00:38 2013 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 87BFA1AE047; Wed, 25 Dec 2013 11:00:38 -0800 (PST) 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 IgLhRlrL0Ztq; Wed, 25 Dec 2013 11:00:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B83A1AE031; Wed, 25 Dec 2013 11:00:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131225190037.7049.85961.idtracker@ietfa.amsl.com> Date: Wed, 25 Dec 2013 11:00:37 -0800 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmip6-qos-10.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: Wed, 25 Dec 2013 19:00:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network-Based Mobility Extensions Working= Group of the IETF. Title : Quality of Service Option for Proxy Mobile IPv6 Authors : Marco Liebsch Pierrick Seite Hidetoshi Yokota Jouni Korhonen Sri Gundavelli Filename : draft-ietf-netext-pmip6-qos-10.txt Pages : 67 Date : 2013-12-25 Abstract: This specification defines a new mobility option, the Quality of Service (QoS) option, for Proxy Mobile IPv6. This option can be used by the local mobility anchor and the mobile access gateway for negotiating Quality of Service parameters for a mobile node's IP flows. The negotiated QoS parameters can be used for QoS policing and marking 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 mobile access gateway enables mapping of these parameters to QoS rules that are specific to the access technology and allows those rules to be enforced on the access network using access technology specific approaches. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmip6-qos/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pmip6-qos-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-pmip6-qos-10 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 jonghyouk@gmail.com Mon Dec 30 05:07:07 2013 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 000BA1AE001 for ; Mon, 30 Dec 2013 05:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 BxuChjHj1h4A for ; Mon, 30 Dec 2013 05:07:04 -0800 (PST) Received: from mail-vb0-x235.google.com (mail-vb0-x235.google.com [IPv6:2607:f8b0:400c:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 268841ADFDD for ; Mon, 30 Dec 2013 05:07:04 -0800 (PST) Received: by mail-vb0-f53.google.com with SMTP id o19so5891296vbm.12 for ; Mon, 30 Dec 2013 05:06:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wZXwnGp02jLTnePKDD2IXgk7jBvbTb4BhMhI7uT5ack=; b=FUHU4Oeie43b0bXJKO9npMnzztJJ+fSvGgOUtoiLLl/e1M5eV5Ji49qugASkEnZ/9r 05CXcVMYqzhtzddlKKlzPAP7cnDqpEzi3oypsOmNOFX998domKY88wrMh6CSgdwV4xac yW7Jl3PEs3W2ExAMjLq6UYIHVO3zvDkVEgQ/v0x45bIXkpHrLuESi50rW2LuF5jpPB/W Doyfj6XWHyQK9EgHTLgGmjw2vsy5VJ1Adcq6T8zcU9sACdOfiaNCnqh4WvCdweMThCPP FQT/b/IN8dzGuewpUdDQp5cGsEzl+lOpZL3djoIDdnd0M32ekBcayC10ABfSL1cJioCS jNtw== MIME-Version: 1.0 X-Received: by 10.58.4.70 with SMTP id i6mr1694873vei.27.1388408818103; Mon, 30 Dec 2013 05:06:58 -0800 (PST) Received: by 10.58.46.207 with HTTP; Mon, 30 Dec 2013 05:06:58 -0800 (PST) In-Reply-To: <20131225190037.7049.85961.idtracker@ietfa.amsl.com> References: <20131225190037.7049.85961.idtracker@ietfa.amsl.com> Date: Mon, 30 Dec 2013 22:06:58 +0900 Message-ID: From: Jong-Hyouk Lee To: Sri Gundavelli Content-Type: multipart/alternative; boundary=001a1136b3a667fb9504eec01e23 Cc: netext@ietf.org Subject: Re: [netext] I-D Action: draft-ietf-netext-pmip6-qos-10.txt 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: Mon, 30 Dec 2013 13:07:07 -0000 --001a1136b3a667fb9504eec01e23 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Sri...I read the draft: draft-ietf-netext-pmip6-qos-10 This document is well organized and describes what we need for QoS packet marking on the path between the LMA and MAG. Let me give only some editorial comments. Kindly consider. Thx. Editorial comments: In p4, I suppose the following =E2=80=9C=E2=80=A6 whereas inter-working wit= h the cellular architecture to establish QoS policies in alternative access networks has not received much attention so far.=E2=80=9D should be revised as there are= many research expressing attention. Just standardisation work is needed for this and you are now doing. In p4, "for mobile nodes (MN)." -> for mobile nodes (MNs)." In p4, "and on the mobile access gateway and its access network for the uplink traffic.=E2=80=9D -> "and on the mobile access gateway for the uplin= k traffic.=E2=80=9D In p5, =E2=80=9Cfor this IP session.=E2=80=9D -> =E2=80=9Cfor the mobile no= de=E2=80=99s traffic=E2=80=9D In p6, "Additionally, this document uses the following abbreviations:=E2=80= =9D -> "Additionally, this document uses the following terminologies (or definitions):=E2=80=9D In p7, "anchor is referred to as the Downlink traffic.=E2=80=9D -> "anchor = are referred to as the Downlink traffic.=E2=80=9D In p7, "anchor is referred to as the Uplink traffic.=E2=80=9D -> "anchor ar= e referred to as the Uplink traffic.=E2=80=9D In p7, =E2=80=9CEach of those services provide=E2=80=9D -> =E2=80=9CEach of= those services provides=E2=80=9D In p9, "The Quality of Service support=E2=80=9D -> "The Quality of Service = (QoS) support=E2=80=9D In p9, "Differentiated-Services architecture=E2=80=9D -> "Differentiated-Se= rvices (DiffServ) architecture=E2=80=9D In p9, =E2=80=9CThe access and the home network=E2=80=9D -> =E2=80=9CThe ac= cess and home networks=E2=80=9D In p9, "between the access and the home network=E2=80=9D -> "between the ac= cess network and the home network=E2=80=9D In p9, "These entities being=E2=80=9D -> "These mobility entities being=E2= =80=9D In p9, "at these nodes.=E2=80=9D -> "at the mobility entities.=E2=80=9D In p9, =E2=80=9Cnegotiate the Quality of Service parameters=E2=80=9D -> "ne= gotiate the QoS parameters=E2=80=9D In p9, =E2=80=9CQoS service negotiation.=E2=80=9D -> =E2=80=9CQoS negotiati= on.=E2=80=9D In p9, "the type of QoS services that are to be enabled for a mobile node= =E2=80=9D -> "the type of QoS that is enabled for a mobile node=E2=80=9D In p9, "for providing QoS service differentiation on the path=E2=80=9D -> "= for providing the DiffServ on the path=E2=80=9D In p9, "The signaling related to QoS services is strictly between the mobility entities and does not result=E2=80=9D -> =E2=80=9CThe signaling ex= tensions defined in this document are strictly applied into the mobile node=E2=80=99s traffi= c between the mobility entities and do not result=E2=80=9D On Thu, Dec 26, 2013 at 4:00 AM, wrote: > > 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 : Quality of Service Option for Proxy Mobile IPv6 > Authors : Marco Liebsch > Pierrick Seite > Hidetoshi Yokota > Jouni Korhonen > Sri Gundavelli > Filename : draft-ietf-netext-pmip6-qos-10.txt > Pages : 67 > Date : 2013-12-25 > > Abstract: > This specification defines a new mobility option, the Quality of > Service (QoS) option, for Proxy Mobile IPv6. This option can be used > by the local mobility anchor and the mobile access gateway for > negotiating Quality of Service parameters for a mobile node's IP > flows. The negotiated QoS parameters can be used for QoS policing > and marking 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 mobile access > gateway enables mapping of these parameters to QoS rules that are > specific to the access technology and allows those rules to be > enforced on the access network using access technology specific > approaches. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netext-pmip6-qos/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-netext-pmip6-qos-10 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-pmip6-qos-10 > > > 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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > --=20 Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random #email: jonghyouk (at) gmail (dot) com #webpage: http://sites.google.com/site/hurryon/ --001a1136b3a667fb9504eec01e23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Sri...I read the draft: draft-ietf-netext-pmip6-q= os-10

This document is well organized and describe= s what we need for QoS packet marking on the path between the LMA and MAG. = Let me give only some editorial comments. Kindly consider. Thx.

Editorial comments:

In p4, I s= uppose the following =E2=80=9C=E2=80=A6 whereas inter-working with the cell= ular architecture to establish QoS policies in alternative access networks = has not received much attention so far.=E2=80=9D should be revised as there= are many research expressing attention. Just standardisation work is neede= d for this and you are now doing.

In p4, "for mobile nodes (MN)." -> for mob= ile nodes (MNs)."

In p4, "and on the mob= ile access gateway and its access network for the uplink traffic.=E2=80=9D = -> "and on the mobile access gateway for the uplink traffic.=E2=80= =9D

In p5, =E2=80=9Cfor this IP session.=E2=80=9D -> =E2= =80=9Cfor the mobile node=E2=80=99s traffic=E2=80=9D

In p6, "Additionally, this document uses the following abbreviation= s:=E2=80=9D -> "Additionally, this document =C2=A0 =C2=A0uses the f= ollowing terminologies (or definitions):=E2=80=9D

In p7, "anchor is referred to as the Downlink traf= fic.=E2=80=9D -> "anchor are referred to as the Downlink traffic.= =E2=80=9D

In p7, "anchor is referred to as th= e Uplink traffic.=E2=80=9D -> "anchor are referred to as the Uplink= traffic.=E2=80=9D

In p7, =E2=80=9CEach of those services provide=E2=80=9D= -> =E2=80=9CEach of those services provides=E2=80=9D

In p9, "The Quality of Service support=E2=80=9D -> "The= Quality of Service (QoS) support=E2=80=9D

In p9, "Differentiated-Services architecture=E2=80= =9D -> "Differentiated-Services (DiffServ) architecture=E2=80=9D

In p9, =E2=80=9CThe access and the home network=E2= =80=9D -> =E2=80=9CThe access and home networks=E2=80=9D

In p9, "between the access and the home network=E2= =80=9D -> "between the access network and the home network=E2=80=9D=

In p9, "These entities being=E2=80=9D -> = "These mobility entities being=E2=80=9D

In p9, "at these nodes.=E2=80=9D -> "at th= e mobility entities.=E2=80=9D

In p9, =E2=80=9Cnego= tiate the Quality of Service parameters=E2=80=9D -> "negotiate the = QoS parameters=E2=80=9D

In p9, =E2=80=9CQoS service negotiation.=E2=80=9D -> =E2=80= =9CQoS negotiation.=E2=80=9D

In p9, "the type= of QoS services that are to be enabled for a mobile node=E2=80=9D -> &q= uot;the type of QoS that is enabled for a mobile node=E2=80=9D

In p9, "for providing QoS service differentiation = on the path=E2=80=9D -> "for providing the DiffServ on the path=E2= =80=9D

In p9, "The signaling related to QoS s= ervices is strictly between the mobility entities and does not result=E2=80= =9D -> =E2=80=9CThe signaling extensions defined in this document are st= rictly applied into the mobile node=E2=80=99s traffic between the mobility = entities =C2=A0and do not result=E2=80=9D=C2=A0



On Thu, Dec 26, 2013 at 4:00 AM, <internet-drafts@ietf.org&g= t; wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Network-Based Mobility Extensions Wo= rking Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Qual= ity of Service Option for Proxy Mobile IPv6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Marco Lie= bsch
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Pierrick Seite
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Hidetoshi Yokota
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Jouni Korhonen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Sri Gundavelli
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-iet= f-netext-pmip6-qos-10.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 67 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2013-12-25

Abstract:
=C2=A0 =C2=A0This specification defines a new mobility option, the Quality = of
=C2=A0 =C2=A0Service (QoS) option, for Proxy Mobile IPv6. =C2=A0This option= can be used
=C2=A0 =C2=A0by the local mobility anchor and the mobile access gateway for=
=C2=A0 =C2=A0negotiating Quality of Service parameters for a mobile node= 9;s IP
=C2=A0 =C2=A0flows. =C2=A0The negotiated QoS parameters can be used for QoS= policing
=C2=A0 =C2=A0and marking of packets to enforce QoS differentiation on the p= ath
=C2=A0 =C2=A0between the local mobility anchor and the mobile access gatewa= y.
=C2=A0 =C2=A0Furthermore, making QoS parameters available on the mobile acc= ess
=C2=A0 =C2=A0gateway enables mapping of these parameters to QoS rules that = are
=C2=A0 =C2=A0specific to the access technology and allows those rules to be=
=C2=A0 =C2=A0enforced on the access network using access technology specifi= c
=C2=A0 =C2=A0approaches.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netext-pmip6-q= os/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-netext-pmip6-qos-10<= br>
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netext-p= mip6-qos-10


Please note that it may take a couple of minutes from the time of submissio= n
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/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt



--
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/rando= m

#email:=C2=A0jonghyouk (at) gmail (dot) com<= /div>
--001a1136b3a667fb9504eec01e23--