RFC 7222
Quality-of-Service Option for Proxy Mobile IPv6
Pages: 58
Proposed Standard
Proposed Standard
Part 3 of 3 – Pages 39 to 58
6. QoS Services in Integrated WLAN-3GPP Networks
6.1. Technical Scope and Procedure
The QoS option specified in this document can provide the equivalent level of QoS information defined in 3GPP, which is used to enforce QoS policies for IP flows that have been established while the mobile node is attached to WLAN access or moved from 3GPP to WLAN access. The QoS classification defined by the 3GPP specification [TS23.207] [TS29.212] is provided by Differentiated Services techniques in the IP transport network. The QoS classification used in the IP transport network is further translated to WLAN QoS-specific techniques in the WLAN access using appropriate WLAN QoS specifications [IEEE802.11aa-2012] [WMM1.2.0]. The details are described in Appendix A and Appendix B. Figure 6 illustrates a generalized architecture where the QoS option can be used. The QoS policies could be retrieved from a Policy Control Function (PCF), such as defined in current cellular mobile communication standards, which aims to assign an appropriate QoS
class to a mobile node's individual flows. Alternatively, more static and default QoS rules could be made locally available, e.g., on a local mobility anchor, through administration. Non-cellular access | Cellular Core Network Cellular (e.g., WLAN) | (e.g., EPC) Access | (e.g., | +-----------+ EUTRAN) | | PCF | | |(e.g.,PCRF)| +----+ | +-----+-----+ |WiFi| (I) | | | AP |---+ +---+---+ | | ((O)) +----+ | |WiFi AR| | PMIPv6 +-----+ +---+ | +----+ (MAG) +=|============| LMA |=====|MAG+--| | | WLC | | tunnel +-----+ +---+ | +----+ | +-------+ | // |WiFi|---+ | // | AP | | // +----+ (II) | // +-------+ | // +----+ +------+ |WiFi AR| | // |WiFi+----+ WLC +------+ (MAG) |=|=======// | AP | | | | | | +----+ +------+ +------ + | ^ ^ | | | | +------------+ QoS inter-working Figure 6: Architecture for QoS Inter-Working between Cellular Access and Non-Cellular Access During a mobile node's handover from cellular access to non-cellular access, e.g., a wireless LAN (WLAN) radio access network, the mobile node's QoS policy rules, as previously established on the local mobility anchor for the mobile node's communication through the cellular access network, are moved to the handover target mobile access gateway serving the non-cellular access network. Such a non- cellular mobile access gateway can have an access-technology-specific controller or function co-located, e.g., a Wireless LAN Controller (WLC), as depicted in option (I) of Figure 6. Alternatively, the access-specific architecture can be distributed, and the access- technology-specific control function is located external to the mobile access gateway, as depicted in option (II). In this case, the mobile access gateway and the access-technology-specific control
function (e.g., the WLC) must provide some protocol for QoS inter- working. Details of such inter-working are out of the scope of this specification.6.2. Relevant QoS Attributes
The QoS Option shall at least contain a DSCP value being associated with IP flows of a mobility session. The DSCP value should correspond to the 3GPP QoS Class Index (QCI), which identifies the type of service in terms of QoS characteristics (e.g., conversational voice, streaming video, signaling, and best effort); more details on DSCP and QCI mapping are given in Appendix A. Optional QoS information could also be added. For instance, in order to comply with the bearer model defined in 3GPP [TS23.203], the following QoS parameters are conveyed for each PMIPv6 mobility session: o Default, non-GBR bearer (QCI=5-9) * DSCP=(BE, AF11, AF21, AF31, AF32) * Per-MN AMBR-UL/DL * Per-Session AMBR-UL/DL {S=1,E=1} * AARP APN (Access Point Name) is provided via the Service Selection ID defined in [RFC5149]. If APN is not interpreted by Wi-Fi AP, the latter will police only based on Per-MN AMBR-UL/DL (without Per- Session AMBR-UL/DL) on the Wi-Fi link. o Dedicated, GBR bearer (QCI=1-4) * DSCP=(EF, AF41) * GBR-UL/DL * MBR-UL/DL * AARP * TS Wi-Fi AP will perform the policy enforcement with the minimum bit rate=GBR and the maximum bit rate=MBR.
o Dedicated, non-GBR bearer (QCI=5-9)
* DSCP=(BE, AF11, AF21, AF31, AF32)
* Per-MN AMBR-UL/DL
* Per-Session AMBR-UL/DL {S=1,E=1}
* AARP
* TS
If APN is not interpreted by Wi-Fi AP, it will police based only
on Per-MN AMBR-UL/DL (without Per-Session AMBR-UL/DL) on the Wi-Fi
link.
If DSCP values follow the 3GPP specification and deployment, the code
point can carry intrinsically additional attributes according to
Figure 7 in Appendix A.
For some optional QoS attributes, the signaling can differentiate
enforcement per mobility session and per IP flow. For the latter, as
long as the AMBR constraints are met, the rule associated with the
identified flow(s) overrules the aggregated rules that apply per
mobile node or per mobility session. Additional attributes can be
appended to the QoS option, but their definition and specification is
out of scope of this document and are left as considerations for
actual deployment.
7. IANA Considerations
IANA has completed the following actions:
o Action-1: This specification defines a new mobility option, the
Quality-of-Service (QoS) option. The format of this option is
described in Section 4.1. The type value 58 for this mobility
option has been allocated from the "Mobility Options" registry at
<http://www.iana.org/assignments/mobility-parameters>.
o Action-2: This specification defines a new mobility attribute
format, the Quality-of-Service attribute. The format of this
attribute is described in Section 4.2. This attribute can be
carried in the Quality-of-Service mobility option. The type
values for this attribute are managed by IANA in a new registry,
the "Quality-of-Service Attribute Registry". This registry is
maintained under the "Mobile IPv6 parameters" registry at
<http://www.iana.org/assignments/mobility-parameters>. This
specification reserves the type values listed below. All other
values (12 - 254) are unassigned and may be assigned by IANA using
the Specification Required policy [RFC5226]. The Designated
Expert reviewing the value assignment is expected to verify that
the protocol extension follows the Proxy Mobile IPv6 architecture
and does not raise backward-compatibility issues with existing
deployments.
+=====+=================================+=================+
|Value| Description | Reference |
+=====+=================================+=================+
| 0 | Reserved | RFC 7222 |
+=====+===================================================+
| 1 | Per-MN-Agg-Max-DL-Bit-Rate | RFC 7222 |
+=====+===================================================+
| 2 | Per-MN-Agg-Max-UL-Bit-Rate | RFC 7222 |
+=====+===================================================+
| 3 | Per-Session-Agg-Max-DL-Bit-Rate | RFC 7222 |
+=====+===================================================+
| 4 | Per-Session-Agg-Max-UL-Bit-Rate | RFC 7222 |
+=====+===================================================+
| 5 | Allocation-Retention-Priority | RFC 7222 |
+=====+===================================================+
| 6 | Aggregate-Max-DL-Bit-Rate | RFC 7222 |
+=====+===================================================+
| 7 | Aggregate-Max-UL-Bit-Rate | RFC 7222 |
+=====+===================================================+
| 8 | Guaranteed-DL-Bit-Rate | RFC 7222 |
+=====+===================================================+
| 9 | Guaranteed-UL-Bit-Rate | RFC 7222 |
+=====+===================================================+
| 10 | QoS-Traffic-Selector | RFC 7222 |
+=====+===================================================+
| 11 | QoS-Vendor-Specific-Attribute | RFC 7222 |
+=====+===================================================+
| 255 | Reserved | RFC 7222 |
+=====+===================================================+
o Action-3: This document defines a new status code,
CANNOT_MEET_QOS_SERVICE_REQUEST (179), for use in Proxy Binding
Acknowledgement messages, as described in Section 4.3. This value
has been assigned from the "Status Codes" registry at
<http://www.iana.org/assignments/mobility-parameters>.
o Action-4: This document defines a new Notification Reason,
QOS_SERVICE_REQUEST (5), for use in Update Notification messages
[RFC7077] as described in Section 4.4. This value has been
assigned from the "Update Notification Reasons Registry" at
<http://www.iana.org/assignments/mobility-parameters>.
o Action-5: This document defines a new status code,
CANNOT_MEET_QOS_SERVICE_REQUEST (130), for use in Update
Notification Acknowledgement messages [RFC7077] as described in
Section 4.5. This value has been assigned from the "Update
Notification Acknowledgement Status Registry" at
<http://www.iana.org/assignments/mobility-parameters>.
8. Security Considerations
The Quality-of-Service option defined in this specification is for
use in Proxy Binding Update, Proxy Binding Acknowledgement, Update
Notification, and Update Notification Acknowledgement messages. This
option is carried in these messages like any other mobility header
option. [RFC5213] and [RFC7077] identify the security considerations
for these signaling messages. When included in these signaling
messages, the Quality-of-Service option does not require additional
security considerations.
9. Acknowledgements
The authors of this document thank the members of NetExt working
group for the valuable feedback to different versions of this
specification. In particular, the authors want to thank Basavaraj
Patil, Behcet Sarikaya, Charles Perkins, Dirk von Hugo, Mark Grayson,
Tricci So, Ahmad Muhanna, Pete McCann, Byju Pularikkal, John
Kaippallimalil, Rajesh Pazhyannur, Carlos J. Bernardos Cano, Michal
Hoeft, Ryuji Wakikawa, Liu Dapeng, Seil Jeon, and Georgios
Karagiannis.
The authors would like to thank all the IESG reviewers, especially,
Ben Campbell, Barry Leiba, Jari Arkko, Alissa Cooper, Stephen
Farrell, Ted Lemon, and Alia Atlas for their valuable comments and
suggestions to improve this specification.
Finally, the authors would like to express sincere and profound
appreciation to our Internet Area Director, Brian Haberman, for his
guidance and great support in allowing us to complete this work.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010. [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, "Traffic Selectors for Flow Bindings", RFC 6088, January 2011. [RFC7077] Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and J. Korhonen, "Update Notifications for Proxy Mobile IPv6", RFC 7077, November 2013.10.2. Informative References
[GSMA.IR.34] GSMA, "Guidelines for IPX Provider networks (Previously Inter-Service Provider IP Backbone Guidelines)", Official Document PRD IR.34, May 2013. [IEEE802.11-2012] IEEE, "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", 2012. [IEEE802.11aa-2012] IEEE, "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, Amendment 2: MAC Enhancements for Robust Audio Video Streaming", 2012. [IEEE802.11e-2005] IEEE, "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, Amendment 8: Medium Access Control (MAC) Quality of Service (QoS) Enhancements", 2005. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[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
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 TableA.2. Use Cases and Protocol Operations
The following subsections provide example message flow charts for scenarios where the QoS option extensions will apply as described in Section 6.1 to the protocol operation for QoS rules establishment (Appendices A.2.1 and A.2.2) and to modification (Appendix A.2.3).A.2.1. Handover of Existing QoS Rules
In Figure 9, the MN is first connected to the LTE network with a multimedia session, such as a video call, with appropriate QoS parameters set by the Policy Control Function. Then, the MN discovers a Wi-Fi AP (e.g., at home or in a cafe) and switches to it, provided that Wi-Fi access has a higher priority when available. Not only is the session continued, but the QoS is also maintained after moving to the Wi-Fi access. In order for that to happen, the LMA delivers the QoS parameters according to the bearer type on the 3GPP access to the MAG via the PMIPv6 signaling with the QoS option
(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 RulesA.2.2. Establishment of QoS Rules
A single operator has deployed both a fixed access network and a mobile access network. In this scenario, the operator may wish a harmonized QoS management on both accesses, but the fixed access network does not implement a QoS control framework. So, the operator chooses to rely on the 3GPP policy control function, which is a standard framework to provide a QoS control, and to enforce the 3GPP QoS policy on the Wi-Fi access network. The PMIP interface is used to realize this QoS policy provisioning. The use case is depicted on Figure 11. The MN first attaches to the Wi-Fi network. During the attachment process, the LMA, which may communicate with Policy Control Function (using procedures outside
the scope of this document), provides the QoS parameters to the MAG via the QoS option (OC=ALLOCATE) in the PMIP signaling (i.e., PBA). Subsequently, an application on the MN may trigger the request for alternative QoS resources, e.g., by use of the WMM-API (Wi-Fi Multimedia - API). The MN may request that traffic resources be reserved using L2 signaling, e.g., sending an Add Traffic System (ADDTS) message [IEEE802.11-2012]. The request is relayed to the MAG, which includes the QoS parameters in the QoS option (OC=ALLOCATE) on the PMIP signaling (i.e., the PBU initiated upon flow creation). The LMA, in coordination with the PCF, can then authorize the enforcement of such QoS policy. Then, the QoS parameters are provided to the MAG via the QoS option (OC=ALLOCATE, SR-ID, QoS attributes, etc.) in the PMIP signaling, and the equivalent QoS treatment is provided towards the MN on the Wi-Fi link. | | | +--------+ | |Policy | | |Control | | |Function| | +---+----+ | | | +---+----+ +----+ +-------+ PMIPv6 | | PGW | +--+ |WiFi|_______| WLC |========|=| (LMA) | |MN|~~| AP | | (MAG) | tunnel | +--------+ +--+ +----+ +-------+ | | Wi-Fi Access | Network | Cellular | Network | Figure 11: QoS Policy Provisioning Figure 12 shows an example of how the QoS rules can be conveyed and enforced between the LMA and MN in the case of initial attachment to WLAN access.
+--+ +--+ +---+ +---+ |MN| |AP|-------------|MAG|-----------------------|LMA| +--+ +--+ +---+ +---+ | | | | | | | | +----attached---+ | [QoS rules] | | | | new session |(E) |(F) |data |----data[QC]-->|---data[DSCPa]-->|-======data[DSCPb]=======->|---> | | |--PBU[update,QoS option]-->| | | | (ReReg) (OC=1) Validate and | | | add QoS rule | | |<----PBA[QoS option]----| | |<-INFO[QoSrules]-| (OC=1, SR-ID)[QoS rules'] | | | | | Apply Establish | | adapted MN's uplink | | QoS rules DSCP rules | | | | | | | | | | | | |data |<--data[QC]----|<---data[DSCP]---|<-======data[DSCP]========-|<---- | | | | | | | |data |---data[QC]--->|-->data[DSCP]--->|-=======data[DSCP]=======->|---> | | | | | | | | (E): AP may enforce uplink QoS rules according to priority class set by the MN (F): MAG can enforce a default QoS class until the local mobility anchor classifies the new flow (notified with PBA) or the mobile access gateway classifies new flow and proposes the associated QoS class to the local mobility anchor for validation (proposed with PBU, notification of validation result with PBA) Figure 12: Adding New QoS Service Request for MN-Initiated FlowA.2.3. Dynamic Update to QoS Policy
A mobile node is attached to the WLAN access and has obtained QoS parameters from the LMA for that mobility session. Having obtained the QoS parameters, a new application, e.g., IP Multimedia Subsystems (IMS) application, gets launched on the mobile node that requires certain QoS support.
The application on the mobile node initiates the communications via a dedicated network function (e.g., IMS Call Session Control Function). Once the communication is established, the application network function notifies the PCF about the new IP flow. The PCF function in turn notifies the LMA about the needed QoS parameters identifying the IP flow and QoS parameters. LMA sends an Update Notification message [RFC7077] to the MAG with the Notification Reason value set to QOS_SERVICE_REQUEST. On receiving the Update Notification message, the MAG completes the PBU/PBA signaling for obtaining the new QoS parameters via the QoS options (OC=MODIFY, SR-ID, QoS attributes, etc.). The MAG provisions the newly obtained QoS parameters on the access network to ensure the newly established IP flow gets its requested network resources. Upon termination of the established IP flow, the application function again notifies the PCF function to remove the established QoS parameters. The PCF notifies the LMA to withdraw the QoS resources established for that voice flow. The LMA sends an Update Notification message to the MAG with the "Notification Reason" value set to "FORCE-REREGISTRATION". On receiving this Update Notification Acknowledgement message, the MAG completes the PBU/PBA signaling for removing the existing QoS rules (OC=DE-ALLOCATE, SR-ID). The MAG then removes the QoS parameters from the corresponding IP flow and releases the dedicated network resources on the access network.Appendix B. Information When Implementing PMIP-Based QoS Support with IEEE 802.11e
This section shows, as an example, the end-to-end QoS management with a 802.11e-capable WLAN access link and a PMIP-based QoS support. The 802.11e, or Wi-Fi Multimedia (WMM), specification provides prioritization of packets for four types of traffic, or access categories (ACs): Voice (AC_VO): Very high-priority queue with minimum delay. Time- sensitive data such as VoIP and streaming mode are automatically sent to this queue. Video (AC_VI): High-priority queue with low delay. Time-sensitive video data is automatically sent to this queue. Best effort (AC_BE): Medium-priority queue with medium throughput and delay. Most traditional IP data is sent to this queue. Background (AC_BK): Lowest-priority queue with high throughput. Bulk data that requires maximum throughput but is not time- sensitive (for example, FTP data) is sent to the queue.
The access point uses the 802.11e indicator to prioritize traffic on the WLAN interface. On the wired side, the access point uses the 802.1p priority tag and DSCP. To allow consistent QoS management on both wireless and wired interfaces, the access point relies on the 802.11e specification, which defines mapping between the 802.11e access categories and the IEEE 802.1D priority (802.1p tag). The end-to-end QoS architecture is depicted in Figure 13, and the 802.11e /802.1D priority mapping is shown in the following table: +-----------+------------------+ | 802.1e AC | 802.1D priority | +-----------+------------------+ | AC_VO | 7,6 | +-----------+------------------+ | AC_VI | 5,4 | +-----------+------------------+ | AC_BE | 0,3 | +-----------+------------------+ | AC_BK | 2,1 | +-----------+------------------+ +=============+ +-----+ DSCP/802.1p | PDP | mapping table +-----+ +=============+ PEP | `._ +---+---+ | `._ |WiFi AR| PMIPv6 +-----+ - + (MAG) +===============| LMA | | WLC | tunnel +-----+ +-------+ PEP | ==Video== 802.1p/DSCP ==Voice== | == B.E.== +----+ +----+ |WLAN| PEP | MN |----802.11e----| AP | +----+ +----+ Figure 13: End-to-End QoS Management with 802.11e When receiving a packet from the MN, the AP checks whether the frame contains 802.11e markings in the L2 header. If not, the AP checks the DSCP field. If the uplink packet contains the 802.11e marking, the access point maps the access categories to the corresponding 802.1D priority as per the table above. If the frame does not contain 802.11e marking, the access point examines the DSCP field.
If DSCP is present, the AP maps DSCP values to a 802.1p value (i.e.,
802.1D priority). This mapping is not standardized and may differ
between operators; a mapping example is given in the following table.
+-------------------+--------+------------+
| Type of traffic | 802.1p | DSCP value |
+-------------------+--------+------------+
| Network Control | 7 | 56 |
+-------------------+--------+------------+
| Voice | 6 | 46 (EF) |
+-------------------+--------+------------+
| Video | 5 | 34 (AF 41) |
+-------------------+--------+------------+
| Voice Control | 4 | 26 (AF 31) |
+-------------------+--------+------------+
| Background Gold | 2 | 18 (AF 21) |
+-------------------+--------+------------+
| Background Silver | 1 | 10 (AF 11) |
+-------------------+--------+------------+
| Best Effort | 0,3 | 0 (BE) |
+-------------------+--------+------------+
The access point prioritizes ingress traffic on the Ethernet port
based on the 802.1p tag or the DSCP value. If the 802.1p priority
tag is not present, the access point checks the DSCP/802.1p mapping
table. The next step is to map the 802.1p priority to the
appropriate egress queue. When 802.11e support is enabled on the
wireless link, the access point uses the IEEE standardized 802.1p/
802.11e correspondence table to map the traffic to the appropriate
hardware queues.
When the 802.11e-capable client sends traffic to the AP, it usually
marks packets with a DSCP value. In that case, the MAG/LMA can come
into play for QoS renegotiation and call flows depicted in Appendix A
apply. Sometimes, when communication is initiated on the WLAN
access, the application does not mark upstream packets. If the
uplink packet does not contain any QoS marking, the AP/MAG could
determine the DSCP field according to traffic selectors received from
the LMA. Figure 14 gives the call flow corresponding to that use
case and shows where QoS tags mapping does come into play. The main
steps are as follows:
(A): During the MN attachment process, the MAG fetches QoS
policies from the LMA. After this step, both the MAG and LMA are
provisioned with QoS policies.
(B): The MN starts a new IP communication without making IP
packets with DSCP tags. The MAG uses the traffic selector to
determine the DSCP value; it then marks the IP packet and forwards
within the PMIP tunnel.
(C): The LMA checks the DSCP value with respect to the traffic
selector. If the QoS policies are valid, the LMA forwards the
packet without renegotiating the QoS rules.
(D): When receiving a marked packet, the MAG, the AP, and the MN
use 802.11e (or WMM), 802.1p tags, and DSCP values to prioritize
the traffic.
+--+ +--+ +---+ +---+
|MN| |AP| |MAG| |LMA|
+--+ + -+ +---+ +---+
(A)|----attach-----|---------------->|-----------PBU---------->|
|<--------------|---------------- |<----PBA[QoS option]-----|
. . [QoS rules] [QoS rules]
(B). . . |
new session | | |
|----data[]---->|----data[]------>|-======data[DSCP]======->|
| | | |
(C)| | | Validate QoS rule
| | | |--->
| | |<======data[DSCP]========|<----
| | | |
| | mapping |
(D)| | DSCP/802.1p |
| |<----data--------| |
| | [802.1p/DSCP] | |
| | | |
| mapping | |
| 802.1p/802.11e | |
|<--data[WMM]---| | |
| | | |
|---data[WMM]-->|------data------>|=======data[DSCP]=======>|--->
| | [802.1p/DSCP] | |
| | | |
Figure 14: Prioritization of a Flow Created on the WLAN Access
Appendix C. Information When Implementing with a Broadband Network Gateway
This section shows an example of QoS interworking between the PMIPv6 domain and the broadband access. The Broadband Network Gateway (BNG) or Broadband Remote Access Server (BRAS) has the MAG function, and the CPE (Customer Premise Equipment) or Residential Gateway (RG) is connected via the broadband access network. The MN is attached to the RG via, e.g., Wi-Fi AP in the broadband home network. In the segment of the broadband access network, the BNG and RG are the Policy Enforcement Point (PEP) for the downlink and uplink traffic, respectively. The QoS information is downloaded from the LMA to the BNG via the PMIPv6 with the QoS option defined in this document. Based on the received QoS parameters (e.g., DSCP values), the broadband access network and the RG provide appropriate QoS treatment to the downlink and uplink traffic to/from the MN. +-----+ | PDP | +-----+ PEP | +-------+ | | BNG/ | PMIPv6 +-----+ | BRAS +===============| LMA | | (MAG) | tunnel +-----+ +-------+ PEP Broadband ( | ) Access ( DSCP ) Network ( | ) +-----+ +----+ | CPE | PEP | MN |-------------| /RG | +----+ Broadband +-----+ Home Network Figure 15: End-to-End QoS Management with the Broadband Access Network In the segment of the broadband access network, QoS mapping between 3GPP QCI values and DSCP described in Section 6.2 is applied. In the segment of the broadband home network, if the MN is attached to the RG via Wi-Fi, the same QoS mapping as described in Appendix B can be applied.
Authors' Addresses
Marco Liebsch NEC Kurfuersten-Anlage 36 Heidelberg D-69115 Germany EMail: liebsch@neclab.eu Pierrick Seite Orange 4, rue du Clos Courtel, BP 91226 Cesson-Sevigne 35512 France EMail: pierrick.seite@orange.com Hidetoshi Yokota KDDI Lab 2-1-15 Ohara Saitama, Fujimino 356-8502 Japan EMail: yokota@kddilabs.jp Jouni Korhonen Broadcom Communications Porkkalankatu 24 Helsinki FIN-00180 Finland EMail: jouni.nospam@gmail.com Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 USA EMail: sgundave@cisco.com