idnits 2.17.1 draft-kutscher-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 (March 12, 2012) is 4421 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-briscoe-conex-initial-deploy-01 == Outdated reference: A later version (-04) exists of draft-briscoe-tsvwg-ecn-encap-guidelines-00 == Outdated reference: A later version (-13) exists of draft-ietf-conex-abstract-mech-03 == Outdated reference: A later version (-05) exists of draft-ietf-conex-concepts-uses-04 == Outdated reference: A later version (-12) exists of draft-ietf-conex-destopt-01 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF D. Kutscher 3 Internet-Draft F. Mir 4 Intended status: Informational R. Winter 5 Expires: September 13, 2012 NEC 6 S. Krishnan 7 Ericsson 8 C. Cano 9 Universidad Carlos III de Madrid 10 March 12, 2012 12 Mobile Communication Congestion Exposure Scenario 13 draft-kutscher-conex-mobile-03 15 Abstract 17 This memo describes a mobile communications use case for congestion 18 exposure (CONEX) with a particular focus on mobile communication 19 networks such as 3GPP EPS. The draft describes the architecture of 20 these networks (access and core networks), current QoS mechanisms and 21 then discusses how congestion exposure concepts could be applied. 22 Based on this, this memo suggests a set of requirements for CONEX 23 mechanisms that particularly apply to mobile networks. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 13, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Overview of 3GPP's Evolved Packet System (EPS) . . . . . . . . 3 58 3. CONEX Use Cases in the Mobile Communication Scenario . . . . . 5 59 3.1. CONEX as a Basis for Traffic Management . . . . . . . . . 6 60 3.2. CONEX to Incentivize Scavenger Transports . . . . . . . . 7 61 3.3. Accounting for Congestion Volume . . . . . . . . . . . . . 8 62 3.4. CONEX as a Form of Differential QoS . . . . . . . . . . . 8 63 3.5. Partial vs. Full Deployment . . . . . . . . . . . . . . . 9 64 3.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 4. CONEX in the EPS . . . . . . . . . . . . . . . . . . . . . . . 10 66 4.1. Possible Deployment Scenarios . . . . . . . . . . . . . . 11 67 4.2. Implementing CONEX Functions in the EPS . . . . . . . . . 14 68 4.2.1. CONEX Protocol Mechanisms . . . . . . . . . . . . . . 15 69 4.2.2. CONEX Functions in the Mobile Network . . . . . . . . 16 70 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 73 8. Informative References . . . . . . . . . . . . . . . . . . . . 19 74 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 21 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 77 1. Introduction 79 Mobile data traffic continues to grow rapidly. The challenge 80 wireless operators face is to support more subscribers with higher 81 bandwidth requirements. To meet the bandwidth demand, operators need 82 to seek for new technologies to efficiently utilize the available 83 network resources, in particular, this concerns resource allocation 84 and flow management. Ample statistics for network traffic from 85 cellular networks are available, stating that many short flows exist, 86 but that a few large flows constitute a large part of the overall 87 traffic volume. Measurement studies have shown that a small number 88 of users is responsible for the most part of the traffic in cellular 89 networks. With the highly skewed network access behavior, more 90 expensive resources in cellular networks as compared to other 91 networks and the rapidly increasing network utilization, resource 92 allocation and usage accountability are two important issues for 93 operators to solve in order to achieve a better, accountable network 94 resource utilization. CONEX, as described in 95 [I-D.ietf-conex-concepts-uses], is a technology to base this upon. 97 The CONEX congestion exposure mechanism is intended as a general 98 technology that could be applied as a key element of congestion 99 management solutions in a variety of use cases. The IETF CONEX WG 100 will however work on a specific use case, where the end hosts and the 101 network that contains the destination end host are CONEX-enabled but 102 other networks need not be. 104 A specific example of such a use case can be a mobile communication 105 network such as a 3GPP EPS network, where UEs (User Equipment, i.e. 106 mobile end hosts), servers and caches, the access network and 107 possibly an operator's core network can be CONEX-enabled. I.e., 108 hosts support the CONEX mechanisms, and the network provides 109 policing/auditing functions at its edges. 111 This draft describes the architecture of such networks (access and 112 core networks), current QoS mechanisms and then discusses how 113 congestion exposure concepts can benefit such networks and how they 114 should be applied. Using this use case as a basis, a set of 115 requirements for CONEX mechanisms are described. 117 2. Overview of 3GPP's Evolved Packet System (EPS) 119 This section provides an overview of 3GPP's "Evolved Packet System" 120 (EPS [3GPP.36.300]) as a specific example of a mobile communication 121 architecture in order to illustrate congestion exposure applicability 122 in this memo. There are other mobile communication architectures. 124 The EPS architecture and its standardized interfaces are depicted in 125 Figure 1. The EPS provides IP connectivity to UEs (user equipment, 126 i.e., mobile nodes) and access to operator services, such as global 127 Internet access and voice communications. The EPS comprises the 128 access (evolved UMTS Terrestrial Radio Access Network, E-UTRAN) and 129 the core network (Evolved Packet Core, EPC -- all network elements 130 except the E-UTRAN). QoS is supported through an EPS bearer concept, 131 providing hierarchical bindings within the network. 133 The evolved NodeB (eNB), the Long Term Evolution (LTE) base station, 134 is part of the access network that provides radio resource 135 management, header compression, security and connectivity to the core 136 network through the S1 interface. In an LTE network, the control 137 plane signaling traffic and the data traffic are handled separately. 138 The eNBs transmit the control traffic and data traffic separately via 139 two logically different interfaces. 141 The Home Subscriber Server, HSS, is a database that contains user 142 subscriptions and QoS profiles. The Mobility Management Entity, MME, 143 is responsible for user authentication, bearer establishment and 144 modification and maintenance of the UE context. 146 The Serving gateway, S-GW, is the mobility anchor and manages the 147 user plane data tunnels during the inter-eNB handovers. It tunnels 148 all user data packets and buffers downlink IP packets destined for 149 UEs that happen to be in idle mode. 151 The Packet Data Network (PDN) Gateway, P-GW, is responsible for IP 152 address allocation to the UE and is a tunnel endpoint for mobility 153 protocols. It is also responsible for charging, packet filtering, 154 and policy-based control of flows. It interconnects the mobile 155 network to external IP networks, e.g. the Internet. 157 In this architecture, data packets are not sent directly on an IP 158 network between the eNB and the gateways. Instead, every packet is 159 sent in a tunneling protocol - the GPRS Tunneling Protocol (GTP 160 [3GPP.29.060]) over UDP/IP. A GTP path is identified in each node 161 with the IP address and a UDP port number on the eNB/gateways. The 162 GTP protocol carries both the data traffic (GTP-U tunnels) and the 163 control traffic (GTP-C tunnels [3GPP.29.274]). Alternativly Proxy 164 Mobile IP (PMIP) is used on the S8 interface. 166 The above is very different from an end-to-end path on the Internet 167 where the packet forwarding is performed at the IP level. 168 Importantly, we observe that these tunneling protocols give the 169 operator a large degree of flexibility to control the congestion 170 mechanism incorporated with the GTP/PMIP protocols. 172 +-------+ 173 +-------+ | PCRF | 174 | HSS | /+-------+\ 175 +-------+ Gx/ \Rx 176 | / \ 177 | / \ 178 | +-------+ SGi +-------+ 179 | | P-GW |=========|IP Svr | 180 | +-------+ +-------+ 181 HPMN | | 182 ------------------------------|--------------|---------------------- 183 VPLMN | | 184 +-------+ | 185 | MME | | 186 /+-------+\ |S8 187 S1-MME / \ | 188 / \S11 | 189 / \ | 190 +-----------+ \ | 191 +----+ LTE-Uu | | \ | 192 | UE |========| | S1-U +-------+ 193 +----+ | E-UTRAN |==============| S-GW | 194 | (eNBs) | +-------+ 195 | | 196 +-----------+ 198 Figure 1: EPS (non-roaming) architecture overview 200 3. CONEX Use Cases in the Mobile Communication Scenario 202 In general, quality of service and good network resource utilization 203 are important requirements for mobile communication network 204 operators. Radio access and backhaul networks are considered scarce 205 resources, and bandwidth (and radio resource) demand is difficult to 206 predict precisely due to user mobility, radio propagation effects 207 etc. Hence today's architectures and protocols go to significant 208 extent in order to provide network-controlled quality of service -- 209 for instance by 3GPP's EPS bearer model that enables the network to 210 allocate service data flows (SDFs) to certain EPS bearers with 211 specific quality of service classes (which can be used for fine- 212 granular per-application service differentiation). 214 In the following, we discuss ways how congestion exposure could be 215 beneficial for supporting resource management in such operated mobile 216 communication networks. [I-D.ietf-conex-concepts-uses] describes 217 fundamental congestion exposure concepts and a set of use cases for 218 applying congestion exposure mechanisms to realize different traffic 219 management functions, accounting etc. Here, we relate these CONEX 220 use cases to the general mobile communication scenario in order to 221 validate the use cases for this scenario. 223 3.1. CONEX as a Basis for Traffic Management 225 Traffic management is a very important function in mobile 226 communication networks. Since wireless resources are considered 227 scarce and since user mobility and shared bandwidth in the wireless 228 access create certain dynamics with respect to available bandwidth, 229 these resources are traditionally managed very tightly (admission 230 control for bearer establishment etc.). 232 In EPS, the QoS requirements for different applications running on a 233 UE is supported by a bearer concept which is managed by the network. 234 Each bearer has an associated QoS Class identifier (QCI) and an 235 Allocation and Retention Policy (ARP) that has been standardized for 236 uniform traffic handling (across implementations). For the necessary 237 QoS across the mobile network, an EPS bearer is maintained that 238 crosses different interfaces in the network and maps to lower layer 239 bearers for packet forwarding. A radio bearer transports traffic 240 between a UE and eNB whereas S1 bearer transports traffic between the 241 eNB and S-GW. Primarily LTE offers two types of bearer: Guaranteed 242 Bit rate bearer for real time communication, e.g., Voice calls etc. 243 and Non-Guaranteed bit rate, e.g., best effort traffic for web access 244 etc. Packets mapped to the same EPS bearer receive the same bearer 245 level packet forwarding treatment. 247 In the light of the significant increase of overall data volume in 3G 248 networks, Deep-Packet-Inspection (DPI) is often considered a 249 desirable function to have in the EPC -- on, for example, a PDN 250 (Packet Data Network) gateway, and some operators do in fact deploy 251 DPI today. 3GPP has a current work item on "Service Awareness and 252 Privacy Policies" that is chartered to add DPI-related extensions to 253 the PCC architecture [3GPP.23.203]. The (optional) DPI entity in the 254 EPC is called "Traffic Detection Function" (TDF), and it performs 255 application detection and reporting of detected application and its 256 service data flow description to the Policy Control and Charging 257 Rules Function (PCRF). The TDF and it can perform functions such as 258 traffic blocking, redirection, policing for selected flows. 260 Congestion exposure can be employed to address these requirements for 261 tight resource management in different ways: 263 1. It can enhance DPI by providing flow policy-based traffic 264 management. At present, DPI-based resource management is often 265 used to prioritize certain application classes with respect to 266 others in overload situations, so that effectively more users can 267 be served on the network. In overload situations, operators use 268 DPI to identify dispensable flows and make them yield to other 269 flows (of different application classes) through policing. Such 270 traffic management is thus based on static configuration and some 271 estimation about the future per-flow bandwidth demand. With 272 congestion exposure it would be possible to more accurately and 273 more timely assess the cost that certain flows are causing so 274 that policing can optimize network utilization (better than a 275 pure DPI-based approach can do). 277 2. It can eventually make DPI obsolete by allowing for a bulk packet 278 traffic management that does not have to consider flows' 279 application classes and individual sessions. Instead traffic 280 management would be based on the current cost (contribution to 281 congestion) incurred by different flows and enable operators to 282 apply policing/accounting depending on their preference. Such 283 traffic management would be simpler and more robust (no real-time 284 flow application type identification required, no static 285 configuration of application classes) and perform better as 286 decisions can be taken based on real-time actual cost 287 contribution. 289 In summary, it can be said that traffic management in 3GPP EPS and 290 other mobile communication architectures in very important. 291 Previously more static approaches based on admission control and 292 static QoS have been applied, but recently, there has been a 293 perceived need for more dynamic mechanisms such as DPI. Adding CONEX 294 support might thus require revisiting the PCC architecture, depending 295 on the scope and impact of a CONEX-based traffic management approach. 297 3.2. CONEX to Incentivize Scavenger Transports 299 As 3G and LTE networks are turning into universal access networks 300 that are shared between mobile (smart) phone users, mobile users with 301 laptop PCs, home users with LTE access etc., it is likely that 302 capacity-sharing among different users and application flows becomes 303 more important in the mobile communication network as a fine-granular 304 differentiation would be too costly. 306 Most of this traffic is likely to be classified as best-effort 307 traffic, without differentiating (for example) periodic OS updates, 308 application store downloads from web (browser)-based or other more 309 real-time communication. Having said that, the general argument for 310 scavenger transports apply. Especially when wireless and backhaul 311 resources are scarce, incentivizing users to use less-than best 312 effort transport for non-interactive background communication would 313 improve the overall utility of the network. It can be argued that, 314 if this would be done with a CONEX approach, it could be in a more 315 effective and cost-efficient way compared to the mentioned DPI 316 mechanisms. 318 This would work best, if the network did not do any traffic class 319 segregation below the IP layer, i.e., if all traffic would be in the 320 same traffic class. With current specifications, that would be 321 possible in principle. 323 3.3. Accounting for Congestion Volume 325 3G and LTE networks provide extensive support for accounting and 326 charging already, for example cf. the Policy Charging Control (PCC) 327 architecture. In fact, most operators today account transmitted data 328 volume on a very fine granular basis and either correlate monthly 329 charging to the exact number of packets/bytes transmitted, or employ 330 some form of flat rate (or flexible flat rate), often with a so- 331 called fair-use policy. With such policies, users are typically 332 limited to an administratively configured maximum bandwidth limit, 333 after they have used their data contractual volume budget for the 334 charging period. 336 Changing this data volume-based accounting to a congestion-based 337 accounting would be possible in principle, especially since there 338 already is an elaborate per-user accounting system available. Also, 339 an operator-provided mobile communication network can be seen as a 340 network domain within such congestion volume accounting would be 341 possible, without requiring any support from the global Internet. 342 Traffic normally leaves/enters the operator's network via well- 343 defined egress/ingress points that would be ideal candidates for 344 policing functions. Moreover, in most commercially operated 345 networks, the user is accounted for both received and sent data, 346 which would facilitate congestion volume accounting as well. 348 With respect to the current PCC framework, accounting for congestion 349 volume could be added as another feature to the "Usage Monitoring 350 Control" capability that is currently based on data volume. This 351 would not require any new interface (reference points) at all. 353 3.4. CONEX as a Form of Differential QoS 355 As mentioned above, 3GPP mobile communication networks provide an 356 elaborate QoS architecture. In LTE, the idea is to map different 357 traffic classes onto different logical channels (bearers) with 358 individual QoS configuration. 360 It can be argued whether this approach is sufficient in a world where 361 most traffic is on TCP port 80 and whether some more application 362 control would be useful. 364 With CONEX, accurate downstream path information would be visible to 365 ingress network operators, which can respond to incipient congestion 366 in time. This can be equivalent to offering different levels of QoS, 367 e.g. premium service with zero congestion response. 369 Again, CONEX could be used in two different ways: 371 1. as additional information to assist network functions to impose 372 different QoS for different application sessions; and 374 2. as a tool to let applications decide on their response to 375 congestion notification, while incentivizing them to react (in 376 general) appropriately, e.g., by enforcing overall limits for 377 congestion contribution or by accounting and charging for such 378 congestion contribution. 380 3.5. Partial vs. Full Deployment 382 In general CONEX lends itself to partial deployment as the mechanism 383 does not require all routers and hosts to support congestion 384 exposure. Moreover, assuming a policing infrastructure has been put 385 in place, it is not required to modify all hosts. Since CONEX is 386 about senders exposing congestion contribution to the network, 387 senders need to be made supporting CONEX (assuming a congestion 388 notification mechanisms such as ECN is in place). 390 [I-D.briscoe-conex-initial-deploy] provides specific examples of how 391 CONEX deployment can be initiated, focusing unilaterial deployment by 392 single networks, i.e., by partial deployment. 394 In mobile communication networks that would for example allow early 395 partial CONEX deployment in the downlink direction only, i.e., 396 servers, gateways and caches would support CONEX but UEs (mobile 397 hosts) would not. 399 When moving towards full deployment in a specific operator's network, 400 different ways for introducing CONEX support on UEs are feasible. 401 Since mobile communication networks are multi-vendor networks, 402 standardizing CONEX support on UEs (e.g., in 3GPP specifications) 403 appears useful. Still, not all UEs would have to support CONEX, and 404 operators would be free to choose their policing approach in such 405 deployment scenarios. Leveraging existing PCC architectures, 3GPP 406 network operators could for example decide policing/accounting 407 approaches per UE -- i.e., apply fixed volume caps for non-CONEX UEs 408 and more flexible schemes for CONEX-enabled UEs. 410 Moreover, it should be noted that network support for CONEX is a 411 feature that some operators may implement to deploy if they wish, but 412 it is not required that all operators (or all other networks) do so. 414 Depending on the extent of CONEX support, specific aspects such as 415 roaming have to be taken into account. I.e., what happens when a 416 user is roaming in a CONEX-enabled network, but their UE is not 417 CONEX-enabled and vice versa. Although these may not be fundamental 418 problems, they need to be considered. For supporting mobility in 419 general, it can be required to shift users' policing state during 420 hand-over. There is existing work in [raghavan2007] on distributed 421 rate limiting and in [nec.euronf-2011] on specific optimizations for 422 congestion exposure and policing in mobility scenarios. 424 Another aspect to consider is the addition of Selected IP Traffic 425 Offload (SIPTO) and Local Breakout (LIPA), also see [3GPP.23.829], 426 i.e., the idea that some traffic (e.g., high-volume Internet traffic) 427 is actually not passed through the EPC but is offloaded at a "break- 428 out point" closer to (or in) the access network. On the other hand, 429 CONEX can also enable more dynamic decisions on what traffic to 430 actually offload by considering congestion exposure in bulk traffic 431 aggregates -- thus making traffic offload more effective. 433 3.6. Summary 435 In summary, the 3GPP EPS is a system architecture that can benefit 436 from congestion exposure in multiple ways, as we have shown by this 437 brief description of CONEX use cases in this environment. Dynamic 438 traffic and congestion management is an acknowledged important 439 requirement for the EPS, also illustrated by the current DPI work for 440 EPS. 442 Moreover, we believe that networks such as an EPS mobile 443 communication network would be quite amenable for deploying CONEX as 444 a mechanism, since they represent clearly defined and well separated 445 operational domains, in which local CONEX deployment would be 446 possible. Aside from roaming (which needs to be considered for a 447 specific solution), a single mobile network deployment is under full 448 control of a single operator, which can enable operator-local 449 enhancement without the need to change the complete architecture. 451 In 3GPP EPS, interfaces between all elements of the architecture are 452 subject to standardization, including UE interfaces and eNodeB 453 interfaces, so that a more general approach, involving more than one 454 single operator's network, can be feasible as well. 456 4. CONEX in the EPS 458 The CONEX mechanism is still work in progress in the IETF working 459 group. Still, we would like to discuss a few options for how such a 460 mechanism (and possibly additional policing functions) could 461 eventually be deployed in 3GPP's EPS. Note that this description of 462 options is not intended as a complete set of possible approaches -- 463 it is merely intended for discussing a few options. More details 464 will be provided in a future revision of this document. 466 4.1. Possible Deployment Scenarios 468 There are different possible ways how CONEX functions on hosts and 469 network elements can be used. For example, CONEX could be used for a 470 limited part of the network only -- e.g., for the access network -- 471 congestion exposure and sender adaptation could involve the mobile 472 nodes or not, or, finally, the CONEX feedback loop could extend 473 beyond a single operator's domain or not. 475 We present three different deployment scenarios for congestion 476 exposure in the figures below: 478 1. In Figure 2 CONEX is supported by servers for sending data (here: 479 web servers in the Internet and caches in an operator's network) 480 but not by UEs (neither for receiving nor sending). An operator 481 who chooses to run a policing function on the network ingress 482 (e.g., on the P-GW) can still benefit from congestion exposure 483 without requiring any change on UEs. 485 2. CONEX is universally employed between operators (as depicted in 486 Figure 3), with an end-to-end CONEX feedback loop. Here, 487 operators could still employ local policies, congestion 488 accounting schemes etc., and they could use information about 489 congestion contribution for determining interconnection 490 agreements. 492 3. Isolated CONEX domains as depicted in Figure 4, CONEX is solely 493 applied locally, in the operator network, and there is no end-to- 494 end congestion exposure. This could be the case when CONEX is 495 only implemented in a few networks, or when operators decide to 496 not expose ECN and account for congestion for inter-domain 497 traffic. Independent of the actual scenario, it is likely that 498 there will be border gateways (as in today's deployments) that 499 are associated with policing and accounting functions. 501 +------------+ 502 | Web server | 503 | w/ CONEX | 504 +------------+ 505 | 506 | 507 | 508 ----------------------- 509 | | | 510 | Internet | | 511 | | | 512 ----------------------- 513 | 514 --------------------------------------------|-------- 515 | | | 516 | +-----------+ | 517 | | Web cache | | 518 | | w/ CONEX | | 519 | +-----------+ | 520 | | | 521 | +----+ +-------+ +-------+ +-------+ | 522 | | UE |=====| eNB |=====| S-GW |=====| P-GW | | 523 | +----+ +-------+ +-------+ +-------+ | 524 | | 525 | Operator B | 526 ----------------------------------------------------- 528 Figure 2: CONEX support on servers and caches 530 ----------------------------------------------------- 531 | +----+ +-------+ +-------+ +-------+ | 532 | | UE |=====| eNB |=====| S-GW |=====| P-GW | | 533 | +----+ +-------+ +-------+ +-------+ | 534 | | | 535 | Operator A | | 536 --------------------------------------------|-------- 537 | 538 ----------------------- 539 | | 540 | Internet | 541 | | 542 ----------------------- 543 | 544 --------------------------------------------|-------- 545 | +----+ +-------+ +-------+ +-------+ | 546 | | UE |=====| eNB |=====| S-GW |=====| P-GW | | 547 | +----+ +-------+ +-------+ +-------+ | 548 | | 549 | Operator B | 550 ----------------------------------------------------- 552 Figure 3: CONEX deployment across operator domains 554 ----------------------------------------------------- 555 | |--- CONEX path ---| | 556 | v v 557 | +----+ +-------+ +-------+ +-------+ | 558 | | UE |=====| eNB |=====| S-GW |=====| P-GW | | 559 | +----+ +-------+ +-------+ +-------+ | 560 | | | 561 | Operator A | | 562 --------------------------------------------|-------- 563 | 564 ----------------------- 565 | | 566 | Internet | 567 | | 568 ----------------------- 569 | 570 --------------------------------------------|-------- 571 | +----+ +-------+ +-------+ +-------+ | 572 | | UE |=====| eNB |=====| S-GW |=====| P-GW | | 573 | +----+ +-------+ +-------+ +-------+ | 574 | | 575 | Operator B | 576 ----------------------------------------------------- 578 Figure 4: CONEX deployment in a single operator domain 580 We consider all three scenarios to be relevant and believe that both 581 of them are within the scope of the CONEX WG charter. A more 582 detailed description will be provided in a future version of this 583 document. 585 4.2. Implementing CONEX Functions in the EPS 587 We expect a CONEX solution to consist of different functions that 588 should be considered when implementing congestion exposure in 3GPP's 589 EPS. [I-D.ietf-conex-abstract-mech] is describing the following 590 congestion exposure components: 592 o Modified senders that send congestion exposure information in 593 response to congestion feedback). 595 o Receivers that generate congestion feedback (leveraging existing 596 behavior or requiring new functions). 598 o Audit functions that audit CONEX signals against actual 599 congestion, e.g., by monitoring flows or aggregate of flows. 601 o Policy devices that monitor congestion exposure information and 602 act on the flows according to the operator's policy. 604 Two aspects are important to consider: 1) how would the CONEX 605 protocol mechanisms be implemented and what modifications to existing 606 networks would be required and 2) where would CONEX functional 607 entities be placed best (to allow for a non-invasive addition). We 608 discuss these two aspects in the following sections. 610 4.2.1. CONEX Protocol Mechanisms 612 As described in [I-D.briscoe-conex-initial-deploy], the most 613 important component for introducing CONEX (initially) is adding the 614 congestion exposure functionality to senders. For an initial 615 deployment, no further modification to senders and receivers would be 616 required. Specifically, there is no fundamental dependency on ECN, 617 i.e., CONEX can be introduced without requiring ECN to be 618 implemented. 620 Congestion exposure information for IPv6 [I-D.ietf-conex-destopt] is 621 represented in a destination option header field, which requires 622 minimal changes at senders and nodes that want to assess path 623 congestion -- and that does not affect non-CONEX nodes in a network. 625 In 3GPP networks, IP tunneling is used intensively, i.e., using 626 either IP-in-GTP-U or PMIP (i.e., IP-in-IP) tunnels. In general, the 627 CONEX destination option of encapsulated packets should be made 628 available for network nodes on the tunnel path, i.e., a tunnel 629 ingress should copy the CONEX destination option field to the outer 630 header. Details will be provided in a future version of this 631 document. 633 For an effective and efficient capacity sharing, we envisage the 634 deployment of ECN in conjunction with CONEX so that ECN-enabled 635 receivers and senders get more accurate and more timely information 636 about their flows congestion contribution. ECN is already partially 637 introduced into 3GPP networks: Section 11.6 in [3GPP.36.300] 638 specifies the usage of ECN for congestion notification on the radio 639 link (between eNB and UE), and [3GPP.26.114] specifies how this can 640 be leveraged for voice codec adaptation. A complete, end-to-end 641 support of ECN would require specification of tunneling behaviour, 642 which should be based on [RFC6040] (for IP-in-IP tunnels) and on 643 [I-D.briscoe-tsvwg-ecn-encap-guidelines]. Specifically, a 644 specification for tunneling ECN in GTP-U will be needed. 646 4.2.2. CONEX Functions in the Mobile Network 648 In the following, we discuss some possible placement strategies for 649 CONEX functional entities (addressing both policing and auditing 650 functions) in the EPS and for possible optimizations for both the 651 uplink and the downlink. 653 In general, CONEX information (exposed congestion) is declared by a 654 sender and remains unchanged on the path, hence reading CONEX 655 information (e.g., by policing functions) is placement-agnostic. 656 Auditing CONEX normally requires assessing declared congestion 657 contribution and current actual congestion. If the latter is, for 658 example, done using ECN, such a function would best be placed at the 659 end of the path. 661 In order to provide a comprehensive CONEX-based capacity management 662 framework for EPS, it would be advantageous to consider user 663 contribution to congestion for both the radio access and the core 664 network. For a non-invasive introduction of CONEX, it can be 665 beneficial to combine CONEX functions with existing logical EPS 666 entities. For example, potential places for CONEX policing and 667 auditing functions would then be eNBs, S-GWs or the P-GWs. Operator 668 deployments may of course still provide additional intermediary 669 CONEX-enabled IP network elements. 671 For a more specific discussion it will be beneficial to distinguish 672 downlink and uplink traffic directions (also see [nec.globecom2010] 673 for a more detailed discussion). In today's networks and usage 674 models, downlink traffic is dominating (also reflected by the 675 different maximum capacity provided by the air interface). That does 676 however not imply that uplink congestion is not an issue, since the 677 asymmetric maximum bandwidth configuration can create a smaller 678 bottleneck for uplink traffic -- and there are of course backhaul 679 links, gateways etc. that can be overloaded as well. 681 For managing downlink traffic -- e.g., in scenarios such as the one 682 depicted in Figure 2, operators can have different requirements for 683 policing traffic. Although policing is in principle location- 684 agnostic, it is important to consider requirements related to the EPS 685 architecture (Figure 1) such as tunneling between P-GWs and eNBs. 686 Policing can require access to subscriber information (e.g., 687 congestion contribution quota) or user-specific accounting, which 688 suggests that the CONEX function could be co-located with the P-GW 689 that already has a PCRF interface. 691 Still, policing can serve different purposes. For example, if the 692 objective is to police bulk traffic induced by peer networks, 693 additional monitoring functions can be placed directly at 694 corresponding ingress points to monitor traffic and possible drive 695 out-of-band functions such as triggering border contract penalties. 697 The auditing function which should be placed at the end of the path 698 (at least after/at the last bottleneck) would likely be placed best 699 on the eNB (wireless base station). 701 For the uplink direction, there are naturally different options for 702 designing monitoring and policy enforcement functions. A likely 703 approach can be to monitor congestion exposure on central gateway 704 nodes (such as P-GWs) that provide the required interfaces to the 705 PCRF, but to perform policing actions in the access network, i.e., in 706 eNBs, e.g., to police traffic at the ingress, before it reaches 707 concentration points in the core network. 709 Such a setup would enable all the CONEX use cases described in 710 Section 3, without requiring significant changes to the EPS 711 architecture, while enabling operators to re-use existing 712 infrastructure, specifically wireless base stations, PCRF and HSS 713 systems. 715 For CONEX functions on elements such as the S-GWs and P-GWs, it is 716 important to consider mobility and tunneling protocol requirements. 717 LTE provides two alternative approaches: Proxy-Mobile-IP (PMIP, 718 [3GPP.23.402]) and GPRS Tunneling Protocol (GTP). For the 719 propagation of congestion information (responses) tunneling 720 considerations are therefore very important. 722 In general, policing will be done based on per-user (per subscriber) 723 information such as congestion quota, current quota usage etc. and 724 network operator policies, e.g., specifying how to react to 725 persistent congestion contribution etc. In the EPS, per-user 726 information is normally part of the user profile (stored in the HSS) 727 that would be accessed by PCC entities such as the PCRF for dynamic 728 updates, enforcement etc. 730 A more detailed description of the different approaches and their 731 respective advantages will be provided in a future revision of this 732 document. 734 5. Summary 736 We have shown how congestion exposure can be useful for efficient 737 resource management in mobile communication networks. The premise 738 for this discussion was the observation that data communication, 739 specifically best-effort bulk data transmission, is becoming a 740 commodity service whereas resources are obviously still limited -- 741 which calls for efficient, scalable, yet effective capacity sharing 742 in such networks. 744 CONEX can be a mechanism that enables such capacity sharing, while 745 allowing operators to apply these mechanisms in different ways, e.g., 746 for implementing different use cases as described in Section 3. It 747 is important to note that CONEX is fundamentally a mechanism that can 748 be applied in different ways -- to realize different operators 749 policies. 751 We have described a few possibilities for adding CONEX as a mechanism 752 to 3GPP LTE-based networks and have shown how this could be done 753 incrementally (starting with partial deployment). It is quite 754 feasible that such partial deployments be done on a per-operator- 755 domain basis, without requiring changes to standard 3GPP interfaces. 756 For a network-wide deployment, e.g., with congestion exposure between 757 operators, more considerations might be needed. 759 We have also identified a few implications/requirements that should 760 be taken into consideration when enabling congestion exposure in such 761 networks: 763 Performance: In mobile communication networks -- with more expensive 764 resources and more stringent QoS requirements -- the feasibility 765 of applying CONEX as well as its performance and deployment 766 scenarios need to be examined closer. For instance, a mobile 767 communication network may encounter longer delay and higher loss 768 rates, which can impose specific requirements on the timeliness 769 and accuracy of congestion exposure information. 771 Mobility: One of the unique characteristics in cellular network is 772 the presence of user mobility compared to wired networks. As the 773 user location changes, the same device can be connected to the 774 network via different base stations (eNodeBs) or even go through 775 switching gateways. Thus, the CONEX scheme must to be able to 776 carry latest congestion information per user/flow across multiple 777 network nodes in real time. 779 Multi-access: In cellular network, multiple access technologies can 780 co-exist. In such cases, a user can use multiple access 781 technologies for multiple applications or even a single 782 application simultaneously. If the congestion policies are set 783 based on each user, then CONEX should have the capability to 784 enable information exchange across multiple access domains. 786 Tunneling: Both 3G and LTE networks make extensive usage of 787 tunneling. The CONEX mechanism should be designed in a way to 788 support usage with different tunneling protocols such as PMIP and 789 GTP. For ECN-based congestion notification, [RFC6040] specifies 790 how the ECN field of the IP header should be constructed on entry 791 and exit from IP-in-IP tunnels, and 792 [I-D.briscoe-tsvwg-ecn-encap-guidelines] provides guidelines for 793 adding congestion notification to protocols that encapsulate IP. 795 Roaming: Independent of the specific architecture, mobile 796 communication networks typically differentiate between non-roaming 797 and roaming scenarios. Roaming scenarios are typically more 798 demanding regarding implementing operator policies, charging etc. 799 It can be expected that this would also hold for deploying CONEX. 800 A more detailed analysis of this problem will be provided in a 801 future revision of this document. 803 It is important to note that CONEX is intended to be used as a 804 supplement and not a replacement to the existing QoS mechanisms in 805 mobile networks. For example, CONEX deployed in 3GPP mobile networks 806 can provide useful input to the existing 3GPP PCC mechanisms by 807 supplying more dynamic network information to supplement the fairly 808 static information used by the PCC. This would enable the mobile 809 network to make better policy control decisions than is possible with 810 only static information. 812 6. IANA Considerations 814 No IANA considerations. 816 7. Security Considerations 818 Security considerations for applying CONEX to EPS include, but are 819 not limited to, the security considerations that apply to the CONEX 820 protocols. 822 8. Informative References 824 [3GPP.23.203] 825 3GPP, "Policy and charging control architecture", 3GPP 826 TS 23.203 10.5.0, December 2011. 828 [3GPP.23.402] 829 3GPP, "Architecture enhancements for non-3GPP accesses", 830 3GPP TS 23.402 10.6.0, December 2011. 832 [3GPP.23.829] 833 3GPP, "Local IP Access and Selected IP Traffic Offload 834 (LIPA-SIPTO)", 3GPP TR 23.829 10.0.1, October 2011. 836 [3GPP.26.114] 837 3GPP, "IP Multimedia Subsystem (IMS); Multimedia 838 telephony; Media handling and interaction", 3GPP TS 26.114 839 10.2.0, December 2011. 841 [3GPP.29.060] 842 3GPP, "General Packet Radio Service (GPRS); GPRS 843 Tunnelling Protocol (GTP) across the Gn and Gp interface", 844 3GPP TS 29.060 3.19.0, March 2004. 846 [3GPP.29.274] 847 3GPP, "3GPP Evolved Packet System (EPS); Evolved General 848 Packet Radio Service (GPRS) Tunnelling Protocol for 849 Control plane (GTPv2-C); Stage 3", 3GPP TS 29.274 8.11.0, 850 December 2011. 852 [3GPP.36.300] 853 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA) 854 and Evolved Universal Terrestrial Radio Access Network 855 (E-UTRAN); Overall description; Stage 2", 3GPP TS 36.300 856 8.12.0, April 2010. 858 [I-D.briscoe-conex-initial-deploy] 859 Briscoe, B., "Initial Congestion Exposure (ConEx) 860 Deployment Examples", 861 draft-briscoe-conex-initial-deploy-01 (work in progress), 862 November 2011. 864 [I-D.briscoe-tsvwg-ecn-encap-guidelines] 865 Briscoe, B., "Guidelines for Adding Congestion 866 Notification to Protocols that Encapsulate IP", 867 draft-briscoe-tsvwg-ecn-encap-guidelines-00 (work in 868 progress), March 2011. 870 [I-D.ietf-conex-abstract-mech] 871 Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) 872 Concepts and Abstract Mechanism", 873 draft-ietf-conex-abstract-mech-03 (work in progress), 874 October 2011. 876 [I-D.ietf-conex-concepts-uses] 877 Briscoe, B., Woundy, R., and A. Cooper, "ConEx Concepts 878 and Use Cases", draft-ietf-conex-concepts-uses-04 (work in 879 progress), March 2012. 881 [I-D.ietf-conex-destopt] 882 Krishnan, S., Kuehlewind, M., and C. Ucendo, "IPv6 883 Destination Option for Conex", draft-ietf-conex-destopt-01 884 (work in progress), October 2011. 886 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 887 Notification", RFC 6040, November 2010. 889 [nec.euronf-2011] 890 Mir, Kutscher, and Brunner, "Congestion Exposure in 891 Mobility Scenarios", in proceedings of 7th EURO-NF 892 CONFERENCE ON NEXT GENERATION INTERNET, June 2011. 894 [nec.globecom2010] 895 Kutscher, Lundqvist, and Mir, "Congestion Exposure in 896 Mobile Wireless Communications", in proceedings of IEEE 897 GLOBECOM 2010, December 2010. 899 [raghavan2007] 900 Raghavan, Vishwanath, Ramabhadran, Yocum, and Snoeren, 901 "Cloud Control with Distributed Rate Limiting", in 902 proceedings of ACM SIGCOMM 2007, 2007. 904 DOI: http://doi.acm.org/10.1145/1282427.1282419 906 Appendix A. Acknowledgments 908 We would like to thank Bob Briscoe and Ingemar Johansson for their 909 support in shaping the overall idea and in improving the draft by 910 providing constructive comments. 912 Authors' Addresses 914 Dirk Kutscher 915 NEC 916 Kurfuersten-Anlage 36 917 Heidelberg, 918 Germany 920 Phone: 921 Email: kutscher@neclab.eu 922 Faisal Ghias Mir 923 NEC 924 Kurfuersten-Anlage 36 925 Heidelberg, 926 Germany 928 Phone: 929 Email: faisal.mir@neclab.eu 931 Rolf Winter 932 NEC 933 Kurfuersten-Anlage 36 934 Heidelberg, 935 Germany 937 Phone: 938 Email: winter@neclab.eu 940 Suresh Krishnan 941 Ericsson 942 8400 Blvd Decarie 943 Town of Mount Royal, Quebec 944 Canada 946 Phone: 947 Email: suresh.krishnan@ericsson.com 949 Carlos Jesus Bernardos Cano 950 Universidad Carlos III de Madrid 952 Email: cjbc@it.uc3m.es