idnits 2.17.1 draft-liebsch-netext-pmip6-qos-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2012) is 4421 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETEXT WG M. Liebsch 3 Internet-Draft NEC 4 Intended status: Standards Track P. Seite 5 Expires: September 13, 2012 France Telecom - Orange 6 H. Yokota 7 KDDI Lab 8 J. Korhonen 9 Nokia Siemens Networks 10 S. Gundavelli 11 Cisco 12 March 12, 2012 14 Quality of Service Option for Proxy Mobile IPv6 15 draft-liebsch-netext-pmip6-qos-01.txt 17 Abstract 19 This specification defines a new mobility option that can be used by 20 the mobility entities in the Proxy Mobile IPv6 domain to exchange 21 Quality of Service parameters associated with a subscriber's IP 22 flows. Using the QoS option, the local mobility anchor and the 23 mobile access gateway can exchange available QoS attributes and 24 associated values. This enables QoS policing and labeling of packets 25 to enforce QoS differentiation on the path between the local mobility 26 anchor and the mobile access gateway. Furthermore, making QoS 27 parameters available on the MAG enables mapping these parameters to 28 QoS rules being specific to the access technology which operates 29 below the mobile access gateway. After such mapping, QoS rules can 30 be enforced on the access technology components, such as an IEEE 31 802.11e Wireless LAN controller. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 13, 2012. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 7 70 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7 71 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 73 3. Description of the Technical Approach . . . . . . . . . . . . 8 74 3.1. Technical Scope and Procedure . . . . . . . . . . . . . . 8 75 3.2. Use Case A -- Handover of Available QoS Context . . . . . 9 76 3.3. Use Case B -- Establishment of new QoS Context in 77 non-3G Access . . . . . . . . . . . . . . . . . . . . . . 10 78 3.4. Relevant QoS Attributes . . . . . . . . . . . . . . . . . 11 79 3.5. Protocol Operation . . . . . . . . . . . . . . . . . . . . 12 80 3.5.1. Handover of existing QoS rules . . . . . . . . . . . . 13 81 3.5.2. Establishment of QoS rules . . . . . . . . . . . . . . 14 83 4. Protocol Considerations . . . . . . . . . . . . . . . . . . . 15 84 4.1. Mobile Access Gateway Considerations . . . . . . . . . . . 15 85 4.2. Local Mobility Anchor Considerations . . . . . . . . . . . 15 87 5. Quality of Service Option . . . . . . . . . . . . . . . . . . 17 89 6. QoS Information Attributes (Type-Length-Values) . . . . . . . 18 90 6.1. Per Mobile Node Aggregate Maximum Downlink Bit Rate . . . 18 91 6.2. Per Mobile Node Aggregate Maximum Uplink Bit Rate . . . . 18 92 6.3. Per Mobility Session Aggregate Maximum Downlink Bit 93 Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 6.4. Per Mobility Session Aggregate Maximum Uplink Bit Rate . . 19 95 6.5. Allocation and Retention Priority . . . . . . . . . . . . 20 96 6.6. Guaranteed Downlink Bit Rate . . . . . . . . . . . . . . . 21 97 6.7. Guaranteed Uplink Bit Rate . . . . . . . . . . . . . . . . 22 99 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 101 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 103 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 105 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 106 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 107 10.2. Informative References . . . . . . . . . . . . . . . . . . 26 109 Appendix A. Information when implementing PMIP based QoS 110 support with IEEE 802.11e . . . . . . . . . . . . . . 27 112 Appendix B. Information when implementing with a Broadband 113 Network Gateway . . . . . . . . . . . . . . . . . . . 31 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 117 1. Introduction 119 Mobile operators deploy Proxy Mobile IPv6 (PMIPv6) [RFC5213] to 120 enable network-based mobility management for mobile nodes (MN). 121 Users can access Internet Protocol (IP) based services from their 122 mobile device by using different radio access technologies. Current 123 standardization effort considers strong QoS classification and 124 enforcement for cellular radio access technologies. QoS policies are 125 typically controlled by a policy control function, whereas the 126 policies are enforced by different gateways in the infrastructure, 127 such as the LMA and the MAG, as well as by access network elements. 128 Policy control and QoS differentiation for access to the mobile 129 operator network through alternative non-cellular access technologies 130 is not yet considered, even though some of these access technologies 131 are able to support QoS by appropriate traffic prioritization 132 techniques. However, handover and IP Flow Mobility using alternative 133 radio access technologies, such as IEEE802.16 and Wireless LAN 134 according to the IEEE802.11 specification, are being considered by 135 the standards [TS23.402], whereas inter-working with the cellular 136 architecture to establish QoS policies in alternative access networks 137 has not been focussed on so far. 139 In particular the Wireless LAN technology has been identified as 140 promising alternative technology to complement cellular radio access. 141 Since the 802.11e standard provides QoS extensions to WLAN, it is 142 beneficial to apply QoS policies to the WLAN access, which enables 143 QoS classification of downlink as well as uplink traffic between an 144 MN and its LMA. Three functional operations have been identified to 145 accomplish this: 147 (a) Maintenance of QoS classification during a handover between 148 cellular radio access and WLAN access by means of establishing QoS 149 policies in the handover target access network, 151 (b) mapping of QoS classes and associated policies between 152 different access systems and 154 (c) establishment of QoS policies for new data sessions/flows, 155 which are initiated while using WLAN access. 157 This document specifies an extension to the PMIPv6 protocol, which 158 enables the transport of established QoS descriptions between an LMA 159 and the MAG by means of a QoS container option in case the QoS policy 160 in the WLAN access is not under explicit control of a policy control 161 system. The specified option allows association between IP session 162 keys, such as a Differentiated Services Code Point (DSCP), and the 163 expected QoS class for this IP session. Further handling of QoS 164 policies between the MAG and the WLAN Controller (WLC) or WLAN Access 165 Point is out of scope of this specification. 167 2. Conventions and Terminology 169 2.1. Conventions 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in RFC 2119 [RFC2119]. 175 2.2. Terminology 177 All the mobility related terms used in this document are to be 178 interpreted as defined in the Proxy Mobile IPv6 specifications 179 [RFC5213], [RFC5844], [RFC5845] and [RFC5846]. Additionally, this 180 document uses the following abbreviations: 182 o WLAN (Wireless Local Area Network) - A wireless network. 184 o WTP (Wireless Termination Point): The entity that functions as the 185 termination point for the network-end of the IEEE 802.11 based air 186 interface from the mobile node. It is also known as the Wireless 187 Access Point. 189 o WLC (Wireless LAN Controller): The entity that provides the 190 centralized forwarding, routing function for the user traffic. 191 All the user traffic from the mobile nodes attached to the WTP's 192 is typically tunneled to this centralized WLAN access controller. 194 3. Description of the Technical Approach 196 3.1. Technical Scope and Procedure 198 The QoS option specified in this document supports the setup of 199 states on the LMA and the MAG to allow enforcement of QoS policies 200 for packet differentiation on the network path between the LMA and 201 the MAG providing non-cellular access to the mobile operator network. 202 QoS differentiation is typically enabled in the mobile operator's 203 network using Differentiated Services techniques in the IP transport 204 network, whereas radio access specific QoS differentiation depends on 205 the radio technology in use. Whereas very accurate and fine granular 206 traffic classes are specified for the cellular radio access, the IP 207 transport network supports enforcement of solely four Differentiated 208 Services classes according to four well-known Differentiated Services 209 Code Points (DSCP). 211 Central control from a Policy Control Function (PCF) is considered in 212 current cellular mobile communication standards to assign an 213 appropriate QoS class to an MN's individual flows. Non-cellular 214 access technologies are not yet considered for per-flow QoS policing 215 under control of a common PCF. The QoS option specified in this 216 document enables exchange of QoS policies, which have been setup for 217 an MN's IP flows on the cellular network, between the LMA and a new 218 MAG during handover from the cellular access network to the non- 219 cellular access network. Furthermore, the QoS option can be used to 220 exchange QoS policies for new IP flows, which are initiated while the 221 MN is attached to the non-cellular MAG. 223 Figure 1 illustrates a generalized architecture where the QoS option 224 can be used. During an MN's handover from cellular access to non- 225 cellular access, e.g. a wireless LAN (WLAN) radio access network, the 226 MN's QoS policy rules, as previously established on the LMA for the 227 MN's communication through the cellular access network, are moved to 228 the handover target MAG serving the non-cellular access network. 229 Such non-cellular MAG can have an access technology specific 230 controller or function co-located, e.g. a Wireless LAN Controller 231 (WLC), as depicted in option (I) of Figure 1. Alternatively, the 232 access specific architecture can be distributed and the access 233 technology specific control function is not co-located with the MAG, 234 as depicted in option (II). In case of a distributed access network 235 architecture as per option (II), the MAG and the access technology 236 specific control function (e.g. the WLC) must provide some protocol 237 for QoS inter-working. Details of such inter-working are out of 238 scope of this specification. 240 Non-cellular access | Cellular Core Network Cellular 241 (e.g. WLAN) | +--------+ Access 242 | |Policy | 243 | |Control +-----+ 244 | |Function| | 245 +----+ | +---+----+ | 246 |WiFi| (I) | | | 247 | AP |---+ +---+---+ | | | ((O)) 248 +----+ | |WiFi AR| | PMIPv6 +-----+ +---+ | 249 +----+ (MAG) +=|============| LMA |=====|MAG+--| 250 | | WLC | | tunnel +-----+ +---+ | 251 +----+ | +-------+ | // 252 |WiFi|---+ | // 253 | AP | | // 254 +----+ (II) | // 255 +-------+ | // 256 +----+ +------+ |WiFi AR| | // 257 |WiFi+----+ WLC +------+ (MAG) |=|=======// 258 | AP | | | | | | 259 +----+ +------+ +------ + | 260 ^ ^ | 261 | | | 262 +------------+ 263 QoS inter-working 265 Figure 1: Architecture for QoS inter-working between cellular access 266 and non-cellular access 268 Based on the architecture illustrated in Figure 1, two key use cases 269 can be supported by the QoS option. Use case A assumes a MN is 270 attached to the network through cellular access and its LMA has QoS 271 policy rules for the MN's data flows available. This specification 272 does not depend on the approach how the cellular specific QoS 273 policies have been configured on the LMA. During its handover, the 274 available QoS policies are established on the handover target MAG, 275 which serves the non-cellular access network. Use case B assumes 276 that new policies need to be established for a MN as a new IP flow is 277 initiated while the MN is attached to the network through the non- 278 cellular network. These use cases are described in more detail in 279 the subsequent sections Section 3.2 and Section 3.3 respectively. 281 3.2. Use Case A -- Handover of Available QoS Context 283 The MN is first connected to the LTE network and having a multimedia 284 session such as a video call with appropriate QoS parameters set by 285 the policy control function. Then, the MN discovers a WiFi AP (e.g., 286 at home or in a cafe) and switches to it provided that WiFi access 287 has a higher priority when available. Not only is the session 288 continued, but also the QoS is maintained after moving to the WiFi 289 access. In order for that to happen, the LMA delivers the QoS 290 parameters to the MAG on the WLC via the PMIPv6 signaling and the 291 equivalent QoS treatment is provided toward the MN on the WiFi link. 293 +--------+ 294 |Policy | 295 |Control | 296 |Function| 297 +---+----+ 298 | 299 +----+ +-------+ +---+----+ 300 +--+ |LTE |_______| SGW | | PGW | 301 |MN|~~|eNB | | |==============| (LMA) | 302 +--+ +----+ +-------+ //+--------+ 303 : // 304 : // 305 V +----+ +-------+ PMIPv6 // 306 +--+ |WiFi|_______| WLC |========= 307 |MN|~~| AP | | (MAG) | tunnel 308 +--+ +----+ +-------+ 310 Figure 2: Handover Scenario 312 3.3. Use Case B -- Establishment of new QoS Context in non-3G Access 314 A single operator has deployed both a fixed access network and a 315 mobile access network. In this scenario, the operator may wish a 316 harmonized QoS management on both accesses. However the fixed access 317 network does not implement a QoS control framework. So, the operator 318 chooses to rely on the 3GPP policy control function, which is is a 319 standard framework to provide a QoS control, and to enforce the 3GPP 320 QoS policy to the Wi-Fi Access network. The PMIP interface is used 321 to realize this QoS policy provisioning. 323 The use-case is depicted on Figure 3. The MN is first attaching to 324 the Wi-Fi network. During attachment process, the LMA, which may be 325 in communication with Policy Control Function (this step of the 326 process is out of the scope of this document), provides the QoS 327 parameters to the MAG piggy-backing the PMIP signaling (i.e. pBA). 328 Subsequently, an application on the MN may trigger the request for 329 enhanced QoS resources, e.g., by use of the WMM-API [80211e]. The MN 330 may request traffic resources be reserved using L2 signalling, e.g., 331 sending an ADDTS message [80211e]. The request is relayed to the MAG 332 which piggybacks the QoS parameters on the PMIP signalling (i.e. PBU 333 initiated on the flow creation). The LMA, in co-ordination with the 334 PCF, can then authorize the enforcement of such QoS policy. Then, 335 the QoS parameters are provided to the MAG piggy-backing the PMIP 336 signaling and the equivalent QoS treatment is provided towards the MN 337 on the WiFi link. 339 | 340 | 341 | +--------+ 342 | |Policy | 343 | |Control | 344 | |Function| 345 | +---+----+ 346 | | 347 | +---+----+ 348 +----+ +-------+ PMIPv6 | | PGW | 349 +--+ |WiFi|_______| WLC |========|=| (LMA) | 350 |MN|~~| AP | | (MAG) | tunnel | +--------+ 351 +--+ +----+ +-------+ | 352 | 353 Wi-Fi Access | 354 Network | Cellular 355 | Network 356 | 358 Figure 3: QoS policy provisioning 360 3.4. Relevant QoS Attributes 362 The QoS Option shall, at least, contain DSCP values associated with 363 IP flows. Optional QoS information could also be added. For 364 instance, in order to comply with 3GPP networks QoS, at minimum there 365 is a need to convey the following additional QoS parameters for each 366 PMIPv6 mobility session: 368 1. Per Mobile Node Aggregate Maximum Bit Rate (MN-AMBR) to both 369 uplink and downlink directions. 371 2. Per mobility session Aggregate Maximum Bit Rate (MS-AMBR) to both 372 uplink and downlink directions. 374 3. QoS Class Identifier (QCI) mapped to a DSCP. 376 The following QoS parameters are good to negotiate during the session 377 setup: 379 1. Allocation and Retention Priority (ARP). 381 2. Guaranteed Bit Rate (GBR) 383 3. Maximum Bit Rate (MBR) 385 This is the GSMA/3GPP mapping for EPC/LTE: 387 QCI DiffServ PHB DSCP 388 1 EF 101110 389 2 EF 101110 390 3 EF 101110 391 4 AF41 100010 392 5 AF31 011010 393 6 AF32 011100 394 7 AF21 010010 395 8 AF11 001010 396 9 BE 000000 398 3.5. Protocol Operation 399 3.5.1. Handover of existing QoS rules 401 +--+ +--+ +---+ +---+ 402 |MN| |AP| |MAG| |LMA| 403 +--+ +--+ +---+ +---+ 404 || | | To |data 405 |+--detach | | cellular<-==data[DSCP]==-|<---- 406 +----attach-----+ | access [QoS rules] 407 | |-INFO[MNattach]->| | 408 | | |------PBU[handover]------->| 409 | | | | 410 | | |<----PBA[QoS option]-------| 411 | |<-INFO[QoSrules]-| | 412 | | | | 413 | Apply Establish Update 414 | mapped MN's uplink MN's downlink 415 | QoS rules DSCP rules DSCP rules 416 | | +===========================+ 417 | | | | 418 | |(B) |(A) |data 419 |<--data[QC]----|<---data[DSCP]---|<-======data[DSCP]========-|<---- 420 | | | | 421 | | | |data 422 |---data[QC]--->|--->data[DSCP]-->|-=======data[DSCP]=======->|----> 423 | |(C) |(D) | 424 | | | | 426 (A): Apply DSCP at link to AP 427 (B): Enforce mapped QoS rules to access technology 428 (C): Map MN-indicated QoS Class (QC) to DSCP on the AP-MAG link, or 429 validate MN-indicated QC and apply DSCP on the AP.-MAG link 430 according to rule 431 (D): Validate received DSCP and apply DSCP according to rule 433 Figure 4: Handover of QoS rules 435 3.5.2. Establishment of QoS rules 437 +--+ +--+ +---+ +---+ 438 |MN| |AP|-------------|MAG|-----------------------|LMA| 439 +--+ +--+ +---+ +---+ 440 | | | | 441 | | | | 442 +----attached---+ | [QoS rules] 443 | | | | 444 new session | |(F) |data 445 |----data[QC]-->|---data[DSCPa]-->|-======data[DSCPb]=======->|----> 446 | |(E) |--PBU[update, QoS option]->|(C) 447 | | | Validate and 448 | | | add QoS rule 449 | | |<----PBA[QoS option]-------| 450 | |<-INFO[QoSrules]-| [QoS rules'] 451 | | | | 452 | Apply Establish | 453 | adapted MN's uplink | 454 | QoS rules DSCP rules | 455 | | | | 456 | | | | 457 | | | |data 458 |<--data[QC]----|<---data[DSCP]---|<-======data[DSCP]========-|<---- 459 | | | | 460 | | | |data 461 |---data[QC]--->|--->data[DSCP]-->|-=======data[DSCP]=======->|----> 462 | | | | 463 | | | | 465 (E): AP may enforce uplink QoS rules according to priority class 466 set by the MN 467 (F): MAG can enforce a default QoS class until LMA has classified 468 the new flow (notified with PBA) or MAG classifies new flow and 469 proposes the associated QoS class to the LMA for validation 470 (proposed with PBU, notification of validation result with 471 PBA) 473 Figure 5: Adding new QoS profile for MN initiated flow 475 4. Protocol Considerations 477 For supporting this specification, there are protocol extensions 478 needed on both the local mobility anchor and mobile access gateway. 479 The following sections identify those extensions. 481 4.1. Mobile Access Gateway Considerations 483 The conceptual Binding Update List entry data structure maintained by 484 the mobile access gateway, described in Section 6.1 of [RFC5213], 485 MUST be extended to store the QoS parameters received from the local 486 mobility anchor. Specifically, the following parameters must be 487 defined. 489 Flow Selectors 491 DSCP Value 493 List of parameters encoded in TLV format 495 If a mobile access gateway is enabled to support Quality of Service 496 option, upon accepting a Proxy Binding Acknowledgement with Quality 497 of Service option, it SHOULD update the Binding Update List for that 498 mobility session with the quality of service parameters received from 499 the local mobility anchor. However, if the mobile access gateway is 500 not enabled to support Quality of Service option, it SHOULD just skip 501 the option and continue to process the rest of the message. 503 The mobility access gateway SHOULD enforce the Quality of Service 504 rules on the mobile node's uplink and downlink traffic as notified by 505 the local mobility anchor. The traffic selectors in the received 506 Quality of Service option are to be used for the flow identification. 507 The DSCP field in the option along with the other parameters in the 508 QoS Information field are to be used for the flow treatment. 510 In deployments where the mobile access gateway is collocated with a 511 WLAN controller, there is interworking needed between the two 512 functions for exchanging the Quality of Service parameters. The WLAN 513 controller can potentially deliver the Quality of Service parameters 514 to the Access Point/WTP over CAPWAP or other control protocol 515 interface. The specific details on how that is achieved is outside 516 the scope of this document. 518 4.2. Local Mobility Anchor Considerations 520 The conceptual Binding Cache entry data structure maintained by the 521 local mobility anchor, described in Section 5.1 of [RFC5213], MUST be 522 extended to store the Quality of Service parameters received from the 523 local mobility anchor. Specifically, the following parameters must 524 be defined. 526 Flow Selectors 528 DSCP Value 530 List of parameters encoded in TLV format 532 Upon accepting a Proxy Binding Update message [RFC5213] from a mobile 533 access gateway, and if the local mobility anchor is enabled to 534 enforce the Quality of Service rules, it SHOULD construct the Quality 535 of Service mobility option and include it in the Proxy Binding 536 Acknowledgement message. 538 The Quality of Service MUST be constructed as specified in Section 5. 539 The flow selectors and the parameters for flow treatment MUST be 540 included in the option. 542 The local mobility anchor SHOULD enforce the Quality of Service rules 543 on the mobile node's uplink and downlink traffic as specified for 544 that mobility session. The traffic selectors and the associated flow 545 treatment is as specified for that mobility session. 547 5. Quality of Service Option 549 A new option, Quality of Service option, is defined for using it in 550 Proxy Binding Update (PBU) and Proxy Binding Acknowledgement (PBA) 551 messages exchanged between a local mobility anchor and a mobile 552 access gateway. This option is used for providing QoS policies and 553 information to the mobile access gateway. 555 The alignment requirement for this option is 4n. 557 0 1 2 3 558 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Type | Length | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Reserved | DSCP | TS Format | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Traffic Selector ... ~ 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | QoS Information (optional) ~ 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 Figure 6: QoS Option 571 o Type: To be assigned by IANA 573 o Length: 8-bit unsigned integer indicating the length in octets of 574 the option, excluding the type and length fields. 576 o Reserved : This field is unused for now. The value MUST be 577 initialized to 0 by the sender and MUST be ignored by the 578 receiver. 580 o DSCP: An 6-bit unsigned integer indicating the code point value, 581 as defined in [RFC2475] to be used for the flow. 583 o TS Format: An 8-bit unsigned integer indicating the Traffic 584 Selector Format. Value "0" is reserved and MUST NOT be used. The 585 value of (1) is assigned for IPv4 Binary Traffic Selector, as 586 defined in section 3.1 of [RFC6088]. 588 o TS Selector : variable-length opaque field for including the 589 traffic specification identified by the TS format field. 591 o QoS Information: one or more Type-Length-Value (TLV) encoded QoS 592 parameters. This information is optional. The interpretation and 593 usage of the QoS information is specific to the TLV. 595 6. QoS Information Attributes (Type-Length-Values) 597 6.1. Per Mobile Node Aggregate Maximum Downlink Bit Rate 599 The maximum downlink bit rate for a single Mobile Node. The maximum 600 is an aggregate of all mobility session the Mobile Node has. When 601 provided in a request, it indicates the maximum requested bandwidth. 602 When provided in an answer, it indicates the maximum bandwidth 603 accepted. 605 0 1 2 3 606 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Type | Length | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Max-Bandwidth-DL | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 o Type: To be assigned by IANA 615 o Length: The length of following data value in octets. Set to 4. 617 o Max-Bandwidth-DL: is of type unsigned 32 bit integer, and it 618 indicates the maximum bandwidth in bits per second for a downlink 619 IP flow. The bandwidth contains all the overhead coming from the 620 IP-layer and the layers above, e.g. IP, UDP, RTP and RTP payload. 622 6.2. Per Mobile Node Aggregate Maximum Uplink Bit Rate 624 The maximum uplink bit rate for a single Mobile Node. The maximum is 625 an aggregate of all mobility session the Mobile Node has. When 626 provided in a request, it indicates the maximum requested bandwidth. 627 When provided in an answer, it indicates the maximum bandwidth 628 accepted. 630 0 1 2 3 631 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | Type | Length | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Max-Bandwidth-UL | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 o Type: To be assigned by IANA 640 o Length: The length of following data value in octets. Set to 4. 642 o Max-Bandwidth-UL: is of type unsigned 32 bit integer, and it 643 indicates the maximum bandwidth in bits per second for an uplink 644 IP flow. The bandwidth contains all the overhead coming from the 645 IP-layer and the layers above, e.g. IP, UDP, RTP and RTP payload. 647 6.3. Per Mobility Session Aggregate Maximum Downlink Bit Rate 649 The maximum downlink bit rate for a single specific mobility session 650 the Mobile Node has. When provided in a request, it indicates the 651 maximum requested bandwidth. When provided in an answer, it 652 indicates the maximum bandwidth accepted. 654 0 1 2 3 655 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Type | Length | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | Max-Bandwidth-DL | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 o Type: To be assigned by IANA 664 o Length: The length of following data value in octets. Set to 4. 666 o Max-Requested-Bandwidth-DL: is of type unsigned 32 bit integer, 667 and it indicates the maximum bandwidth in bits per second for a 668 downlink IP flow. The bandwidth contains all the overhead coming 669 from the IP-layer and the layers above, e.g. IP, UDP, RTP and RTP 670 payload. 672 6.4. Per Mobility Session Aggregate Maximum Uplink Bit Rate 674 The maximum uplink bit rate for a single specific mobility session 675 the Mobile Node has. When provided in a request, it indicates the 676 maximum requested bandwidth. When provided in an answer, it 677 indicates the maximum bandwidth accepted. 679 0 1 2 3 680 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | Type | Length | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | Max-Bandwidth-UL | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 o Type: To be assigned by IANA 688 o Length: The length of following data value in octets. Set to 4. 690 o Max-Bandwidth-UL: is of type unsigned 32 bit integer, and it 691 indicates the maximum bandwidth in bits per second for an uplink 692 IP flow. The bandwidth contains all the overhead coming from the 693 IP-layer and the layers above, e.g. IP, UDP, RTP and RTP payload. 695 6.5. Allocation and Retention Priority 697 The allocation and retention priority indicate the priority of 698 allocation and retention for the corresponding mobility session. 700 0 1 2 3 701 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Type | Length | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Priority-Level | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Pre-emption-Capability | Pre-emption-Vulnerability | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 o Type: To be assigned by IANA 712 o Length: The length of following data values in octets. Set to 8. 714 o Priority-Level: is of type unsigned 32 bit integer, and it used 715 for deciding whether a mobility session establishment or 716 modification request can be accepted or needs to be rejected in 717 case of resource limitations (typically used for admission control 718 of GBR traffic). The priority-level can also be used to decide 719 which existing mobility session to pre-empt during resource 720 limitations. The priority level defines the relative importance 721 of a resource request. 723 Values 1 to 15 are defined, with value 1 as the highest level of 724 priority. 726 Values 1 to 8 should only be assigned for services that are 727 authorized to receive prioritized treatment within an operator 728 domain. Values 9 to 15 may be assigned to resources that are 729 authorized by the home network and thus applicable when a MN is 730 roaming. 732 o Pre-emption-Capability: defines whether a service data flow can 733 get resources that were already assigned to another service data 734 flow with a lower priority level. The following values are 735 defined: 737 Enabled (0): This value indicates that the service data flow is 738 allowed to get resources that were already assigned to another IP 739 data flow with a lower priority level. 741 Disabled (1): This value indicates that the service data flow is 742 not allowed to get resources that were already assigned to another 743 IP data flow with a lower priority level. 745 o Pre-emption-Vulnerability: defines whether a service data flow can 746 lose the resources assigned to it in order to admit a service data 747 flow with higher priority level. The following values are 748 defined: 750 Enabled (0): This value indicates that the resources assigned to 751 the IP data flow can be pre-empted and allocated to a service data 752 flow with a higher priority level. 754 Disabled (1): This value indicates that the resources assigned to 755 the IP data flow shall not be pre-empted and allocated to a 756 service data flow with a higher priority level. 758 6.6. Guaranteed Downlink Bit Rate 760 The guaranteed downlink bit rate for a single specific mobility 761 session the Mobile Node has. When provided in a request, it 762 indicates the maximum requested bandwidth. When provided in an 763 answer, it indicates the maximum bandwidth accepted. 765 0 1 2 3 766 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | Type | Length | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | Guaranteed-DL | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 o Type: To be assigned by IANA 775 o Length: The length of following data value in octets. Set to 4. 777 o Guaranteed-DL: is of type unsigned 32 bit integer, and it 778 indicates the guaranteed bandwidth in bits per second for downlink 779 IP flows. The bandwidth contains all the overhead coming from the 780 IP-layer and the layers above, e.g. IP, UDP, RTP and RTP payload. 782 6.7. Guaranteed Uplink Bit Rate 784 The guaranteed uplink bit rate for a single specific mobility session 785 the Mobile Node has. When provided in a request, it indicates the 786 maximum requested bandwidth. When provided in an answer, it 787 indicates the maximum bandwidth accepted. 789 0 1 2 3 790 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Type | Length | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | Guaranteed-UL | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 o Type: To be assigned by IANA 799 o Length: The length of following data value in octets. Set to 4. 801 o Guaranteed-UL: is of type unsigned 32 bit integer, and it 802 indicates the guaranteed bandwidth in bits per second for uplink 803 IP flows. The bandwidth contains all the overhead coming from the 804 IP-layer and the layers above, e.g. IP, UDP, RTP and RTP payload. 806 7. IANA Considerations 808 This specification defines a new Mobility Header option, the Quality 809 of Service (QoS) option. The format of this option is described in 810 Section 5. The Type value for this option needs to be assigned from 811 the same numbering space as allocated for the other mobility options 812 [RFC6275]. 814 8. Security Considerations 816 The quality of service option defined in this specification is for 817 use in Proxy Binding Update and Proxy Binding Acknowledgement 818 messages. This option is carried like any other mobility header 819 option as specified in [RFC5213] and does not require any special 820 security considerations. Carrying quality of service information 821 does not introduce any new security vulnerabilities. 823 9. Acknowledgements 825 The authors of this document thank the NetExt Working Group for the 826 valuable feedback on the initial version of this document. In 827 particular the authors want to thank Basavaraj Patil, Behcet Sarikaya 828 and Mark Grayson for their valuable comments and suggestions to 829 improve this specification. 831 10. References 833 10.1. Normative References 835 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 836 Requirement Levels", BCP 14, RFC 2119, March 1997. 838 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 839 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 841 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 842 Mobile IPv6", RFC 5844, May 2010. 844 [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, 845 "Traffic Selectors for Flow Bindings", RFC 6088, 846 January 2011. 848 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 849 in IPv6", RFC 6275, July 2011. 851 10.2. Informative References 853 [80211e] IEEE, "IEEE part 11: Wireless LAN Medium Access 854 Control(MAC) and Physical Layer (PHY) specifications. 855 Amendment 8: Medium Access Control (MAC) Quality of 856 Service Enhancements", 2005. 858 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 859 and W. Weiss, "An Architecture for Differentiated 860 Services", RFC 2475, December 1998. 862 [RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, 863 "Generic Routing Encapsulation (GRE) Key Option for Proxy 864 Mobile IPv6", RFC 5845, June 2010. 866 [RFC5846] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., 867 and P. Yegani, "Binding Revocation for IPv6 Mobility", 868 RFC 5846, June 2010. 870 [TS23.402] 871 3GPP, "Architecture enhancements for non-3GPP accesses", 872 2010. 874 Appendix A. Information when implementing PMIP based QoS support with 875 IEEE 802.11e 877 This section shows, as an example, the end-to-end QoS management with 878 a 802.11e capable WLAN access link and a PMIP based QoS support. 880 The 802.11e, or Wi-Fi Multimedia (WMM), specification provides 881 prioritization of packets for four types of traffic, or access 882 categories (AC): 884 Voice (AC_VO): Very high priority queue with minimum delay. Time- 885 sensitive data such as VoIP and streaming mode are automatically 886 sent to this queue. 888 Video (AC_VI): High priority queue with low delay. Time-sensitive 889 video data is automatically sent to this queue. 891 Best effort (AC_BE): Medium priority queue with medium throughput 892 and delay. Most traditional IP data is sent to this queue. 894 Background (AC_BK): Lowest priority queue with high throughput. 895 Bulk data that requires maximum throughput but is not time- 896 sensitive (for example, FTP data) is sent to the queue. 898 The access point uses the 802.11e indicator to prioritize traffic on 899 the WLAN interface. On the wired side, the access point uses the 900 802.1p priority tag and DiffServ code point (DSCP). To allow 901 consistent QoS management on both wireless and wired interfaces, the 902 access point relies on the 802.11e specification which define mapping 903 between the 802.11e access categories and the IEEE 802.1D priority 904 (802.1p tag). The end-to-end QoS architecture is depicted on 905 Figure 7 and the 802.11e/802.1D priority mapping is reminded in the 906 following table: 908 +-----------+------------------+ 909 | 802.1e AC | 802.1D priority | 910 +-----------+------------------+ 911 | AC_VO | 7,6 | 912 +-----------+------------------+ 913 | AC_VI | 5,4 | 914 +-----------+------------------+ 915 | AC_BE | 0,3 | 916 +-----------+------------------+ 917 | AC_BK | 2,1 | 918 +-----------+------------------+ 920 +=============+ +-----+ 921 DSCP/802.1p | PDP | 922 mapping table +-----+ 923 +=============+ PEP | 924 `._ +---+---+ | 925 `._ |WiFi AR| PMIPv6 +-----+ 926 - + (MAG) +===============| LMA | 927 | WLC | tunnel +-----+ 928 +-------+ PEP 929 | 930 ==Video== 802.11p/DSCP 931 ==Voice== | 932 == B.E.== +----+ 933 +----+ |WLAN| PEP 934 | MN |----802.11e----| AP | 935 +----+ +----+ 937 Figure 7: End-to-end QoS management with 802.11e 939 When receiving a packet from the MN, the AP checks whether the frame 940 contains 802.11e markings in the L2 header. If not, the AP checks 941 the DSCP field. If the uplink packet contains the 802.11e marking, 942 the access point maps the access categories to the corresponding 943 802.1D priority as per the table above. If the frame does not 944 contain 802.11e marking, the access point examines the DSCP field. 945 If DSCP is present, the AP maps DSCP values to a 802.1p value (i.e 946 802.1D priority). This mapping is not standardized and may differ 947 between operator; a mapping example given in the following table. 949 +-------------------+--------+------------+ 950 | Type of traffic | 802.1p | DSCP value | 951 +-------------------+--------+------------+ 952 | Network Control | 7 | 56 | 953 +-------------------+--------+------------+ 954 | Voice | 6 | 46 (EF) | 955 +-------------------+--------+------------+ 956 | Video | 5 | 34 (AF 41) | 957 +-------------------+--------+------------+ 958 | voice control | 4 | 26 (AF 31) | 959 +-------------------+--------+------------+ 960 | Background Gold | 2 | 18 (AF 21) | 961 +-------------------+--------+------------+ 962 | Background Silver | 1 | 10 (AF 11) | 963 +-------------------+--------+------------+ 964 | Best effort | 0,3 | 0 (BE) | 965 +-------------------+--------+------------+ 967 The access point prioritizes ingress traffic on the Ethernet port 968 based on the 802.1p tag or the DSCP value. If 802.1p priority tag is 969 not present, the access point checks the DSCP/802.1p mapping table. 970 The next step is to map the 802.1p priority to the appropriate egress 971 queue. When 802.11e support is enabled on the wireless link, the 972 access point uses the IEEE standardized 802.1p/802.11e correspondence 973 table to map the traffic to the appropriate hardware queues. 975 When the 802.11e capable client sends traffic to the AP, it usually 976 marks packets with a DSCP value. In that case, the MAG/LMA can come 977 into play for QoS renegotiation and call flows depicted in 978 Section 3.5 apply. Sometimes, when communication is initiated on the 979 WLAN access, the application does not mark upstream packets. If the 980 uplink packet does not contain any QoS marking, the AP/MAG could 981 determine the DSCP field according to traffic selectors received from 982 the LMA. Figure 8 gives the call flow corresponding to that use-case 983 and shows where QoS tags mapping does come into play. The main steps 984 are as follows: 986 (A): during MN attachment process, the MAG fetches QoS policies 987 from the LMA. After this step, both MAG and LMA are provisionned 988 with QoS policies. 990 (B): the MN starts a new IP communication without making IP 991 packets with DSCP tags. The MAG uses the traffic selector to 992 determine the DSCP value, then it marks the IP packet and forwards 993 within the PMIP tunnel. 995 (C): the LMA checks the DSCP value with respect to the traffic 996 selector. If the QoS policies is valid, the LMA forwards the 997 packet without renegociate QoS rules. 999 (D): when receiving a marked packet, the MAG, the AP and the MN 1000 use 802.11e (or WMM), 802.11p tags and DSCP values to prioritize 1001 the traffic. 1003 +--+ +--+ +---+ +---+ 1004 |MN| |AP| |MAG| |LMA| 1005 +--+ + -+ +---+ +---+ 1006 (A)|----attach-----|---------------->|-----------PBU---------->| 1007 |<--------------|---------------- |<----PBA[QoS option]-----| 1008 . . [QoS rules] [QoS rules] 1009 (B). . . | 1010 new session | | | 1011 |----data[]---->|---data[]------->|-======data[DSCP]======->| 1012 | | | | 1013 (C)| | | Validate QoS rule 1014 | | | |----> 1015 | | |<======data[DSCP]========|<---- 1016 | | | | 1017 | | mapping | 1018 (D)| | DSCP/802.1p | 1019 | |<----data--------| | 1020 | | [802.1p/DSCP] | | 1021 | | | | 1022 | mapping | 1023 | 802.1p/802.11e | | 1024 |<--data[WMM]---| | | 1025 | | | | 1026 |---data[WMM]-->|-----data------->|=======data[DSCP]=======>|----> 1027 | | [802.1p/DSCP] | | 1028 | | | | 1030 Figure 8: Prioritization of a flow created on the WLAN access 1032 Appendix B. Information when implementing with a Broadband Network 1033 Gateway 1035 This section shows an example of QoS interworking between the PMIPv6 1036 domain and the broadband access. The Broadband Network Gateway (BNG) 1037 or Broadband Remote Access Server (BRAS) has the MAG function and the 1038 CPE (Customer Premise Equipment) or Residential Gateway (RG) is 1039 connected via the broadband access network. The MN is attached to 1040 the RG via e.g., WiFi AP in the broadband home network. In the 1041 segment of the broadband access network, the BNG and RG are the 1042 Policy Enforcement Point (PEP) for the downlink and uplink traffic, 1043 respectively. The QoS information is downloaded from the LMA to the 1044 BNG via the PMIPv6 with the QoS option defined in this document. 1045 Based on the received QoS parameters (e.g., DSCP values), the 1046 broadband access network and the RG provide appropriate QoS treatment 1047 to the downlink and uplink traffic to/from the MN. 1049 +-----+ 1050 | PDP | 1051 +-----+ 1052 PEP | 1053 +-------+ | 1054 | BNG/ | PMIPv6 +-----+ 1055 | BRAS +===============| LMA | 1056 | (MAG) | tunnel +-----+ 1057 +-------+ PEP 1058 Broadband ( | ) 1059 Access ( DSCP ) 1060 Network ( | ) 1061 +-----+ 1062 +----+ | CPE | PEP 1063 | MN |-------------| /RG | 1064 +----+ Broadband +-----+ 1065 Home Network 1067 Figure 9: End-to-end QoS management with the broadband access network 1069 In the segment of the broadband access network, QoS mapping between 1070 3GPP QCI values and DSCP described in Section 3.4 is applied. In the 1071 segment of the broadband home network, if the MN is attached to the 1072 RG via WiFi, the same QoS mapping as described in Appendix A can be 1073 applied. 1075 Authors' Addresses 1077 Marco Liebsch 1078 NEC 1079 Kurfuersten-Anlage 36 1080 Heidelberg D-69115 1081 Germany 1083 Email: liebsch@neclab.eu 1085 Pierrick Seite 1086 France Telecom - Orange 1087 4, rue du Clos Courtel, BP 91226 1088 Cesson-Sevigne 35512 1089 France 1091 Email: pierrick.seite@orange.com 1093 Hidetoshi Yokota 1094 KDDI Lab 1095 2-1-15 Ohara 1096 Saitama, Fujimino 356-8502 1097 Japan 1099 Email: yokota@kddilabs.jp 1101 Jouni Korhonen 1102 Nokia Siemens Networks 1103 Linnoitustie 6 1104 Espoo FI-02600 1105 Finland 1107 Email: jouni.nospam@gmail.com 1109 Sri Gundavelli 1110 Cisco 1111 170 West Tasman Drive 1112 San Jose, CA 95134 1113 USA 1115 Email: sgundave@cisco.com