idnits 2.17.1 draft-ietf-conex-mobile-03.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 14, 2014) is 3724 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-briscoe-tsvwg-ecn-encap-guidelines-03 == Outdated reference: A later version (-13) exists of draft-ietf-conex-abstract-mech-08 == Outdated reference: A later version (-12) exists of draft-ietf-conex-destopt-05 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CONEX WG D. Kutscher 3 Internet-Draft F. Mir 4 Intended status: Informational R. Winter 5 Expires: August 18, 2014 NEC 6 S. Krishnan 7 Y. Zhang 8 Ericsson 9 CJ. Bernardos 10 UC3M 11 February 14, 2014 13 Mobile Communication Congestion Exposure Scenario 14 draft-ietf-conex-mobile-03 16 Abstract 18 This memo describes a mobile communications use case for congestion 19 exposure (CONEX) with a particular focus on mobile communication 20 networks such as the 3GPP Evolved Packet System (EPS). The draft 21 provides a brief overview of the architecture of these networks (both 22 access and core networks), current QoS mechanisms and then discusses 23 how congestion exposure concepts could be applied. Based on this, 24 this memo suggests a set of requirements for CONEX mechanisms that 25 particularly apply to mobile networks. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 18, 2014. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. CONEX Use Cases in Mobile Communication Networks . . . . . . . 3 63 2.1. CONEX as a Basis for Traffic Management . . . . . . . . . 4 64 2.2. CONEX to Incentivize Scavenger Transports . . . . . . . . 6 65 2.3. Accounting for Congestion Volume . . . . . . . . . . . . . 7 66 2.4. Partial vs. Full Deployment . . . . . . . . . . . . . . . 7 67 2.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 3. CONEX in the EPS . . . . . . . . . . . . . . . . . . . . . . . 9 69 3.1. Possible Deployment Scenarios . . . . . . . . . . . . . . 9 70 3.2. Implementing CONEX Functions in the EPS . . . . . . . . . 13 71 3.2.1. CONEX Protocol Mechanisms . . . . . . . . . . . . . . 14 72 3.2.2. CONEX Functions in the Mobile Network . . . . . . . . 14 73 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 76 7. Informative References . . . . . . . . . . . . . . . . . . . . 18 77 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20 78 Appendix B. Overview of 3GPP's Evolved Packet System (EPS) . . . 21 79 Appendix C. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 22 80 C.1. draft-ietf-conex-mobile-03 . . . . . . . . . . . . . . . . 22 81 C.2. Earlier . . . . . . . . . . . . . . . . . . . . . . . . . 23 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 84 1. Introduction 86 Mobile data traffic continues to grow rapidly. The challenge 87 wireless operators face is to support more subscribers with an 88 increasing bandwidth demand. To meet these bandwidth requirements, 89 there is a need for new technologies that assist the operators in 90 efficiently utilizing the available network resources. Two specific 91 areas where such new technologies could be deemed useful are resource 92 allocation and flow management. 94 Analysis of cellular network data traffic has shown that most flows 95 are short-lived and low-volume, but a comparatively small number of 96 high-volume flows constitute a large fraction of the overall traffic 97 volume. Measurements have also shown that a small fraction of users 98 is responsible for the majority of traffic in cellular networks. In 99 view of such highly skewed user behavior and limited and expensive 100 resources (e.g. the wireless spectrum), resource allocation and usage 101 accountability are two important issues for operators to solve in 102 order to achieve both a better network resource utilization and fair 103 resource sharing. CONEX, as described in [RFC6789], is a technology 104 that can be used to achieve these goals. 106 The CONEX congestion exposure mechanism is designed to be a general 107 technology that could be applied as a key element of congestion 108 management solutions for a variety of use cases. The IETF CONEX WG 109 decided to initially start to work on a specific use case, where the 110 end hosts and the network that contains the destination end hosts are 111 CONEX-enabled but other networks need not be. 113 A specific example of such a use case can be a mobile communication 114 network such as a 3GPP Evolved Packet System (EPS) network, where UEs 115 (User Equipment, i.e. mobile end hosts), servers and caches, the 116 access network and possibly an operator's core network can be CONEX- 117 enabled. I.e., hosts support the CONEX mechanisms, and the network 118 provides policing/auditing functions at its edges. 120 This document provides a brief overview of the architecture of such 121 networks (access and core networks) and current QoS mechanisms. It 122 further discusses how such networks can benefit from congestion 123 exposure concepts and how they should be applied. Using this use 124 case as a basis, a set of requirements for CONEX mechanisms are 125 described. 127 2. CONEX Use Cases in Mobile Communication Networks 129 In general, quality of service and good network resource utilization 130 are important requirements for mobile communication network 131 operators. Radio access and backhaul networks are considered scarce 132 resources, and bandwidth (and radio resource) demand is difficult to 133 predict precisely due to user mobility, radio propagation effects 134 etc. Hence today's architectures and protocols go to significant 135 extent in order to provide network-controlled quality of service -- 136 for instance by 3GPP's EPS bearer model that enables the network to 137 allocate service data flows (SDFs) to certain EPS bearers with 138 specific quality of service classes (which can be used for fine- 139 granular service differentiation). 141 In the following, we discuss ways how congestion exposure could be 142 beneficial for supporting resource management in such mobile 143 communication networks. [RFC6789] describes fundamental congestion 144 exposure concepts and a set of use cases for applying congestion 145 exposure mechanisms to realize different traffic management functions 146 such as flow policy-based traffic management or traffic offloading. 148 2.1. CONEX as a Basis for Traffic Management 150 Traffic management is a very important function in mobile 151 communication networks. Since wireless resources are considered 152 scarce and since user mobility and shared bandwidth in the wireless 153 access create certain dynamics with respect to available bandwidth, 154 commercially operated mobile networks provide mechanisms for tight 155 resource management (admission control for bearer establishment) -- 156 however sometimes these mechanisms are not easily applicable to IP- 157 and HTTP-dominated traffic mixes, for example, most Internet traffic 158 in todays mobile network is transmitted over the (best-effort) 159 default bearer. 161 In the EPS, the QoS requirements for different services running on a 162 UE are supported by a bearer concept which is managed by the network. 163 Each bearer has an associated QoS Class Identifier (QCI) and an 164 Allocation and Retention Policy (ARP) that has been standardized for 165 uniform traffic handling (across implementations) -- operators can 166 define private QCIs in addition to that. For the necessary QoS 167 across the mobile network, an EPS bearer is maintained that crosses 168 different interfaces in the network and maps to lower layer bearers 169 for packet forwarding. A radio bearer transports traffic between a 170 UE and eNB whereas an S1 bearer transports traffic between the eNB 171 and S-GW and an S5/S8 bearer between the S-GW and P-GW. Primarily 172 LTE offers two types of bearer: a guaranteed bit rate bearer for 173 real-time communication, e.g., voice calls and a non-guaranteed bit 174 rate bearer for best effort traffic for Internet access etc. In 175 addition, different non-guaranteed bit rater bearers can be assigned 176 different priorities. Packets mapped to the same EPS bearer (and 177 priority) receive the same bearer-level packet forwarding treatment. 179 In the light of the significant increase of overall data volume in 3G 180 networks, Deep-Packet-Inspection (DPI) is often considered a 181 desirable function to have in the EPC -- on, for example, a PDN 182 (Packet Data Network) gateway, and some operators do in fact deploy 183 DPI today. The Policy and Charging Control (PCC) architecture 184 [3GPP.23.203] provides a "Traffic Detection Function" (TDF) that 185 performs application detection and reporting of detected applications 186 and its service data flow description to the Policy Control and 187 Charging Rules Function (PCRF) for performing functions such as 188 traffic blocking, redirection or policing for selected flows. 190 Congestion exposure can be employed to address resource management 191 requirements in different ways: 193 1. It can enable or enhance flow policy-based traffic management. 194 At present, DPI-based resource management is often used to 195 prioritize certain application classes with respect to others in 196 overload situations, so that effectively more users can be served 197 on the network. In overload situations, operators use DPI to 198 identify dispensable flows and make them yield to other flows (of 199 different application classes) through policing. Such traffic 200 management is thus based on operator decisions -- using partly 201 static configuration and some estimation about the future per- 202 flow bandwidth demand. With congestion exposure it would be 203 possible to assess the contribution to congestion of individual 204 flows. This information can then be used as input to a policer 205 that can optimize network utilization more accurately and 206 dynamically. By using ConEx congestion contribution as a metric, 207 such policers would not need to be aware of specific link load 208 (e.g., in wireless base stations) or flow application types. 210 2. It can reduce the need for complex DPI by allowing for a bulk 211 packet traffic management system that does not have to consider 212 the application classes flows belong to and individual sessions. 213 Instead, traffic management would be based on the current cost 214 (contribution to congestion) incurred by different flows and 215 enable operators to apply policing/accounting depending on their 216 preference. Such traffic management would be simpler and more 217 robust (no real-time flow application type identification 218 required, no static configuration of application classes) and 219 perform better as decisions can be taken based on real-time 220 actual cost contribution. With CONEX, accurate downstream path 221 information would be visible to ingress network operators, which 222 can respond to incipient congestion in time. This can be 223 equivalent to offering different levels of QoS, e.g. premium 224 service with zero congestion response. For that, ConEx could be 225 used in two different ways: 227 1. as additional information to assist network functions to 228 impose different QoS for different application sessions; and 230 2. as a tool to let applications decide on their response to 231 congestion notification, while incentivizing them to react 232 (in general) appropriately, e.g., by enforcing overall limits 233 for congestion contribution or by accounting and charging for 234 such congestion contribution. Note that this level of 235 responsiveness would be on a different level then, say, 236 application-layer responsive in protocols such as DASH 237 [dash], however it could interwork with such protocols, for 238 example by triggering earlier responses. 240 3. It can further be used to more effectively trigger the offload of 241 selected traffic to a non-3GPP network. Nowadays, it is common 242 that users are equipped with dual mode mobile phones (e.g., 243 integrating third/fourth generation cellular and WiFi radio 244 devices) capable of attaching to available networks either 245 sequentially or simultaneously. With this scenario in mind, 3GPP 246 is currently looking at mechanisms to seamlessly and selectively 247 switch over a single IP flow (e.g., user application) to a 248 different radio access, while keeping all other ongoing 249 connections untouched. The decision on when and which IP flows 250 move is typically based on static configured rules, whereas the 251 use of CONEX mechanisms could also factor in real-time congestion 252 information in the decision. 254 In summary, it can be said that traffic management in 3GPP EPS and 255 other mobile communication architectures is very important. 256 Currently, more static approaches based on admission control and 257 static QoS are in use, but recently, there has been a perceived need 258 for more dynamic mechanisms based on DPI. Introducing CONEX could 259 make these mechanisms more efficient or even remove the need for some 260 of the DPI functions deployed today. Adding CONEX support however 261 might require changes to the PCC architecture, depending on the scope 262 and impact of a CONEX-based traffic management approach. 264 2.2. CONEX to Incentivize Scavenger Transports 266 As 3G and LTE networks are turning into universal access networks 267 that are shared between mobile (smart) phone users, mobile users with 268 laptop PCs, home users with LTE access and others, capacity-sharing 269 among different users and application flows becomes increasingly 270 important in these mobile communication networks. 272 Most of this traffic is likely to be classified as best-effort 273 traffic, without differentiating for example periodic OS updates, 274 application store downloads from web (browser)-based or other more 275 real-time communication. For many of the bulk data transfers, 276 completion times aren't important within certain bounds and therefore 277 if scavenger (or less-than best effort) transports like e.g. LEDBAT 278 [RFC6817] were used, it would improve the overall utility of the 279 network. The use of these transports by the end user however needs 280 to be incentivized. CONEX could be used to build an incentive scheme 281 e.g. by allowing users that contribute less to congestion to give 282 them a larger bandwidth allowance or e.g. to lower the next monthly 283 subscription fee. In principle, this would be possible to implement 284 with current specifications. 286 2.3. Accounting for Congestion Volume 288 3G and LTE networks provide extensive support for accounting and 289 charging already, for example cf. the Policy Charging Control (PCC) 290 architecture. In fact, most operators today account transmitted data 291 volume on a very fine granular basis and either correlate monthly 292 charging to the exact number of packets/bytes transmitted, or employ 293 some form of flat rate (or flexible flat rate), often with a so- 294 called fair-use policy. With such policies, users are typically 295 limited to an administratively configured maximum bandwidth limit, 296 after they have used up their contractual data volume budget for the 297 charging period. 299 Changing this data volume-based accounting to a congestion-based 300 accounting would be possible in principle, especially since there 301 already is an elaborate per-user accounting system available. Also, 302 an operator-provided mobile communication network can be seen as a 303 network domain within such congestion volume accounting would be 304 possible, without requiring any support from the global Internet, in 305 particular since the typical scare resources such as the wireless 306 access and the mobile backhaul are all within this domain. Traffic 307 normally leaves/enters the operator's network via well-defined 308 egress/ingress points that would be ideal candidates for policing 309 functions. Moreover, in most commercially operated networks, 310 accounting is performed for both received and sent data, which would 311 facilitate congestion volume accounting as well. 313 With respect to the current PCC framework, accounting for congestion 314 volume could be added as another feature to the "Usage Monitoring 315 Control" capability that is currently based on data volume. This 316 would not require any new interface (reference points) at all. 318 2.4. Partial vs. Full Deployment 320 In general, CONEX lends itself to partial deployment as the mechanism 321 does not require all routers and hosts to support congestion 322 exposure. Moreover, assuming a policing infrastructure has been put 323 in place, it is not required to modify all hosts. Since CONEX is 324 about senders exposing congestion contribution to the network, 325 senders need to be made CONEX-aware (assuming a congestion 326 notification mechanisms such as ECN is in place). 328 [I-D.briscoe-conex-initial-deploy] provides specific examples of how 329 CONEX deployment can be initiated, focusing unilaterial deployment by 330 single networks, i.e., by partial deployment. 332 In mobile communication networks that would for example allow early 333 partial CONEX deployment in the downlink direction only, i.e., 334 servers, gateways and caches would support CONEX but UEs (mobile 335 hosts) would not. 337 When moving towards full deployment in a specific operator's network, 338 different ways for introducing CONEX support on UEs are feasible. 339 Since mobile communication networks are multi-vendor networks, 340 standardizing CONEX support on UEs (e.g., in 3GPP specifications) 341 appears useful. Still, not all UEs would have to support CONEX, and 342 operators would be free to choose their policing approach in such 343 deployment scenarios. Leveraging existing PCC architectures, 3GPP 344 network operators could for example decide policing/accounting 345 approaches per UE -- i.e., apply fixed volume caps for non-CONEX UEs 346 and more flexible schemes for CONEX-enabled UEs. 348 Moreover, it should be noted that network support for CONEX is a 349 feature that some operators may choose to deploy if they wish, but it 350 is not required that all operators (or all other networks) do so. 352 Depending on the extent of CONEX support, specific aspects such as 353 roaming have to be taken into account. I.e., what happens when a 354 user is roaming in a CONEX-enabled network, but their UE is not 355 CONEX-enabled and vice versa. Although these may not be fundamental 356 problems, they need to be considered. For supporting mobility in 357 general, it can be required to shift users' policing state during 358 hand-over. There is existing work in [raghavan2007] on distributed 359 rate limiting and in [nec.euronf-2011] on specific optimizations for 360 congestion exposure and policing in mobility scenarios. 362 Another aspect to consider is the addition of Selected IP Traffic 363 Offload (SIPTO) and Local Breakout (LIPA), also see [3GPP.23.829], 364 i.e., the idea that some traffic (e.g., high-volume Internet traffic) 365 is actually not passed through the EPC but is offloaded at a "break- 366 out point" closer to (or in) the access network. On the other hand, 367 CONEX can also enable more dynamic decisions on what traffic to 368 actually offload by considering congestion exposure in bulk traffic 369 aggregates -- thus making traffic offload more effective. 371 2.5. Summary 373 In summary, the 3GPP EPS is a system architecture that can benefit 374 from congestion exposure in multiple ways, as we have shown by this 375 brief description of CONEX use cases in this environment. Dynamic 376 traffic and congestion management is an acknowledged and important 377 requirement for the EPS, also illustrated by the current DPI-related 378 work for EPS. 380 Moreover, networks such as an EPS mobile communication network would 381 be quite amenable for deploying CONEX as a mechanism, since they 382 represent clearly defined and well separated operational domains, in 383 which local CONEX deployment would be possible. Aside from roaming 384 (which needs to be considered for a specific solution), such a 385 deployment is fully under the control of a single operator, which can 386 enable operator-local enhancement without the need for major changes 387 to the architecture. 389 In 3GPP EPS, interfaces between all elements of the architecture are 390 subject to standardization, including UE interfaces and eNodeB 391 interfaces, so that a more general approach, involving more than one 392 single operator's network, can be feasible as well. 394 3. CONEX in the EPS 396 At the time of writing, the CONEX mechanism is still work in progress 397 in the IETF working group. Still, discussing a few options for how 398 such a mechanism (and possibly additional policing functions) could 399 eventually be deployed in 3GPP's EPS is useful at this point. Note 400 that this description of options is not intended as a complete set of 401 possible approaches -- it is merely intended for discussing the most 402 promising options. 404 3.1. Possible Deployment Scenarios 406 There are different possible ways how CONEX functions on hosts and 407 network elements can be used. For example, CONEX could be used for a 408 limited part of the network only -- e.g., for the access network -- 409 congestion exposure and sender adaptation could involve the mobile 410 nodes or not, or, finally, the CONEX feedback loop could extend 411 beyond a single operator's domain or not. 413 We present three different deployment scenarios for congestion 414 exposure in the figures below: 416 1. In Figure 1 CONEX is supported by servers for sending data (here: 417 web servers in the Internet and caches in an operator's network) 418 but not by UEs (neither for receiving nor sending). An operator 419 who chooses to run a policing function on the network ingress 420 (e.g., on the P-GW) can still benefit from congestion exposure 421 without requiring any change on UEs. 423 2. CONEX is universally employed between operators (as depicted in 424 Figure 2), with an end-to-end CONEX feedback loop. Here, 425 operators could still employ local policies, congestion 426 accounting schemes etc., and they could use information about 427 congestion contribution for determining interconnection 428 agreements. This deployment scenario would imply the willingness 429 of operators to expose congestion to each other. 431 3. Isolated CONEX domains as depicted in Figure 3, where CONEX is 432 solely applied locally, in the operator network, and there is no 433 end-to-end congestion exposure. This could be the case when 434 CONEX is only implemented in a few networks, or when operators 435 decide to not expose ECN and account for congestion for inter- 436 domain traffic. Independent of the actual scenario, it is likely 437 that there will be border gateways (as in today's deployments) 438 that are associated with policing and accounting functions. 440 +------------+ 441 | Web server | 442 | w/ CONEX | 443 +------------+ 444 | 445 | 446 | 447 ----------------------- 448 | | | 449 | Internet | | 450 | | | 451 ----------------------- 452 | 453 --------------------------------------------|-------- 454 | | | 455 | +-----------+ | 456 | | Web cache | | 457 | | w/ CONEX | | 458 | +-----------+ | 459 | | | 460 | +----+ +-------+ +-------+ +-------+ | 461 | | UE |=====| eNB |=====| S-GW |=====| P-GW | | 462 | +----+ +-------+ +-------+ +-------+ | 463 | | 464 | Operator A | 465 ----------------------------------------------------- 467 Figure 1: CONEX support on servers and caches 469 ----------------------------------------------------- 470 | +----+ +-------+ +-------+ +-------+ | 471 | | UE |=====| eNB |=====| S-GW |=====| P-GW | | 472 | +----+ +-------+ +-------+ +-------+ | 473 | | | 474 | Operator A | | 475 --------------------------------------------|-------- 476 | 477 ----------------------- 478 | | 479 | Internet | 480 | | 481 ----------------------- 482 | 483 --------------------------------------------|-------- 484 | +----+ +-------+ +-------+ +-------+ | 485 | | UE |=====| eNB |=====| S-GW |=====| P-GW | | 486 | +----+ +-------+ +-------+ +-------+ | 487 | | 488 | Operator B | 489 ----------------------------------------------------- 491 Figure 2: CONEX deployment across operator domains 493 ----------------------------------------------------- 494 | |--- CONEX path ---| | 495 | v v 496 | +----+ +-------+ +-------+ +-------+ | 497 | | UE |=====| eNB |=====| S-GW |=====| P-GW | | 498 | +----+ +-------+ +-------+ +-------+ | 499 | | | 500 | Operator A | | 501 --------------------------------------------|-------- 502 | 503 ----------------------- 504 | | 505 | Internet | 506 | | 507 ----------------------- 508 | 509 --------------------------------------------|-------- 510 | +----+ +-------+ +-------+ +-------+ | 511 | | UE |=====| eNB |=====| S-GW |=====| P-GW | | 512 | +----+ +-------+ +-------+ +-------+ | 513 | | 514 | Operator B | 515 ----------------------------------------------------- 517 Figure 3: CONEX deployment in a single operator domain 519 We consider all three scenarios to be relevant and believe that all 520 of them are within the scope of the CONEX WG charter. A more 521 detailed description will be provided in a future version of this 522 document. 524 3.2. Implementing CONEX Functions in the EPS 526 We expect a CONEX solution to consist of different functions that 527 should be considered when implementing congestion exposure in 3GPP's 528 EPS. [I-D.ietf-conex-abstract-mech] is describing the following 529 congestion exposure components: 531 o Modified senders that send congestion exposure information in 532 response to congestion feedback. 534 o Receivers that generate congestion feedback (leveraging existing 535 behavior or requiring new functions). 537 o Audit functions that audit CONEX signals against actual 538 congestion, e.g., by monitoring flows or aggregate of flows. 540 o Policy devices that monitor congestion exposure information and 541 act on the flows according to the operator's policy. 543 Two aspects are important to consider: 1) how the CONEX protocol 544 mechanisms would be implemented and what modifications to existing 545 networks would be required and 2) where CONEX functional entities 546 would be placed best (to allow for a non-invasive addition). We 547 discuss these two aspects in the following sections. 549 3.2.1. CONEX Protocol Mechanisms 551 As described in [I-D.briscoe-conex-initial-deploy], the most 552 important step in introducing CONEX (initially) is adding the 553 congestion exposure functionality to senders. For an initial 554 deployment, no further modification to senders and receivers would be 555 required. Specifically, there is no fundamental dependency on ECN, 556 i.e., CONEX can be introduced without requiring ECN to be 557 implemented. 559 Congestion exposure information for IPv6 [I-D.ietf-conex-destopt] is 560 contained in a destination option header field, which requires 561 minimal changes at senders and nodes that want to assess path 562 congestion -- and that does not affect non-CONEX nodes in a network. 564 In 3GPP networks, IP tunneling is used intensively, i.e., using 565 either IP-in-GTP-U or PMIPv6 (i.e., IP-in-IP) tunnels. In general, 566 the CONEX destination option of encapsulated packets should be made 567 available for network nodes on the tunnel path, i.e., a tunnel 568 ingress should copy the CONEX destination option field to the outer 569 header. 571 For an effective and efficient capacity sharing, we envisage the 572 deployment of ECN in conjunction with CONEX so that ECN-enabled 573 receivers and senders get more accurate and more timely information 574 about their flows congestion contribution. ECN is already partially 575 introduced into 3GPP networks: Section 11.6 in [3GPP.36.300] 576 specifies the usage of ECN for congestion notification on the radio 577 link (between eNB and UE), and [3GPP.26.114] specifies how this can 578 be leveraged for voice codec adaptation. A complete, end-to-end 579 support of ECN would require specification of tunneling behaviour, 580 which should be based on [RFC6040] (for IP-in-IP tunnels) and on 581 [I-D.briscoe-tsvwg-ecn-encap-guidelines]. Specifically, a 582 specification for tunneling ECN in GTP-U will be needed. 584 3.2.2. CONEX Functions in the Mobile Network 586 In the following, we discuss some possible placement strategies for 587 CONEX functional entities (addressing both policing and auditing 588 functions) in the EPS and for possible optimizations for both the 589 uplink and the downlink. 591 In general, CONEX information (exposed congestion) is declared by a 592 sender and remains unchanged on the path, hence reading CONEX 593 information (e.g., by policing functions) is placement-agnostic. 594 Auditing CONEX normally requires assessing declared congestion 595 contribution and current actual congestion. If the latter is, for 596 example, done using ECN, such a function would best be placed at the 597 end of the path. 599 In order to provide a comprehensive CONEX-based capacity management 600 framework for EPS, it would be advantageous to consider user 601 contribution to congestion for both the radio access and the core 602 network. For a non-invasive introduction of CONEX, it can be 603 beneficial to combine CONEX functions with existing logical EPS 604 entities. For example, potential places for CONEX policing and 605 auditing functions would then be eNBs, S-GWs or the P-GWs. Operator 606 deployments may of course still provide additional intermediary 607 CONEX-enabled IP network elements. 609 For a more specific discussion it will be beneficial to distinguish 610 downlink and uplink traffic directions (also see [nec.globecom2010] 611 for a more detailed discussion). In today's networks and usage 612 models, downlink traffic is dominating (also reflected by the 613 asymmetric capacity provided by the LTE radio interface). That does 614 however not imply that uplink congestion is not an issue, since the 615 asymmetric maximum bandwidth configuration can create a smaller 616 bottleneck for uplink traffic -- and there are of course backhaul 617 links, gateways etc. that could be overloaded as well. 619 For managing downlink traffic -- e.g., in scenarios such as the one 620 depicted in Figure 1, operators can have different requirements for 621 policing traffic. Although policing is in principle location- 622 agnostic, it is important to consider requirements related to the EPS 623 architecture (Figure 4) such as tunneling between P-GWs and eNBs. 624 Policing can require access to subscriber information (e.g., 625 congestion contribution quota) or user-specific accounting, which 626 suggests that the CONEX function could be co-located with the P-GW 627 that already has an interface towards the PCRF. 629 Still, policing can serve different purposes. For example, if the 630 objective is to police bulk traffic induced by peer networks, 631 additional monitoring functions can be placed directly at 632 corresponding ingress points to monitor traffic and possible drive 633 out-of-band functions such as triggering border contract penalties. 635 The auditing function which should be placed at the end of the path 636 (at least after/at the last bottleneck) would likely be placed best 637 on the eNB (wireless base station). 639 For the uplink direction, there are naturally different options for 640 designing monitoring and policy enforcement functions. A likely 641 approach can be to monitor congestion exposure on central gateway 642 nodes (such as P-GWs) that provide the required interfaces to the 643 PCRF, but to perform policing actions in the access network, i.e., in 644 eNBs, e.g., to police traffic at the ingress, before it reaches 645 concentration points in the core network. 647 Such a setup would enable all the CONEX use cases described in 648 Section 2, without requiring significant changes to the EPS 649 architecture, while enabling operators to re-use existing 650 infrastructure, specifically wireless base stations, PCRF and HSS 651 systems. 653 For CONEX functions on elements such as the S-GWs and P-GWs, it is 654 important to consider mobility and tunneling protocol requirements. 655 LTE provides two alternative approaches: Proxy-Mobile-IPv6 (PMIPv6, 656 [3GPP.23.402]) and GPRS Tunneling Protocol (GTP). For the 657 propagation of congestion information (responses) tunneling 658 considerations are therefore very important. 660 In general, policing will be done based on per-user (per subscriber) 661 information such as congestion quota, current quota usage etc. and 662 network operator policies, e.g., specifying how to react to 663 persistent congestion contribution. In the EPS, per-user information 664 is normally part of the user profile (stored in the HSS) that would 665 be accessed by PCC entities such as the PCRF for dynamic updates, 666 enforcement etc. 668 A more detailed description of the different approaches and their 669 respective advantages will be provided in a future revision of this 670 document. 672 4. Summary 674 We have shown how congestion exposure can be useful for efficient 675 resource management in mobile communication networks. The premise 676 for this discussion was the observation that data communication, 677 specifically best-effort bulk data transmission, is becoming a 678 commodity service whereas resources are obviously still limited -- 679 which calls for efficient, scalable, yet effective capacity sharing 680 in such networks. 682 CONEX can be a mechanism that enables such capacity sharing, while 683 allowing operators to apply these mechanisms in different ways, e.g., 684 for implementing different use cases as described in Section 2. It 685 is important to note that CONEX is fundamentally a mechanism that can 686 be applied in different ways -- to realize different operators 687 policies. 689 CONEX may also be used to complement 3GPP-based mechanisms for 690 congestion management which are currently under development, such as 691 in the User Plane Congestion Management (UPCON) work item described 692 in [3GPP.23.705]. 694 We have described a few possibilities for adding CONEX as a mechanism 695 to 3GPP LTE-based networks and have shown how this could be done 696 incrementally (starting with partial deployment). It is quite 697 feasible that such partial deployments be done on a per-operator- 698 domain basis, without requiring changes to standard 3GPP interfaces. 699 For a network-wide deployment, e.g., with congestion exposure between 700 operators, more considerations might be needed. 702 We have also identified a few implications/requirements that should 703 be taken into consideration when enabling congestion exposure in such 704 networks: 706 Performance: In mobile communication networks -- with more expensive 707 resources and more stringent QoS requirements -- the feasibility 708 of applying CONEX as well as its performance and deployment 709 scenarios need to be examined closer. For instance, a mobile 710 communication network may encounter longer delay and higher loss 711 rates, which can impose specific requirements on the timeliness 712 and accuracy of congestion exposure information. 714 Mobility: One of the unique characteristics in cellular network is 715 the presence of user mobility compared to wired networks. As the 716 user location changes, the same device can be connected to the 717 network via different base stations (eNodeBs) or even go through 718 switching gateways. Thus, the CONEX scheme must to be able to 719 carry latest congestion information per user/flow across multiple 720 network nodes in real-time. 722 Multi-access: In cellular networks, multiple access technologies can 723 co-exist. In such cases, a user can use multiple access 724 technologies for multiple applications or even a single 725 application simultaneously. If the congestion policies are set 726 based on each user, then CONEX should have the capability to 727 enable information exchange across multiple access domains. 729 Tunneling: Both 3G and LTE networks make extensive usage of 730 tunneling. The CONEX mechanism should be designed in a way to 731 support usage with different tunneling protocols such as PMIPv6 732 and GTP. For ECN-based congestion notification, [RFC6040] 733 specifies how the ECN field of the IP header should be constructed 734 on entry and exit from IP-in-IP tunnels, and 735 [I-D.briscoe-tsvwg-ecn-encap-guidelines] provides guidelines for 736 adding congestion notification to protocols that encapsulate IP. 738 Roaming: Independent of the specific architecture, mobile 739 communication networks typically differentiate between non-roaming 740 and roaming scenarios. Roaming scenarios are typically more 741 demanding regarding implementing operator policies, charging etc. 742 It can be expected that this would also hold for deploying CONEX. 743 A more detailed analysis of this problem will be provided in a 744 future revision of this document. 746 It is important to note that CONEX is intended to be used as a 747 supplement and not a replacement to the existing QoS mechanisms in 748 mobile networks. For example, CONEX deployed in 3GPP mobile networks 749 can provide useful input to the existing 3GPP PCC mechanisms by 750 supplying more dynamic network information to supplement the fairly 751 static information used by the PCC. This would enable the mobile 752 network to make better policy control decisions than is possible with 753 only static information. 755 5. IANA Considerations 757 No IANA considerations. 759 6. Security Considerations 761 Security considerations for applying CONEX to EPS include, but are 762 not limited to, the security considerations that apply to the CONEX 763 protocols. 765 7. Informative References 767 [3GPP.23.203] 768 3GPP, "Policy and charging control architecture", 3GPP 769 TS 23.203 10.9.0, September 2013. 771 [3GPP.23.401] 772 3GPP, "General Packet Radio Service (GPRS) enhancements 773 for Evolved Universal Terrestrial Radio Access Network 774 (E-UTRAN) access", 3GPP TS 23.401 10.10.0, March 2013. 776 [3GPP.23.402] 777 3GPP, "Architecture enhancements for non-3GPP accesses", 778 3GPP TS 23.402 10.8.0, September 2012. 780 [3GPP.23.705] 781 3GPP, "System Enhancements for User Plane Congestion 782 Management", 3GPP TR 23.705 0.8.0, October 2013. 784 [3GPP.23.829] 785 3GPP, "Local IP Access and Selected IP Traffic Offload 786 (LIPA-SIPTO)", 3GPP TR 23.829 10.0.1, October 2011. 788 [3GPP.26.114] 789 3GPP, "IP Multimedia Subsystem (IMS); Multimedia 790 telephony; Media handling and interaction", 3GPP TS 26.114 791 10.7.0, June 2013. 793 [3GPP.29.060] 794 3GPP, "General Packet Radio Service (GPRS); GPRS 795 Tunnelling Protocol (GTP) across the Gn and Gp interface", 796 3GPP TS 29.060 3.19.0, March 2004. 798 [3GPP.29.274] 799 3GPP, "3GPP Evolved Packet System (EPS); Evolved General 800 Packet Radio Service (GPRS) Tunnelling Protocol for 801 Control plane (GTPv2-C); Stage 3", 3GPP TS 29.274 10.11.0, 802 June 2013. 804 [3GPP.36.300] 805 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA) 806 and Evolved Universal Terrestrial Radio Access Network 807 (E-UTRAN); Overall description; Stage 2", 3GPP TS 36.300 808 10.11.0, September 2013. 810 [I-D.briscoe-conex-initial-deploy] 811 Briscoe, B., "Initial Congestion Exposure (ConEx) 812 Deployment Examples", 813 draft-briscoe-conex-initial-deploy-03 (work in progress), 814 July 2012. 816 [I-D.briscoe-tsvwg-ecn-encap-guidelines] 817 Briscoe, B., Kaippallimalil, J., and P. Thaler, 818 "Guidelines for Adding Congestion Notification to 819 Protocols that Encapsulate IP", 820 draft-briscoe-tsvwg-ecn-encap-guidelines-03 (work in 821 progress), September 2013. 823 [I-D.ietf-conex-abstract-mech] 824 Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) 825 Concepts and Abstract Mechanism", 826 draft-ietf-conex-abstract-mech-08 (work in progress), 827 October 2013. 829 [I-D.ietf-conex-destopt] 830 Krishnan, S., Kuehlewind, M., and C. Ucendo, "IPv6 831 Destination Option for ConEx", draft-ietf-conex-destopt-05 832 (work in progress), October 2013. 834 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 835 Notification", RFC 6040, November 2010. 837 [RFC6789] Briscoe, B., Woundy, R., and A. Cooper, "Congestion 838 Exposure (ConEx) Concepts and Use Cases", RFC 6789, 839 December 2012. 841 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, 842 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, 843 December 2012. 845 [dash] ISO/IEC, "ISO/IEC 23009-1: Information Technology -- 846 Dynamic Adaptive Streaming over HTTP (DASH) --", 847 April 2012. 849 [nec.euronf-2011] 850 Mir, Kutscher, and Brunner, "Congestion Exposure in 851 Mobility Scenarios", in proceedings of 7th EURO-NF 852 CONFERENCE ON NEXT GENERATION INTERNET, June 2011. 854 [nec.globecom2010] 855 Kutscher, Lundqvist, and Mir, "Congestion Exposure in 856 Mobile Wireless Communications", in proceedings of IEEE 857 GLOBECOM 2010, December 2010. 859 [raghavan2007] 860 Raghavan, Vishwanath, Ramabhadran, Yocum, and Snoeren, 861 "Cloud Control with Distributed Rate Limiting", in 862 proceedings of ACM SIGCOMM 2007, 2007. 864 DOI: http://doi.acm.org/10.1145/1282427.1282419 866 Appendix A. Acknowledgments 868 We would like to thank Bob Briscoe and Ingemar Johansson for their 869 support in shaping the overall idea and in improving the draft by 870 providing constructive comments. We would also like to thank Andreas 871 Maeder and Dirk Staehle for reviewing the draft and for providing 872 helpful comments. 874 Appendix B. Overview of 3GPP's Evolved Packet System (EPS) 876 This section provides an overview of 3GPP's "Evolved Packet System" 877 (EPS [3GPP.36.300], [3GPP.23.401]) as a specific example of a mobile 878 communication architecture. Of course other architectures exist but 879 the EPS is used as one example to demonstrate the applicability of 880 congestion exposure concepts and mechanisms. 882 The EPS architecture and some of its standardized interfaces are 883 depicted in Figure 1. The EPS provides IP connectivity to user 884 equipment (UE) (i.e., mobile nodes) and access to operator services, 885 such as global Internet access and voice communications. The EPS 886 comprises the radio access network called evolved UMTS Terrestrial 887 Radio Access Network (E-UTRAN) and the core network called Evolved 888 Packet Core (EPC). QoS is supported through an EPS bearer concept, 889 providing bindings to resource reservation within the network. 891 The evolved NodeB (eNB), the Long Term Evolution (LTE) base station, 892 is part of the access network that provides radio resource 893 management, header compression, security and connectivity to the core 894 network through the S1 interface. In an LTE network, the control 895 plane signaling traffic and the data traffic are handled separately. 896 The eNBs transmit the control traffic and data traffic separately via 897 two logically separate interfaces. 899 The Home Subscriber Server, HSS, is a database that contains user 900 subscriptions and QoS profiles. The Mobility Management Entity, MME, 901 is responsible for mobility management, user authentication, bearer 902 establishment and modification and maintenance of the UE context. 904 The Serving gateway, S-GW, is the mobility anchor and manages the 905 user plane data tunnels during the inter-eNB handovers. It tunnels 906 all user data packets and buffers downlink IP packets destined for 907 UEs that happen to be in idle mode. 909 The Packet Data Network (PDN) Gateway, P-GW, is responsible for IP 910 address allocation to the UE and is a tunnel endpoint for user and 911 control plane protocols. It is also responsible for charging, packet 912 filtering, and policy-based control of flows. It interconnects the 913 mobile network to external IP networks, e.g. the Internet. 915 In this architecture, data packets are not sent directly on an IP 916 network between the eNB and the gateways. Instead, every packet is 917 tunneled over a tunneling protocol - the GPRS Tunneling Protocol (GTP 918 [3GPP.29.060]) over UDP/IP. A GTP path is identified in each node 919 with the IP address and a UDP port number on the eNB/gateways. The 920 GTP protocol carries both the data traffic (GTP-U tunnels) and the 921 control traffic (GTP-C tunnels [3GPP.29.274]). Alternatively Proxy 922 Mobile IP (PMIPv6) is used on the S5 interface between S-GW and P-GW. 924 The above is very different from an end-to-end path on the Internet 925 where the packet forwarding is performed at the IP level. 926 Importantly, we observe that these tunneling protocols give the 927 operator a large degree of flexibility to control the congestion 928 mechanism incorporated with the GTP/PMIPv6 protocols. 930 +-------+ 931 +-------+ | PCRF | 932 | HSS | /+-------+\ 933 +-------+ Gx/ \Rx 934 | / \ 935 | / \ 936 | +-------+ SGi +-------+ 937 | | P-GW |=========| AF | 938 | +-------+ +-------+ 939 HPMN | | 940 ------------------------------|--------------|---------------------- 941 VPLMN | | 942 +-------+ | 943 | MME | | 944 /+-------+\ |S8 945 S1-MME / \ | 946 / \S11 | 947 / \ | 948 +-----------+ \ | 949 +----+ LTE-Uu | | \ | 950 | UE |========| | S1-U +-------+ 951 +----+ | E-UTRAN |==============| S-GW | 952 | (eNBs) | +-------+ 953 | | 954 +-----------+ 956 Figure 4: EPS architecture overview (Roaming Case) 958 Appendix C. ChangeLog 960 C.1. draft-ietf-conex-mobile-03 961 o implemented suggestions for improving 3GPP EPS descriptions by 962 Andreas Maeder 964 o mentioned 3GPP UPCON and added reference 966 o updated references 968 o In section 3.1 (CONEX as a Basis for Traffic Management), changed 969 the wording in the first abstract of the enumerated list to state 970 that ConEx can enable/enhance flow policy-based traffic management 971 -- not DPI (as we earlier said). DPI is not the objective -- it 972 is the tool that is currently used... 974 o merged section 3.4 (CONEX as a Form of Differential QoS) into 3.1 975 (CONEX as a Basis for Traffic Management) 977 o moved section 2 (Overview of 3GPP's Evolved Packet System (EPS)) 978 to appendix. 980 o renamed section "CONEX Use Cases in the Mobile Communication 981 Scenario" to "CONEX Use Cases in Mobile Communication Networks" 983 o updated TDF text in "CONEX as a Basis for Traffic Management" 985 o added reference to 3GPP UPCON to summary 987 C.2. Earlier 989 o changed title to "Mobile Communication Congestion Exposure 990 Scenario" (was "use case") 992 o added new section 3 on "CONEX Uses Cases in mobile communication 993 scenario" 995 o removed "Motivation" section in section 4 997 o removed "isolated connex deployment section in section 4" 999 o renamed "EPS integration" section in section 4 to "Additional EPS 1000 integration options" 1002 o added a (still empty) summary section to section 4 1004 o s/Re-ECN/CONEX/g 1006 o added references 1007 o added acknowledgments 1009 Authors' Addresses 1011 Dirk Kutscher 1012 NEC 1013 Kurfuersten-Anlage 36 1014 Heidelberg, 1015 Germany 1017 Phone: 1018 Email: kutscher@neclab.eu 1020 Faisal Ghias Mir 1021 NEC 1022 Kurfuersten-Anlage 36 1023 Heidelberg, 1024 Germany 1026 Phone: 1027 Email: faisal.mir@neclab.eu 1029 Rolf Winter 1030 NEC 1031 Kurfuersten-Anlage 36 1032 Heidelberg, 1033 Germany 1035 Phone: 1036 Email: rolf.winter@neclab.eu 1038 Suresh Krishnan 1039 Ericsson 1040 8400 Blvd Decarie 1041 Town of Mount Royal, Quebec 1042 Canada 1044 Phone: 1045 Email: suresh.krishnan@ericsson.com 1046 Ying Zhang 1047 Ericsson 1048 200 Holger Way 1049 San Jose, CA 95134 1050 USA 1052 Phone: 1053 Email: ying.zhang@ericsson.com 1055 Carlos J. Bernardos 1056 Universidad Carlos III de Madrid 1057 Av. Universidad, 30 1058 Leganes, Madrid 28911 1059 Spain 1061 Phone: +34 91624 6236 1062 Email: cjbc@it.uc3m.es 1063 URI: http://www.it.uc3m.es/cjbc/