diff options
Diffstat (limited to 'doc/rfc/rfc7222.txt')
| -rw-r--r-- | doc/rfc/rfc7222.txt | 3251 |
1 files changed, 3251 insertions, 0 deletions
diff --git a/doc/rfc/rfc7222.txt b/doc/rfc/rfc7222.txt new file mode 100644 index 0000000..d3dc167 --- /dev/null +++ b/doc/rfc/rfc7222.txt @@ -0,0 +1,3251 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Liebsch +Request for Comments: 7222 NEC +Category: Standards Track P. Seite +ISSN: 2070-1721 Orange + H. Yokota + KDDI Lab + J. Korhonen + Broadcom Communications + S. Gundavelli + Cisco + May 2014 + + + 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. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7222. + + + + + + + + +Liebsch, et al. Standards Track [Page 1] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + +Copyright Notice + + Copyright (c) 2014 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. + +Table of Contents + + 1. Introduction ....................................................3 + 2. Conventions and Terminology .....................................4 + 2.1. Conventions ................................................4 + 2.2. Terminology ................................................5 + 3. Overview of QoS Support in Proxy Mobile IPv6 ....................7 + 3.1. Quality-of-Service Option -- Usage Examples ................9 + 3.2. Quality-of-Service Attributes -- Usage Examples ...........11 + 4. Protocol Messaging Extensions ..................................12 + 4.1. Quality-of-Service Option .................................12 + 4.2. Quality-of-Service Attributes .............................14 + 4.2.1. Per-Mobile-Node Aggregate Maximum Downlink + Bit Rate ...........................................16 + 4.2.2. Per-Mobile-Node Aggregate Maximum Uplink Bit Rate ..17 + 4.2.3. Per-Mobility-Session Aggregate Maximum + Downlink Bit Rate ..................................18 + 4.2.4. Per-Mobility-Session Aggregate Maximum + Uplink Bit Rate ....................................20 + 4.2.5. Allocation and Retention Priority ..................22 + 4.2.6. Aggregate Maximum Downlink Bit Rate ................23 + 4.2.7. Aggregate Maximum Uplink Bit Rate ..................25 + 4.2.8. Guaranteed Downlink Bit Rate .......................26 + 4.2.9. Guaranteed Uplink Bit Rate .........................27 + 4.2.10. QoS Traffic Selector ..............................28 + 4.2.11. QoS Vendor-Specific Attribute .....................29 + 4.3. New Status Code for Proxy Binding Acknowledgement .........30 + 4.4. New Notification Reason for Update Notification Message ...30 + 4.5. New Status Code for Update Notification + Acknowledgement Message ...................................31 + 5. Protocol Considerations ........................................31 + 5.1. Local Mobility Anchor Considerations ......................31 + 5.2. Mobile Access Gateway Considerations ......................35 + + + +Liebsch, et al. Standards Track [Page 2] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + 6. QoS Services in Integrated WLAN-3GPP Networks ..................39 + 6.1. Technical Scope and Procedure .............................39 + 6.2. Relevant QoS Attributes ...................................41 + 7. IANA Considerations ............................................42 + 8. Security Considerations ........................................44 + 9. Acknowledgements ...............................................44 + 10. References ....................................................44 + 10.1. Normative References .....................................44 + 10.2. Informative References ...................................45 + Appendix A. Information When Implementing 3GPP QoS in IP + Transport Network ....................................47 + A.1. Mapping Tables ............................................47 + A.2. Use Cases and Protocol Operations .........................48 + A.2.1. Handover of Existing QoS Rules ........................48 + A.2.2. Establishment of QoS Rules ............................50 + A.2.3. Dynamic Update to QoS Policy ..........................52 + Appendix B. Information When Implementing PMIP-Based QoS Support + with IEEE 802.11e ....................................53 + Appendix C. Information When Implementing with a Broadband + Network Gateway ......................................57 + +1. Introduction + + Mobile operators deploy Proxy Mobile IPv6 (PMIPv6) [RFC5213] to + enable network-based mobility management for mobile nodes (MNs). + Users can access IP-based services from their mobile device by using + various radio access technologies. The currently supported mobile + standards have adequate support for QoS-based service differentiation + for subscriber traffic in cellular radio access networks. 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 (LMA) and the + mobile access gateway (MAG), as well as by access network elements. + Policy control and in-band QoS differentiation for access to the + mobile operator network through alternative non-cellular access + technologies are not supported in the currently specified standards. + Although support for IP session handovers and IP flow mobility across + access technologies already exists in cellular standards [TS23.402], + QoS policy handovers across access technologies has not received much + attention so far. + + Based on the deployment trends, Wireless LAN (WLAN) can be considered + as the dominant alternative access technology to complement cellular + radio access. Since the 802.11e extension [IEEE802.11e-2005] + 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 + + + + +Liebsch, et al. Standards Track [Page 3] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + mobility anchor. For realizing this capability, this specification + identifies three functional operations: + + (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 + IP session classification characteristics, such as a Differentiated + Services Code Point (DSCP) [RFC2474], and the expected QoS class for + the IP session. This document specifies fundamental QoS attributes + that apply on a per-mobile-node, per-mobility-session, or 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 + [IEEE802.11-2012]. + + 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 the scope of + this specification. + +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]. + + + + + + + + +Liebsch, et al. Standards Track [Page 4] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + +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: + + 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 within the flows + exceeding the AMBR limit may be discarded by the rate-shaping + function where the AMBR parameter is enforced. Variants of the + "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. For example, 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 are used in this document. + + Allocation and Retention Priority (AARP) + + AARP is used in congestion situations when there are insufficient + resources for meeting all Service 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 honored by preempting an existing low-priority + service. + + Differentiated Services Code Point (DSCP) + + In the 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], [RFC4594], and [RFC2983] for a complete explanation. + + Downlink (DL) Traffic + + The mobile node's IP packets that the mobile access gateway + receives from the local mobility anchor are 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. + + + + + +Liebsch, et al. Standards Track [Page 5] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + 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. + + 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. + + QoS Service Request + + A QoS Service Request is 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. + + 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 (for example, + Internet Service and Voice Over IP Service) and has an identifier + called "Service Identifier". 3GPP APN (Access Point Name) is an + example of a Service Identifier. Refer to [RFC5149] for the + definition of the Service Identifier and the mobility option used + for carrying the Service Identifier. + + Uplink (UL) Traffic + + The mobile node's IP packets that the mobile access gateway + forwards to the local mobility anchor are 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 it implies traffic originating from the mobile node. + + + + + + +Liebsch, et al. Standards Track [Page 6] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + +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 supported in 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. As the tunnel entry and exit points for + the mobile node's IP traffic, these entities are the logical choice + for being chosen as the QoS enforcement points. The basic QoS + functions 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) as well as for realizing relative performance treatment by way + of class-based differentiation. The subscriber's policy and the + charging profile (for example, [TS22.115]) are key considerations 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 + 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. Standards Track [Page 7] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + +=======+ + | MN-1 | + +=======+ + | | | Flow-6 + Flow-1<--(GBR: 64 Kbps) | + | Flow-4 | + Flow-2 | | | + | | Flow-1 | | + | Flow-3 | | | + |_|_| DSCP-X | | | + ( )<--(Per-Session-AMBR: 1 Mbps) : | | | + | | | DSCP-Z : | | | + | | : : | | | + | | | +=====+ +==:=v+ | | | + | '- -- - - - --| | | : o|--' | | + | '- - --- - - -| | __ | v o|----' | + '- - - - - - - -| | _--' '--_ | o--|------' + | | ( ) | | + | MAG |=====( IP Network )=====| LMA | + | | ( ) | | + ,- - - - - - - - -| | '--__--' | o|-- - -, + ,- - -- - -- - -| | | o|--- , | + | | ,- - - - -- -| | | o|--, | | + | | +=====+ +====^+ | | | + |_|_| : | | | + ( _ _ )<--(Per-Session-AMBR: 2 Mbps) : | | | + | | | DSCP-Y | | | + | | | | | + | | | | | | + | Flow-6 Flow-2 | | + | | | | + Flow-5 (MBR: 100 Kbps) Flow-3 | + | | + Flow-4 (GBR: 64 Kbps) Flow-5 + | | | + +=======+ + | MN-2 | + +=======+ + + Figure 1: QoS Support + + Figure 1 illustrates 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. The negotiated QoS parameters include a Per-Session- + AMBR of 1 Mbps and 2 Mbps for MN-1 and MN-2 respectively. + Furthermore, different IP flows from MN-1 and MN-2 are given + + + + +Liebsch, et al. Standards Track [Page 8] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + different QoS service treatment, for example, a GBR of 64 Kbps for + Flow-1 and Flow-4 is assured, a DSCP marking enforcement of "Z" on + Flow-6, and an MBR of 100 Kbps on Flow-5. + +3.1. Quality-of-Service Option -- Usage Examples + + Use Case 1: Figure 2 illustrates 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. + Upon completing the signaling, the LMA and MAG 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 (UPN) message [RFC7077] to the MAG. The + message includes the QoS option (Section 4.1), which includes a + set of QoS parameters. On determining that it cannot support the + + + +Liebsch, et al. Standards Track [Page 9] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + requested QoS Service Request for that mobile, the MAG sends an + Update Notification Acknowledgement (UPA) message. The message + contains a revised QoS option with an updated set of QoS + attributes. The LMA accepts the revised QoS Service Request by + sending a new Update Notification message including the updated + 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) installs the QoS rules on the access network. + + Use Case 2: Figure 3 illustrates 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. + Upon completing the signaling, the LMA and MAG 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 + (PBU) message [RFC5213] to the LMA. The message includes the QoS + + + +Liebsch, et al. Standards Track [Page 10] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + option (Section 4.1), which includes a set of QoS parameters. The + LMA agrees to the proposed QoS Service Request by sending a Proxy + Binding Acknowledgement (PBA) 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 installs the QoS rules on the access network. + +3.2. Quality-of-Service Attributes -- Usage Examples + + This section identifies the use cases where the Quality-of-Service + option (Section 4.1) and its attributes (Section 4.2) defined in this + document are relevant. + + o The subscription policy offered to a mobile subscriber requires + the service provider to enforce Aggregate Maximum Bit Rate (AMBR) + limits on the subscriber's IP traffic. The local mobility anchor + and the mobile access gateway negotiate the uplink and the + downlink AMBR values for the mobility session and enforce them in + the access and the home network. The QoS option (Section 4.1) + with the QoS attributes Per-Session-Agg-Max-DL-Bit-Rate + (Section 4.2.3) and Per-Session-Agg-Max-UL-Bit-Rate + (Section 4.2.4) is used for this purpose. + + o In Community Wi-Fi deployments, the residential gateway + participating in the Wi-Fi service is shared between the home user + and the community Wi-Fi users. In order to ensure the home user's + Wi-Fi service is not impacted because of the community Wi-Fi + service, the service provider enables Guaranteed Bit Rate (GBR) + for the home user's traffic. The QoS option (Section 4.1) with + the QoS attributes Guaranteed-DL-Bit-Rate (Section 4.2.8) and + Guaranteed-UL-Bit-Rate (Section 4.2.9) is used for this purpose. + + o A mobile user using the service provider's Voice over IP + infrastructure establishes a VoIP call with some other user in the + network. The negotiated call parameters for the VoIP call require + a dedicated bandwidth of certain fixed value for the media flows + associated with that VoIP session. The application function in + the VoIP infrastructure notifies the local mobility anchor to + enforce the GBR limits on that IP flow identified by the flow + definition. The QoS option (Section 4.1) with the QoS attributes + Guaranteed-DL-Bit-Rate (Section 4.2.8), Guaranteed-UL-Bit-Rate + (Section 4.2.9), and QoS-Traffic-Selector (Section 4.2.10) is used + for this purpose. + + + + + + +Liebsch, et al. Standards Track [Page 11] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + o An emergency service may require network resources in conditions + when the network resources have been fully allocated to other + users and the network may be experiencing severe congestion. In + such cases, the service provider may want to revoke resources that + have been allocated and reassign them to emergency services. The + local mobility anchor and the mobile access gateway negotiate + Allocation and Retention Priority (AARP) values for the IP + sessions associated with the emergency applications. The QoS + option (Section 4.1) with the QoS attribute Allocation-Retention- + Priority (Section 4.2.5) is used for this purpose. + +4. Protocol Messaging Extensions + +4.1. Quality-of-Service Option + + The Quality-of-Service option is a mobility header option used by + local mobility anchors and mobile access gateways 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 + + o Type: 58 + + o Length: 8-bit unsigned integer indicating the length of the option + in octets, excluding the Type and Length fields. + + o Service Request Identifier (SR-ID): An 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 Service Request Identifier. When a new QoS Service + + + +Liebsch, et al. Standards Track [Page 12] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + Request is initiated by a mobile access gateway, the Service + Request Identifier in the initial request message is set to a + value of (0), and the local mobility anchor allocates a Service + Request Identifier and includes it in the response. For any new + QoS Service Requests initiated by a local mobility anchor, the + Service Request Identifier is set to the allocated value. + + o 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 + a 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. + + Reserved + + 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. + + o Operational Code (OC): 1-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 + that are still active + + + + + +Liebsch, et al. Standards Track [Page 13] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + 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. + + o 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. + + o QoS Attribute(s): Zero or more 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 Attributes + + This section identifies the format of a Quality-of-Service attribute. + A QoS attribute can be included in the Quality-of-Service option + defined in Section 4.1. 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 + + o 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 + + (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. + + + +Liebsch, et al. Standards Track [Page 14] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + (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. + + (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. + + (12) to (254) - Reserved + These values are reserved for future allocation. + + (255) - Reserved + This value is reserved and cannot be used. + + o Length: 8-bit unsigned integer indicating the number of octets + needed to encode the Value, excluding the Type and Length fields. + + o Value: The format of this field is based on the Type value. + + + + + + + + + +Liebsch, et al. Standards Track [Page 15] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + +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 an 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 with sessions anchored either + on a single local mobility anchor or spread out across multiple local + mobility anchors, then it depends on the operator's policy and the + specific deployment as to how the total bandwidth for the mobile node + on each MAG-LMA pair is computed. + + When a QoS option includes both the Per-MN-Agg-Max-DL-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 | 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). + + + + + + +Liebsch, et al. Standards Track [Page 16] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + 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: This is a 32-bit unsigned integer that + 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 with sessions anchored either + on a single local mobility anchor or spread out across multiple local + mobility anchors, then it depends on the operator's policy and the + specific deployment as to how the total bandwidth for the mobile node + on each MAG-LMA pair is computed. + + When a QoS option includes both the Per-MN-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. + + + + + + + + + +Liebsch, et al. Standards Track [Page 17] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + 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: This is a 32-bit unsigned integer that + 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), + then the QoS-Traffic-Selector attribute does not apply to this + attribute. + + + + + +Liebsch, et al. Standards Track [Page 18] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + 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 the mobile + node's other mobility sessions sharing the same Service + Identifier. 3GPP Access Point Name (APN) is an example of a + 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 the target + flows are limited to the current mobility session. + + * 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 the downlink + flows for which the network is providing Guaranteed-Bit-Rate + service 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 + to exclude 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 is measured. + + * When the (E) flag is set to a value of (0), then the request is + not to exclude any IP flows from the target IP flows for which + Per-Session-Agg-Max-DL-Bit-Rate is measured. + + + + + + + +Liebsch, et al. Standards Track [Page 19] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + * When the (S) flag and (E) flag are both set to a value of (1), + then the request is to exclude all the IP flows sharing the + 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: This is a 32-bit unsigned integer + that 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. Standards Track [Page 20] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + 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 the mobile + node's other mobility sessions sharing the same Service + Identifier. 3GPP Access Point Name (APN) is an example of a + 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 the target + flows are limited to the current mobility session. + + * 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 the uplink + flows for which the network is providing Guaranteed-Bit-Rate + service be excluded from the target IP flows for which Per- + Session-Agg-Max-UL-Bit-Rate is measured. + + * When the (E) flag is set to a value of (1), then the request is + to exclude 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 the request is + not to exclude any IP flows from the target IP flows for which + Per-Session-Agg-Max-UL-Bit-Rate is measured. + + * When the (S) flag and (E) flag are both set to a value of (1), + then the request is to exclude 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. + + + + + +Liebsch, et al. Standards Track [Page 21] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + o Per-Session-Agg-Max-UL-Bit-Rate: This is a 32-bit unsigned integer + that 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 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-Retention-Priority + attribute and the QoS-Traffic-Selector attribute (Section 4.2.10), + then the Allocation-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-Retention-Priority + attribute does not include the QoS-Traffic-Selector attribute + (Section 4.2.10), then the Allocation-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 | PL |PC |PV | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + o Type: 5 + + o Length: The length of the attribute in octets, excluding the Type + and Length fields. This value is set to (2). + + 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 (PL): This is a 4-bit unsigned integer value. 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 limitations. The priority level can also be used to + + + +Liebsch, et al. Standards Track [Page 22] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + decide which existing mobility session to preempt 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 (PC): This is a 2-bit unsigned integer + value. It 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. The values + (2) and (3) are reserved. + + o Preemption-Vulnerability (PV): This is a 2-bit unsigned integer + value. It defines whether a service data flow can lose the + resources assigned to it in order to admit a service data flow + with a higher priority level. The following values are defined: + + Enabled (0): This value indicates that the resources assigned + to the IP data flow can be preempted 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 preempted and allocated to a + service data flow with a higher priority level. The values (2) + and (3) are reserved. + +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. + + + + + +Liebsch, et al. Standards Track [Page 23] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + 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 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 identify 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: This is a 32-bit unsigned integer that + 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. + + + + + +Liebsch, et al. Standards Track [Page 24] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + +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. + + 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 identify 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. + + + + +Liebsch, et al. Standards Track [Page 25] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + o Aggregate-Max-UL-Bit-Rate: This is a 32-bit unsigned integer that + 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. + +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 an 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 identify 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 + + + + +Liebsch, et al. Standards Track [Page 26] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + 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-DL-Bit-Rate: This is a 32-bit unsigned integer that + 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 an 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 identify 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. + + + + + + + + +Liebsch, et al. Standards Track [Page 27] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + 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 + + 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: This is a 32-bit unsigned integer that + 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 + identify those target flows. Furthermore, the DSCP marking in the + QoS option is to be applied only to a partial set of the mobile + node's IP flows, and the traffic selectors present in the QoS- + Traffic-Selector attribute identify those target flows. + + + + + + + + + + +Liebsch, et al. Standards Track [Page 28] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + 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. + + o TS Format: An 8-bit unsigned integer indicating the Traffic + Selector Format. The values are allocated from the "Traffic + Selector Format" namespace for the traffic selector sub-option + defined in [RFC6089]; those defined in [RFC6089] are repeated here + for clarity. Value (0) is reserved and MUST NOT be used. When + the value of the 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 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 are 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. + + + + + + + + + + +Liebsch, et al. Standards Track [Page 29] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + 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 namespace for this sub- + type is managed by the vendor identified by the Vendor ID field. + +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): + 179 + +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): 5 + + + + + + + + + + +Liebsch, et al. Standards Track [Page 30] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + +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): + 130 + +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 + each entry must include the Service Request Identifier, DSCP + value, and the attributes defined in Section 4.2. + + LMA Receiving a QoS Service Request: + + o On receiving a Proxy Binding Update message with an instance of + the Quality-of-Service option included in the message and the + Operational Code field of the Quality-of-Service option set to + QUERY, then the local mobility anchor includes all the Quality-of- + Service option(s) reflecting the currently negotiated QoS Service + Requests for that mobility session in the response message. The + Operational Code field in each of the Quality-of-Service + option(s), which is included in the response message, is set to + RESPONSE. + + o On receiving a Proxy Binding Update message with one or more + instances of the Quality-of-Service option included in the message + and the Operational Code field set to ALLOCATE, the local mobility + anchor processes the option(s) and determines 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 other considerations. + + o If the local mobility anchor can support the proposed QoS Service + Requests in entirety, then it sends a Proxy Binding + Acknowledgement message with a status code value of (0). + + * The message includes all the Quality-of-Service option + instances copied (including all the option content) from the + received Proxy Binding Update message. The local mobility + + + +Liebsch, et al. Standards Track [Page 31] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + anchor assigns a Service Request Identifier to each Service + Request and sets the SR-ID field of each included Quality-of- + Service option accordingly. + + * The Operational Code field in each of the Quality-of-Service + option(s) is set to RESPONSE. + + * The local mobility anchor should 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, it rejects the request and sends + a Proxy Binding Acknowledgement message with the status code value + set to CANNOT_MEET_QOS_SERVICE_REQUEST (Cannot meet QoS Service + Request). + + * Since the local mobility anchor cannot support the requested + QoS services for that mobile node, the Proxy Binding + Acknowledgement message will not include any Quality-of-Service + options. This serves as an indication to the mobile access + gateway that QoS services are not supported for that mobile + node. + + * The denial of a QoS Service Request MUST NOT result in removal + of the mobility session for that mobile node. + + o If the local mobility anchor can support QoS services for the + mobile node, but only with lower quality values than indicated in + the QoS attributes of a received QoS option or only for some of + the received QoS Service Requests, the local mobility anchor + includes the QoS option for the supported QoS Service Requests in + the Proxy Binding Acknowledgement message with an updated set of + QoS attributes. + + * If the local mobility anchor cannot support some of the + received QoS Service Requests for that mobile node, then the + Quality-of-Service option for these QoS Service Requests is not + included in the Proxy Binding Acknowledgement message. This + serves as an indication to the mobile access gateway that a + particular QoS Service Request is not supported for that mobile + node. This includes the case where the attributes in a QoS + option have conflicting requirements, for example, Per-Session- + Agg-Max-UL-Bit-Rate is lower than Guaranteed-UL-Bit-Rate. + + * The local mobility anchor includes only QoS options in the + Proxy Binding Acknowledgement message for supported QoS + attributes. The contents of each option (including the QoS + + + +Liebsch, et al. Standards Track [Page 32] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + attributes) reflect the QoS service parameters that the local + mobility anchor can support for that mobile node. The local + mobility anchor sets the values of each supported QoS attribute + according to the level of QoS it can support for the mobile + node. The Service Request Identifier in each of the included + QoS options is set to a value of (0). The Operational Code + field in each of the included Quality-of-Service option(s) is + 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 a mobile node by sending an Update Notification + message [RFC7077]. The Notification Reason in the Update + Notification message is set to a value of QOS_SERVICE_REQUEST, and + the Acknowledgement Requested (A) flag is set to a value of (1). + + * New QoS Service Request: + + + The message includes one or more instances of the Quality- + of-Service option. Each instance of the option will include + one or more QoS attributes. + + + The Operational Code field in the Quality-of-Service option + is set to ALLOCATE. + + + The Service Request Identifier is set to the allocated + value. + + + The DSCP field in the Traffic Class (TC) field is set to the + requested DSCP value. + + * Modification of an existing QoS Service Request: + + + The message includes one or more instances of the 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 + is set to MODIFY. + + + The Service Request Identifier is set to a value that was + allocated for that QoS Service Request. + + + + + +Liebsch, et al. Standards Track [Page 33] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + + The DSCP field in the Traffic Class (TC) field is set to the + requested DSCP value. + + * Deletion of an existing QoS Service Request: + + + The message includes the Quality-of-Service option(s) with + the relevant QoS attributes. + + + The Operational Code field in the Quality-of-Service option + is set to DE-ALLOCATE. + + + The Service Request Identifier is set to a value that was + allocated for that QoS Service Request. + + + The DSCP field in the Traffic Class (TC) field is set to the + DSCP value associated with that request. + + * Query for the previously negotiated QoS Service Requests: + + + The message includes a single instance of the Quality-of- + Service option without including any QoS attributes. + + + The Operational Code field in the Quality-of-Service option + is set to QUERY. + + + The Service Request Identifier is set to a value of (0). + + + The DSCP field in the Traffic Class (TC) field is set to a + value of (0). + + o Handling a Response to the QoS Service Request: + + * If the received Update Notification Acknowledgement [RFC7077] + message has the Status Code field set to a value (0), the local + mobility anchor should 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 has + the Status Code field set to a value + CANNOT_MEET_QOS_SERVICE_REQUEST, the local mobility anchor + applies the following considerations: + + + The denial of a QoS Service Request results in removal of + any QoS state associated with that request. + + + + + + +Liebsch, et al. Standards Track [Page 34] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + + 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 Update Notification message with the updated Quality- + of-Service option(s). + + 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 are 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 includes 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 a handover to a new + mobile access gateway that is unaware of the previously negotiated + QoS services. + +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 each entry must include the Service Request + Identifier, DSCP value and the attributes defined in Section 4.2. + + MAG Receiving a QoS Service Request: + + o On receiving an Update Notification message with one or more + instances of the Quality-of-Service option included in the + message, the mobile access gateway processes the option(s) and + determines 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 + + + +Liebsch, et al. Standards Track [Page 35] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + determination to accept the request(s) can be based on policy + configured on the mobile access gateway, available network + resources, or other considerations. + + o If the mobile access gateway can support the proposed QoS Service + Requests in entirety, then it sends an Update Notification + Acknowledgement message with a status code value of (0). + + * The message includes 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 includes 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) is set to RESPONSE. + + * The mobile access gateway should 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 rejects the request and + sends 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. + + * 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 the Quality-of-Service option is not + 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 + the mobile node, but only with lower quality values than + indicated in the QoS attributes of a received QoS option, + the mobile access gateway includes the QoS option in the + Update Notification Acknowledgement message with an updated + set of QoS attributes. The mobile access gateway sets the + + + +Liebsch, et al. Standards Track [Page 36] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + values of each QoS attribute according to the level of QoS + it can support for the mobile node. The mobile access + gateway includes only QoS options in the Update Notification + Acknowledgement message for supported QoS attributes. If + the mobile access gateway receives one or multiple QoS + options, whose QoS attributes are not supported, it omits + these QoS options in the Update Notification Acknowledgement + message. This includes the case where the attributes in a + QoS option have conflicting requirements, for example, Per- + Session-Agg-Max-UL-Bit-Rate is lower than Guaranteed-UL-Bit- + Rate. The contents of each option (including the QoS + attributes) 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) is 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 includes one or more instances of the Quality- + of-Service option. Each instance of the option will include + one or more QoS attributes. + + + The Operational Code field in each of the Quality-of-Service + option is set to ALLOCATE. + + + The Service Request Identifier is set to a value of (0). + + + The DSCP value in the Traffic Class field reflects the + requested DSCP value. + + * Modification of an existing QoS Service Request: + + + The message includes one or more instances of the 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 + is set to MODIFY. + + + +Liebsch, et al. Standards Track [Page 37] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + + The Service Request Identifier is set to a value that was + allocated for that QoS Service Request. + + + The DSCP field in the Traffic Class (TC) field is set to the + requested DSCP value. + + * Deletion of an existing QoS Service Request: + + + The message includes the Quality-of-Service option(s) with + the relevant QoS attributes. + + + The Operational Code field in the Quality-of-Service option + is set to DE-ALLOCATE. + + + The Service Request Identifier is set to a value that was + allocated for that QoS Service Request. + + + The DSCP field in the Traffic Class (TC) field is set to the + DSCP value associated with that request. + + * Query for the previously negotiated QoS Service Requests: + + + The message includes a single instance of the Quality-of- + Service option without including any QoS attributes. + + + The Operational Code field in the Quality-of-Service option + is set to QUERY. + + + The Service Request Identifier is set to a value of (0). + + + The DSCP field in the Traffic Class (TC) field is set to a + value of (0). + + 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 should enforce the Quality-of-Service rules for the + 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 + applies the following considerations. + + + The denial of a QoS Service Request results in removal of + any QoS state associated with that request. + + + +Liebsch, et al. Standards Track [Page 38] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + + 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. If so, the message includes an instance of a + Quality-of-Service option for each of those Service + Requests. Furthermore, the DSCP value is 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 are released. + +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 that 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 [TS23.207] + [TS29.212] is provided by Differentiated Services techniques in the + IP transport network. The QoS classification used in the IP + transport network is further translated to WLAN QoS-specific + techniques in the WLAN access using appropriate WLAN QoS + specifications [IEEE802.11aa-2012] [WMM1.2.0]. The details 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 + + + + +Liebsch, et al. Standards Track [Page 39] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + 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. + + 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 a 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 + + + + + +Liebsch, et al. Standards Track [Page 40] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + function (e.g., the WLC) must provide some protocol for QoS inter- + working. Details of such inter-working are out of the scope of this + specification. + +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 terms of QoS characteristics (e.g., conversational + voice, streaming video, signaling, and best effort); more details on + DSCP and QCI mapping are given in 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, AF21, AF31, AF32) + + * 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 bit rate=MBR. + + + + + + +Liebsch, et al. Standards Track [Page 41] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + o Dedicated, non-GBR bearer (QCI=5-9) + + * DSCP=(BE, AF11, AF21, AF31, AF32) + + * Per-MN AMBR-UL/DL + + * 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 in Appendix A. + + For some optional QoS attributes, the signaling can differentiate + enforcement per mobility session and per IP flow. For the latter, as + long as the AMBR constraints are met, the rule associated with the + identified flow(s) overrules the aggregated rules that 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 are left as considerations for + actual deployment. + +7. IANA Considerations + + IANA has completed the following 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 58 for this mobility + option has been allocated from the "Mobility Options" registry at + <http://www.iana.org/assignments/mobility-parameters>. + + o Action-2: This specification defines a new mobility attribute + format, the Quality-of-Service attribute. The format of this + attribute is described in Section 4.2. This attribute can be + carried in the Quality-of-Service mobility option. The type + values for this attribute are managed by IANA in a new registry, + the "Quality-of-Service Attribute Registry". This registry is + maintained under the "Mobile IPv6 parameters" registry at + <http://www.iana.org/assignments/mobility-parameters>. This + specification reserves the type values listed below. All other + + + +Liebsch, et al. Standards Track [Page 42] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + values (12 - 254) are unassigned and may be assigned by IANA using + the Specification Required policy [RFC5226]. The Designated + Expert reviewing the value assignment is expected to verify that + the protocol extension follows the Proxy Mobile IPv6 architecture + and does not raise backward-compatibility issues with existing + deployments. + + +=====+=================================+=================+ + |Value| Description | Reference | + +=====+=================================+=================+ + | 0 | Reserved | RFC 7222 | + +=====+===================================================+ + | 1 | Per-MN-Agg-Max-DL-Bit-Rate | RFC 7222 | + +=====+===================================================+ + | 2 | Per-MN-Agg-Max-UL-Bit-Rate | RFC 7222 | + +=====+===================================================+ + | 3 | Per-Session-Agg-Max-DL-Bit-Rate | RFC 7222 | + +=====+===================================================+ + | 4 | Per-Session-Agg-Max-UL-Bit-Rate | RFC 7222 | + +=====+===================================================+ + | 5 | Allocation-Retention-Priority | RFC 7222 | + +=====+===================================================+ + | 6 | Aggregate-Max-DL-Bit-Rate | RFC 7222 | + +=====+===================================================+ + | 7 | Aggregate-Max-UL-Bit-Rate | RFC 7222 | + +=====+===================================================+ + | 8 | Guaranteed-DL-Bit-Rate | RFC 7222 | + +=====+===================================================+ + | 9 | Guaranteed-UL-Bit-Rate | RFC 7222 | + +=====+===================================================+ + | 10 | QoS-Traffic-Selector | RFC 7222 | + +=====+===================================================+ + | 11 | QoS-Vendor-Specific-Attribute | RFC 7222 | + +=====+===================================================+ + | 255 | Reserved | RFC 7222 | + +=====+===================================================+ + + o Action-3: This document defines a new status code, + CANNOT_MEET_QOS_SERVICE_REQUEST (179), for use in Proxy Binding + Acknowledgement messages, as described in Section 4.3. This value + has been assigned from the "Status Codes" registry at + <http://www.iana.org/assignments/mobility-parameters>. + + o Action-4: This document defines a new Notification Reason, + QOS_SERVICE_REQUEST (5), for use in Update Notification messages + [RFC7077] as described in Section 4.4. This value has been + assigned from the "Update Notification Reasons Registry" at + <http://www.iana.org/assignments/mobility-parameters>. + + + +Liebsch, et al. Standards Track [Page 43] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + o Action-5: This document defines a new status code, + CANNOT_MEET_QOS_SERVICE_REQUEST (130), for use in Update + Notification Acknowledgement messages [RFC7077] as described in + Section 4.5. This value has been assigned from the "Update + Notification Acknowledgement Status Registry" at + <http://www.iana.org/assignments/mobility-parameters>. + +8. 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 messages like any other mobility header + option. [RFC5213] and [RFC7077] identify the security considerations + for these signaling messages. When included in these signaling + messages, the Quality-of-Service option does not require additional + security considerations. + +9. Acknowledgements + + The authors of this document thank the members of 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 J. Bernardos Cano, Michal + Hoeft, Ryuji Wakikawa, Liu Dapeng, Seil Jeon, and Georgios + Karagiannis. + + The authors would like to thank all the IESG reviewers, especially, + Ben Campbell, Barry Leiba, Jari Arkko, Alissa Cooper, Stephen + Farrell, Ted Lemon, and Alia Atlas for their valuable comments and + suggestions to improve this specification. + + Finally, the authors would like to express sincere and profound + appreciation to our Internet Area Director, Brian Haberman, for his + guidance and great support in allowing us to complete this work. + +10. References + +10.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. + + + + +Liebsch, et al. Standards Track [Page 44] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 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. + +10.2. Informative References + + [GSMA.IR.34] + GSMA, "Guidelines for IPX Provider networks (Previously + Inter-Service Provider IP Backbone Guidelines)", Official + Document PRD IR.34, May 2013. + + [IEEE802.11-2012] + IEEE, "Part 11: Wireless LAN Medium Access Control (MAC) + and Physical Layer (PHY) Specifications", 2012. + + [IEEE802.11aa-2012] + IEEE, "Part 11: Wireless LAN Medium Access Control (MAC) + and Physical Layer (PHY) Specifications, Amendment 2: MAC + Enhancements for Robust Audio Video Streaming", 2012. + + [IEEE802.11e-2005] + IEEE, "Part 11: Wireless LAN Medium Access Control (MAC) + and Physical Layer (PHY) Specifications, Amendment 8: + Medium Access Control (MAC) Quality of Service (QoS) + Enhancements", 2005. + + [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. + + [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC + 2983, October 2000. + + + +Liebsch, et al. Standards Track [Page 45] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + [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. + + [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., + and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and + Network Mobility (NEMO) Basic Support", RFC 6089, January + 2011. + + [SMI] IANA, "PRIVATE ENTERPRISE NUMBERS", SMI Network Management + Private Enterprise Codes, April 2014, + <http://www.iana.org/assignments/enterprise-numbers>. + + [TS22.115] 3GPP, "Technical Specification Group Services and System + Aspects; Service aspects; Charging and billing", 3GPP TS + 22.115, 2010. + + [TS23.203] 3GPP, "Technical Specification Group Services and System + Aspects; Policy and charging control architecture", 3GPP + TS 23.203, 2013. + + [TS23.207] 3GPP, "End-to-End Quality of Service (QoS) Concept and + Architecture, Release 10", 3GPP TS 23.207, 2011. + + [TS23.402] 3GPP, "Technical Specification Group Services and System + Aspects; Architecture enhancements for non-3GPP accesses", + 3GPP TS 23.402, 2012. + + [TS29.212] 3GPP, "Policy and Charging Control over Gx/Sd Reference + Point, Release 11", 3GPP TS 29.212, 2011. + + [WMM1.2.0] Wi-Fi Alliance, "Wi-Fi Multimedia Technical Specification + (with WMM-Power Save and WMM-Admission Control)", Version + 1.2.0. + + + + + + + + + + + + + + +Liebsch, et al. Standards Track [Page 46] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + +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. Standards Track [Page 47] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + +=======+===============================+=============+ + |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 + + The following 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 + (Appendices A.2.1 and A.2.2) and to modification (Appendix A.2.3). + +A.2.1. Handover of Existing QoS Rules + + In Figure 9, the MN is first connected to the LTE network with 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 the QoS is also 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 + access to the MAG via the PMIPv6 signaling with the QoS option + + + + +Liebsch, et al. Standards Track [Page 48] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + (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 a handover from 3GPP + access to WLAN access. + + + + + + + + + + + + + + + + + + + + + + + + + +Liebsch, et al. Standards Track [Page 49] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + +--+ +--+ +---+ +---+ + |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 + communicate with Policy Control Function (using procedures outside + + + +Liebsch, et al. Standards Track [Page 50] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + 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 (Wi-Fi + Multimedia - API). The MN may request that traffic resources be + reserved using L2 signaling, e.g., sending an Add Traffic System + (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 coordination 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. Standards Track [Page 51] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + +--+ +--+ +---+ +---+ + |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 the local mobility + anchor classifies the new flow (notified with PBA) or the 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., IP Multimedia Subsystems + (IMS) application, gets launched on the mobile node that requires + certain QoS support. + + + + + + +Liebsch, et al. Standards Track [Page 52] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + The application on the mobile node initiates the communications via a + dedicated network function (e.g., IMS Call Session Control Function). + Once the communication is established, the application network + function notifies the 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. On receiving the Update Notification message, + the MAG 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 function + again notifies the PCF function to remove the established QoS + parameters. The PCF notifies the LMA to withdraw 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". On receiving this Update Notification + Acknowledgement message, the MAG 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. + +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 (ACs): + + 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. + + + +Liebsch, et al. Standards Track [Page 53] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + 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 DSCP. To allow consistent QoS management on + both wireless and wired interfaces, the access point relies on the + 802.11e specification, which defines mapping between the 802.11e + access categories and the IEEE 802.1D priority (802.1p tag). The + end-to-end QoS architecture is depicted in Figure 13, and the 802.11e + /802.1D priority mapping is shown 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 | + +-----------+------------------+ + + + +=============+ +-----+ + 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. + + + + +Liebsch, et al. Standards Track [Page 54] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + 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 operators; a mapping example is 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 + based on the 802.1p tag or the DSCP value. If the 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 the MN attachment process, the MAG fetches QoS + policies from the LMA. After this step, both the MAG and LMA are + provisioned with QoS policies. + + + + + + +Liebsch, et al. Standards Track [Page 55] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + + (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; it then 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 are 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. + + +--+ +--+ +---+ +---+ + |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. Standards Track [Page 56] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + +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. Standards Track [Page 57] + +RFC 7222 QoS Support for Proxy Mobile IPv6 May 2014 + + +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. Standards Track [Page 58] + |