idnits 2.17.1 draft-muley-network-based-bonding-hybrid-access-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 (October 22, 2018) is 2006 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Area WG Praveen Muley 2 Internet Draft Wim Henderickx 3 Intended status: Informational Nokia 4 Expires: April 30, 2019 Geng Liang 5 China Mobile 6 Hans Liu 7 D-Link Corp 8 Loris Cardullo 9 Jonathan Newton 10 Vodafone 11 SungHoon Seo 12 Korea Telecom 13 Sagiv Draznin 14 Verizon Wireless 15 Basavaraj Patil 16 AT&T 17 October 22, 2018 19 Network based Bonding solution for Hybrid Access 20 draft-muley-network-based-bonding-hybrid-access-03 22 Abstract 24 In order to address increasing bandwidth demands, operators are 25 considering bundling of multiple heterogeneous access networks 26 (Hybrid access) for residential and enterprise customers. This 27 document describes a solution for Hybrid access and covers the use 28 case scenarios. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in RFC 2119 [RFC2119]. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six 47 months and may be updated, replaced, or obsoleted by other documents 48 at any time. It is inappropriate to use Internet-Drafts as 49 reference material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on April 30, 2019. 53 Copyright Notice 55 Copyright (c) 2018 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with 63 respect to this document. Code Components extracted from this 64 document must include Simplified BSD License text as described in 65 Section 4.e of the Trust Legal Provisions and are provided without 66 warranty as described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction...................................................3 71 2. Terminology....................................................3 72 3. Reference Architecture.........................................4 73 4. Network Based Bonding Solution Overview........................5 74 4.1. Separate BNG and PGW......................................5 75 4.2. Integrated BNG and SGW/PGW................................6 76 5. HAG Function...................................................7 77 5.1. Address Assignment........................................7 78 5.1.1. Separate BNG and PGW.................................7 79 5.1.2. Integrated BNG and SGW/PGW...........................8 80 5.2. Setup and Tunnel Management...............................9 81 5.3. Traffic distribution policies............................10 82 5.4. Path Management..........................................11 83 5.5. Backward compatibility...................................12 84 6. Applicability in Mobile networks..............................12 85 7. Inter-working with MP-TCP.....................................14 86 8. Security Considerations.......................................14 87 9. IANA considerations...........................................15 88 10. References...................................................15 89 10.1. Normative References....................................15 90 10.2. Informative References..................................15 91 11. Acknowledgments..............................................16 93 1. Introduction 95 To address the increasing demand of bandwidth by residential and 96 enterprise customers, operators are looking for alternatives that 97 can avoid rebuilding of the existing fixed access networks. 98 In Hybrid Access network, a Customer Premise Equipment 99 (CPE) is connected to heterogeneous access networks (e.g. DSL, LTE 100 etc) simultaneously. Traffic is distributed in flexible manner over 101 these heterogeneous links thus increasing the bandwidth capacity of 102 a residential or an enterprise customer. 103 This document describes a solution to implement the 104 network based bonding Hybrid Access architecture. The solution is 105 generic enough that it is applicable to fixed as well mobile nodes 106 with multiple Access technologies. 108 2. Terminology 110 All mobility related terms are to be interpreted as defined in 111 [RFC5213] and [RFC5844]. Additionally, this document uses the 112 following terms 114 IFOM IP flow mobility 116 NB-IFOM Network based IFOM 118 ePDG Evolved Packet Data Gateway (defined in 3GPP [24.302]) 120 RR Routing Rule 122 HAG Hybrid Access Gateway 124 PcRF Policy and Charging Rules Function 126 NBF Network based Bonding Function 128 MCP Multi-path conversion point (defined in [NAMPTCP]) 130 3. Reference Architecture 132 +----+ ------ 133 | | / \ 134 |HOST| +-----+ | Wireless +-----\+-----+ 135 | +-----+ | +-+ 3G/4G | | | ***** 136 +----+ Wireless +-+ \ / | | ** ** 137 | | ------ | | * * 138 +----+ | CPE | | HAG +---* Internet * 139 | | | | ------ | | * * 140 |HOST+-----+ +-+ / \ | | ** ** 141 | |Wired| | +-+ | | | ***** 142 +----+ +-----+ | Fixed +-----/+-----+ 143 \ / 144 ------ 146 Figure 1 Network based bonding Hybrid Access Architecture 148 A CPE with HAG Figure 1 shows the network based bonding hybrid 149 access architecture. In this architecture, HAG with network bonding 150 function is deployed at the remote side of the CPE. The HAG receives 151 the downstream traffic from internet and can apply the policies to 152 distribute downstream traffic towards the CPE over available paths. 154 An in-band control protocol between the CPE and the 155 HAG MAY be used to negotiate the traffic distribution policies for 156 uplink traffic. 158 However, there SHOULD be flexibility to download the 159 traffic distribution policies OUT-of-band. 161 Traffic distribution policies on CPE and HAG can have 162 independent packet-based behavior. 164 Operators can have flexibility to distribute flows over 165 multiple paths or associate affinity of flow to a particular access 166 type. Traffic policies can also be applied taking into account the 167 access networks link status such as latency, state etc. 169 Operator can also apply policy to fill one access link 170 first before utilizing other (MAX-FILL). Affinity to one access MAY 171 be due to cost or application characteristics. In this case the 172 distribution of traffic is adjusted dynamically based on the load. 174 Behavior to adjust on moving around flows or packet is a matter of 175 local policy. 177 4. Network Based Bonding Solution Overview 179 4.1. Separate BNG and PGW 181 <--------Fixed Path-----> | <----- PMIPv6/GTP ---->| 183 +------+ +------+ 185 | AAA | | PCRF | 187 +------+ +------+ 188 | | 189 | | 190 +---+ _----_ +------+ _----_ +------+ **** 191 | | _(Fixed )_ | | _( )_ | HAG | ** ** 192 |CPE|<==( Access )==| BNG |==( Operator )==|(NBF/ |==*Internet* 193 +---+ (_ _) | | (_Network_) | PGW) | ** ** 194 ^ '----' +------+ '----' +------+ **** 195 | DSL Access PMIPv6/GTP Tunnel ^ 196 | | 197 | | 198 | | 199 | Non-3GPP access | 200 | =================================== | 201 | 3GPP Access | 202 | +----+ | 203 | +------|MME |----+ | 204 | | +----+ | | 205 | | | | 206 | S1-AP | | S11 | 207 | | | | 208 | +---+ +-----+ S5-c | 209 +=======|eNB|============| SGW |===============+ 210 +---+ S1-u +-----+ S5-u 211 <----GTP----> | <---PMIPV6/GTP--->| 213 Figure 2 Hybrid access service in Fixed mobile convergence 215 In Figure 2, CPE (either home or enterprise) is connected to 216 internet via fixed access network using DSL as well as wireless 217 access network using 4G cellular network. 219 The fixed access network BNG is connected to the 220 PGW using 3GPP s2b reference point [TS23401]. The 4G cellular 221 network is connected to the same PGW using S5 reference point (GPRS 222 Tunneling Protocol (GTP) or Proxy Mobile IPV6 (PMIPV6) [RFC5213]) as 223 specified by the 3GPP system architecture [TS23401]. 225 The 3GPP as well non-3GPP access is bonded in CPE 226 and the HAG which consist of NBF and PGW function. The bonding at 227 HAG is achieved by allocating the same "IP address" when LTE access 228 is setup on s5 and fixed (DSL) access over s2b. 230 The packet distribution policies applied to the bonded 231 session on the HAG and CPE. Policies applied on HAG helps steering 232 downlink traffic on specific access type or distribute percentage of 233 traffic across both access types on per flow basis or per packet 234 basis. Similarly policies applied CPE helps steering uplink traffic 235 on specific access type or distribute percentage of traffic on per 236 flow basis or per packet basis. 238 4.2. Integrated BNG and SGW/PGW 240 <----------------Fixed Path--------------> 242 +------+ +------+ 244 | AAA | | PCRF | 246 +------+ +------+ 247 |---------- | 248 | 249 +---+ _----_ +---+ _----_ +------+ **** 250 |CPE| _(Fixed )_ | | _( )_ | HAG | ** ** 251 | |<==( Access )==|SN |==( Operator )==|(S/PGW|==*Internet* 252 +---+ (_ _) | | (_Network_) | BNG) | ** ** 253 ^ '----' +---+ '----' +------+ **** 254 | DSL Access PMIPv6/GTP Tunnel 255 | ^ ^ 256 | Non-3GPP access | | 257 | ================================= | | 258 | 3GPP Access | | 259 | +----+ | | 260 | +------|MME |--------------------+ | 261 | | +----+ S11-c | 262 | | S1-AP | 263 | | | 264 | +---+ | 265 +=======|eNB|================================+ 266 +---+ S1-u 267 <------------GTP------------> 268 Figure 3 Integrated BNG,SGW,PGW with HAG 270 In Figure 3 , CPE is connected to internet through HAG by fixed and 271 wireless access. HAG consist of BNG,SGW/PGW and NBF function. 273 HAG performs address assignment for all access types and acts as IP 274 anchor point for IP services. 276 5. HAG Function 278 5.1. Address Assignment 280 ======== :::::::: ======= 282 CPE LTE/DSL HAG 284 ======== :::::::: ======= 286 5.1.1. Separate BNG and PGW 288 Following are steps for address allocation when BNG and PGW are 289 separate. HAG in this case performs the NBF and PGW function. 291 [...CPE obtains LTE WAN IF address "A" during Pdp from HAG...] 293 (...CPE performs LTE attach for IMSI "X" APN "Y"...) 295 (...HAG allocates address "A" from APN.............) 297 [...CPE obtains DSL WAN IF address "A" during PPPoE from HAG...] 298 (...CPE begins the PPPoE setup with BNG....................) 300 (...BNG authenticates the CPE .............................) 302 (...BNG receives all the 3GPP attributes from AAA server...) 304 (...BNG signals on s2b to HAG for address allocation.......) 306 (...HAG receives the s2b attach for APN "Y" with same IMSI.) 308 (...HAG finds session for IMSI "X" in APN "Y" RAT=LTE......) 310 (...HAG bonds the LTE session with s2b session.............) 312 (...HAG returns address "A" in S2b response to BNG.........) 314 (...BNG stitches the PPPoE session with s2b session .......) 316 (...BNG returns the address "A" in PPPoE/DHCP to CPE.......) 318 HAG performs Address assignment for all access type which acts as 319 anchor point for IP services. 321 APN "Y" on HAG is configured with property of "bonding" so that it 322 can accept request from another access type for the same IMSI within 323 same APN for same Pdp type. This helps in bonding the session with 324 another access type session instead of treating it as handover. 326 BNG performs authentication of CPE. As part of 327 authentication, it also receives the 3GPP attributes like IMSI, APN 328 and HAG information from AAA server. It uses (3GPP) S2b reference 329 point in [TS23402], specified by the 3GPP system architecture to get 330 IP address from HAG and stitches the fixed access (PPPoE/IPoE) 331 session with the s2b session both in control plane and data-plane. 333 The CPE remains unchanged as it uses standard method of IP 334 address management for IPv4 and IPv6, on LTE link as well as DSL 335 link. 337 5.1.2. Integrated BNG and SGW/PGW 339 Following are the steps for address allocation when BNG, SGW and PGW 340 function is integrated along with the HAG function 342 [...CPE obtains LTE WAN IF address "A" during Pdp from PGW/HAG...] 343 (...CPE performs LTE attach for IMSI "X" APN "Y"...) 345 (...HAG allocates address "A" from APN.............) 347 [...CPE obtains DSL WAN IF address "A" during PPPoE from BNG/HAG..] 349 (...CPE begins the PPPoE setup with on BNG.................) 351 (...BNG authenticates the CPE .............................) 353 (...BNG receives all the 3GPP attributes from AAA server...) 355 (...BNG/HAG finds session for IMSI "X" in APN "Y" RAT=LTE..) 357 (...BNG bonds the PPPoE session with LTE session...........) 359 (...BNG returns the address "A" in PPPoE/DHCP to CPE.......) 361 Address assignment is done in the HAG for all access type which acts 362 as anchor point for IP services. 364 APN "Y" on HAG is configured with property of "bonding" so that it 365 can accept request from another access type for the same IMSI within 366 same APN for same Pdp type. This helps in bonding the session with 367 another access type. 369 BNG performs authentication of CPE. As part of 370 authentication, it also receives the 3GPP attributes like IMSI, APN 371 and PGW information from AAA server. BNG detects that the PGW is 372 local and hence internally bonds the fixed (PPPoE/IPoE) session with 373 the LTE session with the same IMSI and APN. As part of bonding it 374 uses the same IP allocated for the LTE session and sends back in 375 PPPoE response or waits for DHCP to request for the address in the 376 DHCP response. Traffic distribution policies are applied to the 377 bonded LTE and fixed (PPPoE/IPoE) session to distribute the traffic. 379 The CPE remains unchanged as it uses standard method of 380 IP address management for IPv4 and IPv6, on LTE link as well as DSL 381 link. 383 5.2. Setup and Tunnel Management 385 There is no extra tunnel apart from the link tunnels representing 386 each access used in this solution. 388 Any link can be setup first. The link that sets up access tunnel 389 first gets the IP address from HAG. The link which comes later is 390 bonded in HAG with the control plane to the existing access tunnel 391 and the same IP address is returned to the later tunnel setup. 393 BNG stitches the fixed (PPPoE/IPoE) tunnel to the s2b tunnel 394 setup towards the HAG. As part of it, it maps the setup and tear 395 down event of the fixed (PPPoE/IPoE) tunnel to the s2b tunnel and 396 vice versa. 398 5.3. Traffic distribution policies 400 As mentioned in earlier section, traffic distribution policies for 401 upstream traffic is applied at CPE where as the downstream policies 402 are applied at HAG. Given that single IP is allocated to all access 403 type in this solution, it greatly helps to do flow mobility within 404 the accesses. 406 Traffic distribution can be done on per flow basis, per MP- 407 TCP sub-flow basis or on per packet. Flow based traffic distribution 408 avoids out-of-order packets resulting out of differential latencies 409 on each access tunnel and doesn't require buffering resources at the 410 CPE or HAG to re-order the packets. 412 Policies applied in CPE can be downloaded out-of-band using 413 ANDSF mechanism. Some CPEs are capable of sending initial uplink 414 traffic on access type using random hashing but are able to move the 415 flow to the access type chosen by network for the downlink traffic 416 of that flow. Such CPEs need zero to minimal traffic policy 417 configuration. 419 Traffic distribution policies applied at HAG for downlink 420 traffic distribution can help in distributing flows or packets using 421 hashing. 423 Traffic policies MUST have the flexibility to 424 configure the amount of percentage of traffic to be steered over a 425 given access type. This allows addressing the use case where 426 operator MAY want to send a particular type of traffic over a 427 specific access type (Video over DSL). In this case a video rule 428 with affinity of DSL access can be set to steer 100 percent of 429 traffic over DSL link whereas traffic matching any-any rule can be 430 set to steer 50% over DSL and 50 % over LTE. 432 Traffic policies MUST allow asymmetric affinity association of 433 access type for upstream and downstream traffic which allows 434 splitting of a flow in upstream and downstream direction. Applying 435 such polices operators can use LTE for uplink where as fixed (DSL) 436 for downlink. Studies of such configuration have shown application 437 performance improvement over use same access for an application. 439 For the use case where a desired access link bandwidth is 440 filled first (MAX-FILL) and use of second link is for the bandwidth 441 overflow, one can use flow based or packet based approach for 442 traffic distribution. The desirability of preferred access can be 443 due to cheap access path or link characteristics for the given 444 application. 446 To fulfill this requirement, two rate Three color marker 447 (trTCM) can be used. Each access link uses token buckets to meter 448 the packets as per configuration both at CPE and the HAG. Colored 449 based policy is applied at CPE and HAG to steer packets to an access 450 based on color. For ex. Green packets are steered to DSL if that is 451 the preferred access, whereas yellow packets are steered over LTE 452 access. 454 If flow based distribution is used, then on reaching certain 455 thresholds there MUST be flexibility to move the flows from 456 preferred access (say DSL) to another (LTE) by changing the 457 percentage distribution. However, moving of FAT flows MAY result in 458 under utilization of preferred access link. Similarly once the 459 threshold drops, the traffic can be move back to preferred access by 460 reverting the percentage distribution. 462 To avoid FAT flow distribution issues, packet based 463 traffic distribution can be used to fully utilize the preferred 464 access. Packets sent over different access for the same flow can 465 reach out-of-order at the receiving end, due to differential 466 transport latencies. Hence receiving end needs buffering and re- 467 ordering capabilities to deliver flow packets correctly to an 468 application. 470 5.4. Path Management 472 This solution relies of existing mechanism of Path management for 473 wireless (LTE) and fixed (PPPoE/IPoE) tunnels. 475 In case of failure of any access tunnel the traffic MUST be 476 switched to the alternate available access tunnel based on the 477 traffic distribution policies. 479 5.5. Backward compatibility 481 This solution does not introduce any new protocol extensions. In 482 this solution the CPE uses ANDSF routing rules to do the traffic 483 distribution downloaded off-band in the CPE. 485 The policies at the HAG are either local configured or downloaded 486 from PCRF. The existing service (ex. IPTV traffic MUST remain on DSL 487 access) remains untouched by configuring appropriate traffic 488 distribution policies. The exact configuration of those policies is 489 outside the scope of this document. 491 6. Applicability in Mobile networks 493 A mobile node (MN) (also called User Equipment UE) connected to a 494 3GPP access network specified by the 3GPP system architecture 495 [TS23401] is connected over the S5 reference point (Proxy Mobile 496 IPV6 (PMIPV6) [RFC5213] or GPRS Tunneling Protocol (GTP)) to the PGW 497 where the mobile node's session is anchored. 499 The (3GPP) S2b reference point in [TS23402], specified by 500 the 3GPP system architecture defines a mechanism for allowing the 501 mobile node (MN) attached to an "untrusted" non-3GPP IP access 502 network to securely connect to a 3GPP network and access IP 503 services. In this scenario, the mobile node establishes an IPSec ESP 504 tunnel [RFC4303] to the security gateway called evolved packet data 505 gateway (ePDG) and which in turn establishes a GPRS Tunneling 506 Protocol (GTP) [TS23402] or Proxy Mobile IPV6 (PMIPV6) [RFC5213] 507 tunnel to the packet data gateway (PGW) [TS23402] where the mobile 508 node's session is anchored. 510 The figure below shows the hybrid access figure where the 511 mobile node is connected to 3GPP and non-3GPP access simultaneously 512 getting access to IP services via a PGW. 514 <---------- IKEv2/IPsec ------> | <------ PMIPv6/GTP ----->| 516 +------------+ 517 | ePDG | 518 | +--------+ | 519 +---+ _----_ | | IPsec | | _----_ +-----+ **** 520 |MN | _( )_ | | Module | | _( )_ | HAG/| ** ** 521 | |<=( Internet )=| +--------+ |=( Operator )=|(PGW)|-*Internet* 522 +---+ (_ _) | : | (_Network_) +-----+ ** ** 523 ^ '----' | +--------+ | '----' ^ **** 524 | IPsec Tunnel| | GTPv2 | |PMIPv6/GTP Tunnel | 525 | | | MAG | | | 526 | | +--------+ | | 527 | +------------+ | 528 | Non-3GPP access | 529 | ======================================= | 530 | 3GPP Access | 531 | +----+ | 532 | +------|MME |----+ | 533 | | +----+ | | 534 | | | | 535 | S1-AP | | S11 | 536 | | | | 537 | +---+ +-----+ S5-c | 538 +=======|eNB|============| SGW |=================+ 539 +---+ S1-u +-----+ S5-u 540 <------GTP-------> | <---PMIPV6/GTP--->| 542 Figure 4 Hybrid access service in Mobile network 544 In the hybrid access architecture, an User equipment (UE) is 545 connected to multiple access technology at the same time. It MAY 546 connect to same network or different IP network based on the 547 operator service. A mobile node with Third Generation Partnership 548 Project (3GPP) access technology such as LTE, UMTS and non-3GPP 549 access such as WIFI having simultaneous network connections is a use 550 case of hybrid access in mobile networks. 552 As shown in Figure 4, the LTE access is bonded with the 553 WIFI access and the same IP address is allocated on s2b as well as 554 s5 3gpp reference point. As discussed above, traffic distribution 555 policies can be applied to steer traffic over specific access type 556 or distribute over both access type to increase the bandwidth for 557 the mobile node. 559 In some mobile networks, WIFI is preferred access since 560 it's cheap, in that case policies described in MAX-FILL can be 561 applied. 563 In some mobile networks, mobile nodes are configured to prefer 564 WIFI access as local break out policy. However it's been observed 565 that if mobile node has LTE access as well WIFI access available and 566 if the mobile node connects to WIFI access over the s2b reference 567 point to the same PGW, the PGW treats it as 3GPP to non-3GPP access 568 handover and disconnecting the LTE access. But since mobile node is 569 configured to be always connected over LTE access, mobile node 570 reconnects over LTE and the PGW treats it as non-3GPP to 3GPP access 571 handover disconnecting the WIFI access. This results in ping-pong 572 effect. Since both accesses are simultaneously connected, in this 573 solution, it helps in addressing the ping-pong issue as well. 575 7. Inter-working with MP-TCP 577 When used flow based hashing, it is possible that a FAT flow may 578 cause to over congest the access link. To address FAT flow issues 579 operator can deploy a MCP with the NBF. Operator in that case can 580 apply policy to ensure the FAT flow traffic is split among small 581 multi-path flows which can be seamlessly moved between the access 582 types based on traffic distribution policies. 584 Inter-working helps operators in using MP-TCP for 585 selective traffic thus ensuring effective utilization of buffering 586 resources both at CPE as well as at MCP. 588 8. Security Considerations 590 The security considerations applicable while deploying the access 591 types independently remains same while deploying network based 592 bonding hybrid access architecture. This specification does not 593 introduce any new security vulnerabilities. 595 9. IANA considerations 597 10. References 599 10.1. Normative References 601 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 602 Requirement Levels", BCP 14, RFC 2119, March 1997. 604 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 605 RFC 4303, December 2005. 607 [24.008] 3GPP, "Technical specification Group Core Network and 608 Terminals: Mobile radio interface Layer 3 specification; 609 Core network protocols; Stage 3" 611 [24.301] 3GPP, "Technical specification Group Core Network and 612 Terminals: Non-Access-Stratum (NAS) protocol for Evolved 613 Packet System (EPS); Stage 3" 615 [NAMPTCP] M.Bouchadair et al. "draft-nam-mptcp-deployment- 616 considerations-00", (work in progress), October 2016 618 10.2. Informative References 620 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V.,Chowdhury, K., 621 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 623 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 624 Mobile IPv6", RFC 5844, May 2010. 626 [TS23402] 3GPP, "Architecture enhancements for non-3GPP accesses", 627 . 628 [TS23401] 3GPP, General Packet Radio Service (GPRS) enhancements 629 for Evolved Universal Terrestrial Radio Access Network (E- 630 UTRAN) access. 632 11. Acknowledgments 634 The authors are thankful for the detailed review and valuable 635 feedback provided by Guiu Fabregas and Laurent Thiebaut. 637 Authors' Addresses 639 Praveen Muley 640 Nokia 641 805. E. Middle Field Rd. 642 Mountain View, CA, 94043 644 Email: praveen.muley@nokia.com 646 Wim Henderickx 647 Nokia 648 Coperniscuslaan 50 649 Antwerp 2018 650 Belgium 652 Email: wim.henderickx@nokia.com 654 Geng Liang 655 China Mobile 656 32 Xuanwumen West Street, 657 Xicheng District, Beijing, 100053, 658 China 660 Email: gengliang@chinamobile.com 662 Hans Liu 663 D-Link Corporation 664 289, Sinhu 3rd Road, 665 Neihu District, Taipei City, 11494, 666 Taiwan, R.O.C. 668 Email: hans_liu@dlink.com.tw 670 Loris Cardullo 671 Vodafone 672 Italy 674 Email: Loris.Cardullo@vodafone.com 676 Jonathan Newton 677 Vodafone 678 United Kingdom 680 Email: Jonathan.Newton@vodafone.com 681 SungHoon Seo 682 Korea Telecom 683 South Korea 685 Email: sh.seo@kt.com 687 Sagiv Draznin 688 Verizon Wireless 689 USA 691 Email: Sagiv.Draznin@VerizonWireless.com 693 Basavaraj Patil 694 AT&T 695 2900 W. Plano Pkwy 696 Plano, Texas 75075 697 USA 699 Email: bp801n@att.com