idnits 2.17.1 draft-sarikaya-dmm-for-wifi-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 3, 2014) is 3582 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 319, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-architecture' is defined on line 359, 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 6877 == Outdated reference: A later version (-06) exists of draft-matsushima-stateless-uplane-vepc-02 == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-04 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Sarikaya 3 Internet-Draft Huawei USA 4 Intended status: Standards Track L. Xue 5 Expires: January 4, 2015 Huawei 6 July 3, 2014 8 Distributed Mobility Management Protocol for WiFi Users in Fixed Network 9 draft-sarikaya-dmm-for-wifi-00.txt 11 Abstract 13 As networks are moving towards flat architectures, a distributed 14 approach is needed to mobility management. This document defines a 15 distributed mobility management protocol. Protocol is based on 16 mobility aware virtualized routing system with software-defined 17 network support. Routing is in Layer 2 in the access network and in 18 Layer 3 in the core network. Smart phones access the network over 19 IEEE 802.11 (Wi-Fi) interface and can move in home, hotspot and 20 enterprise buildings. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 4, 2015. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Detailed Protocol Operation . . . . . . . . . . . . . . . . . 4 60 4.1. Layer 2 Mobility in Access Network . . . . . . . . . . . 4 61 4.2. Layer 3 Mobility and Routing in Core Network . . . . . . 5 62 5. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . . 7 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 9.2. Informative references . . . . . . . . . . . . . . . . . 8 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 Centralized mobility anchoring has several drawbacks such as single 74 point of failure, routing in a non optimal route, overloading of the 75 centralized data anchor point due to the data traffic increase, low 76 scalability of the centralized route and context management 77 [I-D.ietf-dmm-requirements]. 79 In this document, we define a routing based distributed mobility 80 management protocol. The protocol assumes a flat network 81 architecture as shown in Figure 1. No client software is assumed at 82 the mobile node. 84 IP level mobility signaling needs to be used even when MN is 85 connected to a home network or a hotspot. Distributed anchors in the 86 protocol are called Unified Gateways and they represent an evolution 87 from the Broadband Network Gateway (BNG) currently in use. 89 . 91 Cloud _.---------+----------. 92 ,' ' ---''Virtualized Control Plane---'-. 93 ( +---+ +---+ +---+ `. 94 `. |VM1| |VM2| |VM3| ) 95 +---+ +---+ +--,+ ,' 96 IP Routers | _.---------+----------. 97 with SDN Clients ,----'' | `---'-. 98 and Agents ,-' | | \ `-. 99 ,' | | ' `. 100 ( | IP Network| \ ) 101 `. | | ' ,' 102 `-. | ; ,\' 103 ;-----. ---------+------------------ 104 +-------+ +-------+ +-------+ 105 | UGW | | UGW | | UGW | 106 +-------+ +-------+ +-------+ 107 ,' | `. 108 ( Access Network ) 109 `. | ,' 110 +-----+ +-----+ +-----+ 111 | RG | | RG | | RG | 112 +-----+ +-----+ +-----+ 113 +-----+ +-----+ 114 | MN | ----move---------------> | MN | 115 +-----+ +-----+ 117 Figure 1: Architecture of Wi-Fi DMM Protocol 119 2. Terminology 121 This document uses the terminology defined in 122 [I-D.matsushima-stateless-uplane-vepc]. 124 3. Overview 126 This section presents an overview of the protocol. See also 127 Figure 1. 129 Access routers (AR) are Unified Gateways (UGW) that are the access 130 network gateways that behave similarly as Evolved packet Core (EPC) 131 Edge Router (EPC-E) in [I-D.matsushima-stateless-uplane-vepc]. UGW 132 is configured an anycast address on the interface facing the 133 Residential Gateway (RG). RGs use this address to forward packets 134 from the users. The fixed access network delivers the packets to 135 geographically closes UGW. 137 Wi-Fi smart phone, the mobile node (MN) is assigned a unique prefix 138 using either Stateless Address Auto Configuration (SLAAC) or by a 139 DHCP server which could be placed in the cloud. In case of SLAAC, RG 140 is delegated the prefixes by DHCP server using [RFC3633]. 142 Prefix assignments to MNs are consistent with the prefixes assigned 143 to UGWs that are shorter than /64. These prefixes are part of the 144 operator's prefix(es) which could be /32, /24, etc. 146 The mobile node can move at home or in a hot spot from one Access 147 Point (AP) to another AP and MN mobility will be handled in Layer 2 148 using IEEE 802.11k and 802.11r. 150 When MN moves from one UGW into another UGW, IP mobility signaling 151 needs to be introduced. In this document we use Handover Initiate/ 152 Handover Acknowledge (HI/HAck) messages defined in [RFC5949]. 153 Handover Initiate message can be initiated by either previous UGW 154 (predictive handover) or the next UGW (reactive UGW). In reactive 155 handover, RG establishes a new connection with the next UGW when MN 156 moves to this RG and provides previous UGW address. This will 157 trigger the next UGW to send HI message to the previous UGW. 158 Previous UGW sends HAck messages which establishes a tunnel between 159 previous and next UGWs. Previous UGW sends packets destined to MN to 160 the new UGW which in turn sends them to MN. 162 Note that the mobility signaling just described is control plane 163 functionality. Control plane in our document is moved to the cloud, 164 thus mobility signaling happens at the cloud, possibly between two 165 virtual machines (VM). 167 Upstream packets from MN at the new UGW are sent as usual but 168 downstream packets may need special path establishment if MN's prefix 169 is not hosted at the new UGW. In this case Software-Defined 170 Networking (SDN) is used. SDN allows Routing Information Bases (RIB) 171 in a subset of the upstream routers to be modified to enable the 172 downstream packets to be routed to the new UGW but not to the 173 previous UGW. 175 4. Detailed Protocol Operation 177 In this section, Layer 2 and Layer 3 mobility procedures are 178 explained. 180 4.1. Layer 2 Mobility in Access Network 182 In the access network, RG MAC address acts as an identifier for the 183 MN. Access network switches are controlled by SDN. Controller to 184 Switch interface uses Extensible Messaging and Presence Protocol 185 (XMPP)[RFC6121]. XMPP is based on a general subscribe-publish 186 message bus. SDN controller publishes forwarding instructions to the 187 subscribing switch. Forwarding instructions could be Open Flow like 188 match-forward instructions. 190 Access network is organized as interconnected switches. The switch 191 connected to the RG is called egress switch. The switch connected to 192 the UGW is called ingress switch. IEEE 802.1ad standard for VLAN (Q- 193 in-Q) is used in the access network, where S-VLAN denotes RG groups, 194 and C-VLAN determines traffic classes. One S-VLAN tag is assigned to 195 create one or more VLAN paths between egress and ingress switches. 197 MN mobility in the access network can be tracked by keeping a table 198 consisting of MN IP address and RG MAC address pairs. In this 199 document SDN controllers keep the mobility table. This table is used 200 to select proper S-VLAN downstream path from ingress switch to egress 201 switch and upstream path from egress switch to ingress switch. 203 After a new MN with WiFi associates with RG, RG sends an Unsolicited 204 Neighbor Advertisement (NA) messages upstream. This NA message is 205 constructed as per [RFC4861] but the Source Address field is set to a 206 unicast address of MN. NA message is received by SDN controller and 207 it enables SDN controller to update the mobility table. SDN 208 controller selects proper path including S-VLAN and ingress switch to 209 forward the traffic from this MN. The controller establishes the 210 forwarding needed on these switches. 212 4.2. Layer 3 Mobility and Routing in Core Network 214 MN moving from one RG to another may eventually require MN moving 215 from one UGW to another. This is Layer 3 mobility. 217 Predictive handover happens when MN just before leaving the previous 218 RG (pRG) for the next RG (nRG) MN is able to send an 802.11 message 219 containing MN MAC address and nRG MAC address, e.g. learned from 220 beacons to the pRG (called Leave Report in Figure 2. pRG then sends a 221 handover indication message to pUGW providing MN and nRG addresses 222 (called Leave Indication) and this could happen between two 223 respective virtual machines in the cloud. This message results in 224 pUGW getting nUGW information and then sending Handover Initiate 225 message to nUGW, which also could happen in the cloud. nUGW replies 226 with Handover Acknowledge message. pUGW sends any packets destined 227 to MN to nUGA after being alerted by the control plane. MN moves to 228 nRG and nUGW is informed about this from Layer 2 mobility 229 Section 4.1. uGW delivers MN's outstanding packets to MN. 231 MN P-RG N-RG (P-UGW) (N-UGW) Cloud 232 | Leave | | | | | 233 (a) |--Report-->| | | | | 234 | | | | | | 235 | | Leave | | | 236 (b) | |------indication------>| | | 237 | | | | | | 238 | | | | | | 239 (c) | | | |----HI---->| | 240 | | | | | | 241 | | | | | | 242 (d) | | | |<---HAck---| | 243 | | | |===========| | 245 Figure 2: Predictive Handover 247 Reactive handover handover happens when MN attaches the new RG from 248 the previous RG (called Join Report in Figure 3. MN is able to 249 signal in 802.11 association messages previous RG MAC address. nUGW 250 receives new association information together with pRG information, 251 possibly in the cloud (called Handover Indication). nUGW finds pUGW 252 address and sends HI message to pUGW, again happening between two 253 virtual machines in the cloud. pUGW after receiving indication from 254 the cloud server delivers any outstanding MN's packets to nUGW which 255 in turn delivers them to MN. 257 MN P-RG N-RG (P-UGW) (N-UGW) Cloud 258 | Join | | | | | 259 (a) |--Report------------->| | | | 260 | | | Handover | | 261 (b) | | |------Indication------->| | 262 | | | | | | 263 (c) | | | |<----HI----| | 264 | | | | | | 265 (d) | | | |----HAck-->| | 266 | | | | | | 267 (e) | | | |<--------->| | 268 | | | | | data | 269 (f) | | | |===========| | 271 Figure 3: Reactive Handover 273 Note that Handover Initiate and Handover Acknowledge messages used in 274 this document carry only a subset of parameters defined in [RFC5949]. 275 Also no involvement with the Local Mobility Anchor (LMA) is needed. 277 After handover, SDN route establishment in upstream routers needs to 278 take place. I2RS Agent as XMPP Client in nUGW and in pUGW inform the 279 handover to I2RS Clients as XMPP Server upstream. I2RS Agent at pUGW 280 removes any routing information for MN. XMPP Clients and Servers 281 engage in structured request-response interactions. These 282 interactions are needed for these purposes: I2RS Client publishes the 283 new route for this MN to nUGW at the router upstream. I2RS Agent at 284 nUGW adds new routing information for this MN into its RIB. 286 As a result for MNs that handover, upstream routing that takes place 287 is not modified up to the lowest level of routers. The lowest level 288 of routers handle the mobility but proper modifications so that the 289 packets reach the right Unified Gateway. One way to achive this 290 could be using host routes. 292 5. IPv4 Support 294 IPv4 can be supported similarly as in vEPC 295 [I-D.matsushima-stateless-uplane-vepc]. UGW stays as IPv6 node 296 receiving from all RGs IPv6 packets and forwarding them upstream. 298 IPv4 MN is supported at the RG. RG has B4 functionality of DS-Lite 299 [RFC6333] or CLAT entity for 464XLAT [RFC6877]. RG encapsulates IPv4 300 packets in DS-Lite or translates IPv4 packets in 464XLAT into IPv6 301 packets making sure that UGW stays IPv6 only. 303 6. Security Considerations 305 TBD. 307 7. IANA Considerations 309 TBD. 311 8. Acknowledgements 313 TBD. 315 9. References 317 9.1. Normative References 319 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 320 Requirement Levels", BCP 14, RFC 2119, March 1997. 322 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 323 Host Configuration Protocol (DHCP) version 6", RFC 3633, 324 December 2003. 326 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 327 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 328 September 2007. 330 [RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. 331 Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, 332 September 2010. 334 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 335 Protocol (XMPP): Instant Messaging and Presence", RFC 336 6121, March 2011. 338 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 339 Stack Lite Broadband Deployments Following IPv4 340 Exhaustion", RFC 6333, August 2011. 342 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 343 Combination of Stateful and Stateless Translation", RFC 344 6877, April 2013. 346 9.2. Informative references 348 [I-D.ietf-dmm-requirements] 349 Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen, 350 "Requirements for Distributed Mobility Management", draft- 351 ietf-dmm-requirements-17 (work in progress), June 2014. 353 [I-D.matsushima-stateless-uplane-vepc] 354 Matsushima, S. and R. Wakikawa, "Stateless user-plane 355 architecture for virtualized EPC (vEPC)", draft- 356 matsushima-stateless-uplane-vepc-02 (work in progress), 357 February 2014. 359 [I-D.ietf-i2rs-architecture] 360 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 361 Nadeau, "An Architecture for the Interface to the Routing 362 System", draft-ietf-i2rs-architecture-04 (work in 363 progress), June 2014. 365 Authors' Addresses 367 Behcet Sarikaya 368 Huawei USA 369 5340 Legacy Dr. Building 175 370 Plano, TX 75024 372 Phone: +1 469 277 5839 373 Email: sarikaya@ieee.org 374 Li Xue 375 Huawei 376 NO.156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan, 377 Beijing, HaiDian District 100095 378 China 380 Email: xueli@huawei.com