idnits 2.17.1 draft-ietf-netext-pmip6-qos-11.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 (February 8, 2014) is 3728 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) -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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: August 12, 2014 Orange 6 H. Yokota 7 KDDI Lab 8 J. Korhonen 9 Broadcom Communications 10 S. Gundavelli 11 Cisco 12 February 8, 2014 14 Quality of Service Option for Proxy Mobile IPv6 15 draft-ietf-netext-pmip6-qos-11.txt 17 Abstract 19 This specification defines a new mobility option, the Quality of 20 Service (QoS) option, for Proxy Mobile IPv6. This option can be used 21 by the local mobility anchor and the mobile access gateway for 22 negotiating Quality of Service parameters for a mobile node's IP 23 flows. The negotiated QoS parameters can be used for QoS policing 24 and marking of packets to enforce QoS differentiation on the path 25 between the local mobility anchor and the mobile access gateway. 26 Furthermore, making QoS parameters available on the mobile access 27 gateway enables mapping of these parameters to QoS rules that are 28 specific to the access technology and allows those rules to be 29 enforced on the access network using access technology specific 30 approaches. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on August 12, 2014. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6 69 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6 70 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 72 3. Overview of QoS Support in Proxy Mobile IPv6 . . . . . . . . . 9 73 3.1. Quality of Service Option - Usage Examples . . . . . . . . 11 74 3.2. Quality of Service Attributes - Usage Examples . . . . . . 13 76 4. Protocol Messaging Extensions . . . . . . . . . . . . . . . . 15 77 4.1. Quality of Service Option . . . . . . . . . . . . . . . . 15 78 4.2. Quality of Service Attribute . . . . . . . . . . . . . . . 17 79 4.2.1. Per Mobile Node Aggregate Maximum Downlink Bit Rate . 19 80 4.2.2. Per Mobile Node Aggregate Maximum Uplink Bit Rate . . 20 81 4.2.3. Per Mobility Session Aggregate Maximum Downlink 82 Bit Rate . . . . . . . . . . . . . . . . . . . . . . . 21 83 4.2.4. Per Mobility Session Aggregate Maximum Uplink Bit 84 Rate . . . . . . . . . . . . . . . . . . . . . . . . . 23 85 4.2.5. Allocation and Retention Priority . . . . . . . . . . 25 86 4.2.6. Aggregate Maximum Downlink Bit Rate . . . . . . . . . 26 87 4.2.7. Aggregate Maximum Uplink Bit Rate . . . . . . . . . . 27 88 4.2.8. Guaranteed Downlink Bit Rate . . . . . . . . . . . . . 29 89 4.2.9. Guaranteed Uplink Bit Rate . . . . . . . . . . . . . . 30 90 4.2.10. QoS Traffic Selector . . . . . . . . . . . . . . . . . 31 91 4.2.11. QoS Vendor Specific Attribute . . . . . . . . . . . . 32 92 4.3. New Status Code for Proxy Binding Acknowledgement . . . . 33 93 4.4. New Notification Reason for Update Notification Message . 33 94 4.5. New Status Code for Update Notification 95 Acknowledgement Message . . . . . . . . . . . . . . . . . 33 97 5. Protocol Considerations . . . . . . . . . . . . . . . . . . . 34 98 5.1. Local Mobility Anchor Considerations . . . . . . . . . . . 34 99 5.2. Mobile Access Gateway Considerations . . . . . . . . . . . 38 101 6. QoS Services in Integrated WLAN-3GPP Networks . . . . . . . . 42 102 6.1. Technical Scope and Procedure . . . . . . . . . . . . . . 42 103 6.2. Relevant QoS Attributes . . . . . . . . . . . . . . . . . 44 105 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 107 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 49 109 9. Security Considerations . . . . . . . . . . . . . . . . . . . 51 111 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52 113 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 114 11.1. Normative References . . . . . . . . . . . . . . . . . . . 53 115 11.2. Informative References . . . . . . . . . . . . . . . . . . 53 117 Appendix A. Information when implementing 3GPP QoS in IP 118 transport network . . . . . . . . . . . . . . . . . . 55 119 A.1. Mapping tables . . . . . . . . . . . . . . . . . . . . . . 55 120 A.2. Use cases and protocol operations . . . . . . . . . . . . 56 121 A.2.1. Handover of existing QoS rules . . . . . . . . . . . . 56 122 A.2.2. Establishment of QoS rules . . . . . . . . . . . . . . 58 123 A.2.3. Dynamic Update to QoS Policy . . . . . . . . . . . . . 60 125 Appendix B. Information when implementing PMIP based QoS 126 support with IEEE 802.11e . . . . . . . . . . . . . . 62 128 Appendix C. Information when implementing with a Broadband 129 Network Gateway . . . . . . . . . . . . . . . . . . . 66 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67 133 1. Introduction 135 Mobile operators deploy Proxy Mobile IPv6 (PMIPv6) [RFC5213] to 136 enable network-based mobility management for mobile nodes (MN). 137 Users can access Internet Protocol (IP) based services from their 138 mobile device by using various radio access technologies. Current 139 standardization effort considers strong QoS classification and 140 enforcement for cellular radio access technologies. QoS policies are 141 typically controlled by a policy control function, whereas the 142 policies are enforced by one or more gateways in the infrastructure, 143 such as the local mobility anchor and the mobile access gateway, as 144 well as by access network elements. Policy control and QoS 145 differentiation for access to the mobile operator network through 146 alternative non-cellular access technologies is not yet considered, 147 even though some of these access technologies are able to support QoS 148 by appropriate traffic prioritization techniques. However, handover 149 and IP Flow Mobility using alternative radio access technologies, 150 such as IEEE802.16 and Wireless LAN according to the IEEE802.11 151 specification, are being considered by the standards [TS23.402], 152 whereas inter-working with the cellular architecture to establish QoS 153 policies in alternative access networks has not received much 154 attention so far. 156 In particular Wireless LAN (WLAN) has been identified as an 157 alternative technology to complement cellular radio access. Since 158 the 802.11e extension provides QoS extensions to WLAN, it is 159 beneficial to apply QoS policies to WLAN access, which enables QoS 160 classification of downlink as well as uplink traffic between a mobile 161 node and its local mobility anchor. Three functional operations have 162 been identified to accomplish this: 164 (a) Maintaining QoS classification during a handover between 165 cellular radio access and WLAN access by means of establishing QoS 166 policies in the handover target access network, 168 (b) mapping of QoS classes and associated policies between 169 different access systems and 171 (c) establishment of QoS policies for new data sessions/flows, 172 which are initiated while using WLAN access. 174 This document specifies an extension to the PMIPv6 protocol [RFC5213] 175 to establish QoS policies for a mobile node's data traffic on the 176 local mobility anchor and the mobile access gateway. QoS policies 177 are conveyed in-band with PMIPv6 signaling using the specified QoS 178 option and are enforced on the local mobility anchor for downlink 179 traffic and on the mobile access gateway and its access network for 180 the uplink traffic. The specified option allows association between 181 IP session classification characteristics, such as a Differentiated 182 Services Code Point (DSCP) [RFC2474], and the expected QoS class for 183 this IP session. This document specifies fundamental QoS attributes 184 which apply on a per mobile node, mobility session or on a per-flow 185 basis. The specified attributes are not specific to any access 186 technology, but are compatible with the Third Generation Partnership 187 Project (3GPP) and IEEE 802.11 Wireless LAN QoS specifications. 189 Additional QoS attributes can be specified and used with the QoS 190 option, e.g. to represent more specific descriptions of latency 191 constraints or jitter bounds. The specification of such additional 192 QoS attributes as well as the handling of QoS policies between the 193 mobile access gateway and the access network are out of scope for 194 this specification. 196 2. Conventions and Terminology 198 2.1. Conventions 200 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 201 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 202 document are to be interpreted as described in RFC 2119 [RFC2119]. 204 2.2. Terminology 206 All the mobility related terms used in this document are to be 207 interpreted as defined in the Proxy Mobile IPv6 specifications 208 [RFC5213], [RFC5844], and [RFC7077]. Additionally, this document 209 uses the following abbreviations: 211 Aggregate Maximum Bit Rate (AMBR) 213 AMBR defines the upper limit on the bit-rate that can be provided 214 by the network for a set of IP flows. IP packets exceeding the 215 AMBR limit will be discarded by the rate-shaping function where 216 the AMBR parameter is enforced. Variants of AMBR term can be 217 defined by restricting the target set of IP flows on which the 218 AMBR is applied to a mobile node, mobility session or flow 219 direction. For example, Per Mobile Node Aggregate Maximum 220 Downlink Bit Rate, Per Mobile Node Aggregate Maximum Uplink Bit 221 Rate, Per Mobility Session Aggregate Maximum Downlink Bit Rate and 222 Per Mobility Session Aggregate Maximum Uplink Bit Rate are used in 223 this document. 225 Allocation and Retention Priority (AARP) 227 AARP is used in congestion situations when there are no sufficient 228 resources for meeting all services requests. It is used primarily 229 by the Admission Control function to determine whether a 230 particular service request must be rejected due to lack of 231 resources, or if it must be rejected by preempting an existing 232 low-priority service. 234 Differentiated Services Code Point (DSCP) 236 In Differentiated Services Architecture [RFC2474], packets are 237 classified and marked to receive a particular per-hop forwarding 238 behavior on nodes along their path based on the marking present on 239 the packet. This marking on IPv4 and IPv6 packets that defines a 240 specific Per-hop behavior is known as DSCP. Refer to [RFC2474], 241 [RFC2475] and [RFC4594] for a complete explanation. 243 Downlink (DL) Traffic 244 The mobile node's IP packets that the mobile access gateway 245 receives from the local mobility anchor is referred to as the 246 Downlink traffic. The "Downlink" term used in the QoS attribute 247 definition is always from the reference point of the mobile node 248 and it implies traffic heading towards the mobile node. 250 Guaranteed Bit Rate (GBR) 252 GBR denotes the assured bit-rate that will be provided by the 253 network for a set of IP flows. It is assumed that the network 254 reserves the resources for supporting the GBR parameter. Variants 255 of the GBR term can be defined by limiting the scope of the target 256 IP flows on which the GBR is applied to a mobile node, mobility 257 session or flow direction. For example, Guaranteed Downlink Bit 258 Rate and Guaranteed Uplink Bit Rate are used in this document. 260 Mobility Session 262 The term mobility session, is defined in [RFC5213]. It refers to 263 the creation or existence of state associated with the mobile 264 node's mobility binding on the local mobility anchor and on the 265 mobile access gateway. 267 QoS Service Request 269 A set of QoS parameters that are defined to be enforced on one or 270 more mobile node's IP flows. The parameters at the minimum 271 include a DSCP marking and additionally may include Guaranteed Bit 272 Rate or Aggregate Maximum Bit Rate. The Quality of Service option 273 defined in this document represents a QoS Service Request. 275 Service Identifier 277 In some mobility architectures, multiple services within the same 278 mobility service subscription are offered to a mobile node. Each 279 of those services provide a specific service (examples: Internet 280 Service, Voice Over IP Service) and has an identifier called 281 Service Identifier. 3GPP APN (Access Point Name) is an example of 282 a Service Identifier. Refer to [RFC5149] for the definition of 283 the Service Identifier and the mobility option used for carrying 284 the Service Identifier. 286 Uplink (UL) Traffic 288 The mobile node's IP packets that the mobile access gateway 289 forwards to the local mobility anchor is referred to as the Uplink 290 traffic. The "Uplink" term used in the QoS attribute definitions 291 is based on the reference point of the mobile node and "Uplink" 292 implies traffic originating from the mobile node. 294 3. Overview of QoS Support in Proxy Mobile IPv6 296 The Quality of Service support in Proxy Mobile IPv6 specified in this 297 document is based on the Differentiated-Services architecture 298 ([RFC2474] and [RFC2475]). The access and the home network in the 299 Proxy Mobile IPv6 domain are assumed to be DiffServ enabled, with 300 every network node in the forwarding path for the mobile node's IP 301 traffic being Diffserv compliant. The per-hop behavior for providing 302 differential treatment based on the DiffServ marking in the packet is 303 assumed to be consistent throughout the Proxy Mobile IPv6 domain. 305 The local mobility anchor in the home network and the mobile access 306 gateway in the access network define the network boundary between the 307 access and the home network. These entities being the entry and exit 308 points for the mobile node's IP traffic are the logical choice for 309 being the QoS enforcement points. The basic QoS primitives such as 310 marking, metering, policing and rate-shaping on the mobile node's IP 311 flows can be enforced at these nodes. 313 The local mobility anchor and the mobile access gateway can negotiate 314 the Quality of Service parameters for a mobile node's IP flows based 315 on the signaling extensions defined in this document. The QoS 316 services that can be enabled for a mobile node are for meeting both 317 the quantitative performance requirements (such as Guaranteed Bit- 318 Rate) and as well for realizing relative performance treatment by the 319 ways of class-based differentiation. The subscriber's policy and the 320 charging profile is a key consideration for the mobility entities in 321 the QoS service negotiation. The decision on the type of QoS 322 services that are to be enabled for a mobile node is based on the 323 subscriber profile and based on available network resources. The 324 negotiated QoS parameters are used for providing QoS service 325 differentiation on the path between the local mobility anchor and the 326 mobile access gateway. The signaling related to QoS services is 327 strictly between the mobility entities and does not result in per- 328 flow state, or signaling to any other node in the network. 330 +=======+ 331 | MN-1 | 332 +=======+ 333 | | | Flow-6 334 Flow-1<--(GBR: 64Kbps) | 335 | Flow-4 | 336 Flow-2 | | | 337 | | Flow-1 | | 338 | Flow-3 | | | 339 |_|_| DSCP-X | | | 340 ( )<--(Per-Session-AMBR: 1Mbps) : | | | 341 | | | DSCP-Z : | | | 342 | | : : | | | 343 | | | +=====+ +==:=v+ | | | 344 | '- -- - - - --| | | : o|--' | | 345 | '- - --- - - -| | __ | v o|----' | 346 '- - - - - - - -| | _--' '--_ | o--|------' 347 | | ( Diffserv ) | | 348 | MAG |=====( enabled )=====| LMA | 349 | | (IP Network) | | 350 ,- - - - - - - - -| | '--__--' | o|-- - -, 351 ,- - -- - -- - -| | | o|--- , | 352 | | ,- - - - -- -| | | o|--, | | 353 | | +=====+ +====^+ | | | 354 |_|_| : | | | 355 ( _ _ )<--(Per-Session-AMBR: 2Mbps) : | | | 356 | | | DSCP-Y | | | 357 | | | | | 358 | | | | | | 359 | Flow-6 Flow-2 | | 360 | | | | 361 Flow-5 (MBR: 100Kbps) Flow-3 | 362 | | 363 Flow-4 (GBR: 64Kbps) Flow-5 364 | | | 365 +=======+ 366 | MN-2 | 367 +=======+ 369 Figure 1: QoS Support 371 Figure 1 explains the support of QoS services in a Proxy Mobile IPv6 372 domain. The local mobility anchor and the mobile access gateway have 373 negotiated QoS parameters for the mobility sessions belonging to MN-1 374 and MN-2. A Per-Session-AMBR of 1Mbps and 2 Mbps for MN-1 and MN-2 375 respectively. Furthermore, different IP flows from MN-1 and MN-2 are 376 given different QoS service treatment. For example, a GBR of 64Kbps 377 for Flow-1 and Flow-5 is assured, a DSCP marking enforcement of "Z" 378 on Flow-6, and MBR of 100 Kbps on Flow-5; 380 3.1. Quality of Service Option - Usage Examples 382 Use Case 1: Figure 2 explains a scenario where a local mobility 383 anchor initiates a QoS service request to a mobile access gateway. 385 +-----+ +-----+ +-----+ 386 | MN | | MAG | | LMA | 387 +-----+ +-----+ +-----+ 388 | | | 389 1) |---- MN Attach ----| | 390 2) | |------ PBU ------->| 391 3) | |<----- PBA --------| 392 | | | 393 4) | |o=================o| 394 | | PMIPv6 Tunnel | 395 | | | 396 | (LMA initiates QoS Service Request) | 397 5) | |<----- UPN (QoS)---| 398 | | | 399 | (MAG proposes a revised QoS Request) | 400 6) | |------ UPA (QoS')->| 401 | | | 402 7) | |<----- UPN (QoS')--| 403 8) | |------ UPA (QoS')->| 404 | QoS Rules ---| | 405 9) | Established <-| | QoS Rules ---| 406 10) | ---| Established <-| | 407 | | ---| 408 11) |<----------------->| | 410 Figure 2: LMA Initiated QoS Service Request 412 o (1) to (4): MAG detects the mobile node's attachment to the access 413 link and initiates the signaling with the local mobility anchor. 414 The LMA and MAG upon completing the signaling establish the 415 mobility session and the forwarding state. 417 o (5) to (8): The LMA initiates a QoS Service request to the mobile 418 access gateway. The trigger for this service can be based on a 419 trigger from a policy function and the specific details of that 420 trigger are outside the scope of this document. The LMA sends an 421 Update Notification message [RFC7077] to the MAG. The message 422 includes the QoS option Section 4.1 which includes a set of QoS 423 parameters. The mobile access gateway on determining that it 424 cannot support the requested QoS service request for that mobile 425 sends an revised QoS option in the Update Notification 426 Acknowledgement message, which the LMA agrees to the proposed QoS 427 parameters by sending a new Update Notification message with a 428 modified QoS option. 430 o (9) to (11): Upon successfully negotiating a QoS service request 431 the MAG and the LMA install the QoS rules for that service 432 request. Furthermore, the MAG (using access technology specific 433 mechanisms) install the QoS rules on the access network. 435 Use Case 2: Figure 3 explains a scenario where a mobile access 436 gateway initiates a QoS service request to a local mobility anchor. 438 +-----+ +-----+ +-----+ 439 | MN | | MAG | | LMA | 440 +-----+ +-----+ +-----+ 441 | | | 442 1) |---- MN Attach ----| | 443 2) | |------ PBU ------->| 444 3) | |<----- PBA --------| 445 | | | 446 4) | |o=================o| 447 | | PMIPv6 Tunnel | 448 | | | 449 | (MAG initiates QoS Service Request) | 450 5) | |------ PBU (QoS)-->| 451 6) | |<----- PBA (QoS)---| 452 | QoS Rules ---| | 453 7) | Established <-| | QoS Rules ---| 454 8) | ---| Established <-| | 455 | | ---| 456 9) |<----------------->| | 458 Figure 3: MAG Initiated QoS Service Request 460 o (1) to (4): MAG detects the mobile node's attachment to the access 461 link and initiates the signaling with the local mobility anchor. 462 The LMA and MAG upon completing the signaling establish the 463 mobility session and the forwarding state. 465 o (5) to (6): The MAG initiates a QoS Service request to the local 466 mobility anchor. The trigger for this service can be based on a 467 trigger from the mobile node using access technology specific 468 mechanisms. The specific details of that trigger are outside the 469 scope of this document. The MAG sends a Proxy Binding Update 470 message [RFC5213] to the LMA. The message includes the QoS option 471 Section 4.1 which includes a set of QoS parameters. The LMA 472 agrees to the proposed QoS service request by sending Proxy 473 Binding Acknowledgement message. 475 o (7) to (9): Upon successfully negotiating a QoS service request 476 the MAG and the LMA install the QoS rules for that service 477 request. Furthermore, the MAG using access technology specific 478 mechanisms install the QoS rules on the access network. 480 3.2. Quality of Service Attributes - Usage Examples 482 This section identifies the use-cases where the Quality of Service 483 Option (Section 4.1) and its attributes (Section 4.2) defined in this 484 document are relevant. 486 o The subscription policy offered to a mobile subscriber requires 487 the service provider to enforce Aggregate Maximum Bit Rate (AMBR) 488 limits on the subscriber's IP traffic. The local mobility anchor 489 and the mobile access gateway negotiate the uplink and the 490 downlink AMBR values for the mobility session and enforce them in 491 the access and the home network. The QoS option (Section 4.1) 492 with the QoS Attributes, Per-Session-Agg-Max-DL-Bit-Rate 493 (Section 4.2.3) and Per-Session-Agg-Max-UL-Bit-Rate 494 (Section 4.2.4) are used for this purpose. 496 o In Community Wi-Fi deployments, the residential gateway 497 participating in the Wi-Fi service is shared between the home user 498 and the community Wi-Fi users. In order to ensure the home user's 499 Wi-Fi service is not impacted because of the community Wi-Fi 500 service, the service provider enables Guaranteed Bit Rate (GBR) 501 for the home user's traffic. The QoS option (Section 4.1) with 502 the QoS Attributes, Guaranteed-DL-Bit-Rate (Section 4.2.8), 503 Guaranteed-UL-Bit-Rate (Section 4.2.9) are used for this purpose. 505 o A mobile user using the service provider's Voice over IP 506 infrastructure establishes a VoIP call with some other user in the 507 network. The negotiated call parameters for the VoIP call require 508 a dedicated bandwidth of certain fixed value for the media flows 509 associated with that VoIP session. The Application function in 510 the VoIP infrastructure notifies the local mobility anchor to 511 enforce the GBR limits on that IP flow identified by the flow 512 definition. The QoS option (Section 4.1) with the QoS Attributes, 513 Guaranteed-DL-Bit-Rate (Section 4.2.8), Guaranteed-UL-Bit-Rate 514 (Section 4.2.9), QoS-Traffic-Selector (Section 4.2.10) are used 515 for this purpose. 517 o A service provider is required to ensure the application traffic 518 associated with emergency services is not impacted under any 519 network condition. An emergency service may require network 520 resources in conditions when the network resources have been fully 521 allocated to other users and the network may be experiencing 522 severe congestion and in such cases the service provider may have 523 to revoke resources that have been allocated and be reassigned to 524 emergency services. The local mobility anchor and the mobile 525 access gateway negotiate Allocation and Retention Priority (AARP) 526 values for the IP sessions associated with the emergency 527 applications. The QoS option (Section 4.1) with the QoS 528 Attribute, Allocation-Retention-Priority (Section 4.2.5) are used 529 for this purpose. 531 4. Protocol Messaging Extensions 533 4.1. Quality of Service Option 535 The Quality of Service option is a mobility header option used by 536 local mobility anchor and mobile access gateway for negotiating QoS 537 parameters associated with a mobility session. This option can be 538 carried in Proxy Binding Update (PBU) [RFC5213], Proxy Binding 539 Acknowledgement (PBA) [RFC5213], Update Notification (UPN) [RFC7077] 540 and Update Notification Acknowledgement(UPA) [RFC7077] messages. 541 There can be more than one instance of the Quality of Service option 542 in a single message. Each instance of the Quality of Service option 543 represents a specific QoS service request. 545 The alignment requirement for this option is 4n. 547 0 1 2 3 548 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 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Type | Length | SR-ID | TC | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | OC | Reserved | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 ~ QoS Attribute(s) ~ 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 Figure 4: QoS Option 559 Type 561 563 Length 565 8-bit unsigned integer indicating the length of the option in 566 octets, excluding the Type and Length fields. 568 Service Request Identifier (SR-ID) 570 A 8-bit unsigned integer used for identifying the QoS service 571 request. Its uniqueness is within the scope of a mobility 572 session. The local mobility anchor always allocates the 573 identifier value. When the QoS Service request is initiated by 574 a mobile access gateway, it sets the value to (0) and the local 575 mobility anchor allocates and includes the value in the 576 response. For any QoS service requests initiated by a local 577 mobility anchor, the Service Request Identifier is set to the 578 allocated value. 580 Traffic Class (TC) 582 Traffic Class consists of a 6-bit DSCP field followed by a 583 2-bit reserved field. 585 Differentiated Services Code Point (DSCP) 587 A 6-bit unsigned integer indicating the code point value, as 588 defined in [RFC2475] to be used for the mobile node's IP 589 flows. When this DSCP marking needs to be applied only for 590 a subset of mobile node's IP flows, there will be a Traffic 591 Selector attribute (Section 4.2.10) in the option which 592 provides the flow selectors. In the absence of any such 593 traffic selector attribute, the DSCP marking applies to all 594 the IP flows associated with the mobility session. 596 Two-bit Reserved Field 598 The last two-bits in the Traffic Class field are currently 599 unused. These bits MUST be initialized by the sender to (0) 600 and MUST be ignored by the receiver. 602 Operational Code (OC) 604 One-Octet Operational code indicates the type of QoS request. 606 RESPONSE: (0) 607 Response to a QoS request 609 ALLOCATE: (1) 610 Request to allocate QoS resources 612 DE-ALLOCATE: (2) 613 Request to de-Allocate QoS resources 615 MODIFY: (3) 616 Request to modify QoS parameters for a previously negotiated 617 QoS service request 619 QUERY: (4) 620 Query to list the previously negotiated QoS service requests 621 and that are still active 623 NEGOTIATE: (5) 624 Response to a QoS service request with a counter QoS 625 proposal 627 Reserved: (6) to (255) 628 Currently not used. Receiver MUST ignore the option 629 received with any value in this range. 631 Reserved 633 This field is unused for now. The value MUST be initialized to 634 a value of (0) by the sender and MUST be ignored by the 635 receiver. 637 QoS Attribute(s) 639 Zero or more Type-Length-Value (TLV) encoded QoS Attributes. 640 The format of the QoS attribute is defined in Section 4.2. The 641 interpretation and usage of the QoS attribute is based on the 642 value in the "Type" field. 644 4.2. Quality of Service Attribute 646 This section identifies the format of a Quality of Service attribute. 647 QoS attribute can be included in the Quality of Service option 648 defined in Section 4.1. The latter part of this section identifies 649 the QoS attributes defined by this specification. 651 0 1 2 3 652 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 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | Type | Length | Value ~ 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 Figure 5: Format of a Quality of Service Attribute 659 Type: 8-bit unsigned integer indicating the type of the QoS 660 attribute. This specification reserves the following values. 662 (0) - Reserved 663 This value is reserved and cannot be used 665 (1) - Per-MN-Agg-Max-DL-Bit-Rate 666 This QoS attribute, Per Mobile Node Aggregate Maximum Downlink 667 Bit Rate, is defined in Section 4.2.1. 669 (2) - Per-MN-Agg-Max-UL-Bit-Rate 670 This QoS attribute, Per Mobile Node Aggregate Maximum Uplink 671 Bit Rate, is defined in Section 4.2.2. 673 (3) - Per-Session-Agg-Max-DL-Bit-Rate 674 This QoS attribute, Per Mobility Session Aggregate Maximum 675 Downlink Bit Rate, is defined in Section 4.2.3. 677 (4) - Per-Session-Agg-Max-UL-Bit-Rate 678 This QoS attribute, Per Mobility Session Aggregate Maximum 679 Uplink Bit Rate, is defined in Section 4.2.4. 681 (5) - Allocation-Retention-Priority 682 This QoS attribute, Allocation and Retention Priority, is 683 defined in Section 4.2.5. 685 (6) - Aggregate-Max-DL-Bit-Rate 686 This QoS attribute, Aggregate Maximum Downlink Bit Rate, is 687 defined in Section 4.2.6. 689 (7) - Aggregate-Max-UL-Bit-Rate 690 This QoS attribute, Aggregate Maximum Uplink Bit Rate, is 691 defined in Section 4.2.7. 693 (8) - Guaranteed-DL-Bit-Rate 694 This QoS attribute, Guaranteed Downlink Bit Rate, is defined in 695 Section 4.2.8. 697 (9) - Guaranteed-UL-Bit-Rate 698 This QoS attribute, Guaranteed Uplink Bit Rate, is defined in 699 Section 4.2.9. 701 (10) - QoS-Traffic-Selector 702 This QoS attribute, QoS Traffic Selector, is defined in 703 Section 4.2.10. 705 (11) - QoS-Vendor-Specific-Attribute 706 This QoS attribute, QoS Vendor Specific Attribute, is defined 707 in Section 4.2.11. 709 (12) to (254) - Reserved 710 These values are are reserved for future allocation. 712 (255) - Reserved 713 This value is reserved and cannot be used 715 Length: 8-bit unsigned integer indicating the number of octets 716 needed to encode the Value, excluding the Type and Length fields. 718 Value: The format of this field is based on the Type value. 720 4.2.1. Per Mobile Node Aggregate Maximum Downlink Bit Rate 722 This attribute, Per-MN-Agg-Max-DL-Bit-Rate, represents the maximum 723 downlink bit-rate for a mobile node. It is a variant of the AMBR 724 term defined in Section 2.2. This value is an aggregate across all 725 mobility sessions associated with that mobile node. 727 This attribute can be included in the Quality of Service option 728 defined in Section 4.1 and it is an optional attribute. There can 729 only be a single instance of this attribute present in a QoS option. 731 When this attribute is present in a Proxy Binding Update sent by a 732 mobile access gateway, or in a Update Notification message sent by a 733 local mobility anchor, it indicates the maximum aggregate downlink 734 bit-rate that is being requested for the mobile node at the peer. 736 When this attribute is present in a Proxy Binding Acknowledgement 737 message, or in an Update Notification Acknowledgement message, it 738 indicates the maximum aggregate downlink bit-rate that the peer 739 agrees to offer. 741 If multiple mobility sessions are established for a mobile node, 742 through multiple mobile access gateways and with sessions anchored 743 either on a single local mobility anchor, or when spread out across 744 multiple local mobility anchors, then it depends on the operator's 745 policy and the specific deployment as how the total bandwidth for the 746 mobile node on each MAG-LMA pair is computed. 748 0 1 2 3 749 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 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Type | Length | Reserved | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Per-MN-Agg-Max-DL-Bit-Rate | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 o Type: 1 758 o Length: The length in octets of the attribute, excluding the Type 759 and Length fields. This value is set to (6). 761 o Reserved: This field is unused for now. The value MUST be 762 initialized by the sender to 0 and MUST be ignored by the 763 receiver. 765 o Per-MN-Agg-Max-DL-Bit-Rate: is a 32-bit unsigned integer, and it 766 indicates the aggregate maximum downlink bit-rate that is 767 requested/allocated for all the mobile node's IP flows. The 768 measurement units for Per-MN-Agg-Max-DL-Bit-Rate are bits-per- 769 second. 771 4.2.2. Per Mobile Node Aggregate Maximum Uplink Bit Rate 773 This attribute, Per-MN-Agg-Max-UL-Bit-Rate, represents the maximum 774 uplink bit-rate for the mobile node. It is a variant of the AMBR 775 term defined in Section 2.2. This value is an aggregate across all 776 mobility sessions associated with that mobile node. 778 This attribute can be included in the Quality of Service option 779 defined in Section 4.1 and it is an optional attribute. There can 780 only be a single instance of this attribute present in a QoS option. 782 When this attribute is present in a Proxy Binding Update sent by a 783 mobile access gateway, or in an Update Notification message sent by 784 the local mobility anchor, it indicates the maximum aggregate uplink 785 bit-rate that is being requested for the mobile node at the peer. 787 When this attribute is present in a Proxy Binding Acknowledgement 788 message, or in an Update Notification Acknowledgement message, it 789 indicates the maximum aggregate uplink bit-rate that the peer agrees 790 to offer for that mobile node. 792 If multiple mobility sessions are established for a mobile node, 793 through multiple mobile access gateways and with sessions anchored 794 either on a single local mobility anchor, or when spread out across 795 multiple local mobility anchors, then it depends on the operator's 796 policy and the specific deployment as how the total bandwidth for the 797 mobile node on each MAG-LMA pair is computed. 799 0 1 2 3 800 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 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Type | Length | Reserved | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | Per-MN-Agg-Max-UL-Bit-Rate | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 o Type: 2 809 o Length: The length in octets of the attribute, excluding the Type 810 and Length fields. This value is set to (6). 812 o Reserved: This field is unused for now. The value MUST be 813 initialized by the sender to 0 and MUST be ignored by the 814 receiver. 816 o Per-MN-Agg-Max-UL-Bit-Rate: is of type unsigned 32-bit integer, 817 and it indicates the aggregate maximum uplink bit-rate that is 818 requested/allocated for the mobile node's IP flows. The 819 measurement units for Per-MN-Agg-Max-UL-Bit-Rate are bits-per- 820 second. 822 4.2.3. Per Mobility Session Aggregate Maximum Downlink Bit Rate 824 This attribute, Per-Session-Agg-Max-DL-Bit-Rate, represents the 825 maximum downlink bit-rate for the mobility session. It is a variant 826 of the AMBR term defined in Section 2.2. 828 This attribute can be included in the Quality of Service option 829 defined in Section 4.1 and it is an optional attribute. There can 830 only be a single instance of this attribute present in a QoS option. 832 When this attribute is present in a Proxy Binding Update sent by a 833 mobile access gateway, or in an Update Notification message sent by 834 the local mobility anchor, it indicates the maximum aggregate 835 downlink bit-rate that is being requested for that mobility session. 837 When this attribute is present in a Proxy Binding Acknowledgement 838 message, or in an Update Notification Acknowledgement message, it 839 indicates the maximum aggregate downlink bit-rate that the peer 840 agrees to offer for that mobility session. 842 When a QoS option includes both the Per-Session-Agg-Max-DL-Bit-Rate 843 attribute and the QOS Traffic Selector attribute (Section 4.2.10), 844 then the QOS Traffic Selector attribute does not apply to this 845 attribute. 847 0 1 2 3 848 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 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | Type | Length |S|E| Reserved | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | Per-Session-Agg-Max-DL-Bit-Rate | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 o Type: 3 857 o Length: The length of the attribute in octets, excluding the Type 858 and Length fields. This value is set to (6). 860 o Service (S) flag: This flag is used for extending the scope of the 861 target flows for Per-Session-Agg-Max-DL-Bit-Rate to mobile node's 862 other mobility sessions sharing the same service identifier. 3GPP 863 Access Point Name (APN) is an example of service identifier and 864 that identifier is carried using the Service Selection mobility 865 option [RFC5149]. 867 * When the (S) flag is set to a value of (1), then the Per- 868 Session-Agg-Max-DL-Bit-Rate is measured as an aggregate across 869 all the mobile node's other mobility sessions sharing the same 870 service identifier associated with this mobility session. 872 * When the (S) flag is set to a value of (0), then there is no 873 special effect on the receiver. 875 * The (S) flag MUST NOT be set to a value of (1), when there is 876 no service identifier associated with the mobility session. 878 o Exclude (E) flag: This flag is used to request that some flows be 879 excluded from the target IP flows for which Per-Session-Agg-Max- 880 DL-Bit-Rate is measured. 882 * When the (E) flag is set to a value of (1), then the request is 883 for excluding the IP flows for which Guaranteed-DL-Bit-Rate 884 (Section 4.2.8) is negotiated, from the flows for which Per- 885 Session-Agg-Max-DL-Bit-Rate applies is measured. 887 * When the (E) flag is set to a value of (0), then there is no 888 special effect on the receiver. 890 * When the (S) flag and (E) flag are both set to a value of (1), 891 then the request is for excluding all the IP flows sharing the 892 service identifier associated with this mobility session, from 893 the target flows for which Per-Session-Agg-Max-DL-Bit-Rate is 894 measured. 896 o Reserved: This field is unused for now. The value MUST be 897 initialized by the sender to 0 and MUST be ignored by the 898 receiver. 900 o Per-Session-Agg-Max-DL-Bit-Rate: is a 32-bit unsigned integer, and 901 it indicates the aggregate maximum downlink bit-rate that is 902 requested/allocated for all the IP flows associated with that 903 mobility session. The measurement units for Per-Session-Agg-Max- 904 DL-Bit-Rate are bits-per-second. 906 4.2.4. Per Mobility Session Aggregate Maximum Uplink Bit Rate 908 This attribute, Per-Session-Agg-Max-UL-Bit-Rate, represents the 909 maximum uplink bit-rate for the mobility session. It is a variant of 910 the AMBR term defined in Section 2.2. 912 This attribute can be included in the Quality of Service option 913 defined in Section 4.1 and it is an optional attribute. There can 914 only be a single instance of this attribute present in a QoS option. 916 When this attribute is present in a Proxy Binding Update sent by a 917 mobile access gateway, or in an Update Notification message [RFC7077] 918 sent by the local mobility anchor, it indicates the maximum aggregate 919 uplink bit-rate that is being requested for that mobility session. 921 When this attribute is present in a Proxy Binding Acknowledgement 922 message, or in an Update Notification Acknowledgement [RFC7077] 923 message, it indicates the maximum aggregate uplink bit-rate that the 924 peer agrees to offer for that mobility session. 926 When a QoS option includes both the Per-Session-Agg-Max-UL-Bit-Rate 927 attribute and the QOS Traffic Selector attribute (Section 4.2.10), 928 then the QOS Traffic Selector attribute does not apply to this 929 attribute. 931 0 1 2 3 932 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 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | Type | Length |S|E| Reserved | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | Per-Session-Agg-Max-UL-Bit-Rate | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 o Type: 4 940 o Length: The length of the attribute in octets, excluding the Type 941 and Length fields. This value is set to (6). 943 o Service (S) flag: This flag is used for extending the scope of the 944 target flows for Per-Session-Agg-Max-UL-Bit-Rate to mobile node's 945 other mobility sessions sharing the same service identifier. 3GPP 946 Access Point Name (APN) is an example of service identifier and 947 that identifier is carried using the Service Selection mobility 948 option [RFC5149]. 950 * When the (S) flag is set to a value of (1), then the Per- 951 Session-Agg-Max-UL-Bit-Rate is measured as an aggregate across 952 all the mobile node's other mobility sessions sharing the same 953 service identifier associated with this mobility session. 955 * When the (S) flag is set to a value of (0), then there is no 956 special effect on the receiver. 958 * The (S) flag MUST NOT be set to a value of (1), when there is 959 no service identifier associated with the mobility session. 961 o Exclude (E) flag: This flag is used to request that some flows be 962 excluded from the target IP flows for which Per-Session-Agg-Max- 963 UL-Bit-Rate is measured. 965 * SGS When the (E) flag is set to a value of (1), then the 966 request is for excluding the IP flows for which Guaranteed-UL- 967 Bit-Rate (Section 4.2.9) is negotiated, from the flows for 968 which Per-Session-Agg-Max-UL-Bit-Rate is measured. 970 * When the (E) flag is set to a value of (0), then there is no 971 special effect on the receiver. 973 * When the (S) flag and (E) flag are both set to a value of (1), 974 then the request is for excluding all the IP flows sharing the 975 service identifier associated with this mobility session, from 976 the target flows for which Per-Session-Agg-Max-UL-Bit-Rate is 977 measured. 979 o Reserved: This field is unused for now. The value MUST be 980 initialized by the sender to 0 and MUST be ignored by the 981 receiver. 983 o Per-Session-Agg-Max-UL-Bit-Rate: is a 32-bit unsigned integer, and 984 it indicates the aggregate maximum uplink bit-rate that is 985 requested/allocated for all the IP flows associated with that 986 mobility session. The measurement units for Per-Session-Agg-Max- 987 UL-Bit-Rate are bits-per-second. 989 4.2.5. Allocation and Retention Priority 991 This attribute, Allocation-Retention-Priority, represents allocation 992 and retention priority for the mobility session or a set of IP flows. 993 It is defined in Section 2.2. 995 This attribute can be included in the Quality of Service option 996 defined in Section 4.1 and it is an optional attribute. There can 997 only be a single instance of this attribute present in a QoS option. 999 When the QoS option includes both the Allocation and Retention 1000 Priority attribute and the QOS Traffic Selector attribute 1001 (Section 4.2.8), then the Allocation and Retention Priority attribute 1002 is to be applied at a flow level. The traffic selector in the QOS 1003 Traffic Selector attribute identifies the target flows. 1005 When the QoS option including the Allocation and Retention Priority 1006 attribute does not include the QOS Traffic Selector attribute 1007 (Section 4.2.8), then the Allocation and Retention Priority attribute 1008 is to be applied to all the IP flows associated with that mobility 1009 session. 1011 0 1 2 3 1012 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 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 | Type | Length | Reserved | PL |PC |PV | 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 o Type: 5 1019 o Length: The length of the attribute in octets, excluding the Type 1020 and Length fields. This value is set to (10). 1022 o Reserved: This field is unused for now. The value MUST be 1023 initialized by the sender to 0 and MUST be ignored by the 1024 receiver. 1026 o Priority-Level (PL): is a 4-bit unsigned integer value. It is 1027 used to decide whether a mobility session establishment or 1028 modification request can be accepted; this is typically used for 1029 admission control of Guaranteed Bit Rate traffic in case of 1030 resource limitations. The priority level can also be used to 1031 decide which existing mobility session to pre-empt during resource 1032 limitations. The priority level defines the relative timeliness 1033 of a resource request. 1035 Values 1 to 15 are defined, with value 1 as the highest level of 1036 priority. 1038 Values 1 to 8 should only be assigned for services that are 1039 authorized to receive prioritized treatment within an operator 1040 domain. Values 9 to 15 may be assigned to resources that are 1041 authorized by the home network and thus applicable when a mobile 1042 node is roaming. 1044 o Preemption-Capability (PC): is a 2-bit unsigned integer value. It 1045 defines whether a service data flow can get resources that were 1046 already assigned to another service data flow with a lower 1047 priority level. The following values are defined: 1049 Enabled (0): This value indicates that the service data flow is 1050 allowed to get resources that were already assigned to another IP 1051 data flow with a lower priority level. 1053 Disabled (1): This value indicates that the service data flow is 1054 not allowed to get resources that were already assigned to another 1055 IP data flow with a lower priority level. The values (2) and (3) 1056 are reserved. 1058 o Preemption-Vulnerability (PV): is a 2-bit unsigned integer value. 1059 It defines whether a service data flow can lose the resources 1060 assigned to it in order to admit a service data flow with higher 1061 priority level. The following values are defined: 1063 Enabled (0): This value indicates that the resources assigned to 1064 the IP data flow can be pre-empted and allocated to a service data 1065 flow with a higher priority level. 1067 Disabled (1): This value indicates that the resources assigned to 1068 the IP data flow shall not be pre-empted and allocated to a 1069 service data flow with a higher priority level. The values (2) 1070 and (3) are reserved. 1072 4.2.6. Aggregate Maximum Downlink Bit Rate 1074 This attribute, Aggregate-Max-DL-Bit-Rate, represents the maximum 1075 downlink bit-rate for the mobility session. It is a variant of the 1076 AMBR term defined in Section 2.2. 1078 This attribute can be included in the Quality of Service option 1079 defined in Section 4.1 and it is an optional attribute. There can 1080 only be a single instance of this attribute present in a QoS option. 1082 When this attribute is present in a Proxy Binding Update sent by a 1083 mobile access gateway, or in an Update Notification message sent by 1084 the local mobility anchor, it indicates the maximum aggregate bit- 1085 rate for downlink IP flows that is being requested. 1087 When this attribute is present in a Proxy Binding Acknowledgement 1088 message, or in an Update Notification Acknowledgement message, it 1089 indicates the maximum aggregate downlink bit-rate that the peer 1090 agrees to offer. 1092 When a QoS option includes both the Aggregate-Max-DL-Bit-Rate 1093 attribute and the QOS-Traffic-Selector attribute (Section 4.2.10), 1094 then the Aggregate-Max-DL-Bit-Rate attribute is to be enforced at a 1095 flow level and the traffic selectors present in the QOS-Traffic- 1096 Selector attribute identifies those target flows. 1098 When the QoS option that includes the Aggregate-Max-DL-Bit-Rate 1099 attribute does not include the QOS-Traffic-Selector attribute 1100 (Section 4.2.10), then the Aggregate-Max-DL-Bit-Rate attribute is to 1101 be applied to all the IP flows associated with the mobility session. 1103 0 1 2 3 1104 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 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 | Type | Length | Reserved | 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 | Aggregate-Max-DL-Bit-Rate | 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 o Type: 6 1113 o Length: The length of the attribute in octets, excluding the Type 1114 and Length fields. This value is set to (6). 1116 o Reserved: This field is unused for now. The value MUST be 1117 initialized by the sender to 0 and MUST be ignored by the 1118 receiver. 1120 o Aggregate-Max-DL-Bit-Rate: is a 32-bit unsigned integer, and it 1121 indicates the aggregate maximum downlink bit-rate that is 1122 requested/allocated for downlink IP flows. The measurement units 1123 for Aggregate-Max-DL-Bit-Rate are bits-per-second. 1125 4.2.7. Aggregate Maximum Uplink Bit Rate 1127 This attribute, Aggregate-Max-UL-Bit-Rate, represents the maximum 1128 uplink bit-rate for the mobility session. It is a variant of the 1129 AMBR term defined in Section 2.2. 1131 This attribute can be included in the Quality of Service option 1132 defined in Section 4.1 and it is an optional attribute. There can 1133 only be a single instance of this attribute present in a QoS option. 1135 When this attribute is present in a Proxy Binding Update sent by a 1136 mobile access gateway, or in an Update Notification message sent by 1137 the local mobility anchor, it indicates the maximum aggregate uplink 1138 bit-rate that is being requested. 1140 When this attribute is present in a Proxy Binding Acknowledgement 1141 message, or in an Update Notification Acknowledgement message, it 1142 indicates the maximum aggregate uplink bit-rate that the peer agrees 1143 to offer. 1145 When a QoS option includes both the Aggregate-Max-UL-Bit-Rate 1146 attribute and the QOS-Traffic-Selector attribute (Section 4.2.10), 1147 then the Aggregate-Max-UL-Bit-Rate attribute is to be enforced at a 1148 flow level and the traffic selectors present in the QOS-Traffic- 1149 Selector attribute identifies those target flows. 1151 When the QoS option that includes the Aggregate-Max-UL-Bit-Rate 1152 attribute does not include the QOS-Traffic-Selector attribute 1153 (Section 4.2.10), then the Aggregate-Max-UL-Bit-Rate attribute is to 1154 be applied to all the IP flows associated with the mobility session. 1156 0 1 2 3 1157 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 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 | Type | Length | Reserved | 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1161 | Aggregate-Max-UL-Bit-Rate | 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 o Type: 7 1166 o Length: The length of the attribute in octets, excluding the Type 1167 and Length fields. This value is set to (6). 1169 o Reserved: This field is unused for now. The value MUST be 1170 initialized by the sender to 0 and MUST be ignored by the 1171 receiver. 1173 o Per-Session-Agg-Max-UL-Bit-Rate: is a 32-bit unsigned integer, and 1174 it indicates the aggregate maximum uplink bit-rate that is 1175 requested/allocated for all the IP flows associated with that 1176 mobility session. The measurement units for Aggregate-Max-UL-Bit- 1177 Rate are bits-per-second. 1179 4.2.8. Guaranteed Downlink Bit Rate 1181 This attribute, Guaranteed-DL-Bit-Rate, represents the assured bit- 1182 rate on the downlink path that will be provided for a set of IP flows 1183 associated with a mobility session. It is a variant of the GBR term 1184 defined in Section 2.2. 1186 This attribute can be included in the Quality of Service option 1187 defined in Section 4.1 and it is an optional attribute. There can 1188 only be a single instance of this attribute present in a QoS option. 1190 When this attribute is present in a Proxy Binding Update sent by a 1191 mobile access gateway, or in a Update Notification message sent by 1192 the local mobility anchor, it indicates the guaranteed downlink bit- 1193 rate that is being requested. 1195 When this attribute is present in a Proxy Binding Acknowledgement 1196 message, or in an Update Notification Acknowledgement message, it 1197 indicates the guaranteed downlink bit-rate that the peer agrees to 1198 offer. 1200 When a QoS option includes both the Guaranteed-DL-Bit-Rate attribute 1201 and the QOS-Traffic-Selector attribute (Section 4.2.10), then the 1202 Guaranteed-DL-Bit-Rate attribute is to be enforced at a flow level 1203 and the traffic selectors present in the QOS-Traffic-Selector 1204 attribute identifies those target flows. 1206 When the QoS option that includes the Guaranteed-DL-Bit-Rate 1207 attribute does not include the QOS-Traffic-Selector attribute 1208 (Section 4.2.10), then the Guaranteed-DL-Bit-Rate attribute is to be 1209 applied to all the IP flows associated with the mobility session. 1211 0 1 2 3 1212 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 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1214 | Type | Length | Reserved | 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 | Guaranteed-DL-Bit-Rate | 1217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 o Type: 8 1221 o Length: The length of the attribute in octets, excluding the Type 1222 and Length fields. This value is set to (6). 1224 o Reserved: This field is unused for now. The value MUST be 1225 initialized by the sender to 0 and MUST be ignored by the 1226 receiver. 1228 o Guaranteed-DL-Bit-Rate: is of type unsigned 32-bit integer, and it 1229 indicates the guaranteed bandwidth in bits-per-second for downlink 1230 IP flows. The measurement units for Guaranteed-DL-Bit-Rate are 1231 bits-per-second. 1233 4.2.9. Guaranteed Uplink Bit Rate 1235 This attribute, Guaranteed-UL-Bit-Rate, represents the assured bit- 1236 rate on the uplink path that will be provided for a set of IP flows 1237 associated with a mobility session. It is a variant of the GBR term 1238 defined in Section 2.2. 1240 This attribute can be included in the Quality of Service option 1241 defined in Section 4.1 and it is an optional attribute. There can 1242 only be a single instance of this attribute present in a QoS option. 1244 When this attribute is present in a Proxy Binding Update sent by a 1245 mobile access gateway, or in a Update Notification message sent by 1246 the local mobility anchor, it indicates the guaranteed uplink bit- 1247 rate that is being requested. 1249 When this attribute is present in a Proxy Binding Acknowledgement 1250 message, or in an Update Notification Acknowledgement message, it 1251 indicates the guaranteed uplink bit-rate that the peer agrees to 1252 offer. 1254 When a QoS option includes both the Guaranteed-UL-Bit-Rate attribute 1255 and the QOS-Traffic-Selector attribute (Section 4.2.10), then the 1256 Guaranteed-UL-Bit-Rate attribute is to be enforced at a flow level 1257 and the traffic selectors present in the QOS-Traffic-Selector 1258 attribute identifies those target flows. 1260 When the QoS option that includes the Guaranteed-UL-Bit-Rate 1261 attribute does not include the QOS-Traffic-Selector attribute 1262 (Section 4.2.10), then the Guaranteed-UL-Bit-Rate attribute is to be 1263 applied to all the IP flows associated with the mobility session. 1265 0 1 2 3 1266 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 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 | Type | Length | Reserved | 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 | Guaranteed-UL-Bit-Rate | 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 o Type: 9 1274 o Length: The length of the attribute in octets, excluding the Type 1275 and Length fields. This value is set to (6). 1277 o Reserved: This field is unused for now. The value MUST be 1278 initialized by the sender to 0 and MUST be ignored by the 1279 receiver. 1281 o Guaranteed-UL-Bit-Rate: is of type unsigned 32-bit integer, and it 1282 indicates the guaranteed bandwidth in bits-per-second for uplink 1283 IP flows. The measurement units for Guaranteed-UL-Bit-Rate are 1284 bits-per-second. 1286 4.2.10. QoS Traffic Selector 1288 This attribute, QoS-Traffic-Selector, includes the parameters used to 1289 match packets for a set of IP flows. 1291 This attribute can be included in the Quality of Service option 1292 defined in Section 4.1 and it is an optional attribute. 1294 When a QoS option that includes the QoS-Traffic-Selector also 1295 includes any one or more of the attributes, Allocation-Retention- 1296 Priority (Section 4.2.5), Aggregate-Max-DL-Bit-Rate (Section 4.2.6), 1297 Aggregate-Max-UL-Bit-Rate (Section 4.2.7), Guaranteed-DL-Bit-Rate 1298 (Section 4.2.8), and Guaranteed-UL-Bit-Rate (Section 4.2.9), then 1299 those included attributes are to be enforced at a flow level and the 1300 traffic selectors present in the QoS-Traffic-Selector attribute 1301 identifies those target flows. Furthermore, the DSCP marking in the 1302 QoS option is to be applied only to partial set of mobile node's IP 1303 flows and the traffic selectors present in the QoS-Traffic-Selector 1304 attribute identifies those target flows. 1306 0 1 2 3 1307 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 1308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1309 | Type | Length | Reserved | TS Format | 1310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1311 ~ Traffic Selector ... ~ 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 o Type: 10 1316 o Length: The length of the attribute in octets, excluding the Type 1317 and Length fields. 1319 o Reserved: This field is unused for now. The value MUST be 1320 initialized by the sender to 0 and MUST be ignored by the 1321 receiver. 1323 o TS Format: An 8-bit unsigned integer indicating the Traffic 1324 Selector Format. Value (0) is reserved and MUST NOT be used. 1325 When the value of TS Format field is set to (1), the format that 1326 follows is the IPv4 Binary Traffic Selector specified in section 1327 3.1 of [RFC6088], and when the value of TS Format field is set to 1328 (2), the format that follows is the IPv6 Binary Traffic Selector 1329 specified in section 3.2 of [RFC6088]. 1331 o Traffic Selector: variable-length field for including the traffic 1332 specification identified by the TS format field. 1334 4.2.11. QoS Vendor Specific Attribute 1336 This attribute is used for carrying vendor specific QoS attributes. 1337 The interpretation and the handling of this option is specific to the 1338 vendor implementation. 1340 This attribute can be included in the Quality of Service option 1341 defined in Section 4.1 and it is an optional attribute. There can be 1342 multiple instances of this attribute with different sub-type values 1343 present in a single QoS option. 1345 0 1 2 3 1346 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 1347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1348 | Type | Length | Reserved | 1349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1350 | Vendor ID | 1351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1352 | Sub-Type | ... ~ 1353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1355 o Type: 11 1357 o Length: The length of the attribute in octets, excluding the Type 1358 and Length fields. 1360 o Reserved: This field is unused for now. The value MUST be 1361 initialized by the sender to 0 and MUST be ignored by the 1362 receiver. 1364 o Vendor ID: The Vendor ID is the SMI (Structure of Management 1365 Information) Network Management Private Enterprise Code of the 1366 IANA-maintained Private Enterprise Numbers registry [SMI]. 1368 o Sub-Type: An 8-bit field indicating the type of vendor-specific 1369 information carried in the option. The name space for this Sub- 1370 type is managed by the Vendor identified by the Vendor ID field. 1372 4.3. New Status Code for Proxy Binding Acknowledgement 1374 This document defines the following new Status Code value for use in 1375 Proxy Binding Acknowledgement message. 1377 CANNOT_MEET_QOS_SERVICE_REQUEST (Cannot meet QoS Service Request): 1378 1380 4.4. New Notification Reason for Update Notification Message 1382 This document defines the following new Notification Reason value for 1383 use in Update Notification message. 1385 QOS_SERVICE_REQUEST (QoS Service Requested): 1387 4.5. New Status Code for Update Notification Acknowledgement Message 1389 This document defines the following new Status code value for use in 1390 Update Notification Acknowledgement message. 1392 CANNOT_MEET_QOS_SERVICE_REQUEST (Cannot meet QoS Service Request ): 1393 1395 5. Protocol Considerations 1397 5.1. Local Mobility Anchor Considerations 1399 o The conceptual Binding Cache entry data structure maintained by 1400 the local mobility anchor, described in Section 5.1 of [RFC5213], 1401 can be extended to store a list of negotiated Quality of Service 1402 requests to be enforced. There can be multiple such entries and 1403 entry must include the Service Request Identifier, DSCP value and 1404 the attributes defined in Section Section 4.2. 1406 LMA Receiving a QoS Service Request: 1408 o On receiving a Proxy Binding Update message with one or more 1409 instances of Quality of Service option included in the message, 1410 the local mobility anchor MUST process the option(s) and determine 1411 if the QoS service request for the proposed QoS service request(s) 1412 can be met. Each instance of the Quality of Service option 1413 represents a specific QoS service request. This determination to 1414 accept the request(s) can be based on policy configured on the 1415 local mobility anchor, available network resources, or based on 1416 other considerations. 1418 o If the local mobility anchor can support the proposed QoS service 1419 requests in entirety, then it MUST send a Proxy Binding 1420 Acknowledgement message with a status code value of (0). 1422 * The message MUST include all the Quality of Service option 1423 instances copied (including all the option content) from the 1424 received Proxy Binding Update message. However, if the 1425 Operational Code field in the request is a QUERY, then the 1426 message MUST include all the Quality of Service option(s) 1427 reflecting the currently negotiated QoS service requests for 1428 that mobility session. 1430 * The Operational Code field in each of the Quality of Service 1431 option(s) MUST be set to RESPONSE. 1433 * The local mobility anchor MUST enforce the Quality of Service 1434 rules for all the negotiated QoS service requests on the mobile 1435 node's uplink and downlink traffic. 1437 o If the local mobility anchor cannot support any of the requested 1438 QoS service requests in entirety, then it MUST reject the request 1439 and send a Proxy Binding Acknowledgement message with the status 1440 code value set to CANNOT_MEET_QOS_SERVICE_REQUEST (Cannot meet QoS 1441 Service Request). 1443 * The denial for QoS service request MUST NOT result in removal 1444 of the mobility session for that mobile node. 1446 * The Operational Code field in each of the Quality of Service 1447 option(s) MUST be set to RESPONSE. 1449 * The Proxy Binding Acknowledgement message may include the 1450 Quality of Service option based on the following 1451 considerations. 1453 + If the local mobility anchor cannot support QoS services for 1454 that mobile node, then Quality of Service option MUST NOT be 1455 included in the Proxy Binding Acknowledgement message. This 1456 serves as an indication to the mobile access gateway that 1457 QoS services are not supported for that mobile node. 1459 + If the local mobility anchor can support QoS services for 1460 that mobile node, but for a downgraded/revised QoS service 1461 request, or for a partial set of QoS service requests, then 1462 the updated Quality of Service option(s) MUST be included in 1463 the Proxy Binding Acknowledgement message. This includes 1464 the case, where the Attributes in a QoS option have 1465 conflicting requirements, Ex: Per-Session-Agg-Max-UL-Bit- 1466 Rate is lower than the Guaranteed-UL-Bit-Rate. The contents 1467 of each of the option (including the QoS attributes) MUST 1468 reflect the QoS service parameters that the local mobility 1469 anchor can support for that mobile node. The Operational 1470 Code field in each of the Quality of Service option(s) MUST 1471 be set to NEGOTIATE. This serves as an indication for the 1472 mobile access gateway to resend the Proxy Binding Update 1473 message with the revised QoS parameters. 1475 LMA Sending a QoS Service Request: 1477 o The local mobility anchor, at any time, can initiate a QoS service 1478 request for mobile node, by sending an Update Notification message 1479 [RFC7077]. The Notification Reason in the Update Notification 1480 message MUST be set to a value of QOS_SERVICE_REQUEST and the 1481 Acknowledgement Requested (A) flag set to a value of (1). 1483 * New QoS service request: 1485 + The message MUST include a Quality of Service option with 1486 one or more QoS attributes included in the option. 1488 + The Operational Code field in the Quality of Service option 1489 MUST be set to ALLOCATE. 1491 + The Service Request Identifier MUST be set to a value of 1492 (0). 1494 + The DSCP field in the Traffic Class (TC) field MUST reflect 1495 the requested DSCP value. 1497 * Modification of an existing QoS Service Request: 1499 + The message MUST include a Quality of Service option with 1500 the QoS attributes reflecting the updated values in the 1501 Attributes, and the updated list of Attributes. 1503 + The Operational Code field in the Quality of Service option 1504 MUST be set to MODIFY. 1506 + The Service Request Identifier MUST be set to a value that 1507 was allocated for that QoS service request. 1509 + There can be more than one QOS service request in a single 1510 message, but there MUST be a instance of a Quality of 1511 Service option in the message for each of those service 1512 requests. 1514 * Deletion of an existing QoS Service Request: 1516 + The Operational Code field in the Quality of Service option 1517 MUST be set to DE-ALLOCATE. 1519 + The Service Request Identifier MUST be set to a value that 1520 was allocated for that QoS service request. 1522 + The message MUST include a Quality of Service option with 1523 the QoS attributes reflecting the updated values for the 1524 attributes. 1526 * Query for the previously negotiated QoS Service Requests: 1528 + The Operational Code field in the Quality of Service option 1529 MUST be set to QUERY. 1531 + The Service Request Identifier MUST be set to a value of 1532 (0). 1534 + The message MUST include a single instance of the Quality of 1535 Service option without including any QoS Attributes. 1537 o Handling a Response to the QoS Service Request: 1539 * If the received Update Notification Acknowledgement [RFC7077] 1540 message has the status code field set to value of (0), the 1541 local mobility anchor MUST enforce the Quality of Service rules 1542 for the negotiated QoS parameters on the mobile node's uplink 1543 and downlink traffic. 1545 * If the received Update Notification Acknowledgement message is 1546 with the status code field set to value of 1547 (CANNOT_MEET_QOS_SERVICE_REQUEST), the local mobility anchor 1548 MUST apply the following considerations. 1550 + The denial of QoS service request MUST NOT result in removal 1551 of any of the mobile node's Binding Cache entries. 1553 + If the message did not include any Quality of Service 1554 option(s), then it is an indication from the mobile access 1555 gateway that QoS services are not enabled for the mobile 1556 node. 1558 + If the Operational Code field in the Quality of Service 1559 option is set to a value of NEGOTIATE and the message 1560 includes one or more instances of the Quality of Service 1561 option, but the option contents reflect a downgraded/revised 1562 set of QoS parameters, then the local mobility anchor MAY 1563 choose to agree to proposed QoS service request by resending 1564 a new Proxy Binding Update message with the updated Quality 1565 of Service option. 1567 General Considerations: 1569 o Any time the local mobility anchor removes a mobile node's 1570 mobility session by removing a Binding Cache entry [RFC5213], for 1571 which QoS resources have been previously allocated, those 1572 allocated resources MUST be released. 1574 o Any time the local mobility anchor receives a Proxy Binding Update 1575 with HI hint = 3 (inter-MAG handover), the local mobility anchor 1576 when sending a Proxy Binding Acknowledgement message MUST include 1577 the QoS option(s) for each of the QoS service requests that are 1578 active for that mobile node. This allows the mobile access 1579 gateway to allocate QoS resources on the current path. This is 1580 relevant for the scenario where a mobile node performs an handover 1581 to a new mobile access gateway which is unaware of the previously 1582 negotiated QoS services. 1584 5.2. Mobile Access Gateway Considerations 1586 o The conceptual Binding Update List entry data structure maintained 1587 by the mobile access gateway, described in Section 6.1 of 1588 [RFC5213], can be extended to store a list of negotiated Quality 1589 of Service requests to be enforced. There can be multiple such 1590 entries and entry must include the Service Request Identifier, 1591 DSCP value and the attributes defined in Section Section 4.2. 1593 MAG Receiving a QoS Service Request: 1595 o On receiving a Update Notification message with one or more 1596 instances of Quality of Service option included in the message, 1597 the mobile access gateway MUST process the option(s) and determine 1598 if the QoS service request for the proposed QoS service request(s) 1599 can be met. Each instance of the Quality of Service option 1600 represents a specific QoS service request. This determination to 1601 accept the request(s) can be based on policy configured on the 1602 mobile access gateway, available network resources, or based on 1603 other considerations. 1605 o If the mobile access gateway can support the proposed QoS service 1606 requests in entirety, then it MUST send a an Update Notification 1607 Acknowledgement message with status code value of (0). 1609 * The message MUST include all the Quality of Service option 1610 instances copied (including all the option content) from the 1611 received Update Notification message. However, if the 1612 Operational Code field in the request is a QUERY, then the 1613 message MUST include all the Quality of Service option(s) 1614 reflecting the currently negotiated QoS service requests for 1615 that mobility session. 1617 * The Operational Code field in each of the Quality of Service 1618 option(s) MUST be set to RESPONSE. 1620 * The mobile access gateway MUST enforce the Quality of Service 1621 rules for all the negotiated QoS service requests on the mobile 1622 node's uplink and downlink traffic. 1624 o If the mobile access gateway cannot support any of the requested 1625 QoS service requests in entirety, then it MUST reject the request 1626 and send an Update Notification Acknowledgement message with the 1627 status code set to CANNOT_MEET_QOS_SERVICE_REQUEST (Cannot meet 1628 QoS Service Request). 1630 * The denial for QoS service request MUST NOT result in removal 1631 of the mobility session for that mobile node. 1633 * The Operational Code field in each of the Quality of Service 1634 option(s) MUST be set to RESPONSE. 1636 * The Update Notification Acknowledgement message may include the 1637 Quality of Service option(s) based on the following 1638 considerations. 1640 + If the mobile access gateway cannot support QoS services for 1641 that mobile node, then Quality of Service option MUST NOT be 1642 included in the Update Notification Acknowledgement message. 1643 This serves as an indication to the local mobility anchor 1644 that QoS services are not supported for that mobile node. 1646 + If the mobile access gateway can support QoS services for 1647 that mobile node, but for a downgraded/revised QoS service 1648 request, or for a partial set of QoS service requests, then 1649 the updated Quality of Service option(s) MUST be included in 1650 the Update Notification Acknowledgement message. This 1651 includes the case, where the Attributes in a QoS option have 1652 conflicting requirements, Ex: Per-Session-Agg-Max-UL-Bit- 1653 Rate is lower than the Guaranteed-UL-Bit-Rate. The contents 1654 of each of the option (including the QoS attributes) MUST 1655 reflect the QoS service parameters that the mobile access 1656 gateway can support for that mobile node. The Operational 1657 Code field in each of the Quality of Service option(s) MUST 1658 be set to NEGOTIATE. This serves as an indication to the 1659 local mobility anchor to resend the Update Notification 1660 message with the revised QoS parameters. 1662 MAG Sending a QoS Service Request: 1664 o The mobile access gateway, at any time, can initiate a QoS service 1665 request for a mobile node, by sending a Proxy Binding Update 1666 message. The QoS service request can be initiated as part of the 1667 initial Binding registration, or during binding re-registrations. 1669 * New QoS service request: 1671 + The message MUST include a Quality of Service option with 1672 one or more QoS attributes included in the option. 1674 + The Operational Code field in the Quality of Service option 1675 MUST be set to ALLOCATE. 1677 + The Service Request Identifier MUST be set to a value of 1678 (0). 1680 + The DSCP value in the Traffic Class field MUST reflect the 1681 requested DSCP value. 1683 * Modification of an existing QoS Service Request: 1685 + The message MUST include a Quality of Service option with 1686 the QoS attributes reflecting the updated values in the 1687 Attributes, and the updated list of Attributes. 1689 + The Operational Code field in the Quality of Service option 1690 MUST be set to MODIFY. 1692 + The Service Request Identifier MUST be set to a value that 1693 was allocated for that QoS service request. 1695 + There can be more than one QOS service request in a single 1696 message, but there MUST be a instance of a Quality of 1697 Service option in the message for each of those service 1698 requests. 1700 * Deletion of an existing QoS Service Request: 1702 + The Operational Code field in the Quality of Service option 1703 MUST be set to DE-ALLOCATE. 1705 + The Service Request Identifier MUST be set to a value that 1706 was allocated for that QoS service request. 1708 + The message MUST include a Quality of Service option with 1709 the QoS attributes reflecting the updated values for the 1710 attributes. 1712 * Query for the previously negotiated QoS Service Requests: 1714 + The Operational Code field in the Quality of Service option 1715 MUST be set to QUERY. 1717 + The Service Request Identifier MUST be set to a value of 1718 (0). 1720 + The message MUST include a single instance of the Quality of 1721 Service option without including any QoS Attributes. 1723 o Handling a Response to the QoS Service Request: 1725 * If the received Proxy Binding Acknowledgement message has the 1726 status code field set to a value of (0), the mobile access 1727 gateway MUST enforce the Quality of Service rules for the 1728 negotiated QoS parameters on the mobile node's uplink and 1729 downlink traffic. 1731 * If the received Proxy Binding Acknowledgement message has the 1732 status code field set to a value of 1733 (CANNOT_MEET_QOS_SERVICE_REQUEST), the mobile access gateway 1734 MUST apply the following considerations. 1736 + The denial of QoS service request MUST NOT result in removal 1737 of any of the mobile node's Binding Update list entries. 1739 + If the message did not include any Quality of Service 1740 option(s), then it is an indication from the local mobility 1741 anchor that QoS services are not enabled for the mobile 1742 node. 1744 + If the Operational Code field in the Quality of Service 1745 option is set to a value of NEGOTIATE and the message 1746 includes one or more instances of the Quality of Service 1747 option, but the option contents reflect a downgraded/revised 1748 set of QoS parameters, then the mobile access gateway MAY 1749 choose to agree to proposed QoS service request by resending 1750 a new Proxy Binding Update message with the updated Quality 1751 of Service option. 1753 * General Considerations: 1755 + There can be more than one QOS service request in a single 1756 message, but there MUST be an instance of a Quality of 1757 Service option in the message for each of those service 1758 requests. Furthermore, the DSCP value MUST be different in 1759 each of those requests. 1761 + Any time the mobile access gateway removes a mobile node's 1762 mobility session by removing a Binding Update List entry 1763 [RFC5213], for which QoS resources have been previously 1764 allocated, those allocated resources MUST to be released. 1766 6. QoS Services in Integrated WLAN-3GPP Networks 1768 6.1. Technical Scope and Procedure 1770 The QoS option specified in this document can provide the equivalent 1771 level of QoS information defined in 3GPP, which is used to enforce 1772 QoS policies for IP flows, which have been established while the 1773 mobile node is attached to WLAN access, or moved from 3GPP to WLAN 1774 access. The QoS classification defined by the 3GPP specification is 1775 provided by Differentiated Services techniques in the IP transport 1776 network and translated as appropriate into WLAN QoS specification in 1777 WLAN access, the details of which are described in Appendix A and 1778 Appendix B. 1780 Figure 6 illustrates a generalized architecture where the QoS option 1781 can be used. The QoS policies could be retrieved from a Policy 1782 Control Function (PCF), such as defined in current cellular mobile 1783 communication standards, which aims to assign an appropriate QoS 1784 class to a mobile node's individual flows. Alternatively, more 1785 static and default QoS rules could be made locally available, e.g. on 1786 a local mobility anchor, through administration. 1788 Non-cellular access | Cellular Core Network Cellular 1789 (e.g. WLAN) | (e.g. EPC) Access 1790 | (e.g. 1791 | +-----------+ EUTRAN) 1792 | | PCF | 1793 | |(e.g. PCRF)| 1794 +----+ | +-----+-----+ 1795 |WiFi| (I) | | 1796 | AP |---+ +---+---+ | | ((O)) 1797 +----+ | |WiFi AR| | PMIPv6 +-----+ +---+ | 1798 +----+ (MAG) +=|============| LMA |=====|MAG+--| 1799 | | WLC | | tunnel +-----+ +---+ | 1800 +----+ | +-------+ | // 1801 |WiFi|---+ | // 1802 | AP | | // 1803 +----+ (II) | // 1804 +-------+ | // 1805 +----+ +------+ |WiFi AR| | // 1806 |WiFi+----+ WLC +------+ (MAG) |=|=======// 1807 | AP | | | | | | 1808 +----+ +------+ +------ + | 1809 ^ ^ | 1810 | | | 1811 +------------+ 1812 QoS inter-working 1814 Figure 6: Architecture for QoS inter-working between cellular access 1815 and non-cellular access 1817 During a mobile node's handover from cellular access to non-cellular 1818 access, e.g. a wireless LAN (WLAN) radio access network, the mobile 1819 node's QoS policy rules, as previously established on the local 1820 mobility anchor for the mobile node's communication through the 1821 cellular access network, are moved to the handover target mobile 1822 access gateway serving the non-cellular access network. Such non- 1823 cellular mobile access gateway can have an access technology specific 1824 controller or function co-located, e.g. a Wireless LAN Controller 1825 (WLC), as depicted in option (I) of Figure 6. Alternatively, the 1826 access specific architecture can be distributed and the access 1827 technology specific control function is located external to the 1828 mobile access gateway, as depicted in option (II). In this case, the 1829 mobile access gateway and the access technology specific control 1830 function (e.g. the WLC) must provide some protocol for QoS inter- 1831 working. Details of such inter-working are out of scope of this 1832 specification. 1834 6.2. Relevant QoS Attributes 1836 The QoS Option shall at least contain a DSCP value being associated 1837 with IP flows of a mobility session. The DSCP value should 1838 correspond to the 3GPP QoS Class Index (QCI), which identifies the 1839 type of service in term of QoS characteristics (e.g. conversational 1840 voice, streaming video, signaling, best effort,...); more details on 1841 DSCP and QCI mapping are given on section Appendix A. Optional QoS 1842 information could also be added. For instance, in order to comply 1843 with the bearer model defined in 3GPP [TS23.203], the following QoS 1844 parameters are conveyed for each PMIPv6 mobility session: 1846 o Default, non-GBR bearer (QCI=5-9) 1848 * DSCP={BE,AF11/21/31/32} 1850 * Per-MN AMBR-UL/DL 1852 * Per-Session AMBR-UL/DL {S=1,E=1} 1854 * AARP 1856 APN (Access Point Name) is provided via the Service Selection ID 1857 defined in [RFC5149]. If APN is not interpreted by Wi-Fi AP, the 1858 latter will police only based on Per-MN AMBR-UL/DL (without Per- 1859 Session AMBR-UL/DL) on the Wi-Fi link. 1861 o Dedicated, GBR bearer (QCI=1-4) 1863 * DSCP={EF/AF41} 1865 * GBR-UL/DL 1867 * MBR-UL/DL 1869 * AARP 1871 * TS 1873 Wi-Fi AP will perform the policy enforcement with the minimum bit- 1874 rate=GBR and the maximum bitrate=MBR. 1876 o Dedicated, non-GBR bearer (QCI=5-9) 1878 * DSCP={BE,AF11/21/31/32} 1880 * Per-MN AMBR-UL/DL 1881 * Per-Session AMBR-UL/DL {S=1,E=1} 1883 * AARP 1885 * TS 1887 If APN is not interpreted by Wi-Fi AP, it will police based only 1888 on Per-MN AMBR-UL/DL (without Per-Session AMBR-UL/DL) on the Wi-Fi 1889 link. 1891 If DSCP values follow the 3GPP specification and deployment, the code 1892 point can carry intrinsically additional attributes according to 1893 Figure 7. 1895 For some optional QoS attributes the signaling can differentiate 1896 enforcement per mobility session and per IP flow. For the latter, 1897 the rule associated with the identified flow(s) overrules the 1898 aggregated rules which apply per Mobile Node or per Mobility Session. 1899 Additional attributes can be appended to the QoS option, but their 1900 definition and specification is out of scope of this document and 1901 left to their actual deployment. 1903 7. IANA Considerations 1905 This document requires the following IANA actions. 1907 o Action-1: This specification defines a new mobility option, the 1908 Quality of Service (QoS) option. The format of this option is 1909 described in Section 4.1. The type value for this 1910 mobility option needs to be allocated from the Mobility Options 1911 registry at . 1912 RFC Editor: Please replace in Section 4.1 with the 1913 assigned value and update this section accordingly. 1915 o Action-2: This specification defines a new mobility attribute 1916 format, Quality of Service attribute. The format of this 1917 attribute is described in Section 4.2. This attribute can be 1918 carried in Quality of Service mobility option. The type values 1919 for this attribute needs to be managed by IANA, under the 1920 Registry, Quality of Service Attribute Registry. This registry 1921 should be created under "Mobile IPv6 Parameters" registry at 1922 . This 1923 specification reserves the following type values and all other 1924 values are reserved for future IANA allocations. Approval of new 1925 Quality of Service Attribute type values are to be made through 1926 IANA Expert Review. 1928 +=====+=================================+=================+ 1929 |Value| Description | Reference | 1930 +=====+=================================+=================+ 1931 | 0 | Reserved | | 1932 +=====+===================================================+ 1933 | 1 | Per-MN-Agg-Max-DL-Bit-Rate | | 1934 +=====+===================================================+ 1935 | 2 | Per-MN-Agg-Max-UL-Bit-Rate | | 1936 +=====+===================================================+ 1937 | 3 | Per-Session-Agg-Max-DL-Bit-Rate | | 1938 +=====+===================================================+ 1939 | 4 | Per-Session-Agg-Max-UL-Bit-Rate | | 1940 +=====+===================================================+ 1941 | 5 | Allocation-Retention-Priority | | 1942 +=====+===================================================+ 1943 | 6 | Aggregate-Max-DL-Bit-Rate | | 1944 +=====+===================================================+ 1945 | 7 | Aggregate-Max-UL-Bit-Rate | | 1946 +=====+===================================================+ 1947 | 8 | Guaranteed-DL-Bit-Rate | | 1948 +=====+===================================================+ 1949 | 9 | Guaranteed-UL-Bit-Rate | | 1950 +=====+===================================================+ 1951 | 10 | QoS-Traffic-Selector | | 1952 +=====+===================================================+ 1953 | 11 | QoS-Vendor-Specific-Attribtute | | 1954 +=====+===================================================+ 1955 | 255 | Reserved | | 1956 +=====+===================================================+ 1958 o Action-3: This document defines a new status value, 1959 CANNOT_MEET_QOS_SERVICE_REQUEST () for use in Proxy 1960 Binding Acknowledgement message, as described in Section 4.3. 1961 This value is to be assigned from the "Status Codes" registry at 1962 . The 1963 allocated value has to be greater than 127. RFC Editor: Please 1964 replace in Section 4.3 with the assigned value and update 1965 this section accordingly. 1967 o Action-4: This document defines a new Notification Reason, 1968 QOS_SERVICE_REQUEST () for use in Update Notification 1969 message [RFC7077] as described in Section 4.4. This value is to 1970 be assigned from the "Update Notification Reasons Registry" at 1971 . RFC 1972 Editor: Please replace in Section 4.4 with the assigned 1973 value and update this section accordingly. 1975 o Action-5: This document defines a new Notification Reason, 1976 CANNOT_MEET_QOS_SERVICE_REQUEST () for use in Update 1977 Notification Acknowledgement message [RFC7077] as described in 1978 Section 4.5. This value is to be assigned from the "Update 1979 Notification Acknowledgement Status Registry" at 1980 . RFC 1981 Editor: Please replace in Section 4.5 with the assigned 1982 value and update this section accordingly. 1984 8. Implementation Status 1986 Note to RFC Editor: Please remove this section and the reference to 1987 [RFC6982] before publication. 1989 This section records the status of known implementations of the 1990 protocol defined by this specification at the time of posting of this 1991 Internet-Draft, and is based on a proposal described in [RFC6982]. 1992 The description of implementations in this section is intended to 1993 assist the IETF in its decision processes in progressing drafts to 1994 RFCs. Please note that the listing of any individual implementation 1995 here does not imply endorsement by the IETF. Furthermore, no effort 1996 has been spent to verify the information presented here that was 1997 supplied by IETF contributors. This is not intended as, and must not 1998 be construed to be, a catalog of available implementations or their 1999 features. Readers are advised to note that other implementations may 2000 exist. 2002 According to [RFC6982], "this will allow reviewers and working groups 2003 to assign due consideration to documents that have the benefit of 2004 running code, which may serve as evidence of valuable experimentation 2005 and feedback that have made the implemented protocols more mature. 2006 It is up to the individual working groups to use this information as 2007 they see fit". 2009 Cisco Implementation 2011 Organization: Cisco 2013 Description: QoS Extensions to Cisco IOS-based MAG and LMA 2014 Implementations. Engineering prototype code under development. 2016 Coverage: Support includes QoS signaling from MAG to LMA based on 2017 PBU/PBA and LMA to MAG based on the recently standardized UPN/UPA 2018 messages. Implementation includes only a partial set of QoS 2019 attributes and support for other Attributes is under development. 2020 The QoS option is based on the Vendor-specific mobility option, 2021 but it has all the parameters defined in -07 version of the 2022 document. We have plans to show a demo in the next IETF. 2024 Licensing: Closed. However, cisco has plans to release the MAG 2025 portion of the code for Linux as open source. 2027 Implementation Experience: The feedback from the developer 2028 suggests that the protocol extensions needed for this 2029 specification proved to be reasonably straightforward. Numerous 2030 draft revisions were made based on the questions and comments from 2031 the developer. The effort to most part appears to be around 2032 interfacing with the platform specific QoS features for enforcing 2033 the negotiated QoS parameters for a subscriber's IP session/flows. 2034 On Cisco IOS, there is a programmatic interface with rich 2035 semantics for interfacing with IOS MQC. It needs to be seen as 2036 how this can be realized on a Linux OS. 2038 Contact: Sri Gundavelli (sgundave@cisco.com) 2040 9. Security Considerations 2042 The quality of service option defined in this specification is for 2043 use in Proxy Binding Update, Proxy Binding Acknowledgement, Update 2044 Notification, and Update Notification Acknowledgement messages. This 2045 option is carried in these message like any other mobility header 2046 option. [RFC5213] and [RFC7077] identify the security considerations 2047 for these signaling messages. The quality of service option when 2048 included in these signaling messages does not require additional 2049 security considerations. 2051 10. Acknowledgements 2053 The authors of this document thank the NetExt Working Group for the 2054 valuable feedback to different versions of this specification. In 2055 particular the authors want to thank Basavaraj Patil, Behcet 2056 Sarikaya, Charles Perkins, Dirk von Hugo, Mark Grayson, Tricci So, 2057 Ahmad Muhanna, Pete McCann, Byju Pularikkal, John Kaippallimalil, 2058 Rajesh Pazhyannur, Carlos J. Bernardos Cano, Michal Hoeft, Ryuji 2059 Wakikawa, Liu Dapeng, Seil Jeon, Georgios Karagiannis and Brian 2060 Haberman for their valuable comments and suggestions to improve this 2061 specification. 2063 11. References 2065 11.1. Normative References 2067 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2068 Requirement Levels", BCP 14, RFC 2119, March 1997. 2070 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 2071 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 2073 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 2074 Mobile IPv6", RFC 5844, May 2010. 2076 [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, 2077 "Traffic Selectors for Flow Bindings", RFC 6088, 2078 January 2011. 2080 [RFC7077] Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and 2081 J. Korhonen, "Update Notifications for Proxy Mobile IPv6", 2082 RFC 7077, November 2013. 2084 11.2. Informative References 2086 [GSMA.IR.34] 2087 GSMA, "Inter-Service Provider IP Backbone Guidelines 5.0", 2088 May 2013. 2090 [IEEE802.11-2012] 2091 IEEE, "Part 11: Wireless LAN Medium Access Control(MAC) 2092 and Physical Layer (PHY) specifications", 2012. 2094 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2095 "Definition of the Differentiated Services Field (DS 2096 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2097 December 1998. 2099 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 2100 and W. Weiss, "An Architecture for Differentiated 2101 Services", RFC 2475, December 1998. 2103 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 2104 Guidelines for DiffServ Service Classes", RFC 4594, 2105 August 2006. 2107 [RFC5149] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service 2108 Selection for Mobile IPv6", RFC 5149, February 2008. 2110 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 2111 Code: The Implementation Status Section", RFC 6982, 2112 July 2013. 2114 [SMI] IANA, "PRIVATE ENTERPRISE NUMBERS", SMI Network Management 2115 Private Enterprise Codes, February 2011. 2117 [TS23.203] 2118 3GPP, "Policy and charging control architecture", 2013. 2120 [TS23.402] 2121 3GPP, "Architecture enhancements for non-3GPP accesses", 2122 2010. 2124 Appendix A. Information when implementing 3GPP QoS in IP transport 2125 network 2127 A.1. Mapping tables 2129 Mapping between 3GPP QCI values and DSCP is defined in [GSMA.IR.34] 2130 as follows. 2132 +=====+================+===========================+======+ 2133 | QCI | Traffic Class | DiffServ Per-Hop-Behavior | DSCP | 2134 +=====+================+===========================+======+ 2135 | 1 | Conversational | EF |101110| 2136 +=====+===================================================+ 2137 | 2 | Conversational | EF |101110| 2138 +=====+===================================================+ 2139 | 3 | Conversational | EF |101110| 2140 +=====+===================================================+ 2141 | 4 | Streaming | AF41 |100010| 2142 +=====+===================================================+ 2143 | 5 | Interactive | AF31 |011010| 2144 +=====+===================================================+ 2145 | 6 | Interactive | AF32 |011100| 2146 +=====+===================================================+ 2147 | 7 | Interactive | AF21 |010010| 2148 +=====+===================================================+ 2149 | 8 | Interactive | AF11 |001010| 2150 +=====+===================================================+ 2151 | 9 | Background | BE |000000| 2152 +=====+===================================================+ 2154 Figure 7: QCI/DSCP Mapping Table 2156 Mapping between QoS attributes defined in this document and 3GPP QoS 2157 parameters is as follows. 2159 +=======+===============================+=============+ 2160 |Section| PMIPv6 QoS | 3GPP QoS | 2161 | | Attribute | Parameter | 2162 +=======+===============================+=============+ 2163 | 4.2.1 | Per-MN-Agg-Max-DL-Bit-Rate | UE AMBR-DL | 2164 +-------+-------------------------------+-------------+ 2165 | 4.2.2 | Per-MN-Agg-Max-UL-Bit-Rate | UE AMBR-UL | 2166 +-------+-------------------------------+-------------+ 2167 | 4.2.3 |Per-Session-Agg-Max-DL-Bit-Rate| APN AMBR-DL | 2168 | | Flags: (S=1, E=1) | | 2169 +-------+-------------------------------+-------------+ 2170 | 4.2.4 |Per-Session-Agg-Max-UL-Bit-Rate| APN AMBR-UL | 2171 | | Flags: (S=1, E=1) | | 2172 +-------+-------------------------------+-------------+ 2173 | 4.2.5 | Allocation-Retention-Priority | ARP | 2174 +-------+-------------------------------+-------------+ 2175 | 4.2.6 | Aggregate-Max-DL-Bit-Rate | MBR-DL | 2176 +-------+-------------------------------+-------------+ 2177 | 4.2.7 | Aggregate-Max-UL-Bit-Rate | MBR-UL | 2178 +-------+-------------------------------+-------------+ 2179 | 4.2.8 | Guaranteed-DL-Bit-Rate | GBR-DL | 2180 +-------+-------------------------------+-------------+ 2181 | 4.2.9 | Guaranteed-UL-Bit-Rate | GBR-UL | 2182 +-------+-------------------------------+-------------+ 2183 | 4.2.10| QoS-Traffic-Selector | TFT | 2184 +-------+-------------------------------+-------------+ 2186 Figure 8: QoS attributes and 3GPP QoS parameters Mapping Table 2188 A.2. Use cases and protocol operations 2190 This subsections provide example message flow charts for scenarios 2191 where the QoS option extensions will apply as described in 2192 (Section 6.1), to the protocol operation for QoS rules establishment 2193 as shown in Appendix A.2.1 and Appendix A.2.2, and modification as 2194 show in Appendix A.2.3. 2196 A.2.1. Handover of existing QoS rules 2198 In Figure 9, the MN is first connected to the LTE network, and having 2199 a multimedia session such as a video call with appropriate QoS 2200 parameters set by the Policy Control Function. Then, the MN 2201 discovers a Wi-Fi AP (e.g., at home or in a cafe) and switches to it 2202 provided that Wi-Fi access has a higher priority when available. Not 2203 only is the session continued, but also the QoS is maintained after 2204 moving to the Wi-Fi access. In order for that to happen, the LMA 2205 delivers the QoS parameters according to the bearer type on the 3GPP 2206 access to the MAG via the PMIPv6 signaling with the QoS option 2207 (OC=ALLOCATE, SR-ID, QoS attributes, etc.). The equivalent QoS 2208 treatment is provided by the Wi-Fi AP toward the MN on the Wi-Fi 2209 link. 2211 +--------+ 2212 |Policy | 2213 |Control | 2214 |Function| 2215 +---+----+ 2216 | 2217 +----+ +-------+ +---+----+ 2218 +--+ |LTE |_______| SGW | | PGW | 2219 |MN|~~|eNB | | |==============| (LMA) | 2220 +--+ +----+ +-------+ //+--------+ 2221 : // 2222 : // 2223 V +----+ +-------+ PMIPv6 // 2224 +--+ |WiFi|_______| WLC |========= 2225 |MN|~~| AP | | (MAG) | tunnel 2226 +--+ +----+ +-------+ 2228 Figure 9: Handover Scenario (from LTE to WLAN) 2230 Figure 10 shows an example of how the QoS rules can be conveyed and 2231 enforced between the LMA and MN in the case of handover from 3GPP 2232 access to WLAN access. 2234 +--+ +--+ +---+ +---+ 2235 |MN| |AP| |MAG| |LMA| 2236 +--+ +--+ +---+ +---+ 2237 || | | To |data 2238 |+--detach | | cellular<-==data[DSCP]==-|<---- 2239 +----attach-----+ | access [QoS rules] 2240 | |-INFO[MNattach]->| | 2241 | | |-------PBU[handover]------>| 2242 | | | | 2243 | | |<--PBA[QoS option(OC=1 )]--| 2244 | |<-INFO[QoSrules]-| | 2245 | | | | 2246 | Apply Establish Update 2247 | mapped MN's uplink MN's downlink 2248 | QoS rules DSCP rules DSCP rules 2249 | | +===========================+ 2250 | | | | 2251 | |(B) |(A) |data 2252 |<--data[QC]----|<---data[DSCP]---|<-======data[DSCP]========-|<---- 2253 | | | | 2254 | | | |data 2255 |---data[QC]--->|-->data[DSCP]--->|-=======data[DSCP]=======->|---> 2256 | |(C) |(D) | 2257 | | | | 2259 (A): Apply DSCP at link to AP 2260 (B): Enforce mapped QoS rules to access technology 2261 (C): Map MN-indicated QoS Class (QC) to DSCP on the AP-MAG link, or 2262 validate MN-indicated QC and apply DSCP on the AP-MAG link 2263 according to QoS rules 2264 (D): Validate received DSCP and apply DSCP according to QoS rules 2266 Figure 10: Handover of QoS rules 2268 A.2.2. Establishment of QoS rules 2270 A single operator has deployed both a fixed access network and a 2271 mobile access network. In this scenario, the operator may wish a 2272 harmonized QoS management on both accesses, but the fixed access 2273 network does not implement a QoS control framework. So, the operator 2274 chooses to rely on the 3GPP policy control function, which is a 2275 standard framework to provide a QoS control, and to enforce the 3GPP 2276 QoS policy on the Wi-Fi Access network. The PMIP interface is used 2277 to realize this QoS policy provisioning. 2279 The use-case is depicted on Figure 11. The MN first attaches to the 2280 Wi-Fi network. During the attachment process, the LMA, which may 2281 communicate with Policy Control Function (using procedures outside 2282 the scope of this document), provides the QoS parameters to the MAG 2283 via the QoS option (OC=ALLOCATE) in the PMIP signaling (i.e. PBA). 2284 Subsequently, an application on the MN may trigger the request for 2285 alternative QoS resources, e.g., by use of the WMM-API. The MN may 2286 request traffic resources be reserved using L2 signaling, e.g., 2287 sending an ADDTS message [IEEE802.11-2012]. The request is relayed 2288 to the MAG which includes the QoS parameters in the QoS option 2289 (OC=ALLOCATE) on the PMIP signaling (i.e. the PBU initiated upon flow 2290 creation). The LMA, in co-ordination with the PCF, can then 2291 authorize the enforcement of such QoS policy. Then, the QoS 2292 parameters are provided to the MAG via the QoS option (OC=ALLOCATE, 2293 SR-ID, QoS attributes, etc.) in the PMIP signaling and the equivalent 2294 QoS treatment is provided towards the MN on the Wi-Fi link. 2296 | 2297 | 2298 | +--------+ 2299 | |Policy | 2300 | |Control | 2301 | |Function| 2302 | +---+----+ 2303 | | 2304 | +---+----+ 2305 +----+ +-------+ PMIPv6 | | PGW | 2306 +--+ |WiFi|_______| WLC |========|=| (LMA) | 2307 |MN|~~| AP | | (MAG) | tunnel | +--------+ 2308 +--+ +----+ +-------+ | 2309 | 2310 Wi-Fi Access | 2311 Network | Cellular 2312 | Network 2313 | 2315 Figure 11: QoS policy provisioning 2317 Figure 12 shows an example of how the QoS rules can be conveyed and 2318 enforced between the LMA and MN in the case of initial attachment to 2319 WLAN access. 2321 +--+ +--+ +---+ +---+ 2322 |MN| |AP|-------------|MAG|-----------------------|LMA| 2323 +--+ +--+ +---+ +---+ 2324 | | | | 2325 | | | | 2326 +----attached---+ | [QoS rules] 2327 | | | | 2328 new session |(E) |(F) |data 2329 |----data[QC]-->|---data[DSCPa]-->|-======data[DSCPb]=======->|---> 2330 | | |--PBU[update,QoS option]-->| 2331 | | | (ReReg) (OC=1) Validate and 2332 | | | add QoS rule 2333 | | |<----PBA[QoS option]----| 2334 | |<-INFO[QoSrules]-| (OC=1, SR-ID)[QoS rules'] 2335 | | | | 2336 | Apply Establish | 2337 | adapted MN's uplink | 2338 | QoS rules DSCP rules | 2339 | | | | 2340 | | | | 2341 | | | |data 2342 |<--data[QC]----|<---data[DSCP]---|<-======data[DSCP]========-|<---- 2343 | | | | 2344 | | | |data 2345 |---data[QC]--->|-->data[DSCP]--->|-=======data[DSCP]=======->|---> 2346 | | | | 2347 | | | | 2349 (E): AP may enforce uplink QoS rules according to priority class 2350 set by the MN 2351 (F): MAG can enforce a default QoS class until local mobility anchor 2352 has classified the new flow (notified with PBA) or mobile 2353 access gateway classifies new flow and proposes the associated 2354 QoS class to the local mobility anchor for validation (proposed 2355 with PBU, notification of validation result with PBA) 2357 Figure 12: Adding new QoS Service Request for MN initiated flow 2359 A.2.3. Dynamic Update to QoS Policy 2361 A mobile node is attached to the WLAN access and has obtained QoS 2362 parameters from the LMA for that mobility session. Having obtained 2363 the QoS parameters, a new application, e.g. IMS application, gets 2364 launched on the mobile node that requires certain QoS support. 2366 The application on the mobile node initiates the communications via a 2367 dedicated network function (e.g. IMS Call Session Control Function). 2369 Once the communication is established, the application network 2370 function notifies the PCF about the new IP flow. The PCF function in 2371 turn notifies the LMA about the needed QoS parameters identifying the 2372 IP flow and QoS parameters. LMA sends an Update Notification message 2373 [RFC7077] to the MAG with the Notification Reason value set to 2374 "QOS_SERVICE_REQUEST". The MAG, on receiving the Update Notification 2375 message, completes the PBU/PBA signaling for obtaining the new QoS 2376 parameters via the QoS options (OC=MODIFY, SR-ID, QoS attributes, 2377 etc.). The MAG provisions the newly obtained QoS parameters on the 2378 access network to ensure the newly established IP flow gets its 2379 requested network resources. 2381 Upon termination of the established IP flow, the application network 2382 function again notifies the PCF function for removing the established 2383 QoS parameters. The PCF notifies the LMA for withdrawing the QoS 2384 resources established for that voice flow. The LMA sends an Update 2385 Notification message to the MAG with the "Notification Reason" value 2386 set to "FORCE-REREGISTRATION". The MAG on receiving this message 2387 Update Notification Acknowledgement and completes the PBU/PBA 2388 signaling for removing the existing QoS rules (OC=DE-ALLOCATE, 2389 SR-ID). The MAG then removes the QoS parameters from the 2390 corresponding IP flow and releases the dedicated network resources on 2391 the access network. 2393 Appendix B. Information when implementing PMIP based QoS support with 2394 IEEE 802.11e 2396 This section shows, as an example, the end-to-end QoS management with 2397 a 802.11e capable WLAN access link and a PMIP based QoS support. 2399 The 802.11e, or Wi-Fi Multimedia (WMM), specification provides 2400 prioritization of packets for four types of traffic, or access 2401 categories (AC): 2403 Voice (AC_VO): Very high priority queue with minimum delay. Time- 2404 sensitive data such as VoIP and streaming mode are automatically 2405 sent to this queue. 2407 Video (AC_VI): High priority queue with low delay. Time-sensitive 2408 video data is automatically sent to this queue. 2410 Best effort (AC_BE): Medium priority queue with medium throughput 2411 and delay. Most traditional IP data is sent to this queue. 2413 Background (AC_BK): Lowest priority queue with high throughput. 2414 Bulk data that requires maximum throughput but is not time- 2415 sensitive (for example, FTP data) is sent to the queue. 2417 The access point uses the 802.11e indicator to prioritize traffic on 2418 the WLAN interface. On the wired side, the access point uses the 2419 802.1p priority tag and DiffServ code point (DSCP). To allow 2420 consistent QoS management on both wireless and wired interfaces, the 2421 access point relies on the 802.11e specification which define mapping 2422 between the 802.11e access categories and the IEEE 802.1D priority 2423 (802.1p tag). The end-to-end QoS architecture is depicted on 2424 Figure 13 and the 802.11e/802.1D priority mapping is reminded in the 2425 following table: 2427 +-----------+------------------+ 2428 | 802.1e AC | 802.1D priority | 2429 +-----------+------------------+ 2430 | AC_VO | 7,6 | 2431 +-----------+------------------+ 2432 | AC_VI | 5,4 | 2433 +-----------+------------------+ 2434 | AC_BE | 0,3 | 2435 +-----------+------------------+ 2436 | AC_BK | 2,1 | 2437 +-----------+------------------+ 2439 +=============+ +-----+ 2440 DSCP/802.1p | PDP | 2441 mapping table +-----+ 2442 +=============+ PEP | 2443 `._ +---+---+ | 2444 `._ |WiFi AR| PMIPv6 +-----+ 2445 - + (MAG) +===============| LMA | 2446 | WLC | tunnel +-----+ 2447 +-------+ PEP 2448 | 2449 ==Video== 802.1p/DSCP 2450 ==Voice== | 2451 == B.E.== +----+ 2452 +----+ |WLAN| PEP 2453 | MN |----802.11e----| AP | 2454 +----+ +----+ 2456 Figure 13: End-to-end QoS management with 802.11e 2458 When receiving a packet from the MN, the AP checks whether the frame 2459 contains 802.11e markings in the L2 header. If not, the AP checks 2460 the DSCP field. If the uplink packet contains the 802.11e marking, 2461 the access point maps the access categories to the corresponding 2462 802.1D priority as per the table above. If the frame does not 2463 contain 802.11e marking, the access point examines the DSCP field. 2464 If DSCP is present, the AP maps DSCP values to a 802.1p value (i.e 2465 802.1D priority). This mapping is not standardized and may differ 2466 between operator; a mapping example given in the following table. 2468 +-------------------+--------+------------+ 2469 | Type of traffic | 802.1p | DSCP value | 2470 +-------------------+--------+------------+ 2471 | Network Control | 7 | 56 | 2472 +-------------------+--------+------------+ 2473 | Voice | 6 | 46 (EF) | 2474 +-------------------+--------+------------+ 2475 | Video | 5 | 34 (AF 41) | 2476 +-------------------+--------+------------+ 2477 | voice control | 4 | 26 (AF 31) | 2478 +-------------------+--------+------------+ 2479 | Background Gold | 2 | 18 (AF 21) | 2480 +-------------------+--------+------------+ 2481 | Background Silver | 1 | 10 (AF 11) | 2482 +-------------------+--------+------------+ 2483 | Best effort | 0,3 | 0 (BE) | 2484 +-------------------+--------+------------+ 2486 The access point prioritizes ingress traffic on the Ethernet port 2487 based on the 802.1p tag or the DSCP value. If 802.1p priority tag is 2488 not present, the access point checks the DSCP/802.1p mapping table. 2489 The next step is to map the 802.1p priority to the appropriate egress 2490 queue. When 802.11e support is enabled on the wireless link, the 2491 access point uses the IEEE standardized 802.1p/802.11e correspondence 2492 table to map the traffic to the appropriate hardware queues. 2494 When the 802.11e capable client sends traffic to the AP, it usually 2495 marks packets with a DSCP value. In that case, the MAG/LMA can come 2496 into play for QoS renegotiation and call flows depicted in Appendix A 2497 apply. Sometimes, when communication is initiated on the WLAN 2498 access, the application does not mark upstream packets. If the 2499 uplink packet does not contain any QoS marking, the AP/MAG could 2500 determine the DSCP field according to traffic selectors received from 2501 the LMA. Figure 14 gives the call flow corresponding to that use- 2502 case and shows where QoS tags mapping does come into play. The main 2503 steps are as follows: 2505 (A): during MN attachment process, the MAG fetches QoS policies 2506 from the LMA. After this step, both MAG and LMA are provisioned 2507 with QoS policies. 2509 (B): the MN starts a new IP communication without making IP 2510 packets with DSCP tags. The MAG uses the traffic selector to 2511 determine the DSCP value, then it marks the IP packet and forwards 2512 within the PMIP tunnel. 2514 (C): the LMA checks the DSCP value with respect to the traffic 2515 selector. If the QoS policies is valid, the LMA forwards the 2516 packet without renegotiating the QoS rules. 2518 (D): when receiving a marked packet, the MAG, the AP and the MN 2519 use 802.11e (or WMM), 802.1p tags and DSCP values to prioritize 2520 the traffic. 2522 +--+ +--+ +---+ +---+ 2523 |MN| |AP| |MAG| |LMA| 2524 +--+ + -+ +---+ +---+ 2525 (A)|----attach-----|---------------->|-----------PBU---------->| 2526 |<--------------|---------------- |<----PBA[QoS option]-----| 2527 . . [QoS rules] [QoS rules] 2528 (B). . . | 2529 new session | | | 2530 |----data[]---->|----data[]------>|-======data[DSCP]======->| 2531 | | | | 2532 (C)| | | Validate QoS rule 2533 | | | |---> 2534 | | |<======data[DSCP]========|<---- 2535 | | | | 2536 | | mapping | 2537 (D)| | DSCP/802.1p | 2538 | |<----data--------| | 2539 | | [802.1p/DSCP] | | 2540 | | | | 2541 | mapping | | 2542 | 802.1p/802.11e | | 2543 |<--data[WMM]---| | | 2544 | | | | 2545 |---data[WMM]-->|------data------>|=======data[DSCP]=======>|---> 2546 | | [802.1p/DSCP] | | 2547 | | | | 2549 Figure 14: Prioritization of a flow created on the WLAN access 2551 Appendix C. Information when implementing with a Broadband Network 2552 Gateway 2554 This section shows an example of QoS interworking between the PMIPv6 2555 domain and the broadband access. The Broadband Network Gateway (BNG) 2556 or Broadband Remote Access Server (BRAS) has the MAG function and the 2557 CPE (Customer Premise Equipment) or Residential Gateway (RG) is 2558 connected via the broadband access network. The MN is attached to 2559 the RG via e.g., Wi-Fi AP in the broadband home network. In the 2560 segment of the broadband access network, the BNG and RG are the 2561 Policy Enforcement Point (PEP) for the downlink and uplink traffic, 2562 respectively. The QoS information is downloaded from the LMA to the 2563 BNG via the PMIPv6 with the QoS option defined in this document. 2564 Based on the received QoS parameters (e.g., DSCP values), the 2565 broadband access network and the RG provide appropriate QoS treatment 2566 to the downlink and uplink traffic to/from the MN. 2568 +-----+ 2569 | PDP | 2570 +-----+ 2571 PEP | 2572 +-------+ | 2573 | BNG/ | PMIPv6 +-----+ 2574 | BRAS +===============| LMA | 2575 | (MAG) | tunnel +-----+ 2576 +-------+ PEP 2577 Broadband ( | ) 2578 Access ( DSCP ) 2579 Network ( | ) 2580 +-----+ 2581 +----+ | CPE | PEP 2582 | MN |-------------| /RG | 2583 +----+ Broadband +-----+ 2584 Home Network 2586 Figure 15: End-to-end QoS management with the broadband access 2587 network 2589 In the segment of the broadband access network, QoS mapping between 2590 3GPP QCI values and DSCP described in Section 6.2 is applied. In the 2591 segment of the broadband home network, if the MN is attached to the 2592 RG via Wi-Fi, the same QoS mapping as described in Appendix B can be 2593 applied. 2595 Authors' Addresses 2597 Marco Liebsch 2598 NEC 2599 Kurfuersten-Anlage 36 2600 Heidelberg D-69115 2601 Germany 2603 Email: liebsch@neclab.eu 2605 Pierrick Seite 2606 Orange 2607 4, rue du Clos Courtel, BP 91226 2608 Cesson-Sevigne 35512 2609 France 2611 Email: pierrick.seite@orange.com 2613 Hidetoshi Yokota 2614 KDDI Lab 2615 2-1-15 Ohara 2616 Saitama, Fujimino 356-8502 2617 Japan 2619 Email: yokota@kddilabs.jp 2621 Jouni Korhonen 2622 Broadcom Communications 2623 Porkkalankatu 24 2624 Helsinki FIN-00180 2625 Finland 2627 Email: jouni.nospam@gmail.com 2629 Sri Gundavelli 2630 Cisco 2631 170 West Tasman Drive 2632 San Jose, CA 95134 2633 USA 2635 Email: sgundave@cisco.com