From charliep@computer.org Sat Feb 1 18:55:40 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 9EE6B1A0029 for ; Sat, 1 Feb 2014 18:55:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.654 X-Spam-Level: ** X-Spam-Status: No, score=2.654 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_ASCII_ART_SPACINGc=0.833, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 UuGafOzriIYy for ; Sat, 1 Feb 2014 18:55:30 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id C32741A0027 for ; Sat, 1 Feb 2014 18:55:28 -0800 (PST) Received: from [99.51.72.196] (helo=[192.168.1.81]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1W9nDI-0000Va-1p; Sat, 01 Feb 2014 21:55:17 -0500 Message-ID: <52EDB392.7050300@computer.org> Date: Sat, 01 Feb 2014 18:55:14 -0800 From: "Charles E. Perkins" Organization: Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------030606030902070108040903" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8691b0e6a76c902320d6f655d38250c554350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Cc: netext@ietf.org, draft-ietf-netext-pmip6-qos@tools.ietf.org Subject: Re: [netext] WGLC for I-D: draft-ietf-netext-pmip6-qos 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: Sun, 02 Feb 2014 02:55:40 -0000 This is a multi-part message in MIME format. --------------030606030902070108040903 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hello folks, I didn't have time for a complete review, but I did make the following notes. ================================================== Suggestion: use Kb/sec or at least bytes/sec as the units. With 802.11ac, we are already over the limit of what 32 bits can measure for transmission rates measured in bits/sec. Terminology should be alphabetized. The term "sub-options" is never used. Should use abbreviations LMA and MAG most of the time after introducing them and citing RFC 5213. 5213 uses them most of the time, why not this document? What about Quality of Service Attribute types 12 through 254 in section 4.2? In section 4.2.5. Allocation and Retention Priority, it is not clear why Priority-Level, Preemption-Capability, and Preemption-Vulnerability are defined to take up 64 bits, when all the values that have been defined would easily fit within less than half of the Reserved field. Perhaps some justification is indicated for this design. Worse yet, there is absolutely no hint to the implementer about how the features are to be used. If there is some other document available for this purpose, it should be cited. Otherwise, some additional description is required in this document. In section 4.2.10. QoS Traffic Selector, the format of the Traffic Selector is *NOT* opaque. It follows the specifications cited in the previous paragraph, right?? ============================================================= I made a few editorial improvements, which can be seen as shown in the attached file. Sorry, for some reason I can't get rfcdiff to work right now. Regards, Charlie P. On 1/30/2014 1:24 AM, Ryuji Wakikawa wrote: > Raj, > > I don’t see any issue in this version. > The draft is ready for publication. > > thanks > ryuji > > 2014/01/23 午前8:33、Basavaraj Patil のメール： > >> Hello, >> >> This is the WG last call for the I-D: Quality of Service Option for >> Proxy Mobile IPv6 >> >> 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 I-D is intended for publication as a proposed standard. >> The deadline for receiving reviews, comments, feedback is February 7th, >> 2014. >> >> Please send your review comments to the mailing list, chairs or, >> authors. >> >> -Chairs >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext -- Regards, Charlie P. --------------030606030902070108040903 Content-Type: text/plain; charset=windows-1252; name="draft-ietf-netext-pmip6-qos-10cep.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-netext-pmip6-qos-10cep.txt" Comments: Suggestion: use Kb/sec or at least bytes/sec as the units. With 802.11ac, we are already over the limit of what 32 bits can measure for transmission rates measured in bits/sec. Terminology should be alphabetized. The term "sub-options" is never used. Should use abbreviations LMA and MAG most of the time after introducing them and citing RFC 5213. 5213 uses them most of the time, why not this document? What about Quality of Service Attribute types 12 through 254 in section 4.2? In section 4.2.5. Allocation and Retention Priority, it is not clear why Priority-Level, Preemption-Capability, and Preemption-Vulnerability are defined to take up 64 bits, when all the values that have been defined would easily fit within less than half of the Reserved field. Perhaps some justification is indicated for this design. Worse yet, there is absolutely no hint to the implementer about how the features are to be used. If there is some other document available for this purpose, it should be cited. Otherwise, some additional description is required in this document. In section 4.2.10. QoS Traffic Selector, the format of the Traffic Selector is *NOT* opaque. It follows the specifications cited in the previous paragraph, right?? NETEXT WG M. Liebsch Internet-Draft NEC Intended status: Standards Track P. Seite Expires: June 28, 2014 Orange H. Yokota KDDI Lab J. Korhonen Broadcom Communications S. Gundavelli Cisco December 25, 2013 Quality of Service Option for Proxy Mobile IPv6 draft-ietf-netext-pmip6-qos-10.txt 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. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 28, 2014. Liebsch, et al. Expires June 28, 2014 [Page 1] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Liebsch, et al. Expires June 28, 2014 [Page 2] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 7 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 3. Overview of QoS Support in Proxy Mobile IPv6 . . . . . . . . . 10 3.1. Quality of Service Option - Usage Examples . . . . . . . . 12 4. Protocol Messaging Extensions . . . . . . . . . . . . . . . . 15 4.1. Quality of Service Option . . . . . . . . . . . . . . . . 15 4.2. Quality of Service Attribute . . . . . . . . . . . . . . . 17 4.2.1. Per Mobile Node Aggregate Maximum Downlink Bit Rate . 19 4.2.2. Per Mobile Node Aggregate Maximum Uplink Bit Rate . . 20 4.2.3. Per Mobility Session Aggregate Maximum Downlink Bit Rate . . . . . . . . . . . . . . . . . . . . . . . 21 4.2.4. Per Mobility Session Aggregate Maximum Uplink Bit Rate . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.2.5. Allocation and Retention Priority . . . . . . . . . . 25 4.2.6. Aggregate Maximum Downlink Bit Rate . . . . . . . . . 26 4.2.7. Aggregate Maximum Uplink Bit Rate . . . . . . . . . . 27 4.2.8. Guaranteed Downlink Bit Rate . . . . . . . . . . . . . 29 4.2.9. Guaranteed Uplink Bit Rate . . . . . . . . . . . . . . 30 4.2.10. QoS Traffic Selector . . . . . . . . . . . . . . . . . 31 4.2.11. QoS Vendor Specific Attribute . . . . . . . . . . . . 32 4.3. New Status Code for Proxy Binding Acknowledgement . . . . 33 4.4. New Notification Reason for Update Notification Message . 33 4.5. New Status Code for Update Notification Acknowledgement Message . . . . . . . . . . . . . . . . . 33 5. Protocol Considerations . . . . . . . . . . . . . . . . . . . 34 5.1. Local Mobility Anchor Considerations . . . . . . . . . . . 34 5.2. Mobile Access Gateway Considerations . . . . . . . . . . . 38 6. QoS Services in Integrated WLAN-3GPP Networks . . . . . . . . 42 6.1. Technical Scope and Procedure . . . . . . . . . . . . . . 42 6.2. Relevant QoS Attributes . . . . . . . . . . . . . . . . . 44 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 49 9. Security Considerations . . . . . . . . . . . . . . . . . . . 51 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52 Liebsch, et al. Expires June 28, 2014 [Page 3] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 11.1. Normative References . . . . . . . . . . . . . . . . . . . 53 11.2. Informative References . . . . . . . . . . . . . . . . . . 53 Appendix A. Information when implementing 3GPP QoS in IP transport network . . . . . . . . . . . . . . . . . . 55 A.1. Mapping tables . . . . . . . . . . . . . . . . . . . . . . 55 A.2. Use cases and protocol operations . . . . . . . . . . . . 56 A.2.1. Handover of existing QoS rules . . . . . . . . . . . . 56 A.2.2. Establishment of QoS rules . . . . . . . . . . . . . . 58 A.2.3. Dynamic Update to QoS Policy . . . . . . . . . . . . . 60 Appendix B. Information when implementing PMIP based QoS support with IEEE 802.11e . . . . . . . . . . . . . . 62 Appendix C. Information when implementing with a Broadband Network Gateway . . . . . . . . . . . . . . . . . . . 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67 Liebsch, et al. Expires June 28, 2014 [Page 4] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 1. Introduction Mobile operators deploy Proxy Mobile IPv6 (PMIPv6) [RFC5213] to enable network-based mobility management for mobile nodes (MN). Users can access Internet Protocol (IP) based services from their mobile device by using various radio access technologies. Current standardization effort considers strong QoS classification and enforcement for cellular radio access technologies. QoS policies are typically controlled by a policy control function, whereas the policies are enforced by one or more gateways in the infrastructure, such as the local mobility anchor and the mobile access gateway, as well as by access network elements. Policy control and QoS differentiation for access to the mobile operator network through alternative non-cellular access technologies is not yet considered, even though some of these access technologies are able to support QoS by appropriate traffic prioritization techniques. However, handover and IP Flow Mobility using alternative radio access technologies, such as IEEE802.16 and Wireless LAN according to the IEEE802.11 specification, are being considered by the standards [TS23.402], whereas inter-working with the cellular architecture to establish QoS policies in alternative access networks has not received much attention so far. In particular Wireless LAN (WLAN) has been identified as an alternative technology to complement cellular radio access. Since the 802.11e extension provides QoS extensions to WLAN, it is beneficial to apply QoS policies to WLAN access, which enables QoS classification of downlink as well as uplink traffic between a mobile node and its local mobility anchor. Three functional operations have been identified to accomplish this: (a) Maintaining QoS classification during a handover between cellular radio access and WLAN access by means of establishing QoS policies in the handover target access network, (b) mapping of QoS classes and associated policies between different access systems and (c) establishment of QoS policies for new data sessions/flows, which are initiated while using WLAN access. This document specifies an extension to the PMIPv6 protocol [RFC5213] to establish QoS policies for a mobile node's data traffic on the local mobility anchor and the mobile access gateway. QoS policies are conveyed in-band with PMIPv6 signaling using the specified QoS option and are enforced on the local mobility anchor for downlink traffic and on the mobile access gateway and its access network for the uplink traffic. The specified option allows association between Liebsch, et al. Expires June 28, 2014 [Page 5] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 IP session classification characteristics, such as a Differentiated Services Code Point (DSCP) [RFC2474], and the expected QoS class for this IP session. This document specifies fundamental QoS attributes which apply on a per mobile node, mobility session or on a per-flow basis. The specified attributes are not specific to any access technology, but are compatible with the Third Generation Partnership Project (3GPP) and IEEE 802.11 Wireless LAN QoS specifications. Additional QoS attributes can be specified and used with the QoS option, e.g. to represent more specific descriptions of latency constraints or jitter bounds. The specification of such additional QoS attributes as well as the handling of QoS policies between the mobile access gateway and the access network are out of scope for this specification. Liebsch, et al. Expires June 28, 2014 [Page 6] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 2. Conventions and Terminology 2.1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2.2. Terminology All the mobility related terms used in this document are to be interpreted as defined in the Proxy Mobile IPv6 specifications [RFC5213], [RFC5844], and [RFC7077]. Additionally, this document uses the following abbreviations: Differentiated Services Code Point (DSCP) In Differentiated Services Architecture [RFC2474], packets are classified and marked to receive a particular per-hop forwarding behavior on nodes along their path based on the marking present on the packet. This marking on IPv4 and IPv6 packets that defines a specific Per-hop behavior is known as DSCP. Refer to [RFC2474], [RFC2475] and [RFC4594] for a complete explanation. QoS Service Request A set of QoS parameters that are defined to be enforced on one or more mobile node's IP flows. The parameters at the minimum include a DSCP marking and additionally may include Guaranteed Bit Rate or Aggregate Maximum Bit Rate. The Quality of Service option defined in this document represents a QoS Service Request. Guaranteed Bit Rate (GBR) GBR denotes the assured bit-rate that will be provided by the network for a set of IP flows. It is assumed that the network reserves the resources for supporting the GBR parameter. Variants of the GBR term can be defined by limiting the scope of the target IP flows on which the GBR is applied to a mobile node, mobility session or flow direction. For example, Guaranteed Downlink Bit Rate and Guaranteed Uplink Bit Rate are used in this document. Aggregate Maximum Bit Rate (AMBR) AMBR defines the upper limit on the bit-rate that can be provided by the network for a set of IP flows. IP packets exceeding the AMBR limit will be discarded by the rate-shaping function where Liebsch, et al. Expires June 28, 2014 [Page 7] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 the AMBR parameter is enforced. Variants of AMBR term can be defined by restricting the target set of IP flows on which the AMBR is applied to a mobile node, mobility session or flow direction. Example of such definitions that are used in this document are, Per Mobile Node Aggregate Maximum Downlink Bit Rate, Per Mobile Node Aggregate Maximum Uplink Bit Rate, Per Mobility Session Aggregate Maximum Downlink Bit Rate, and Per Mobility Session Aggregate Maximum Uplink Bit Rate. Allocation and Retention Priority (AARP) AARP is used in congestion situations when there are no sufficient resources for meeting all services requests. It is used primarily by the Admission Control function to determine whether a particular service request must be rejected due to lack of resources, or if it must be rejected by preempting an existing low-priority service. Downlink (DL) Traffic The mobile node's IP packets that the mobile access gateway receives from the local mobility anchor is referred to as the Downlink traffic. The "Downlink" term used in the QoS attribute definition is always from the reference point of the mobile node and it implies traffic heading towards the mobile node. Uplink (UL) Traffic The mobile node's IP packets that the mobile access gateway forwards to the local mobility anchor is referred to as the Uplink traffic. The "Uplink" term used in the QoS attribute definitions is based on the reference point of the mobile node and "Uplink" implies traffic originating from the mobile node. Mobility Session The term mobility session, is defined in [RFC5213]. It refers to the creation or existence of state associated with the mobile node's mobility binding on the local mobility anchor and on the mobile access gateway. Service Identifier In some mobility architectures, multiple services within the same mobility service subscription are offered to a mobile node. Each of those services provide a specific service (examples: Internet Service, Voice Over IP Service) and has an identifier called Service Identifier. 3GPP APN (Access Point Name) is an example of Liebsch, et al. Expires June 28, 2014 [Page 8] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 a Service Identifier. Refer to [RFC5149] for the definition of the Service Identifier and the mobility option used for carrying the Service Identifier. Liebsch, et al. Expires June 28, 2014 [Page 9] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 3. Overview of QoS Support in Proxy Mobile IPv6 The Quality of Service support in Proxy Mobile IPv6 specified in this document is based on the Differentiated-Services architecture ([RFC2474] and [RFC2475]). The access and the home network in the Proxy Mobile IPv6 domain are assumed to be DiffServ enabled, with every network node in the forwarding path for the mobile node's IP traffic being Diffserv compliant. The per-hop behavior for providing differential treatment based on the DiffServ marking in the packet is assumed to be consistent throughout the Proxy Mobile IPv6 domain. The local mobility anchor in the home network and the mobile access gateway in the access network define the network boundary between the access and the home network. These entities being the entry and exit points for the mobile node's IP traffic are the logical choice for being the QoS enforcement points. The basic QoS primitives such as marking, metering, policing and rate-shaping on the mobile node's IP flows can be enforced at these nodes. The local mobility anchor and the mobile access gateway can negotiate the Quality of Service parameters for a mobile node's IP flows based on the signaling extensions defined in this document. The QoS services that can be enabled for a mobile node are for meeting both the quantitative performance requirements (such as Guaranteed Bit- Rate) and as well for realizing relative performance treatment by the ways of class-based differentiation. The subscriber's policy and the charging profile is a key consideration for the mobility entities in the QoS service negotiation. The decision on the type of QoS services that are to be enabled for a mobile node is based on the subscriber profile and based on available network resources. The negotiated QoS parameters are used for providing QoS service differentiation on the path between the local mobility anchor and the mobile access gateway. The signaling related to QoS services is strictly between the mobility entities and does not result in per- flow state, or signaling to any other node in the network. Liebsch, et al. Expires June 28, 2014 [Page 10] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 +=======+ | MN-1 | +=======+ | | | Flow-6 Flow-1<--(GBR: 64Kbps) | | Flow-4 | Flow-2 | | | | | Flow-1 | | | Flow-3 | | | |_|_| DSCP-X | | | ( )<--(Per-Session-AMBR: 1Mbps) : | | | | | | DSCP-Z : | | | | | : : | | | | | | +=====+ +==:=v+ | | | | '- -- - - - --| | | : o|--' | | | '- - --- - - -| | __ | v o|----' | '- - - - - - - -| | _--' '--_ | o--|------' | | ( Diffserv ) | | | MAG |=====( enabled )=====| LMA | | | (IP Network) | | ,- - - - - - - - -| | '--__--' | o|-- - -, ,- - -- - -- - -| | | o|--- , | | | ,- - - - -- -| | | o|--, | | | | +=====+ +====^+ | | | |_|_| : | | | ( _ _ )<--(Per-Session-AMBR: 2Mbps) : | | | | | | DSCP-Y | | | | | | | | | | | | | | | Flow-6 Flow-2 | | | | | | Flow-5 (MBR: 100Kbps) Flow-3 | | | Flow-4 (GBR: 64Kbps) Flow-5 | | | +=======+ | MN-2 | +=======+ Figure 1: QoS Support Figure 1 explains the support of QoS services in a Proxy Mobile IPv6 domain. The local mobility anchor and the mobile access gateway have negotiated QoS parameters for the mobility sessions belonging to MN-1 and MN-2. A Per-Session-AMBR of 1Mbps and 2 Mbps for MN-1 and MN-2 respectively. Furthermore, different IP flows from MN-1 and MN-2 are given different QoS service treatment. For example, a GBR of 64Kbps for Flow-1 and Flow-5 is assured, a DSCP marking enforcement of "Z" Liebsch, et al. Expires June 28, 2014 [Page 11] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 on Flow-6, and MBR of 100 Kbps on Flow-5; 3.1. Quality of Service Option - Usage Examples Use Case 1: Figure 2 explains a scenario where a local mobility anchor initiates a QoS service request to a mobile access gateway. +-----+ +-----+ +-----+ | MN | | MAG | | LMA | +-----+ +-----+ +-----+ | | | 1) |---- MN Attach ----| | 2) | |------ PBU ------->| 3) | |<----- PBA --------| | | | 4) | |o=================o| | | PMIPv6 Tunnel | | | | | (LMA initiates QoS Service Request) | 5) | |<----- UPN (QoS)---| | | | | (MAG proposes a revised QoS Request) | 6) | |------ UPA (QoS')->| | | | 7) | |<----- UPN (QoS')--| 8) | |------ UPA (QoS')->| | QoS Rules ---| | 9) | Established <-| | QoS Rules ---| 10) | ---| Established <-| | | | ---| 11) |<----------------->| | Figure 2: LMA Initiated QoS Service Request o (1) to (4): MAG detects the mobile node's attachment to the access link and initiates the signaling with the local mobility anchor. The LMA and MAG upon completing the signaling establish the mobility session and the forwarding state. o (5) to (8): The LMA initiates a QoS Service request to the mobile access gateway. The trigger for this service can be based on a trigger from a policy function and the specific details of that trigger are outside the scope of this document. The LMA sends an Update Notification message [RFC7077] to the MAG. The message includes the QoS option Section 4.1 which includes a set of QoS parameters. The mobile access gateway on determining that it cannot support the requested QoS service request for that mobile sends an revised QoS option in the Update Notification Liebsch, et al. Expires June 28, 2014 [Page 12] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 Acknowledgement message, which the LMA agrees to the proposed QoS parameters by sending a new Update Notification message with a modified QoS option. o (9) to (11): Upon successfully negotiating a QoS service request the MAG and the LMA install the QoS rules for that service request. Furthermore, the MAG (using access technology specific mechanisms) install the QoS rules on the access network. Use Case 2: Figure 3 explains a scenario where a mobile access gateway initiates a QoS service request to a local mobility anchor. +-----+ +-----+ +-----+ | MN | | MAG | | LMA | +-----+ +-----+ +-----+ | | | 1) |---- MN Attach ----| | 2) | |------ PBU ------->| 3) | |<----- PBA --------| | | | 4) | |o=================o| | | PMIPv6 Tunnel | | | | | (MAG initiates QoS Service Request) | 5) | |------ PBU (QoS)-->| 6) | |<----- PBA (QoS)---| | QoS Rules ---| | 7) | Established <-| | QoS Rules ---| 8) | ---| Established <-| | | | ---| 9) |<----------------->| | Figure 3: MAG Initiated QoS Service Request o (1) to (4): MAG detects the mobile node's attachment to the access link and initiates the signaling with the local mobility anchor. The LMA and MAG upon completing the signaling establish the mobility session and the forwarding state. o (5) to (6): The MAG initiates a QoS Service request to the local mobility anchor. The trigger for this service can be based on a trigger from the mobile node using access technology specific mechanisms. The specific details of that trigger are outside the scope of this document. The MAG sends a Proxy Binding Update message [RFC5213] to the LMA. The message includes the QoS option Section 4.1 which includes a set of QoS parameters. The LMA agrees to the proposed QoS service request by sending Proxy Liebsch, et al. Expires June 28, 2014 [Page 13] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 Binding Acknowledgement message. o (7) to (9): Upon successfully negotiating a QoS service request the MAG and the LMA install the QoS rules for that service request. Furthermore, the MAG using access technology specific mechanisms install the QoS rules on the access network. Liebsch, et al. Expires June 28, 2014 [Page 14] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 4. Protocol Messaging Extensions 4.1. Quality of Service Option The Quality of Service option is a mobility header option used by local mobility anchor and mobile access gateway for negotiating QoS parameters associated with a mobility session. This option can be carried in Proxy Binding Update (PBU) [RFC5213], Proxy Binding Acknowledgement (PBA) [RFC5213], Update Notification (UPN) [RFC7077] and Update Notification Acknowledgement(UPA) [RFC7077] messages. There can be more than one instance of the Quality of Service option in a single message. Each instance of the Quality of Service option represents a specific QoS service request. The alignment requirement for this option is 4n. 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 | SR-ID | TC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OC | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ QoS Attribute(s) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: QoS Option Type Length 8-bit unsigned integer indicating the length of the option in octets, excluding the Type and Length fields. Service Request Identifier (SR-ID) A 8-bit unsigned integer used for identifying the QoS service request. Its uniqueness is within the scope of a mobility session. The local mobility anchor always allocates the identifier value. When the QoS Service request is initiated by a mobile access gateway, it sets the value to (0) and the local mobility anchor allocates and includes the value in the Liebsch, et al. Expires June 28, 2014 [Page 15] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 response. For any QoS service requests initiated by a local mobility anchor, the Service Request Identifier is set to the allocated value. Traffic Class (TC) Traffic Class consists of a 6-bit DSCP field followed by a 2-bit reserved field. Differentiated Services Code Point (DSCP) A 6-bit unsigned integer indicating the code point value, as defined in [RFC2475] to be used for the mobile node's IP flows. When this DSCP marking needs to be applied only for a subset of mobile node's IP flows, there will be a Traffic Selector attribute (Section 4.2.10) in the option which provides the flow selectors. In the absence of any such traffic selector attribute, the DSCP marking applies to all the IP flows associated with the mobility session. Two-bit Reserved Field The last two-bits in the Traffic Class field are currently unused. These bits MUST be initialized by the sender to (0) and MUST be ignored by the receiver. Operational Code (OC) One-Octet Operational code indicates the type of QoS request. RESPONSE: (0) Response to a QoS request ALLOCATE: (1) Request to allocate QoS resources DE-ALLOCATE: (2) Request to de-Allocate QoS resources MODIFY: (3) Request to modify QoS parameters for a previously negotiated QoS service request QUERY: (4) Query to list the previously negotiated QoS service requests and that are still active Liebsch, et al. Expires June 28, 2014 [Page 16] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 NEGOTIATE: (5) Response to a QoS service request with a counter QoS proposal Reserved: (6) to (255) Currently not used. Receiver MUST ignore the option received with any value in this range. Reserved This field is unused for now. The value MUST be initialized to a value of (0) by the sender and MUST be ignored by the receiver. QoS Attribute(s) Zero or more Type-Length-Value (TLV) encoded QoS Attributes. The format of the QoS attribute is defined in Section 4.2. The interpretation and usage of the QoS attribute is based on the value in the "Type" field. 4.2. Quality of Service Attribute This section identifies the format of a Quality of Service attribute. QoS attribute is a sub-option that can be included in the Quality of Service option defined in Section 4.1. The latter part of this section identifies the QoS attributes defined by this specification. 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 | Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Format of a Quality of Service Attribute Type: 8-bit unsigned integer indicating the type of the QoS attribute. This specification reserves the following values. (0) - Reserved This value is reserved and cannot be used Liebsch, et al. Expires June 28, 2014 [Page 17] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 (1) - Per-MN-Agg-Max-DL-Bit-Rate This QoS attribute, Per Mobile Node Aggregate Maximum Downlink Bit Rate, is defined in Section 4.2.1. (2) - Per-MN-Agg-Max-UL-Bit-Rate This QoS attribute, Per Mobile Node Aggregate Maximum Uplink Bit Rate, is defined in Section 4.2.2. (3) - Per-Session-Agg-Max-DL-Bit-Rate This QoS attribute, Per Mobility Session Aggregate Maximum Downlink Bit Rate, is defined in Section 4.2.3. (4) - Per-Session-Agg-Max-UL-Bit-Rate This QoS attribute, Per Mobility Session Aggregate Maximum Uplink Bit Rate, is defined in Section 4.2.4. (5) - Allocation-Retention-Priority This QoS attribute, Allocation and Retention Priority, is defined in Section 4.2.5. (6) - Aggregate-Max-DL-Bit-Rate This QoS attribute, Aggregate Maximum Downlink Bit Rate, is defined in Section 4.2.6. (7) - Aggregate-Max-UL-Bit-Rate This QoS attribute, Aggregate Maximum Uplink Bit Rate, is defined in Section 4.2.7. (8) - Guaranteed-DL-Bit-Rate This QoS attribute, Guaranteed Downlink Bit Rate, is defined in Section 4.2.8. (9) - Guaranteed-UL-Bit-Rate This QoS attribute, Guaranteed Uplink Bit Rate, is defined in Section 4.2.9. Liebsch, et al. Expires June 28, 2014 [Page 18] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 (10) - QoS-Traffic-Selector This QoS attribute, QoS Traffic Selector, is defined in Section 4.2.10. (11) - QoS-Vendor-Specific-Attribute This QoS attribute, QoS Vendor Specific Attribute, is defined in Section 4.2.11. (255) - Reserved This value is reserved and cannot be used Length: 8-bit unsigned integer indicating the number of octets needed to encode the Value, excluding the Type and Length fields. Value: The format of this field is based on the Type value. 4.2.1. Per Mobile Node Aggregate Maximum Downlink Bit Rate This attribute, Per-MN-Agg-Max-DL-Bit-Rate, represents the maximum downlink bit-rate for a mobile node. It is a variant of the AMBR term defined in Section 2.2. This value is an aggregate across all mobility sessions associated with that mobile node. This attribute can be included in the Quality of Service option defined in Section 4.1 and it is an optional attribute. There can only be a single instance of this attribute present in a QoS option. When this attribute is present in a Proxy Binding Update sent by a mobile access gateway, or in a Update Notification message sent by a local mobility anchor, it indicates the maximum aggregate downlink bit-rate that is being requested for the mobile node at the peer. When this attribute is present in a Proxy Binding Acknowledgement message, or in an Update Notification Acknowledgement message, it indicates the maximum aggregate downlink bit-rate that the peer agrees to offer. If multiple mobility sessions are established for a mobile node, through multiple mobile access gateways and with sessions anchored either on a single local mobility anchor, or when spread out across multiple local mobility anchors, then it depends on the operator's policy and the specific deployment as how the total bandwidth for the mobile node on each MAG-LMA pair is computed. Liebsch, et al. Expires June 28, 2014 [Page 19] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Per-MN-Agg-Max-DL-Bit-Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: 1 o Length: The length in octets of the attribute, excluding the Type and Length fields. This value is set to (6). o Reserved: This field is unused for now. The value MUST be initialized by the sender to 0 and MUST be ignored by the receiver. o Per-MN-Agg-Max-DL-Bit-Rate: is a 32-bit unsigned integer, and it indicates the aggregate maximum downlink bit-rate that is requested/allocated for all the mobile node's IP flows. The measurement units for Per-MN-Agg-Max-DL-Bit-Rate are bits-per- second. 4.2.2. Per Mobile Node Aggregate Maximum Uplink Bit Rate This attribute, Per-MN-Agg-Max-UL-Bit-Rate, represents the maximum uplink bit-rate for the mobile node. It is a variant of the AMBR term defined in Section 2.2. This value is an aggregate across all mobility sessions associated with that mobile node. This attribute can be included in the Quality of Service option defined in Section 4.1 and it is an optional attribute. There can only be a single instance of this attribute present in a QoS option. When this attribute is present in a Proxy Binding Update sent by a mobile access gateway, or in an Update Notification message sent by the local mobility anchor, it indicates the maximum aggregate uplink bit-rate that is being requested for the mobile node at the peer. When this attribute is present in a Proxy Binding Acknowledgement message, or in an Update Notification Acknowledgement message, it indicates the maximum aggregate uplink bit-rate that the peer agrees to offer for that mobile node. If multiple mobility sessions are established for a mobile node, through multiple mobile access gateways and with sessions anchored either on a single local mobility anchor, or when spread out across multiple local mobility anchors, then it depends on the operator's Liebsch, et al. Expires June 28, 2014 [Page 20] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 policy and the specific deployment as how the total bandwidth for the mobile node on each MAG-LMA pair is computed. 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Per-MN-Agg-Max-UL-Bit-Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: 2 o Length: The length in octets of the attribute, excluding the Type and Length fields. This value is set to (6). o Reserved: This field is unused for now. The value MUST be initialized by the sender to 0 and MUST be ignored by the receiver. o Per-MN-Agg-Max-UL-Bit-Rate: is of type unsigned 32-bit integer, and it indicates the aggregate maximum uplink bit-rate that is requested/allocated for the mobile node's IP flows. The measurement units for Per-MN-Agg-Max-UL-Bit-Rate are bits-per- second. 4.2.3. Per Mobility Session Aggregate Maximum Downlink Bit Rate This attribute, Per-Session-Agg-Max-DL-Bit-Rate, represents the maximum downlink bit-rate for the mobility session. It is a variant of the AMBR term defined in Section 2.2. This attribute can be included in the Quality of Service option defined in Section 4.1 and it is an optional attribute. There can only be a single instance of this attribute present in a QoS option. When this attribute is present in a Proxy Binding Update sent by a mobile access gateway, or in an Update Notification message sent by the local mobility anchor, it indicates the maximum aggregate downlink bit-rate that is being requested for that mobility session. When this attribute is present in a Proxy Binding Acknowledgement message, or in an Update Notification Acknowledgement message, it indicates the maximum aggregate downlink bit-rate that the peer agrees to offer for that mobility session. When a QoS option includes both the Per-Session-Agg-Max-DL-Bit-Rate attribute and the QOS Traffic Selector attribute (Section 4.2.10), Liebsch, et al. Expires June 28, 2014 [Page 21] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 then the QOS Traffic Selector attribute does not apply to this attribute. 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 |S|E| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Per-Session-Agg-Max-DL-Bit-Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: 3 o Length: The length of the attribute in octets, excluding the Type and Length fields. This value is set to (6). o Service (S) flag: This flag is used for extending the scope of the target flows for Per-Session-Agg-Max-DL-Bit-Rate to mobile node's other mobility sessions sharing the same service identifier. 3GPP Access Point Name (APN) is an example of service identifier and that identifier is carried using the Service Selection mobility option [RFC5149]. * When the (S) flag is set to a value of (1), then the Per- Session-Agg-Max-DL-Bit-Rate is measured as an aggregate across all the mobile node's other mobility sessions sharing the same service identifier associated with this mobility session. * When the (S) flag is set to a value of (0), then there is no special effect on the receiver. * The (S) flag MUST NOT be set to a value of (1), when there is no service identifier associated with the mobility session. o Exclude (E) flag: This flag is used to request that some flows be excluded from the target IP flows for which Per-Session-Agg-Max- DL-Bit-Rate is measured. * When the (E) flag is set to a value of (1), then the request is for excluding the IP flows for which Guaranteed-DL-Bit-Rate (Section 4.2.8) is negotiated, from the flows for which Per- Session-Agg-Max-DL-Bit-Rate applies is measured. * When the (E) flag is set to a value of (0), then there is no special effect on the receiver. * When the (S) flag and (E) flag are both set to a value of (1), then the request is for excluding all the IP flows sharing the Liebsch, et al. Expires June 28, 2014 [Page 22] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 service identifier associated with this mobility session, from the target flows for which Per-Session-Agg-Max-DL-Bit-Rate is measured. o Reserved: This field is unused for now. The value MUST be initialized by the sender to 0 and MUST be ignored by the receiver. o Per-Session-Agg-Max-DL-Bit-Rate: is a 32-bit unsigned integer, and it indicates the aggregate maximum downlink bit-rate that is requested/allocated for all the IP flows associated with that mobility session. The measurement units for Per-Session-Agg-Max- DL-Bit-Rate are bits-per-second. 4.2.4. Per Mobility Session Aggregate Maximum Uplink Bit Rate This attribute, Per-Session-Agg-Max-UL-Bit-Rate, represents the maximum uplink bit-rate for the mobility session. It is a variant of the AMBR term defined in Section 2.2. This attribute can be included in the Quality of Service option defined in Section 4.1 and it is an optional attribute. There can only be a single instance of this attribute present in a QoS option. When this attribute is present in a Proxy Binding Update sent by a mobile access gateway, or in an Update Notification message [RFC7077] sent by the local mobility anchor, it indicates the maximum aggregate uplink bit-rate that is being requested for that mobility session. When this attribute is present in a Proxy Binding Acknowledgement message, or in an Update Notification Acknowledgement [RFC7077] message, it indicates the maximum aggregate uplink bit-rate that the peer agrees to offer for that mobility session. When a QoS option includes both the Per-Session-Agg-Max-UL-Bit-Rate attribute and the QOS Traffic Selector attribute (Section 4.2.10), then the QOS Traffic Selector attribute does not apply to this attribute. 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 |S|E| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Per-Session-Agg-Max-UL-Bit-Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Liebsch, et al. Expires June 28, 2014 [Page 23] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 o Type: 4 o Length: The length of the attribute in octets, excluding the Type and Length fields. This value is set to (6). o Service (S) flag: This flag is used for extending the scope of the target flows for Per-Session-Agg-Max-UL-Bit-Rate to mobile node's other mobility sessions sharing the same service identifier. 3GPP Access Point Name (APN) is an example of service identifier and that identifier is carried using the Service Selection mobility option [RFC5149]. * When the (S) flag is set to a value of (1), then the Per- Session-Agg-Max-UL-Bit-Rate is measured as an aggregate across all the mobile node's other mobility sessions sharing the same service identifier associated with this mobility session. * When the (S) flag is set to a value of (0), then there is no special effect on the receiver. * The (S) flag MUST NOT be set to a value of (1), when there is no service identifier associated with the mobility session. o Exclude (E) flag: This flag is used to request that some flows be excluded from the target IP flows for which Per-Session-Agg-Max- UL-Bit-Rate is measured. * SGS When the (E) flag is set to a value of (1), then the request is for excluding the IP flows for which Guaranteed-UL- Bit-Rate (Section 4.2.9) is negotiated, from the flows for which Per-Session-Agg-Max-UL-Bit-Rate is measured. * When the (E) flag is set to a value of (0), then there is no special effect on the receiver. * When the (S) flag and (E) flag are both set to a value of (1), then the request is for excluding all the IP flows sharing the service identifier associated with this mobility session, from the target flows for which Per-Session-Agg-Max-UL-Bit-Rate is measured. o Reserved: This field is unused for now. The value MUST be initialized by the sender to 0 and MUST be ignored by the receiver. o Per-Session-Agg-Max-UL-Bit-Rate: is a 32-bit unsigned integer, and it indicates the aggregate maximum uplink bit-rate that is requested/allocated for all the IP flows associated with that Liebsch, et al. Expires June 28, 2014 [Page 24] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 mobility session. The measurement units for Per-Session-Agg-Max- UL-Bit-Rate are bits-per-second. 4.2.5. Allocation and Retention Priority This attribute, Allocation-Retention-Priority, represents allocation and retention priority for the mobility session or a set of IP flows. It is defined in Section 2.2. This attribute can be included in the Quality of Service option defined in Section 4.1 and it is an optional attribute. There can only be a single instance of this attribute present in a QoS option. When the QoS option includes both the Allocation and Retention Priority attribute and the QOS Traffic Selector attribute (Section 4.2.8), then the Allocation and Retention Priority attribute is to be applied at a flow level. The traffic selector in the QOS Traffic Selector attribute identifies the target flows. When the QoS option including the Allocation and Retention Priority attribute does not include the QOS Traffic Selector attribute (Section 4.2.8), then the Allocation and Retention Priority attribute is to be applied to all the IP flows associated with that mobility session. 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Priority-Level | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preemption-Capability | Preemption-Vulnerability | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: 5 o Length: The length of the attribute in octets, excluding the Type and Length fields. This value is set to (10). o Reserved: This field is unused for now. The value MUST be initialized by the sender to 0 and MUST be ignored by the receiver. o Priority-Level: is of type unsigned 32-bit integer, and it is used to decide whether a mobility session establishment or modification request can be accepted; this is typically used for admission control of Guaranteed Bit Rate traffic in case of resource Liebsch, et al. Expires June 28, 2014 [Page 25] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 limitations. The priority level can also be used to decide which existing mobility session to pre-empt during resource limitations. The priority level defines the relative timeliness of a resource request. Values 1 to 15 are defined, with value 1 as the highest level of priority. Values 1 to 8 should only be assigned for services that are authorized to receive prioritized treatment within an operator domain. Values 9 to 15 may be assigned to resources that are authorized by the home network and thus applicable when a mobile node is roaming. o Preemption-Capability: defines whether a service data flow can get resources that were already assigned to another service data flow with a lower priority level. The following values are defined: Enabled (0): This value indicates that the service data flow is allowed to get resources that were already assigned to another IP data flow with a lower priority level. Disabled (1): This value indicates that the service data flow is not allowed to get resources that were already assigned to another IP data flow with a lower priority level. o Preemption-Vulnerability: defines whether a service data flow can lose the resources assigned to it in order to admit a service data flow with higher priority level. The following values are defined: Enabled (0): This value indicates that the resources assigned to the IP data flow can be pre-empted and allocated to a service data flow with a higher priority level. Disabled (1): This value indicates that the resources assigned to the IP data flow shall not be pre-empted and allocated to a service data flow with a higher priority level. 4.2.6. Aggregate Maximum Downlink Bit Rate This attribute, Aggregate-Max-DL-Bit-Rate, represents the maximum downlink bit-rate for the mobility session. It is a variant of the AMBR term defined in Section 2.2. This attribute can be included in the Quality of Service option defined in Section 4.1 and it is an optional attribute. There can only be a single instance of this attribute present in a QoS option. Liebsch, et al. Expires June 28, 2014 [Page 26] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 When this attribute is present in a Proxy Binding Update sent by a mobile access gateway, or in an Update Notification message sent by the local mobility anchor, it indicates the maximum aggregate bit- rate for downlink IP flows that is being requested. When this attribute is present in a Proxy Binding Acknowledgement message, or in an Update Notification Acknowledgement message, it indicates the maximum aggregate downlink bit-rate that the peer agrees to offer. When a QoS option includes both the Aggregate-Max-DL-Bit-Rate attribute and the QOS-Traffic-Selector attribute (Section 4.2.10), then the Aggregate-Max-DL-Bit-Rate attribute is to be enforced at a flow level and the traffic selectors present in the QOS-Traffic- Selector attribute identifies those target flows. When the QoS option that includes the Aggregate-Max-DL-Bit-Rate attribute does not include the QOS-Traffic-Selector attribute (Section 4.2.10), then the Aggregate-Max-DL-Bit-Rate attribute is to be applied to all the IP flows associated with the mobility session. 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Aggregate-Max-DL-Bit-Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: 6 o Length: The length of the attribute in octets, excluding the Type and Length fields. This value is set to (6). o Reserved: This field is unused for now. The value MUST be initialized by the sender to 0 and MUST be ignored by the receiver. o Aggregate-Max-DL-Bit-Rate: is a 32-bit unsigned integer, and it indicates the aggregate maximum downlink bit-rate that is requested/allocated for downlink IP flows. The measurement units for Aggregate-Max-DL-Bit-Rate are bits-per-second. 4.2.7. Aggregate Maximum Uplink Bit Rate This attribute, Aggregate-Max-UL-Bit-Rate, represents the maximum uplink bit-rate for the mobility session. It is a variant of the AMBR term defined in Section 2.2. Liebsch, et al. Expires June 28, 2014 [Page 27] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 This attribute can be included in the Quality of Service option defined in Section 4.1 and it is an optional attribute. There can only be a single instance of this attribute present in a QoS option. When this attribute is present in a Proxy Binding Update sent by a mobile access gateway, or in an Update Notification message sent by the local mobility anchor, it indicates the maximum aggregate uplink bit-rate that is being requested. When this attribute is present in a Proxy Binding Acknowledgement message, or in an Update Notification Acknowledgement message, it indicates the maximum aggregate uplink bit-rate that the peer agrees to offer. When a QoS option includes both the Aggregate-Max-UL-Bit-Rate attribute and the QOS-Traffic-Selector attribute (Section 4.2.10), then the Aggregate-Max-UL-Bit-Rate attribute is to be enforced at a flow level and the traffic selectors present in the QOS-Traffic- Selector attribute identifies those target flows. When the QoS option that includes the Aggregate-Max-UL-Bit-Rate attribute does not include the QOS-Traffic-Selector attribute (Section 4.2.10), then the Aggregate-Max-UL-Bit-Rate attribute is to be applied to all the IP flows associated with the mobility session. 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Aggregate-Max-UL-Bit-Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: 7 o Length: The length of the attribute in octets, excluding the Type and Length fields. This value is set to (6). o Reserved: This field is unused for now. The value MUST be initialized by the sender to 0 and MUST be ignored by the receiver. o Per-Session-Agg-Max-UL-Bit-Rate: is a 32-bit unsigned integer, and it indicates the aggregate maximum uplink bit-rate that is requested/allocated for all the IP flows associated with that mobility session. The measurement units for Aggregate-Max-UL-Bit- Rate are bits-per-second. Liebsch, et al. Expires June 28, 2014 [Page 28] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 4.2.8. Guaranteed Downlink Bit Rate This attribute, Guaranteed-DL-Bit-Rate, represents the assured bit- rate on the downlink path that will be provided for a set of IP flows associated with a mobility session. It is a variant of the GBR term defined in Section 2.2. This attribute can be included in the Quality of Service option defined in Section 4.1 and it is an optional attribute. There can only be a single instance of this attribute present in a QoS option. When this attribute is present in a Proxy Binding Update sent by a mobile access gateway, or in a Update Notification message sent by the local mobility anchor, it indicates the guaranteed downlink bit- rate that is being requested. When this attribute is present in a Proxy Binding Acknowledgement message, or in an Update Notification Acknowledgement message, it indicates the guaranteed downlink bit-rate that the peer agrees to offer. When a QoS option includes both the Guaranteed-DL-Bit-Rate attribute and the QOS-Traffic-Selector attribute (Section 4.2.10), then the Guaranteed-DL-Bit-Rate attribute is to be enforced at a flow level and the traffic selectors present in the QOS-Traffic-Selector attribute identifies those target flows. When the QoS option that includes the Guaranteed-DL-Bit-Rate attribute does not include the QOS-Traffic-Selector attribute (Section 4.2.10), then the Guaranteed-DL-Bit-Rate attribute is to be applied to all the IP flows associated with the mobility session. 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Guaranteed-DL-Bit-Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: 8 o Length: The length of the attribute in octets, excluding the Type and Length fields. This value is set to (6). o Reserved: This field is unused for now. The value MUST be initialized by the sender to 0 and MUST be ignored by the receiver. Liebsch, et al. Expires June 28, 2014 [Page 29] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 o Guaranteed-DL-Bit-Rate: is of type unsigned 32-bit integer, and it indicates the guaranteed bandwidth in bits-per-second for downlink IP flows. The measurement units for Guaranteed-DL-Bit-Rate are bits-per-second. 4.2.9. Guaranteed Uplink Bit Rate This attribute, Guaranteed-UL-Bit-Rate, represents the assured bit- rate on the uplink path that will be provided for a set of IP flows associated with a mobility session. It is a variant of the GBR term defined in Section 2.2. This attribute can be included in the Quality of Service option defined in Section 4.1 and it is an optional attribute. There can only be a single instance of this attribute present in a QoS option. When this attribute is present in a Proxy Binding Update sent by a mobile access gateway, or in a Update Notification message sent by the local mobility anchor, it indicates the guaranteed uplink bit- rate that is being requested. When this attribute is present in a Proxy Binding Acknowledgement message, or in an Update Notification Acknowledgement message, it indicates the guaranteed uplink bit-rate that the peer agrees to offer. When a QoS option includes both the Guaranteed-UL-Bit-Rate attribute and the QOS-Traffic-Selector attribute (Section 4.2.10), then the Guaranteed-UL-Bit-Rate attribute is to be enforced at a flow level and the traffic selectors present in the QOS-Traffic-Selector attribute identifies those target flows. When the QoS option that includes the Guaranteed-UL-Bit-Rate attribute does not include the QOS-Traffic-Selector attribute (Section 4.2.10), then the Guaranteed-UL-Bit-Rate attribute is to be applied to all the IP flows associated with the mobility session. 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Guaranteed-UL-Bit-Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: 9 Liebsch, et al. Expires June 28, 2014 [Page 30] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 o Length: The length of the attribute in octets, excluding the Type and Length fields. This value is set to (6). o Reserved: This field is unused for now. The value MUST be initialized by the sender to 0 and MUST be ignored by the receiver. o Guaranteed-UL-Bit-Rate: is of type unsigned 32-bit integer, and it indicates the guaranteed bandwidth in bits-per-second for uplink IP flows. The measurement units for Guaranteed-UL-Bit-Rate are bits-per-second. 4.2.10. QoS Traffic Selector This attribute, QoS-Traffic-Selector, includes the parameters used to match packets for a set of IP flows. This attribute can be included in the Quality of Service option defined in Section 4.1 and it is an optional attribute. When a QoS option that includes the QoS-Traffic-Selector also includes any one or more of the attributes, Allocation-Retention- Priority (Section 4.2.5), Aggregate-Max-DL-Bit-Rate (Section 4.2.6), Aggregate-Max-UL-Bit-Rate (Section 4.2.7), Guaranteed-DL-Bit-Rate (Section 4.2.8), and Guaranteed-UL-Bit-Rate (Section 4.2.9), then those included attributes are to be enforced at a flow level and the traffic selectors present in the QoS-Traffic-Selector attribute identifies those target flows. Furthermore, the DSCP marking in the QoS option is to be applied only to partial set of mobile node's IP flows and the traffic selectors present in the QoS-Traffic-Selector attribute identifies those target flows. 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 | Reserved | TS Format | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Traffic Selector ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: 10 o Length: The length of the attribute in octets, excluding the Type and Length fields. o Reserved: This field is unused for now. The value MUST be initialized by the sender to 0 and MUST be ignored by the receiver. Liebsch, et al. Expires June 28, 2014 [Page 31] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 o TS Format: An 8-bit unsigned integer indicating the Traffic Selector Format. Value (0) is reserved and MUST NOT be used. When the value of TS Format field is set to (1), the format that follows is the IPv4 Binary Traffic Selector specified in section 3.1 of [RFC6088], and when the value of TS Format field is set to (2), the format that follows is the IPv6 Binary Traffic Selector specified in section 3.2 of [RFC6088]. o Traffic Selector: variable-length opaque field for including the traffic specification identified by the TS format field. 4.2.11. QoS Vendor Specific Attribute This attribute is used for carrying vendor specific QoS attributes. The interpretation and the handling of this option is specific to the vendor implementation. This attribute can be included in the Quality of Service option defined in Section 4.1 and it is an optional attribute. There can be multiple instances of this attribute with different sub-type values present in a single QoS option. 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Type | ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Type: 11 o Length: The length of the attribute in octets, excluding the Type and Length fields. o Reserved: This field is unused for now. The value MUST be initialized by the sender to 0 and MUST be ignored by the receiver. o Vendor ID: The Vendor ID is the SMI (Structure of Management Information) Network Management Private Enterprise Code of the IANA-maintained Private Enterprise Numbers registry [SMI]. o Sub-Type: An 8-bit field indicating the type of vendor-specific information carried in the option. The name space for this Sub- type is managed by the Vendor identified by the Vendor ID field. Liebsch, et al. Expires June 28, 2014 [Page 32] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 4.3. New Status Code for Proxy Binding Acknowledgement This document defines the following new Status Code value for use in Proxy Binding Acknowledgement message. CANNOT_MEET_QOS_SERVICE_REQUEST (Cannot meet QoS Service Request): 4.4. New Notification Reason for Update Notification Message This document defines the following new Notification Reason value for use in Update Notification message. QOS_SERVICE_REQUEST (QoS Service Requested): 4.5. New Status Code for Update Notification Acknowledgement Message This document defines the following new Status code value for use in Update Notification Acknowledgement message. CANNOT_MEET_QOS_SERVICE_REQUEST (Cannot meet QoS Service Request ): Liebsch, et al. Expires June 28, 2014 [Page 33] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 5. Protocol Considerations 5.1. Local Mobility Anchor Considerations o The conceptual Binding Cache entry data structure maintained by the local mobility anchor, described in Section 5.1 of [RFC5213], can be extended to store a list of negotiated Quality of Service requests to be enforced. There can be multiple such entries and entry must include the Service Request Identifier, DSCP value and the attributes defined in Section Section 4.2. LMA Receiving a QoS Service Request: o On receiving a Proxy Binding Update message with one or more instances of Quality of Service option included in the message, the local mobility anchor MUST process the option(s) and determine if the QoS service request for the proposed QoS service request(s) can be met. Each instance of the Quality of Service option represents a specific QoS service request. This determination to accept the request(s) can be based on policy configured on the local mobility anchor, available network resources, or based on other considerations. o If the local mobility anchor can support the proposed QoS service requests in entirety, then it MUST send a Proxy Binding Acknowledgement message with a status code value of (0). * The message MUST include all the Quality of Service option instances copied (including all the option content) from the received Proxy Binding Update message. However, if the Operational Code field in the request is a QUERY, then the message MUST include all the Quality of Service option(s) reflecting the currently negotiated QoS service requests for that mobility session. * The Operational Code field in each of the Quality of Service option(s) MUST be set to RESPONSE. * The local mobility anchor MUST enforce the Quality of Service rules for all the negotiated QoS service requests on the mobile node's uplink and downlink traffic. o If the local mobility anchor cannot support any of the requested QoS service requests in entirety, then it MUST reject the request and send a Proxy Binding Acknowledgement message with the status code value set to CANNOT_MEET_QOS_SERVICE_REQUEST (Cannot meet QoS Service Request). Liebsch, et al. Expires June 28, 2014 [Page 34] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 * The denial for QoS service request MUST NOT result in removal of the mobility session for that mobile node. * The Operational Code field in each of the Quality of Service option(s) MUST be set to RESPONSE. * The Proxy Binding Acknowledgement message may include the Quality of Service option based on the following considerations. + If the local mobility anchor cannot support QoS services for that mobile node, then Quality of Service option MUST NOT be included in the Proxy Binding Acknowledgement message. This serves as an indication to the mobile access gateway that QoS services are not supported for that mobile node. + If the local mobility anchor can support QoS services for that mobile node, but for a downgraded/revised QoS service request, or for a partial set of QoS service requests, then the updated Quality of Service option(s) MUST be included in the Proxy Binding Acknowledgement message. This includes the case, where the Attributes in a QoS option have conflicting requirements, Ex: Per-Session-Agg-Max-UL-Bit- Rate is lower than the Guaranteed-UL-Bit-Rate. The contents of each of the option (including the QoS attributes) MUST reflect the QoS service parameters that the local mobility anchor can support for that mobile node. The Operational Code field in each of the Quality of Service option(s) MUST be set to NEGOTIATE. This serves as an indication for the mobile access gateway to resend the Proxy Binding Update message with the revised QoS parameters. LMA Sending a QoS Service Request: o The local mobility anchor, at any time, can initiate a QoS service request for mobile node, by sending an Update Notification message [RFC7077]. The Notification Reason in the Update Notification message MUST be set to a value of QOS_SERVICE_REQUEST and the Acknowledgement Requested (A) flag set to a value of (1). * New QoS service request: + The message MUST include a Quality of Service option with one or more QoS attributes included in the option. + The Operational Code field in the Quality of Service option MUST be set to ALLOCATE. Liebsch, et al. Expires June 28, 2014 [Page 35] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 + The Service Request Identifier MUST be set to a value of (0). + The DSCP field in the Traffic Class (TC) field MUST reflect the requested DSCP value. * Modification of an existing QoS Service Request: + The message MUST include a Quality of Service option with the QoS attributes reflecting the updated values in the Attributes, and the updated list of Attributes. + The Operational Code field in the Quality of Service option MUST be set to MODIFY. + The Service Request Identifier MUST be set to a value that was allocated for that QoS service request. + There can be more than one QOS service request in a single message, but there MUST be a instance of a Quality of Service option in the message for each of those service requests. * Deletion of an existing QoS Service Request: + The Operational Code field in the Quality of Service option MUST be set to DE-ALLOCATE. + The Service Request Identifier MUST be set to a value that was allocated for that QoS service request. + The message MUST include a Quality of Service option with the QoS attributes reflecting the updated values for the attributes. * Query for the previously negotiated QoS Service Requests: + The Operational Code field in the Quality of Service option MUST be set to QUERY. + The Service Request Identifier MUST be set to a value of (0). + The message MUST include a single instance of the Quality of Service option without including any QoS Attributes. Liebsch, et al. Expires June 28, 2014 [Page 36] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 o Handling a Response to the QoS Service Request: * If the received Update Notification Acknowledgement [RFC7077] message has the status code field set to value of (0), the local mobility anchor MUST enforce the Quality of Service rules for the negotiated QoS parameters on the mobile node's uplink and downlink traffic. * If the received Update Notification Acknowledgement message is with the status code field set to value of (CANNOT_MEET_QOS_SERVICE_REQUEST), the local mobility anchor MUST apply the following considerations. + The denial of QoS service request MUST NOT result in removal of any of the mobile node's Binding Cache entries. + If the message did not include any Quality of Service option(s), then it is an indication from the mobile access gateway that QoS services are not enabled for the mobile node. + If the Operational Code field in the Quality of Service option is set to a value of NEGOTIATE and the message includes one or more instances of the Quality of Service option, but the option contents reflect a downgraded/revised set of QoS parameters, then the local mobility anchor MAY choose to agree to proposed QoS service request by resending a new Proxy Binding Update message with the updated Quality of Service option. General Considerations: o Any time the local mobility anchor removes a mobile node's mobility session by removing a Binding Cache entry [RFC5213], for which QoS resources have been previously allocated, those allocated resources MUST be released. o Any time the local mobility anchor receives a Proxy Binding Update with HI hint = 3 (inter-MAG handover), the local mobility anchor when sending a Proxy Binding Acknowledgement message MUST include the QoS option(s) for each of the QoS service requests that are active for that mobile node. This allows the mobile access gateway to allocate QoS resources on the current path. This is relevant for the scenario where a mobile node performs an handover to a new mobile access gateway which is unaware of the previously negotiated QoS services. Liebsch, et al. Expires June 28, 2014 [Page 37] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 5.2. Mobile Access Gateway Considerations o The conceptual Binding Update List entry data structure maintained by the mobile access gateway, described in Section 6.1 of [RFC5213], can be extended to store a list of negotiated Quality of Service requests to be enforced. There can be multiple such entries and entry must include the Service Request Identifier, DSCP value and the attributes defined in Section Section 4.2. MAG Receiving a QoS Service Request: o On receiving a Update Notification message with one or more instances of Quality of Service option included in the message, the mobile access gateway MUST process the option(s) and determine if the QoS service request for the proposed QoS service request(s) can be met. Each instance of the Quality of Service option represents a specific QoS service request. This determination to accept the request(s) can be based on policy configured on the mobile access gateway, available network resources, or based on other considerations. o If the mobile access gateway can support the proposed QoS service requests in entirety, then it MUST send a an Update Notification Acknowledgement message with status code value of (0). * The message MUST include all the Quality of Service option instances copied (including all the option content) from the received Update Notification message. However, if the Operational Code field in the request is a QUERY, then the message MUST include all the Quality of Service option(s) reflecting the currently negotiated QoS service requests for that mobility session. * The Operational Code field in each of the Quality of Service option(s) MUST be set to RESPONSE. * The mobile access gateway MUST enforce the Quality of Service rules for all the negotiated QoS service requests on the mobile node's uplink and downlink traffic. o If the mobile access gateway cannot support any of the requested QoS service requests in entirety, then it MUST reject the request and send an Update Notification Acknowledgement message with the status code set to CANNOT_MEET_QOS_SERVICE_REQUEST (Cannot meet QoS Service Request). * The denial for QoS service request MUST NOT result in removal of the mobility session for that mobile node. Liebsch, et al. Expires June 28, 2014 [Page 38] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 * The Operational Code field in each of the Quality of Service option(s) MUST be set to RESPONSE. * The Update Notification Acknowledgement message may include the Quality of Service option(s) based on the following considerations. + If the mobile access gateway cannot support QoS services for that mobile node, then Quality of Service option MUST NOT be included in the Update Notification Acknowledgement message. This serves as an indication to the local mobility anchor that QoS services are not supported for that mobile node. + If the mobile access gateway can support QoS services for that mobile node, but for a downgraded/revised QoS service request, or for a partial set of QoS service requests, then the updated Quality of Service option(s) MUST be included in the Update Notification Acknowledgement message. This includes the case, where the Attributes in a QoS option have conflicting requirements, Ex: Per-Session-Agg-Max-UL-Bit- Rate is lower than the Guaranteed-UL-Bit-Rate. The contents of each of the option (including the QoS attributes) MUST reflect the QoS service parameters that the mobile access gateway can support for that mobile node. The Operational Code field in each of the Quality of Service option(s) MUST be set to NEGOTIATE. This serves as an indication to the local mobility anchor to resend the Update Notification message with the revised QoS parameters. MAG Sending a QoS Service Request: o The mobile access gateway, at any time, can initiate a QoS service request for a mobile node, by sending a Proxy Binding Update message. The QoS service request can be initiated as part of the initial Binding registration, or during binding re-registrations. * New QoS service request: + The message MUST include a Quality of Service option with one or more QoS attributes included in the option. + The Operational Code field in the Quality of Service option MUST be set to ALLOCATE. + The Service Request Identifier MUST be set to a value of (0). Liebsch, et al. Expires June 28, 2014 [Page 39] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 + The DSCP value in the Traffic Class field MUST reflect the requested DSCP value. * Modification of an existing QoS Service Request: + The message MUST include a Quality of Service option with the QoS attributes reflecting the updated values in the Attributes, and the updated list of Attributes. + The Operational Code field in the Quality of Service option MUST be set to MODIFY. + The Service Request Identifier MUST be set to a value that was allocated for that QoS service request. + There can be more than one QOS service request in a single message, but there MUST be a instance of a Quality of Service option in the message for each of those service requests. * Deletion of an existing QoS Service Request: + The Operational Code field in the Quality of Service option MUST be set to DE-ALLOCATE. + The Service Request Identifier MUST be set to a value that was allocated for that QoS service request. + The message MUST include a Quality of Service option with the QoS attributes reflecting the updated values for the attributes. * Query for the previously negotiated QoS Service Requests: + The Operational Code field in the Quality of Service option MUST be set to QUERY. + The Service Request Identifier MUST be set to a value of (0). + The message MUST include a single instance of the Quality of Service option without including any QoS Attributes. o Handling a Response to the QoS Service Request: * If the received Proxy Binding Acknowledgement message has the status code field set to a value of (0), the mobile access gateway MUST enforce the Quality of Service rules for the Liebsch, et al. Expires June 28, 2014 [Page 40] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 negotiated QoS parameters on the mobile node's uplink and downlink traffic. * If the received Proxy Binding Acknowledgement message has the status code field set to a value of (CANNOT_MEET_QOS_SERVICE_REQUEST), the mobile access gateway MUST apply the following considerations. + The denial of QoS service request MUST NOT result in removal of any of the mobile node's Binding Update list entries. + If the message did not include any Quality of Service option(s), then it is an indication from the local mobility anchor that QoS services are not enabled for the mobile node. + If the Operational Code field in the Quality of Service option is set to a value of NEGOTIATE and the message includes one or more instances of the Quality of Service option, but the option contents reflect a downgraded/revised set of QoS parameters, then the mobile access gateway MAY choose to agree to proposed QoS service request by resending a new Proxy Binding Update message with the updated Quality of Service option. * General Considerations: + There can be more than one QOS service request in a single message, but there MUST be an instance of a Quality of Service option in the message for each of those service requests. Furthermore, the DSCP value MUST be different in each of those requests. + Any time the mobile access gateway removes a mobile node's mobility session by removing a Binding Update List entry [RFC5213], for which QoS resources have been previously allocated, those allocated resources MUST to be released. Liebsch, et al. Expires June 28, 2014 [Page 41] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 6. QoS Services in Integrated WLAN-3GPP Networks 6.1. Technical Scope and Procedure The QoS option specified in this document can provide the equivalent level of QoS information defined in 3GPP, which is used to enforce QoS policies for IP flows, which have been established while the mobile node is attached to WLAN access, or moved from 3GPP to WLAN access. The QoS classification defined by the 3GPP specification is provided by Differentiated Services techniques in the IP transport network and translated as appropriate into WLAN QoS specification in WLAN access, the details of which are described in Appendix A and Appendix B. Figure 6 illustrates a generalized architecture where the QoS option can be used. The QoS policies could be retrieved from a Policy Control Function (PCF), such as defined in current cellular mobile communication standards, which aims to assign an appropriate QoS class to a mobile node's individual flows. Alternatively, more static and default QoS rules could be made locally available, e.g. on a local mobility anchor, through administration. Liebsch, et al. Expires June 28, 2014 [Page 42] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 Non-cellular access | Cellular Core Network Cellular (e.g. WLAN) | (e.g. EPC) Access | (e.g. | +-----------+ EUTRAN) | | PCF | | |(e.g. PCRF)| +----+ | +-----+-----+ |WiFi| (I) | | | AP |---+ +---+---+ | | ((O)) +----+ | |WiFi AR| | PMIPv6 +-----+ +---+ | +----+ (MAG) +=|============| LMA |=====|MAG+--| | | WLC | | tunnel +-----+ +---+ | +----+ | +-------+ | // |WiFi|---+ | // | AP | | // +----+ (II) | // +-------+ | // +----+ +------+ |WiFi AR| | // |WiFi+----+ WLC +------+ (MAG) |=|=======// | AP | | | | | | +----+ +------+ +------ + | ^ ^ | | | | +------------+ QoS inter-working Figure 6: Architecture for QoS inter-working between cellular access and non-cellular access During a mobile node's handover from cellular access to non-cellular access, e.g. a wireless LAN (WLAN) radio access network, the mobile node's QoS policy rules, as previously established on the local mobility anchor for the mobile node's communication through the cellular access network, are moved to the handover target mobile access gateway serving the non-cellular access network. Such non- cellular mobile access gateway can have an access technology specific controller or function co-located, e.g. a Wireless LAN Controller (WLC), as depicted in option (I) of Figure 6. Alternatively, the access specific architecture can be distributed and the access technology specific control function is located external to the mobile access gateway, as depicted in option (II). In this case, the mobile access gateway and the access technology specific control function (e.g. the WLC) must provide some protocol for QoS inter- working. Details of such inter-working are out of scope of this specification. Liebsch, et al. Expires June 28, 2014 [Page 43] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 6.2. Relevant QoS Attributes The QoS Option shall at least contain a DSCP value being associated with IP flows of a mobility session. The DSCP value should correspond to the 3GPP QoS Class Index (QCI), which identifies the type of service in term of QoS characteristics (e.g. conversational voice, streaming video, signaling, best effort,...); more details on DSCP and QCI mapping are given on section Appendix A. Optional QoS information could also be added. For instance, in order to comply with the bearer model defined in 3GPP [TS23.203], the following QoS parameters are conveyed for each PMIPv6 mobility session: o Default, non-GBR bearer (QCI=5-9) * DSCP={BE,AF11/21/31/32} * Per-MN AMBR-UL/DL * Per-Session AMBR-UL/DL {S=1,E=1} * AARP APN (Access Point Name) is provided via the Service Selection ID defined in [RFC5149]. If APN is not interpreted by Wi-Fi AP, the latter will police only based on Per-MN AMBR-UL/DL (without Per- Session AMBR-UL/DL) on the Wi-Fi link. o Dedicated, GBR bearer (QCI=1-4) * DSCP={EF/AF41} * GBR-UL/DL * MBR-UL/DL * AARP * TS Wi-Fi AP will perform the policy enforcement with the minimum bit- rate=GBR and the maximum bitrate=MBR. o Dedicated, non-GBR bearer (QCI=5-9) * DSCP={BE,AF11/21/31/32} * Per-MN AMBR-UL/DL Liebsch, et al. Expires June 28, 2014 [Page 44] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 * Per-Session AMBR-UL/DL {S=1,E=1} * AARP * TS If APN is not interpreted by Wi-Fi AP, it will police based only on Per-MN AMBR-UL/DL (without Per-Session AMBR-UL/DL) on the Wi-Fi link. If DSCP values follow the 3GPP specification and deployment, the code point can carry intrinsically additional attributes according to Figure 7. For some optional QoS attributes the signaling can differentiate enforcement per mobility session and per IP flow. For the latter, the rule associated with the identified flow(s) overrules the aggregated rules which apply per Mobile Node or per Mobility Session. Additional attributes can be appended to the QoS option, but their definition and specification is out of scope of this document and left to their actual deployment. Liebsch, et al. Expires June 28, 2014 [Page 45] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 7. IANA Considerations This document requires the following IANA actions. o Action-1: This specification defines a new mobility option, the Quality of Service (QoS) option. The format of this option is described in Section 4.1. The type value for this mobility option needs to be allocated from the Mobility Options registry at . RFC Editor: Please replace in Section 4.1 with the assigned value and update this section accordingly. o Action-2: This specification defines a new mobility sub-option format, Quality of Service attribute. The format of this mobility sub-option is described in Section 4.2. This sub-option can be carried in Quality of Service mobility option. The type values for this sub-option needs to be managed by IANA, under the Registry, Quality of Service Attribute Registry. This registry should be created under "Mobile IPv6 Parameters" registry at . This specification reserves the following type values. Approval of new Quality of Service Attribute type values are to be made through IANA Expert Review. Liebsch, et al. Expires June 28, 2014 [Page 46] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 +=====+=================================+=================+ |Value| Description | Reference | +=====+=================================+=================+ | 0 | Reserved | | +=====+===================================================+ | 1 | Per-MN-Agg-Max-DL-Bit-Rate | | +=====+===================================================+ | 2 | Per-MN-Agg-Max-UL-Bit-Rate | | +=====+===================================================+ | 3 | Per-Session-Agg-Max-DL-Bit-Rate | | +=====+===================================================+ | 4 | Per-Session-Agg-Max-UL-Bit-Rate | | +=====+===================================================+ | 5 | Allocation-Retention-Priority | | +=====+===================================================+ | 6 | Aggregate-Max-DL-Bit-Rate | | +=====+===================================================+ | 7 | Aggregate-Max-UL-Bit-Rate | | +=====+===================================================+ | 8 | Guaranteed-DL-Bit-Rate | | +=====+===================================================+ | 9 | Guaranteed-UL-Bit-Rate | | +=====+===================================================+ | 10 | QoS-Traffic-Selector | | +=====+===================================================+ | 11 | QoS-Vendor-Specific-Attribtute | | +=====+===================================================+ | 255 | Reserved | | +=====+===================================================+ o Action-3: This document defines a new status value, CANNOT_MEET_QOS_SERVICE_REQUEST () for use in Proxy Binding Acknowledgement message, as described in Section 4.3. This value is to be assigned from the "Status Codes" registry at . The allocated value has to be greater than 127. RFC Editor: Please replace in Section 4.3 with the assigned value and update this section accordingly. o Action-4: This document defines a new Notification Reason, QOS_SERVICE_REQUEST () for use in Update Notification message [RFC7077] as described in Section 4.4. This value is to be assigned from the "Update Notification Reasons Registry" at . RFC Editor: Please replace in Section 4.4 with the assigned value and update this section accordingly. Liebsch, et al. Expires June 28, 2014 [Page 47] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 o Action-5: This document defines a new Notification Reason, CANNOT_MEET_QOS_SERVICE_REQUEST () for use in Update Notification Acknowledgement message [RFC7077] as described in Section 4.5. This value is to be assigned from the "Update Notification Acknowledgement Status Registry" at . RFC Editor: Please replace in Section 4.5 with the assigned value and update this section accordingly. Liebsch, et al. Expires June 28, 2014 [Page 48] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 8. Implementation Status Note to RFC Editor: Please remove this section and the reference to [RFC6982] before publication. This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC6982]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to [RFC6982], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit". Cisco Implementation Organization: Cisco Description: QoS Extensions to Cisco IOS-based MAG and LMA Implementations. Engineering prototype code under development. Coverage: Support includes QoS signaling from MAG to LMA based on PBU/PBA and LMA to MAG based on the recently standardized UPN/UPA messages. Implementation includes only a partial set of QoS attributes and support for other Attributes is under development. The QoS option is based on the Vendor-specific mobility option, but it has all the parameters defined in -07 version of the document. We have plans to show a demo in the next IETF. Licensing: Closed. However, cisco has plans to release the MAG portion of the code for Linux as open source. Implementation Experience: The feedback from the developer suggests that the protocol extensions needed for this specification proved to be reasonably straightforward. Numerous draft revisions were made based on the questions and comments from the developer. The effort to most part appears to be around Liebsch, et al. Expires June 28, 2014 [Page 49] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 interfacing with the platform specific QoS features for enforcing the negotiated QoS parameters for a subscriber's IP session/flows. On Cisco IOS, there is a programmatic interface with rich semantics for interfacing with IOS MQC. It needs to be seen as how this can be realized on a Linux OS. Contact: Sri Gundavelli (sgundave@cisco.com) Liebsch, et al. Expires June 28, 2014 [Page 50] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 9. Security Considerations The quality of service option defined in this specification is for use in Proxy Binding Update, Proxy Binding Acknowledgement, Update Notification, and Update Notification Acknowledgement messages. This option is carried in these message like any other mobility header option. [RFC5213] and [RFC7077] identify the security considerations for these signaling messages. The quality of service option when included in these signaling messages does not require additional security considerations. Liebsch, et al. Expires June 28, 2014 [Page 51] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 10. Acknowledgements The authors of this document thank the NetExt Working Group for the valuable feedback to different versions of this specification. In particular the authors want to thank Basavaraj Patil, Behcet Sarikaya, Charles Perkins, Dirk von Hugo, Mark Grayson, Tricci So, Ahmad Muhanna, Pete McCann, Byju Pularikkal, John Kaippallimalil, Rajesh Pazhyannur, Carlos Jesus, Bernardos Cano, Michal Hoeft, Dirk Von Hugo, Ryuji Wakikawa, Liu Dapeng, Seil Jeon, Georgios Karagiannis and Brian Haberman for their valuable comments and suggestions to improve this specification. Liebsch, et al. Expires June 28, 2014 [Page 52] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010. [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, "Traffic Selectors for Flow Bindings", RFC 6088, January 2011. [RFC7077] Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and J. Korhonen, "Update Notifications for Proxy Mobile IPv6", RFC 7077, November 2013. 11.2. Informative References [GSMA.IR.34] GSMA, "Inter-Service Provider IP Backbone Guidelines 5.0", May 2013. [IEEE802.11-2012] IEEE, "Part 11: Wireless LAN Medium Access Control(MAC) and Physical Layer (PHY) specifications", 2012. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006. [RFC5149] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service Selection for Mobile IPv6", RFC 5149, February 2008. [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Liebsch, et al. Expires June 28, 2014 [Page 53] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 Code: The Implementation Status Section", RFC 6982, July 2013. [SMI] IANA, "PRIVATE ENTERPRISE NUMBERS", SMI Network Management Private Enterprise Codes, February 2011. [TS23.203] 3GPP, "Policy and charging control architecture", 2013. [TS23.402] 3GPP, "Architecture enhancements for non-3GPP accesses", 2010. Liebsch, et al. Expires June 28, 2014 [Page 54] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 Appendix A. Information when implementing 3GPP QoS in IP transport network A.1. Mapping tables Mapping between 3GPP QCI values and DSCP is defined in [GSMA.IR.34] as follows. +=====+================+===========================+======+ | QCI | Traffic Class | DiffServ Per-Hop-Behavior | 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| +=====+===================================================+ | 7 | Interactive | AF21 |010010| +=====+===================================================+ | 8 | Interactive | AF11 |001010| +=====+===================================================+ | 9 | Background | BE |000000| +=====+===================================================+ Figure 7: QCI/DSCP Mapping Table Mapping between QoS attributes defined in this document and 3GPP QoS parameters is as follows. Liebsch, et al. Expires June 28, 2014 [Page 55] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 +=======+===============================+=============+ |Section| PMIPv6 QoS | 3GPP QoS | | | Attribute | Parameter | +=======+========================+======+=============+ | 4.2.1 | Per-MN-Agg-Max-DL-Bit-Rate | UE AMBR-DL | +-------+-------------------------------+-------------+ | 4.2.2 | Per-MN-Agg-Max-UL-Bit-Rate | UE AMBR-UL | +-------+-------------------------------+-------------+ | 4.2.3 |Per-Session-Agg-Max-DL-Bit-Rate| APN AMBR-DL | | | Flags: (S=1, E=1) | | +-------+-------------------------------+-------------+ | 4.2.4 |Per-Session-Agg-Max-UL-Bit-Rate| APN AMBR-UL | | | Flags: (S=1, E=1) | | +-------+-------------------------------+-------------+ | 4.2.5 | Allocation-Retention-Priority | ARP | +-------+-------------------------------+-------------+ | 4.2.6 | Aggregate-Max-DL-Bit-Rate | MBR-DL | +-------+-------------------------------+-------------+ | 4.2.7 | Aggregate-Max-UL-Bit-Rate | MBR-UL | +-------+-------------------------------+-------------+ | 4.2.8 | Guaranteed-DL-Bit-Rate | GBR-DL | +-------+-------------------------------+-------------+ | 4.2.9 | Guaranteed-UL-Bit-Rate | GBR-UL | +-------+-------------------------------+-------------+ | 4.2.10| QoS-Traffic-Selector | TFT | +-------+-------------------------------+-------------+ Figure 8: QoS attributes and 3GPP QoS parameters Mapping Table A.2. Use cases and protocol operations This subsections provide example message flow charts for scenarios where the QoS option extensions will apply as described in (Section 6.1), to the protocol operation for QoS rules establishment as shown in Appendix A.2.1 and Appendix A.2.2, and modification as show in Appendix A.2.3. A.2.1. Handover of existing QoS rules In Figure 9, the MN is first connected to the LTE network, and having a multimedia session such as a video call with appropriate QoS parameters set by the Policy Control Function. Then, the MN discovers a Wi-Fi AP (e.g., at home or in a cafe) and switches to it provided that Wi-Fi access has a higher priority when available. Not only is the session continued, but also the QoS is maintained after moving to the Wi-Fi access. In order for that to happen, the LMA delivers the QoS parameters according to the bearer type on the 3GPP Liebsch, et al. Expires June 28, 2014 [Page 56] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 access to the MAG via the PMIPv6 signaling with the QoS option (OC=ALLOCATE, SR-ID, QoS attributes, etc.). The equivalent QoS treatment is provided by the Wi-Fi AP toward the MN on the Wi-Fi link. +--------+ |Policy | |Control | |Function| +---+----+ | +----+ +-------+ +---+----+ +--+ |LTE |_______| SGW | | PGW | |MN|~~|eNB | | |==============| (LMA) | +--+ +----+ +-------+ //+--------+ : // : // V +----+ +-------+ PMIPv6 // +--+ |WiFi|_______| WLC |========= |MN|~~| AP | | (MAG) | tunnel +--+ +----+ +-------+ Figure 9: Handover Scenario (from LTE to WLAN) Figure 10 shows an example of how the QoS rules can be conveyed and enforced between the LMA and MN in the case of handover from 3GPP access to WLAN access. Liebsch, et al. Expires June 28, 2014 [Page 57] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 +--+ +--+ +---+ +---+ |MN| |AP| |MAG| |LMA| +--+ +--+ +---+ +---+ || | | To |data |+--detach | | cellular<-==data[DSCP]==-|<---- +----attach-----+ | access [QoS rules] | |-INFO[MNattach]->| | | | |-------PBU[handover]------>| | | | | | | |<--PBA[QoS option(OC=1 )]--| | |<-INFO[QoSrules]-| | | | | | | Apply Establish Update | mapped MN's uplink MN's downlink | QoS rules DSCP rules DSCP rules | | +===========================+ | | | | | |(B) |(A) |data |<--data[QC]----|<---data[DSCP]---|<-======data[DSCP]========-|<---- | | | | | | | |data |---data[QC]--->|-->data[DSCP]--->|-=======data[DSCP]=======->|---> | |(C) |(D) | | | | | (A): Apply DSCP at link to AP (B): Enforce mapped QoS rules to access technology (C): Map MN-indicated QoS Class (QC) to DSCP on the AP-MAG link, or validate MN-indicated QC and apply DSCP on the AP-MAG link according to QoS rules (D): Validate received DSCP and apply DSCP according to QoS rules Figure 10: Handover of QoS rules A.2.2. Establishment of QoS rules A single operator has deployed both a fixed access network and a mobile access network. In this scenario, the operator may wish a harmonized QoS management on both accesses, but the fixed access network does not implement a QoS control framework. So, the operator chooses to rely on the 3GPP policy control function, which is a standard framework to provide a QoS control, and to enforce the 3GPP QoS policy on the Wi-Fi Access network. The PMIP interface is used to realize this QoS policy provisioning. The use-case is depicted on Figure 11. The MN first attaches to the Wi-Fi network. During the attachment process, the LMA, which may Liebsch, et al. Expires June 28, 2014 [Page 58] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 communicate with Policy Control Function (using procedures outside the scope of this document), provides the QoS parameters to the MAG via the QoS option (OC=ALLOCATE) in the PMIP signaling (i.e. PBA). Subsequently, an application on the MN may trigger the request for alternative QoS resources, e.g., by use of the WMM-API. The MN may request traffic resources be reserved using L2 signaling, e.g., sending an ADDTS message [IEEE802.11-2012]. The request is relayed to the MAG which includes the QoS parameters in the QoS option (OC=ALLOCATE) on the PMIP signaling (i.e. the PBU initiated upon flow creation). The LMA, in co-ordination with the PCF, can then authorize the enforcement of such QoS policy. Then, the QoS parameters are provided to the MAG via the QoS option (OC=ALLOCATE, SR-ID, QoS attributes, etc.) in the PMIP signaling and the equivalent QoS treatment is provided towards the MN on the Wi-Fi link. | | | +--------+ | |Policy | | |Control | | |Function| | +---+----+ | | | +---+----+ +----+ +-------+ PMIPv6 | | PGW | +--+ |WiFi|_______| WLC |========|=| (LMA) | |MN|~~| AP | | (MAG) | tunnel | +--------+ +--+ +----+ +-------+ | | Wi-Fi Access | Network | Cellular | Network | Figure 11: QoS policy provisioning Figure 12 shows an example of how the QoS rules can be conveyed and enforced between the LMA and MN in the case of initial attachment to WLAN access. Liebsch, et al. Expires June 28, 2014 [Page 59] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 +--+ +--+ +---+ +---+ |MN| |AP|-------------|MAG|-----------------------|LMA| +--+ +--+ +---+ +---+ | | | | | | | | +----attached---+ | [QoS rules] | | | | new session |(E) |(F) |data |----data[QC]-->|---data[DSCPa]-->|-======data[DSCPb]=======->|---> | | |--PBU[update,QoS option]-->| | | | (ReReg) (OC=1) Validate and | | | add QoS rule | | |<----PBA[QoS option]----| | |<-INFO[QoSrules]-| (OC=1, SR-ID)[QoS rules'] | | | | | Apply Establish | | adapted MN's uplink | | QoS rules DSCP rules | | | | | | | | | | | | |data |<--data[QC]----|<---data[DSCP]---|<-======data[DSCP]========-|<---- | | | | | | | |data |---data[QC]--->|-->data[DSCP]--->|-=======data[DSCP]=======->|---> | | | | | | | | (E): AP may enforce uplink QoS rules according to priority class set by the MN (F): MAG can enforce a default QoS class until local mobility anchor has classified the new flow (notified with PBA) or mobile access gateway classifies new flow and proposes the associated QoS class to the local mobility anchor for validation (proposed with PBU, notification of validation result with PBA) Figure 12: Adding new QoS Service Request for MN initiated flow A.2.3. Dynamic Update to QoS Policy A mobile node is attached to the WLAN access and has obtained QoS parameters from the LMA for that mobility session. Having obtained the QoS parameters, a new application, e.g. IMS application, gets launched on the mobile node that requires certain QoS support. The application on the mobile node initiates the communications via a dedicated network function (e.g. IMS Call Session Control Function). Liebsch, et al. Expires June 28, 2014 [Page 60] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 Once the communication is established, the application network function notifies the PCF about the new IP flow. The PCF function in turn notifies the LMA about the needed QoS parameters identifying the IP flow and QoS parameters. LMA sends an Update Notification message [RFC7077] to the MAG with the Notification Reason value set to "QOS_SERVICE_REQUEST". The MAG, on receiving the Update Notification message, completes the PBU/PBA signaling for obtaining the new QoS parameters via the QoS options (OC=MODIFY, SR-ID, QoS attributes, etc.). The MAG provisions the newly obtained QoS parameters on the access network to ensure the newly established IP flow gets its requested network resources. Upon termination of the established IP flow, the application network function again notifies the PCF function for removing the established QoS parameters. The PCF notifies the LMA for withdrawing the QoS resources established for that voice flow. The LMA sends an Update Notification message to the MAG with the "Notification Reason" value set to "FORCE-REREGISTRATION". The MAG on receiving this message Update Notification Acknowledgement and completes the PBU/PBA signaling for removing the existing QoS rules (OC=DE-ALLOCATE, SR-ID). The MAG then removes the QoS parameters from the corresponding IP flow and releases the dedicated network resources on the access network. Liebsch, et al. Expires June 28, 2014 [Page 61] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 Appendix B. Information when implementing PMIP based QoS support with IEEE 802.11e This section shows, as an example, the end-to-end QoS management with a 802.11e capable WLAN access link and a PMIP based QoS support. The 802.11e, or Wi-Fi Multimedia (WMM), specification provides prioritization of packets for four types of traffic, or access categories (AC): Voice (AC_VO): Very high priority queue with minimum delay. Time- sensitive data such as VoIP and streaming mode are automatically sent to this queue. Video (AC_VI): High priority queue with low delay. Time-sensitive video data is automatically sent to this queue. Best effort (AC_BE): Medium priority queue with medium throughput and delay. Most traditional IP data is sent to this queue. Background (AC_BK): Lowest priority queue with high throughput. Bulk data that requires maximum throughput but is not time- sensitive (for example, FTP data) is sent to the queue. The access point uses the 802.11e indicator to prioritize traffic on the WLAN interface. On the wired side, the access point uses the 802.1p priority tag and DiffServ code point (DSCP). To allow consistent QoS management on both wireless and wired interfaces, the access point relies on the 802.11e specification which define mapping between the 802.11e access categories and the IEEE 802.1D priority (802.1p tag). The end-to-end QoS architecture is depicted on Figure 13 and the 802.11e/802.1D priority mapping is reminded in the following table: +-----------+------------------+ | 802.1e AC | 802.1D priority | +-----------+------------------+ | AC_VO | 7,6 | +-----------+------------------+ | AC_VI | 5,4 | +-----------+------------------+ | AC_BE | 0,3 | +-----------+------------------+ | AC_BK | 2,1 | +-----------+------------------+ Liebsch, et al. Expires June 28, 2014 [Page 62] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 +=============+ +-----+ DSCP/802.1p | PDP | mapping table +-----+ +=============+ PEP | `._ +---+---+ | `._ |WiFi AR| PMIPv6 +-----+ - + (MAG) +===============| LMA | | WLC | tunnel +-----+ +-------+ PEP | ==Video== 802.1p/DSCP ==Voice== | == B.E.== +----+ +----+ |WLAN| PEP | MN |----802.11e----| AP | +----+ +----+ Figure 13: End-to-end QoS management with 802.11e When receiving a packet from the MN, the AP checks whether the frame contains 802.11e markings in the L2 header. If not, the AP checks the DSCP field. If the uplink packet contains the 802.11e marking, the access point maps the access categories to the corresponding 802.1D priority as per the table above. If the frame does not contain 802.11e marking, the access point examines the DSCP field. If DSCP is present, the AP maps DSCP values to a 802.1p value (i.e 802.1D priority). This mapping is not standardized and may differ between operator; a mapping example given in the following table. +-------------------+--------+------------+ | Type of traffic | 802.1p | DSCP value | +-------------------+--------+------------+ | Network Control | 7 | 56 | +-------------------+--------+------------+ | Voice | 6 | 46 (EF) | +-------------------+--------+------------+ | Video | 5 | 34 (AF 41) | +-------------------+--------+------------+ | voice control | 4 | 26 (AF 31) | +-------------------+--------+------------+ | Background Gold | 2 | 18 (AF 21) | +-------------------+--------+------------+ | Background Silver | 1 | 10 (AF 11) | +-------------------+--------+------------+ | Best effort | 0,3 | 0 (BE) | +-------------------+--------+------------+ The access point prioritizes ingress traffic on the Ethernet port Liebsch, et al. Expires June 28, 2014 [Page 63] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 based on the 802.1p tag or the DSCP value. If 802.1p priority tag is not present, the access point checks the DSCP/802.1p mapping table. The next step is to map the 802.1p priority to the appropriate egress queue. When 802.11e support is enabled on the wireless link, the access point uses the IEEE standardized 802.1p/802.11e correspondence table to map the traffic to the appropriate hardware queues. When the 802.11e capable client sends traffic to the AP, it usually marks packets with a DSCP value. In that case, the MAG/LMA can come into play for QoS renegotiation and call flows depicted in Appendix A apply. Sometimes, when communication is initiated on the WLAN access, the application does not mark upstream packets. If the uplink packet does not contain any QoS marking, the AP/MAG could determine the DSCP field according to traffic selectors received from the LMA. Figure 14 gives the call flow corresponding to that use- case and shows where QoS tags mapping does come into play. The main steps are as follows: (A): during MN attachment process, the MAG fetches QoS policies from the LMA. After this step, both MAG and LMA are provisioned with QoS policies. (B): the MN starts a new IP communication without making IP packets with DSCP tags. The MAG uses the traffic selector to determine the DSCP value, then it marks the IP packet and forwards within the PMIP tunnel. (C): the LMA checks the DSCP value with respect to the traffic selector. If the QoS policies is valid, the LMA forwards the packet without renegotiating the QoS rules. (D): when receiving a marked packet, the MAG, the AP and the MN use 802.11e (or WMM), 802.1p tags and DSCP values to prioritize the traffic. Liebsch, et al. Expires June 28, 2014 [Page 64] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 +--+ +--+ +---+ +---+ |MN| |AP| |MAG| |LMA| +--+ + -+ +---+ +---+ (A)|----attach-----|---------------->|-----------PBU---------->| |<--------------|---------------- |<----PBA[QoS option]-----| . . [QoS rules] [QoS rules] (B). . . | new session | | | |----data[]---->|----data[]------>|-======data[DSCP]======->| | | | | (C)| | | Validate QoS rule | | | |---> | | |<======data[DSCP]========|<---- | | | | | | mapping | (D)| | DSCP/802.1p | | |<----data--------| | | | [802.1p/DSCP] | | | | | | | mapping | | | 802.1p/802.11e | | |<--data[WMM]---| | | | | | | |---data[WMM]-->|------data------>|=======data[DSCP]=======>|---> | | [802.1p/DSCP] | | | | | | Figure 14: Prioritization of a flow created on the WLAN access Liebsch, et al. Expires June 28, 2014 [Page 65] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 Appendix C. Information when implementing with a Broadband Network Gateway This section shows an example of QoS interworking between the PMIPv6 domain and the broadband access. The Broadband Network Gateway (BNG) or Broadband Remote Access Server (BRAS) has the MAG function and the CPE (Customer Premise Equipment) or Residential Gateway (RG) is connected via the broadband access network. The MN is attached to the RG via e.g., Wi-Fi AP in the broadband home network. In the segment of the broadband access network, the BNG and RG are the Policy Enforcement Point (PEP) for the downlink and uplink traffic, respectively. The QoS information is downloaded from the LMA to the BNG via the PMIPv6 with the QoS option defined in this document. Based on the received QoS parameters (e.g., DSCP values), the broadband access network and the RG provide appropriate QoS treatment to the downlink and uplink traffic to/from the MN. +-----+ | PDP | +-----+ PEP | +-------+ | | BNG/ | PMIPv6 +-----+ | BRAS +===============| LMA | | (MAG) | tunnel +-----+ +-------+ PEP Broadband ( | ) Access ( DSCP ) Network ( | ) +-----+ +----+ | CPE | PEP | MN |-------------| /RG | +----+ Broadband +-----+ Home Network Figure 15: End-to-end QoS management with the broadband access network In the segment of the broadband access network, QoS mapping between 3GPP QCI values and DSCP described in Section 6.2 is applied. In the segment of the broadband home network, if the MN is attached to the RG via Wi-Fi, the same QoS mapping as described in Appendix B can be applied. Liebsch, et al. Expires June 28, 2014 [Page 66] Internet-Draft QoS Support for Proxy Mobile IPv6 December 2013 Authors' Addresses Marco Liebsch NEC Kurfuersten-Anlage 36 Heidelberg D-69115 Germany Email: liebsch@neclab.eu Pierrick Seite Orange 4, rue du Clos Courtel, BP 91226 Cesson-Sevigne 35512 France Email: pierrick.seite@orange.com Hidetoshi Yokota KDDI Lab 2-1-15 Ohara Saitama, Fujimino 356-8502 Japan Email: yokota@kddilabs.jp Jouni Korhonen Broadcom Communications Porkkalankatu 24 Helsinki FIN-00180 Finland Email: jouni.nospam@gmail.com Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: sgundave@cisco.com Liebsch, et al. Expires June 28, 2014 [Page 67] --------------030606030902070108040903-- From sgundave@cisco.com Mon Feb 3 06:52:58 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 A615A1A012F for ; Mon, 3 Feb 2014 06:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.136 X-Spam-Level: X-Spam-Status: No, score=-13.136 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, 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 QNONxiYfHxIG for ; Mon, 3 Feb 2014 06:52:55 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3C21A0165 for ; Mon, 3 Feb 2014 06:52:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7566; q=dns/txt; s=iport; t=1391439168; x=1392648768; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=1vPEKEkaWHp6p1XGYr/457keJ1GVRz/pze+yfM80F1Q=; b=evPm/Ld0Rzj4WCkHcbAO1yyFBz4Qs7PwOfQym2yVn7m2PbuHi/0A1Ogo Owsni0UEYiHrcOCFjJ5UVvW2YA4dhuSe5820u76Hmj8DyD01fcFLlOOiK DP/nTG1orm47mdIfJgxyI9dB0pidGGcRSPO3CiNSmEtxWTMp0pQtEWoPp E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAM+s71KtJV2d/2dsb2JhbABZgww4V4MBujhPGHEWdIIlAQEBBAEBARoGEToLEgEGAhgCAiYCBB8GCxUQAgQOBYdxAxENj1KbcZdqDYkzEwSBKYtKgT8kGBsHgm+BSQEDlj6BbIxehUODLYFpQQ X-IronPort-AV: E=Sophos;i="4.95,772,1384300800"; d="scan'208";a="301561275" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 03 Feb 2014 14:52:48 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s13Eqmck028278 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Feb 2014 14:52:48 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.95]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Mon, 3 Feb 2014 08:52:48 -0600 From: "Sri Gundavelli (sgundave)" To: "Charles E. Perkins" Thread-Topic: [netext] WGLC for I-D: draft-ietf-netext-pmip6-qos Thread-Index: AQHPIO+aEuuXEJgga0eO4KukjKmZwQ== Date: Mon, 3 Feb 2014 14:52:47 +0000 Message-ID: In-Reply-To: <52EDB392.7050300@computer.org> 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.213] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "netext@ietf.org" , "draft-ietf-netext-pmip6-qos@tools.ietf.org" Subject: Re: [netext] WGLC for I-D: draft-ietf-netext-pmip6-qos 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, 03 Feb 2014 14:52:58 -0000 SGkgQ2hhcmxpZSwNCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3IGFuZCBmb3IgdGhlIHByb3Bvc2Vk IGNoYW5nZXMgdG8gdGhlIHRleHQuIFZlcnkgbXVjaA0KYXBwcmVjaWF0ZWQuDQoNCldlIChBdXRo b3JzKSBoYXZlIGRpc2N1c3NlZCB5b3VyIGNvbW1lbnRzIGFuZCBoZXJlIGlzIG91ciByZXNwb25z ZSB0byB5b3VyDQpjb21tZW50cy4NCg0KDQoNCk9uIDIvMS8xNCA2OjU1IFBNLCAiQ2hhcmxlcyBF LiBQZXJraW5zIiA8Y2hhcmxpZXBAY29tcHV0ZXIub3JnPiB3cm90ZToNCg0KPg0KPkhlbGxvIGZv bGtzLA0KPg0KPkkgZGlkbid0IGhhdmUgdGltZSBmb3IgYSBjb21wbGV0ZSByZXZpZXcsIGJ1dCBJ IGRpZCBtYWtlDQo+dGhlIGZvbGxvd2luZyBub3Rlcy4NCj4NCj49PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPg0KPlN1Z2dlc3Rpb246IHVzZSBLYi9z ZWMgb3IgYXQgbGVhc3QgYnl0ZXMvc2VjIGFzIHRoZSB1bml0cy4NCj5XaXRoIDgwMi4xMWFjLCB3 ZSBhcmUgYWxyZWFkeSBvdmVyIHRoZSBsaW1pdCBvZiB3aGF0IDMyIGJpdHMgY2FuDQo+bWVhc3Vy ZSBmb3IgdHJhbnNtaXNzaW9uIHJhdGVzIG1lYXN1cmVkIGluIGJpdHMvc2VjLg0KDQpUaGlzIGlz IGEgcmVhc29uYWJsZSBzdWdnZXN0aW9uLiBXZSBoYWQgYSBkaXNjdXNzaW9uIG9uIHRoaXMgd2l0 aCBHZW9yZ2lvcw0KYmVmb3JlLg0KV2l0aCAzMi1iaXQgbnVtYmVyIHdlIGNhbiByZXByZXNlbnQg dXAgdG8gNEdiIGFuZCB3ZSB0aG91Z2h0IHdlIGFyZQ0KY292ZXJlZCBmb3IgYW55IG9mIHRoZSBj dXJyZW50IGFjY2VzcyB0ZWNobm9sb2dpZXMgdGhhdCBhcmUgc3VwcG9ydGVkDQp0b2RheSBpbmNs dWRpbmcgODAyLjExYWMuDQpBbHNvLCBnaXZlbiB0aGF0IHRoaXMgaXMgYWxzbyBhbGlnbmVkIHdp dGggM0dQUCwgd2UgY2hvc2UgdG8ga2VlcCB0aGUNCnVuaXRzIGFzICJicHMiLg0KDQoNCj4NCj5U ZXJtaW5vbG9neSBzaG91bGQgYmUgYWxwaGFiZXRpemVkLg0KDQpPay4NCg0KPg0KPlRoZSB0ZXJt ICJzdWItb3B0aW9ucyIgaXMgbmV2ZXIgdXNlZC4NCg0KV2lsbCBmaXggaXQuDQoNCg0KPg0KPlNo b3VsZCB1c2UgYWJicmV2aWF0aW9ucyBMTUEgYW5kIE1BRyBtb3N0IG9mIHRoZSB0aW1lDQo+YWZ0 ZXIgaW50cm9kdWNpbmcgdGhlbSBhbmQgY2l0aW5nIFJGQyA1MjEzLiAgNTIxMyB1c2VzIHRoZW0N Cj5tb3N0IG9mIHRoZSB0aW1lLCB3aHkgbm90IHRoaXMgZG9jdW1lbnQ/DQoNCldoZW4gd2Ugd2Vy ZSB3cml0aW5nIFJGQzUyMTMvUkZDNTg0NCwgd2UgbG9va2VkIGF0IFJGQzMzNDQgYW5kIFJGQzM3 NzUNCmNhcmVmdWxseSBhbmQgZm9sbG93ZWQgdGhlIHNhbWUgY29udmVudGlvbnMuIFRoYXQgcHJl dHR5IG11Y2ggY29udGludWVkDQphbmQgYWxsIHRoZSBQTUlQIHNwZWNzIGZvbGxvd2VkIHRoZSBz YW1lIGNvbnZlbnRpb25zLiBJIGRvIGFncmVlLCB0aGlzDQptYWtlcyB0aGUgZG9jIGxlbmd0aHks IGJ1dCBrZWVwcyBpdCBjb25zaXN0ZW50LiBJZiB5b3UgYXJlIG5vdCB0b28ga2VlbiBvbg0KdGhp cywgd2UgcHJlZmVyIHRvIGtlZXAgdGhpcyBjb25zaXN0ZW50IHdpdGggdGhlIG90aGVyIHNwZWNz Lg0KDQoNCg0KPg0KPldoYXQgYWJvdXQgUXVhbGl0eSBvZiBTZXJ2aWNlIEF0dHJpYnV0ZSB0eXBl cyAxMiB0aHJvdWdoIDI1NA0KPmluIHNlY3Rpb24gNC4yPw0KDQpUaGFua3MuIFdpbGwgYWRkIGFu IGV4cGxpY2l0IG5vdGUgdGhhdCB0aG9zZSB2YWx1ZXMgYXJlIFJlc2VydmVkLg0KDQoNCj4NCj5J biBzZWN0aW9uIDQuMi41LiAgQWxsb2NhdGlvbiBhbmQgUmV0ZW50aW9uIFByaW9yaXR5LA0KPml0 IGlzIG5vdCBjbGVhciB3aHkgUHJpb3JpdHktTGV2ZWwsIFByZWVtcHRpb24tQ2FwYWJpbGl0eSwN Cj5hbmQgUHJlZW1wdGlvbi1WdWxuZXJhYmlsaXR5IGFyZSBkZWZpbmVkIHRvIHRha2UgdXAgNjQN Cj5iaXRzLCB3aGVuIGFsbCB0aGUgdmFsdWVzIHRoYXQgaGF2ZSBiZWVuIGRlZmluZWQgd291bGQN Cj5lYXNpbHkgZml0IHdpdGhpbiBsZXNzIHRoYW4gaGFsZiBvZiB0aGUgUmVzZXJ2ZWQgZmllbGQu DQo+UGVyaGFwcyBzb21lIGp1c3RpZmljYXRpb24gaXMgaW5kaWNhdGVkIGZvciB0aGlzIGRlc2ln bi4NCg0KDQpPSy4gV2UgZ290IHRoZSBzYW1lIHJldmlldyBjb21tZW50IGVhcmxpZXIgZnJvbSBv bmUgb3RoZXIgcmV2aWV3ZXIuIFdlDQp3aWxsIGNoYW5nZSB0aGUgZm9ybWF0IHRvIHRoZSBmb2xs b3dpbmcuDQoNCg0KICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAy ICAgICAgICAgICAgICAgICAgIDMNCiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1 IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICAgICBU eXBlICAgICAgfCAgICAgTGVuZ3RoICAgIHwgICBSZXNlcnZlZCAgICB8ICAgUEwgIHxQQyB8UFYg fA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsNCg0KUEw6IFByaW9yaXR5IExldmVsIDEtMTUgKDRiaXRzKQ0KUEM6IFBy ZS1lbXB0aW9uIENhcGFiaWxpdHkgMC8xICgyIGJpdHM7IDEgYml0IGlzIGEgc3BhcmUgYXMgaW4g R1RQIGZvcm1hdCkNClBWOiBQcmUtZW1wdGlvbiBWdWxuZXJhYmlsaXR5IDAvMSAoc2FtZSBhcyB0 aGUgYWJvdmUpDQoNCg0KPg0KPldvcnNlIHlldCwgdGhlcmUgaXMgYWJzb2x1dGVseSBubyBoaW50 IHRvIHRoZSBpbXBsZW1lbnRlcg0KPmFib3V0IGhvdyB0aGUgZmVhdHVyZXMgYXJlIHRvIGJlIHVz ZWQuICBJZiB0aGVyZSBpcyBzb21lDQo+b3RoZXIgZG9jdW1lbnQgYXZhaWxhYmxlIGZvciB0aGlz IHB1cnBvc2UsIGl0IHNob3VsZCBiZQ0KPmNpdGVkLiAgT3RoZXJ3aXNlLCBzb21lIGFkZGl0aW9u YWwgZGVzY3JpcHRpb24gaXMgcmVxdWlyZWQNCj5pbiB0aGlzIGRvY3VtZW50Lg0KDQpBY2suIFdp bGwgY3JhZnQgc29tZSB0ZXh0Lg0KDQoNCj4NCj5JbiBzZWN0aW9uIDQuMi4xMC4gIFFvUyBUcmFm ZmljIFNlbGVjdG9yLA0KPnRoZSBmb3JtYXQgb2YgdGhlIFRyYWZmaWMgU2VsZWN0b3IgaXMgKk5P VCogb3BhcXVlLg0KPkl0IGZvbGxvd3MgdGhlIHNwZWNpZmljYXRpb25zIGNpdGVkIGluIHRoZSBw cmV2aW91cw0KPnBhcmFncmFwaCwgcmlnaHQ/Pw0KDQoNCk9rLiBXaWxsIGZpeCBpdC4NCg0KDQo+ DQo+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KPg0KPkkgbWFkZSBhIGZldyBlZGl0b3JpYWwgaW1wcm92ZW1lbnRzLCB3aGljaCBj YW4gYmUgc2VlbiBhcyBzaG93biBpbg0KPnRoZSBhdHRhY2hlZCBmaWxlLiBTb3JyeSwgZm9yIHNv bWUgcmVhc29uIEkgY2FuJ3QgZ2V0IHJmY2RpZmYgdG8gd29yaw0KPnJpZ2h0IG5vdy4NCg0KQWNr LiBXaWxsIGltcGxlbWVudCB0aG9zZSBjaGFuZ2VzLg0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXcu IFRoaXMgcmVhbGx5IGhlbHBzLg0KDQpSZWdhcmRzDQpTcmkNCg0KDQoNCj4NCj5SZWdhcmRzLA0K PkNoYXJsaWUgUC4NCj4NCj4NCj5PbiAxLzMwLzIwMTQgMToyNCBBTSwgUnl1amkgV2FraWthd2Eg d3JvdGU6DQo+PiBSYWosDQo+Pg0KPj4gSSBkb27DouKCrOKEonQgc2VlIGFueSBpc3N1ZSBpbiB0 aGlzIHZlcnNpb24uDQo+PiBUaGUgZHJhZnQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLg0KPj4N Cj4+IHRoYW5rcw0KPj4gcnl1amkNCj4+DQo+PiAyMDE0LzAxLzIzIMOlwo3LhsOl4oCwwo04OjMz w6PigqzCgUJhc2F2YXJhaiBQYXRpbCA8YnBhdGlsMUBnbWFpbC5jb20+DQo+PsOjwoHCrsOjxpLC ocOjxpLCvMOjxpLCq8OvwrzFoQ0KPj4NCj4+PiBIZWxsbywNCj4+Pg0KPj4+IFRoaXMgaXMgdGhl IFdHIGxhc3QgY2FsbCBmb3IgdGhlIEktRDogUXVhbGl0eSBvZiBTZXJ2aWNlIE9wdGlvbiBmb3IN Cj4+PiBQcm94eSBNb2JpbGUgSVB2NiA8ZHJhZnQtaWV0Zi1uZXRleHQtcG1pcDYtcW9zLTEwLnR4 dD4NCj4+Pg0KPj4+IEFic3RyYWN0DQo+Pj4NCj4+PiAgICAgVGhpcyBzcGVjaWZpY2F0aW9uIGRl ZmluZXMgYSBuZXcgbW9iaWxpdHkgb3B0aW9uLCB0aGUgUXVhbGl0eSBvZg0KPj4+ICAgICBTZXJ2 aWNlIChRb1MpIG9wdGlvbiwgZm9yIFByb3h5IE1vYmlsZSBJUHY2LiAgVGhpcyBvcHRpb24gY2Fu IGJlDQo+Pj51c2VkDQo+Pj4gICAgIGJ5IHRoZSBsb2NhbCBtb2JpbGl0eSBhbmNob3IgYW5kIHRo ZSBtb2JpbGUgYWNjZXNzIGdhdGV3YXkgZm9yDQo+Pj4gICAgIG5lZ290aWF0aW5nIFF1YWxpdHkg b2YgU2VydmljZSBwYXJhbWV0ZXJzIGZvciBhIG1vYmlsZSBub2RlJ3MgSVANCj4+PiAgICAgZmxv d3MuICBUaGUgbmVnb3RpYXRlZCBRb1MgcGFyYW1ldGVycyBjYW4gYmUgdXNlZCBmb3IgUW9TIHBv bGljaW5nDQo+Pj4gICAgIGFuZCBtYXJraW5nIG9mIHBhY2tldHMgdG8gZW5mb3JjZSBRb1MgZGlm ZmVyZW50aWF0aW9uIG9uIHRoZSBwYXRoDQo+Pj4gICAgIGJldHdlZW4gdGhlIGxvY2FsIG1vYmls aXR5IGFuY2hvciBhbmQgdGhlIG1vYmlsZSBhY2Nlc3MgZ2F0ZXdheS4NCj4+PiAgICAgRnVydGhl cm1vcmUsIG1ha2luZyBRb1MgcGFyYW1ldGVycyBhdmFpbGFibGUgb24gdGhlIG1vYmlsZSBhY2Nl c3MNCj4+PiAgICAgZ2F0ZXdheSBlbmFibGVzIG1hcHBpbmcgb2YgdGhlc2UgcGFyYW1ldGVycyB0 byBRb1MgcnVsZXMgdGhhdCBhcmUNCj4+PiAgICAgc3BlY2lmaWMgdG8gdGhlIGFjY2VzcyB0ZWNo bm9sb2d5IGFuZCBhbGxvd3MgdGhvc2UgcnVsZXMgdG8gYmUNCj4+PiAgICAgZW5mb3JjZWQgb24g dGhlIGFjY2VzcyBuZXR3b3JrIHVzaW5nIGFjY2VzcyB0ZWNobm9sb2d5IHNwZWNpZmljDQo+Pj4g ICAgIGFwcHJvYWNoZXMuDQo+Pj4NCj4+PiBUaGUgSS1EIGlzIGludGVuZGVkIGZvciBwdWJsaWNh dGlvbiBhcyBhIHByb3Bvc2VkIHN0YW5kYXJkLg0KPj4+IFRoZSBkZWFkbGluZSBmb3IgcmVjZWl2 aW5nIHJldmlld3MsIGNvbW1lbnRzLCBmZWVkYmFjayBpcyBGZWJydWFyeSA3dGgsDQo+Pj4gMjAx NC4NCj4+Pg0KPj4+IFBsZWFzZSBzZW5kIHlvdXIgcmV2aWV3IGNvbW1lbnRzIHRvIHRoZSBtYWls aW5nIGxpc3QsIGNoYWlycyBvciwNCj4+PiBhdXRob3JzLg0KPj4+DQo+Pj4gLUNoYWlycw0KPj4+ DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ PiBuZXRleHQgbWFpbGluZyBsaXN0DQo+Pj4gbmV0ZXh0QGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRleHQNCj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBuZXRleHQgbWFpbGluZyBsaXN0DQo+ PiBuZXRleHRAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0ZXh0DQo+DQo+DQo+DQo+DQo+LS0gDQo+UmVnYXJkcywNCj5DaGFybGllIFAuDQoNCg== From sarikaya2012@gmail.com Wed Feb 5 08:36:34 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 EFB791A01FD for ; Wed, 5 Feb 2014 08:36:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 QjAM1ErLpavP for ; Wed, 5 Feb 2014 08:36:32 -0800 (PST) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 771701A01FE for ; Wed, 5 Feb 2014 08:36:32 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id ec20so529108lab.9 for ; Wed, 05 Feb 2014 08:36:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; bh=r5tlfPbHv/NEokLtA7SFtOu4vwdB1fF3sN/eifaDBHY=; b=XCWpSPt9OLf8OWMiNIxguFe+p5eyd4OrIhu0a19OcAnmT3z1Ld9pf6BtoAZPbZjKeO eGfwnNGnmtumkapSazpLMaupMsGTvO17wFHuP7K1yGAHERAJbCVQIJFZVTqE5+FNcmXu JU4KQILZ/4Dz0e6unnhthyOgc65byBZAKlANSHVYUCtV9m2pS9tG21wlh0MzT+Ps8quK iATVwiiKk9OVelunhEgMA+aBFGDdDlTJKJk9slBoj63DfzGyGj/qKFSn7Vh5hqFT6kzX w/ATO0oWDZuHmfQRVs559VHdFJ/yjQ8FI5vBsYbCeAHKklo8F2fx22bGfRaEZR137qj1 X5ZQ== MIME-Version: 1.0 X-Received: by 10.152.43.47 with SMTP id t15mr1752384lal.38.1391618190978; Wed, 05 Feb 2014 08:36:30 -0800 (PST) Received: by 10.114.170.193 with HTTP; Wed, 5 Feb 2014 08:36:30 -0800 (PST) Date: Wed, 5 Feb 2014 10:36:30 -0600 Message-ID: From: Behcet Sarikaya To: "Carlos J. Bernardos" Content-Type: multipart/alternative; boundary=001a11c24100efb25104f1ab5b0c Cc: "netext@ietf.org" Subject: [netext] draft-ietf-netext-pmipv6-flowmob-08 and RFC 7109 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org 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, 05 Feb 2014 16:36:34 -0000 --001a11c24100efb25104f1ab5b0c Content-Type: text/plain; charset=ISO-8859-1 Hi Carlos, Please take a look at the newly published RFC 7109, http://tools.ietf.org/html/rfc7109 This RFC is very relevant to draft-ietf-netext-pmipv6-flowmob, due to HA-LMA relationship. New Flow Binding messages defined in RFC 7109 are very relevant. Mobility option extensions to Flow Identification Mobility option defined in RFC 7109 are also very relevant. There is point in reinventing the wheel. Here it is there make use of it. By the way I don't mind if you wish to keep using BID anymore :-) Regards, Behcet --001a11c24100efb25104f1ab5b0c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Carlos,

Plea= se take a look at the newly published RFC 7109,
http://tools.ietf.org/html/rfc7109

= This RFC is very relevant to draft-ietf-netext-pmipv6-flowmob, due to HA-LM= A relationship.

New Flow Binding messages defined in RFC 7109 are very relevant.<= br>
Mobility option extensions to Flow Identification Mobility option de= fined in RFC 7109 are also very relevant.

There is point in re= inventing the wheel. Here it is there make use of it.=A0 By the way I don&#= 39;t mind if you wish to keep using BID anymore :-)

Regards,

Behcet
--001a11c24100efb25104f1ab5b0c-- From brian@innovationslab.net Wed Feb 5 11:33:02 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 B0BF31A0138 for ; Wed, 5 Feb 2014 11:33:02 -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 MJQG7jthmRvs for ; Wed, 5 Feb 2014 11:33:00 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA901A00EB for ; Wed, 5 Feb 2014 11:32:59 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 71F9A880F3 for ; Wed, 5 Feb 2014 11:32:59 -0800 (PST) Received: from clemson.local (c-76-21-129-88.hsd1.md.comcast.net [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 2D7B21368154 for ; Wed, 5 Feb 2014 11:32:59 -0800 (PST) Message-ID: <52F291E9.6030309@innovationslab.net> Date: Wed, 05 Feb 2014 14:32:57 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: netext@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qX2hmwbgdoTFtecjdeM7xpaanTI40PMP1" Subject: Re: [netext] draft-ietf-netext-pmipv6-flowmob-08 and RFC 7109 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: Wed, 05 Feb 2014 19:33:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qX2hmwbgdoTFtecjdeM7xpaanTI40PMP1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Keeping in mind that 7109 is a non-consensus & experimental RFC via the Independent Stream... On 2/5/14 11:36 AM, Behcet Sarikaya wrote: > Hi Carlos, >=20 > Please take a look at the newly published RFC 7109, > http://tools.ietf.org/html/rfc7109 >=20 > This RFC is very relevant to draft-ietf-netext-pmipv6-flowmob, due to > HA-LMA relationship. >=20 > New Flow Binding messages defined in RFC 7109 are very relevant. >=20 > Mobility option extensions to Flow Identification Mobility option defin= ed > in RFC 7109 are also very relevant. >=20 > There is point in reinventing the wheel. Here it is there make use of i= t. > By the way I don't mind if you wish to keep using BID anymore :-) >=20 > Regards, >=20 > Behcet >=20 >=20 >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext >=20 --qX2hmwbgdoTFtecjdeM7xpaanTI40PMP1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS8pHpAAoJEBOZRqCi7goqztkH/2ZtxVjrwi8UBOc9f2E5C+vh t6pkAjAIBn+gM/+DRlU9fLtVllII+O8zvsS+nRshEEbDwdoNscty4mrgzXL61ige R4kOqmIXDNYMSapxlkNIWzLpQnVv9Ow/JqkuVz5Qup/vNeK5XMbHBoMtCOY09lUG atyelUg0yHOuQj36DR6XNUD9w2jCSx6vhn0/eUVJy2hdN0XA5BBvc1ZBRFGBxVos 7/kQJxlFnqsy4Zl5WS+LsnHNFGZ/3iHbqX5qp0lsBcaed+FjajWul/jyM7HxN8/z 1nDgaqSi2ladTnW411LfLzciQERNnATfcCRldYem8QmFfbLGx3APYST/WhUOWsY= =V49W -----END PGP SIGNATURE----- --qX2hmwbgdoTFtecjdeM7xpaanTI40PMP1-- From sarikaya2012@gmail.com Thu Feb 6 07:34:19 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 962671A013D for ; Thu, 6 Feb 2014 07:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 YrT5pJ2MJzqQ for ; Thu, 6 Feb 2014 07:34:18 -0800 (PST) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id A83371A0186 for ; Thu, 6 Feb 2014 07:34:17 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id ec20so1623855lab.9 for ; Thu, 06 Feb 2014 07:34:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=OzHrQqIfO2GTjwFKxNA08BDTI26ZyFRB/cfOlPU+WLU=; b=Az3CDXglehM3c0nZWK2W5mS+b4DIehWILUhiDRv7EryZ47DD35phoba6UUQXCFIhF+ JhHm7roOH7NZ/WTe+ULkWNvBkX2aHRq+GVe58Tgt66n8uQIvUGQTJjkDJtDqDq5qNjvY lgr0Yiy1BvbcU1zOnefL7ogNAT9B7p1WCOw7nb1/Y1c7iU0qLhIpJ4DwJtAtqjQLEFEb nsEuXP+IzfKqvc7yVp6CKq/8lzCiyPQ0g3PKVQzTkFRYy1z4dbiWpk8QGz+q907Lt8Ng Vf/DAiaxzzAjO5oDXGErnHVgwU3Xswg0de88bRidKR5/f1FcxE3/CmVLjyRv/JgEaXuC Ej/Q== MIME-Version: 1.0 X-Received: by 10.152.8.47 with SMTP id o15mr6129679laa.20.1391700855922; Thu, 06 Feb 2014 07:34:15 -0800 (PST) Received: by 10.114.170.193 with HTTP; Thu, 6 Feb 2014 07:34:15 -0800 (PST) In-Reply-To: <52F291E9.6030309@innovationslab.net> References: <52F291E9.6030309@innovationslab.net> Date: Thu, 6 Feb 2014 09:34:15 -0600 Message-ID: From: Behcet Sarikaya To: "netext@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3640226a3f804f1be9b5b Subject: Re: [netext] draft-ietf-netext-pmipv6-flowmob-08 and RFC 7109 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org 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, 06 Feb 2014 15:34:19 -0000 --001a11c3640226a3f804f1be9b5b Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 5, 2014 at 1:32 PM, Brian Haberman wrote: > Keeping in mind that 7109 is a non-consensus & experimental RFC via the > Independent Stream... > > For clarification, I did not say otherwise. All the extensions proposed in RFC 7109 are recorded by IANA as follows: http://www.iana.org/assignments/mobility-parameters/mobility-parameters.xhtml I said that these extensions are relevant to draft-ietf-netext-pmipv6-flowmob Regards, Behcet > On 2/5/14 11:36 AM, Behcet Sarikaya wrote: > > Hi Carlos, > > > > Please take a look at the newly published RFC 7109, > > http://tools.ietf.org/html/rfc7109 > > > > This RFC is very relevant to draft-ietf-netext-pmipv6-flowmob, due to > > HA-LMA relationship. > > > > New Flow Binding messages defined in RFC 7109 are very relevant. > > > > Mobility option extensions to Flow Identification Mobility option defined > > in RFC 7109 are also very relevant. > > > > There is point in reinventing the wheel. Here it is there make use of it. > > By the way I don't mind if you wish to keep using BID anymore :-) > > > > Regards, > > > > Behcet > > > > > > > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > --001a11c3640226a3f804f1be9b5b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Feb 5, 2014 at 1:32 PM, Brian Haberman &l= t;brian@innov= ationslab.net> wrote:
Keeping in mind that 7109= is a non-consensus & experimental RFC via the
Independent Stream...


For= clarification, I did not say otherwise.

All the extensio= ns proposed in RFC 7109 are recorded by IANA as follows:

http://www.iana.org/assignments/mobility-parameters/mobility-parameters= .xhtml


I said that these extensions are relevant to draft-ietf-= netext-pmipv6-flowmob

Regards,

Behcet
<= /div>
On 2/5/14 11:36 AM, Behcet Sarikaya wrote:
> Hi Carlos,
>
> Please take a look at the newly published RFC 7109,
> http:= //tools.ietf.org/html/rfc7109
>
> This RFC is very relevant to draft-ietf-netext-pmipv6-flowmob, due to<= br> > HA-LMA relationship.
>
> New Flow Binding messages defined in RFC 7109 are very relevant.
>
> Mobility option extensions to Flow Identification Mobility option defi= ned
> in RFC 7109 are also very relevant.
>
> There is point in reinventing the wheel. Here it is there make use of = it.
> By the way I don't mind if you wish to keep using BID anymore :-)<= br> >
> Regards,
>
> Behcet
>
>
>
> _______________________________________________
> netext mailing list
> netext@ietf.org
> https://www.ietf.org/mailman/listinfo/netext
>


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


--001a11c3640226a3f804f1be9b5b-- From internet-drafts@ietf.org Sat Feb 8 09:56:28 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 1688D1A047B; Sat, 8 Feb 2014 09:56:28 -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 RQUeGo3fl4_v; Sat, 8 Feb 2014 09:56:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 57CBE1A0025; Sat, 8 Feb 2014 09:56:26 -0800 (PST) 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.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140208175626.2196.83998.idtracker@ietfa.amsl.com> Date: Sat, 08 Feb 2014 09:56:26 -0800 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmip6-qos-11.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: Sat, 08 Feb 2014 17:56:28 -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 : 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-11.txt Pages : 67 Date : 2014-02-08 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-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-pmip6-qos-11 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 cjbc@it.uc3m.es Tue Feb 11 12:46:45 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 604651A0745 for ; Tue, 11 Feb 2014 12:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 KlRMdplPY3yW for ; Tue, 11 Feb 2014 12:46:43 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0CB1A0740 for ; Tue, 11 Feb 2014 12:46:43 -0800 (PST) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E31D4CD72F6 for ; Tue, 11 Feb 2014 21:46:41 +0100 (CET) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.139.224] (unknown [163.117.139.224]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id D6700CC0F0F for ; Tue, 11 Feb 2014 21:46:41 +0100 (CET) Message-ID: <1392151601.4016.127.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "netext@ietf.org" Date: Tue, 11 Feb 2014 21:46:41 +0100 Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5-2+b1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20496.002 Subject: [netext] Next steps on draft-ietf-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: cjbc@it.uc3m.es 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, 11 Feb 2014 20:46:45 -0000 Hi, I'm restarting the discussion about the flow mobility draft. 3GPP is considering NB-IFOM again for Rel-13, so I think we should close this document as soon as possible. As discussed during the last meeting, all the issues were cleared. Rajeev made some comments on issue #15, brought by Pierrick, on the use of update notifications. Rajeev, are you OK with the proposed resolution? BTW, can I ask what is the current status of draft-ietf-netext-logical-interface-support? I think we should also close that document. Thanks, Carlos From sgundave@cisco.com Tue Feb 11 16:27: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 A0AC61A07C6 for ; Tue, 11 Feb 2014 16:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 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.548, 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 J8VWgXyIzgl6 for ; Tue, 11 Feb 2014 16:27:10 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id BFEF81A0791 for ; Tue, 11 Feb 2014 16:27:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1838; q=dns/txt; s=iport; t=1392164830; x=1393374430; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=SlN0Dx6RtguCaRCkg7emlei1dFiCh4KUt//K5iPCshI=; b=EYr3156r3VQirzsFxGC2SaEQ38ychr7xtyJqK36OdY4hDvVler2Gw0oT FaubJ3ehFvnxmt+JMVuq6LAfiIAfdBN0uqyATgZaU5wE5ClYaEL/futXG 4Hp18NFNZ+q+pa8se29J3UzqYPYv+qudcH0hFsAAnqtu7rl4HJuc4/gvu c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAPS++lKtJV2d/2dsb2JhbABagww4V75GT4EWFnSCJQEBAQMBAQEBaxANAQhtCyUCBAESh30IDclyEwSORjqEOASJEI8akiCDLYIq X-IronPort-AV: E=Sophos;i="4.95,828,1384300800"; d="scan'208";a="19713400" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP; 12 Feb 2014 00:27:10 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1C0R9Nt030609 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Feb 2014 00:27:10 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.95]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 18:27:09 -0600 From: "Sri Gundavelli (sgundave)" To: "cjbc@it.uc3m.es" , "netext@ietf.org" Thread-Topic: [netext] Next steps on draft-ietf-netext-pmipv6-flowmob Thread-Index: AQHPJ4kqQ1vLttxK8UqQtRnY+xGnXQ== Date: Wed, 12 Feb 2014 00:27:09 +0000 Message-ID: In-Reply-To: <1392151601.4016.127.camel@acorde.it.uc3m.es> 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.21.89.235] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netext] Next steps on draft-ietf-netext-pmipv6-flowmob 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: Wed, 12 Feb 2014 00:27:12 -0000 Hi Carlos, > BTW, can I ask what is the current status of >draft-ietf-netext-logical-interface-support? I think we should also close >that document. Absolutely. We need to close this work. Here is the document status. - There were around 6 technical issues that were reported in the issue tracker - We have discussed those issues some time back during the meeting and presented the fixes. The AD (Jari) at that time also was present during the presentation and agreed with the fixes - We addresses those comments and updated the draft. Julien had additional comments and that held the draft for a while - In the last rev, we addresses Julien's comments (in fact it was his text) that we adopted AFAIK, there is no open issue that the Authors are aware off. Raj wanted to do a detailed review and provide some text/updates. Once we get that feedback, we can WGLC. I think we need some good reviews on the draft to ensure the WG is comfortable with the quality of the document. Regards Sri On 2/11/14 12:46 PM, "Carlos Jes=FAs Bernardos Cano" wrot= e: >Hi, > >I'm restarting the discussion about the flow mobility draft. 3GPP is >considering NB-IFOM again for Rel-13, so I think we should close this >document as soon as possible. > >As discussed during the last meeting, all the issues were cleared. Rajeev >made some comments on issue #15, brought by Pierrick, on the use of >update notifications. Rajeev, are you OK with the proposed resolution? > >BTW, can I ask what is the current status of >draft-ietf-netext-logical-interface-support? I think we should also >close that document. > >Thanks, > >Carlos > > > >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext From sarikaya2012@gmail.com Wed Feb 12 09:35: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 DD1911A05E5 for ; Wed, 12 Feb 2014 09:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 HdK-Teql27tx for ; Wed, 12 Feb 2014 09:35:11 -0800 (PST) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 287D61A0680 for ; Wed, 12 Feb 2014 09:35:04 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id ec20so7450772lab.9 for ; Wed, 12 Feb 2014 09:35:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=dH8QUj3P9a8adpaK+WlnqJmV2p8O+HyaEohx6KvYlu4=; b=IsXz4bJywd97vlb2Cb7LjexBbzWkh7S7Q8EiRmtFccgW+knz7+5EieDSJkIjBNdZ2h XwXtIFsjdyJN3FrrebUA5OXvKzwgmVjbXtXBrjckhGq7za1Lov9OlJ3wDRXZsNVRHWgy 2FV3GuzbEU+7QErjKX3dDdPkH0IxNxpu3BTWXGaGEwlZrkwtHH/mDGOOFn/yPTMrVRFl dGtZa6xO8/LFs2z3a19gWBq2LBc+0FFBfeMYC0iAKVHfQ2o2MZwEharuCTmoJbFxhrH8 3SP8E+wvWREd/2eJHhJFgJ1EnZrXNyjycRKS5Izli/L4o8+x9xqG7o8A4vTSFgZBvNTT 6gDg== MIME-Version: 1.0 X-Received: by 10.152.8.47 with SMTP id o15mr32389306laa.20.1392226503571; Wed, 12 Feb 2014 09:35:03 -0800 (PST) Received: by 10.114.170.193 with HTTP; Wed, 12 Feb 2014 09:35:03 -0800 (PST) In-Reply-To: <1392151601.4016.127.camel@acorde.it.uc3m.es> References: <1392151601.4016.127.camel@acorde.it.uc3m.es> Date: Wed, 12 Feb 2014 11:35:03 -0600 Message-ID: From: Behcet Sarikaya To: "Carlos J. Bernardos" Content-Type: multipart/alternative; boundary=001a11c36402313dc504f238fe26 Cc: "netext@ietf.org" Subject: Re: [netext] Next steps on draft-ietf-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org 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, 12 Feb 2014 17:35:13 -0000 --001a11c36402313dc504f238fe26 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Carlos, On Tue, Feb 11, 2014 at 2:46 PM, Carlos Jes=FAs Bernardos Cano < cjbc@it.uc3m.es> wrote: > Hi, > > I'm restarting the discussion about the flow mobility draft. 3GPP is > considering NB-IFOM again for Rel-13, so I think we should close this > document as soon as possible. > > As discussed during the last meeting, all the issues were cleared. Rajeev > made some comments on issue #15, brought by Pierrick, on the use of > update notifications. Rajeev, are you OK with the proposed resolution? > > I made many comments on the issue tracker, on the list and in meetings. Actually we comments have now been culminated in HA-based flow mobility protocol as in RFC 7109 (please see my previous mail on the list). You always preferred to ignore them, why? I remember very well, in the last face-to-face meeting the chairs asked you to meet with me during the meeting and try to resolve the issues face to face. I saw you in the breaks, you never attempted to talk to me. I was ready to talk. Again, I think that PMIPv6 flow mobility protocol should be compatible with RFC 7109 because on this way the implementers can reuse HA code for PMIPv6 as well. Regards, Behcet > BTW, can I ask what is the current status of > draft-ietf-netext-logical-interface-support? I think we should also > close that document. > > Thanks, > > Carlos > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > --001a11c36402313dc504f238fe26 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Carlos,


On Tue, Feb 11, 2014 at 2:46 PM, Carlos Jes=FAs Bernardos= Cano <cjbc@it.uc3m.es> wrote:
Hi,

I'm restarting the discussion about the flow mobility draft. 3GPP is considering NB-IFOM again for Rel-13, so I think we should close this
document as soon as possible.

As discussed during the last meeting, all the issues were cleared. Rajeev made some comments on issue #15, brought by Pierrick, on the use of
update notifications. Rajeev, are you OK with the proposed resolution?


I made many comments on the issue trac= ker, on the list and in meetings.
Actually we comments have n= ow been culminated in HA-based flow mobility protocol as in RFC 7109 (pleas= e see my previous mail on the list).

You always preferred to ignore them, why?
I re= member very well, in the last face-to-face meeting the chairs asked you to = meet with me during the meeting and try to resolve the issues face to face.=
I saw you in the breaks, you never attempted to talk to me. I wa= s ready to talk.

Again, I think that PMIPv6 flow mobility= protocol should be compatible with RFC 7109 because on this way the implem= enters can reuse HA code for PMIPv6 as well.

Regards,

Behcet
BTW, can I ask what is the current status of
draft-ietf-netext-logical-interface-support? I think we should also
close that document.

Thanks,

Carlos



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

--001a11c36402313dc504f238fe26-- From cjbc@it.uc3m.es Wed Feb 12 10:39:01 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 82BFA1A0614 for ; Wed, 12 Feb 2014 10:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.449 X-Spam-Level: X-Spam-Status: No, score=-4.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 PZ1Au5_nUUQI for ; Wed, 12 Feb 2014 10:38:46 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 738981A069A for ; Wed, 12 Feb 2014 10:38:45 -0800 (PST) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E1F04CD7813; Wed, 12 Feb 2014 19:38:43 +0100 (CET) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id D4E22CD77FE; Wed, 12 Feb 2014 19:38:43 +0100 (CET) Message-ID: <1392230323.21827.10.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: sarikaya@ieee.org Date: Wed, 12 Feb 2014 19:38:43 +0100 In-Reply-To: References: <1392151601.4016.127.camel@acorde.it.uc3m.es> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5-2+b1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20498.001 Cc: "netext@ietf.org" Subject: Re: [netext] Next steps on draft-ietf-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: cjbc@it.uc3m.es 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, 12 Feb 2014 18:39:01 -0000 Hi Behcet, On Wed, 2014-02-12 at 11:35 -0600, Behcet Sarikaya wrote: > Hi Carlos, > > > On Tue, Feb 11, 2014 at 2:46 PM, Carlos Jesús Bernardos Cano > wrote: > Hi, > > I'm restarting the discussion about the flow mobility draft. > 3GPP is > considering NB-IFOM again for Rel-13, so I think we should > close this > document as soon as possible. > > As discussed during the last meeting, all the issues were > cleared. Rajeev > made some comments on issue #15, brought by Pierrick, on the > use of > update notifications. Rajeev, are you OK with the proposed > resolution? > > > > I made many comments on the issue tracker, on the list and in > meetings. > > Actually we comments have now been culminated in HA-based flow > mobility protocol as in RFC 7109 (please see my previous mail on the > list). > > > You always preferred to ignore them, why? The WG agreed on how to resolve all your issues. The document reflects the WG consensus. I even remember Suresh going one by one in one meeting and everybody agreed. Carlos > > I remember very well, in the last face-to-face meeting the chairs > asked you to meet with me during the meeting and try to resolve the > issues face to face. > > I saw you in the breaks, you never attempted to talk to me. I was > ready to talk. > Again, I think that PMIPv6 flow mobility protocol should be compatible > with RFC 7109 because on this way the implementers can reuse HA code > for PMIPv6 as well. > > > Regards, > > > Behcet > > BTW, can I ask what is the current status of > draft-ietf-netext-logical-interface-support? I think we should > also > close that document. > > Thanks, > > Carlos > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > From sarikaya2012@gmail.com Thu Feb 13 09:06:56 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 677481A0305 for ; Thu, 13 Feb 2014 09:06:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 uoy_bjuMj2Ez for ; Thu, 13 Feb 2014 09:06:50 -0800 (PST) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 15EBF1A0342 for ; Thu, 13 Feb 2014 09:06:49 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id b8so8358298lan.19 for ; Thu, 13 Feb 2014 09:06:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=5vbgwcz7yFvV/U8z4gLqD8EhdCIVmKQWVZs945b82vQ=; b=Zk2FW9wVr5fEpX4GZU8Oivo2oMA8R10U4tGWDVaAdkSnp25cvLY2DulT12c2vnUQub /eH+efgj2XAkd5/Ec578rjGw7qWEG3frl3YNx1YIJ4AynOScdWaNK+h23mNN+Tna1Bky aRs+WI8hLy8Ha3YD54qS8b9TAMgA7580s9AaISVCcJrbxw90klM2BquDAKErIEYufY7g kshscXoOf849s8RZFZhF26PaAmGDHYjoe4oc6gD1zACU4aJwtxbbaEUZEw1r4wOEsSzF mdz+SvzcXRAL0iWEhRHiypEwxypmrJPDI9OWTPXAJqDYXVf5D0hbUYtm+W9f66/dbmND gNTA== MIME-Version: 1.0 X-Received: by 10.112.22.196 with SMTP id g4mr1625550lbf.47.1392311208204; Thu, 13 Feb 2014 09:06:48 -0800 (PST) Received: by 10.114.170.193 with HTTP; Thu, 13 Feb 2014 09:06:48 -0800 (PST) In-Reply-To: <1392230323.21827.10.camel@acorde.it.uc3m.es> References: <1392151601.4016.127.camel@acorde.it.uc3m.es> <1392230323.21827.10.camel@acorde.it.uc3m.es> Date: Thu, 13 Feb 2014 11:06:48 -0600 Message-ID: From: Behcet Sarikaya To: "Carlos J. Bernardos" Content-Type: multipart/alternative; boundary=14dae9473ba3fb5f6e04f24cb665 Cc: "netext@ietf.org" Subject: Re: [netext] Next steps on draft-ietf-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org 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, 13 Feb 2014 17:06:56 -0000 --14dae9473ba3fb5f6e04f24cb665 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Feb 12, 2014 at 12:38 PM, Carlos Jes=FAs Bernardos Cano < cjbc@it.uc3m.es> wrote: > Hi Behcet, > > On Wed, 2014-02-12 at 11:35 -0600, Behcet Sarikaya wrote: > > Hi Carlos, > > > > > > On Tue, Feb 11, 2014 at 2:46 PM, Carlos Jes=FAs Bernardos Cano > > wrote: > > Hi, > > > > I'm restarting the discussion about the flow mobility draft. > > 3GPP is > > considering NB-IFOM again for Rel-13, so I think we should > > close this > > document as soon as possible. > > > > As discussed during the last meeting, all the issues were > > cleared. Rajeev > > made some comments on issue #15, brought by Pierrick, on the > > use of > > update notifications. Rajeev, are you OK with the proposed > > resolution? > > > > > > > > I made many comments on the issue tracker, on the list and in > > meetings. > > > > Actually we comments have now been culminated in HA-based flow > > mobility protocol as in RFC 7109 (please see my previous mail on the > > list). > > > > > > You always preferred to ignore them, why? > > The WG agreed on how to resolve all your issues. The document reflects > the WG consensus. I even remember Suresh going one by one in one meeting > and everybody agreed. > > No. Will you please reply what follows below? > Carlos > > > I remember very well, in the last face-to-face meeting the chairs asked you to meet with me during the meeting and try to resolve the issues face to face. I saw you in the breaks, you never attempted to talk to me. I was ready to talk. ? > Again, I think that PMIPv6 flow mobility protocol should be compatible > with RFC 7109 because on this way the implementers can reuse HA code > for PMIPv6 as well. > > > Regards, > > > Behcet > > BTW, can I ask what is the current status of > draft-ietf-netext-logical-interface-support? I think we should > also > close that document. > > Thanks, > > Carlos > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > --14dae9473ba3fb5f6e04f24cb665 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Feb 12, 2014 at 12:38 PM, Carlos Jes=FAs Bernardos Cano <cjb= c@it.uc3m.es> wrote:
Hi Behcet,

On Wed, 2014-02-12 at 11:35 -0600, Behcet Sarikaya wrote:
> Hi Carlos,
>
>
> On Tue, Feb 11, 2014 at 2:46 PM, Carlos Jes=FAs Bernardos Cano
> <cjbc@it.uc3m.es> wrote:<= br> > =A0 =A0 =A0 =A0 Hi,
>
> =A0 =A0 =A0 =A0 I'm restarting the discussion about the flow mobil= ity draft.
> =A0 =A0 =A0 =A0 3GPP is
> =A0 =A0 =A0 =A0 considering NB-IFOM again for Rel-13, so I think we sh= ould
> =A0 =A0 =A0 =A0 close this
> =A0 =A0 =A0 =A0 document as soon as possible.
>
> =A0 =A0 =A0 =A0 As discussed during the last meeting, all the issues w= ere
> =A0 =A0 =A0 =A0 cleared. Rajeev
> =A0 =A0 =A0 =A0 made some comments on issue #15, brought by Pierrick, = on the
> =A0 =A0 =A0 =A0 use of
> =A0 =A0 =A0 =A0 update notifications. Rajeev, are you OK with the prop= osed
> =A0 =A0 =A0 =A0 resolution?
>
>
>
> I made many comments on the issue tracker, on the list and in
> meetings.
>
> Actually we comments have now been culminated in HA-based flow
> mobility protocol as in RFC 7109 (please see my previous mail on the > list).
>
>
> You always preferred to ignore them, why?

The WG agreed on how to resolve all your issues. The document reflect= s
the WG consensus. I even remember Suresh going one by one in one meeting and everybody agreed.


No.

Will you please reply what fol= lows below?
=A0
Carlos
>
<= /blockquote>
=A0I remember very well, in the last face-to-= face meeting the chairs
asked you to meet with me during the meeting and try to resolve the
=A0 issues face to face.

=A0 I saw you in the breaks, you never attempted to talk to me. I was
ready to talk.

?

> Again, I think that PMIPv6 flow mobility protocol should be compatible=
> with RFC 7109 because on this way the implementers can reuse HA code > for PMIPv6 as well.
>
>
> Regards,
>
>
> Behcet
>
> =A0 =A0 =A0 =A0 BTW, can I ask what is the current status of
> =A0 =A0 =A0 =A0 draft-ietf-netext-logical-interface-support? I think w= e should
> =A0 =A0 =A0 =A0 also
> =A0 =A0 =A0 =A0 close that document.
>
> =A0 =A0 =A0 =A0 Thanks,
>
> =A0 =A0 =A0 =A0 Carlos
>
>
>
> =A0 =A0 =A0 =A0 _______________________________________________
> =A0 =A0 =A0 =A0 netext mailing list
> =A0 =A0 =A0 =A0 netext@ietf.org=
> =A0 =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/netext
>
>



--14dae9473ba3fb5f6e04f24cb665-- From sarikaya2012@gmail.com Thu Feb 13 09:25:09 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 7550B1A0325 for ; Thu, 13 Feb 2014 09:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 hw7Hb8z1gUeQ for ; Thu, 13 Feb 2014 09:25:08 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7A51A0323 for ; Thu, 13 Feb 2014 09:25:07 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id w7so8340895lbi.21 for ; Thu, 13 Feb 2014 09:25:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=50pMZqMyjlZgUxUKtocFdoIr0QmYVPX6faWzjJZMSus=; b=Fsb2ikYfa5zw6jnTBGFzBqELryXB0CjBJUWz5YFjJccYF7ffRvqGKnBXiz7NVrTARX NmnCNlfcdw1uPo1KljgN0mv4O0CN9npQVjz9inq++8QrPS3tSBQXcYk5Z/Iiip8mKYvO TM1/PFoSVJ0c4sFgZPRYb5+HefgBudecqmZhCGGEEMatdSlWEJ8ETG+L7QIdlmz1SdJe AaYo3xKO/Dy87w5YUBa/6r9u3ZMWBJS+yDB9UlbzqrTcBl4s0bnLtSJ6NakV5427u18Q 3Td0In6vawSfB4YSO9dK8xHN87sH+x/MV8e+wOH8PtIiscNotYDdJollrVAC3Ivyj4Rr HTZw== MIME-Version: 1.0 X-Received: by 10.112.134.38 with SMTP id ph6mr1789859lbb.16.1392312305421; Thu, 13 Feb 2014 09:25:05 -0800 (PST) Received: by 10.114.170.193 with HTTP; Thu, 13 Feb 2014 09:25:05 -0800 (PST) Date: Thu, 13 Feb 2014 11:25:05 -0600 Message-ID: From: Behcet Sarikaya To: "netext@ietf.org" Content-Type: multipart/alternative; boundary=047d7b3a894661905d04f24cf8f8 Subject: [netext] draft-ietf-netext-pmipv6-flowmob-08 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org 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, 13 Feb 2014 17:25:09 -0000 --047d7b3a894661905d04f24cf8f8 Content-Type: text/plain; charset=ISO-8859-1 Hi all, I was reading this document once more and this point somehow sticks so I thought I should share with the WG: Section 3.2.1 presents a solution with LMA assigning the same prefix to different interfaces of MN. So the draft can easily say that this is the solution to flow mobility in PMIP, PMIP is extended to adopt this prefix-assignment policy and here is the solution. Why continue and present another solution in Section 3.2.2? Another comment on Section 3.1. Why are these three the only use cases? I served in the editorial team initially and the main use cases were MAG-initiated flow mobility and LMA-initiated flow mobility and actually there were many solution drafts proposing solution for each and those drafts were taken as input by the editorial team. What happened to that in Section 3.1? Regards, Behcet --047d7b3a894661905d04f24cf8f8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,<= br>
I was reading this document once more and this point somehow s= ticks so I thought I should share with the WG:

Section 3.2.1 p= resents a solution with LMA assigning the same prefix to different interfac= es of MN.

So the draft can easily say that this is the solution to flow mob= ility in PMIP, PMIP is extended to adopt this prefix-assignment policy and = here is the solution.

Why continue and present another solutio= n in Section 3.2.2?

Another comment on Section 3.1.
Why are these three the= only use cases?
I served in the editorial team initially and the = main use cases were MAG-initiated flow mobility and LMA-initiated flow mobi= lity and actually there were many solution drafts proposing solution for ea= ch and those drafts were taken as input by the editorial team.

What happened to that in Section 3.1?

Regards,
Behcet
--047d7b3a894661905d04f24cf8f8-- From nobody Thu Feb 13 11:07:29 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 32EC01A0415; Thu, 13 Feb 2014 11:07:26 -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 BASJQPl8U30v; Thu, 13 Feb 2014 11:07:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6493C1A0408; Thu, 13 Feb 2014 11:07:24 -0800 (PST) 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.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140213190724.11172.52743.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2014 11:07:24 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/QnlJTGFbC2UYC4095sjLN1cW6PY Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-05.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, 13 Feb 2014 19:07:26 -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 WiFi - EPC Integration Authors : Ravi Valmikam Rajeev Koodli Filename : draft-ietf-netext-wifi-epc-eap-attributes-05.txt Pages : 13 Date : 2014-02-13 Abstract: With WiFi beginning to establishing itself as a trusted access network for service providers, it has become important to provide functions commonly available in 3G and 4G networks in WiFi access networks. Such functions include Access Point Name (APN) Selection, multiple Packet Data Network (PDN) connections and seamless mobility between WiFi and 3G/4G networks. EAP/AKA (and EAP/AKA') is standardized by 3GPP as the access authentication protocol for trusted access networks. This IETF specification is required for mobile devices to access the 3GPP Evolved Packet Core (EPC) networks. This document defines a few new EAP attributes and procedures to provide the above-mentioned functions in trusted WiFi access networks. 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-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-wifi-epc-eap-attributes-05 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 Feb 13 11:30:21 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 059141A041F for ; Thu, 13 Feb 2014 11:30:20 -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 qNL47vx8JHjP for ; Thu, 13 Feb 2014 11:30:17 -0800 (PST) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 4C59A1A03E0 for ; Thu, 13 Feb 2014 11:30:17 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id w62so8036679wes.15 for ; Thu, 13 Feb 2014 11:30:15 -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=0dJgKlXfZXByoaBuzRXNYHgaNL0hPMyALZ9hlcSNRFM=; b=QoCBwnFShGUBCWnvtEuwE8KowxV/d1SziFucZ0BDkCkp7qdXwTEYEVcPxJ5f7GNXCm LTVsA+50KRlFGpTXng3+Fl3ep3PiYhcugu0i0EvUGnVrcX9DoBtCX6USzFhkTucQWzJG K0y5rdRnmXqL1tbbvAqLGejAHHNDBATuxaQnT6ikGFeWvEdNWyi1FowY14/D6zbpfYDK UW6/lYuUo1q5Zuf+0KQakGekXnQqY6q0vn/Dv/WkvSBtAVhkz4ldm4Z/G55w9cb/lOXg 3X9VVBPelF+LvMZcfkImAVcxDbl/E1+ZVawn+Y9YXFBjFv8s826LuqeEOrAOW2zA/j/o k+Mg== MIME-Version: 1.0 X-Received: by 10.194.134.132 with SMTP id pk4mr79608wjb.82.1392319815361; Thu, 13 Feb 2014 11:30:15 -0800 (PST) Received: by 10.194.20.199 with HTTP; Thu, 13 Feb 2014 11:30:15 -0800 (PST) In-Reply-To: <1392151601.4016.127.camel@acorde.it.uc3m.es> References: <1392151601.4016.127.camel@acorde.it.uc3m.es> Date: Thu, 13 Feb 2014 11:30:15 -0800 Message-ID: From: Rajeev Koodli To: cjbc@it.uc3m.es Content-Type: multipart/alternative; boundary=089e01227f440254ca04f24eb830 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/hDH4RXA4fYo0vWoc0kHDeIPClUg Cc: "netext@ietf.org" Subject: Re: [netext] Next steps on draft-ietf-netext-pmipv6-flowmob 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, 13 Feb 2014 19:30:20 -0000 --089e01227f440254ca04f24eb830 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Carlos, what is the proposed resolution? Thanks. -Rajeev >As discussed during the last meeting, all the issues were cleared. Rajeev >made some comments on issue #15, brought by Pierrick, on the use of >update notifications. Rajeev, are you OK with the proposed resolution? On Tue, Feb 11, 2014 at 12:46 PM, Carlos Jes=FAs Bernardos Cano < cjbc@it.uc3m.es> wrote: > Hi, > > I'm restarting the discussion about the flow mobility draft. 3GPP is > considering NB-IFOM again for Rel-13, so I think we should close this > document as soon as possible. > > As discussed during the last meeting, all the issues were cleared. Rajeev > made some comments on issue #15, brought by Pierrick, on the use of > update notifications. Rajeev, are you OK with the proposed resolution? > > BTW, can I ask what is the current status of > draft-ietf-netext-logical-interface-support? I think we should also > close that document. > > Thanks, > > Carlos > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > --089e01227f440254ca04f24eb830 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Carlos,

what is the p= roposed resolution?

Thanks.

-Rajeev

>As discussed during the last meeting, all the issu= es were cleared. Rajeev
>made some c= omments on issue #15, brought by Pierrick, on the use of
>update notifications. Rajeev, are you OK= with the proposed resolution?


O= n Tue, Feb 11, 2014 at 12:46 PM, Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m= .es> wrote:
Hi,

I'm restarting the discussion about the flow mobility draft. 3GPP is considering NB-IFOM again for Rel-13, so I think we should close this
document as soon as possible.

As discussed during the last meeting, all the issues were cleared. Rajeev made some comments on issue #15, brought by Pierrick, on the use of
update notifications. Rajeev, are you OK with the proposed resolution?

BTW, can I ask what is the current status of
draft-ietf-netext-logical-interface-support? I think we should also
close that document.

Thanks,

Carlos



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

--089e01227f440254ca04f24eb830-- From nobody Thu Feb 13 11:38:40 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 CBC391A0429 for ; Thu, 13 Feb 2014 11:38:34 -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 DqWssxzH1Ixa for ; Thu, 13 Feb 2014 11:38:32 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A2A8A1A042F for ; Thu, 13 Feb 2014 11:38:31 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id hn9so9172301wib.0 for ; Thu, 13 Feb 2014 11:38:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=HYi4+E2nkjTqZXYYcIOyc0MU+LvS4L7HCLskHTla2sE=; b=TVnpjwQZcN2tVXsZU2r7RkIcKt20kqBnbxyTC3qUqSkuMykKsFDfNIE0Z6oHhMH7jd dy4tIZpx4vrnwJBIi24iu487FPZ6cy94BqBBDcVH230LTvHOOmj9w0U/KyRwFXPhjE60 hideZm7VPjy6qwLjiEwMS7YwI8B5f1qjXXAxphSW6htKIBURItJeztry7T+wsjgd8edj +yh7n238OePUTtr8AsPlctsjVaQ0AQ7W1tu8cFScExsDAdLtzobeoJ6CMYOuioxXLGN4 uPI4/woDc+Xj3zXDB9RN57pXRKRXSpC+FSNzEaFalE+GywiW61/oMqj1+aBXSfwvM3Uu JOYQ== MIME-Version: 1.0 X-Received: by 10.194.134.132 with SMTP id pk4mr102518wjb.82.1392320309980; Thu, 13 Feb 2014 11:38:29 -0800 (PST) Received: by 10.194.20.199 with HTTP; Thu, 13 Feb 2014 11:38:29 -0800 (PST) Date: Thu, 13 Feb 2014 11:38:29 -0800 Message-ID: From: Rajeev Koodli To: "netext@ietf.org" Content-Type: multipart/alternative; boundary=089e01227f447da0a204f24ed564 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/gfvJjqaZYaNXbrlj_c6ZwxktpY4 Subject: [netext] Meeting agenda items 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, 13 Feb 2014 19:38:35 -0000 --089e01227f447da0a204f24ed564 Content-Type: text/plain; charset=ISO-8859-1 Hello folks, we are meeting on Friday (March 7, 2014) at 9am. We need to wrap up the flow mobility ID and the EAP ID. Let's resolve any outstanding issues over email so we can progress these documents. I have not seen any discussion on some of the new topics presented at the last IETF. If there is interest in the WG, it would be good to discuss now. In this context, please let us know if you would like to lead the discussion on these topics. Please provide your request with the topic, time and an associated ID reference. Thanks. Chairs. --089e01227f447da0a204f24ed564 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hello folks,

we are meet= ing on Friday (March 7, 2014) at 9am.

We need to w= rap up the flow mobility ID and the EAP ID.
Let's resolve any= outstanding issues over email so we can progress these documents.

I have not seen any discussion on some of the new topic= s presented at the last IETF.
If there is interest in the WG, it = would be good to discuss now. In this context, please let us know if you wo= uld like to lead the discussion on these topics.

Please provide your request with the topic, time and an= associated ID reference.

Thanks.

Chairs.

--089e01227f447da0a204f24ed564-- From nobody Thu Feb 13 17:45:45 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 EE4651A0069; Thu, 13 Feb 2014 17:45:42 -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 4canQtgNZh5j; Thu, 13 Feb 2014 17:45:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA081A001B; Thu, 13 Feb 2014 17:45:41 -0800 (PST) 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.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214014541.24193.91779.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2014 17:45:41 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/h7WwWikkaAWH9mE5YXYOZKonKPs Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-06.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, 14 Feb 2014 01:45:43 -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 WiFi - EPC Integration Authors : Ravi Valmikam Rajeev Koodli Filename : draft-ietf-netext-wifi-epc-eap-attributes-06.txt Pages : 14 Date : 2014-02-13 Abstract: With WiFi beginning to establishing itself as a trusted access network for service providers, it has become important to provide functions commonly available in 3G and 4G networks in WiFi access networks. Such functions include Access Point Name (APN) Selection, multiple Packet Data Network (PDN) connections and seamless mobility between WiFi and 3G/4G networks. EAP/AKA (and EAP/AKA') is standardized by 3GPP as the access authentication protocol for trusted access networks. This IETF specification is required for mobile devices to access the 3GPP Evolved Packet Core (EPC) networks. This document defines a few new EAP attributes and procedures to provide the above-mentioned functions in trusted WiFi access networks. 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-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-wifi-epc-eap-attributes-06 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 Feb 14 01:13:48 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 8CF8D1A01EC for ; Fri, 14 Feb 2014 01:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 hpffIbEVQObv for ; Fri, 14 Feb 2014 01:13:41 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 10FA31A0173 for ; Fri, 14 Feb 2014 01:13:29 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id E289C2DC1AF; Fri, 14 Feb 2014 10:13:27 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id C38892380B8; Fri, 14 Feb 2014 10:13:27 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Fri, 14 Feb 2014 10:13:27 +0100 From: To: "sarikaya@ieee.org" , "netext@ietf.org" Thread-Topic: [netext] draft-ietf-netext-pmipv6-flowmob-08 Thread-Index: AQHPKOCNwuZkYpgeWUG/Yczry8Xe1pq0c/2w Date: Fri, 14 Feb 2014 09:13:26 +0000 Message-ID: <28165_1392369207_52FDDE37_28165_1198_2_81C77F07008CA24F9783A98CFD706F71141F4AB7@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: multipart/alternative; boundary="_000_81C77F07008CA24F9783A98CFD706F71141F4AB7PEXCVZYM12corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/7I45dGnBj2gBhfR0Pe4J2lWVQag Subject: Re: [netext] draft-ietf-netext-pmipv6-flowmob-08 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, 14 Feb 2014 09:13:46 -0000 --_000_81C77F07008CA24F9783A98CFD706F71141F4AB7PEXCVZYM12corpo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Behcet, De : netext [mailto:netext-bounces@ietf.org] De la part de Behcet Sarikaya Envoy=E9 : jeudi 13 f=E9vrier 2014 18:25 =C0 : netext@ietf.org Objet : [netext] draft-ietf-netext-pmipv6-flowmob-08 Hi all, I was reading this document once more and this point somehow sticks so I th= ought I should share with the WG: Section 3.2.1 presents a solution with LMA assigning the same prefix to dif= ferent interfaces of MN. So the draft can easily say that this is the solution to flow mobility in P= MIP, PMIP is extended to adopt this prefix-assignment policy and here is th= e solution. Why continue and present another solution in Section 3.2.2? >> I remember long an impassioned discussion regarding this point; the WG h= as finally decided to keep the solution to maintain compatibility with regu= lar RFC5213 operation. I think it can be acceptable; however I'm still doub= tful about combination of the two prefix management models (section 3.2.1 a= nd 3.2.2) , and I'd rewove section 3.2.3 and corresponding text in section= 3.1. However, I'll follow the group consensus if any. BR, Pierrick Another comment on Section 3.1. Why are these three the only use cases? I served in the editorial team initially and the main use cases were MAG-in= itiated flow mobility and LMA-initiated flow mobility and actually there we= re many solution drafts proposing solution for each and those drafts were t= aken as input by the editorial team. What happened to that in Section 3.1? Regards, Behcet ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_81C77F07008CA24F9783A98CFD706F71141F4AB7PEXCVZYM12corpo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Behcet,

 <= /p>

 = ;

De : nete= xt [mailto:netext-bounces@ietf.org] De la part de Behcet Sarikaya
Envoy=E9 : jeudi 13 f=E9vrier 2014 18:25
=C0 : netext@ietf.org
Objet : [netext] draft-ietf-netext-pmipv6-flowmob-08=

 

Hi all,

I was reading this do= cument once more and this point somehow sticks so I thought I should share = with the WG:

Section 3.2.1 present= s a solution with LMA assigning the same prefix to different interfaces of = MN.

So the draft can easi= ly say that this is the solution to flow mobility in PMIP, PMIP is extended= to adopt this prefix-assignment policy and here is the solution.

Why continue and pres= ent another solution in Section 3.2.2?

>> I= remember long an impassioned discussion regarding this point; the WG has f= inally decided to keep the solution to maintain compatibility with regular RFC5213 operation. I think it can be acceptable; however I’m= still doubtful about combination of the two prefix management models (sect= ion 3.2.1 and 3.2.2) , and I’d rewove  section 3.2.3 and corresp= onding text in section 3.1. However, I’ll follow the group consensus if any.

 = ;

BR,

Pierrick

 = ;

Another comment on Section 3.1.=

Why are these three the only us= e cases?

= I served in the editorial team initially and the main use cases were= MAG-initiated flow mobility and LMA-initiated flow mobility and actually t= here were many solution drafts proposing solution for each and those drafts were taken as input by the editorial te= am.

What happened to that= in Section 3.1?

Regards,

Behcet

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_81C77F07008CA24F9783A98CFD706F71141F4AB7PEXCVZYM12corpo_-- From nobody Fri Feb 14 12:20:31 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 B1A061A03BF; Fri, 14 Feb 2014 12:20:25 -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 qIH80YrvdKR9; Fri, 14 Feb 2014 12:20:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0481A03C0; Fri, 14 Feb 2014 12:20:22 -0800 (PST) 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.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214202022.23517.9604.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 12:20:22 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/s6dxBIQDVE4h8AQVb6-2_NymuG0 Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmip-cp-up-separation-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, 14 Feb 2014 20:20:26 -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 : Separation of Control and User Plane for Proxy Mobile IPv6 Authors : Ryuji Wakikawa Rajesh S. Pazhyannur Sri Gundavelli Charles E. Perkins Filename : draft-ietf-netext-pmip-cp-up-separation-02.txt Pages : 11 Date : 2014-02-14 Abstract: This document describes splitting of Control Plane (CP) and User Plane (UP) for a Proxy Mobile IPv6 based network infrastructure. Existing specifications allow a MAG to perform splitting of its control and user plane using Alternate Care of address mobility option for IPv6, or Alternate IPv4 Care of Address option for IPv4. However, the current specification does not have semantics for allowing the LMA to perform such functional split. To realize this requirement, this specification defines a mobility option that enables a local mobility anchor to provide an alternate LMA address to be used for the bi-directional tunnel between the MAG and LMA. With this extension, a local mobility anchor will be able to use an IP address for its user plane which is different than the IP address used for the control plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmip-cp-up-separation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pmip-cp-up-separation-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-pmip-cp-up-separation-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 Mon Feb 17 13:01:32 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 B6B461A0281 for ; Mon, 17 Feb 2014 13:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.449 X-Spam-Level: X-Spam-Status: No, score=-4.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 Bbejd8rQuEQ6 for ; Mon, 17 Feb 2014 13:01:26 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4C91A0277 for ; Mon, 17 Feb 2014 13:01:26 -0800 (PST) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E157911C183C; Mon, 17 Feb 2014 22:01:22 +0100 (CET) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [192.168.1.190] (82.158.201.225.dyn.user.ono.com [82.158.201.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id AA33311845FF; Mon, 17 Feb 2014 22:01:22 +0100 (CET) Message-ID: <1392670882.4216.1.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Rajeev Koodli Date: Mon, 17 Feb 2014 22:01:22 +0100 In-Reply-To: References: <1392151601.4016.127.camel@acorde.it.uc3m.es> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5-2+b1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20510.000 X-TM-AS-Result: No--23.448-7.0-31-1 X-imss-scan-details: No--23.448-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/ShUf6OceAoZax2ZEfQTLzVC4tWA Cc: "netext@ietf.org" Subject: Re: [netext] Next steps on draft-ietf-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: cjbc@it.uc3m.es 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, 17 Feb 2014 21:01:29 -0000 Hi Rajeev, On Thu, 2014-02-13 at 11:30 -0800, Rajeev Koodli wrote: > > Hi Carlos, > > > what is the proposed resolution? > The consensus of the WG was to use the Update Notifications (issue #15), as per draft-ietf-netext-update-notifications (now RFC7077). This is was presented in Vancouver. Thanks, Carlos > > Thanks. > > > -Rajeev > > > >As discussed during the last meeting, all the issues were cleared. > Rajeev > >made some comments on issue #15, brought by Pierrick, on the use of > >update notifications. Rajeev, are you OK with the proposed > resolution? > > > > On Tue, Feb 11, 2014 at 12:46 PM, Carlos Jesús Bernardos Cano > wrote: > Hi, > > I'm restarting the discussion about the flow mobility draft. > 3GPP is > considering NB-IFOM again for Rel-13, so I think we should > close this > document as soon as possible. > > As discussed during the last meeting, all the issues were > cleared. Rajeev > made some comments on issue #15, brought by Pierrick, on the > use of > update notifications. Rajeev, are you OK with the proposed > resolution? > > BTW, can I ask what is the current status of > draft-ietf-netext-logical-interface-support? I think we should > also > close that document. > > Thanks, > > Carlos > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > From nobody Mon Feb 17 13:06: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 91C411A0281 for ; Mon, 17 Feb 2014 13:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.449 X-Spam-Level: X-Spam-Status: No, score=-4.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 aWXFFmJDxydn for ; Mon, 17 Feb 2014 13:06:07 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 1B05D1A0277 for ; Mon, 17 Feb 2014 13:06:07 -0800 (PST) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E8955894CE2; Mon, 17 Feb 2014 22:06:03 +0100 (CET) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [192.168.1.190] (82.158.201.225.dyn.user.ono.com [82.158.201.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id ABCC68946F9; Mon, 17 Feb 2014 22:06:03 +0100 (CET) Message-ID: <1392671162.4216.5.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: sarikaya@ieee.org Date: Mon, 17 Feb 2014 22:06:02 +0100 In-Reply-To: References: <1392151601.4016.127.camel@acorde.it.uc3m.es> <1392230323.21827.10.camel@acorde.it.uc3m.es> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5-2+b1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20510.000 X-TM-AS-Result: No--36.771-7.0-31-1 X-imss-scan-details: No--36.771-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/CaI4IBPOdFZIOpUXWrxCoYt0t7c Cc: "netext@ietf.org" Subject: Re: [netext] Next steps on draft-ietf-netext-pmipv6-flowmob X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: cjbc@it.uc3m.es 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, 17 Feb 2014 21:06:10 -0000 Hi Behcet, On Thu, 2014-02-13 at 11:06 -0600, Behcet Sarikaya wrote: > > > > On Wed, Feb 12, 2014 at 12:38 PM, Carlos Jesús Bernardos Cano > wrote: > Hi Behcet, > > On Wed, 2014-02-12 at 11:35 -0600, Behcet Sarikaya wrote: > > Hi Carlos, > > > > > > On Tue, Feb 11, 2014 at 2:46 PM, Carlos Jesús Bernardos Cano > > wrote: > > Hi, > > > > I'm restarting the discussion about the flow > mobility draft. > > 3GPP is > > considering NB-IFOM again for Rel-13, so I think we > should > > close this > > document as soon as possible. > > > > As discussed during the last meeting, all the issues > were > > cleared. Rajeev > > made some comments on issue #15, brought by > Pierrick, on the > > use of > > update notifications. Rajeev, are you OK with the > proposed > > resolution? > > > > > > > > I made many comments on the issue tracker, on the list and > in > > meetings. > > > > Actually we comments have now been culminated in HA-based > flow > > mobility protocol as in RFC 7109 (please see my previous > mail on the > > list). > > > > > > You always preferred to ignore them, why? > > > The WG agreed on how to resolve all your issues. The document > reflects > the WG consensus. I even remember Suresh going one by one in > one meeting > and everybody agreed. > > > > No. > > > Will you please reply what follows below? Sure. > > > Carlos > > > > I remember very well, in the last face-to-face meeting the chairs > asked you to meet with me during the meeting and try to resolve the > issues face to face. > > I saw you in the breaks, you never attempted to talk to me. I was > ready to talk. > Was I expected to come to you? I don't think the WG asked me to do that... I was also ready to talk. Carlos > ? > > > Again, I think that PMIPv6 flow mobility protocol should be > compatible > > with RFC 7109 because on this way the implementers can reuse HA code > > for PMIPv6 as well. > > > > > > Regards, > > > > > > Behcet > > > > BTW, can I ask what is the current status of > > draft-ietf-netext-logical-interface-support? I think we > should > > also > > close that document. > > > > Thanks, > > > > Carlos > > > > > > > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > > > > > > > > > From nobody Mon Feb 17 14:30: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 D559D1A0532 for ; Mon, 17 Feb 2014 14:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 doL8aPPw-1Dt for ; Mon, 17 Feb 2014 14:30:42 -0800 (PST) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4861A02B8 for ; Mon, 17 Feb 2014 14:30:41 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id e16so11765515lan.12 for ; Mon, 17 Feb 2014 14:30:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=y2xifpRcjOcGa/FEa4beG+PNu91V6GWpVP5UCZT5Vzo=; b=KNqCKjWmoVLLkbNU1vlGGY03wmBu2mY9Ku9lf0gUE+TV0Frl+4LWpMG0FpsmBEukJH TEfahrxR+SBfDFH0ELAQVC5nzh+0gewheJDjJ4eU2bXxvz7yEWDsbjWkm5cbrRfUs8/y 2tDpUe50IUtetfUdqk2yELp4Ho6INVZgpGdi7rZcBgdBmXXlNFkZ776yWzYUql9XqStW f/gUwssNl2AR0E9qrCN6/yqG7aESraaprbO29zvt/GCPJ827eS4WR2QqAoJP3rYah6KF c1LFwA1/Y3/+YfFHpF7lIjzZmb0Ojl5SpB62hqL0S7TlOQDoWX9Wsh7T76k2hZNBPoHD lMcA== MIME-Version: 1.0 X-Received: by 10.112.201.164 with SMTP id kb4mr18050010lbc.32.1392676238184; Mon, 17 Feb 2014 14:30:38 -0800 (PST) Received: by 10.114.170.195 with HTTP; Mon, 17 Feb 2014 14:30:38 -0800 (PST) In-Reply-To: <28165_1392369207_52FDDE37_28165_1198_2_81C77F07008CA24F9783A98CFD706F71141F4AB7@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <28165_1392369207_52FDDE37_28165_1198_2_81C77F07008CA24F9783A98CFD706F71141F4AB7@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Mon, 17 Feb 2014 16:30:38 -0600 Message-ID: From: Behcet Sarikaya To: Pierrick Seite Content-Type: multipart/alternative; boundary=001a11c2602e76d57204f2a1b4ae Archived-At: http://mailarchive.ietf.org/arch/msg/netext/lmtOYwz9TvwulW_C8IXvPUhAw5I Cc: "netext@ietf.org" Subject: Re: [netext] draft-ietf-netext-pmipv6-flowmob-08 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org 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, 17 Feb 2014 22:30:45 -0000 --001a11c2602e76d57204f2a1b4ae Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Pierrick, On Fri, Feb 14, 2014 at 3:13 AM, wrote: > Hi Behcet, > > > > > > *De :* netext [mailto:netext-bounces@ietf.org] *De la part de* Behcet > Sarikaya > *Envoy=E9 :* jeudi 13 f=E9vrier 2014 18:25 > *=C0 :* netext@ietf.org > *Objet :* [netext] draft-ietf-netext-pmipv6-flowmob-08 > > > > Hi all, > > I was reading this document once more and this point somehow sticks so I > thought I should share with the WG: > > Section 3.2.1 presents a solution with LMA assigning the same prefix to > different interfaces of MN. > > So the draft can easily say that this is the solution to flow mobility in > PMIP, PMIP is extended to adopt this prefix-assignment policy and here is > the solution. > > Why continue and present another solution in Section 3.2.2? > > >> I remember long an impassioned discussion regarding this point; the WG > has finally decided to keep the solution to maintain compatibility with > regular RFC5213 operation. I think it can be acceptable; however I'm stil= l > doubtful about combination of the two prefix management models (section > 3.2.1 and 3.2.2) , and I'd rewove section 3.2.3 and corresponding text i= n > section 3.1. However, I'll follow the group consensus if any. > > > I would remove the whole 3.1 because I don't see why the prefix management so-called models are called flow mobility protocol use cases? Different ways of managing prefixes are not specific to flow mobility. Regards, Behcet > BR, > > Pierrick > > > > Another comment on Section 3.1. > > Why are these three the only use cases? > > I served in the editorial team initially and the main use cases were > MAG-initiated flow mobility and LMA-initiated flow mobility and actually > there were many solution drafts proposing solution for each and those > drafts were taken as input by the editorial team. > > What happened to that in Section 3.1? > > Regards, > > Behcet > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > --001a11c2602e76d57204f2a1b4ae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Pierrick,


On Fri, Feb 14, 2014 at 3:13 AM, <= ;pierrick.se= ite@orange.com> wrote:

Hi Behcet,<= /span>

 

&nb= sp;

De : nete= xt [mailto:net= ext-bounces@ietf.org] De la part de Behcet Sarikaya
Envoy=E9 : jeudi 13 f=E9vrier 2014 18:25
=C0 : nete= xt@ietf.org
Objet : [netext] draft-ietf-netext-pmipv6-flowmob-08<= /u>

 

Hi all,=

I was reading this do= cument once more and this point somehow sticks so I thought I should share = with the WG:

Section 3.2.1 present= s a solution with LMA assigning the same prefix to different interfaces of = MN.

So the draft can easi= ly say that this is the solution to flow mobility in PMIP, PMIP is extended= to adopt this prefix-assignment policy and here is the solution.=

Why continue and pres= ent another solution in Section 3.2.2?=

>= > I remember long an impassioned discussion regarding this point; the WG= has finally decided to keep the solution to maintain compatibility with regular RFC5213 operation. I think it can be acceptable; however I’m= still doubtful about combination of the two prefix management models (sect= ion 3.2.1 and 3.2.2) , and I’d rewove  section 3.2.3 and corresp= onding text in section 3.1. However, I’ll follow the group consensus if any.

&nb= sp;

<= /blockquote>

I would remove the whole 3.1 because I don't see wh= y the prefix management so-called models are called flow mobility protocol = use cases?
Different ways of managing prefixes are not specif= ic to flow mobility.

Regards,

Behcet
 

BR,=

Pierrick

&nb= sp;

Another comment on Section 3.1.=

Why are these three the only us= e cases?

= I served in the editorial team initially and the main use cases were= MAG-initiated flow mobility and LMA-initiated flow mobility and actually t= here were many solution drafts proposing solution for each and those drafts were taken as input by the editorial te= am.

What happened to that= in Section 3.1?

Regards,

Behcet

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

--001a11c2602e76d57204f2a1b4ae-- From nobody Tue Feb 18 12:45:22 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 155AE1A0214 for ; Tue, 18 Feb 2014 12:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 JLrIg6ehaIMJ for ; Tue, 18 Feb 2014 12:45:19 -0800 (PST) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id B05591A0136 for ; Tue, 18 Feb 2014 12:45:19 -0800 (PST) Received: by mail-oa0-f41.google.com with SMTP id j17so19912551oag.14 for ; Tue, 18 Feb 2014 12:45:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=TrpGFuAUMFTSHgKxOKp2tJ9MCXAVyRjzu1DAyxl2pTI=; b=Hm/Vc0CosLER9ZQbYd3UkL6aURDeNXOl8nFSPc+WKXeReftTwK4q53WFvHSo0wzt+B eM+jOtKO+7k0YtF63xrMBykyH2RfYqW9bTNa7VZAvpQg0j6lgDLpXmL6rcqqKVbu3Utl BXnaA0Xp+zI182ERXMMIUI1kRVj0A2QzRJFOaS1HJAG/vv5F47648RX56SZ4cLUnwxQ2 SlYMBptSkvvRjSRuRB/f84U/tW8JqttwYvT8kfCauyc1Qnn1+tC7LHBAyVZ7WBElytyi 5aF3wYdMQVixUBVOYmg6r9CWzNfCfSX8HS8Qk2EWNAPzq3m62rJzvC/Bm5a9rLjhKfl1 nTnQ== MIME-Version: 1.0 X-Received: by 10.60.134.166 with SMTP id pl6mr27990376oeb.16.1392756316522; Tue, 18 Feb 2014 12:45:16 -0800 (PST) Received: by 10.182.232.105 with HTTP; Tue, 18 Feb 2014 12:45:16 -0800 (PST) Date: Tue, 18 Feb 2014 14:45:16 -0600 Message-ID: From: Basavaraj Patil To: "netext@ietf.org" Content-Type: multipart/alternative; boundary=047d7b41cc3e82b8ca04f2b459fb Archived-At: http://mailarchive.ietf.org/arch/msg/netext/etAdGIODV9i3A03tV28GO9PnucU Cc: draft-ietf-netext-wifi-epc-eap-attributes@tools.ietf.org Subject: [netext] WG last call for I-D: draft-ietf-netext-wifi-epc-eap-attributes-06 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, 18 Feb 2014 20:45:21 -0000 --047d7b41cc3e82b8ca04f2b459fb Content-Type: text/plain; charset=ISO-8859-1 Hello, This is the start of the working group last call for I-D: " EAP Attributes for WiFi - EPC Integration " This I-D is intended to be progressed as an Informational document. Please review the I-D and provide feedback via the mailing list or to the authors directly. The working group last call will end on March 10th, 2014. -Raj --047d7b41cc3e82b8ca04f2b459fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hello,

This is the start of the working group last call for I-D: "
EAP=
 Attributes  for WiFi - EPC Integration
<draft-ietf-netext-wifi-epc-eap-attributes-06.txt>
=A0 "
This I-D is intended to be progressed as an Informational d= ocument.

Please review the I-D and provide feedback via the ma= iling list or to the authors directly.

The working group last call will end on March 10th, 2014.

-Raj
<= br>
--047d7b41cc3e82b8ca04f2b459fb-- From nobody Tue Feb 18 14:31:55 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 BEFDC1A0298 for ; Tue, 18 Feb 2014 14:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 UEy5QxdlpWtT for ; Tue, 18 Feb 2014 14:31:52 -0800 (PST) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 771241A0296 for ; Tue, 18 Feb 2014 14:31:52 -0800 (PST) Received: by mail-ob0-f180.google.com with SMTP id wp4so19380205obc.11 for ; Tue, 18 Feb 2014 14:31:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=MaFL+SEh8AJx9AnlN7pvL2bu+gSgswlBVePMu5+G09A=; b=BSOhgLhkIpmbdk9wylCOWBlsv0BQNl4fic1/3Eq3D8ArGL5Kfoz7df8X2Vp3EBUTOH AftjbLy+nUOjQTXaXyua4P+RgOOqizR9JV9cdjz06x5aBuaxCrRSsvzlbWf5JJjzxlQ6 fKhx/B4kF5wrdyorCjQAvDFftEOgSz/3kbSpIZu5E2HGnL8QzbG7a2n5DYG1DiC624p9 qbl6EkIzTc270g8LeozaiTWgqWPO9/8NfjH3kGcQsY71mbmKSdnaCpMQdBjgmjLIJpKr M3/s4xcYjPLOHPnWP6WTkFA7SVNF/bcOCzh4+6b9C4Ob4ptUEtWHHTsKTyEpUI/pYPl+ TY7A== MIME-Version: 1.0 X-Received: by 10.182.102.134 with SMTP id fo6mr28058038obb.10.1392762708913; Tue, 18 Feb 2014 14:31:48 -0800 (PST) Received: by 10.182.232.105 with HTTP; Tue, 18 Feb 2014 14:31:48 -0800 (PST) Date: Tue, 18 Feb 2014 16:31:48 -0600 Message-ID: From: Basavaraj Patil To: draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org Content-Type: multipart/alternative; boundary=089e0149c38085737804f2b5d65f Archived-At: http://mailarchive.ietf.org/arch/msg/netext/XvTUv6l6Rhx0M7uQ5PGkZjAgRPE Cc: "netext@ietf.org" Subject: [netext] Review of I-D: draft-ietf-netext-pmip-cp-up-separation 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, 18 Feb 2014 22:31:54 -0000 --089e0149c38085737804f2b5d65f Content-Type: text/plain; charset=ISO-8859-1 Hello authors, I have reviewed the I-D and I would say that it is ready for publication. I did not find any issues except for a few editorial ones. The problem statement as well as the objective of separating the CP and UP as well as the new mobility option are well defined. I would recommend that we proceed with a WG last call on this I-D. -- Basavaraj Patil --089e0149c38085737804f2b5d65f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hello authors,

I hav= e reviewed the I-D and I would say that it is ready for publication. I did = not find any issues except for a few editorial ones.
The problem stateme= nt as well as the objective of separating the CP and UP as well as the new = mobility option are well defined.

I would recommend that we proceed with a WG last call on this I-D= .

--
Basavaraj Patil
--089e0149c38085737804f2b5d65f-- From nobody Tue Feb 18 15:41:29 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 717961A02AE for ; Tue, 18 Feb 2014 15:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.548, 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 W1IJb1HHHVRI for ; Tue, 18 Feb 2014 15:41:24 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 576F31A0106 for ; Tue, 18 Feb 2014 15:41:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9870; q=dns/txt; s=iport; t=1392766881; x=1393976481; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=tfwf7Oi0kALCCrECZpWx0RNeUOaTIr24nrKSRutN4fY=; b=JUaMZzIEnI0dty450RAGqaLXe+Pd7bq82C/+E4txanrq3aQZ15eZc43x Dma8xCObzXq2/TuikF9HXuKZn/uEr2kHn7gNgWnfiYdST5hQq+7hvH9eW yEv2CsRHAgbo9M1Ad2BMxhoMqTmnJaegfd0FyJFByk0dafCnPvVZOtZ6n 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloHANHuA1OtJXG9/2dsb2JhbABZgkJEOFerBoxliFaBIRZ0giUBAQEELVwCAQgRAwECCx0HIREUCQgCBBMIh2kDEAENxEYNh34XjE+BMxEBHyAXAYMkgRQElkSDHosshUaDLYFxOQ X-IronPort-AV: E=Sophos;i="4.97,503,1389744000"; d="scan'208,217";a="304767612" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 18 Feb 2014 23:41:21 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1INfLPe020234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 18 Feb 2014 23:41:21 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.22]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Tue, 18 Feb 2014 17:41:20 -0600 From: "Rajesh Pazhyannur (rpazhyan)" To: "netext@ietf.org" Thread-Topic: [netext] Meeting agenda items Thread-Index: AQHPKPM1lZVkGLOCK0aBUNYuRjyG/Zq8FyqA//+bfWA= Date: Tue, 18 Feb 2014 23:41:19 +0000 Message-ID: <4ED2E36A22261145861BAB2C24088B4320F5A726@xmb-aln-x09.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.133.56] Content-Type: multipart/alternative; boundary="_000_4ED2E36A22261145861BAB2C24088B4320F5A726xmbalnx09ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/d8XhaB3DsKpuShjO3yjy0utwIXQ Subject: Re: [netext] Meeting agenda items 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, 18 Feb 2014 23:41:26 -0000 --_000_4ED2E36A22261145861BAB2C24088B4320F5A726xmbalnx09ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rajeev We presented a draft on civic location in the last meeting. We got some com= ments and suggestions. We have incorporated them in a new version. http://d= atatracker.ietf.org/doc/draft-pazhyannur-netext-civic-location-ani-subopt/. I would like to get some presentation time (say 10 min) to go over the chan= ges. Thanks Regards Rajesh From: Rajeev Koodli > Date: Thursday, February 13, 2014 11:38 AM To: "netext@ietf.org" > Subject: [netext] Meeting agenda items Hello folks, we are meeting on Friday (March 7, 2014) at 9am. We need to wrap up the flow mobility ID and the EAP ID. Let's resolve any outstanding issues over email so we can progress these do= cuments. I have not seen any discussion on some of the new topics presented at the l= ast IETF. If there is interest in the WG, it would be good to discuss now. In this co= ntext, please let us know if you would like to lead the discussion on these= topics. Please provide your request with the topic, time and an associated ID refer= ence. Thanks. Chairs. --_000_4ED2E36A22261145861BAB2C24088B4320F5A726xmbalnx09ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Rajeev

 

We presented a draft on civic location in = the last meeting. We got some comments and suggestions. We have incorporate= d them in a new version. http://datatracker.ietf.org/doc/draft-pazhyannur-netext-civic-location-ani-= subopt/.

I would like to get some presentation time= (say 10 min) to go over the changes.

 

Thanks

 

Regards

 

Rajesh

From: Rajeev Koodli <rajeev.koodli@gmail.com>
Date: Thursday, February 13, 2014 11:38 AM
To: "netext@ietf.org&quo= t; <netext@ietf.org>
Subject: [netext] Meeting agenda items

 

 

Hello folks,

 

we are meeting on Friday (M= arch 7, 2014) at 9am.

 

We need to wrap up the flow= mobility ID and the EAP ID.

Let's resolve any outstandi= ng issues over email so we can progress these documents.<= /p>

 

I have not seen any discuss= ion on some of the new topics presented at the last IETF.=

If there is interest in the= WG, it would be good to discuss now. In this context, please let us know i= f you would like to lead the discussion on these topics.<= /p>

 

Please provide your request= with the topic, time and an associated ID reference.

 

Thanks.

 

Chairs.

 

--_000_4ED2E36A22261145861BAB2C24088B4320F5A726xmbalnx09ciscoc_-- From nobody Fri Feb 21 14:23:54 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 88DDB1A02D5; Fri, 21 Feb 2014 14:23:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 jfBJxc_xFni8; Fri, 21 Feb 2014 14:23:50 -0800 (PST) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 0F46F1A027F; Fri, 21 Feb 2014 14:23:50 -0800 (PST) Received: by mail-oa0-f45.google.com with SMTP id i11so5246480oag.18 for ; Fri, 21 Feb 2014 14:23:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=o4RkOBirfeUFUaJPXkTvADdBUMlyz9ED4T9gtEV4Y9o=; b=Xo/SiKfxVhNd4YUSep0p8Bumro7hvUM7ALgeGO3Ioq3V1wHScKSEpRzd+S5SVsMOXN aNDVuX+CVhPg+b8/PTvmM+JbcjmLB8fpVFyr1Vp1sZnohSc5Z5PLselRuD3+s42mKiIJ 9OX3KyDxwBbNt9Nsp3Ipb20MuuxcFxGSaO203w4Rsszxd5WJvlZYEBdvVGuVDJ0RRriz BRFr/5OF26KCqLJzqTVmdN8e4pzHMLMTt9Iqm0r0cWvp7VyXNAaySezYxMhClOlxd7pT hq5rM8uFRikXS30YI8Bs1HmZZPGRTTaIec3mAfYMAVIqwC+lomurvNi+41NMDjXu69PJ fx4Q== MIME-Version: 1.0 X-Received: by 10.60.165.72 with SMTP id yw8mr12307474oeb.71.1393021425920; Fri, 21 Feb 2014 14:23:45 -0800 (PST) Received: by 10.182.232.105 with HTTP; Fri, 21 Feb 2014 14:23:45 -0800 (PST) Date: Fri, 21 Feb 2014 16:23:45 -0600 Message-ID: From: Basavaraj Patil To: iesg-secretary@ietf.org Content-Type: multipart/alternative; boundary=047d7b41904b41b1ba04f2f2137e Archived-At: http://mailarchive.ietf.org/arch/msg/netext/IiBF9xF2v2dzWRsMVKuYNtfbbYE Cc: "netext@ietf.org" Subject: [netext] Request to progress Netext WG I-D: draft-ietf-netext-pmip6-qos-11.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: Fri, 21 Feb 2014 22:23:53 -0000 --047d7b41904b41b1ba04f2f2137e Content-Type: text/plain; charset=ISO-8859-1 Hello, The Netext WG I-D: Quality of Service Option for Proxy Mobile IPv6 has completed WG last call and is ready for IESG review and approval. We would like to request the IESG to review this I-D and progress it towards publication. -Chairs (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard This I-D specifies a new mobility extension and enables application of QoS to different flows. And hence it is appropriate to progress this document on standards track. (2) The IESG approval announcement includes a Document Announcement Write-Up. Technical Summary: 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. Working Group Summary: The WG supports this I-D as it is relevant in the context of the protocols applicability within 3GPP standards. There is strong support to standardize this work. It has been reviewed multiple times by several experts. Document Quality: There is at least one known implementation of the protocol. There is good support for the specification and an interest in utilizing the protocol as a feature by various vendors. All reviewers of the I-D have been acknowledged in the document. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Document Shepherd: Basavaraj Patil Responsible AD: Brian Haberman (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have reviewed the I-D and this version of the document is ready for consideration by the IESG. The justification for the needed mobility extension to support QoS especially in the scenario of a handover from a 3GPP access to non-3GPP access is weak. But it does have applicability in various scenario in the context of 3GPP networks and architectures. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. There is no need for a special review by experts from security, operations, DNS, DHCP etc. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. I do not have any concerns about the document and believe it is ready to be progressed by the IESG. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. All authors have confirmed compliance. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No known IPR disclosure which references this document. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is strong WG consensus behind this document to publish it as a proposed standard. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. None. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Formal review by a MIB Doctor, media type or URI type not needed. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? All normative references are published RFCs. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. There are no downward normative references. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. Publishing this document does not change the status of other existing RFCs. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The IANA considerations section is clear and easy to understand. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registrie This specification defines a new mobility attribute format, Quality of Service attribute. The format of this attribute is described in Section 4.2. This attribute can be carried in Quality of Service mobility option. The type values for this attribute needs to be managed by IANA, under the Registry, Quality of Service Attribute Registry. This registry should be created under "Mobile IPv6 Parameters" registry at . (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. None. --047d7b41904b41b1ba04f2f2137e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hello,

The Ne= text WG I-D: Quality of Service Option for Proxy Mobile IPv6
<= draft-ietf-netext-pmip6-qos-11.txt> has completed WG last call and is
ready for IESG review and approval.

We would = like to request the IESG to review this I-D and progress it
towar= ds publication.

-Chairs


(1) What type of RFC is being requested (BCP, Proposed Stand= ard,
Internet Standard, Informational, Experimental, or Historic)= ? Why is
this the proper type of RFC? Is this type of RFC indicat= ed in the
title page header? =A0

Proposed Standard
This I-D specifies a new mobility extension and enables application o= f
QoS to different flows. And hence it is appropriate to progress= this
document on standards track.

(2) The IESG app= roval announcement includes a Document Announcement
Write-Up.=A0<= /div>
Technical Summary:

=A0 =A0This specifica= tion defines a new mobility option, the Quality of
=A0 =A0Service (QoS) option, for Proxy Mobile IPv6. =A0This option can= be used
=A0 =A0by the local mobility anchor and the mobile acces= s gateway for
=A0 =A0negotiating Quality of Service parameters fo= r a mobile node's IP
=A0 =A0flows. =A0The negotiated QoS parameters can be used for QoS pol= icing
=A0 =A0and marking of packets to enforce QoS differentiatio= n on the path
=A0 =A0between the local mobility anchor and the mo= bile access gateway.
=A0 =A0Furthermore, making QoS parameters available on the mobile acce= ss
=A0 =A0gateway enables mapping of these parameters to QoS rule= s that are
=A0 =A0specific to the access technology and allows th= ose rules to be
=A0 =A0enforced on the access network using access technology specific=
=A0 =A0approaches.

Working Group Summar= y:

The WG supports this I-D as it is relevant in t= he context of the
protocols applicability within 3GPP standards. There is strong support=
to standardize this work. It has been reviewed multiple times by=
several experts.

Document Quality:

There is at least one known implementation of the proto= col. There is
good support for the specification and an interest = in utilizing the
protocol as a feature by various vendors.
All reviewers of the I-D have been acknowledged in the document.=A0

Personnel:

Who is the Docum= ent Shepherd? Who is the Responsible Area Director?

Document Shepherd: Basavaraj Patil
Responsible AD: Brian Haberman=


(3) Briefly describe the review of= this document that was performed by
the Document Shepherd. If th= is version of the document is not ready
for publication, please explain why the document is being forwarded to=
the IESG.=A0

I have reviewed the I-D an= d this version of the document is ready for
consideration by the = IESG. The justification for the needed mobility
extension to support QoS especially in the scenario of a handover from=
a 3GPP access to non-3GPP access is weak. But it does have
=
applicability in various scenario in the context of 3GPP networks and<= /div>
architectures.=A0


(4) Does the= document Shepherd have any concerns about the depth or
breadth o= f the reviews that have been performed?=A0

No.=A0<= /div>

(5) Do portions of the document need review from a part= icular or from
broader perspective, e.g., security, operational c= omplexity, AAA, DNS,
DHCP, XML, or internationalization? If so, d= escribe the review that
took place.=A0

No. There is no need for a spe= cial review by experts from security,
operations, DNS, DHCP etc.<= /div>

(6) Describe any specific concerns or issues that = the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she i= s
uncomfortable with certain parts of the document, or has concer= ns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.=A0

I do not have any concerns about the document and believe it is = ready
to be progressed by the IESG.

(7) = Has each author confirmed that any and all appropriate IPR
disclo= sures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why?=A0

Yes. All authors have confirmed compliance.
(8) Has an IPR disclosure been filed that references this docum= ent? If
so, summarize any WG discussion and conclusion regarding the IPR
=
disclosures.=A0

No known IPR disclosure which= references this document.

(9) How solid is the WG= consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it= ?=A0

There is strong WG consensus behind this docu= ment to publish it as a
proposed standard.

(10) Has anyone threatened= an appeal or otherwise indicated extreme
discontent? If so, plea= se summarise the areas of conflict in separate
email messages to = the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)=A0

No.

(11) Identify any ID n= its the Document Shepherd has found in this
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.=A0

None.
=

(12) Describe how the document meets any required forma= l review
criteria, such as the MIB Doctor, media type, and URI type reviews.=A0=

Formal review by a MIB Doctor, media type or URI = type not needed.

(13) Have all references within t= his document been identified as
either normative or informative?=A0

Yes.

(14) Are there normative references to documents that = are not ready
for advancement or are otherwise in an unclear stat= e? If such
normative references exist, what is the plan for their completion?=A0<= /div>

All normative references are published RFCs.
=

(15) Are there downward normative references references= (see RFC
3967)? If so, list these downward references to support the Area
=
Director in the Last Call procedure.=A0

There= are no downward normative references.

(16) Will p= ublication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed<= /div>
in the abstract, and discussed in the introduction? If the RFCs a= re
not listed in the Abstract and Introduction, explain why, and = point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.=A0

No. Publishing this document does not change the status of o= ther
existing RFCs.

(17) Describe the Do= cument Shepherd's review of the IANA
considerations section, = especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations= in
IANA registries. Confirm that any referenced IANA registries = have been
clearly identified. Confirm that newly created IANA registries include=
a detailed specification of the initial contents for the registr= y,
that allocations procedures for future registrations are defin= ed, and
a reasonable name for the new registry has been suggested (see RFC
5226).=A0

The IANA considerations section i= s clear and easy to understand.=A0

(18) List any n= ew IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registrie

=A0 =A0 =A0 This specification defines a new mobili= ty attribute
=A0 =A0 =A0 format, Quality of Service attribute. =A0The format of thi= s
=A0 =A0 =A0 attribute is described in Section 4.2. =A0This attr= ibute can be
=A0 =A0 =A0 carried in Quality of Service mobility o= ption. =A0The type values
=A0 =A0 =A0 for this attribute needs to be managed by IANA, under the<= /div>
=A0 =A0 =A0 Registry, Quality of Service Attribute Registry. =A0T= his registry
=A0 =A0 =A0 should be created under "Mobile IPv= 6 Parameters" registry at
=A0 =A0 =A0 <http://www.iana.org/assignments/mobility-parameters>.=A0

(19) Describe reviews and automated checks performe= d by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.=A0
=

None.


--047d7b41904b41b1ba04f2f2137e-- From nobody Mon Feb 24 02:03:49 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 852481A0428 for ; Mon, 24 Feb 2014 02:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 F2xoG_P7JI60 for ; Mon, 24 Feb 2014 02:03:45 -0800 (PST) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id A8D6E1A02FD for ; Mon, 24 Feb 2014 02:03:45 -0800 (PST) Received: by mail-pd0-f181.google.com with SMTP id p10so1672903pdj.12 for ; Mon, 24 Feb 2014 02:03:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EBTYa5ztIVy6SIYLfbNmfii3VI/7XLQxtA+In0amtUc=; b=m/938JQhbzDCTpbtiAZV+/KQCt4Z1gWE0xslWA/ItlXDKx/RVL+sXbT6T9hdxMVUtM wE1UjQ0Cbtgv6SOL+dp/hGS1DiwIJt2/PsiGeHC2KCYjtOJ1UjdMaYBphT3L8mk+24c0 3W2DPHEwNgTmekYlWzbB4bPNDObwjbwrIBIEKiuGtXjhx+keXiuJ8uEorqhXob3Cwd+v db1+zOzFnG/k5Uma/uwOOkY698uAaN6P0k0giGSOOY0u/JH4cWKDFKA0J3BvjdRL74r3 NFqqOKySfoy4k+pshOIiL8ttJQjk1ForzvCDBXoeb0yQeD8wsn5Iuvkerz5Vne4FTgOK MEhQ== X-Received: by 10.66.146.199 with SMTP id te7mr24247838pab.106.1393236225333; Mon, 24 Feb 2014 02:03:45 -0800 (PST) Received: from [192.168.3.8] (softbank126077040002.bbtec.net. [126.77.40.2]) by mx.google.com with ESMTPSA id kc9sm48456265pbc.25.2014.02.24.02.03.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Feb 2014 02:03:44 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ryuji Wakikawa In-Reply-To: Date: Mon, 24 Feb 2014 19:03:41 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Basavaraj Patil X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/netext/LfbVnAUL7lSwW9en7S3by08HAy8 Cc: "netext@ietf.org" , draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org Subject: Re: [netext] Review of I-D: draft-ietf-netext-pmip-cp-up-separation 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, 24 Feb 2014 10:03:47 -0000 Hi Raj, Thanks for the message.=20 Please proceed to the WGLC. We are read for it. thanks ryuji On Feb 19, 2014, at 7:31 AM, Basavaraj Patil wrote: >=20 > Hello authors, >=20 > I have reviewed the I-D and I would say that it is ready for = publication. I did not find any issues except for a few editorial ones. > The problem statement as well as the objective of separating the CP = and UP as well as the new mobility option are well defined.=20 >=20 > I would recommend that we proceed with a WG last call on this I-D. >=20 > --=20 > Basavaraj Patil > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From nobody Mon Feb 24 09:43:17 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 1F2531A026D for ; Mon, 24 Feb 2014 09:43:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 lIP1qnzsCojk for ; Mon, 24 Feb 2014 09:43:12 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 88DBC1A0293 for ; Mon, 24 Feb 2014 09:43:11 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDX74333; Mon, 24 Feb 2014 17:43:10 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 24 Feb 2014 17:43:04 +0000 Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 24 Feb 2014 17:43:09 +0000 Received: from DFWEML703-CHM.china.huawei.com ([169.254.5.106]) by dfweml705-chm.china.huawei.com ([169.254.7.50]) with mapi id 14.03.0158.001; Mon, 24 Feb 2014 09:42:59 -0800 From: John Kaippallimalil To: "netext@ietf.org" Thread-Topic: [request for feedback] FW: New Version Notification for draft-kaippallimalil-netext-pmip-qos-wifi-04.txt Thread-Index: AQHPMYfbXs489yxZt0m9q+SV2+JAbw== Date: Mon, 24 Feb 2014 17:42:58 +0000 Message-ID: <6561EABF52675C45BCDACA1B4D7AA1171D9BC3CA@dfweml703-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.65] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netext/t_OucLZ21YGhuPBuYDEu_lw_G5c Subject: [netext] [request for feedback] FW: New Version Notification for draft-kaippallimalil-netext-pmip-qos-wifi-04.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, 24 Feb 2014 17:43:15 -0000 SGVsbG8sDQpXZSBoYXZlIGEgbmV3IGRyYWZ0IG9uIE1hcHBpbmcgODAyLjExIFFvUyBpbiBQTUlQ djYgTW9iaWxpdHkgZG9tYWluIChodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1rYWlwcGFsbGltYWxpbC1uZXRleHQtcG1pcC1xb3Mtd2lmaS0wNC50eHQpIHdpdGggY29t bWVudHMgZnJvbSB0aGUgZ3JvdXAgYWRkcmVzc2VkLiANCg0KVGhlIG1haW4gY29tbWVudHMgZnJv bSBsYXN0IG1lZXRpbmc6DQotIFdoeSBkbyB3ZSBuZWVkIHBlci11c2VyIFFvUyBhbmQgd2hhdCBp cyBtaXNzaW5nICAgICggLS0gbmV3IHRleHQgaW4gSW50cm9kdWN0aW9uKQ0KLSBkZWZhdWx0IGNv bm5lY3Rpb24vYWRtaXNzaW9uIGNvbnRyb2wsIGV0Yy4gICAgICAgICAoIC0tIHJldmlzZWQvYWRk ZWQgdXNlIGNhc2VzKQ0KLSBEb24ndCB1bmRlcnN0YW5kIGp1c3RpZmljYXRpb24gZm9yIERTQ1Ag bWFwIHNldCAgICAoIC0tIHJlbW92ZWQgZnJvbSBkcmFmdCkNCi0gbWFwcGluZyBvZiBjb25uZWN0 aW9uIHBhcmFtZXRlcnMgYmV0d2VlbiBXaUZpL1BNSVAgKCAtLSBhZGRlZCB0YWJsZXMgZm9yIHRo ZSBtYXBwaW5nKQ0KDQpXZSB3b3VsZCBsaWtlIHRvIGdldCBmZWVkYmFjayBvbiB0aGlzIGRyYWZ0 L3JldmlzaW9uIGFuZCB3b3VsZCBsaWtlIHRvIGhhdmUgaXQgYWRvcHRlZCBhcyBhIHdvcmtpbmcg Z3JvdXAgaXRlbS4gDQoNClJlZ2FyZHMsDQpKb2huDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDExLCAyMDE0IDExOjA5 IEFNDQpUbzogSm9obiBLYWlwcGFsbGltYWxpbDsgSm9obiBLYWlwcGFsbGltYWxpbDsgUmFqZXNo IFBhemh5YW5udXI7IFBhcnZpeiBZZWdhbmk7IFJhamVzaCBQYXpoeWFubnVyOyBQYXJ2aXogWWVn YW5pDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWthaXBwYWxs aW1hbGlsLW5ldGV4dC1wbWlwLXFvcy13aWZpLTA0LnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2Yg SS1ELCBkcmFmdC1rYWlwcGFsbGltYWxpbC1uZXRleHQtcG1pcC1xb3Mtd2lmaS0wNC50eHQNCmhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSm9obiBLYWlwcGFsbGltYWxpbCBhbmQg cG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1rYWlwcGFsbGlt YWxpbC1uZXRleHQtcG1pcC1xb3Mtd2lmaQ0KUmV2aXNpb246CTA0DQpUaXRsZToJCU1hcHBpbmcg ODAyLjExIFFvUyBpbiBhIFBNSVB2NiBNb2JpbGl0eSBEb21haW4NCkRvY3VtZW50IGRhdGU6CTIw MTQtMDItMTANCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTI0DQpVUkw6 ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQta2Fp cHBhbGxpbWFsaWwtbmV0ZXh0LXBtaXAtcW9zLXdpZmktMDQudHh0IA0KU3RhdHVzOiAgICAgICAg IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWthaXBwYWxsaW1hbGlsLW5l dGV4dC1wbWlwLXFvcy13aWZpLyANCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1rYWlwcGFsbGltYWxpbC1uZXRleHQtcG1pcC1xb3Mtd2lmaS0wNA0KRGlm ZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWthaXBw YWxsaW1hbGlsLW5ldGV4dC1wbWlwLXFvcy13aWZpLTA0DQoNCkFic3RyYWN0Og0KICAgVGhpcyBk b2N1bWVudCBwcm92aWRlcyByZWNvbW1lbmRhdGlvbnMgb24gcHJvY2VkdXJlcyBhbmQgbWFwcGlu ZyBvZg0KICAgUW9TIHBhcmFtZXRlcnMgYmV0d2VlbiA4MDIuMTEgYW5kIFBNSVB2Ni4gUW9TIHBh cmFtZXRlcnMgaW4gODAyLjExDQogICB0aGF0IHJlc2VydmUgcmVzb3VyY2VzIGZvciA4MDIuMTEg c3RyZWFtcyBzaG91bGQgYmUgbWFwcGVkIHRvIFBNSVANCiAgIFFvUyByZXNvdXJjZXMgZm9yIElQ IHNlc3Npb25zIGFuZCBmbG93cy4gUW9TIHJlc2VydmF0aW9uIHNlcXVlbmNlcyBpbg0KICAgODAy LjExIHNob3VsZCBhbGxvdyBjYXNlcyB3aGVyZSBNTiBpbml0aWF0ZSByZXNvdXJjZSByZXNlcnZh dGlvbiwgYXMNCiAgIHdlbGwgYXMgY2FzZXMgd2hlcmUgdGhlIG5ldHdvcmsgaW5pdGlhdGVzIHJl c291cmNlIHJlc2VydmF0aW9uLg0KICAgQWRkaXRpb25hbGx5LCBpdCBzaG91bGQgYmUgcG9zc2li bGUgZm9yIFFvUyBwYXJhbWV0ZXJzIGZvciBQTUlQdjYNCiAgIGZsb3dzIGFuZCBtb2JpbGl0eSBz ZXNzaW9ucyB0byBiZSBtYXBwZWQgdG8gODAyLjExIHRyYWZmaWMgc3RyZWFtDQogICByZXNlcnZh dGlvbnMuIFRoZSBzZXF1ZW5jZXMgYW5kIHBhcmFtZXRlcnMgdG8gYmUgbWFwcGVkIHRvIHByb3Zp ZGUgYQ0KICAgY29uc2lzdGVudCBiZWhhdmlvciBhY3Jvc3MgODAyLjExIGFuZCBQTUlQdjYgUW9T IGFyZSBkZXNjcmliZWQgaGVyZS4NCg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0K DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0 aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0 DQoNCg== From nobody Tue Feb 25 06:07: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 941AF1A072A for ; Tue, 25 Feb 2014 06:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 91WI7WIRk63K for ; Tue, 25 Feb 2014 06:07:33 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id CBE1A1A072B for ; Tue, 25 Feb 2014 06:07:32 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 4A7483B40F7; Tue, 25 Feb 2014 15:07:31 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 2EC7E4C17E; Tue, 25 Feb 2014 15:07:31 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Tue, 25 Feb 2014 15:07:30 +0100 From: To: John Kaippallimalil , "netext@ietf.org" Thread-Topic: [request for feedback] FW: New Version Notification for draft-kaippallimalil-netext-pmip-qos-wifi-04.txt Thread-Index: AQHPMYfbXs489yxZt0m9q+SV2+JAb5rGApSQ Date: Tue, 25 Feb 2014 14:07:30 +0000 Message-ID: <31833_1393337251_530CA3A3_31833_8607_1_81C77F07008CA24F9783A98CFD706F71141FADF8@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <6561EABF52675C45BCDACA1B4D7AA1171D9BC3CA@dfweml703-chm.china.huawei.com> In-Reply-To: <6561EABF52675C45BCDACA1B4D7AA1171D9BC3CA@dfweml703-chm.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.25.93015 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/GzkKrVy77jxZqCQ3XOgQXL_2MyU Subject: Re: [netext] [request for feedback] FW: New Version Notification for draft-kaippallimalil-netext-pmip-qos-wifi-04.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: Tue, 25 Feb 2014 14:07:35 -0000 Hi John, I have read draft-kaippallimalil-netext-pmip-qos-wifi and I found it very g= ood. IMHO, this document is a good companion document of draft-ietf-netext-pmip6= -qos; it clarifies very well how to use PMIP QoS option on a WLAN access. Hence, I have very few comments/questions:=20 - The draft assumes that MAC and WLC are collocated; can we imagine archite= cture where the controller is not in the datapath? If yes, what is the impa= ct? - There is an unsaid assumption: the LMA is the decision maker regarding th= e QoS policy. I think it should be clearly stated somewhere. I mean, althou= gh it is not the current trend, I imagine that some deployment may let the = MAG making the final decision regarding the QoS policy to apply.=20 - You wrote that Mean Data Rate has no equivalent parameter in PMIP QoS. Ho= wever, last update of pmip-qos draft includes a vendor specific option whic= h, IMO, could be used for that purpose. BR, Pierrick >-----Message d'origine----- >De=A0: netext [mailto:netext-bounces@ietf.org] De la part de John Kaippall= imalil >Envoy=E9=A0: lundi 24 f=E9vrier 2014 18:43 >=C0=A0: netext@ietf.org >Objet=A0: [netext] [request for feedback] FW: New Version Notification for >draft-kaippallimalil-netext-pmip-qos-wifi-04.txt > >Hello, >We have a new draft on Mapping 802.11 QoS in PMIPv6 Mobility domain >(http://www.ietf.org/internet-drafts/draft-kaippallimalil-netext-pmip-qos- >wifi-04.txt) with comments from the group addressed. > >The main comments from last meeting: >- Why do we need per-user QoS and what is missing ( -- new text in >Introduction) >- default connection/admission control, etc. ( -- revised/added us= e cases) >- Don't understand justification for DSCP map set ( -- removed from dra= ft) >- mapping of connection parameters between WiFi/PMIP ( -- added tables for >the mapping) > >We would like to get feedback on this draft/revision and would like to hav= e it >adopted as a working group item. > >Regards, >John > > > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: Tuesday, February 11, 2014 11:09 AM >To: John Kaippallimalil; John Kaippallimalil; Rajesh Pazhyannur; Parviz Ye= gani; >Rajesh Pazhyannur; Parviz Yegani >Subject: New Version Notification for draft-kaippallimalil-netext-pmip-qos- >wifi-04.txt > > >A new version of I-D, draft-kaippallimalil-netext-pmip-qos-wifi-04.txt >has been successfully submitted by John Kaippallimalil and posted to the I= ETF >repository. > >Name: draft-kaippallimalil-netext-pmip-qos-wifi >Revision: 04 >Title: Mapping 802.11 QoS in a PMIPv6 Mobility Domain >Document date: 2014-02-10 >Group: Individual Submission >Pages: 24 >URL: http://www.ietf.org/internet-drafts/draft-kaippallimalil-n= etext- >pmip-qos-wifi-04.txt >Status: https://datatracker.ietf.org/doc/draft-kaippallimalil-nete= xt-pmip- >qos-wifi/ >Htmlized: http://tools.ietf.org/html/draft-kaippallimalil-netext-pmi= p-qos- >wifi-04 >Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-kaippallimalil-ne= text-pmip- >qos-wifi-04 > >Abstract: > This document provides recommendations on procedures and mapping of > QoS parameters between 802.11 and PMIPv6. QoS parameters in 802.11 > that reserve resources for 802.11 streams should be mapped to PMIP > QoS resources for IP sessions and flows. QoS reservation sequences in > 802.11 should allow cases where MN initiate resource reservation, as > well as cases where the network initiates resource reservation. > Additionally, it should be possible for QoS parameters for PMIPv6 > flows and mobility sessions to be mapped to 802.11 traffic stream > reservations. The sequences and parameters to be mapped to provide a > consistent behavior across 802.11 and PMIPv6 QoS are described here. > > > > > > >Please note that it may take a couple of minutes from the time of submissi= on >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Feb 25 08:57:59 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 033F01A07ED for ; Tue, 25 Feb 2014 08:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.047 X-Spam-Level: X-Spam-Status: No, score=-10.047 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, RP_MATCHES_RCVD=-0.547, 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 l6fg-cY7X7Ju for ; Tue, 25 Feb 2014 08:57:42 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 352F61A07E7 for ; Tue, 25 Feb 2014 08:57:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18934; q=dns/txt; s=iport; t=1393347461; x=1394557061; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=hzQeVTtR6XYjCqb3Ru24v+w5OyLcmDsFbtOUnKC4gfU=; b=JaqRznf+2ch0GEypfqfVzpTFkZ+6JZej54bbzqNEEG0B7z5VXkJQZkZi J9FMTX52Dxwj9di9sQcTwoXRpQXSIECjLMLM7e5lQRjhnlIB27aiAl/YM gTvpYWwnYZcCv90xr6MiivO83g3EAm7i1mQVajl+mgZ329uhQAWVt7FId I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIGAH3KDFOtJV2Y/2dsb2JhbABZgkJEO1EGuHmICU+BGBZ0giUBAQEDAQEBASpBCQcHBAIBCBEBAwEBCxkEBycLFAMFAQgCBAESCAGHdAgIBccDF44CEQEfLQsGgx6BFASJEINUjQKGEopjgW+BPoFxOQ X-IronPort-AV: E=Sophos; i="4.97,541,1389744000"; d="scan'208,217"; a="23069740" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP; 25 Feb 2014 16:57:40 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1PGve5x011214 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 16:57:40 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.22]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 10:57:39 -0600 From: "Rajesh Pazhyannur (rpazhyan)" To: "pierrick.seite@orange.com" , "John Kaippallimalil" , "netext@ietf.org" Thread-Topic: [request for feedback] FW: New Version Notification for draft-kaippallimalil-netext-pmip-qos-wifi-04.txt Thread-Index: AQHPMYfbXs489yxZt0m9q+SV2+JAb5rGApSQgAAtqkA= Date: Tue, 25 Feb 2014 16:57:39 +0000 Message-ID: <4ED2E36A22261145861BAB2C24088B4320F5E1A7@xmb-aln-x09.cisco.com> References: <6561EABF52675C45BCDACA1B4D7AA1171D9BC3CA@dfweml703-chm.china.huawei.com> <31833_1393337251_530CA3A3_31833_8607_1_81C77F07008CA24F9783A98CFD706F71141FADF8@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <31833_1393337251_530CA3A3_31833_8607_1_81C77F07008CA24F9783A98CFD706F71141FADF8@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.35.68.69] Content-Type: multipart/alternative; boundary="_000_4ED2E36A22261145861BAB2C24088B4320F5E1A7xmbalnx09ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/K14vUTBLFMDdOl4JMBu71yaUbNA Subject: Re: [netext] [request for feedback] FW: New Version Notification for draft-kaippallimalil-netext-pmip-qos-wifi-04.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: Tue, 25 Feb 2014 16:57:48 -0000 --_000_4ED2E36A22261145861BAB2C24088B4320F5E1A7xmbalnx09ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for the review. Appreciate it. Regards Rajesh -----Original Message----- From: netext [mailto:netext-bounces@ietf.org] On Behalf Of pierrick.seite@o= range.com Sent: Tuesday, February 25, 2014 6:08 AM To: John Kaippallimalil; netext@ietf.org Subject: Re: [netext] [request for feedback] FW: New Version Notification f= or draft-kaippallimalil-netext-pmip-qos-wifi-04.txt Hi John, I have read draft-kaippallimalil-netext-pmip-qos-wifi and I found it very g= ood. IMHO, this document is a good companion document of draft-ietf-netext-pmip6= -qos; it clarifies very well how to use PMIP QoS option on a WLAN access. Hence, I have very few comments/questions: - The draft assumes that MAC and WLC are collocated; can we imagine archite= cture where the controller is not in the datapath? If yes, what is the impa= ct? > Yes, definitely we should consider the possibility of WLC not being in t= he datapath. In such a case we assume that MAG is on the AP. The link betwe= en AP and WLC is only used for control and management and not for carrying = the datapath. > There is a third possibility where the MAG is on the WLC but datapath is = between the AP and LMA. (For example this could be Done using the Alt-CoA option. I don't think we have highlighted this case= as this would depend on how the MAG (on WLC) communicates with AP (e.g., = using CAPWAP or some other means). - There is an unsaid assumption: the LMA is the decision maker regarding th= e QoS policy. I think it should be clearly stated somewhere. I mean, althou= gh it is not the current trend, I imagine that some deployment may let the = MAG making the final decision regarding the QoS policy to apply. > I don't fully understand the intent here. For example, is the LMA sends = a policy in an Update Request and the MAG does not have resources to meet i= t, the MAG can change it. But I suspect that this is not what you are ask= ing. - You wrote that Mean Data Rate has no equivalent parameter in PMIP QoS. Ho= wever, last update of pmip-qos draft includes a vendor specific option whic= h, IMO, could be used for that purpose. > Noted. BR, Pierrick >-----Message d'origine----- >De : netext [mailto:netext-bounces@ietf.org] De la part de John >Kaippallimalil Envoy=E9 : lundi 24 f=E9vrier 2014 18:43 =C0 : netext@ietf.= org >Objet : [netext] [request for feedback] FW: New Version Notification >for draft-kaippallimalil-netext-pmip-qos-wifi-04.txt > >Hello, >We have a new draft on Mapping 802.11 QoS in PMIPv6 Mobility domain >(http://www.ietf.org/internet-drafts/draft-kaippallimalil-netext-pmip-q >os- >wifi-04.txt) with comments from the group addressed. > >The main comments from last meeting: >- Why do we need per-user QoS and what is missing ( -- new text in >Introduction) >- default connection/admission control, etc. ( -- revised/added us= e cases) >- Don't understand justification for DSCP map set ( -- removed from dra= ft) >- mapping of connection parameters between WiFi/PMIP ( -- added tables >for the mapping) > >We would like to get feedback on this draft/revision and would like to >have it adopted as a working group item. > >Regards, >John > > > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:in= ternet-drafts@ietf.org] >Sent: Tuesday, February 11, 2014 11:09 AM >To: John Kaippallimalil; John Kaippallimalil; Rajesh Pazhyannur; Parviz >Yegani; Rajesh Pazhyannur; Parviz Yegani >Subject: New Version Notification for >draft-kaippallimalil-netext-pmip-qos- >wifi-04.txt > > >A new version of I-D, draft-kaippallimalil-netext-pmip-qos-wifi-04.txt >has been successfully submitted by John Kaippallimalil and posted to >the IETF repository. > >Name: draft-kaippallimalil-netext-pmip-qos-wifi >Revision: 04 >Title: Mapping 802.11 QoS in a PMIPv6 Mobility Domain >Document date: 2014-02-10 >Group: Individual Submission >Pages: 24 >URL: http://www.ietf.org/internet-drafts/draft-kaippallimalil-n= etext- >pmip-qos-wifi-04.txt >Status: https://datatracker.ietf.org/doc/draft-kaippallimalil-nete= xt-pmip- >qos-wifi/ >Htmlized: http://tools.ietf.org/html/draft-kaippallimalil-netext-pmi= p-qos- >wifi-04 >Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-kaippallimalil-ne= text-pmip- >qos-wifi-04 > >Abstract: > This document provides recommendations on procedures and mapping of > QoS parameters between 802.11 and PMIPv6. QoS parameters in 802.11 > that reserve resources for 802.11 streams should be mapped to PMIP > QoS resources for IP sessions and flows. QoS reservation sequences in > 802.11 should allow cases where MN initiate resource reservation, as > well as cases where the network initiates resource reservation. > Additionally, it should be possible for QoS parameters for PMIPv6 > flows and mobility sessions to be mapped to 802.11 traffic stream > reservations. The sequences and parameters to be mapped to provide a > consistent behavior across 802.11 and PMIPv6 QoS are described here. > > > > > > >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. > >The IETF Secretariat > >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext --_000_4ED2E36A22261145861BAB2C24088B4320F5E1A7xmbalnx09ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks for the review. Appreciate it. <= /div>
 
Regards
 
Rajesh
 
-----Original Message-----
From: netext [mailto:netext-boun= ces@ietf.org] On Behalf Of pierrick.seite@orange.com
Sent: Tuesday, February 25, 2014 6:08 AM
To: John Kaippallimalil; netext@ietf.org
Subject: Re: [netext] [request for feedback] FW: New Version Notification f= or draft-kaippallimalil-netext-pmip-qos-wifi-04.txt
 
Hi John,
 
I have read draft-kaippallimalil-netext-pmip-qos-wifi and I found it v= ery good.
 
IMHO, this document is a good companion document of draft-ietf-netext-= pmip6-qos; it clarifies very well how to use PMIP QoS option on a WLAN acce= ss.
 
Hence, I have very few comments/questions:
 
- The draft assumes that MAC and WLC are collocated; can we imagine ar= chitecture where the controller is not in the datapath? If yes, what is the= impact?
 
>  Yes, definitely we should consider = the possibility of WLC not being in the datapath. In such= a case we assume that MAG is on the AP. The link between AP and WLC is only used for control and management and not for carr= ying the datapath.
> There is a third possibility where the MA= G is on the WLC but datapath is between the AP and LMA. (For example this c= ould be
Done using the Alt-CoA option.  I donR= 17;t think we have highlighted this case as this would depend on  how = the MAG (on WLC) communicates with AP (e.g., using CAPWAP or some other mea= ns).
 
- There is an unsaid assumption: the LMA is the decision maker regardi= ng the QoS policy. I think it should be clearly stated somewhere. I mean, a= lthough it is not the current trend, I imagine that some deployment may let= the MAG making the final decision regarding the QoS policy to apply.
 
>  I don’t fully understand the intent here. For example, = is the LMA sends a policy in an Update Request and the MAG does not have resources to meet it, the MAG can change it= .  But I suspect that  this is not what you are asking.
 
- You wrote that Mean Data Rate has no equivalent parameter in PMIP Qo= S. However, last update of pmip-qos draft includes a vendor specific option= which, IMO, could be used for that purpose.
 
> Noted.
 
BR,
Pierrick
 
>-----Message d'origine-----
>De : netext [mailt= o:netext-bounces@ietf.org] De la part de John
>Kaippallimalil Envoy=E9 : lundi 24 f=E9vrier 2014 18:43 =C0&n= bsp;: netext@ietf.org
>Objet : [netext] [request for feedback] FW: New Version Notif= ication
>for draft-kaippallimalil-netext-pmip-qos-wifi-04.txt
>
>Hello,
>We have a new draft on Mapping 802.11 QoS in PMIPv6 Mobility domai= n
>os-
>wifi-04.txt) with comments from the group addressed.
>
>The main comments from last meeting:
>- Why do we need per-user QoS and what is missing   = ; ( -- new text in
>Introduction)
>- default connection/admission control, etc.   &nbs= p;     ( -- revised/added use cases)
>- Don't understand justification for DSCP map set   = ; ( -- removed from draft)
>- mapping of connection parameters between WiFi/PMIP ( -- added ta= bles
>for the mapping)
>
>We would like to get feedback on this draft/revision and would lik= e to
>have it adopted as a working group item.
>
>Regards,
>John
>
>
>
>-----Original Message-----
>Sent: Tuesday, February 11, 2014 11:09 AM
>To: John Kaippallimalil; John Kaippallimalil; Rajesh Pazhyannur; P= arviz
>Yegani; Rajesh Pazhyannur; Parviz Yegani
>Subject: New Version Notification for
>draft-kaippallimalil-netext-pmip-qos-
>wifi-04.txt
>
>
>A new version of I-D, draft-kaippallimalil-netext-pmip-qos-wifi-04= .txt
>has been successfully submitted by John Kaippallimalil and posted = to
>the IETF repository.
>
>Name:          draft-= kaippallimalil-netext-pmip-qos-wifi
>Revision:      04
>Title:         Mapping 802= .11 QoS in a PMIPv6 Mobility Domain
>Document date: 2014-02-10
>Group:         Individual = Submission
>Pages:         24
>pmip-qos-wifi-04.txt
>qos-wifi/
>wifi-04
>qos-wifi-04
>
>Abstract:
>   This document provides recommendations on procedures = and mapping of
>   QoS parameters between 802.11 and PMIPv6. QoS paramet= ers in 802.11
>   that reserve resources for 802.11 streams should be m= apped to PMIP
>   QoS resources for IP sessions and flows. QoS reservat= ion sequences in
>   802.11 should allow cases where MN initiate resource = reservation, as
>   well as cases where the network initiates resource re= servation.
>   Additionally, it should be possible for QoS parameter= s for PMIPv6
>   flows and mobility sessions to be mapped to 802.11 tr= affic stream
>   reservations. The sequences and parameters to be mapp= ed to provide a
>   consistent behavior across 802.11 and PMIPv6 QoS are = described here.
>
>
>
>
>
>
>Please note that it may take a couple of minutes from the time of =
>submission until the htmlized version and diff are available at to= ols.ietf.org.
>
>The IETF Secretariat
>
>_______________________________________________
>netext mailing list
 
______________________________________________________________________= ___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con= fidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploite= s ou copies sans autorisation. Si vous avez recu ce message par erreur, veu= illez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques eta= nt susceptibles d'alteration, Orange decline toute responsabilite si ce mes= sage a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege= d information that may be protected by law; they should not be distributed,= used or copied without authorisation.
If you have received this email in error, please notify the sender and= delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified.
Thank you.
 
_______________________________________________
netext mailing list
 
 --_000_4ED2E36A22261145861BAB2C24088B4320F5E1A7xmbalnx09ciscoc_-- From nobody Tue Feb 25 09:04:18 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 0CC0B1A073A for ; Tue, 25 Feb 2014 09:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 V2Iyp5HgJPU8 for ; Tue, 25 Feb 2014 09:04:14 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6478E1A0735 for ; Tue, 25 Feb 2014 09:04:13 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBM66263; Tue, 25 Feb 2014 17:04:12 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 25 Feb 2014 17:04:03 +0000 Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 25 Feb 2014 17:04:11 +0000 Received: from DFWEML703-CHM.china.huawei.com ([169.254.5.106]) by dfweml705-chm.china.huawei.com ([169.254.7.50]) with mapi id 14.03.0158.001; Tue, 25 Feb 2014 09:03:59 -0800 From: John Kaippallimalil To: "pierrick.seite@orange.com" , "netext@ietf.org" Thread-Topic: [request for feedback] FW: New Version Notification for draft-kaippallimalil-netext-pmip-qos-wifi-04.txt Thread-Index: AQHPMYfbXs489yxZt0m9q+SV2+JAb5rGApSQgAAl6sA= Date: Tue, 25 Feb 2014 17:03:58 +0000 Message-ID: <6561EABF52675C45BCDACA1B4D7AA1171D9BDAD5@dfweml703-chm.china.huawei.com> References: <6561EABF52675C45BCDACA1B4D7AA1171D9BC3CA@dfweml703-chm.china.huawei.com> <31833_1393337251_530CA3A3_31833_8607_1_81C77F07008CA24F9783A98CFD706F71141FADF8@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <31833_1393337251_530CA3A3_31833_8607_1_81C77F07008CA24F9783A98CFD706F71141FADF8@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.65] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netext/AOhhwJvGuM1Y4NsMav8rVfmSucc Cc: Parviz Yegani Subject: Re: [netext] [request for feedback] FW: New Version Notification for draft-kaippallimalil-netext-pmip-qos-wifi-04.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: Tue, 25 Feb 2014 17:04:17 -0000 Hi Pierrick, I do appreciate the review and comments. The questions need clarification and we will revise the draft to address th= em.=20 A few notes inline below.. Best Regards, John > -----Original Message----- > From: pierrick.seite@orange.com [mailto:pierrick.seite@orange.com] > Sent: Tuesday, February 25, 2014 8:08 AM > To: John Kaippallimalil; netext@ietf.org > Subject: RE: [request for feedback] FW: New Version Notification for > draft-kaippallimalil-netext-pmip-qos-wifi-04.txt >=20 > Hi John, >=20 > I have read draft-kaippallimalil-netext-pmip-qos-wifi and I found it > very good. >=20 > IMHO, this document is a good companion document of draft-ietf-netext- > pmip6-qos; it clarifies very well how to use PMIP QoS option on a WLAN > access. >=20 > Hence, I have very few comments/questions: >=20 > - The draft assumes that MAC and WLC are collocated; can we imagine > architecture where the controller is not in the datapath? If yes, what > is the impact? Will revise text in Introduction to explain that this draft does not requir= e MAG/WLC/AP to be co-located.=20 We can discuss with you further about the controller/datapath. So far, we h= ave made no assumptions on a centralized controller, but can imagine that i= t is one solution to program the dataplane related entities.=20 >=20 > - There is an unsaid assumption: the LMA is the decision maker > regarding the QoS policy. I think it should be clearly stated > somewhere. I mean, although it is not the current trend, I imagine that > some deployment may let the MAG making the final decision regarding the > QoS policy to apply. Will revise. >=20 > - You wrote that Mean Data Rate has no equivalent parameter in PMIP > QoS. However, last update of pmip-qos draft includes a vendor specific > option which, IMO, could be used for that purpose. Will revise.=20 >=20 > BR, > Pierrick >=20 > >-----Message d'origine----- > >De=A0: netext [mailto:netext-bounces@ietf.org] De la part de John > >Kaippallimalil Envoy=E9=A0: lundi 24 f=E9vrier 2014 18:43 =C0=A0: > netext@ietf.org > >Objet=A0: [netext] [request for feedback] FW: New Version Notification > >for draft-kaippallimalil-netext-pmip-qos-wifi-04.txt > > > >Hello, > >We have a new draft on Mapping 802.11 QoS in PMIPv6 Mobility domain > >(http://www.ietf.org/internet-drafts/draft-kaippallimalil-netext-pmip- > q > >os- > >wifi-04.txt) with comments from the group addressed. > > > >The main comments from last meeting: > >- Why do we need per-user QoS and what is missing ( -- new text in > >Introduction) > >- default connection/admission control, etc. ( -- > revised/added use cases) > >- Don't understand justification for DSCP map set ( -- removed from > draft) > >- mapping of connection parameters between WiFi/PMIP ( -- added tables > >for the mapping) > > > >We would like to get feedback on this draft/revision and would like to > >have it adopted as a working group item. > > > >Regards, > >John > > > > > > > >-----Original Message----- > >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >Sent: Tuesday, February 11, 2014 11:09 AM > >To: John Kaippallimalil; John Kaippallimalil; Rajesh Pazhyannur; > Parviz > >Yegani; Rajesh Pazhyannur; Parviz Yegani > >Subject: New Version Notification for > >draft-kaippallimalil-netext-pmip-qos- > >wifi-04.txt > > > > > >A new version of I-D, draft-kaippallimalil-netext-pmip-qos-wifi-04.txt > >has been successfully submitted by John Kaippallimalil and posted to > >the IETF repository. > > > >Name: draft-kaippallimalil-netext-pmip-qos-wifi > >Revision: 04 > >Title: Mapping 802.11 QoS in a PMIPv6 Mobility Domain > >Document date: 2014-02-10 > >Group: Individual Submission > >Pages: 24 > >URL: http://www.ietf.org/internet-drafts/draft- > kaippallimalil-netext- > >pmip-qos-wifi-04.txt > >Status: https://datatracker.ietf.org/doc/draft-kaippallimalil- > netext-pmip- > >qos-wifi/ > >Htmlized: http://tools.ietf.org/html/draft-kaippallimalil- > netext-pmip-qos- > >wifi-04 > >Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-kaippallimalil- > netext-pmip- > >qos-wifi-04 > > > >Abstract: > > This document provides recommendations on procedures and mapping of > > QoS parameters between 802.11 and PMIPv6. QoS parameters in 802.11 > > that reserve resources for 802.11 streams should be mapped to PMIP > > QoS resources for IP sessions and flows. QoS reservation sequences > in > > 802.11 should allow cases where MN initiate resource reservation, > as > > well as cases where the network initiates resource reservation. > > Additionally, it should be possible for QoS parameters for PMIPv6 > > flows and mobility sessions to be mapped to 802.11 traffic stream > > reservations. The sequences and parameters to be mapped to provide > a > > consistent behavior across 802.11 and PMIPv6 QoS are described > here. > > > > > > > > > > > > > >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. > > > >The IETF Secretariat > > > >_______________________________________________ > >netext mailing list > >netext@ietf.org > >https://www.ietf.org/mailman/listinfo/netext >=20 > _______________________________________________________________________ > __________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou copies sans autorisation. Si vous avez recu ce message par > erreur, veuillez le signaler a l'expediteur et le detruire ainsi que > les pieces jointes. Les messages electroniques etant susceptibles > d'alteration, Orange decline toute responsabilite si ce message a ete > altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be > distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > Thank you. From nobody Wed Feb 26 00:54:19 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 8E1801A0135 for ; Wed, 26 Feb 2014 00:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 nbzndAuYkO8t for ; Wed, 26 Feb 2014 00:53:52 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 0CAFA1A012B for ; Wed, 26 Feb 2014 00:53:51 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 07CBE374192; Wed, 26 Feb 2014 09:53:50 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id E0FAF384078; Wed, 26 Feb 2014 09:53:49 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Wed, 26 Feb 2014 09:53:49 +0100 From: To: "Rajesh Pazhyannur (rpazhyan)" , John Kaippallimalil , "netext@ietf.org" Thread-Topic: [request for feedback] FW: New Version Notification for draft-kaippallimalil-netext-pmip-qos-wifi-04.txt Thread-Index: AQHPMYfbXs489yxZt0m9q+SV2+JAb5rGApSQgAAtqkCAAQt24A== Date: Wed, 26 Feb 2014 08:53:49 +0000 Message-ID: <14723_1393404829_530DAB9D_14723_13685_1_81C77F07008CA24F9783A98CFD706F71141FB388@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <6561EABF52675C45BCDACA1B4D7AA1171D9BC3CA@dfweml703-chm.china.huawei.com> <31833_1393337251_530CA3A3_31833_8607_1_81C77F07008CA24F9783A98CFD706F71141FADF8@PEXCVZYM12.corporate.adroot.infra.ftgroup> <4ED2E36A22261145861BAB2C24088B4320F5E1A7@xmb-aln-x09.cisco.com> In-Reply-To: <4ED2E36A22261145861BAB2C24088B4320F5E1A7@xmb-aln-x09.cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: multipart/alternative; boundary="_000_81C77F07008CA24F9783A98CFD706F71141FB388PEXCVZYM12corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.26.42115 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/X_AYtA6bfHuefOeDdaYe1s-YeHg Subject: Re: [netext] [request for feedback] FW: New Version Notification for draft-kaippallimalil-netext-pmip-qos-wifi-04.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: Wed, 26 Feb 2014 08:54:01 -0000 --_000_81C77F07008CA24F9783A98CFD706F71141FB388PEXCVZYM12corpo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Thaks for the answers, please see inline. Pierrick De : Rajesh Pazhyannur (rpazhyan) [mailto:rpazhyan@cisco.com] Envoy=E9 : mardi 25 f=E9vrier 2014 17:58 =C0 : SEITE Pierrick IMT/OLN; John Kaippallimalil; netext@ietf.org Objet : RE: [request for feedback] FW: New Version Notification for draft-k= aippallimalil-netext-pmip-qos-wifi-04.txt Thanks for the review. Appreciate it. Regards Rajesh -----Original Message----- From: netext [mailto:netext-bounces@ietf.org] On Behalf Of pierrick.seite@o= range.com Sent: Tuesday, February 25, 2014 6:08 AM To: John Kaippallimalil; netext@ietf.org Subject: Re: [netext] [request for feedback] FW: New Version Notification f= or draft-kaippallimalil-netext-pmip-qos-wifi-04.txt Hi John, I have read draft-kaippallimalil-netext-pmip-qos-wifi and I found it very g= ood. IMHO, this document is a good companion document of draft-ietf-netext-pmip6= -qos; it clarifies very well how to use PMIP QoS option on a WLAN access. Hence, I have very few comments/questions: - The draft assumes that MAC and WLC are collocated; can we imagine archite= cture where the controller is not in the datapath? If yes, what is the impa= ct? > Yes, definitely we should consider the possibility of WLC not being in t= he datapath. In such a case we assume that MAG is on the AP. The link betwe= en AP and WLC is only used for control and management and not for carrying = the datapath. > There is a third possibility where the MAG is on the WLC but datapath is = between the AP and LMA. (For example this could be Done using the Alt-CoA option. I don't think we have highlighted this case= as this would depend on how the MAG (on WLC) communicates with AP (e.g., = using CAPWAP or some other means). - There is an unsaid assumption: the LMA is the decision maker regarding th= e QoS policy. I think it should be clearly stated somewhere. I mean, althou= gh it is not the current trend, I imagine that some deployment may let the = MAG making the final decision regarding the QoS policy to apply. > I don't fully understand the intent here. For example, is the LMA sends = a policy in an Update Request and the MAG does not have resources to meet i= t, the MAG can change it. But I suspect that this is not what you are ask= ing. The document clearly illustrates how the MAG and LMA can negociate QoS ress= ources. My point is only on "who is making the final decision during this n= egotiation?"; the document assumes that the LMA makes the final decision an= d I'm fine with this. I'm just saying that this assumption should be clearl= y stated; just in case some people may want to let the MAG make the final d= ecision (BTW, your document allows this kind of implementation). - You wrote that Mean Data Rate has no equivalent parameter in PMIP QoS. Ho= wever, last update of pmip-qos draft includes a vendor specific option whic= h, IMO, could be used for that purpose. > Noted. BR, Pierrick >-----Message d'origine----- >De : netext [mailto:netext-bounces@ietf.org] De la part de John >Kaippallimalil Envoy=E9 : lundi 24 f=E9vrier 2014 18:43 =C0 : netext@ietf.= org >Objet : [netext] [request for feedback] FW: New Version Notification >for draft-kaippallimalil-netext-pmip-qos-wifi-04.txt > >Hello, >We have a new draft on Mapping 802.11 QoS in PMIPv6 Mobility domain >(http://www.ietf.org/internet-drafts/draft-kaippallimalil-netext-pmip-q >os- >wifi-04.txt) with comments from the group addressed. > >The main comments from last meeting: >- Why do we need per-user QoS and what is missing ( -- new text in >Introduction) >- default connection/admission control, etc. ( -- revised/added us= e cases) >- Don't understand justification for DSCP map set ( -- removed from dra= ft) >- mapping of connection parameters between WiFi/PMIP ( -- added tables >for the mapping) > >We would like to get feedback on this draft/revision and would like to >have it adopted as a working group item. > >Regards, >John > > > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:in= ternet-drafts@ietf.org] >Sent: Tuesday, February 11, 2014 11:09 AM >To: John Kaippallimalil; John Kaippallimalil; Rajesh Pazhyannur; Parviz >Yegani; Rajesh Pazhyannur; Parviz Yegani >Subject: New Version Notification for >draft-kaippallimalil-netext-pmip-qos- >wifi-04.txt > > >A new version of I-D, draft-kaippallimalil-netext-pmip-qos-wifi-04.txt >has been successfully submitted by John Kaippallimalil and posted to >the IETF repository. > >Name: draft-kaippallimalil-netext-pmip-qos-wifi >Revision: 04 >Title: Mapping 802.11 QoS in a PMIPv6 Mobility Domain >Document date: 2014-02-10 >Group: Individual Submission >Pages: 24 >URL: http://www.ietf.org/internet-drafts/draft-kaippallimalil-n= etext- >pmip-qos-wifi-04.txt >Status: https://datatracker.ietf.org/doc/draft-kaippallimalil-nete= xt-pmip- >qos-wifi/ >Htmlized: http://tools.ietf.org/html/draft-kaippallimalil-netext-pmi= p-qos- >wifi-04 >Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-kaippallimalil-ne= text-pmip- >qos-wifi-04 > >Abstract: > This document provides recommendations on procedures and mapping of > QoS parameters between 802.11 and PMIPv6. QoS parameters in 802.11 > that reserve resources for 802.11 streams should be mapped to PMIP > QoS resources for IP sessions and flows. QoS reservation sequences in > 802.11 should allow cases where MN initiate resource reservation, as > well as cases where the network initiates resource reservation. > Additionally, it should be possible for QoS parameters for PMIPv6 > flows and mobility sessions to be mapped to 802.11 traffic stream > reservations. The sequences and parameters to be mapped to provide a > consistent behavior across 802.11 and PMIPv6 QoS are described here. > > > > > > >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. > >The IETF Secretariat > >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_81C77F07008CA24F9783A98CFD706F71141FB388PEXCVZYM12corpo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 = ;

Thaks for = the answers, please see inline.

 = ;

Pierrick

 = ;

 = ;

De : Raje= sh Pazhyannur (rpazhyan) [mailto:rpazhyan@cisco.com]
Envoy=E9 : mardi 25 f=E9vrier 2014 17:58
=C0 : SEITE Pierrick IMT/OLN; John Kaippallimalil; netext@ietf.= org
Objet : RE: [request for feedback] FW: New Version Notification= for draft-kaippallimalil-netext-pmip-qos-wifi-04.txt

 

Thanks for the review. Ap= preciate it.

 = ;

Regards

 

Rajesh

 

-----Original Message-----
From: netext [mailto:netext-boun= ces@ietf.org] On Behalf Of pierrick.seite@orange.com
Sent: Tuesday, February 25, 2014 6:08 AM
To: John Kaippallimalil; netext@ietf.org
Subject: Re: [netext] [request for feedback] FW: New Version Notification f= or draft-kaippallimalil-netext-pmip-qos-wifi-04.txt

 

Hi John,

 

I have read draft-kaippallimalil-netext= -pmip-qos-wifi and I found it very good.

 

IMHO, this document is a good companion= document of draft-ietf-netext-pmip6-qos; it clarifies very well how to use= PMIP QoS option on a WLAN access.

 

Hence, I have very few comments/questio= ns:

 

- The draft assumes that MAC and WLC ar= e collocated; can we imagine architecture where the controller is not in th= e datapath? If yes, what is the impact?

 

>  Yes, definitely we should consider the possib= ility of WLC not being in the datapath. In such a case we assume that MAG i= s on the AP. The link between AP and WLC is only used for control and manag= ement and not for carrying the datapath.

> There is a third pos= sibility where the MAG is on the WLC but datapath is between the AP and LMA= . (For example this could be

Done using the Alt-CoA op= tion.  I don’t think we have highlighted this case as this would= depend on  how the MAG (on WLC) communicates with AP (e.g., using CAPWAP or some other means).

 = ;

- There is an unsaid assumption: the LM= A is the decision maker regarding the QoS policy. I think it should be clea= rly stated somewhere. I mean, although it is not the current trend, I imagine that some deployment may let the MAG making the final dec= ision regarding the QoS policy to apply.

 

>  I don’t fully understand the intent her= e. For example, is the LMA sends a policy in an Update Request and the MAG = does not have resources to meet it, the MAG can change it.  But I susp= ect that  this is not what you are asking.

 <= /p>

The docume= nt clearly illustrates how the MAG and LMA can negociate QoS ressources. My= point is only on “who is making the final decision during this negotiation?”; the document assumes that the LMA makes the fina= l decision and I’m fine with this. I’m just saying that this as= sumption should be clearly stated; just in case some people may want to let= the MAG make the final decision (BTW, your document allows this kind of implementation).

&nbs= p;

- You wrote that Mean Data Rate has no = equivalent parameter in PMIP QoS. However, last update of pmip-qos draft in= cludes a vendor specific option which, IMO, could be used for that purpose.

 

> Noted.

 

BR,

Pierrick

 

>-----Message d'origine-----

>De : netext [mailto:netext-bounces@ietf.org] De la part de= John

>Kaippallimalil Envoy=E9 : lund= i 24 f=E9vrier 2014 18:43 =C0 : netext@ietf.org

>Objet : [netext] [request for = feedback] FW: New Version Notification

>for draft-kaippallimalil-netext-pmi= p-qos-wifi-04.txt

> 

>Hello,

>We have a new draft on Mapping 802.= 11 QoS in PMIPv6 Mobility domain

>os-

>wifi-04.txt) with comments from the= group addressed.

> 

>The main comments from last meeting= :

>- Why do we need per-user QoS and w= hat is missing    ( -- new text in

>Introduction)

>- default connection/admission cont= rol, etc.         ( -- revised/adde= d use cases)

>- Don't understand justification fo= r DSCP map set    ( -- removed from draft)=

>- mapping of connection parameters = between WiFi/PMIP ( -- added tables

>for the mapping)<= /p>

> 

>We would like to get feedback on th= is draft/revision and would like to

>have it adopted as a working group = item.

> 

>Regards,

>John

> 

> 

> 

>-----Original Message-----

>From: internet-drafts@ietf.org [<= a href=3D"mailto:internet-drafts@ietf.org">mailto:internet-drafts@ietf.org<= /a>]

>Sent: Tuesday, February 11, 2014 11= :09 AM

>To: John Kaippallimalil; John Kaipp= allimalil; Rajesh Pazhyannur; Parviz

>Yegani; Rajesh Pazhyannur; Parviz Y= egani

>Subject: New Version Notification f= or

>draft-kaippallimalil-netext-pmip-qo= s-

>wifi-04.txt

> 

> 

>A new version of I-D, draft-kaippal= limalil-netext-pmip-qos-wifi-04.txt

>has been successfully submitted by = John Kaippallimalil and posted to

>the IETF repository.

> 

>Name:     =      draft-kaippallimalil-netext-pmip-qos-wifi

>Revision:    &n= bsp; 04

>Title:     = ;    Mapping 802.11 QoS in a PMIPv6 Mobility Domain

>Document date: 2014-02-10

>Group:     = ;    Individual Submission

>Pages:     = ;    24

>pmip-qos-wifi-04.txt

>qos-wifi/

>wifi-04

>qos-wifi-04

> 

>Abstract:

>   This document provides= recommendations on procedures and mapping of

>   QoS parameters between= 802.11 and PMIPv6. QoS parameters in 802.11

>   that reserve resources= for 802.11 streams should be mapped to PMIP

>   QoS resources for IP s= essions and flows. QoS reservation sequences in

>   802.11 should allow ca= ses where MN initiate resource reservation, as

>   well as cases where th= e network initiates resource reservation.

>   Additionally, it shoul= d be possible for QoS parameters for PMIPv6

>   flows and mobility ses= sions to be mapped to 802.11 traffic stream

>   reservations. The sequ= ences and parameters to be mapped to provide a

>   consistent behavior ac= ross 802.11 and PMIPv6 QoS are described here.

> 

> 

> 

> 

> 

> 

>Please note that it may take a coup= le of minutes from the time of

>submission until the htmlized versi= on and diff are available at tools.ietf.org.

> 

>The IETF Secretariat

> 

>___________________________________= ____________

>netext mailing list

 

_______________________________________= ___________________________________________________________________________= _______

 

Ce message et ses pieces jointes peuven= t contenir des informations confidentielles ou privilegiees et ne doivent d= onc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expedite= ur et le detruire ainsi que les pieces jointes. Les messages electroniques = etant susceptibles d'alteration, Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci.

 

This message and its attachments may co= ntain confidential or privileged information that may be protected by law; = they should not be distributed, used or copied without authorisation.<= /o:p>

If you have received this email in erro= r, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not= liable for messages that have been modified, changed or falsified.

Thank you.

 

_______________________________________= ________

netext mailing list

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_81C77F07008CA24F9783A98CFD706F71141FB388PEXCVZYM12corpo_-- From nobody Wed Feb 26 12:18: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 7870C1A0880 for ; Wed, 26 Feb 2014 12:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 4ym-C4YnTVeP for ; Wed, 26 Feb 2014 12:18:45 -0800 (PST) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE3F1A0870 for ; Wed, 26 Feb 2014 12:18:45 -0800 (PST) Received: by mail-oa0-f41.google.com with SMTP id o6so1442473oag.28 for ; Wed, 26 Feb 2014 12:18:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=/EGFFW2agr4NDuey8PEzKFLoLoctVyp1WzhyXYOIjac=; b=m7m+5gn0C6cjNGLLA6MhhG5kKvAoSLFSE0OhBCMW5LPv/V7q38Rn+p7ui4vsmvc9+j /H2wMVnf6Tbi3o0lbdH4x3poKP/ONvq0DTmUgdL/hN5vYoS2bcQ+J22pTqGV7fdjOq5k VVb3/2dHzuCJ6Qoei2xsah3EPsnX3Z0xFI/Tevlg4kF7PXZAsVOEDrw0Sqf3Mq4AheGP xwfCULm9SEATxLotUMsT+tDkkSf1++JA3ebvg6bUTe+utTO8Asf1tolYnhHZNAKeX6jV qipO0R/2wqGsoWsU8NIJIo9AzWO7IDvhOOTHon/ihhlxzIKTa4aOQFTHCgziX4/X7+z4 vaVw== MIME-Version: 1.0 X-Received: by 10.60.52.101 with SMTP id s5mr8364515oeo.7.1393445923854; Wed, 26 Feb 2014 12:18:43 -0800 (PST) Received: by 10.182.232.105 with HTTP; Wed, 26 Feb 2014 12:18:43 -0800 (PST) Date: Wed, 26 Feb 2014 14:18:43 -0600 Message-ID: From: Basavaraj Patil To: "netext@ietf.org" Content-Type: multipart/alternative; boundary=001a11330d544e651504f354e981 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/z2YtIVBXFfP4dNvtEgAn3Ej0uYs Subject: [netext] Agenda for WG meeting at IETF89 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: Wed, 26 Feb 2014 20:18:46 -0000 --001a11330d544e651504f354e981 Content-Type: text/plain; charset=ISO-8859-1 Network-Based Mobility Extensions (NetExt) WG meeting FRIDAY, March 7, 2014 0900-1130 GMT Friday Morning Session I (Palace C) Chairs: Rajeev Koodli Basavaraj Patil --------------------------------------------------------------------- 1. Logistics (Bluesheets, minutes takers, jabber, agenda bashing) 5 mins 2. WG Status update Chairs 5 Mins 3. Proxy Mobile IPv6 Extensions to Support Flow Mobility 20 Mins I-D: draft-ietf-netext-pmipv6-flowmob CJ Bernardos 4. Mapping 802.11 QoS in a PMIPv6 Mobility Domain 15 Mins I-D: draft-kaippallimalil-netext-pmip-qos-wifi-04 J. Kaippallimalil 5. Civic location ANI suboption for PMIP6 10 Mins I-D: draft-pazhyannur-netext-civic-location-ani-subopt-01.txt R. Pazhyannur 6. Roadmap for Netext 10 Mins Chairs/AD --001a11330d544e651504f354e981 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Network-Based Mobility Extensions (Net= Ext) WG meeting

FRIDAY, March 7, 2014
09= 00-1130 GMT Friday Morni= ng Session I (Palace C)

Chairs: Rajeev Koodli
Basavaraj Patil

-----= ----------------------------------------------------------------
=
1. Logistics (Bluesheets, minutes takers, jabber, agenda bashing= ) 5 mins

2. WG Status update =A0Chairs =A0 =A05 Mins

3. Proxy Mobile IPv6 Extensions to Support Flow Mobilit= y =A020 Mins
=A0 =A0I-D: draft-ietf-netext-pmipv6-flowmob =A0CJ Bernardos

=
4. Mapping 802.11 QoS in a PMIPv6 Mobility Domain =A0 =A0 =A0 15 Mins
=
=A0 =A0I-D: draft-kaippallimalil-netext-pmip-qos-wifi-04 =A0 =A0J. Kai= ppallimalil

5. Civic location ANI suboption for PM= IP6 10 Mins
=A0 =A0I-D: draft-pazhyannur-netext-civic-location-ani-subopt-01.txt = =A0 =A0R. Pazhyannur


6. Roadmap for= Netext 10 Mins =A0 =A0= =A0 Chairs/AD


--001a11330d544e651504f354e981-- From nobody Fri Feb 28 11:51: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 7F4021A02A1 for ; Fri, 28 Feb 2014 11:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 orw3nPLiYHH0 for ; Fri, 28 Feb 2014 11:51:22 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 701F41A0286 for ; Fri, 28 Feb 2014 11:51:22 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id uz6so4408968obc.1 for ; Fri, 28 Feb 2014 11:51:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=l6ok9Huqj68AeMvGd1bhSwb1iC6EkI/6WhqijJVwnm0=; b=cor5vgO0qe4kflD79CODUhwy4R6+4bMTrsqVPL+fTOjY4Lt+9m93CRA7LYCHSpOZH9 Z4td4EFB0zz1uo+fez3QJ7oXyLSloq0BLlqxkboGHGaGaZmiRNdjTwL35vzBxTIuPcTF MN5nexdA5Uph6f3FkkldgVu5HkiUnUaPROPUxQzM8pjr/gZqo8TUMRxE3xyN447fNK29 9gzgKQDP9SS/Lc9aLMxg6M5pc/LIJ/Jno3AXR9QRM9HTRaVV8tOJ2KgfHihyjOPTfjRB lmop1HcE0DCvNCPN1TLHV5b49p31gBorGGLlcwolp3lx4/LyD+TBEIf59SSvlBNq/Of3 RtIg== MIME-Version: 1.0 X-Received: by 10.182.81.197 with SMTP id c5mr15666773oby.40.1393617080382; Fri, 28 Feb 2014 11:51:20 -0800 (PST) Received: by 10.182.76.196 with HTTP; Fri, 28 Feb 2014 11:51:20 -0800 (PST) Date: Fri, 28 Feb 2014 13:51:20 -0600 Message-ID: From: Basavaraj Patil To: "netext@ietf.org" Content-Type: multipart/alternative; boundary=047d7b2e4d58077a3304f37cc3d5 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/ftnn--m8b7FTtb3m2dKouVGFSes Subject: [netext] Consensus call to adopt I-D: draft-kaippallimalil-netext-pmip-qos-wifi-04 as WG doc 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, 28 Feb 2014 19:51:23 -0000 --047d7b2e4d58077a3304f37cc3d5 Content-Type: text/plain; charset=ISO-8859-1 Hello, The WG has discussed the following I-D: Mapping 802.11 QoS in a PMIPv6 Mobility Domain at several WG meetings. This is a consensus call to adopt this I-D as a working group document and progress it as on the Informational track. Please respond to the following question; Q: Do you support adoption of the I-D draft-kaippallimalil-netext-pmip-qos-wifi-04 as a Netext WG document? Yes [ ] No [ ] -Chairs --047d7b2e4d58077a3304f37cc3d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hello,

The WG has discussed the following I-D:=A0
Mapping 802.11 QoS in a PMIPv6 Mobility Domain <draft-kaippallimalil-netext-pmip-qos-wifi-04>

<= /div>at several WG meetings.=A0

This is a consensus call= to adopt this I-D as a working group document and progress it as on the In= formational track.

Please respond to the following question;
Q: Do you support adoption of the I-D=A0draft-kaippallimalil-netext-pmip= -qos-wifi-04=A0=A0as a Netext WG document?

Yes =A0[ =A0]
No =A0 [ =A0]<= /div>

-Chairs

--047d7b2e4d58077a3304f37cc3d5-- From nobody Fri Feb 28 13:54:56 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 1BD861A02A9 for ; Fri, 28 Feb 2014 13:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.047 X-Spam-Level: X-Spam-Status: No, score=-10.047 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, RP_MATCHES_RCVD=-0.547, 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 AK1tTBZevruv for ; Fri, 28 Feb 2014 13:54:53 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 44CB51A0269 for ; Fri, 28 Feb 2014 13:54:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4484; q=dns/txt; s=iport; t=1393624491; x=1394834091; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=6HJotRsepWaXjNWiKb+X/t5efpKpP4E3oVA+T+9h3e0=; b=kB/1tuQzuy8qeN9Z3IfI8WA1nQv4VZU2sP76pHr1TgYzxHURGu2I/rlb KGhu4Rl13lpXdi2dzSXH9zweCUQ5GI07Q97Cg3ioKsoFgwpkSfwdaIr9c hC69EsZcsgFY/NGfCotEyh0mJ+63MCAjW2DXSaN6/xq1z8+XNUZgesTj+ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAEUEEVOtJV2a/2dsb2JhbABZgkJEgRLBIIEVFnSCJQECBIELAQgECgMDAQIoKBEUCQgCBAESh2UDEcRADYcdF4w/ggUYhDcElk2BbYxjhUiBb4E+gio X-IronPort-AV: E=Sophos; i="4.97,564,1389744000"; d="scan'208,217"; a="24059342" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP; 28 Feb 2014 21:54:51 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1SLsoQM024395 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Feb 2014 21:54:51 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.138]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Fri, 28 Feb 2014 15:54:50 -0600 From: "Sri Gundavelli (sgundave)" To: Basavaraj Patil , "netext@ietf.org" Thread-Topic: [netext] Consensus call to adopt I-D: draft-kaippallimalil-netext-pmip-qos-wifi-04 as WG doc Thread-Index: AQHPNM+0v6KIEH+pWEWdLmE4NAS3wQ== Date: Fri, 28 Feb 2014 21:54:49 +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.213] Content-Type: multipart/alternative; boundary="_000_CF3644E311A857sgundaveciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/qci-Qrk8S5cUDNJoodxZKmhpFDw Subject: Re: [netext] Consensus call to adopt I-D: draft-kaippallimalil-netext-pmip-qos-wifi-04 as WG doc 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, 28 Feb 2014 21:54:55 -0000 --_000_CF3644E311A857sgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I think this is a good proposal. A companion document to the IETF PMIP-QoS = document with focus on WLAN access. I support this work; Its a useful document for PMIP-based SP Wi-Fi architec= tures. The current =9600 version can be adopted as the WG document and should be u= sed as the basis for further discussions and WG contributions. Sri From: Basavaraj Patil > Date: Friday, February 28, 2014 11:51 AM To: "netext@ietf.org" > Subject: [netext] Consensus call to adopt I-D: draft-kaippallimalil-netext-= pmip-qos-wifi-04 as WG doc Hello, The WG has discussed the following I-D: Mapping 802.11 QoS in a PMIPv6 Mobility Domain at several WG meetings. This is a consensus call to adopt this I-D as a working group document and = progress it as on the Informational track. Please respond to the following question; Q: Do you support adoption of the I-D draft-kaippallimalil-netext-pmip-qos-= wifi-04 as a Netext WG document? Yes [ ] No [ ] -Chairs --_000_CF3644E311A857sgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

I think this is a good proposal. A companion document to the IETF PMIP= -QoS document with focus on WLAN access.

I support this work; Its a useful document for PMIP-based SP Wi-Fi arc= hitectures. 

The current =9600 version can be adopted as the WG document and should= be used as the basis for further discussions and WG contributions.


Sri



From: Basavaraj Patil <bpatil1@gmail.com>
Date: Friday, February 28, 2014 11:= 51 AM
To: "netext@ietf.org" <= netext@ietf.org>
Subject: [netext] Consensus call to= adopt I-D: draft-kaippallimalil-netext-pmip-qos-wifi-04 as WG doc


Hello,

The WG has discussed the following I-D: 
Mapping 802.11 QoS in a PMIPv6 Mobility Domain
<draft-kaippallimalil-netext-pmip-qos-wifi-04>

at several WG meetings. 

This is a consensus call to adopt this I-D as a working group document= and progress it as on the Informational track.

Please respond to the following question;

Q: Do you support adoption of the I-D draft-kaippallimalil-netext-pmip-qos= -wifi-04  as a Netext WG document?

Yes  [  ]
No   [  ]

-Chairs

 --_000_CF3644E311A857sgundaveciscocom_--