RFC 7561
Mapping Quality of Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN
RFC 7561: Mapping Quality of Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN 🎀
Okay bestie, here's the vibe. This RFC is an Informational doc from June 2015 (ISSN 2070-1721) 💖. It was written by J. Kaippallimalil from Huawei, R. Pazhyannur from Cisco, and P. Yegani from Juniper ✨. Its job is to help you get end-to-end QoS in a PMIPv6 network when the access side is Wi-Fi (IEEE 802.11) 📶. Its header doesn't list any obsoletes or updates entries 🦋.
Abstract 🌸
Okay so this doc gives you guidelines for getting end-to-end QoS in a PMIPv6 domain where the access network runs on IEEE 802.11 🔥. RFC 7222 is the one that describes QoS negotiation between the MAG and the LMA in a PMIPv6 mobility domain 👑. The negotiated parameters can then be used for QoS policing and marking of packets, which is how you actually enforce QoS differentiation on the path between the MAG and LMA 💅.
On the Wi-Fi side, IEEE 802.11 and WMM-AC describe how a Wi-Fi Station (the MN, in PMIPv6 terms) and an Access Point negotiate QoS 🧚. This doc maps those two sets of QoS procedures onto each other, along with their associated QoS parameters 💜. It's meant to be a companion to RFC 7222 so you can actually implement end-to-end QoS 🫶.
Status of This Memo ✨
This doc is not an Internet Standards Track specification. It's published for informational purposes 🦋.
It's a product of 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) 💅. Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 🙈.
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7561 🔗.
Copyright Notice 🌸
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved 💖.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as in effect on the date of publication ✨. Please read these carefully, because they describe your rights and restrictions for this doc 📜. Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 🎀.
Table of Contents 🦋
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
2. Overview of IEEE 802.11 QoS . . . . . . . . . . . . . . . . . 7
3. Mapping QoS Procedures between IEEE 802.11 and PMIPv6 . . . . 7
3.1. MN-Initiated QoS Service Request . . . . . . . . . . . . 8
3.1.1. MN-Initiated QoS Reservation Request . . . . . . . . 8
3.1.2. MN-Initiated QoS De-allocation Request . . . . . . . 11
3.2. LMA-Initiated QoS Service Request . . . . . . . . . . . . 12
3.2.1. LMA-Initiated QoS Reservation Request . . . . . . . . 12
3.2.2. Discussion on QoS Request Handling with IEEE 802.11aa 13
3.2.3. LMA-Initiated QoS De-allocation Request . . . . . . . 14
4. Mapping between IEEE 802.11 QoS and PMIPv6 QoS Parameters . . 15
4.1. Connection Parameters . . . . . . . . . . . . . . . . . . 15
4.2. QoS Class . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Normative References . . . . . . . . . . . . . . . . . . 19
6.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. LMA-Initiated QoS Service Flow with IEEE 802.11aa . 21
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 231. Introduction ✨
Okay so, PMIPv6 QoS [1] describes a way to negotiate QoS for Proxy Mobile IPv6 (PMIPv6) mobility sessions that doesn't depend on the access network 💖. IEEE 802.11, Wi-Fi Multimedia (WMM), and Wi-Fi Multimedia - Admission Control (WMM-AC) describe how to provide QoS for Wi-Fi traffic between the Wi-Fi Station (STA) and the Access Point (AP) 📶.
This doc explains how QoS can be implemented when the access network is IEEE 802.11 (Wi-Fi) 🦋. It needs a mapping between QoS procedures and information elements in two segments: 1) the Wi-Fi segment and 2) the PMIPv6 segment 🧚. (See Figure 1.) The recommendations here let the IEEE 802.11 access network configure dynamic QoS policy information per Mobile Node (MN) and session 🌈. PMIPv6 QoS signaling between the Mobile Access Gateway (MAG) and Local Mobility Anchor (LMA) provisions the per-MN QoS policies in the MAG 💅. More on policy configuration and the Policy Control Function (PCF) is in [1], Section 6.1 🙈. In the IEEE 802.11 access network modeled here, the MAG lives at the AP / Wireless LAN Controller (WLC) 🫶. Figure 1 below gives you the lay of the land 👑.
+-----+ +-------+
| AAA | | PCF |
+--+--+ +---+---+
| |
| |
+----+ +--+--------+ +---+---+
| | IEEE 802.11, WMM-AC |+-++ +---+| PMIPv6 | |
| MN <---------------------->|AP+--+MAG|<==========> LMA |
| | (ADDTS, DELTS) |+--+ +---+| QoS | |
+----+ +-----------+ +-------+Figure 1: End-to-End QoS in Networks with IEEE 802.11 Access
The MN and the AP use IEEE 802.11 QoS mechanisms to set up QoS flows in the Wi-Fi segment 💜. The MAG and LMA set up QoS flows using PMIPv6 QoS procedures 🌸. The protocols and mechanisms between the AP and MAG are outside the scope of this doc 🚫. Some implementations may put the AP and MAG in the same network node 🍓. But this doc doesn't rule out other deployments, including ones where the AP and WLC are separate nodes or where the MAG control and data planes are separate 🎀.
The recommendations here use IEEE 802.11 QoS and PMIPv6 QoS mechanisms [1] ✨. The state machines for QoS policy setup in IEEE 802.11 and PMIPv6 work differently 🙃. So the guidelines for installing QoS in the MN across the IEEE 802.11 and PMIPv6 segments, and for mapping parameters between them, are outlined below 💖.
- Procedure Mapping:
PMIPv6-defined procedures for QoS setup, as specified in [1], may be triggered by the LMA or the MAG 🔥. IEEE 802.11 QoS setup, on the other hand, is always triggered by the MN (IEEE 802.11 QoS Station (QSTA)) 💀. So the end-to-end QoS setup across these network segments should handle QoS that's triggered by the network or by the end user 🫶.
- Parameter Mapping:
Lowkey there's no systematic way to map specific parameters between PMIPv6 QoS parameters and IEEE 802.11 QoS 😭. For example, parameters like Allocation and Retention Priority (AARP) in PMIPv6 QoS have no equivalent in IEEE 802.11 🙈.
The main focus of this spec is handling the interworking between WMM-AC signaling/procedures and PMIPv6 QoS signaling/procedures 👑. When the client doesn't support WMM-AC, the AP/MAG uses the connection mapping in Table 2, plus the DSCP-to-AC mapping shown in Table 3 🌈.
The rest of the doc is organized like this. Section 2 gives an overview of IEEE 802.11 QoS 🦋. Section 3 describes a mapping of QoS signaling procedures between IEEE 802.11 and PMIPv6 🧚. The parameter mapping between IEEE 802.11 and PMIPv6 QoS is in Section 4 💅.
1.1. Abbreviations 💜
AAA Authentication, Authorization, and Accounting
AARP Allocation and Retention Priority
AC Access Category
ADDTS ADD Traffic Stream
AIFS Arbitration Inter-Frame Space
ALG Application Layer Gateway
AMBR Aggregate Maximum Bit Rate
AP Access Point
CW Contention Window
DELTS DELete Traffic Stream
DL DownLink
DSCP Differentiated Services Code Point
DPI Deep Packet Inspection
EDCA Enhanced Distributed Channel Access
EPC Evolved Packet Core
GBR Guaranteed Bit Rate
MAC Media Access Control
MAG Mobile Access Gateway
MBR Maximum Bit Rate
MN Mobile Node
MSDU Media Access Control Service Data Unit
PBA Proxy Binding Acknowledgement
PBU Proxy Binding Update
PCF Policy Control Function
PHY Physical Layer
QCI QoS Class Identifier
QoS Quality of Service
QSTA QoS Station
SIP Session Initiation Protocol
STA Station
TC Traffic Class
TCLAS Type Classification
TCP Transmission Control Protocol
TS Traffic Stream
TSPEC Traffic Conditioning Specification
UDP User Datagram Protocol
UL UpLink
UP User Priority
WLAN Wireless Local Area Network
WLC Wireless Controller
WMM Wi-Fi MultiMedia
WMM-AC Wi-Fi MultiMedia Admission Control1.2. Definitions 📚✨
okay so before we get into the good stuff, let's make sure we're all speaking the same language 🫶
Peak Data Rate 💖
In WMM-AC, Peak Data Rate is the maximum data rate in bits per second. The Maximum Data Rate doesn't count the MAC and PHY overheads [4]. Data rate covers the transport of the IP packet and header.
TSPECs for both uplink and downlink may contain Peak Data Rate 🎀
Mean Data Rate 🌸
This is the average data rate in bits per second. The Mean Data Rate doesn't count the MAC and PHY overheads [4] either. Data rate covers the transport of the IP packet and header.
TSPECs for both uplink and downlink must contain the Mean Data Rate. no exceptions, bestie 💅
Minimum Data Rate 🦋
In WMM-AC, Minimum Data Rate is the minimum data rate in bits per second. It also doesn't count the MAC and PHY overheads [4], and data rate covers the transport of the IP packet and header.
Minimum Data Rate is not used in QoS provisioning as it's described here 🙈
QCI 🌈
The QoS Class Identifier (QCI) is a scalar parameter that points to standardized QoS characteristics. Instead of signaling separate parameters for resource type, priority, delay, and loss, you just send one number that points to the whole bundle [8]. it's giving efficiency 👑
STA 🧚
A station (STA) is a device that can use the IEEE 802.11 protocol. For example, a station maybe a laptop, a desktop PC, an access point, or a Wi-Fi phone [3].
An STA that implements the QoS facility is a QoS Station (QSTA) [3]. QSTA main character energy ✨
TSPEC 💜
The TSPEC element in IEEE 802.11 holds the set of parameters that define the characteristics and QoS expectations of a traffic flow [3]. basically, it's the flow's whole vibe check 💅
TCLAS 🍓
The TCLAS element is an element that holds a set of parameters needed to identify incoming MSDUs (MAC Service Data Units) that belong to a particular TS (Traffic Stream) [3]. it's how the network knows which packets are yours 🫶
2. Overview of IEEE 802.11 QoS 🌟
okay so IEEE 802.11 has a way of giving prioritized access to different traffic classes (video, voice, etc.) through a mechanism called EDCA (Enhanced Distributed Channel Access). The priority levels in EDCA are called access categories (ACs), and there are four of them (in decreasing order of priority): Voice, Video, Best-Effort, and Background. Prioritized access works by using AC-specific values for Contention Window (CW) and Arbitration Inter-Frame Space (AIFS). (Higher-priority categories have smaller values for minimum and maximum CW and AIFS.) it's literally a priority lineup and the VIP gets the smaller numbers 👑
A subset of the QoS mechanisms is defined in WMM -- a Wi-Fi Alliance certification of support for a set of features from an IEEE 802.11e draft (which is now part of IEEE 802.11). This certification covers both clients and APs and certifies the operation of WMM. WMM is mainly the implementation of the EDCA component of IEEE 802.11e. WMM uses the IEEE 802.1P classification scheme developed by the IEEE, which is now part of the 802.1D specification. The IEEE 802.1P classification scheme has eight priorities, and WMM maps those to four access categories: AC_BK, AC_BE, AC_VI, and AC_VO. The lack of support for TCLAS in WMM (the thing used to identify an IP flow) has an impact on QoS provisioning. That impact on WMM-based QoS provisioning is described in Sections 3 and 4. not me going "the TCLAS gap" 😭🎀
IEEE 802.11 defines how a (non-AP) STA can request QoS to be reserved for an access category. In response, the AP can decide whether to admit or deny the request based on the available resources. The AP may also require that Admission Control is mandatory for an access category. In that case, the STA is expected to use the access category only after being successfully admitted. WMM-AC is a Wi-Fi Alliance certification of support for Admission Control based on a set of features in IEEE 802.11 🔥
The QoS signaling in IEEE 802.11 is initiated by the (non-AP) STA by sending an ADDTS request. This specification references procedures in IEEE 802.11, WMM, and WMM-AC. iykyk 🌸
3. Mapping QoS Procedures between IEEE 802.11 and PMIPv6 🦋
okay this part is the main plot 🎬 There are two main ways to provision QoS for flows that need Admission Control. In the first, the MN starts the QoS request and the network provisions the resources. In the second, the network provisions resources because of a PMIPv6 QoS request. In that second scenario, the LMA can push the QoS configuration to the MAG. However, there's no standard way for the AP to start a QoS service request to the MN, which is kind of a bummer 🥺 The recommendations for setting up QoS in both cases are described in this section 💖
3.1. MN-Initiated QoS Service Request 💅
3.1.1. MN-Initiated QoS Reservation Request ✨
This procedure covers the case where the MN is configured to start the QoS signaling. In this case, the MN sends an ADDTS request that indicates the QoS required for the flow. The AP/MAG gets the corresponding level of QoS to grant to the flow by using the PMIPv6 PBU/PBA sequence, which contains the QoS options exchanged with the LMA. The details of QoS provisioning for the flow are below 👇
+-----------+
+----+ |+--+ +---+| +-------+
| MN | ||AP| |MAG|| | LMA |
+-+--+ ++-++--+-+-++ +---+---+
| | | |
+-------------------------------------------------------------+
| (0) establish session with mobile network |
+-------------------------------------------------------------+
| | | |
+-------------+ | | |
|upper-layer | | | |
|notification | | | |
+-+-+-+-+-+-+-+ | | |
| | | |
| ADDTS Request(TCLAS(opt),TSPEC),AC| |
|---------------------------->| | |
| (1) |---->|PBU(QoS options)(2)|
| | |------------------>|
| | | | Policy
| | |PBA(QoS option)(3) |<----->
| | |<------------------|
| |<----| |
|ADDTS Response(TCLAS(opt),TSPEC),AC| |
|<----------------------------| | |
| (4) | |Figure 2: MS-Initiated QoS Service Request 🍓
In the use case shown in Figure 2, the MN starts the QoS service request.
(0) The MN establishes a session as described in steps 1-4 of Use Case 2 (MAG-Initiated QoS Service Request) in Section 3.1 of [1]. At this point, a connection with a PMIPv6 tunnel is set up to the LMA. This lets the MN start application-level signaling 🌈
(1) The trigger for the MN to request QoS is an upper-layer notification. This may come from end-to-end application signaling and setup procedures (e.g., SIP [10]).
Since the MN is configured to start QoS signaling, it sends an ADDTS request with TSPEC and TCLAS identifying the flow it wants QoS for.
It should be noted that WMM-AC specifications don't contain TCLAS. When TCLAS isn't present, there's no direct way to derive flow-specific attributes like Traffic Selector in PMIPv6. In this case, functionality to derive IP flow details from information in upper-layer protocols (e.g., SIP [10]) and link them to a later QoS request may be used. This isn't described further here, but it may be functionality in an Application Layer Gateway (ALG) or Deep Packet Inspection (DPI). It should be noted that an ALG or DPI can increase the complexity of the AP/MAG implementation and affect its scalability. If no TCLAS is derived, the reservation applies to all flows of the MN. Parameter mapping in this case is shown in Table 2 🙈
(2) If there are enough resources at the AP/WLC to satisfy the request, the MAG sends a PBU with QoS options, Operational Code ALLOCATE, and the Traffic Selector identifying the flow. The Traffic Selector is derived from the TCLAS to identify the flow requesting QoS. IEEE 802.11 QoS parameters in TSPEC are mapped to PMIPv6 parameters. The mapping of TCLAS to PMIPv6 is shown in Table 1, and the TSPEC parameter mapping is shown in Table 4. 🔥
If TCLAS isn't present (when WMM-AC is used), TCLAS may be derived from information in upper-layer protocols (as described in step 1) and populated in the Traffic Selector. If TCLAS can't be derived, the Traffic Selector field isn't included in the QoS options.
(3) The LMA gets the authorized QoS for the flow and responds to the MAG with Operational Code set to RESPONSE. The mapping of PMIPv6 to IEEE 802.11 TCLAS is shown in Table 1, and the mapping of TSPEC parameters is shown in Table 4.
Reserved bandwidth for flows is calculated separately from the non-reserved session bandwidth. The Traffic Selector identifies the flow the QoS reservations are made for.
If the LMA offers downgraded QoS values to the MAG, it should send a PBU to the LMA with Operational Code set to DE-ALLOCATE. (The LMA would respond with PBA to confirm the request is complete.) 🥹
(4) The AP/MAG provisions the corresponding QoS and replies with an ADDTS Response containing the authorized QoS in TSPEC, the flow identification in TSPEC, and ResultCode set to SUCCESS.
The AP polices these flows according to the QoS provisioning. 👮♀️✨
In step 3, if the LMA sends a downgraded QoS or a PBA message with status code CANNOT_MEET_QOS_SERVICE_REQUEST (179), then the AP should respond to the MN with an ADDTS Response and ResultCode set as follows:
- for downgraded QoS from LMA, ResultCode is set to
REJECTED_WITH_SUGGESTED_CHANGES. Downgraded QoS values from LMA are mapped to TSPEC as per Table 4. This is still a rejection, but the MN may revise the QoS to a lower level and repeat this sequence if the application can adapt. 💜 - if LMA cannot meet the QoS service request, ResultCode is set to
TCLAS_RESOURCES_EXHAUSTED. 💀
Either REJECTED_WITH_SUGGESTED_CHANGES or TCLAS_RESOURCES_EXHAUSTED results in the rejection of the QoS reservation, but it doesn't cause the removal of the session itself. So the session survives, even if the reservation doesn't 🫶🦋
3.1.2. MN-Initiated QoS De-allocation Request ✨
okay so QoS resources reserved for a session get released once the session is done 🌸 When the application session wraps up, the LMA or the MN can both signal for the release. In the setup in Figure 3, the MN is the one who kicks it off 💅
+-----------+
+----+ |+--+ +---+| +-------+
| MN | ||AP| |MAG|| | LMA |
+-+--+ ++-++--+-+-++ +---+---+
| | | |
+-------------------------------------------------------------+
| (0) Establishment of application session |
| and reservation of QoS resources |
| |
| (Session in progress) |
| |
| Release of application session |
+-------------------------------------------------------------+
| | | |
| DELTS Request (TS INFO)(1) | | |
|---------------------------->| | |
| |---->| |
| |<----| |
| DELTS Response (TS INFO)(2) | | |
|<----------------------------| | |
| | |PBU(QoS,DE-ALLOC)(3)|
| | |------------------->|Policy
| | | |<---->
| | | |Update
| | |PBA(QoS,RESPONSE)(4)|
| | |<-------------------|
| | | |Figure 3: MN-Initiated QoS Resource Release
(0) The MN establishes and reserves QoS resources. When the application session terminates, the MN prepares to release QoS resources. 🎀
(1) The MN releases its own internal resources and sends a DELTS Request to the AP with TS (Traffic Stream) INFO. 🦋
(2) The AP receives the DELTS request, releases local resources, and responds to the MN with a DELTS response. 💖
(3) The MAG initiates a PBU, with the Operational Code set to DE-ALLOCATE, and with the Traffic Selector constructed from TCLAS and PMIPv6 QoS parameters from TSPEC.
When TCLAS is not present, the MAG should de-allocate all flows with the same access category as indicated in the DELTS Request. In the typical case, if the client does not support TCLAS and only MN-initiated QoS Service requests are supported, then the MAG will have at most one QoS Service request per access category. 🧚
(4) LMA receives the PBU and releases local resources. The LMA then responds with a PBA. 🫶
It should be noted that steps 3 and 4 can proceed independently of the DELTS Response (step 2). 👑
3.2. LMA-Initiated QoS Service Request
3.2.1. LMA-Initiated QoS Reservation Request
okay so this section is about the case where the QoS service request comes from the LMA 🦋 For example, an app like voice might ask the network to set up extra QoS policy, as in [8], Section 7.4.2. The thing is, current WLAN specs have no standard-defined way for the AP to start a QoS service request to the MN 😭 So when the MAG gets a QoS request from the LMA, it doesn't have any standard mechanisms to kick off QoS requests to the MN over the access network. That means the PMIPv6 QoS service requests and any potential WLAN service requests (such as the ones described in Section 3.1) are handled asynchronously. 🌈
The PMIPv6 QoS service requests and the WLAN QoS service request could still be coordinated to give you an end-to-end QoS. If the MAG gets an Update Notification (UPN) request from the LMA to reserve QoS resources for which it has no matching QoS request from the MN, the MAG may, in consultation with the AP, provision a policy that can grant a subsequent QoS request from the MN. If the MN starts QoS procedures after the PMIPv6 QoS procedures are done, the AP/MAG can keep the QoS resources in the access network consistent with the QoS resources between the MAG and LMA. 💅
For example, if the MN is requesting a mean data rate of x Mbps, the AP and MAG can make sure that the rate can be supported on the network between the MAG and LMA, based on the earlier PMIPv6 QoS procedures. If the MN later requests data rates of x Mbps or less, the AP can accept the request based on the earlier PMIPv6 QoS provisioning. For the case where there is a mismatch, i.e., the network does not support the x Mbps, then either the MAG should renegotiate the QoS resource and ask for increased QoS resources, or the AP should reject the QoS request. 🙈
3.2.2. Discussion on QoS Request Handling with IEEE 802.11aa
this part is about the challenges with network-initiated QoS service requests 🥺 IEEE 802.11 doesn't give the AP any mechanism to start a QoS request. So the AP/MAG can't explicitly make any reservations in response to a QoS reservation request made using UPN. ✨ IEEE 802.11aa [5] (an amendment to IEEE 802.11) does have a mechanism that lets the AP ask the client to reserve QoS for a traffic stream, using the ADDTS Reserve Request. The ADDTS Reserve Request contains a TSPEC, an optional TCLAS, and a mandatory stream identifier. The spec doesn't describe how the AP would get such a stream identifier 💀 So there needs to be a new higher-layer protocol that both the MN and AP understand, and that gives both ends a common stream identifier. Alternately, the IEEE 802.11aa specification could be modified to make the usage optional. When (or if) the stream identifier becomes optional, the TCLAS can provide information about the traffic stream. 🌸
Appendix A outlines a protocol sequence with PMIPv6 UPN / Update Notification Acknowledgement (UPA) if the above IEEE 802.11aa issues can be resolved. 🦋
3.2.3. LMA-Initiated QoS De-allocation Request
same energy as before but flipped 🔄 QoS resources reserved for a session get released once the session completes. When the application session is done, the LMA or the MN can signal for the release of resources. In this use case, the network starts the release of QoS resources. 💜
+-----------+
+----+ |+--+ +---+| +-------+
| MN | ||AP| |MAG|| | LMA |
+-+--+ ++-++--+-+-++ +---+---+
| | | |
+-------------------------------------------------------------+
| Establishment of application session |
| and reservation of QoS resources |
| |
| (Session in progress) |
| |
| Release of application session |
+-------------------------------------------------------------+
| | | | Policy
| | | |<------
| | |UPN(QoS,DE-ALLOC) |
| | |<------------------|
| |<----| (1) |
| |---->|UPA(QoS,RESPONSE) |
| | |------------------>|
| | | (2) |
| | | |
| DELTS Request (TS INFO)(3) | | |
|<----------------------------| | |
| DELTS Response (TS INFO)(4) | | |
|---------------------------->| | |
| | | |Figure 4: LMA-Initiated QoS Resource Release
In the use case shown in Figure 4, the network starts the release of QoS resources. When the application session terminates, the LMA gets notified of that event. The LMA releases the local QoS resources associated with the flow, and then starts signaling to release QoS resources in the network. 🫧
(1) The LMA sends a UPN with QoS options identifying the flow for which QoS resources are to be released, with the Operational Code set to DE-ALLOCATE. No additional LMA QoS parameters are sent. 🎀
(2) The MAG replies with a UPA confirming the acceptance, with the Operational Code set to RESPONSE. 💖
(3) The AP/WLC (MAG) releases local QoS resources associated with the flow. The AP derives the corresponding access category from the Traffic Class (TC) field provided in the QoS option. In addition, if the AP supports TCLAS and the QoS option contains a Traffic Selector field, then the AP shall map the Traffic Selector into a TCLAS element. In the case where the AP does not support TCLAS (for example, an AP compliant with WMM-AC), then the AP shall only use the access category. The AP sends a DELTS Request with TS INFO identifying the reservation. 🧚
(4) The MN sends a DELTS Response confirming the release. 🫶
It should be noted that steps 3 and 4 can proceed independently of the UPA (step 2). 👑
4. Mapping between IEEE 802.11 QoS and PMIPv6 QoS Parameters ✨
4.1. Connection Parameters ✨
okay so TSPEC in IEEE 802.11 is what reserves QoS for a traffic stream, identified by the pair (MN MAC, TS ID) 💅 the reservation is for 802.11 frames tied to an MN's MAC address, bestie 🫶
the TCLAS element with Classifier 1 (TCP/UDP Parameters) is how you identify a PMIPv6 QoS flow 🦋 and we should note that WMM-AC procedures do not support TCLAS 😭 when TCLAS is present, there's a one-to-one mapping between the TCLAS-defined flow and the Traffic Selector, as shown below 🎀
802.11 QoS reservations are made per traffic stream (the one named in TCLAS), and they line up with PMIPv6 QoS session parameters (the ones named by the Traffic Selector) 🌸 PMIPv6 QoS [1] says that when QoS-Traffic-Selector shows up together with the per-session bandwidth attributes from Section 4.3 below, those attributes apply at a per-session level 💜
+--------------------------------+----------------------------+
| MN <--> AP (IEEE 802.11) | MAG <--> LMA (PMIPv6) |
+--------------------------------+----------------------------+
| (TCLAS Classifier 1)TCP/UDP IP | Traffic Selector (IP flow) |
| (TCLAS Classifier 1) DSCP | Traffic Class (TC) |
+--------------------------------+----------------------------+
Table 1: IEEE 802.11 - PMIPv6 QoS Connection Mappingif the MN or AP can't convey flow parameters in TCLAS, the QoS reservation request in 802.11 gets derived as shown in Table 2 🧚
+------------------------------+--------------------------+
| MN <--> AP (WMM) | MAG <--> LMA (PMIPv6) |
+------------------------------+--------------------------+
| (no IP flow parameter/TCLAS) | (a) applies to all flows |
| | (b) derived out-of-band |
| | |
| User Priority (802.1D) | Traffic Class (TC) |
| | (derived using Table 3) |
+------------------------------+--------------------------+
Table 2: WMM - PMIPv6 QoS Connection Mappingwhen WMM [4] is used and TCLAS isn't there to specify the IP flow, one of two options applies for the MAG - LMA (PMIPv6) segment 👑
(a) the bandwidth parameters from Section 4.3 apply to all flows of the MN. this is not a preferred mode of operation if the LMA is doing reservation for a single flow, like a voice flow identified by an IP 5-tuple 🙈
(b) the IP flow the MN wants reserved gets derived out-of-band 🌈 for example, the AP/MAG watches application-level signaling (like SIP [10]) or session-level signaling (like 3GPP WLCP (WLAN Control Protocol) [7]), links later ADDTS requests to those using heuristics, and then works out the IP flow / Traffic Selector field 🔥
4.2. QoS Class 🌈
Table 3 is the mapping between access category (AC) and the IEEE 802.1D User Priority (UP) tag in 802.11 frames, plus DSCP in IP data packets 💖 it also maps AC to DSCP for use in the 802.11 TSPEC and PMIPv6 QoS (Traffic Class). mapping QCI to DSCP uses the tables in [6] ✨
+-----+------+-----------+---------+----------------------+
| QCI | DSCP | 802.1D UP | AC | Example Services |
+-----+------+-----------+---------+----------------------+
| 1 | EF | 6(VO) | 3 AC_VO | conversational voice |
| 2 | EF | 6(VO) | 3 AC_VO | conversational video |
| 3 | EF | 6(VO) | 3 AC_VO | real-time gaming |
| 4 | AF41 | 5(VI) | 2 AC_VI | buffered streaming |
| 5 | AF31 | 4(CL) | 2 AC_VI | signaling |
| 6 | AF32 | 4(CL) | 2 AC_VI | buffered streaming |
| 7 | AF21 | 3(EE) | 0 AC_BE | interactive gaming |
| 8 | AF11 | 1(BE) | 0 AC_BE | web access |
| 9 | BE | 0(BK) | 1 AC_BK | email |
+-----+------+-----------+---------+----------------------+
Table 3: QoS Mapping between QCI/DSCP, 802.1D UP, ACthe MN tags all data packets with DSCP and IEEE 802.1D UP that match the application and the subscribed policy or authorization 💅 the AP polices sessions and flows based on the configured QoS policy values for the MN 🫶
for QoS reservations, TSPEC uses WMM-AC values and PMIPv6 QoS uses the matching DSCP values in Traffic Class (TC) 🦋 AC_VO and AC_VI are the ones used for QoS reservations 🎀 AC_BE and AC_BK should not be used in reservations 😬
when WMM-AC specs without TCLAS are used, you can only have one reservation per Traffic Class / access category, and PMIPv6 QoS won't carry any flow-specific attributes like Traffic Selector 🙈
4.3. Bandwidth 💜
the bandwidth parameters that need mapping between 802.11 and PMIPv6 QoS are in Table 4 🌸
+-------------------------+---------------------------+
| MN <--> AP(IEEE 802.11) | MAG <--> LMA (PMIPv6) |
+-------------------------+---------------------------+
| Mean Data Rate, DL | Guaranteed-DL-Bit-Rate |
| Mean Data Rate, UL | Guaranteed-UL-Bit-Rate |
| Peak Data Rate, DL | Aggregate-Max-DL-Bit-Rate |
| Peak Data Rate, UL | Aggregate-Max-UL-Bit-Rate |
+-------------------------+---------------------------+
Table 4: Bandwidth Parameters for Admission-Controlled Flowsin PMIPv6 QoS [1], services sending at a rate smaller than or equal to the Guaranteed Bit Rate (GBR) can generally assume congestion-related packet drops won't happen [8] 🍓 if the rate offered by the service goes above that threshold, no guarantees are given 💀 802.11 radio networks don't offer that kind of guarantee, but [4] notes that the application (service) requirements are captured in TSPEC by the MSDU (MAC Service Data Unit) and Mean Data Rate ✨ the TSPEC should contain Mean Data Rate, and it is recommended that it be mapped to the GBR parameters, Guaranteed-DL-Bit-Rate and Guaranteed-UL-Bit-Rate in PMIPv6 QoS [1] 🫶
802.11 TSPEC requests don't have to fill in every field 🧚 [4] specifies a list of TSPEC parameters that are required in the specification. Peak Data Rate isn't required in WMM, but for MNs and APs that can specify the Peak Data Rate, it should be mapped to MBR (Maximum Bit Rate) in PMIPv6 QoS 👑 the AP should use the MBR parameters Aggregate-Max-DL-Bit-Rate and Aggregate-Max-UL-Bit-Rate to police these flows on the backhaul segment between MAG and LMA 🔥
during the QoS reservation procedure, if the MN requests a Mean Data Rate or Peak Data Rate in excess of the values authorized in PMIPv6 QoS, the AP should deny the request in an ADDTS response 😭 the AP may set the reject cause code to REJECTED_WITH_SUGGESTED_CHANGES and send a revised TSPEC with Mean Data Rate and Peak Data Rate set to acceptable GBR and MBR, respectively, in PMIPv6 QoS 🌈
5. Security Considerations 🔐
okay this part is SERIOUS bestie 😭 this document describes mapping PMIPv6 QoS parameters to IEEE 802.11 QoS parameters, so the security of the WLAN and PMIPv6 signaling segments AND the functional entities that map the two protocols all need to be considered 💀 IEEE 802.11 [3] gives you ways to secure the management frames used for ADDTS and DELTS 🛡️ the PMIPv6 specification [9] recommends using IPsec and IKEv2 to secure protocol messages 🔒 the security of the node(s) implementing the QoS mapping functionality should be considered in real deployments, no cap 🫣
the QoS mappings themselves don't introduce any additional security concerns ✨
6. References 📚
6.1. Normative References 💖
[1] Liebsch, M., Seite, P., Yokota, H., Korhonen, J., and S. Gundavelli, "Quality-of-Service Option for Proxy Mobile IPv6", RFC 7222, DOI 10.17487/RFC7222, May 2014, <http://www.rfc-editor.org/info/rfc7222>.
[2] Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and J. Korhonen, "Update Notifications for Proxy Mobile IPv6", RFC 7077, DOI 10.17487/RFC7077, November 2013, <http://www.rfc-editor.org/info/rfc7077>.
6.2. Informative References 🌸
[3] IEEE, "IEEE Standard for Information Technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11.
[4] Wi-Fi Alliance, "Wi-Fi Multimedia Technical Specification (with WMM-Power Save and WMM-Admission Control)", Version 1.2.0, May 2012.
[5] IEEE, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specification, Amendment 2: MAC Enhancements for Robust Audio Video Streaming", IEEE 802.11aa.
[6] 3GPP, "Guidelines for IPX Provider networks (Previously Inter-Service Provider IP Backbone Guidelines)", GSMA Official Document IR.34 v11.0, November 2014, <http://www.gsma.com/newsroom/wp-content/uploads/ IR.34-v11.0.pdf>.
[7] 3GPP, "Technical Specification Group Core Network and Services; Wireless LAN control plane protocols for trusted WLAN access to EPC; Stage 3 (Release 12)", 3GPP TS 23.244 12.1.0, December 2014, <http://www.3gpp.org/ftp/specs/archive/24_series/24.244/>.
[8] 3GPP, "Technical Specification Group Services and System Aspects; Policy and Charging Control Architecture (Release 13)", 3GPP TS 23.203 13.2.0, December 2014, <http://www.3gpp.org/ftp/specs/archive/23_series/23.203/>.
[9] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, DOI 10.17487/RFC5213, August 2008, <http://www.rfc-editor.org/info/rfc5213>.
[10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
Appendix A. LMA-Initiated QoS Service Flow with IEEE 802.11aa 🦋
Okay bestie, this is the grand finale! 🎀 Here's the whole flow in one picture, so you can see the LMA kicking things off and the Wi-Fi side doing its thing ✨
+-----------+
+----+ |+--+ +---+| +-------+
| MN | ||AP| |MAG|| | LMA |
+-+--+ ++-++--+-+-++ +---+---+
| | | |
+----------------------------------------------------------------+
| (0) establish session with mobile network |
+----------------------------------------------------------------+
| | | |
| | | | Policy
| | | |<----------
| | |UPN(QoS opt(2) | Update(1)
| ADDTS Reserve Request | |<-----------------|
| (TCLAS, TSPEC)(3) |<----| |
|<-------------------------| | |
| ADDTS Reserve Response | | |
| (TCLAS, TSPEC)(4) | | |
|------------------------->| | |
| |---->|UPA(QoS opt)(5) |
| | |----------------->|
| | | |
Figure 5: LMA-Initiated QoS Service Request with 802.11aaFigure 5: LMA-Initiated QoS Service Request with 802.11aa
So in the use case shown in Figure 5, the LMA is the one that starts the QoS service request, and IEEE 802.11aa is what sets up the QoS reservation on the Wi-Fi segment. It's giving teamwork 🫶
(0) The MN sets up a best-effort session first. This lets the MN do its application-level signaling and setup, so everything's ready before the upgrade. 🌸
(1) The policy server sends a QoS reservation request to the LMA. This is usually sent in response to an application that asks the policy server for higher QoS for some of its flows. Then the LMA reserves resources for the flow that was requested. Main character energy 👑
(2) The LMA sends a PMIPv6 UPN (Update Notification) [2], as outlined in Section 3.2.1, to the MAG. The Notification Reason is set to QOS_SERVICE_REQUEST and the Acknowledgement Requested flag is set to 1. The Operational Code in the QoS option is set to ALLOCATE, and the Traffic Selector identifies the flow for QoS. 💖
The LMA QoS parameters include Guaranteed-DL-Bit-Rate/Guaranteed-UL-Bit-Rate and Aggregate-Max-DL-Bit-Rate/Aggregate-Max-UL-Bit-Rate for the flow. The reserved bandwidth for flows is calculated separately from the non-reserved session bandwidth, which is so organized 🍓
(3) If there are sufficient resources to satisfy the request, the AP/MAG sends an ADDTS Reserve Request (IEEE 802.11aa) that specifies the QoS reserved for the traffic stream. This includes the TSPEC and TCLAS elements, which are mapped from the PMIPv6 QoS Traffic Selector so the flow can be identified. ✨
PMIPv6 parameters are mapped to TCLAS (Table 1) and TSPEC (Table 4). If there are insufficient resources at the AP/WLC, the MAG will not send an ADDTS message and will continue the processing of step 5. Oof, not ideal, but the flow keeps moving 💀
The higher-level stream identifier in IEEE 802.11aa should be encoded as discussed in Section 3.2.2.
(4) The MN accepts the QoS reserved in the network and replies with an ADDTS Reserve Response. Accepted and locked in 🔥
(5) The MAG (AP/WLC) replies with a UPA confirming the acceptance of the QoS options, with the Operational Code set to RESPONSE. The AP/WLC polices flows based on the new QoS. 🦋
If there are insufficient resources at the AP in step 3, the MAG sends a response with the UPA status code set to CANNOT_MEET_QOS_SERVICE_REQUEST (130). Not everything can be a win, but at least it's clear what happened 🙈
Acknowledgements 🫶
The authors thank the NETEXT Working Group for the valuable feedback to different versions of this specification. In particular, the authors wish to thank Sri Gundavelli, Georgios Karagianis, Rajeev Koodli, Kent Leung, Marco Liebsch, Basavaraj Patil, Pierrick Seite, and Hidetoshi Yokota for their suggestions and valuable input. The authors also thank George Calcev, Mirko Schramm, Mazin Shalash, and Marco Spini for detailed input on parameters and scheduling in IEEE 802.11 and 3GPP radio networks. The whole squad deserves flowers 💐
Authors' Addresses 💌
John Kaippallimalil
Huawei
5340 Legacy Dr., Suite 175
Plano, TX 75024
United States
EMail: john.kaippallimalil@huawei.com
Rajesh Pazhyannur
Cisco
170 West Tasman Drive
San Jose, CA 95134
United States
EMail: rpazhyan@cisco.com
Parviz Yegani
Juniper
1194 North Mathilda Ave.
Sunnyvale, CA 94089-1206
United States
EMail: pyegani@juniper.net📦 where this page comes from
- ietf: rfc7561 2015-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms