RFC 7222
Quality-of-Service Option for Proxy Mobile IPv6
Quality-of-Service Option for Proxy Mobile IPv6 🎀
The title block, bestie: this is RFC 7222, published in May 2014 as a Standards Track document, which means it's an official Internet standard 💅. It came from the IETF (the Internet Engineering Task Force) and its ISSN is 2070-1721 🌸. The authors are M. Liebsch (NEC), P. Seite (Orange), H. Yokota (KDDI Lab), J. Korhonen (Broadcom Communications), and S. Gundavelli (Cisco) 🫶. The header doesn't list any RFCs this one obsoletes or updates, so it's standing on its own 🧚.
Abstract
okay so this spec adds a brand new mobility option called the Quality-of-Service (QoS) option to Proxy Mobile IPv6 ✨. The local mobility anchor and the mobile access gateway use it to negotiate QoS parameters for a mobile node's IP flows 🦋. Those negotiated parameters can then be used for QoS policing and marking of packets, so QoS differentiation gets enforced on the path between the local mobility anchor and the mobile access gateway 💖.
It's also giving main character energy because once the QoS parameters are sitting on the mobile access gateway, they can be mapped onto QoS rules that are specific to the access technology. Those rules then get enforced on the access network using approaches specific to that access technology 👑.
Status of This Memo
This is an Internet Standards Track document 🌈.
It comes from the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 5741 📚.
You can find the current status of this document, any errata, and how to give feedback at http://www.rfc-editor.org/info/rfc7222 🍓.
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) as they stood on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 🙈. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They also come 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
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 ......................................571. Introduction ✨
okay so mobile operators run Proxy Mobile IPv6 (PMIPv6) [RFC5213] to get network-based mobility management for mobile nodes (MNs) 📱. People can reach IP-based services from their phones over all sorts of radio access technologies 🌸. The mobile standards that exist today already handle QoS-based service differentiation for subscriber traffic on cellular radio access networks, which is honestly so iconic 💅. QoS policies are usually controlled by a policy control function, and they get enforced by gateways in the infrastructure, like the local mobility anchor (LMA) and the mobile access gateway (MAG), plus by access network elements 🧚. What's not covered in the current standards is policy control and in-band QoS differentiation for getting into the mobile operator network through alternative non-cellular access technologies 😭. IP session handovers and IP flow mobility across access technologies already exist in cellular standards [TS23.402], but QoS policy handovers across access technologies haven't gotten much attention yet 🙈.
Wireless LAN (WLAN) is basically the dominant alternative access technology that can complement cellular radio access 📶. The 802.11e extension [IEEE802.11e-2005] adds QoS extensions to WLAN, so it makes sense to apply QoS policies to WLAN access too 🦋. That lets you do QoS classification of both downlink and uplink traffic between a mobile node and its local mobility anchor 💖. To make this happen, this specification pins down three functional operations 👑:
- (a) Maintaining QoS classification during a handover between cellular radio access and WLAN access, by establishing QoS policies in the handover target access network 🎀
- (b) mapping QoS classes and their associated policies between different access systems 🌈
- (c) establishing QoS policies for new data sessions/flows that get started while using WLAN access ✨
This document extends the PMIPv6 protocol [RFC5213] so QoS policies can be set up for a mobile node's data traffic on the local mobility anchor and the mobile access gateway 💅. The QoS policies travel in-band with PMIPv6 signaling, using the QoS option defined here 🫶. They get enforced on the local mobility anchor for downlink traffic, and on the mobile access gateway and its access network for uplink traffic 🔥. The option also lets you link IP session classification characteristics, like a Differentiated Services Code Point (DSCP) [RFC2474], to the QoS class you expect for that IP session 🍓. This document defines the fundamental QoS attributes that apply per mobile node, per mobility session, or per flow 💜. These attributes aren't tied to any one access technology, but they're compatible with the Third Generation Partnership Project (3GPP) and IEEE 802.11 Wireless LAN QoS specifications [IEEE802.11-2012] 🌸.
Additional QoS attributes can be defined and used with the QoS option, for example to describe latency constraints or jitter bounds in more detail 🧚. Specifying those extra attributes, and handling QoS policies between the mobile access gateway and the access network, are both out of scope for this specification 🙈.
2. Conventions and Terminology 💖
2.1. Conventions
okay this part is the important bit, so read carefully 🤓. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🔥✨.
2.2. Terminology 💅
okay so all the mobility words in here mean exactly what they mean in the Proxy Mobile IPv6 specs [RFC5213], [RFC5844], and [RFC7077] 🧚 no reinventing the wheel bestie. this doc also uses a bunch of abbreviations, so here's the tea ☕
Aggregate Maximum Bit Rate (AMBR)
AMBR is the upper limit on the bit rate the network can provide for a set of IP flows 💸. IP packets in those flows that go over the AMBR limit may be discarded by the rate-shaping function where the AMBR parameter is enforced. Variants of the "AMBR" term can be made by restricting the target set of IP flows that the AMBR gets applied to, like a mobile node, a mobility session, or a 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 shows up in congestion situations when there aren't enough resources to meet every Service Request 😭. It's mainly used by the Admission Control function to decide whether a particular Service Request must be rejected because there's no room, or honored by preempting an existing low-priority service. it's giving triage energy 🩺
Differentiated Services Code Point (DSCP)
In the Differentiated Services Architecture [RFC2474], packets get classified and marked so they receive a particular per-hop forwarding behavior on the nodes along their path, based on the marking 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 📚 (go read them, I'll wait 🙈)
Downlink (DL) Traffic
The mobile node's IP packets that the mobile access gateway receives from the local mobility anchor are called Downlink traffic. The "Downlink" term used in the QoS attribute definition is always from the reference point of the mobile node, so it means traffic heading towards the mobile node 🌸
Guaranteed Bit Rate (GBR)
GBR is the assured bit rate the network will provide for a set of IP flows, and it's the main character of guarantees 👑. It's assumed that the network reserves the resources for supporting the GBR parameter. Variants of the "GBR" term can be made by limiting the scope of the target IP flows that the GBR applies to, like a mobile node, a mobility session, or a 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 tied to 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 defined to be enforced on one or more of a mobile node's IP flows ✨. The parameters at minimum include a DSCP marking, and they may also 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, a mobile node is offered multiple services within the same mobility service subscription 🍓. Each of those services provides 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 it 🦋
Uplink (UL) Traffic
The mobile node's IP packets that the mobile access gateway forwards to the local mobility anchor are called Uplink traffic. The "Uplink" term used in the QoS attribute definitions is based on the reference point of the mobile node, so it means traffic originating from the mobile node 🌈
3. Overview of QoS Support in Proxy Mobile IPv6 🎀
okay the QoS support in Proxy Mobile IPv6 described in this doc is built on the Differentiated Services Architecture ([RFC2474] and [RFC2475]) 💅. The access network 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 that gives 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 to be 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 there for meeting both the quantitative performance requirements (such as Guaranteed Bit Rate) and for realizing relative performance treatment through 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 which type of QoS services are to be enabled for a mobile node is based on the subscriber profile and on available network resources. The negotiated QoS parameters are used to provide 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 🙈
Here's the picture, bestie 🖼️
+=======+
| 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 SupportFigure 1 shows 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 get 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 💖 slay
3.1. Quality-of-Service Option -- Usage Examples ✨
okay so let's look at some real scenarios 🎀 first up is Use Case 1, where the local mobility anchor (LMA) is the one that kicks off a QoS Service Request toward the mobile access gateway (MAG). ✨
+-----+ +-----+ +-----+
| 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- (1) to (4): the MAG spots the mobile node (MN) attaching to the access link and starts the signaling with the LMA 🌸 once that's done, the LMA and MAG set up the mobility session and the forwarding state. tidy! 💖
- (5) to (8): the LMA is the one starting this QoS Service Request to the MAG 👑 the trigger can come from a policy function, but the details of that trigger are outside the scope of this document (not our problem today 🙈). the LMA sends an Update Notification (UPN) message [RFC7077] to the MAG, and that message carries the QoS option (Section 4.1), which has a set of QoS parameters inside. if the MAG decides it can't support what was asked for that mobile, it sends back an Update Notification Acknowledgement (UPA) message with a revised QoS option that has an updated set of QoS attributes 😭 then the LMA accepts that revised request by sending a brand new Update Notification with the updated QoS option. the negotiation is giving ping-pong energy and I'm here for it 🏓
- (9) to (11): once the QoS Service Request is successfully negotiated, the MAG and the LMA install the QoS rules for it 🔥 and on top of that, the MAG (using access-technology-specific mechanisms) installs the QoS rules on the access network. everybody's on the same page now 🫶
Use Case 2 flips the script 🦋 this time, Figure 3 shows a mobile access gateway starting the QoS Service Request toward the 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- (1) to (4): same opening moves as before, the MAG detects the MN on the access link and kicks off signaling with the LMA, and then the mobility session and forwarding state get established 🧚
- (5) to (6): this time the MAG starts the QoS Service Request aimed at the LMA 💅 the trigger can come from the MN using access-technology-specific mechanisms, and the specifics of that trigger are (again!) outside the scope of this document. the MAG sends a Proxy Binding Update (PBU) message [RFC5213] to the LMA, carrying the QoS option (Section 4.1) with a set of QoS parameters. the LMA says "yes, let's do it" by sending back a Proxy Binding Acknowledgement (PBA) message 🎀
- (7) to (9): once the QoS Service Request is successfully negotiated, the MAG and the LMA install the QoS rules for it 🌈 and the MAG, using access-technology-specific mechanisms, installs the QoS rules on the access network too. ✨ iconic.
3.2. Quality-of-Service Attributes -- Usage Examples 💜
this section is the "where would you actually use this?" part 🍓 it points out the use cases where the Quality-of-Service option (Section 4.1) and its attributes (Section 4.2), both defined in this document, are relevant.
- Subscriber AMBR limits: the subscription policy a mobile subscriber is offered means the service provider has to enforce Aggregate Maximum Bit Rate (AMBR) limits on that subscriber's IP traffic 💖 the LMA and the MAG negotiate the uplink and downlink AMBR values for the mobility session and enforce them in the access and the home network. for this, the QoS option (Section 4.1) uses the QoS attributes
Per-Session-Agg-Max-DL-Bit-Rate(Section 4.2.3) andPer-Session-Agg-Max-UL-Bit-Rate(Section 4.2.4). very organized, very slay 💅 - Community Wi-Fi: in these deployments, the residential gateway that runs the Wi-Fi service is shared between the home user and the community Wi-Fi users 🏠 so the service provider turns on Guaranteed Bit Rate (GBR) for the home user's traffic, which means the home user's Wi-Fi isn't impacted by the community service 🫶 the QoS option (Section 4.1) uses the QoS attributes
Guaranteed-DL-Bit-Rate(Section 4.2.8) andGuaranteed-UL-Bit-Rate(Section 4.2.9) for this. - VoIP calls: a mobile user on the service provider's Voice over IP (VoIP) infrastructure calls someone else on the network 📞 the negotiated call parameters need a dedicated, fixed amount of bandwidth for the media flows of that VoIP session. the application function in the VoIP infrastructure tells the LMA to enforce GBR limits on that IP flow, identified by the flow definition 😭 the QoS option (Section 4.1) uses
Guaranteed-DL-Bit-Rate(Section 4.2.8),Guaranteed-UL-Bit-Rate(Section 4.2.9), andQoS-Traffic-Selector(Section 4.2.10) for this one. - Emergency services: sometimes the network resources are completely allocated to other users and the network might be dealing with severe congestion 🚨 in those moments, the service provider may want to revoke resources that were already allocated and hand them over to emergency services. the LMA and the MAG negotiate Allocation and Retention Priority (AARP) values for the IP sessions tied to emergency applications 🙏 the QoS option (Section 4.1) uses the QoS attribute
Allocation-Retention-Priority(Section 4.2.5) for this. this is the one that matters most, bestie 🌸
4. Protocol Messaging Extensions 🧚♀️✨
4.1. Quality-of-Service Option 🎀
Okay bestie, this is the Quality-of-Service option, and it's giving main character energy ✨ Local mobility anchors and mobile access gateways use it to negotiate QoS parameters for a mobility session. It can ride along in Proxy Binding Update (PBU) [RFC5213], Proxy Binding Acknowledgement (PBA) [RFC5213], Update Notification (UPN) [RFC7077] and Update Notification Acknowledgement (UPA) [RFC7077] messages. One message can hold more than one instance of it, and each instance stands for one specific QoS Service Request 💅
The alignment requirement for this option is 4n.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | SR-ID | TC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OC | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ QoS Attribute(s) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: QoS Option- Type:
58 - Length: An 8-bit unsigned integer indicating the length of the option in octets, excluding the Type and Length fields.
- 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 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. - 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.
- Operational Code (OC): The 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. - 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.
- RESPONSE:
- Reserved: This field is unused for now. The value MUST be initialized to a value of
(0)by the sender and MUST be ignored by the receiver. - QoS Attribute(s): Zero or more 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 is all about 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, and this is where we list the QoS attributes this specification defines 🫶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Format of a Quality-of-Service Attribute- Type: An 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.
- (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.
- Length: An 8-bit unsigned integer indicating the number of octets needed to encode the Value, excluding the Type and Length fields.
- Value: The format of this field is based on the Type value.
4.2.1. Per-Mobile-Node Aggregate Maximum Downlink Bit Rate 🦋
This attribute, Per-MN-Agg-Max-DL-Bit-Rate, represents the maximum downlink bit rate for a mobile node. It's a variant of the "AMBR" term defined in Section 2.2. The value is an aggregate across all mobility sessions tied to that mobile node, so it's giving "the whole vibe, not just one lane" 💖
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type:
1 - Length: The length in octets of the attribute, excluding the Type and Length fields. This value is set to
(6). - Reserved: This field is unused for now. The value MUST be initialized by the sender to
0and MUST be ignored by the receiver. - 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 💖
Okay so this one is Per-MN-Agg-Max-UL-Bit-Rate 🦋 It's the maximum uplink bit rate for the mobile node, and it's a variant of the "AMBR" term from Section 2.2. The vibe is that it's an aggregate across ALL the mobility sessions tied to that mobile node. Main character energy ✨
It can go in the Quality-of-Service option from Section 4.1, and it's an optional attribute 🎀 Only one instance can show up in a QoS option, so no doubling up, bestie 💅
When it shows up in a Proxy Binding Update from a mobile access gateway, or in an Update Notification from the local mobility anchor, it's requesting that maximum aggregate uplink rate for the mobile node at the peer 🌸
When it's in a Proxy Binding Acknowledgement or an Update Notification Acknowledgement, the peer is basically saying "yep, I'll offer up to this max aggregate uplink rate for that mobile node" 🫶
Now the multi-session situation 😭 If a mobile node has multiple mobility sessions, whether they go through multiple mobile access gateways with sessions anchored on one local mobility anchor or spread out across several of them, then it depends on the operator's policy and the specific deployment for how the total bandwidth gets computed on each MAG-LMA pair. That's the operator's vibe, not ours 🧚
Quick one: if a QoS option includes both this attribute and the QoS-Traffic-Selector attribute (Section 4.2.10), the QoS-Traffic-Selector attribute does not apply to this one 🙈
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type: 2Length: The length in octets of the attribute, excluding the Type and Length fields. This value is set to (6).Reserved: This field is unused for now. The value MUST be initialized by the sender to 0 and MUST be ignored by the receiver. 🙏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 one is Per-Session-Agg-Max-DL-Bit-Rate, and it represents the maximum downlink bit rate for a mobility session. It's another variant of the "AMBR" term from Section 2.2 💜
It can be included in the Quality-of-Service option from Section 4.1, and it's an optional attribute. Again, only a single instance can be present in a QoS option 🎀
When it's in a Proxy Binding Update from a mobile access gateway, or in an Update Notification from the local mobility anchor, it's the maximum aggregate downlink rate being requested for that mobility session 🌸
When it's in a Proxy Binding Acknowledgement or an Update Notification Acknowledgement, it's the max aggregate downlink rate the peer agrees to offer for that mobility session 🫶
And again, if a QoS option has both this attribute and the QoS-Traffic-Selector attribute (Section 4.2.10), the QoS-Traffic-Selector attribute does not apply to this one 🙈
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type: 3Length: The length of the attribute in octets, excluding the Type and Length fields. This value is set to (6).- Service (S) flag: This flag extends the scope of the target flows for
Per-Session-Agg-Max-DL-Bit-Rateto the mobile node's other mobility sessions that share the same Service Identifier. A 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-Rateis 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.
- When the (S) flag is set to a value of (1), then the
- 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-Rateis 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-Rateis 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-Rateis 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-DL-Bit-Rateis 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
Reserved: This field is unused for now. The value MUST be initialized by the sender to 0 and MUST be ignored by the receiver. 🙏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 forPer-Session-Agg-Max-DL-Bit-Rateare bits per second.
4.2.4. Per-Mobility-Session Aggregate Maximum Uplink Bit Rate 💅
Last one for this part! This is Per-Session-Agg-Max-UL-Bit-Rate, which is the maximum uplink bit rate for the mobility session, and yep, it's a variant of the "AMBR" term from Section 2.2 🦋
It can go in the Quality-of-Service option from Section 4.1, it's optional, and only one instance can be present in a QoS option 🎀
When it's in a Proxy Binding Update from a mobile access gateway, or in an Update Notification [RFC7077] from the local mobility anchor, it's the max aggregate uplink rate being requested for that mobility session 🌸
When it's in a Proxy Binding Acknowledgement or an Update Notification Acknowledgement [RFC7077], the peer is telling you the max aggregate uplink rate it agrees to offer for that mobility session 🫶
If a QoS option includes both this attribute and the QoS-Traffic-Selector attribute (Section 4.2.10), the QoS-Traffic-Selector attribute does not apply to this one 🙈
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type: 4Length: The length of the attribute in octets, excluding the Type and Length fields. This value is set to (6).- Service (S) flag: This flag extends the scope of the target flows for
Per-Session-Agg-Max-UL-Bit-Rateto the mobile node's other mobility sessions that share the same Service Identifier. A 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-Rateis 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.
- When the (S) flag is set to a value of (1), then the
- 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-Rateis 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-Rateis 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-Rateis 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-Rateis 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
Reserved: This field is unused for now. The value MUST be initialized by the sender to 0 and MUST be ignored by the receiver. 🙏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 forPer-Session-Agg-Max-UL-Bit-Rateare bits per second.
4.2.5. Allocation and Retention Priority ✨
okay so this one is Allocation-Retention-Priority 💖 It tells the network how much priority a mobility session (or a set of IP flows) gets when it comes to allocating resources and holding onto them. The term is defined in Section 2.2 🫶
This attribute can go inside the Quality-of-Service option from Section 4.1, and it's optional 🎀 There can only be a single instance of it in a QoS option, periodt 💅
When the QoS option has both the Allocation-Retention-Priority attribute and the QoS-Traffic-Selector attribute (Section 4.2.10), the Allocation-Retention-Priority attribute gets applied at a flow level. The traffic selector in the QoS-Traffic-Selector attribute is what picks out the target flows 🎯
When the QoS option with the Allocation-Retention-Priority attribute does not include the QoS-Traffic-Selector attribute (Section 4.2.10), the Allocation-Retention-Priority attribute gets applied to all the IP flows tied to 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type:
5🏷️ - Length: the length of the attribute in octets, not counting the Type and Length fields. This is set to
(2). - Reserved: this field is unused for now 🫠 The value MUST be initialized by the sender to
0, and MUST be ignored by the receiver. - Priority-Level (PL): a 4-bit unsigned integer 🔥 It's 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 when resources are limited. The priority level can also decide which existing mobility session gets preempted during resource limitations. It 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, so they're applicable when a mobile node is roaming 🧳
- Preemption-Capability (PC): a 2-bit unsigned integer 🦋 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): 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): 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.
- Preemption-Vulnerability (PV): a 2-bit unsigned integer 🫣 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): 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): 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 is Aggregate-Max-DL-Bit-Rate and it's the maximum downlink bit rate for the mobility session 📥 It's a variant of the "AMBR" term from Section 2.2 💅
This attribute can go inside the Quality-of-Service option from Section 4.1, and it's optional 🎀 There can only be a single instance of it in a QoS option.
When this attribute shows up in a Proxy Binding Update sent by a mobile access gateway, or in an Update Notification message sent by the local mobility anchor, it's saying "this is the maximum aggregate bit rate for downlink IP flows that I'm requesting" 🙋♀️
When it shows up in a Proxy Binding Acknowledgement message or in an Update Notification Acknowledgement message, it's 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), the Aggregate-Max-DL-Bit-Rate attribute is enforced at a flow level. The traffic selectors in the QoS-Traffic-Selector attribute identify those target flows 🎯
When the QoS option with the Aggregate-Max-DL-Bit-Rate attribute does not include the QoS-Traffic-Selector attribute (Section 4.2.10), the Aggregate-Max-DL-Bit-Rate attribute is 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type:
6🏷️ - Length: the length of the attribute in octets, not counting the Type and Length fields. This is set to
(6). - Reserved: this field is unused for now. The value MUST be initialized by the sender to
0, and MUST be ignored by the receiver. - Aggregate-Max-DL-Bit-Rate: a 32-bit unsigned integer 💯 It's the aggregate maximum downlink bit rate that's requested or allocated for downlink IP flows. The units are bits per second ⚡
4.2.7. Aggregate Maximum Uplink Bit Rate 🌷
This attribute is Aggregate-Max-UL-Bit-Rate and it's the maximum uplink bit rate for the mobility session 📤 It's a variant of the "AMBR" term from Section 2.2 🦋
This attribute can go inside the Quality-of-Service option from Section 4.1, and it's optional 🎀 There can only be a single instance of it in a QoS option.
When this attribute shows up in a Proxy Binding Update sent by a mobile access gateway, or in an Update Notification message sent by the local mobility anchor, it's the maximum aggregate uplink bit rate being requested 🙋♀️
When it shows up in a Proxy Binding Acknowledgement message or in an Update Notification Acknowledgement message, it's 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), the Aggregate-Max-UL-Bit-Rate attribute is enforced at a flow level. The traffic selectors in the QoS-Traffic-Selector attribute identify those target flows 🎯
When the QoS option with the Aggregate-Max-UL-Bit-Rate attribute does not include the QoS-Traffic-Selector attribute (Section 4.2.10), the Aggregate-Max-UL-Bit-Rate attribute is 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type:
7🏷️ - Length: the length of the attribute in octets, not counting the Type and Length fields. This is set to
(6). - Reserved: this field is unused for now. The value MUST be initialized by the sender to
0, and MUST be ignored by the receiver. - Aggregate-Max-UL-Bit-Rate: a 32-bit unsigned integer 💫 It's the aggregate maximum uplink bit rate that's requested or allocated for all the IP flows tied to that mobility session. The units are bits per second ⚡
4.2.8. Guaranteed Downlink Bit Rate 🧚
This attribute is Guaranteed-DL-Bit-Rate and it represents the assured bit rate on the downlink path that gets provided for a set of IP flows tied to a mobility session 🛡️ It's a variant of the "GBR" term from Section 2.2 💖
This attribute can go inside the Quality-of-Service option from Section 4.1, and it's optional 🎀 There can only be a single instance of it in a QoS option.
When this attribute shows up in a Proxy Binding Update sent by a mobile access gateway, or in an Update Notification message sent by the local mobility anchor, it's the guaranteed downlink bit rate being requested 🙋♀️
When it shows up in a Proxy Binding Acknowledgement message or in an Update Notification Acknowledgement message, it's 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), the Guaranteed-DL-Bit-Rate attribute is enforced at a flow level. The traffic selectors in the QoS-Traffic-Selector attribute identify those target flows 🎯
When the QoS option with the Guaranteed-DL-Bit-Rate attribute does not include the QoS-Traffic-Selector attribute (Section 4.2.10), the Guaranteed-DL-Bit-Rate attribute is 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type:
8🏷️ - Length: the length of the attribute in octets, not counting the Type and Length fields. This is set to
(6). - Reserved: this field is unused for now. The value MUST be initialized by the sender to
0, and MUST be ignored by the receiver. - Guaranteed-DL-Bit-Rate: a 32-bit unsigned integer 🥰 It's the guaranteed bandwidth in bits per second for downlink IP flows. The units are bits per second ⚡
4.2.9. Guaranteed Uplink Bit Rate ✨
okay bestie, this one is Guaranteed-UL-Bit-Rate 🫶 It's the assured bit rate on the uplink path for a bunch of IP flows tied to a mobility session. It's basically a cousin of the "GBR" term from Section 2.2 💅
This attribute can go inside the Quality-of-Service option from Section 4.1, and it's optional 🌸 You can only have one instance of it in a QoS option, no doubles 🙅♀️
Who says what depends on the message:
- When it shows up in a Proxy Binding Update from a mobile access gateway, or in an Update Notification from the local mobility anchor, it's the guaranteed uplink bit rate being asked for 🙋♀️
- When it shows up in a Proxy Binding Acknowledgement or an Update Notification Acknowledgement, it's the rate the peer agrees to offer 🤝
Now the flow-targeting drama 🎀 If the QoS option has both Guaranteed-UL-Bit-Rate and the QoS-Traffic-Selector attribute (Section 4.2.10), then the rate gets enforced at a flow level, and the traffic selectors in QoS-Traffic-Selector pick out which flows it applies to 🎯
If there's no QoS-Traffic-Selector attribute (Section 4.2.10) in that option, then Guaranteed-UL-Bit-Rate applies to all the IP flows tied to the mobility session 🌈
Here's the layout 🦋
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type: 9 🍓Length: the attribute length in octets, not counting the Type and Length fields. It's always set to (6) ✨Reserved: unused for now 💤 The sender MUST set it to 0, and the receiver MUST ignore it 🫶Guaranteed-UL-Bit-Rate: a 32-bit unsigned integer with the guaranteed bandwidth in bits per second for uplink IP flows 💖 The units are bits per second, always 🧚
4.2.10. QoS Traffic Selector 💜
This attribute, QoS-Traffic-Selector, holds the parameters used to match packets for a set of IP flows 🎯 It's the thing that decides which flows the other attributes hit 💅
It can go inside the Quality-of-Service option from Section 4.1 and it's optional 🌸
Now the main event 🔥 If a QoS option has QoS-Traffic-Selector and also includes any of 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), or Guaranteed-UL-Bit-Rate (Section 4.2.9), then those attributes get enforced at a flow level, with the traffic selectors picking the target flows 🎀 On top of that, the DSCP marking in the QoS option only applies to a partial set of the mobile node's IP flows, again chosen by the traffic selectors 🦋
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 ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type: 10 🧚Length: the attribute length in octets, not counting Type and Length 📏Reserved: unused for now 💤 The sender MUST set it to 0, and the receiver MUST ignore it 🫶TS Format: an 8-bit unsigned integer that says which Traffic Selector Format you're using 🔥 The values come from the "Traffic Selector Format" namespace for the traffic selector sub-option defined in [RFC6089], and the ones from [RFC6089] are copied here just so it's clearer 💅 Value (0) is reserved, so you MUST NOT use it 🙅♀️ IfTS Formatis (1), the format that follows is the IPv4 Binary Traffic Selector from Section 3.1 of [RFC6088]. If it's (2), it's the IPv6 Binary Traffic Selector from Section 3.2 of [RFC6088] 🌈Traffic Selector: a variable-length field holding the traffic specification that theTS Formatfield identifies 🎯
4.2.11. QoS Vendor-Specific Attribute 🌸
This attribute carries vendor-specific QoS attributes 🧚 How it's interpreted and handled is up to each vendor's implementation, so it's their call 💅
It can go inside the Quality-of-Service option from Section 4.1, and it's optional 🌸 Unlike most of the others, you can have multiple instances of this one in a single QoS option, as long as they have different sub-type values 🙌
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 | ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type: 11 🍓Length: the attribute length in octets, not counting Type and Length 📏Reserved: unused for now 💤 The sender MUST set it to 0, and the receiver MUST ignore it 🫶Vendor ID: the SMI (Structure of Management Information) Network Management Private Enterprise Code from the IANA-maintained "Private Enterprise Numbers" registry [SMI] 🏷️Sub-Type: an 8-bit field saying what kind of vendor-specific info is inside the option 🔮 The namespace for it is managed by whichever vendor is identified in theVendor IDfield 💖
4.3. New Status Code for Proxy Binding Acknowledgement 🎀
This document defines a brand-new status code for the 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 a new Notification Reason value for the Update Notification message 💌
QOS_SERVICE_REQUEST (QoS Service Requested): 5 ✨
4.5. New Status Code for Update Notification Acknowledgement Message 💜
This document also defines a new status code for the Update Notification Acknowledgement message 🌸
CANNOT_MEET_QOS_SERVICE_REQUEST (Cannot meet QoS Service Request): 130 💅
5. Protocol Considerations 🌈
5.1. Local Mobility Anchor Considerations 🦋
okay so the Binding Cache entry the local mobility anchor keeps (see Section 5.1 of [RFC5213]) can be extended to hold a list of negotiated Quality-of-Service requests it has to enforce 💅. there can be multiple entries, and each entry must include the Service Request Identifier, the DSCP value, and the attributes from Section 4.2 🎀
LMA Receiving a QoS Service Request:
- when the LMA gets a Proxy Binding Update with a Quality-of-Service option whose
Operational Codefield isQUERY, it puts all the Quality-of-Service options for the currently negotiated QoS Service Requests of that mobility session into the response. everyOperational Codefield in those response options is set toRESPONSE✨ - when the LMA gets a Proxy Binding Update with one or more Quality-of-Service options whose
Operational Codefield is set toALLOCATE, it processes them and figures out whether each proposed QoS Service Request can be met. each option instance represents one specific QoS Service Request. the call to accept can be based on policy configured on the LMA, available network resources, or other considerations 🤔 - if the LMA can support the proposed QoS Service Requests in entirety, it sends a Proxy Binding Acknowledgement with a status code value of
(0).- the message includes all the Quality-of-Service option instances copied over, including all the option content, from the Proxy Binding Update. the LMA assigns a Service Request Identifier to each Service Request and sets the
SR-IDfield of each included option to match 🍓 - the
Operational Codefield in each Quality-of-Service option is set toRESPONSE. - the LMA should enforce the Quality-of-Service rules for all the negotiated QoS Service Requests on the mobile node's uplink and downlink traffic.
- the message includes all the Quality-of-Service option instances copied over, including all the option content, from the Proxy Binding Update. the LMA assigns a Service Request Identifier to each Service Request and sets the
- if the LMA can't support any of the requested QoS Service Requests in entirety, it rejects the request and sends a Proxy Binding Acknowledgement with the status code value set to
CANNOT_MEET_QOS_SERVICE_REQUEST(Cannot meet QoS Service Request) 💀- since the LMA can't support the requested QoS services for that mobile node, the Proxy Binding Acknowledgement won't include any Quality-of-Service options. that's the signal to the mobile access gateway that QoS services aren't 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. ⚠️
- if the LMA can support QoS for the mobile node, but only with lower quality values than the QoS attributes of a received option indicate, or only for some of the received QoS Service Requests, it includes the QoS option for the supported requests in the Proxy Binding Acknowledgement with an updated set of QoS attributes 🌈
- if the LMA can't support some of the received QoS Service Requests for that mobile node, the Quality-of-Service option for those requests is left out of the Proxy Binding Acknowledgement. that's the signal to the mobile access gateway that a particular QoS Service Request isn't 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-Rateis lower thanGuaranteed-UL-Bit-Rate🙃 - the LMA only includes QoS options in the Proxy Binding Acknowledgement for supported QoS attributes. the contents of each option (including the QoS attributes) reflect the QoS service parameters the LMA can support for that mobile node. the LMA sets the value of each supported QoS attribute according to the level of QoS it can support 🎀
- the
Service Request Identifierin each included QoS option is set to a value of(0). theOperational Codefield in each included Quality-of-Service option is set toNEGOTIATE. this tells the mobile access gateway to resend the Proxy Binding Update with the revised QoS parameters 🔁
- if the LMA can't support some of the received QoS Service Requests for that mobile node, the Quality-of-Service option for those requests is left out of the Proxy Binding Acknowledgement. that's the signal to the mobile access gateway that a particular QoS Service Request isn't supported for that mobile node. this includes the case where the attributes in a QoS option have conflicting requirements, for example,
LMA Sending a QoS Service Request:
- 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 Reasonin the Update Notification message is set toQOS_SERVICE_REQUEST, and the Acknowledgement Requested (A) flag is set to(1)👑- New QoS Service Request:
- the message includes one or more instances of the Quality-of-Service option. each instance includes one or more QoS attributes.
- the
Operational Codefield in the Quality-of-Service option is set toALLOCATE. - the
Service Request Identifieris set to the allocated value. - the
DSCPfield in theTraffic 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 and the updated list of attributes.
- the
Operational Codefield in the Quality-of-Service option is set toMODIFY. - the
Service Request Identifieris set to a value that was allocated for that QoS Service Request. - the
DSCPfield in theTraffic 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 Codefield in the Quality-of-Service option is set toDE-ALLOCATE. - the
Service Request Identifieris set to a value that was allocated for that QoS Service Request. - the
DSCPfield in theTraffic 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 any QoS attributes.
- the
Operational Codefield in the Quality-of-Service option is set toQUERY. - the
Service Request Identifieris set to a value of(0). - the
DSCPfield in theTraffic Class (TC)field is set to a value of(0).
- New QoS Service Request:
Handling a Response to the QoS Service Request:
- if the received Update Notification Acknowledgement [RFC7077] message has the
Status Codefield set to a value of(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 Codefield set toCANNOT_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.
- if the message didn't include any Quality-of-Service option(s), it's an indication from the mobile access gateway that QoS services aren't enabled for the mobile node.
- if the
Operational Codefield in the Quality-of-Service option is set toNEGOTIATEand the message includes one or more instances of the Quality-of-Service option, but the option contents reflect a downgraded or revised set of QoS parameters, then the local mobility anchor MAY choose to agree to the proposed QoS Service Request by resending a new Update Notification message with the updated Quality-of-Service option(s) 🌸
General Considerations:
- 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 🧚
- 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, 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 hands over to a new mobile access gateway that is unaware of the previously negotiated QoS services 🦋
5.2. Mobile Access Gateway Considerations 🦋
- okay so the conceptual Binding Update List entry data structure the mobile access gateway keeps (the one from Section 6.1 of [RFC5213]) can be extended to store a list of negotiated Quality-of-Service requests that need enforcing 💅 There can be multiple 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 ✨
- when the mobile access gateway gets an Update Notification message with one or more instances of the Quality-of-Service option in it, it processes those options and figures out whether it can actually meet each proposed QoS Service Request 🔥 Each instance of the option stands for one specific QoS Service Request. The call to accept the request(s) can be based on policy configured on the mobile access gateway, the network resources that are available, or other considerations 🧚
- if the mobile access gateway can support every proposed QoS Service Request in its entirety, it sends back an Update Notification Acknowledgement message with a status code value of
(0)👑- the message copies all the Quality-of-Service option instances from the received Update Notification message, including all of the option content. The exception is when the Operational Code field in the request is
QUERY. In that case, the message includes all the Quality-of-Service option(s) that reflect the QoS Service Requests currently negotiated 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 🌈
- the message copies all the Quality-of-Service option instances from the received Update Notification message, including all of the option content. The exception is when the Operational Code field in the request is
- if the mobile access gateway cannot support any of the requested QoS Service Requests in their entirety, 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) 😭- a denial for a QoS Service Request MUST NOT result in removal of the mobility session for that mobile node. The mobility session stays put, bestie 🙈
- the Update Notification Acknowledgement message may include the Quality-of-Service option(s), depending on the following considerations 🍓
- if the mobile access gateway cannot support QoS services for that mobile node at all, the Quality-of-Service option is left out of the Update Notification Acknowledgement message. That absence tells 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 the QoS attributes in a received QoS option, it includes the QoS option in the Update Notification Acknowledgement message with an updated set of QoS attributes. It sets the value of each QoS attribute to the level of QoS it can actually support for the mobile node. It only includes QoS options for supported QoS attributes. If it receives one or more QoS options whose QoS attributes are not supported, it leaves those QoS options out of the Update Notification Acknowledgement message. This also covers the case where the attributes in a QoS option have conflicting requirements, for example,
Per-Session-Agg-Max-UL-Bit-Rateis lower thanGuaranteed-UL-Bit-Rate. The contents of each option (including the QoS attributes) reflect the QoS service parameters 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 toNEGOTIATE. That's the signal for the local mobility anchor to resend the Update Notification message with the revised QoS parameters ⭐
MAG Sending a QoS Service Request 🌸
- at any time, the mobile access gateway can start a QoS Service Request for a mobile node by sending a Proxy Binding Update message. It can do this 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 includes 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 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 🎀
- 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 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)🌟
- New QoS Service Request:
- 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
CANNOT_MEET_QOS_SERVICE_REQUEST, the mobile access gateway applies the following considerations 😤- a denied QoS Service Request results in removal of any QoS state associated with that request 🧹
- if the message didn't include any Quality-of-Service option(s), that's the local mobility anchor telling you QoS services aren't enabled for the mobile node 🚫
- if the Operational Code field in the Quality-of-Service option is set to
NEGOTIATE, and the message includes one or more instances of the Quality-of-Service option, but the option contents reflect a downgraded or revised set of QoS parameters, then the mobile access gateway MAY choose to agree to the 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 there are, the message includes an instance of a Quality-of-Service option for each of those Service Requests. The DSCP value is different in each of those requests too 🌈
- 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 were previously allocated, those allocated resources are released 🕊️
- if the received Proxy Binding Acknowledgement message has the Status Code field set to a value of
6. QoS Services in Integrated WLAN-3GPP Networks 🌟
6.1. Technical Scope and Procedure 🎀
okay so the QoS option in this doc can carry the same level of QoS info that 3GPP defines 💅 It's used to enforce QoS policies on IP flows that were set up while the mobile node is on WLAN access, or that got moved over from 3GPP to WLAN access 🦋 The QoS classification from the 3GPP specs [TS23.207] [TS29.212] gets handled with Differentiated Services techniques in the IP transport network ✨ Then the IP transport classification gets translated into WLAN-specific QoS techniques on the WLAN side, using the WLAN QoS specs [IEEE802.11aa-2012] [WMM1.2.0] 🌸 The full details are in Appendix A and Appendix B 📚
Figure 6 shows the big-picture architecture where the QoS option can be used 🧚 The QoS policies could come from a Policy Control Function (PCF), like the one in current cellular standards, and its whole job is to give each mobile node's individual flows an appropriate QoS class 💖 Or, if you want something more static and default, the QoS rules can just be sitting locally, like on a local mobility anchor, set up through admin config 🍓
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 AccessSo during a mobile node's handover from cellular to non-cellular access (like a WLAN radio access network), its QoS policy rules get moved over to the target mobile access gateway serving the non-cellular network 🫶 The rules were already set up on the local mobility anchor for the node's cellular traffic, so they just come along for the ride ✨ That non-cellular mobile access gateway can have an access-technology-specific controller or function built in, like a Wireless LAN Controller (WLC), which is option (I) in Figure 6 🎀 Or, the access-specific setup can be distributed, with the access-technology-specific control function sitting outside the mobile access gateway, which is option (II) 👑 In that case, the mobile access gateway and that control function (like the WLC) MUST provide some protocol for QoS inter-working 😭 The details of that inter-working are out of scope for this spec, so no spoilers here 🙈
6.2. Relevant QoS Attributes 💜
okay bestie, the QoS Option SHALL at least contain a DSCP value tied to the IP flows of a mobility session 💅 That DSCP value SHOULD correspond to the 3GPP QoS Class Index (QCI), which tells you the type of service in QoS terms (like conversational voice, streaming video, signaling, and best effort) 🌈 You can find more on the DSCP and QCI mapping in Appendix A ✨ Optional QoS info can also get added on top 🦋 Like, to match the bearer model defined in 3GPP [TS23.203], these QoS parameters get conveyed for each PMIPv6 mobility session 🎀
- 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. 🙈
- 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. 🍓
- 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 extra attributes on top, as shown in Figure 7 in Appendix A 🧚
Some optional QoS attributes let the signaling tell apart enforcement per mobility session and per IP flow 👑 For the per-flow case, as long as the AMBR constraints are met, the rule for the identified flow(s) overrules the aggregated rules that apply per mobile node or per mobility session 🌈 Extra attributes can be tacked onto the QoS option too, but how those get defined and specced is out of scope for this doc, so they're left as considerations for real-world deployment 💅✨
7. IANA Considerations 🦋
IANA has completed the following actions:
- 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. - 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 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 |
+=====+===================================================+- 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. - 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. - 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 🔥
⚠️ Security is serious business, so read this part carefully, bestie 😭
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 ✨
okay bestie, these are the must-read refs for this spec 📚 keep them close, they're the foundation 🫶
- [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.
- [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 🌸
these ones are the extra reading that gives you the bigger picture 🧚 not strictly required, but so good for context ngl
- [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.
- [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.
Appendix A. Information When Implementing 3GPP QoS in IP Transport Network 💅
this appendix is the practical stuff, like how the 3GPP QoS stuff maps onto IP transport 🎀
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.
+=======+===============================+=============+
|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 next bits are example message flows showing where the QoS option extensions kick in, as described in Section 6.1. they cover rule setup (Appendices A.2.1 and A.2.2) and 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 (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. 🌈
+--+ +--+ +---+ +---+
|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 ✨
okay so picture this bestie 🫶 a single operator has deployed BOTH a fixed access network AND a mobile access network 📶. the operator may wish for harmonized QoS management across both accesses, but the fixed network doesn't implement a QoS control framework 😭. so the operator chooses to lean on the 3GPP policy control function, which is a standard framework for QoS control, and enforce that 3GPP QoS policy on the Wi-Fi access network too 💅. the PMIP interface is what makes this QoS policy provisioning happen 🎀
here's the vibe for Figure 11 🦋 the MN first attaches to the Wi-Fi network. during attachment, the LMA (which may talk to the Policy Control Function, using procedures outside the scope of this document 🙈) hands the QoS parameters to the MAG via the QoS option (OC=ALLOCATE) in the PMIP signaling, which is the PBA. then an application on the MN may trigger a request for alternative QoS resources, e.g., through the WMM-API (Wi-Fi Multimedia - API) 🌸. the MN may ask for traffic resources to be reserved using L2 signaling, e.g., by sending an Add Traffic System (ADDTS) message [IEEE802.11-2012] ✨. that request gets relayed to the MAG, which puts the QoS parameters in the QoS option (OC=ALLOCATE) on the PMIP signaling (the PBU that's initiated when the flow is created). the LMA, working with the PCF, can then authorize enforcement of that QoS policy 👑. after that, the QoS parameters go to the MAG via the QoS option (OC=ALLOCATE, SR-ID, QoS attributes, etc.) in the PMIP signaling, and the MN gets the equivalent QoS treatment 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 ProvisioningFigure 12 is giving QoS rules bestie 🍓 it shows how the QoS rules can be conveyed and enforced between the LMA and the MN when the MN first attaches to WLAN access.
+--+ +--+ +---+ +---+
|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]=======->|--->
| | | |
| | | |
Figure 12: Adding New QoS Service Request for MN-Initiated Flowand the two little notes that go with it 🙈
- (E): the AP may enforce uplink QoS rules according to the priority class set by the MN 💜
- (F): the 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 the new flow and proposes the associated QoS class to the local mobility anchor for validation (proposed with PBU, with the validation result notified with PBA) 🔥
A.2.3. Dynamic Update to QoS Policy 🌈
okay this one is a whole glow-up arc bestie 💖 a mobile node is attached to the WLAN access and has already obtained QoS parameters from the LMA for that mobility session. then a new application, e.g., an IP Multimedia Subsystems (IMS) application, gets launched on the mobile node and needs a certain amount of QoS support 🦋
the application on the mobile node starts the communications through a dedicated network function (e.g., the IMS Call Session Control Function) 📞. once the communication is established, the application network function tells the PCF about the new IP flow. the PCF then tells the LMA which QoS parameters are needed, identifying the IP flow along with them ✨. the LMA sends an Update Notification message [RFC7077] to the MAG with the Notification Reason value set to QOS_SERVICE_REQUEST 🔥. when the MAG gets that Update Notification message, it completes the PBU/PBA signaling to get the new QoS parameters through the QoS options (OC=MODIFY, SR-ID, QoS attributes, etc.) 💅. then the MAG provisions those newly obtained QoS parameters on the access network so the newly established IP flow actually gets the network resources it asked for 👑
when the IP flow ends, the application function tells the PCF again to remove the established QoS parameters 😭. the PCF tells the LMA to withdraw the QoS resources that were set up for that voice flow. the LMA sends an Update Notification message to the MAG with the "Notification Reason" value set to "FORCE-REREGISTRATION" 💀. once the MAG receives this Update Notification Acknowledgement message, it completes the PBU/PBA signaling to remove the existing QoS rules (OC=DE-ALLOCATE, SR-ID) 🧚. then the MAG 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 ✨
Okay bestie, this section walks through a real example of end-to-end QoS 🎀 with an 802.11e-capable WLAN access link and PMIP-based QoS support. It's giving full network journey 🦋
The 802.11e spec, also known as Wi-Fi Multimedia (WMM), sorts packets into four traffic types called access categories (ACs) 💅
- Voice (AC_VO): Very high-priority queue with minimum delay. Time-sensitive data like VoIP and streaming mode gets automatically sent here 🎤
- Video (AC_VI): High-priority queue with low delay. Time-sensitive video data is automatically sent here 📹
- Best effort (AC_BE): Medium-priority queue with medium throughput and delay. Most traditional IP data goes here 🌸
- Background (AC_BK): Lowest-priority queue with high throughput. Bulk data that needs maximum throughput but isn't time-sensitive (for example, FTP data) goes here 📦
The access point uses the 802.11e indicator to prioritize traffic on the WLAN interface. On the wired side, it uses the 802.1p priority tag and DSCP 🧚 To keep QoS management consistent across wireless and wired interfaces, the access point relies on the 802.11e spec, which defines the mapping between 802.11e access categories and the IEEE 802.1D priority (the 802.1p tag). The end-to-end QoS architecture is shown in Figure 13, and the 802.11e /802.1D priority mapping is in this 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.11eWhen a packet comes in from the MN, the AP checks whether the frame has 802.11e markings in the L2 header 🔍 If it doesn't, the AP checks the DSCP field. If the uplink packet has the 802.11e marking, the access point maps the access categories to the matching 802.1D priority, using the table above. If the frame has no 802.11e marking, the access point looks at the DSCP field instead 💖
If DSCP is present, the AP maps DSCP values to an 802.1p value (i.e., 802.1D priority). This mapping is not standardized and may differ between operators, so here's a mapping example in the table below 🍓
+-------------------+--------+------------+
| 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 isn't there, the access point checks the DSCP/802.1p mapping table. The next step is mapping the 802.1p priority to the right 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 traffic to the right hardware queues 🌈
When an 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 the call flows in Appendix A apply 💜 Sometimes, though, communication starts on the WLAN access and the application doesn't mark upstream packets. If the uplink packet has no QoS marking, the AP/MAG could determine the DSCP field according to traffic selectors received from the LMA. Figure 14 shows the call flow for that use case and where QoS tag mapping comes into play. The main steps are:
- (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 📥
- (B): The MN starts a new IP communication without making IP packets with DSCP tags. The MAG uses the traffic selector to determine the DSCP value, then marks the IP packet and forwards it within the PMIP tunnel 🚀
- (C): The LMA checks the DSCP value against the traffic selector. If the QoS policies are valid, the LMA forwards the packet without renegotiating the QoS rules ✅
- (D): When a marked packet is received, 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 AccessAppendix C. Information When Implementing with a Broadband Network Gateway 🌸
This section shows an example of QoS interworking between the PMIPv6 domain and 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) connects over the broadband access network. The MN attaches to the RG via, e.g., a Wi-Fi AP in the broadband home network. In the broadband access network segment, the BNG and RG are the Policy Enforcement Point (PEP) for downlink and uplink traffic, respectively. The QoS information is downloaded from the LMA to the BNG via PMIPv6, using the QoS option defined in this document. Based on the received QoS parameters (e.g., DSCP values), the broadband access network and the RG give appropriate QoS treatment to the downlink and uplink traffic to and 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
NetworkIn the broadband access network segment, the QoS mapping between 3GPP QCI values and DSCP described in Section 6.2 is applied 💜 In the broadband home network segment, if the MN is attached to the RG via Wi-Fi, the same QoS mapping described in Appendix B can be applied ✨
Authors' Addresses 🫶
Here are the folks who brought this spec to life 💖
Marco Liebsch
NEC
Kurfuersten-Anlage 36
Heidelberg D-69115
Germany
EMail: liebsch@neclab.euPierrick Seite
Orange
4, rue du Clos Courtel, BP 91226
Cesson-Sevigne 35512
France
EMail: pierrick.seite@orange.comHidetoshi Yokota
KDDI Lab
2-1-15 Ohara
Saitama, Fujimino 356-8502
Japan
EMail: yokota@kddilabs.jpJouni Korhonen
Broadcom Communications
Porkkalankatu 24
Helsinki FIN-00180
Finland
EMail: jouni.nospam@gmail.comSri Gundavelli
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
EMail: sgundave@cisco.com📦 where this page comes from
- ietf: rfc7222 2014-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms