idnits 2.17.1 draft-xue-intarea-fmc-ps-02.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 : ---------------------------------------------------------------------------- ** There are 71 instances of too long lines in the document, the longest one being 9 characters in excess of 72. 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 12, 2012) is 4426 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'EAP-SIM' is mentioned on line 443, but not defined == Missing Reference: 'RFC 4186' is mentioned on line 443, but not defined == Unused Reference: 'RFC6269' is defined on line 734, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) == Outdated reference: A later version (-10) exists of draft-ietf-intarea-nat-reveal-analysis-01 == Outdated reference: A later version (-02) exists of draft-so-ipsecme-ikev2-cpext-01 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Xue 3 Internet-Draft B. Sarikaya 4 Intended status: Informational Huawei 5 Expires: September 13, 2012 D. von Hugo 6 Telekom Innovation Laboratories 7 March 12, 2012 9 Problem Statement for Fixed Mobile Convergence 10 draft-xue-intarea-fmc-ps-02.txt 12 Abstract 14 The purpose of this document is to analyze the issues that have 15 arisen so far and then to propose a set of requirements for the Fixed 16 Mobile Convergence. The term Fixed Mobile Convergence spans several 17 scenarios from true integration of fixed and mobile terminals, 18 services, and network infrastructure on both technical and management 19 level down to pure interworking between fixed and mobile networks in 20 serving access for multi-interface terminals like todays' 21 smartphones. In the interworking scenario, the mobile network passes 22 on the mobile subscribers policies to the fixed broadband network in 23 order to maintain the end-to-end service level agreement and to 24 support remote terminal and access network management. Explicitly, 25 the fixed broadband network must have partnership with the mobile 26 network in Fixed Mobile Convergence interworking scenario. This 27 document gives a brief overview of the assumed Fixed Mobile 28 Convergence architecture and related works and then introduces 29 several requirements based on the partnership in Fixed Mobile 30 Convergence architecture, such as User Equipment identification and 31 authentication, Femto Access Point management, device type 32 identification and mobility considerations. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 13, 2012. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 7 69 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 4. Key issues in Fixed Mobile Converged Interworking . . . . . . 8 71 4.1. UE identification and AAA management in fixed 72 broadband network . . . . . . . . . . . . . . . . . . . . 9 73 4.2. Femto Access Point Management . . . . . . . . . . . . . . 12 74 4.3. Device type identification . . . . . . . . . . . . . . . . 14 75 4.4. Carrier Grade NAT Related Issues . . . . . . . . . . . . . 14 76 4.5. UE Mobility in Fixed Broadband Network . . . . . . . . . . 15 77 4.6. Flow Mobility between different interface . . . . . . . . 17 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 83 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 86 1. Introduction 88 Growing availability of intelligent mobile devices and mature 89 networks of operators providing both reliable carrier grade 90 connectivity and affordable high bandwidth access offer to the 91 customer a nice climate of mobile broadband. With widespread 92 availability and easy usability of mobile broadband, mobile broadband 93 applications become more ubiquitous. Subscribers demand for various 94 service applications, especially Internet applications, such as 95 mobile Internet video, mobile Internet real-time communication, etc. 97 The subscribers requirements lay the foundation of mobile broadband. 98 On the other hand, simultaneously, the subscribers' services promote 99 the evolution of mobile broadband, which will impact the network 100 architecture. The flourishing mobile applications demand more and 101 more bandwidth offered by the operators. Even with wireless networks 102 becoming mature, such as 3G and LTE, the average bandwidth offered is 103 not comparable to data rates offered by fixed networks. With data 104 services rapidly increasing, the traditional cellular network 105 operating at a shared medium and thus being limited in transmission 106 rate often becomes the bottle-neck of mobile broadband. In addition 107 radio network technology generally requires high capital investment 108 and operational expenditures. Cellular network operators are facing 109 the challenge of increasing traffic demand at decreasing revenue and 110 have to provide means of more cost efficient access technology in a 111 highly competitive environment. The trend of offloading the traffic 112 to fixed broadband network is emerging. Mobile industry has 113 specified functionalities to offload the data traffic to the fixed 114 broadband (FBB) network, via WLAN or a Home (e)NodeB (HNB or eNodeB, 115 aka. Femtocell) [TR23.829], which could alleviate traffic pressure 116 on the mobile network. That is to say, today, operators are able to 117 employ mechanisms to manage the subscriber service over both the 118 mobile and the fixed broadband network. We can say, FMC is emerging 119 on the basis of subscribers and operators requirements. 121 Fixed Mobile Convergence is a technology trend which aims to provide 122 the subscribers access to services regardless of the access network 123 type they are connecting to and provide the operators with the 124 flexibility to ensure transparency of services to the end user. For 125 a mobile subscriber to access services over both mobile and fixed 126 broadband networks seamlessly, additionally, the subscriber's end-to- 127 end service level agreement (SLA) must be maintained. This is 128 achieved by interworking the control planes of the fixed broadband 129 network and the mobile network. 131 In the FMC interworking scenario addressed here, the fixed broadband 132 network must partner with the mobile network to perform 133 authorisation, authentication, and accounting (AAA) and acquire the 134 policies for the mobile subscriber. Please note, a single converged 135 control plane, used for both the fixed broadband and the mobile 136 network, may be used in a truely converged, i.e. integrated 137 convergence scenario. This document only focuses on the interworking 138 scenario in this version. The convergence scenario is for further 139 study. 141 Figure 1 shows the assumed reference architecture of Fixed Mobile 142 Convergence Interworking for a Mobile (3GPP) Network and a fixed non- 143 3GPP access network as proposed by 3GPP and BroadBand Forum (BBF) as 144 an example in document [WT203]. 146 +---------------------------------------+ 147 | Mobile Network | 148 | ---- | 149 | +------+ / \| 150 | +----+ PCRF | |Operator| 151 | | +---+--+ | Service| 152 | | | \ /| 153 | | | --+- | 154 +------+ +------+ | +------+ +---+--+ | | | 155 | UE | | eNB +-----+ SGW +---+ PGW +-----|---------+----------+ 156 +------+ +------+ | +------+ +--+---+---+ | +------+| | 157 | +--+---+ +-|-----+M AAA || --+- 158 | | ePDG +---+ | +---+--+| / \ 159 +------------+------+-----|---------|---+ |Internet 160 | | | | Service 161 +---------------|---------|---------|---+ \ / 162 | Fixed Network | +---+--+ +---+--+| --+- 163 | | +---+ BPCF | |F AAA || | 164 | +--+-+-+ +------+ +---+--+| | 165 +------+ | | BNG +---------------+ | | 166 | Femto+-----------+ +--+-+-+ | | 167 +------+ | | | +----------------------------+ 168 +------+ | | +--+---+ | 169 | UE | | +----+ AN | | 170 +------+ +------+ | +--+---+ | 171 |WiFiAP|-------------------+ | 172 | RG | | | 173 +------+ | | 174 +---------------------------------------+ 175 Legend: 176 M AAA Authentication Authorization Accounting in Mobile Network 177 F AAA Authentication Authorization Accounting in Fixed Network 178 BPCF Broadband Policy Control Function 179 BNG Broadband Network Gateway 180 ePDG evolved Packet Data Gateway 181 PCRF Policy Charging Rule Function 182 PGW Packet Data Network Gateway 183 SGW Serving Gateway 184 UE User Equipment 185 RG Residential Gateway 187 Figure 1: Reference Architecture of Fixed Mobile Convergence 189 The policy and charging control (PCC) system is an important element 190 in FMC architecture. PCC system of FMC consists of policy decision 191 point (PCRF in the mobile network and BPCF in the fixed broadband 192 network) and the policy enforcement point (PGW and BNG, 193 respectively), shown in Figure 1. PCC should support for controlling 194 the QoS (e.g., QoS class and bit rates) authorized for service, and 195 IP flow based charging. In FMC interworking scenario, these services 196 can be divided into four types. 198 1. Service via macrocell wireless network 200 2. Service via WiFi/Femtocell access routed back to 3GPP Evolved 201 Packet Core (EPC), where the fixed broadband network is used as 202 the access network, 204 * The service from a mobile UE is connected to WiFi or to 205 Femtocell Access Point (FAP) at the residential gateway (RG), 206 routed back to 3GPP Evolved Packet Core (EPC). 208 3. Services via WiFi access only fixed broadband routed 210 * The service from a mobile UE is connected to WiFi without 211 traversing the mobile network. 213 * In this scenario, the UE service may be guaranteed based on 214 subscriber's policy from the mobile network. 216 4. LIPA/SIPTO traffic 218 * Support of Local IP access (LIPA) and of Selected IP traffic 219 offload (SIPTO) for the Home (e)NodeB Subsystem and for the 220 macro layer network include a more integrated FMC scenario and 221 thus are for further study. 223 As for the services stated above, only the second and the third type 224 are related to FMC, where both the fixed broadband and the mobile 225 network are involved. The FMC architecture shall be capable to set 226 operator policies to support simultaneous access to these service. 228 In the network today, deploying FMC is a worthy way for operators to 229 satisfy subscriber's requirement and ease pressure from bandwidth. 230 In the following sections, we first describe the motivation and then 231 discuss the key issues in FMC interworking scenario. 233 2. Conventions and Terminology 235 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 236 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 237 document are to be interpreted as described in RFC 2119 [RFC2119]. 239 3. Motivation 241 The motivation is to highlight and discuss the issues when 242 facilitating FMC. We systematically analyze the issues that have 243 been proposed so far and briefly assess the possible extensions which 244 could solve the problems. In the network architecture, we target and 245 limit the scope to the interworking architecture for FMC. The 246 convergence architecture is out of scope. 248 Regarding the traffic management and control requirements in FMC 249 interworking scenario, there are five essential issues from an IETF 250 Internet Area and fixed broadband network point of view, as follows. 252 1. UE identification in fixed broadband network 254 2. Femto Access Point management 256 3. Device type identification 258 4. UE Mobility in fixed broadband network 260 5. Flow Mobility 262 In Section 4 below, we discuss the key issues and some problems based 263 on the FMC architecture. There are many standardization issues 264 related to FMC and protocol extension work needed are stated in this 265 document. 267 If these issues are fixed, the advantages brought out will be: 269 1. Optimize traffic management (per-UE granularity in the fixed 270 broadband network) 272 2. Enhance device management (via IP address synchronization between 273 fixed broadband network and mobile network) 275 3. Reduce operators load on Deep Packet Inspection (DPI) (bypass the 276 unnecessary traffic) 278 4. Quick Responsiveness based on UE status 280 4. Key issues in Fixed Mobile Converged Interworking 282 This section provides some key issues related to FMC when deployed. 283 These issues, which motivate the FMC, must be resolved. It is 284 difficult to foresee the most suitable solutions to resolve these 285 issues now, but in any event, some possibilities need to be analysed 286 based on the scenarios. Mobile network solutions of these issues are 287 out of scope. 289 4.1. UE identification and AAA management in fixed broadband network 291 A user accessing a network point of attachment has to be authorised 292 and authenticated by the network as well as vice versa to assure 293 reliability of service as well as proper exchange of accounting 294 information. That is the identity of the user and the AAA 295 credentials have to be transferred and acknowledged. In addition a 296 unique identity has to be assigned to the customer and/or his 297 terminal, i.e. to maintain a session, a routable IP address has to be 298 provided. Detailed consideration of AAA issues is out of sccope of 299 this document. 301 Nowadays, a subscriber is always provided with a single private IPv4 302 address at their home or small business, which should reduce the 303 pressure on the available public IPv4 addresses which are now 304 exhausted. For instance, in the fixed broadband network, each host 305 within the local network will be assigned a private IPv4 address, 306 then NA(P)T function is responsible for translating the private IPv4 307 address to the public IPv4 address assigned to the CPE (Customer 308 Premises Equipment) by operators, and vice versa. 310 As a result of maintaining growth of IPv4 service, private addressing 311 plan will require address sharing, which will cause issues for 312 operators, such as traffic management, QoS enforcement, etc. in the 313 FMC scenarios, where the policy control must be based on the 314 fundamental concept of per-UE granularity. Note that ultimately, 315 deploying IPv6 is the only perennial way to ease pressure on the 316 public IPv4 address without the need for address sharing mechanisms 317 that give rise to the issues identified herein. But in the interim, 318 however, IPv4 services are also very important for end-users, and 319 service providers, which can not be ignored. 321 The FMC architecture shall be capable to set operator policies to 322 support simultaneous access to mobile services and traffic offloading 323 to the fixed broadband network. Accordingly, regarding policy and 324 QoS interworking between the fixed broadband and mobile 325 architectures, we consider the following scenarios, see Figure 2: 327 1. Mobile UE with mobile-routed traffic and no NAT in Residential 328 Gateway (RG) 330 2. Mobile UE with mobile-routed traffic with NAT in RG 332 3. Mobile UE with offloaded traffic and no NAT in RG 333 4. Mobile UE with offloaded traffic with NAT in RG 335 +---------------------------------------+ 336 | Mobile Network | 337 | ---- | 338 | / \| 339 | |Operator| 340 | +-----------------> | Service| 341 | |+--------------->> /| 342 | || ---- | 343 | +-----+ ||+------+ | 344 | | SGW +--||+ PGW +--------------------------+ 345 | +-----+ ||+--+---+ | | 346 | || | | --+- 347 | || | | / \ 348 +----------||---+-----------------------+ |Internet 349 || | | Service 350 +----------||---+-----------------------+ \ / 351 | || | +------------------>>> --+- 352 | || | |+----------------->>>> | 353 | ||+--+---+ || | | 354 | ||| BNG +-||----------------+------+ 355 +------+ +------+<----case1-- -+|+------+ || | 356 | UE | | RG | | | || | 357 +------+ +------|<<---case3-----++------+ || | 358 | | AN | || | 359 +------+ +------+<<---case2---+ +------+ || | 360 | UE | |RG NAT| | +-----------+| | 361 +------+ +------+<<<<-case4----------------+ | 362 Private IP | +---------------------------------------+ 363 Public IP + UDP 365 Figure 2: FMC Cases 367 Currently PCC can support case 1 and 3, but issues will be introduced 368 in cases 2 and 4 because of address sharing via NA(P)T. The important 369 consideration is that today's PCC (including QoS control and IP flow 370 based charging) must be based on the fundamental concept of IP 371 Connectivity Access Network (IP-CAN) in per-UE granularity. IP-CAN 372 session [TS23.203] is the association between a UE and an IP network. 373 So in FMC network, it is assumed that fixed broadband network could 374 manage the traffic in per-UE granularity. 376 Obviously, the fixed broadband network and mobile network must 377 support inter-operator subscribers policy exchange, this introduces a 378 major challenge on how to coordinate UE identification across the 379 operators' domains so that the mobile network can inform the suitable 380 policy to the serving fixed broadband access network that its mobile 381 user equipment (UE) is attached to. So that the fixed broadband 382 network can provide the appropriate FMC interworking policy and 383 bearer control on UE's traffic. 385 There may be limitations with BNG implementations with respect to the 386 level of granularity (per-UE) of the enforcement. Take case 4 for an 387 example, a key problem is to identify offloaded traffic from a 388 special UE, i.e. UE identification substantively, behind the NA(P)T 389 embedded into RG, there is no longer a unique IP address per UE, in 390 addition, the UDP port behind NA(P)T is not bound to the special UE. 392 Another factor that contributes to UE identification is efficient 393 packet inspection. Operators expect the fixed broadband network 394 could be configured in such a way that the traffic subject to packet 395 inspection is routed via the Traffic Detection Function (TDF) 396 [TS29.212], otherwise, the traffic that is not subject to packet 397 inspection may bypass the TDF. This assumption only holds if it is 398 possible to identify individual UEs behind NA(P)T embedded into the 399 RG in fixed broadband network, shown in Figure 3. Issues may arise 400 if there is a NA(P)T in or beyond the RG, even a NA(P)T in or beyond 401 the BNG. As a result, additional mechanisms are needed to enable 402 this. 404 +--------+ 405 | | 406 +-------+ PCRF | 407 | | | 408 | +--------+ 409 +--------+ +--------+ +--------+ +----+----+ 410 | | | | | +-----+ | 411 | ------------------------------------------------------------------ 412 | | | | | | | TDF | / \ 413 | ****************************************************************** 414 | | | +-------+ | | | Service 415 | | | | | | | \ / 416 | | | | | | | +--------+ 417 | | |Resident| | | +--------+ | 418 | ********---------**********--------************------------******* | 419 | UE | |Gateway | | BNG +------------------+ PGW | 420 +--------+ +--------+ +--------+ +--------+ 421 Legends: 422 --------- 3GPP UE User Plane Traffic Offloaded subject to packet inspection 424 ********* 3GPP UE User Plane Traffic Offloaded not subject to packet inspection 426 *****---- 3GPP UE User Plane Traffic Home Routed 427 Figure 3: UE's Traffic Routed with TDF 429 As discussed before, there are many drivers for the UE identification 430 in the broadband network. They include efficient packet inspection, 431 QoS enforcement, charging. We can note that all these functions in 432 FMC depend on being able to identify UEs behind the NA(P)T. 434 There are several possibilities which provide solutions. One 435 recommendation from fixed broadband, defined in [WT146], is to bind 436 the UDP port (after NA(P)T) to the special UE. This solution has 437 limitations because it may not be feasible due to static 438 configuration in RG, to provide unique UDP port numbers to all the 439 devices on user side. This is the overload scenario for operators. 441 Beside 3GPP-defined algorithms to derive unique identities for use 442 within a fixed access network from 3GPP-specified SIM (Subscriber 443 Identity Module) such as in [EAP-SIM, RFC 4186] or [EAP-AKA, RFC 4187 444 or EAP-AKA', RFC 5448] there are several possible IP or TCP protocol 445 extensions, discussed in [I-D.ietf-intarea-nat-reveal-analysis]. In 446 that draft, TCP host identifier option is also discussed. 447 Additionally, there may be other possibilities, such as some other 448 new identifier to be defined, etc. It is difficult to foresee which 449 is the suitable solution, more work needs to be done. 451 4.2. Femto Access Point Management 453 Femtocells (FAPs), whose architecture is specified in the mobile 454 standards (e.g., 3GPP, Femto Forum, etc.), are an exemplary feature 455 of an FMC network. The access network to which Femtocells are 456 attached is the fixed broadband network as depicted in Figure 4. As 457 mentioned before, in order to achieve PCC, there is a need for the 458 fixed broadband network to have partnership with mobile network to 459 maintain the service level agreement (SLA). Here, the private IPv4 460 addressing plan in fixed broadband network introduces the 461 limitations, which was described in the draft 462 [I-D.so-ipsecme-ikev2-cpext]. In today's generic FAP architecture, 463 it is difficult to guarantee a unique mapping, shown as follows: 465 1. Determine the UE attached FAP's public IPv4 address together with 466 the translated port number of the UDP header of the encapsulated 467 IPsec tunnel between the FAP and the Security Gateway (SeGW) 468 which are assigned by the fixed broadband network. The FAP's 469 public IPv4 address is: 471 * used for identifying the location of the FAP, 473 * used for identifying the UE's traffic at the fixed broadband 474 network. 476 2. Determine the corresponding FAP's public IPv4 address's 477 association with the UE's inner-IPv4 address which is assigned by 478 the mobile network. The association is: 480 * used for identifying the mobile UE that is attached to the FAP 481 in order to allow the PCRF to retrieve the UE's policy to be 482 passed onto the BPCF at the fixed broadband network. 484 +-------------+ +------------------------+ 485 (Mobile network | | | | 486 assigned Inner | | | | 487 IP) | | | | 488 | | +------+ | | +------+ +---------+ | 489 | | | BPCF +---------+ PCRF +--+MME/SGW | | 490 | | +--+---+ | | +------+ +----+----+ | 491 | | | | | | | 492 | | +--+---+ | | +------+ +----+----+ | 493 +---+ | +---+ | | | | | | | | | | 494 +----+ | <---|----------+--+------+---+---+-> | | | | 495 | UE | |FAP| v |RG | | | BNG | | | | SeGW +--+ FAP-GW | | 496 +----+ | <--------------+--+------+---+---+-> | | | | 497 +---+^ +---+^ | | | | | | | | | | 498 | | | +------+ | | +------+ +----+----+ | 499 | | | | | | | 500 | | | | | | | 501 | | | Fixed | | +----+----+ | 502 Private | | Broadband | | | | | 503 IP | | Network | | | PGW | | 504 | | | | | | | 505 Public-------------+ | +----+----+ | 506 IP+Port | Mobile | | 507 (NAPT) | Network | | 508 | | | 509 +----------------+-------+ 510 --+- 511 Legends: / \ 512 |Internet| 513 <---> | Service| 514 <---> IPsec Tunnel \ / 515 MME Mobility Management Entity ---- 517 Figure 4: FMC Femto Access Architecture 519 Due to the requirement for inter-operators subscribers policy 520 exchange, the private and public addressing which rely on NA(P)T, 521 must be coordinated cross the operators domains. Additionally, FAP 522 location must be identified for management. These major factors 523 drive the solutions in interworking architecture with Femtocell 524 scenario such as extending IKEv2 [RFC5996], so that the overall 525 service performance and the user experience could be enhanced. 527 4.3. Device type identification 529 As there are multiple types of user terminal devices, e.g. PDA, 530 mobile phone, personal computer, etc. with different characteristic 531 capabilities (portability, screen size, audio output etc.) for some 532 service applications and corresponding QoS and management 533 requirements, it is important for operators to capture the service- 534 specific terminal device type, especially in FMC interworking 535 scenario. In such cases, different rules for policy control and 536 traffic routing are needed to be provided by the operators to ensure 537 acceptable SLA to the device. 539 When WiFi is deployed for traffic offload, the terminal devices, such 540 as mobile phone and personal computer could be used for service. In 541 this case, only the traffic from the 3GPP service, such as mobile 542 voice may need policy control and management. The best effort 543 traffic will not be routed via the mobile core (EPC) and thus has no 544 impact to the FMC at all. With this method, the traffic management 545 optimization generally occurs based on selecting suitable types of 546 device which need special policy control and management. 548 In the current WiFi network, the device type information is 549 transparent to the fixed broadband network, because only IP and port 550 information is used for identification. It is difficult for BNG to 551 distinguish the traffic from UE device, and then route it specially. 552 So a solution is needed to identify the device type, especially at 553 the BNG. 555 4.4. Carrier Grade NAT Related Issues 557 Referring to Figure 4, FAP is usually behind a Carrier Grade NAT 558 (CGN) box. CGN may be used as part of architecting the support of 559 NAT44 or NAT444 [RFC6264]. CGN could be colocated with BNG in 560 Figure 4. In such a configuration, UE maintains long lived IPsec or 561 TLS connection across the CGN. 563 Carrier Grade NAT may flush the long lived session after a certain 564 timeout period. Currently most NAT implementations would flush all 565 sessions after they reach 24 hours, regardless of the state of the 566 session. 568 CGN terminating all existing sessions of a UE does present a number 569 of problems. One problem is that this will cause more attachment 570 signaling to be introduced in order to reestablish UE's sessions. 572 More serious problem may occur though. UEs all active phone calls 573 are possibly disrupted. UE may even be involved in calls to 574 emergency services like 911 which would be disrupted as well. 576 4.5. UE Mobility in Fixed Broadband Network 578 The users are the mobile subscribers in FMC. Note that all the 579 services depend on the substantive character of subscriber's 580 mobility. It is important for operators to capture the user device 581 when it is moving into or outside the network, even in WiFi access. 582 Besides, the application and service from the subscriber must be 583 guaranteed based on the policy of operators. 585 In mobile network today, there are many mature solutions offered for 586 user's mobility already. Herein, only mobility in fixed access, 587 i.e., WiFi access, will be considered. For example, the user device 588 is attached to the home LAN (e.g., WiFi ) network, and establishes a 589 connection back to the subscriber's mobile service provider network 590 via the fixed broadband network. The mobile operator should 591 cooperate with the broadband access operator to deliver proper policy 592 for the service from UE. 594 The mobility considered in the fixed access is a little different. 595 In this section, we divide the mobility capability into two cases: 597 1. UE is moving into or outside the coverage area of WiFi AP 599 2. UE's WiFi access is dormant or not. 601 The following figure shows an example of the scenario where mobile 602 UEs are served in WiFi deployment over the fixed broadband network. 603 RG embeds WiFi AP and NA(P)T function. Each UE is provided with a 604 single private IPv4 address assigned within the local network. 605 NA(P)T in RG is responsible for translating the private IPv4 address 606 to the public IPv4 address assigned by the fixed operator. 608 Policy for UE 609 identified by IP + Port 610 +-------------+| +------------------------+ 611 | || | | 612 | || | | 613 | || | | 614 | +------+ || | +------+ +---------+ | 615 | | BPCF +---+V--+-+ PCRF +--+ MME | | 616 | +--+---+ | | +---+--+ +----+----+ | 617 +----+ | | | | | | | 618 |UE1 |Private IP1 | +--+---+ | | +---+--+ +----+----+ | 619 +----+ +---+ | | | | | | | | | | 620 | <----------+--+------+---+---+-> | | | | 621 |RG | | | BNG | | | | ePDG +--+ SGW | | 622 +----+ | <-^--------+--+------+---+---+-> | | | | 623 |UE2 | +---+ | | | | | | | | | | | 624 +----+Private IP2 | | +------+ | | +------+ +----+----+ | 625 | | | | | | 626 | | | | | | 627 | | Fixed | | +----+----+ | 628 | | Broadband | | | | | 629 Public IP | Network | | | PGW | | 630 NA(P)T | | | | | | 631 +-------------+ | +----+----+ | 632 | Mobile | | 633 | Network | | 634 | | | 635 Legends: +----------------+-------+ 636 --+- 637 <---> / \ 638 <---> IPsec Tunnel |Internet| 639 | Service| 640 \ / 641 ---- 643 Figure 5: Mobility in the Fixed Broadband Network 645 As described previously, BPCF in fixed broadband network must have 646 partnership with PCRF in mobile network in order to maintain the 647 service level agreement (SLA). In order to allow the PCRF to 648 retrieve the UE's policy to be passed onto the BPCF in the fixed 649 broadband network, it is mainly concerned about the traffic and UE 650 identification binding used to achieve the actual traffic control. 651 The BPCF/BNG will perform the policy control based on the binding. 653 Based on the UE's mobility, issues will arise. For example, the PCRF 654 will retrieve the wrong policy to the BPCF, if the UE identification 655 can not be updated in time. For instance, there are two UEs, shown 656 in Figure 5. UE1 and UE2 are assigned different private IP addresses 657 within the local network, IP1 and IP2 accordingly. After NAPT, BPCF/ 658 BNG will be based on the public IPv4 address and the different UDP 659 port numbers assigned by NAPT to perform the admission control and 660 policy enforcement on the UE's traffic. 662 Since plenty of UEs may move into the coverage of WiFi AP, it is 663 possible that the same UDP port will be used for both UE1 and UE2 at 664 the different time period. For example, UE1 moved out of the WiFi 665 coverage and later the UE2 moved in. The same UDP port used by UE1 666 before is assigned to UE2 again. As mentioned, the identification 667 must be consistent between fixed broadband network and the mobile 668 network for policy exchange. So the UDP port used as part of UE 669 identification must be updated in time based on the status of UE, 670 otherwise the PCRF will confused about which policy is used. 672 Especially, there may be a requirement to binding the UDP port to a 673 special UE described in Section 4.1. The UDP ports must be cleared 674 if the UEs corresponding to prior port binding are out of coverage of 675 the WiFi AP. That is to say the configuration must be updated 676 regularly to satisfy that the WiFi AP can serve thousands of UEs. 677 Other solutions to solve the issue in Section 4.1 may also fix this 678 challenge introduced by the mobility of UE. 680 Based on the discussion, for UE's mobility in WiFi network, we can 681 recognize that the important requirement for the fixed broadband 682 network is to update the UE identification based on UE mobility. In 683 this scenario, the fixed broadband network must be able to update the 684 record for UE during the UE mobility. 686 4.6. Flow Mobility between different interface 688 Traffic offloading requires the ability to move the traffic flows 689 from one interface to the other interface of the UE. The type of 690 flows to be moved depends on the policy and should be dictated by the 691 mobile operator. 693 Several IP flow mobility protocol approaches are under discussion 694 some of which have been already adopted for use in mobile networks, 695 e.g. by 3GPP, but currently no such flow mobility protocol has been 696 applied for use in an fixed broadband network, e.g. by BBF. Without 697 an overarching commonly agreed on flow mobility protocol, offloading 698 traffic from mobile network to fixed broadband network can simply not 699 be achieved. 701 5. IANA Considerations 703 This document makes no request to IANA. 705 6. Security Considerations 707 Serious concern of mobile operators towards FMC approaches has been 708 the customer access via networks not under control of the operator. 709 Operators would like to keep their own high security measures to 710 prevent various kinds of fraud or attack to the operators services 711 and network entities. Well known risks and vulnerabilities which are 712 common to any NA(P)T application are documented in the NAT 713 specification [RFC2663]. Any additional security considerations 714 arising from FMC are TBD. 716 7. Acknowledgements 718 Many people provided comments that have been incorporated into this 719 document including Mohamed Boucadair, David Binet, Pierrick Seite. 720 Special thanks to Cameron Byrne for providing the text in Section 721 4.4. 723 8. References 725 8.1. Normative References 727 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 728 Requirement Levels", BCP 14, RFC 2119, March 1997. 730 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 731 "Internet Key Exchange Protocol Version 2 (IKEv2)", 732 RFC 5996, September 2010. 734 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 735 Roberts, "Issues with IP Address Sharing", RFC 6269, 736 June 2011. 738 [TR23.829] 739 "3GPP TR23.829, Local IP Access and Selected IP Traffic 740 Offload (LIPA-SIPTO)", October 2010. 742 [TS23.203] 743 "3GPP TS23.203, Policy and Charging control architecture", 744 December 2011. 746 [TS29.212] 747 "3GPP TS29.212, Policy and Charging Control (PCC) over 748 Gx/Sd reference point", December 2011. 750 8.2. Informative References 752 [I-D.ietf-intarea-nat-reveal-analysis] 753 Boucadair, M., Touch, J., Levis, P., and R. Penno, 754 "Analysis of Solution Candidates to Reveal a Host 755 Identifier in Shared Address Deployments", 756 draft-ietf-intarea-nat-reveal-analysis-01 (work in 757 progress), March 2012. 759 [I-D.so-ipsecme-ikev2-cpext] 760 So, T., "IKEv2 Configuration Payload Extension for Private 761 IPv4 Support for Fixed Mobile Convergence", 762 draft-so-ipsecme-ikev2-cpext-01 (work in progress), 763 February 2012. 765 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 766 Translator (NAT) Terminology and Considerations", 767 RFC 2663, August 1999. 769 [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental 770 Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, 771 June 2011. 773 [WT146] "Broadband Forum Working Text WT-146, Subscriber 774 Sessions", June 2011. 776 [WT203] "Broadband Forum Working Text WT-203, Interworking between 777 Next Generation Fixed and 3GPP Wireless Access", 778 December 2011. 780 Authors' Addresses 782 Li Xue 783 Huawei 784 NO.156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan, 785 Beijing, HaiDian District 100095 786 China 788 Email: xueli@huawei.com 789 Behcet Sarikaya 790 Huawei 791 5340 Legacy Dr. 792 Plano, TX 75074 794 Email: sarikaya@ieee.org 796 Dirk von Hugo 797 Telekom Innovation Laboratories 798 Deutsche-Telekom-Allee 7 799 D-64295 Darmstadt 800 Germany 802 Phone: 803 Email: Dirk.von-Hugo@telekom.de