idnits 2.17.1 draft-sarikaya-dmm-for-wifi-01.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 24, 2014) is 3465 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 561, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-architecture' is defined on line 633, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 6244 ** Downref: Normative reference to an Informational RFC: RFC 6877 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802.11i' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802.11-2007' == Outdated reference: A later version (-06) exists of draft-matsushima-stateless-uplane-vepc-03 == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-05 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Sarikaya 3 Internet-Draft L. Xue 4 Intended status: Standards Track Huawei 5 Expires: April 27, 2015 October 24, 2014 7 Distributed Mobility Management Protocol for WiFi Users in Fixed Network 8 draft-sarikaya-dmm-for-wifi-01.txt 10 Abstract 12 As networks are moving towards flat architectures, a distributed 13 approach is needed to mobility management. This document defines a 14 distributed mobility management protocol. Protocol is based on 15 mobility aware virtualized routing system with software-defined 16 network support. Routing is in Layer 2 in the access network and in 17 Layer 3 in the core network. Smart phones access the network over 18 IEEE 802.11 (Wi-Fi) interface and can move in home, hotspot and 19 enterprise buildings. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 27, 2015. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Detailed Protocol Operation . . . . . . . . . . . . . . . . . 4 59 4.1. Layer 2 Mobility in Access Network . . . . . . . . . . . 4 60 4.2. Layer 3 Mobility and Routing in Core Network . . . . . . 5 61 5. Authentication and Charging . . . . . . . . . . . . . . . . . 7 62 5.1. Authentication . . . . . . . . . . . . . . . . . . . . . 7 63 5.2. Charging . . . . . . . . . . . . . . . . . . . . . . . . 11 64 6. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . . 13 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 67 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 70 10.2. Informative references . . . . . . . . . . . . . . . . . 14 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 73 1. Introduction 75 Centralized mobility anchoring has several drawbacks such as single 76 point of failure, routing in a non optimal route, overloading of the 77 centralized data anchor point due to the data traffic increase, low 78 scalability of the centralized route and context management 79 [I-D.ietf-dmm-requirements]. 81 In this document, we define a routing based distributed mobility 82 management protocol. The protocol assumes a flat network 83 architecture as shown in Figure 1. No client software is assumed at 84 the mobile node. 86 IP level mobility signaling needs to be used even when MN is 87 connected to a home network or a hotspot. Distributed anchors in the 88 protocol are called Unified Gateways and they represent an evolution 89 from the Broadband Network Gateway (BNG) currently in use. 91 . 93 Cloud _.---------+----------. 94 ,' ' ---''Virtualized Control Plane---'-. 95 ( +---+ +---+ +---+ `. 96 `. |VM1| |VM2| |VM3| ) 97 +---+ +---+ +--,+ ,' 98 IP Routers | _.---------+----------. 99 with SDN Clients ,----'' | `---'-. 100 and Agents ,-' | | \ `-. 101 ,' | | ' `. 102 ( | IP Network| \ ) 103 `. | | ' ,' 104 `-. | ; ,\' 105 ;-----. ---------+------------------ 106 +-------+ +-------+ +-------+ 107 | UGW | | UGW | | UGW | 108 +-------+ +-------+ +-------+ 109 ,' | `. 110 ( Access Network ) 111 `. | ,' 112 +-----+ +-----+ +-----+ 113 | RG | | RG | | RG | 114 +-----+ +-----+ +-----+ 115 +-----+ +-----+ 116 | MN | ----move---------------> | MN | 117 +-----+ +-----+ 119 Figure 1: Architecture of Wi-Fi DMM Protocol 121 2. Terminology 123 This document uses the terminology defined in 124 [I-D.matsushima-stateless-uplane-vepc]. 126 3. Overview 128 This section presents an overview of the protocol. See also 129 Figure 1. 131 Access routers (AR) are Unified Gateways (UGW) that are the access 132 network gateways that behave similarly as Evolved packet Core (EPC) 133 Edge Router (EPC-E) in [I-D.matsushima-stateless-uplane-vepc]. UGW 134 is configured an anycast address on the interface facing the 135 Residential Gateway (RG). RGs use this address to forward packets 136 from the users. The fixed access network delivers the packets to 137 geographically closes UGW. 139 Wi-Fi smart phone, the mobile node (MN) is assigned a unique prefix 140 using either Stateless Address Auto Configuration (SLAAC) or by a 141 DHCP server which could be placed in the cloud. In case of SLAAC, RG 142 is delegated the prefixes by DHCP server using [RFC3633]. 144 Prefix assignments to MNs are consistent with the prefixes assigned 145 to UGWs that are shorter than /64. These prefixes are part of the 146 operator's prefix(es) which could be /32, /24, etc. 148 The mobile node can move at home or in a hot spot from one Access 149 Point (AP) to another AP and MN mobility will be handled in Layer 2 150 using IEEE 802.11k and 802.11r. Authentication is handled in Layer 2 151 using [IEEE-802.11i] and [IEEE-802.11-2007] (as described in 152 Section 5). 154 When MN moves from one UGW into another UGW, IP mobility signaling 155 needs to be introduced. In this document we use Handover Initiate/ 156 Handover Acknowledge (HI/HAck) messages defined in [RFC5949]. 157 Handover Initiate message can be initiated by either previous UGW 158 (predictive handover) or the next UGW (reactive UGW). In reactive 159 handover, RG establishes a new connection with the next UGW when MN 160 moves to this RG and provides previous UGW address. This will 161 trigger the next UGW to send HI message to the previous UGW. 162 Previous UGW sends HAck messages which establishes a tunnel between 163 previous and next UGWs. Previous UGW sends packets destined to MN to 164 the new UGW which in turn sends them to MN. 166 Note that the mobility signaling just described is control plane 167 functionality. Control plane in our document is moved to the cloud, 168 thus mobility signaling happens at the cloud, possibly between two 169 virtual machines (VM). 171 Upstream packets from MN at the new UGW are sent as usual but 172 downstream packets may need special path establishment if MN's prefix 173 is not hosted at the new UGW. In this case Software-Defined 174 Networking (SDN) is used. SDN allows Routing Information Bases (RIB) 175 in a subset of the upstream routers to be modified to enable the 176 downstream packets to be routed to the new UGW but not to the 177 previous UGW. 179 4. Detailed Protocol Operation 181 In this section, Layer 2 and Layer 3 mobility procedures are 182 explained. 184 4.1. Layer 2 Mobility in Access Network 186 In the access network, RG MAC address acts as an identifier for the 187 MN. Access network switches are controlled by SDN. Controller to 188 Switch interface uses Extensible Messaging and Presence Protocol 189 (XMPP)[RFC6121]. XMPP is based on a general subscribe-publish 190 message bus. SDN controller publishes forwarding instructions to the 191 subscribing switch. Forwarding instructions could be Open Flow like 192 match-forward instructions. 194 Access network is organized as interconnected switches. The switch 195 connected to the RG is called egress switch. The switch connected to 196 the UGW is called ingress switch. IEEE 802.1ad standard for VLAN (Q- 197 in-Q) is used in the access network, where S-VLAN denotes RG groups, 198 and C-VLAN determines traffic classes. One S-VLAN tag is assigned to 199 create one or more VLAN paths between egress and ingress switches. 201 MN mobility in the access network can be tracked by keeping a table 202 consisting of MN IP address and RG MAC address pairs. In this 203 document SDN controllers keep the mobility table. This table is used 204 to select proper S-VLAN downstream path from ingress switch to egress 205 switch and upstream path from egress switch to ingress switch. 207 After a new MN with WiFi associates with RG, RG sends an Unsolicited 208 Neighbor Advertisement (NA) messages upstream. This NA message is 209 constructed as per [RFC4861] but the Source Address field is set to a 210 unicast address of MN. NA message is received by SDN controller and 211 it enables SDN controller to update the mobility table. SDN 212 controller selects proper path including S-VLAN and ingress switch to 213 forward the traffic from this MN. The controller establishes the 214 forwarding needed on these switches. 216 4.2. Layer 3 Mobility and Routing in Core Network 218 MN moving from one RG to another may eventually require MN moving 219 from one UGW to another. This is Layer 3 mobility. 221 Predictive handover happens when MN just before leaving the previous 222 RG (pRG) for the next RG (nRG) MN is able to send an 802.11 message 223 containing MN MAC address and nRG MAC address, e.g. learned from 224 beacons to the pRG (called Leave Report in Figure 2. pRG then sends a 225 handover indication message to pUGW providing MN and nRG addresses 226 (called Leave Indication) and this could happen between two 227 respective virtual machines in the cloud. This message results in 228 pUGW getting nUGW information and then sending Handover Initiate 229 message to nUGW, which also could happen in the cloud. nUGW replies 230 with Handover Acknowledge message. pUGW sends any packets destined 231 to MN to nUGA after being alerted by the control plane. MN moves to 232 nRG and nUGW is informed about this from Layer 2 mobility 233 Section 4.1. uGW delivers MN's outstanding packets to MN. 235 MN P-RG N-RG (P-UGW) (N-UGW) Cloud 236 | Leave | | | | | 237 (a) |--Report-->| | | | | 238 | | | | | | 239 | | Leave | | | 240 (b) | |------indication------>| | | 241 | | | | | | 242 | | | | | | 243 (c) | | | |----HI---->| | 244 | | | | | | 245 | | | | | | 246 (d) | | | |<---HAck---| | 247 | | | |===========| | 249 Figure 2: Predictive Handover 251 Reactive handover handover happens when MN attaches the new RG from 252 the previous RG (called Join Report in Figure 3. MN is able to 253 signal in 802.11 association messages previous RG MAC address. nUGW 254 receives new association information together with pRG information, 255 possibly in the cloud (called Handover Indication). nUGW finds pUGW 256 address and sends HI message to pUGW, again happening between two 257 virtual machines in the cloud. pUGW after receiving indication from 258 the cloud server delivers any outstanding MN's packets to nUGW which 259 in turn delivers them to MN. 261 MN P-RG N-RG (P-UGW) (N-UGW) Cloud 262 | Join | | | | | 263 (a) |--Report------------->| | | | 264 | | | Handover | | 265 (b) | | |------Indication------->| | 266 | | | | | | 267 (c) | | | |<----HI----| | 268 | | | | | | 269 (d) | | | |----HAck-->| | 270 | | | | | | 271 (e) | | | |<--------->| | 272 | | | | | data | 273 (f) | | | |===========| | 275 Figure 3: Reactive Handover 277 Note that Handover Initiate and Handover Acknowledge messages used in 278 this document carry only a subset of parameters defined in [RFC5949]. 279 Also no involvement with the Local Mobility Anchor (LMA) is needed. 281 After handover, SDN route establishment in upstream routers needs to 282 take place. In this case NETCONF protocol [RFC6241] and YANG 283 modeling [RFC6020] are used. I2RS Agent as NETCONF Client in nUGW 284 and in pUGW inform the handover to I2RS Clients as NETCONF Server 285 upstream. I2RS Agent at pUGW removes any routing information for MN. 286 NETCONF Clients and Servers engage in simple Remote Procedure Call 287 (RPC) request-reply interactions. These interactions are needed for 288 these purposes: I2RS Client publishes the new route for this MN to 289 nUGW at the router upstream. I2RS Agent at nUGW adds new routing 290 information for this MN into its RIB. 292 A YANG module for DMM for WiFi is TBD. Detailed NETCONF operations 293 using this module is TBD. We explain how the two can be used 294 together. Client and Server exchange their capabilities using hello 295 messages. Client builds and sends an operation defined in YANG 296 module, encoded in XML, within RPC request message [RFC6244]. Server 297 verifies the contents of the request against the YANG module and then 298 performs the requested operation and then sends a response, encoded 299 in XML, in RPC reply message. The request could be to add a host 300 route and the reply is the result of this request. 302 As a result for MNs that handover, upstream routing that takes place 303 is not modified up to the lowest level of routers. The lowest level 304 of routers handle the mobility but proper modifications so that the 305 packets reach the right Unified Gateway. One way to achive this 306 could be using host routes. 308 5. Authentication and Charging 310 5.1. Authentication 312 Extensible Authentication Protocol (EAP)[RFC3748] is preferred for MN 313 authentication in IEEE 802.11 (Wi-Fi) network. When a MN tries to 314 connect to the WiFi, it needs to mutually authenticate with the 315 network server first. A successful EAP authentication procedure must 316 result in a Pairwise Master Key(PMK) (defined in [IEEE-802.11i]) for 317 the traffic encryption between the MN and the AR. 319 When a MN moves at home or in a hot spot from one AP to another AP in 320 the same UGW, it is possible that it may to undergo a full EAP 321 authentication (as defined in[RFC3748]). However, there are simplied 322 several authentication methods (defined in [IEEE-802.11-2007] ): 324 o Preauthentication: When The MN supplicant may authenticate with 325 both pRG and nRG at a time. Successful completion of EAP 326 authentication between the MN and nRG establishes a pair of PMKSA 327 on both the MN and nRG. When the MN moves to the nRG, the 328 authentication has already done, which is shown as follows. 330 +---------------+ 331 | Authentication| 332 | Server | 333 +--*----*-------+ 334 Preauthentication <..........* 335 / * 336 +---------*-----+ 337 |/ *UGW | 338 *---------*-----+ 339 ,' / * | `. 340 ( / Access *Network ) 341 `. / * | ,' 342 +-----* +-*---+ +-----+ 343 | RG /| ******* RG | | RG | 344 +----/+ ***** +-----+ +-----+ 345 +-----**** +-----+ 346 | MN | ----move-----> | MN | 347 +-----+ +-----+ 349 Preauthentication 351 o Cached PMK: The RG reserves the PMK as a result of previous 352 authentication. When the MN is roaming back to the previous RG, 353 if a successful EAP authentication has happened. The MN can 354 retain the 802.11 connection based on PMK information reserved. 355 When the authentication is handled by the UGW as an Authenticator. 356 When the MN moves to the nRG, a join report packet will be 357 initiated from the MN to nRG for IEEE802.11 connection to the same 358 UGW. The nRG can retain the PMK information from the UGW which is 359 reserved during the successful authentication procedure between 360 the MN and the pRG, as shown in Figure 4. 362 +---------------+ 363 | Authentication| 364 | Server | 365 +--*------------+ 366 Authentication <....* 367 / 368 *-------------+ 369 /| UGW | PMK Cache 370 / +-------------+ / 371 ,' / | / `. 372 ( / Access Network/ ) 373 `. / | / ,' 374 +-----* +-----+ | MN | 379 +-----+ +-----+ 381 Figure 4: Cached PMK-UGW Authenticator 383 When a MN moves at home or in a hot spot from one AP to another AP in 384 the same UGW, it is possible that it may to undergo a full EAP 385 authentication (as defined in[RFC3748]). However, there are several 386 simple authentication methods (defined in [IEEE-802.11-2007] ): 388 When MN moves from one UGW into another UGW, a join report packet 389 will be initiated from the MN to nRG for IEEE802.11 connection. It 390 is possible that it may to undergo a full EAP authentication (as 391 defined in[RFC3748]). However, because of service performance and 392 contiunity requirement, the operators prefer to avoid the full EAP 393 authentication. There are several simplied authentication methods 394 (defined in [IEEE-802.11-2007] ): 396 o Preauthentication: MN supplicant may authenticate with both pRG 397 and nRG at a time. Successful completion of EAP authentication 398 between the MN and nRG establishes a pair of PMKSA on both the MN 399 and nRG. When the MN moves to the nRG, the authentication has 400 already been completed, which is shown as follows. 402 +---------------+ 403 | Authentication| 404 | Server | 405 +--*----*-------+ 406 Preauthentication <..........* 407 / * 408 +-------+ / +-*-----+ +-------+ 409 | UGW | / | *UGW | | UGW | 410 +-------+ / +-*-----+ +-------+ 411 ,' / * | `. 412 ( / Access *Network ) 413 `. / * | ,' 414 +-----* +-*---+ +-----+ 415 | RG /| ******* RG | | RG | 416 +----/+ ***** +-----+ +-----+ 417 +-----**** +-----+ 418 | MN | ----move-----> | MN | 419 +-----+ +-----+ 421 o Cached PMK: The RG reserves the PMK as a result of previous 422 authentication. When the MN is roaming back to the previous RG, 423 if a successful EAP authentication has happened. The MN can 424 retain the 802.11 connection based on PMK information reserved. 425 When the authentication is handled by the UGW as an Authenticator. 426 When the MN moves to the nRG, a join report packet will be 427 initiated from the MN to nRG for IEEE802.11 connection to nUGW. 428 The nRG can retain the PMK information from the nUGW, the nUGW may 429 can retain the reserved PMK from the pUGW based on HI message. 431 +---------------+ 432 | Authentication| 433 | Server | 434 +--*------------+ 435 Authentication <..../ 436 / 437 +---------+ HI(PMK Q)+---------+ 438 PMK Cached| pUGW |<-------- | nUGW | 439 ++--------+ -------> +--------++ ^ Join Report Msg 440 ,' | / HAck(PMK) | | `. 441 ( | / | | ) 442 `. | / Access Network | | ,' 443 +----+* +-----+ ++--+-+ 444 | RG /| | RG | | RG | 445 +----/+ +-----+ +-----+ 446 +----- +-----+ 447 | MN | ----move--------------- | MN | 448 +-----+ +-----+ 450 The above Layer 2 operations do not affect Layer 3. MN does not 451 change the prefix/address assigned to it initially. 453 5.2. Charging 455 When MN moves from one UGW into another UGW, the charging needs to be 456 considered. In this document we describe two cases, one operator and 457 two interworking operators. 459 One operator case. 461 Two operators case. If the pUGW and nUGW are belonging to two 462 different operators. 464 There are two possibilities. The traffic is directed to the visited 465 network, and traffic routed back to home. 467 Charging 468 +---------------+ +---------------+ 469 |pAuthentication|<-----------|nAuthentication| 470 | Server |----------->| Server | 471 +---------------+ ++--------------+ 472 Data *********************** Charging 473 | * ^ 474 | * | 475 | * | 476 +---------+ +-+----*-++ 477 | pUGW | | nUGW* | 478 ++--------+ +------*-++ ^ Join Report Msg 479 ,' | * | | `. 480 ( | * | | ) 481 `. | Access Network * | | ,' 482 +----++ +-----+ * ++--+-+ 483 | RG | | RG | * | RG | 484 +-----+ +-----+ * +-----+ 485 +----- +*----+ 486 | MN | ----move--------------- | MN | 487 +-----+ +-----+ 489 Two operators interworking - Traffic offload in visited network 490 +---------------+ charging +---------------+ 491 |pAuthentication|----------->|nAuthentication| 492 | Server | | Server | 493 +---------------+ ^ ++--------------+ 494 | 495 Data | charging | 496 ********** | | 497 * | | 498 +-------*-+ Charging +-+-------+ 499 | pUGW* |<---------+ nUGW | 500 ++------*-+ +--------++ ^ Join Report Msg 501 ,' | ******************** | | `. 502 ( | * | | ) 503 `. | Access Network * | | ,' 504 +----++ +-----+ * ++--+-+ 505 | RG | | RG | * | RG | 506 +-----+ +-----+ * +-----+ 507 +----- +*----+ 508 | MN | ----move--------------- | MN | 509 +-----+ +-----+ 511 Two operators interworking - Traffic routed back to home 513 +---------------+ 514 | Authentication| 515 | Server | 516 +-- ------------+ ^ 517 | Charging 518 | 519 +---------+ +----+----+ 520 | pUGW | | nUGW | 521 ++--------+ +--------++ ^ Join Report Msg 522 ,' | | | `. 523 ( | | | ) 524 `. | Access Network | | ,' 525 +----++ +-----+ ++--+-+ 526 | RG | | RG | | RG | 527 +-----+ +-----+ +-----+ 528 +----- +-----+ 529 | MN | ----move--------------- | MN | 530 +-----+ +-----+ 532 Charging in one operator 534 6. IPv4 Support 536 IPv4 can be supported similarly as in vEPC 537 [I-D.matsushima-stateless-uplane-vepc]. UGW stays as IPv6 node 538 receiving from all RGs IPv6 packets and forwarding them upstream. 540 IPv4 MN is supported at the RG. RG has B4 functionality of DS-Lite 541 [RFC6333] or CLAT entity for 464XLAT [RFC6877]. RG encapsulates IPv4 542 packets in DS-Lite or translates IPv4 packets in 464XLAT into IPv6 543 packets making sure that UGW stays IPv6 only. 545 7. Security Considerations 547 TBD. 549 8. IANA Considerations 551 TBD. 553 9. Acknowledgements 555 TBD. 557 10. References 559 10.1. Normative References 561 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 562 Requirement Levels", BCP 14, RFC 2119, March 1997. 564 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 565 Host Configuration Protocol (DHCP) version 6", RFC 3633, 566 December 2003. 568 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 569 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 570 3748, June 2004. 572 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 573 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 574 September 2007. 576 [RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. 577 Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, 578 September 2010. 580 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 581 Network Configuration Protocol (NETCONF)", RFC 6020, 582 October 2010. 584 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 585 Protocol (XMPP): Instant Messaging and Presence", RFC 586 6121, March 2011. 588 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 589 Bierman, "Network Configuration Protocol (NETCONF)", RFC 590 6241, June 2011. 592 [RFC6244] Shafer, P., "An Architecture for Network Management Using 593 NETCONF and YANG", RFC 6244, June 2011. 595 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 596 Stack Lite Broadband Deployments Following IPv4 597 Exhaustion", RFC 6333, August 2011. 599 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 600 Combination of Stateful and Stateless Translation", RFC 601 6877, April 2013. 603 [IEEE-802.11i] 604 "Institute of Electrical and Electronics Engineers, 605 "Unapproved Draft Supplement to Standard for 606 Telecommunications and Information Exchange Between 607 Systems-LAN/MAN Specific Requirements -Part 11: Wireless 608 LAN Medium Access Control (MAC) and Physical Layer (PHY) 609 Specifications: Specification for Enhanced Security" "", 610 September 2004. 612 [IEEE-802.11-2007] 613 "Institute of Electrical and Electronics Engineers, 614 "Telecommunications and information exchange between 615 systems-Local and metropolitan area networks specific 616 requirements -Part 11: Wireless LAN Medium Access Control 617 (MAC) and Physical Layer (PHY) Specifications"", March 618 2007. 620 10.2. Informative references 622 [I-D.ietf-dmm-requirements] 623 Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen, 624 "Requirements for Distributed Mobility Management", draft- 625 ietf-dmm-requirements-17 (work in progress), June 2014. 627 [I-D.matsushima-stateless-uplane-vepc] 628 Matsushima, S. and R. Wakikawa, "Stateless user-plane 629 architecture for virtualized EPC (vEPC)", draft- 630 matsushima-stateless-uplane-vepc-03 (work in progress), 631 July 2014. 633 [I-D.ietf-i2rs-architecture] 634 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 635 Nadeau, "An Architecture for the Interface to the Routing 636 System", draft-ietf-i2rs-architecture-05 (work in 637 progress), July 2014. 639 Authors' Addresses 641 Behcet Sarikaya 642 Huawei 643 5340 Legacy Dr. Building 175 644 Plano, TX 75024 646 Phone: +1 469 277 5839 647 Email: sarikaya@ieee.org 649 Li Xue 650 Huawei 651 NO.156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan, 652 Beijing, HaiDian District 100095 653 China 655 Email: xueli@huawei.com