diff options
Diffstat (limited to 'doc/rfc/rfc7561.txt')
| -rw-r--r-- | doc/rfc/rfc7561.txt | 1291 |
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc7561.txt b/doc/rfc/rfc7561.txt new file mode 100644 index 0000000..4a41b14 --- /dev/null +++ b/doc/rfc/rfc7561.txt @@ -0,0 +1,1291 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Kaippallimalil +Request for Comments: 7561 Huawei +Category: Informational R. Pazhyannur +ISSN: 2070-1721 Cisco + P. Yegani + Juniper + June 2015 + + + Mapping Quality of Service (QoS) Procedures + of Proxy Mobile IPv6 (PMIPv6) and WLAN + +Abstract + + This document provides guidelines for achieving end-to-end Quality of + Service (QoS) in a Proxy Mobile IPv6 (PMIPv6) domain where the access + network is based on IEEE 802.11. RFC 7222 describes QoS negotiation + between a Mobile Access Gateway (MAG) and Local Mobility Anchor (LMA) + in a PMIPv6 mobility domain. The negotiated QoS parameters can be + used for QoS policing and marking of packets to enforce QoS + differentiation on the path between the MAG and LMA. IEEE 802.11 and + Wi-Fi Multimedia - Admission Control (WMM-AC) describe methods for + QoS negotiation between a Wi-Fi Station (MN in PMIPv6 terminology) + and an Access Point. This document provides a mapping between the + above two sets of QoS procedures and the associated QoS parameters. + This document is intended to be used as a companion document to RFC + 7222 to enable implementation of end-to-end QoS. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7561. + + + + + + + + +Kaippallimalil, et al. Informational [Page 1] + +RFC 7561 Wi-Fi PMIPv6 QoS June 2015 + + +Copyright Notice + + Copyright (c) 2015 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 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 . . . . . . . . . . . . . . . . . . . . . . . 23 + + + + + + + + + + + +Kaippallimalil, et al. Informational [Page 2] + +RFC 7561 Wi-Fi PMIPv6 QoS June 2015 + + +1. Introduction + + PMIPv6 QoS [1] describes an access-network-independent way to + negotiate Quality of Service (QoS) for Proxy Mobile IPv6 (PMIPv6) + mobility sessions. IEEE 802.11, Wi-Fi Multimedia (WMM), and Wi-Fi + Multimedia - Admission Control (WMM-AC) describe ways to provide QoS + for Wi-Fi traffic between the Wi-Fi Station (STA) and Access Point + (AP). This document describes how QoS can be implemented in a + network where the access network is based on IEEE 802.11 (Wi-Fi). It + requires 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 allow for dynamic QoS policy + information per Mobile Node (MN) and session to be configured by the + IEEE 802.11 access network. PMIPv6 QoS signaling between the Mobile + Access Gateway (MAG) and Local Mobility Anchor (LMA) provisions the + per-MN QoS policies in the MAG. Further details on policy + configuration and the Policy Control Function (PCF) can be found in + [1], Section 6.1. In the IEEE 802.11 access network modeled here, + the MAG is located at the AP / Wireless LAN Controller (WLC). + Figure 1 below provides an overview of the entities and protocols. + + +-----+ +-------+ + | 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 Access Point (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 document. Some + implementations may have the AP and MAG in the same network node. + However, this document does not exclude various deployments including + those in which the AP and WLC are separate nodes or in which the MAG + control and data planes are separate. + + The recommendations in this document use IEEE 802.11 QoS and PMIPv6 + QoS mechanisms [1]. State machines for QoS policy setup in IEEE + 802.11 and PMIPv6 operate differently. Guidelines for installing QoS + in the MN using IEEE 802.11 and PMIPv6 segments and for mapping + parameters between them are outlined below. + + + +Kaippallimalil, et al. Informational [Page 3] + +RFC 7561 Wi-Fi PMIPv6 QoS June 2015 + + + - Procedure Mapping: + + PMIPv6-defined procedures for QoS setup, as specified in [1], may + be triggered by the LMA or MAG. IEEE 802.11 QoS setup, on the + other hand, is always triggered by the MN (IEEE 802.11 QoS + Station (QSTA)). The end-to-end QoS setup across these network + segments should accommodate QoS that is triggered by the network + or by the end user. + + - Parameter Mapping: + + There is no systematic method of mapping of 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 primary emphasis of this specification is to handle the + interworking between WMM-AC signaling/procedures and PMIPv6 QoS + signaling/procedures. When the client does not support WMM-AC, then + the AP/MAG uses the connection mapping in Table 2 and DSCP-to-AC + mapping as shown in Table 3. + + The rest of the document is organized as follows. Section 2 provides + an overview of IEEE 802.11 QoS. Section 3 describes a mapping of QoS + signaling procedures between IEEE 802.11 and PMIPv6. The mapping of + parameters between IEEE 802.11 and PMIPv6 QoS is described 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 + + + +Kaippallimalil, et al. Informational [Page 4] + +RFC 7561 Wi-Fi PMIPv6 QoS June 2015 + + + 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 Control + +1.2. Definitions + + Peak Data Rate + + In WMM-AC, Peak Data Rate specifies the maximum data rate in bits + per second. The Maximum Data Rate does not include the MAC and + PHY overheads [4]. Data rate includes 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 does not include the MAC and PHY overheads [4]. Data rate + includes the transport of the IP packet and header. + + TSPECs for both uplink and downlink must contain the Mean Data + Rate. + + + + + + + +Kaippallimalil, et al. Informational [Page 5] + +RFC 7561 Wi-Fi PMIPv6 QoS June 2015 + + + Minimum Data Rate + + In WMM-AC, Minimum Data Rate specifies the minimum data rate in + bits per second. The Minimum Data Rate does not include the MAC + and PHY overheads [4]. Data rate includes the transport of the IP + packet and header. + + Minimum Data Rate is not used in QoS provisioning as it is + described here. + + QCI + + The QoS Class Identifier (QCI) is a scalar parameter that points + to standardized characteristics of QoS as opposed to signaling + separate parameters for resource type, priority, delay, and loss + [8]. + + STA + + A station (STA) is a device that has the capability to 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]. + + TSPEC + + The TSPEC element in IEEE 802.11 contains the set of parameters + that define the characteristics and QoS expectations of a traffic + flow [3]. + + TCLAS + + The TCLAS element specifies an element that contains a set of + parameters necessary to identify incoming MSDUs (MAC Service Data + Units) that belong to a particular TS (Traffic Stream) [3]. + + + + + + + + + + + + + + +Kaippallimalil, et al. Informational [Page 6] + +RFC 7561 Wi-Fi PMIPv6 QoS June 2015 + + +2. Overview of IEEE 802.11 QoS + + IEEE 802.11 defines a way of providing prioritized access for + different traffic classes (video, voice, etc.) by a mechanism called + EDCA (Enhanced Distributed Channel Access). The levels of priority + in EDCA are called access categories (ACs) and there are four levels + (in decreasing order of priority): Voice, Video, Best-Effort, and + Background. Prioritized access is achieved 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.) + + 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 (now part of IEEE 802.11). This certification is for both + clients and APs and certifies the operation of WMM. WMM is primarily + 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 a part of the 802.1D specification). The IEEE 802.1P + classification scheme has eight priorities, which WMM maps to four + access categories: AC_BK, AC_BE, AC_VI, and AC_VO. The lack of + support in WMM for the TCLAS (used in identifying an IP flow) has an + impact on the QoS provisioning. The impact on WMM-based QoS + provisioning is described in Sections 3 and 4. + + IEEE 802.11 defines the way a (non-AP) STA can request QoS to be + reserved for an access category. Correspondingly, the AP can + determine whether to admit or deny the request depending on the + available resources. Further, the AP may require that Admission + Control is mandatory for an access category. In such a 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. + +3. Mapping QoS Procedures between IEEE 802.11 and PMIPv6 + + There are two main types of interaction possible to provision QoS for + flows that require Admission Control -- one where the MN initiates + the QoS request and the network provisions the resources. The second + is where the network provisions resources as a result of a PMIPv6 QoS + request. In the second scenario, the LMA can push the QoS + configuration to the MAG. However, there is no standard way for the + AP to initiate a QoS service request to the MN. Recommendations to + set up QoS in both these cases are described in this section. + + + +Kaippallimalil, et al. Informational [Page 7] + +RFC 7561 Wi-Fi PMIPv6 QoS June 2015 + + +3.1. MN-Initiated QoS Service Request + +3.1.1. MN-Initiated QoS Reservation Request + + This procedure outlines the case where the MN is configured to start + the QoS signaling. In this case, the MN sends an ADDTS request + indicating the QoS required for the flow. The AP/MAG obtains the + corresponding level of QoS to be granted to the flow by using the + PMIPv6 PBU/PBA sequence that contains the QoS options exchanged with + the LMA. Details of the QoS provisioning for the flow are provided + 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 initiates 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 established + to the LMA. This allows the MN to start application-level + signaling. + + + +Kaippallimalil, et al. Informational [Page 8] + +RFC 7561 Wi-Fi PMIPv6 QoS June 2015 + + + (1) The trigger for the MN to request QoS is an upper-layer + notification. This may be the result of 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 for which + QoS is requested. + + It should be noted that WMM-AC specifications do not contain + TCLAS. When TCLAS is not present, there is 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 + associate them with a subsequent QoS request may be used. This + is not 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 sufficient 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. TSPEC parameter mapping is shown in Table 4. + + If TCLAS is not 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 + cannot be derived, the Traffic Selector field is not included in + the QoS options. + + (3) The LMA obtains the authorized QoS for the flow and responds to + the MAG with Operational Code set to RESPONSE. Mapping of PMIPv6 + to IEEE 802.11 TCLAS is shown in Table 1, and 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 for which the QoS reservations are made. + + 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 completion of the + request.) + + + +Kaippallimalil, et al. Informational [Page 9] + +RFC 7561 Wi-Fi PMIPv6 QoS June 2015 + + + (4) The AP/MAG provisions the corresponding QoS and replies with + ADDTS Response containing 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 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 does not cause the removal of the session + itself. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kaippallimalil, et al. Informational [Page 10] + +RFC 7561 Wi-Fi PMIPv6 QoS June 2015 + + +3.1.2. MN-Initiated QoS De-allocation Request + + QoS resources reserved for a session are released on completion of + the session. When the application session completes, the LMA or the + MN may signal for the release of resources. In the use case shown in + Figure 3, the MN initiates the release of QoS resources. + + +-----------+ + +----+ |+--+ +---+| +-------+ + | 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. + + + + + +Kaippallimalil, et al. Informational [Page 11] + +RFC 7561 Wi-Fi PMIPv6 QoS June 2015 + + + (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 + + This section describes the case when the QoS service request is + initiated by the LMA. For example, an application such as voice may + request the network to initiate configuration of additional QoS + policy as in [8], Section 7.4.2. In the current WLAN specifications, + there is no standard-defined way for the AP to initiate a QoS service + request to the MN. As a result, when the MAG receives a QoS request + from the LMA, it does not have any standard mechanisms to initiate + any QoS requests to the MN over the access network. Given this, the + PMIPv6 QoS service requests and any potential WLAN service requests + (such as described in Section 3.1) are handled asynchronously. + + The PMIPv6 QoS service requests and WLAN QoS service request could + still be coordinated to provide an end-to-end QoS. If the MAG + receives an Update Notification (UPN) request from the LMA to reserve + QoS resources for which it has no corresponding 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 initiates + QoS procedures after the completion of PMIPv6 QoS procedures, the AP/ + MAG can ensure consistency between the QoS resources in the access + network and 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 ensure that the rate can be supported on the network + between MAG and LMA based on previous PMIPv6 QoS procedures. If the + MN subsequently requests data rates of x Mbps or less, the AP can + accept a request based on the earlier PMIPv6 QoS provisioning. For + the case where there is a mismatch, i.e., the network does not + + + +Kaippallimalil, et al. Informational [Page 12] + +RFC 7561 Wi-Fi PMIPv6 QoS June 2015 + + + 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 + + The network-initiated QoS service request scenario poses some + challenges outlined here. IEEE 802.11 does not provide any + mechanisms for the AP to initiate a QoS request. As a result, the + AP/MAG cannot explicitly make any reservations in response to a QoS + reservation request made using UPN. IEEE 802.11aa [5] (which is an + amendment to IEEE 802.11) has a mechanism that enables the AP to ask + the client to reserve QoS for a traffic stream. It does this via the + ADDTS Reserve Request. The ADDTS Reserve Request contains a TSPEC, + an optional TCLAS, and a mandatory stream identifier. The + specification does not describe how the AP would obtain such a stream + identifier. As a result, there needs to be a new higher-layer + protocol defined that is understood by the MN and AP and that + provides a common stream identifier to both ends. Alternately, the + IEEE 802.11aa specification could be modified to make the usage + optional. When (or if) the stream identifier is made 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. + + + + + + + + + + + + + + + + + + + + + + + + + +Kaippallimalil, et al. Informational [Page 13] + +RFC 7561 Wi-Fi PMIPv6 QoS June 2015 + + +3.2.3. LMA-Initiated QoS De-allocation Request + + QoS resources reserved for a session are released on completion of + the session. When the application session completes, the LMA or the + MN may signal for the release of resources. In this use case, the + network initiates 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 initiates the release + of QoS resources. When the application session terminates, the LMA + receives notification of that event. The LMA releases local QoS + resources associated with the flow and initiates 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 and Operational Code set + to DE-ALLOCATE. No additional LMA QoS parameters are sent. + + + + + +Kaippallimalil, et al. Informational [Page 14] + +RFC 7561 Wi-Fi PMIPv6 QoS June 2015 + + + (2) The MAG replies with a UPA confirming the acceptance and + 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 DELTS Response confirming 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 + + TSPEC in IEEE 802.11 is used to reserve QoS for a traffic stream (MN + MAC, TS ID). The IEEE 802.11 QoS reservation is for IEEE 802.11 + frames associated with an MN's MAC address. + + The TCLAS element with Classifier 1 (TCP/UDP Parameters) is used to + identify a PMIPv6 QoS flow. We should note that WMM-AC procedures do + not support TCLAS. When TCLAS is present, a one-to-one mapping + between the TCLAS-defined flow and the Traffic Selector is given + below. + + QoS reservations in IEEE 802.11 are made for a traffic stream + (identified in TCLAS) and correspond to PMIPv6 QoS session parameters + (identified by the Traffic Selector). PMIPv6 QoS [1] specifies that + when QoS-Traffic-Selector is included along with the per-session + bandwidth attributes described in Section 4.3 below, the 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 Mapping + + + + +Kaippallimalil, et al. Informational [Page 15] + +RFC 7561 Wi-Fi PMIPv6 QoS June 2015 + + + If the MN or AP is not able to convey flow parameters in TCLAS, the + QoS reservation request in IEEE 802.11 is 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 Mapping + + When WMM [4] is used, and TCLAS is not present to specify IP flow, + one of two options apply for the MAG - LMA (PMIPv6) segment: + + (a) Bandwidth parameters described in Section 4.3 apply to all flows + of the MN. This is not a preferred mode of operation if the LMA + performs reservation for a single flow, e.g., a voice flow + identified by an IP 5-tuple. + + (b) The IP flow for which the MN requests reservation is derived out- + of-band. For example, the AP/MAG observes application-level + signaling (e.g., SIP [10]) or session-level signaling (e.g., 3GPP + WLCP (WLAN Control Protocol) [7]), associates subsequent ADDTS + requests using heuristics, and then derives the IP flow / Traffic + Selector field. + +4.2. QoS Class + + Table 3 contains a mapping between access category (AC) and IEEE + 802.1D User Priority (UP) tag in IEEE 802.11 frames, and DSCP in IP + data packets. The table also provides the mapping between AC and + DSCP for use in IEEE 802.11 TSPEC and PMIPv6 QoS (Traffic Class). + Mapping of QCI to DSCP uses the tables in [6]. + + + + + + + + + + + + + +Kaippallimalil, et al. Informational [Page 16] + +RFC 7561 Wi-Fi PMIPv6 QoS June 2015 + + + +-----+------+-----------+---------+----------------------+ + | 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, AC + + The MN tags all data packets with DSCP and IEEE 802.1D UP + corresponding to 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 + corresponding DSCP values in Traffic Class (TC). IEEE 802.11 QoS + Access Category AC_VO and AC_VI are used for QoS reservations. AC_BE + and AC_BK should not be used in reservations. + + When WMM-AC specifications that do not contain TCLAS are used, it is + only possible to have one reservation per Traffic Class / access + category. PMIPv6 QoS will not contain any flow-specific attributes + like Traffic Selector. + +4.3. Bandwidth + + Bandwidth parameters that need to be mapped between IEEE 802.11 and + PMIPv6 QoS are shown 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 Flows + + + + + +Kaippallimalil, et al. Informational [Page 17] + +RFC 7561 Wi-Fi PMIPv6 QoS June 2015 + + + In PMIPv6 QoS [1], services using a sending rate smaller than or + equal to the Guaranteed Bit Rate (GBR) can assume, in general, that + congestion-related packet drops will not occur [8]. If the rate + offered by the service exceeds this threshold, there are no + guarantees provided. IEEE 802.11 radio networks do not offer such a + 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]. + + IEEE 802.11 TSPEC requests do not require all fields to be completed. + [4] specifies a list of TSPEC parameters that are required in the + specification. Peak Data Rate is not required in WMM; however, for + MNs and APs that are capable of specifying 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 Mean Data + Rate, or Peak Data Rate in excess of 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 + + This document describes mapping of PMIPv6 QoS parameters to IEEE + 802.11 QoS parameters. Thus, the security in the WLAN and PMIPv6 + signaling segments and the functional entities that map the two + protocols need to be considered. IEEE 802.11 [3] provides the means + to secure management frames that are used for ADDTS and DELTS. The + PMIPv6 specification [9] recommends using IPsec and IKEv2 to secure + protocol messages. The security of the node(s) that implement the + QoS mapping functionality should be considered in actual deployments. + + The QoS mappings themselves do not introduce additional security + concerns. + + + + + + + + + + + +Kaippallimalil, et al. Informational [Page 18] + +RFC 7561 Wi-Fi PMIPv6 QoS June 2015 + + +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/>. + + + + + + +Kaippallimalil, et al. Informational [Page 19] + +RFC 7561 Wi-Fi PMIPv6 QoS June 2015 + + + [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>. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kaippallimalil, et al. Informational [Page 20] + +RFC 7561 Wi-Fi PMIPv6 QoS June 2015 + + +Appendix A. LMA-Initiated QoS Service Flow with IEEE 802.11aa + + +-----------+ + +----+ |+--+ +---+| +-------+ + | 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.11aa + + In the use case shown in Figure 5, the LMA initiates the QoS service + request and IEEE 802.11aa is used to set up the QoS reservation in + the Wi-Fi segment. + + (0) The MN sets up a best-effort session. This allows the MN to + perform application-level signaling and setup. + + (1) The policy server sends a QoS reservation request to the LMA. + This is usually sent in response to an application that requests + the policy server for higher QoS for some of its flows. + + The LMA reserves resources for the flow requested. + + (2) The LMA sends a PMIPv6 UPN (Update Notification) [2], as outlined + in Section 3.2.1, to the MAG with Notification Reason set to + QOS_SERVICE_REQUEST and Acknowledgement Requested flag set to 1. + The Operational Code in the QoS option is set to ALLOCATE, and + the Traffic Selector identifies the flow for QoS. + + + + + + + +Kaippallimalil, et al. Informational [Page 21] + +RFC 7561 Wi-Fi PMIPv6 QoS June 2015 + + + 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. + + (3) If there are sufficient resources to satisfy the request, the AP/ + MAG sends an ADDTS Reserve Request (IEEE 802.11aa) specifying the + QoS reserved for the traffic stream, including the TSPEC and + TCLAS elements mapped from the PMIPv6 QoS Traffic Selector to + identify the flow. + + 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. + + The higher-level stream identifier in IEEE 802.11aa should be + encoded as discussed in Section 3.2.2. + + (4) MN accepts the QoS reserved in the network and replies with ADDTS + Reserve Response. + + (5) The MAG (AP/WLC) replies with a UPA confirming the acceptance of + QoS options and 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 UPA status code set to + CANNOT_MEET_QOS_SERVICE_REQUEST (130). + + + + + + + + + + + + + + + + + + + + + + +Kaippallimalil, et al. Informational [Page 22] + +RFC 7561 Wi-Fi PMIPv6 QoS June 2015 + + +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. + +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 + + + + + + + + + + + + + +Kaippallimalil, et al. Informational [Page 23] + |