idnits 2.17.1 draft-kutscher-conex-mobile-00.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 7, 2011) is 4796 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-ietf-conex-concepts-uses-00 Summary: 0 errors (**), 0 flaws (~~), 3 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 8, 2011 NEC 6 S. Krishnan 7 Y. Zhang 8 Ericsson 9 March 7, 2011 11 Mobile Communication Congestion Exposure Scenario 12 draft-kutscher-conex-mobile-00 14 Abstract 16 This memo describes a mobile communications use case for congestion 17 exposure (CONEX) with a particular focus on mobile communication 18 networks such as 3GPP LTE. The draft describes the architecture of 19 these networks (access and core networks), current QoS mechanisms and 20 then discusses how congestion exposure concepts could be applied. 21 Based on this, this memo suggests a set of requirements for CONEX 22 mechanisms that particularly apply to mobile networks. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 8, 2011. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Overview of 3GPP's Evolved Packet System (EPS) . . . . . . . . 3 57 3. CONEX Use Cases in the Mobile Communication Scenario . . . . . 5 58 3.1. CONEX as a basis for traffic management . . . . . . . . . 6 59 3.2. CONEX to incentivize scavenger transports . . . . . . . . 6 60 3.3. Accounting for Congestion Volume . . . . . . . . . . . . . 7 61 3.4. CONEX as a form of differential QoS . . . . . . . . . . . 7 62 3.5. Partial vs. Full Deployment . . . . . . . . . . . . . . . 8 63 3.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 4. CONEX in the EPS . . . . . . . . . . . . . . . . . . . . . . . 9 65 4.1. Possible Deployment Scenarios . . . . . . . . . . . . . . 9 66 4.2. Implementing CONEX Functions in the EPS . . . . . . . . . 11 67 5. Implications for CONEX . . . . . . . . . . . . . . . . . . . . 13 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 73 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 15 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 76 1. Introduction 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in RFC 2119 [RFC2119]. 82 Mobile data traffic continues to grows rapidly. The challenge 83 wireless operators face is to support more subscribers with higher 84 bandwidth requirements. To meet the bandwidth demand, operators need 85 to seek for new technologies to efficiently utilize the available 86 network resources, in particular, this concerns resource allocation 87 and flow management. Ample statistics for network traffic from 88 cellular networks are available, stating that many short flows exist, 89 but that a few large flows constitute a large part of the overall 90 traffic volume. Measurement studies have shown that a small number 91 of users is responsible for the most part of the traffic in cellular 92 networks. With the highly skewed network access behavior, more 93 expensive resources in cellular networks as compared to other 94 networks and the rapidly increasing network utilization, resource 95 allocation and usage accountability are two important issues for 96 operators to solve in order to achieve a better, accountable network 97 resource utilization. CONEX, as described in 98 [I-D.ietf-conex-concepts-uses] is a technology to base this upon. 100 The CONEX congestion exposure mechanism is intended as a general 101 technology that could be applied as a key element of congestion 102 management solutions in a variety of use cases. The IETF CONEX WG 103 will however work on a specific use case, where the end hosts and the 104 network that contains the destination end host are CONEX-enabled but 105 other networks need not be. 107 A specific example of such a use case can be a mobile communication 108 network such as a 3GPP LTE network, where the UE (User Equipment, 109 i.e. mobile end host), its access network and possibly an operator's 110 core network can be CONEX-enabled. This draft describes the 111 architecture of such networks (access and core networks), current QoS 112 mechanisms and then discusses how congestion exposure concepts could 113 be applied. Using this use case as a basis, a set of requirements 114 for CONEX mechanisms are described. 116 2. Overview of 3GPP's Evolved Packet System (EPS) 118 This section provides an overview of 3GPP's "Evolved Packet System" 119 (EPS [3GPP.36.300]) as a specific example of a mobile communication 120 architecture in order to illustrate congestion exposure applicability 121 in this memo. There are other mobile communication architectures. 123 The EPS architecture and its standardized interfaces are depicted in 124 Figure 1. The EPS provides IP connectivity to UEs (user equipment, 125 i.e., mobile nodes) and access to operator services, such as global 126 Internet access and voice communications. The EPS comprises the 127 access (evolved UMTS Terrestrial Radio Access Network, E-UTRAN) and 128 the core network (Evolved Packet Core, EPC). QoS is supported 129 through an EPS bearer concept, providing hierarchical bindings within 130 the network. 132 The evolved NodeB (eNB), the LTE base station, is part of the access 133 network that provides radio resource management, header compression, 134 security and connectivity to the core network through the S1 135 interface. In LTE an network, the control plane signaling traffic 136 and the data traffic are handled separately. The eNBs transmit the 137 control traffic and data traffic separately via two logically 138 different interfaces. 140 The Home Subscriber Server, HSS, is a database that contains users 141 subscription and QoS profile. The Mobility Management Entity, MME, 142 is responsible for user authentication, bearer establishment and 143 modification and maintenance of the UE context. 145 The Serving gateway, S-GW, is the mobility anchor and manages the 146 user plane data tunnels during the inter-eNB handovers. It tunnels 147 all user data packets and buffers downlink IP packets destined for 148 UEs that happen to be in idle mode. 150 The Packet Gateway, P-GW, is responsible for IP address allocation to 151 the UE and is a tunnel endpoint for mobility protocols. It is also 152 responsible for charging, packet filtering, and policy-based control 153 of flows. It interconnects the mobile network to external IP 154 networks, e.g. the Internet. 156 In this architecture, data packets are not sent directly on an IP 157 network between the eNB and the GWs. Instead, every packet is sent 158 in a tunneling protocol - the GPRS Tunneling Protocol (GTP 159 [3GPP.29.060]) over UDP/IP. A GTP path is identified in each node 160 with the IP address and a UDP port number on the eNB/GWs. The GTP 161 protocol carries both the data traffic (GTP-U tunnels) and the 162 control traffic (GTP-C tunnels [3GPP.29.274]). 164 The above is very different from an end-to-end path on the Internet 165 where the packet forwarding is performed at the IP level. 166 Importantly, we observe that these tunneling protocols give the 167 operator a large degree of flexibility to control the congestion 168 mechanism incorporated with the GTP protocols. 170 +-------+ 171 +-------+ | PCRF | 172 | HSS | /+-------+\ 173 +-------+ Gx/ \Rx 174 | / \ 175 | / \ 176 | +-------+ SGi +-------+ 177 | | PDN |=========|IP Svr | 178 | +-------+ +-------+ 179 HPMN | | 180 ------------------------------|--------------|---------------------- 181 VPLMN | | 182 +-------+ | 183 | MME | | 184 /+-------+\ |S8 185 S1-MME / \ | 186 / \S11 | 187 / \ | 188 +-----------+ \ | 189 +----+ LTE-Uu | | \ | 190 | UE |========| | S1-U +-------+ 191 +----+ | E-UTRAN |==============| S-GW | 192 | | +-------+ 193 | | 194 +-----------+ 196 Figure 1: EPS Architecture Overview 198 3. CONEX Use Cases in the Mobile Communication Scenario 200 Given the initial scope of CONEX, the problem that mobile operators 201 are facing and large networks that are under tight operator control, 202 including the mobile end devices to a certain extend, the LTE use 203 case appears to be an ideal first target deployment scenario. In 204 addition, mobile networks already have many of the principle 205 functions that the CONEX use cases require such as accounting. 206 Mobile networks however have characteristics that differ 207 significantly enough from fixed network architectures that these 208 should be taken into account. 210 [I-D.ietf-conex-concepts-uses] describes fundamental congestion 211 exposure concepts and a set of use cases for applying congestion 212 exposure mechanisms to achieve different functions in traffic 213 management, accounting etc. In this section, we relate these CONEX 214 use cases to the general mobile communication scenario in order to 215 validate the use cases for this scenario. 217 3.1. CONEX as a basis for traffic management 219 Traffic management is a very important function in mobile 220 communication networks. Since wireless resources have been 221 considered scarce and since user mobility and shared bandwidth in the 222 wireless access create a certain dynamics with respect to available 223 bandwidth, these resources are traditionally managed very tightly 224 (admission control for bearers establishment etc.) 226 In LTE, the QoS requirements for different applications running on a 227 UE is supported by a bearer concept which is managed by the network. 228 Each bearer has an associated QoS Class identifier (QCI) and an 229 Allocation and retention policy (ARP) that has been standardized for 230 uniform traffic handling (across implementations). For the necessary 231 QoS across the mobile network, an EPS bearer is maintained that 232 crosses different interfaces in the network and maps to lower layer 233 bearers for packet forwarding. A radio bearer transports traffic 234 between a UE and eNB whereas S1 bearer transports traffic between the 235 eNB and S-GW. Primarily LTE offers two types of bearer: Guaranteed 236 Bit rate bearer for real time communication, e.g., Voice calls etc 237 and Non-Guaranteed bit rate, e.g., best effort traffic for web access 238 etc. Packets mapped to the same EPS bearer receive the same bearer 239 level packet forwarding treatment. 241 In the light of the significant increase of overall data volume in 3G 242 networks, Deep-Packet-Inspection (DPI) is often considered a 243 desirable function to have in the EPC -- on, for example, a PDN 244 gateway, and some operators do in fact deploy DPI today. 3GPP has a 245 current work item on "Service Awareness and Privacy Policies" that is 246 chartered to add DPI-related extensions to the PCC architecture 247 [3GPP.23.203]. 249 In summary, it can be said that traffic management in 3GPP EPS and 250 other mobile communication architectures in very important. 251 Previously more static approach based on admission control and static 252 QoS have been applied, but recently, there has been a perceived need 253 for more dynamic mechanisms such as DPI. Adding CONEX support might 254 thus require revisiting the PCC architecture, depending on the scope 255 and impact of a CONEX-based traffic management approach. 257 3.2. CONEX to incentivize scavenger transports 259 As 3G and LTE networks are turning into universal access networks 260 that are shared between mobile (smart) phone users, mobile users with 261 laptop PC, home users with LTE access etc., the mobile communication 262 network will be used like any other access network, i.e., different 263 applications from different users compete for bandwidth. 265 Most of this traffic is likely to be classified as best-effort 266 traffic, so that it will eventually be difficult to distinguish 267 periodic OS updates, application store downloads from web (browser)- 268 based communication (this is reflected by the current DPI activities 269 in 3GPP). Having said that, the general argument for scavenger 270 transports apply. Especially when wireless and backhaul resources 271 are scarce, incentivizing users to use less-than best effort 272 transport for non-interactive background communication would improve 273 the overall utility of the network. It can be argued that, if this 274 would be done with a CONEX approach, much of the envisioned DPI 275 mechanisms would not be needed. 277 This would work best, if the network did not do any traffic class 278 segregation below the IP layer, i.e., if all traffic would be in the 279 same traffic class. With current specifications, that would be 280 possible in principle. 282 3.3. Accounting for Congestion Volume 284 3G and LTE networks provide extensive support for accounting and 285 charging already, for example cf. the PCC architecture. In fact, 286 most operators today account transmitted data volume on a very fine 287 granular basis and either correlate monthly charging to the exact 288 number of packets/bytes transmitted, or employ some form of flat rate 289 (or flexible flat rate), often with a so-called fair-use policy. 290 With such policies, users are typically limited to an 291 administratively configured maximum bandwidth limit, after they have 292 used their data contractual volume budget for the charging period. 294 Changing this data volume-based accounting to a congestion-based 295 accounting would be possible in principle, especially since there 296 already is an elaborated per-user accounting system available. Also, 297 an operator-provided mobile communication network can be seen as a 298 network domain within such congestion volume accounting would be 299 possible, without requiring any support from the global Internet. 300 Traffic normally leaves/enters the operator's network via well- 301 defined egress/ingress points that would be ideal candidates for 302 policing functions. Moreover, in most commercially operated 303 networks, the user is accounted for both received and sent data, 304 which would facilitate congestion volume accounting as well. 306 3.4. CONEX as a form of differential QoS 308 As mentioned above, 3GPP mobile communication networks provide an 309 elaborate QoS architecture. In LTE, the idea is to map different 310 traffic classes onto different logical channels (bearers) with 311 individual QoS configuration. 313 It can be argued whether this approach is sufficient in a world where 314 most traffic is on TCP port 80 and whether some more application 315 control would be useful. 317 With CONEX, accurate downstream path information would be visible to 318 ingress network operators, which can respond to incipient congestion 319 in time. This can be equivalent to offering different levels of QoS, 320 e.g. premium service with zero congestion response. 322 3.5. Partial vs. Full Deployment 324 A 3GPP mobile communication network can be seen as separate network 325 domain that would enable the introduction of CONEX through a careful 326 standardization of interfaces and behavior of its system elements. 327 While it can be possible to deploy CONEX in a single operator's 328 network only, it may in fact not be practical, since support on 329 mobile nodes (UEs) may be required to actually implement the host end 330 transport mechanisms. 332 Aspects such as roaming have to be considered, i.e., what happens if 333 a user is roaming in a CONEX-enabled network, but their UE is not 334 CONEX-enabled and vice versa. Although these may not be fundamental 335 problems, they need to be considered. 337 Another aspect to consider is the addition of Selected IP Traffic 338 Offload (SIPTO) and Local Breakout (LIPA), also see [3GPP.23.829], 339 i.e., the idea that some traffic (e.g., high-volume Internet traffic) 340 is actually not passed through the EPC but is offloaded at a "break- 341 out point" closer to (or in) the access network. 343 3.6. Summary 345 In summary, the 3GPP EPS in a system architecture that can benefit 346 from congestion exposure in multiple ways, as we have shown by this 347 brief description of CONEX use cases in this environment. Dynamic 348 traffic and congestion management is an acknowledged important 349 requirement for the EPS, also illustrated by the current DPI work for 350 EPS. 352 Moreover, we believe that networks such as an LTE mobile 353 communication networks would be quite amenable for deploying CONEX as 354 a mechanism, since they represent clearly defined and well separated 355 operational domains, in which local CONEX deployment would be 356 possible. Aside from roaming (which needs to be considered for a 357 specific solution), a single mobile network deployment is under full 358 control of a single operator, which can enable operator-local 359 enhancement without the need to change the complete architecture. 361 In 3GPP EPS, interfaces between all elements of the architecture are 362 subject to standardization, including UE interfaces and eNodeB 363 interfaces, so that a standardized approach can be feasible as well. 365 4. CONEX in the EPS 367 The CONEX mechanism is still work in progress in the IETF working 368 group. Still, we would like to discuss a few options for how such a 369 mechanism (and possibly additional policing functions) could 370 eventually be deployed in 3GPP's EPS. Note that this description of 371 options is not intended as a complete set of possible approaches -- 372 it is merely intended for discussing a few options. More details 373 will be provided in a future revision of this document. 375 4.1. Possible Deployment Scenarios 377 There are different possible ways how CONEX functions on hosts and 378 network elements can be used. For example, CONEX could be used for a 379 limited part of the network only -- e.g., for the access network -- 380 congestion exposure and sender adaptation could involve the mobile 381 nodes or not, or, finally, the CONEX feedback loop could extend 382 beyond a single operator's domain or not. 384 We can differentiate two fundamental deployment scenarios for 385 congestion exposure as depicted in the figures below: 1) CONEX is 386 universally employed between operators (as depicted in Figure 2), 387 with an end-to-end CONEX feedback loop. Here, operators could still 388 employ local policies, congestion accounting schemes etc., and they 389 could use information about congestion contribution for determining 390 interconnection agreements. For 2), isolated CONEX domains as 391 depicted in Figure 3, CONEX is solely applied locally, in the 392 operator network, and there is no end-to-end congestion exposure. 393 This could be the case when CONEX is only implemented in a few 394 networks, or when operators decide to not expose and account for 395 congestion for inter-domain traffic. Independent of the actual 396 scenario, it is likely that there will be border gateways (as in 397 today's deployments) that are associated with policing and accounting 398 functions. 400 ----------------------------------------------------- 401 | +----+ +-------+ +-------+ +-------+ | 402 | | UE |=====| eNB |=====| S-GW |=====| P-GW | | 403 | +----+ +-------+ +-------+ +-------+ | 404 | | | 405 | Operator A | | 406 --------------------------------------------|-------- 407 | 408 ----------------------- 409 | | 410 | Internet | 411 | | 412 ----------------------- 413 | 414 --------------------------------------------|-------- 415 | +----+ +-------+ +-------+ +-------+ | 416 | | UE |=====| eNB |=====| S-GW |=====| P-GW | | 417 | +----+ +-------+ +-------+ +-------+ | 418 | | 419 | Operator B | 420 ----------------------------------------------------- 422 Figure 2: CONEX deployment across operator domains 424 ----------------------------------------------------- 425 | |--- CONEX path ---| | 426 | v v 427 | +----+ +-------+ +-------+ +-------+ | 428 | | UE |=====| eNB |=====| S-GW |=====| P-GW | | 429 | +----+ +-------+ +-------+ +-------+ | 430 | | | 431 | Operator A | | 432 --------------------------------------------|-------- 433 | 434 ----------------------- 435 | | 436 | Internet | 437 | | 438 ----------------------- 439 | 440 --------------------------------------------|-------- 441 | +----+ +-------+ +-------+ +-------+ | 442 | | UE |=====| eNB |=====| S-GW |=====| P-GW | | 443 | +----+ +-------+ +-------+ +-------+ | 444 | | 445 | Operator B | 446 ----------------------------------------------------- 448 Figure 3: CONEX deployment in a single operator domain 450 We consider both scenarios to be relevant and believe that both of 451 them are within the scope of the CONEX WG charter. A more detailed 452 description of these descriptions will be provided in a future 453 version of this document. 455 4.2. Implementing CONEX Functions in the EPS 457 We expect a CONEX solution to consist of different functions that 458 should be considered when implementing congestion exposure in 3GPP's 459 EPS. 461 o The CONEX mechanism defines how congestion is actually indicated, 462 how hosts can re-act to it, and how congestion contribution is 463 finally declared. For ECN-based mechanisms, ECN marking in 464 routers would be part of the mechanism. 466 o Policing functions are normally expected to manage the 467 experienced/declared congestion in the network. They are 468 considered important functions in an overall CONEX framework, as 469 they provide incentives to users/applications to actually re-act 470 to congestion indication. Also, it is assumed that accounting is 471 performed based on function related to policing. Finally, 472 implementations of CONEX may require the network to enforce proper 473 congestion contribution declaration (i.e., as droppers in the Re- 474 ECN proposal). 476 In the following, we discuss some possible placement strategies for 477 CONEX functional entities in the EPS and for possible optimizations 478 for both the uplink and the downlink. In order to provide a 479 comprehensive CONEX-based capacity management framework for LTE, it 480 would be advantageous to consider user contribution to congestion for 481 both the radio access and the core network. Potential places for 482 CONEX functions are e.g. the eNBs, the S-GWs or the P-GWs. Operator 483 deployments may provide additional intermediary CONEX-enabled IP 484 network elements. 486 For CONEX functions on elements such as the S-GWs and P-GWs, it is 487 important to consider mobility and tunneling protocol requirements. 488 LTE provides two alternative approaches: Proxy-Mobile-IP (PMIP, 489 [3GPP.23.402]) and GPRS Tunneling Protocol (GTP). For the 490 propagation of congestion information (responses) tunneling 491 considerations are therefore very important. 493 In general, policing will be done based on per-user (per subscriber) 494 information such as congestion quota, current quota usage etc. and 495 network operator policies, e.g., specifying how to re-act to 496 persistent congestion contribution etc. In the EPS, per-user 497 information is normally part of the user profile (stored in HSS) that 498 would be accessed by PCC entities such as the PCRF for dynamic 499 updates, enforcement etc. 501 The Conex mechanism allows operators to either have congestion based 502 policing in the uplink/downlink or in both directions. With the 503 given flexibility, the functional entities can further be divided 504 into uplink and downlink directions e.g. uplink/downlink policer etc. 506 Policers may be placed at different network locations (also see 507 [nec.globecom2010]). E.g., placing an uplink Policer at the base 508 station can be beneficial, because if there is congestion in the 509 backhaul, traffic would be policed before reaching the congested 510 segments. On the other hand, considering user mobility, operating 511 uplink policers on base stations may not be the optimal approach. 513 Downlink Policers would also be positioned best at border gateways 514 where they can process ingress traffic. Depending on the specific 515 architecture, up- and downlink policers could also be collocated. 517 A more detailed description of the different approaches and their 518 respective advantages will be provided in a future revision of this 519 document. 521 5. Implications for CONEX 523 Our description of possible CONEX use cases and deployment options in 524 the previous sections has yielded a set of implications/requirements 525 for the CONEX mechanism that we summarize in this section. 527 Performance: CONEX's capability of ensuring fairness could be used 528 for ensuring fairness in cellular networks. However, although the 529 idea looks promising, its advantages and performance have been not 530 yet been verified thoroughly yet. In the context of cellular 531 networks, which has more expensive resources and more stringent 532 QoS requirements, the feasibility of applying Conex to cellular 533 network as well as its performance and deployment scenarios need 534 to be examined. For instance, the mobile network may encounter 535 longer delay and higher loss rate but most of the flows are short- 536 lived. In the network with fast changing conditions, it requires 537 Conex to expose latest congestion information in time. In 538 addition, it is significant if it has the capability to indicate 539 out-of-date congestion information to avoid misusage of such 540 information. 542 Mobility: One of the unique characteristics in cellular network is 543 the presence of user mobility compared to wired networks. As the 544 user location changes, the same device can be connected to the 545 network via different base stations (eNodeBs) or even go through 546 switching gateways. Thus, the CONEX scheme must to be able to 547 carry latest congestion information per user/flow across multiple 548 network nodes in real time. 550 Multi-access: In cellular network, multiple access technologies can 551 co-exist. In such cases, a user can use multiple access 552 technologies for multiple applications or even a single 553 application simutaneously. If the congestion policies are set 554 based on each user, then Conex should have the capability to 555 enable information exchange across multiple access domains. 557 Tunneling Both 3G and LTE networks make extensive usage of 558 tunneling. The CONEX mechanism should be designed in a way to 559 support usage with different tunneling protocols such as PMIP and 560 GTP. 562 Roaming Independent of the specific architecture, mobile 563 communication networks typically differentiate between non-roaming 564 and roaming scenarios. Roaming scenarios are typically more 565 demanding regarding implementing operator policies, charging etc. 566 It can be expected that this would also hold for deploying CONEX. 567 A more detailed analysis of this problem will be provided in a 568 future revision of this document. 570 6. IANA Considerations 572 No IANA considerations. 574 7. Security Considerations 576 Security considerations will be provided in a future version of this 577 document. 579 8. References 581 8.1. Normative References 583 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 584 Requirement Levels", BCP 14, RFC 2119, March 1997. 586 8.2. Informative References 588 [3GPP.23.203] 589 3GPP, "Policy and charging control architecture", 3GPP 590 TS 23.203 10.2.1, January 2011. 592 [3GPP.23.402] 593 3GPP, "Architecture enhancements for non-3GPP accesses", 594 3GPP TS 23.402 10.2.1, January 2011. 596 [3GPP.23.829] 597 3GPP, "Local IP Access & Selected IP Traffic Offload 598 (LIPA-SIPTO)", 3GPP TR 23.829 1.3.0, September 2010. 600 [3GPP.29.060] 601 3GPP, "General Packet Radio Service (GPRS); GPRS 602 Tunnelling Protocol (GTP) across the Gn and Gp interface", 603 3GPP TS 29.060 3.19.0, March 2004. 605 [3GPP.29.274] 606 3GPP, "3GPP Evolved Packet System (EPS); Evolved General 607 Packet Radio Service (GPRS) Tunnelling Protocol for 608 Control plane (GTPv2-C); Stage 3", 3GPP TS 29.274 10.1.0, 609 December 2010. 611 [3GPP.36.300] 612 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA) 613 and Evolved Universal Terrestrial Radio Access Network 614 (E-UTRAN); Overall description; Stage 2", 3GPP TS 36.300 615 10.2.0, December 2010. 617 [I-D.ietf-conex-concepts-uses] 618 Briscoe, B., Woundy, R., Moncaster, T., and J. Leslie, 619 "ConEx Concepts and Use Cases", 620 draft-ietf-conex-concepts-uses-00 (work in progress), 621 November 2010. 623 [nec.globecom2010] 624 Kutscher, Lundqvist, and Mir, "Congestion Exposure in 625 Mobile Wireless Communications", in proceedings of IEEE 626 GLOBECOM 2010, December 2010. 628 Appendix A. Acknowledgments 630 We would like to thank Ingemar Johansson for his support in shaping 631 the overall idea and in improving the draft. 633 Authors' Addresses 635 Dirk Kutscher 636 NEC 637 Kurfuersten-Anlage 36 638 Heidelberg, 639 Germany 641 Phone: 642 Email: kutscher@neclab.eu 644 Faisal Ghias Mir 645 NEC 646 Kurfuersten-Anlage 36 647 Heidelberg, 648 Germany 650 Phone: 651 Email: faisal.mir@neclab.eu 652 Rolf Winter 653 NEC 654 Kurfuersten-Anlage 36 655 Heidelberg, 656 Germany 658 Phone: 659 Email: winter@neclab.eu 661 Suresh Krishnan 662 Ericsson 663 8400 Blvd Decarie 664 Town of Mount Royal, Quebec 665 Canada 667 Phone: 668 Email: suresh.krishnan@ericsson.com 670 Ying Zhang 671 Ericsson 672 200 Holger Way 673 San Jose, CA 95134 674 USA 676 Phone: 677 Email: ying.zhang@ericsson.com