idnits 2.17.1 draft-sarikaya-dmm-for-wifi-05.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 3 instances of too long lines in the document, the longest one being 14 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 date (October 30, 2017) is 2370 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) == Outdated reference: A later version (-04) exists of draft-ietf-dmm-deployment-models-02 ** Downref: Normative reference to an Informational draft: draft-ietf-dmm-deployment-models (ref. 'I-D.ietf-dmm-deployment-models') -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802.11-2007' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802.11i' ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 6224 ** Downref: Normative reference to an Informational RFC: RFC 6244 ** Downref: Normative reference to an Informational RFC: RFC 6877 ** Downref: Normative reference to an Experimental RFC: RFC 7161 ** Obsolete normative reference: RFC 8022 (Obsoleted by RFC 8349) Summary: 8 errors (**), 0 flaws (~~), 2 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 4 Intended status: Standards Track L. Xue 5 Expires: May 3, 2018 October 30, 2017 7 Distributed Mobility Management Protocol for WiFi Users in Fixed Network 8 draft-sarikaya-dmm-for-wifi-05.txt 10 Abstract 12 As networks are moving towards flat architectures, a distributed 13 approach is needed to mobility management. This document presents a 14 use case distributed mobility management protocol called Distributed 15 Mobility Management for Wi-Fi. The protocol is based on mobility 16 aware virtualized routing system with software-defined network 17 support. Routing is in Layer 2 in the access network and in Layer 3 18 in the core network. Smart phones access the network over IEEE 19 802.11 (Wi-Fi) interface and can move in home, hotspot and enterprise 20 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 https://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 May 3, 2018. 39 Copyright Notice 41 Copyright (c) 2017 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 (https://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. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 58 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Detailed Protocol Operation . . . . . . . . . . . . . . . . . 5 60 4.1. Layer 2 Mobility in Access Network . . . . . . . . . . . 6 61 4.2. Layer 3 Mobility and Routing in Core Network . . . . . . 6 62 4.3. Route Establishment . . . . . . . . . . . . . . . . . . . 8 63 4.4. Authentication . . . . . . . . . . . . . . . . . . . . . 10 64 5. Multicast Support . . . . . . . . . . . . . . . . . . . . . . 14 65 5.1. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . 14 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 71 9.2. Informative References . . . . . . . . . . . . . . . . . 18 72 Appendix A. YANG and RPC Programs . . . . . . . . . . . . . . . 19 73 A.1. Host Routing Module . . . . . . . . . . . . . . . . . . . 19 74 A.2. Route Establishment RPCs . . . . . . . . . . . . . . . . 19 75 A.3. get-config RPC procedure for host routes . . . . . . . . 20 76 A.4. edit-config RPC procedure to create a host route . . . . 21 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 79 1. Introduction 81 Centralized mobility anchoring has several drawbacks such as single 82 point of failure, routing in a non optimal route, overloading of the 83 centralized data anchor point due to the data traffic increase, low 84 scalability of the centralized route and context management 85 [RFC7333]. 87 In this document, we define a routing based distributed mobility 88 management protocol. The protocol assumes a flat network 89 architecture as shown in Figure 1. No client software is assumed at 90 the mobile node. 92 IP level mobility signaling needs to be used even when MN is 93 connected to a home network or a hotspot. Distributed anchors in the 94 protocol are called Unified Gateways and they represent an evolution 95 from the Broadband Network Gateway (BNG) currently in use. 97 2. Conventions and Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119 [RFC2119]. 103 This document uses the terminology defined in 104 [I-D.ietf-dmm-deployment-models] and 105 [I-D.matsushima-stateless-uplane-vepc]. 107 3. Overview 109 This section presents an overview of the protocol, Distributed 110 Mobility Management for Wi-Fi protocol (DMM4WiFi). See also 111 Figure 1. 113 Access routers (AR) are Unified Gateways (UGW) that are the access 114 network gateways that behave similarly as Evolved Packet Core (EPC) 115 Edge Router (EPC-E) in [I-D.matsushima-stateless-uplane-vepc]. UGW 116 is configured an anycast address on the interface facing the 117 Residential Gateway (RG). RGs use this address to forward packets 118 from the users. The fixed access network delivers the packets to 119 geographically closest UGW. UGW plays the role of Access Data Plane 120 Node (A-DPN) defined in [I-D.ietf-dmm-deployment-models]. A-DPN and 121 UGW are interchangeably used in this document. 123 Cloud _.---------+----------. 124 ,' ' ---''Virtualized Control Plane---'-. 125 ( +---+ +---+ +---+ `. 126 `. |VM1| |VM2| |VM3| ) 127 +---+ +---+ +--,+ ,' 128 IP Routers | _.---------+----------. 129 with SDN Clients ,----'' | `---'-. 130 and Agents ,-' | | \ `-. 131 ,' | | ' `. 132 ( | IP Network| \ ) 133 `. | | ' ,' 134 `-. | ; ,\' 135 ;-----. ---------+------------------ 136 +-------+ +-------+ +-------+ 137 | A-DPN | | A-DPN | | A-DPN | 138 +-------+ +-------+ +-------+ 139 ,' | `. 140 ( Access Network ) 141 `. | ,' 142 +-----+ +-----+ +-----+ 143 | RG | | RG | | RG | 144 +-----+ +-----+ +-----+ 145 +-----+ +-----+ 146 | MN | ----move---------------> | MN | 147 +-----+ +-----+ 149 Figure 1: SDN Based Architecture of Wi-Fi Protocol 151 Wi-Fi smart phone, the mobile node (MN) is assigned a unique prefix 152 using either Stateless Address Auto Configuration (SLAAC) or by a 153 DHCP server which could be placed in the cloud. In case of SLAAC, RG 154 is delegated the prefixes by DHCP server using [RFC3633]. 156 Prefix assignments to MNs are consistent with the prefixes assigned 157 to UGWs that are shorter than /64. These prefixes are part of the 158 operator's prefix(es) which could be /32, /24, etc. 160 The mobile node can move at home or in a hot spot from one Access 161 Point (AP) to another AP and MN mobility will be handled in Layer 2 162 using IEEE 802.11k and 802.11r. Authentication is handled in Layer 2 163 using [IEEE-802.11i] and [IEEE-802.11-2007] (as described in 164 Section 4.4). 166 When MN moves from one A-DPN into another A-DPN, IP mobility 167 signaling needs to be introduced. In this document we use Handover 168 Initiate/ Handover Acknowledge (HI/HAck) messages defined in 169 [RFC5949]. Handover Initiate message can be initiated by either 170 previous UGW (predictive handover) or the next UGW (reactive UGW). 172 In reactive handover, RG establishes a new connection with the next 173 UGW when MN moves to this RG and provides previous UGW address. This 174 will trigger the next UGW to send HI message to the previous UGW. 175 Previous UGW sends HAck messages which establishes a tunnel between 176 previous and next UGWs. Previous UGW sends packets destined to MN to 177 the new UGW which in turn sends them to MN. 179 Note that the mobility signaling just described is control plane 180 functionality, i.e. between Access-Control Plane Nodes (A-CPN). 181 Control plane in our document is moved to the cloud, thus mobility 182 signaling happens at the cloud, possibly between two virtual machines 183 (VM), A-CPNs. 185 Upstream packets from MN at the new A-DPN establish the initial 186 routing path when MN first enters the system. This path needs to be 187 updated as MN moves from one A-DPN to another, i.e. MN handover. 188 Since MN keeps the prefix initially assigned, after handover, the new 189 upstream path establishment may establish host routes in the upstream 190 routers. This route is refreshed as long as MN stays under the same 191 A-DPN. Handover signaling and subsequent upstream path establishment 192 is very critical because the downstream packets may need to follow 193 the path that is established for MN. 195 Software-Defined Networking (SDN) is used in DMM4WiFi in both Layer 2 196 and Layer 3 routing management. In case of Layer 2 routing, the Open 197 Flow Switch Protocol is used as the south bound interface between the 198 SDN Controller and Layer 2 access network switches. Extensible 199 Messaging and Presence Protocol (XMPP) is used as the north bound 200 interface between the SDN controller and DMM4WiFi application. 201 DMM4WiFi Layer 3 routing is based on SDN controllers manipulating 202 Routing Information Bases (RIB) in a subset of the upstream routers. 203 In this case south bound interface is the NETCONF protocol which is 204 based on the Remote Procedure Call (RPC) protocol and YANG. I2RS 205 architecture is used in this context. 207 Mobile node generates interface identifier using [RFC7217] in SLAAC. 208 With this method, MN interface identifiers will be different when MN 209 moves from one A-DPN to another A-DPN. MN MAY have different IPv6 210 addresses due to this method of interface identifier generation. 212 4. Detailed Protocol Operation 214 In this section, Layer 2 and Layer 3 mobility procedures are 215 explained. 217 4.1. Layer 2 Mobility in Access Network 219 In the access network, RG MAC address acts as an identifier for the 220 MN. Access network switches are controlled by SDN. Controller to 221 Switch interface uses a protocol such as Extensible Messaging and 222 Presence Protocol (XMPP) [RFC6121]. XMPP is based on a general 223 subscribe-publish message bus. SDN controller publishes forwarding 224 instructions to the subscribing switch. Forwarding instructions 225 could be Open Flow like match-forward instructions. Open Flow 226 protocol can also be used [ONFv1.5]. 228 Access network is organized as interconnected switches. The switch 229 connected to the RG is called egress switch. The switch connected to 230 the UGW is called ingress switch. IEEE 802.1ad standard for VLAN (Q- 231 in-Q) is used in the access network, where S-VLAN denotes RG groups, 232 and C-VLAN determines traffic classes. One S-VLAN tag is assigned to 233 create one or more VLAN paths between egress and ingress switches. 235 MN mobility in the access network can be tracked by keeping a table 236 consisting of MN IP address and RG MAC address pairs. In this 237 document SDN controllers keep the mobility table. This table is used 238 to select proper S-VLAN downstream path from ingress switch to egress 239 switch and upstream path from egress switch to ingress switch. 241 After a new MN with WiFi associates with RG, RG sends an Unsolicited 242 Neighbor Advertisement (NA) message upstream. This NA message is 243 constructed as per [RFC4861] but the Source Address field is set to a 244 unicast address of MN. NA message is received by SDN controller and 245 it enables SDN controller to update the mobility table. SDN 246 controller selects proper path including S-VLAN and ingress switch to 247 forward the traffic from this MN. The controller establishes the 248 forwarding needed on these switches [IEEE-Paper], i.e. Layer 2 route. 250 The packet eventually reaches the closest UGW due to the anycast 251 addressing used at the access network interfaces. UGW forwards this 252 packet to the upstream router and so on. The upstream router 253 establishes a route for MN in its routing table with MN's prefix and 254 with the UGW as the next hop. Prefixes in those routes get smaller 255 and smaller as the packet moves upstream in the routing hierarchy. 256 The routing protocol used could be BGP or other protocols like IS-IS. 258 4.2. Layer 3 Mobility and Routing in Core Network 260 MN moving from one RG to another may eventually require MN moving 261 from one A-DPN to another. This is Layer 3 mobility. 263 Predictive handover happens when MN just before leaving the previous 264 RG (pRG) for the next RG (nRG) MN is able to send an 802.11 message 265 containing MN MAC address and nRG MAC address, e.g. learned from 266 beacons to the pRG (called Leave Report in Figure 2. pRG then sends a 267 handover indication message to pUGW providing MN and nRG addresses 268 (called Leave Indication) and this could happen between two 269 respective virtual machines in the cloud. This message results in 270 pUGW getting nUGW information and then sending Handover Initiate 271 message to nUGW, which also could happen in the cloud. nUGW replies 272 with Handover Acknowledge message. pUGW sends any packets destined 273 to MN to nUGW after being alerted by the control plane. MN moves to 274 nRG and nUGW is informed about this from Layer 2 mobility 275 Section 4.1. uGW delivers MN's outstanding packets to MN. 277 MN P-RG N-RG (P-UGW) (N-UGW) Cloud 278 | Leave | | | | | 279 (a) |--Report-->| | | | | 280 | | | | | | 281 | | Leave | | | 282 (b) | |------indication------>| | | 283 | | | | | | 284 | | | | | | 285 (c) | | | |----HI---->| | 286 | | | | | | 287 | | | | | | 288 (d) | | | |<---HAck---| | 289 | | | |===========| | 291 Figure 2: Predictive Handover 293 Reactive handover handover happens when MN attaches the new RG from 294 the previous RG, called Join Report in Figure 3. MN is able to 295 signal in 802.11 association messages previous RG MAC address. nUGW 296 or A-CPN receives new association information together with pRG 297 information, possibly in the cloud (called Handover Indication). nUGW 298 finds pUGW address and sends HI message to pUGW, again happening 299 between two virtual machines in the cloud. pUGW after receiving 300 indication from the cloud server delivers any outstanding MN's 301 packets to nUGW which in turn delivers them to MN. 303 MN P-RG N-RG (P-UGW) (N-UGW) Cloud 304 | Join | | | | | 305 (a) |--Report------------->| | | | 306 | | | Handover | | 307 (b) | | |------Indication------->| | 308 | | | | | | 309 (c) | | | |<----HI----| | 310 | | | | | | 311 (d) | | | |----HAck-->| | 312 | | | | | | 313 (e) | | | |<--------->| | 314 | | | | | data | 315 (f) | | | |===========| | 317 Figure 3: Reactive Handover 319 Note that Handover Initiate and Handover Acknowledge messages used in 320 this document carry only a subset of parameters defined in [RFC5949]. 321 Also no involvement with the Local Mobility Anchor (LMA) [RFC5213] is 322 needed. 324 4.3. Route Establishment 326 After handover, SDN route establishment in upstream routers needs to 327 take place. In this case NETCONF protocol [RFC6241] and YANG 328 modeling [RFC6020] are used. 330 Client and Server exchange their capabilities using NETCONF message 331 layer message called hello messages. Client builds and sends an 332 operation defined in YANG module, encoded in XML, within RPC request 333 message [RFC6244]. Server verifies the contents of the request 334 against the YANG module and then performs the requested operation and 335 then sends a response, encoded in XML, in RPC reply message. 337 Defining configuration data is the primary focus of YANG. 338 Configuration data is writable (rw - read-write) data that is 339 required to transform a system from its initial default state into 340 its current state. There is also state data (ro - read-only) which 341 is a set of data that has been obtained by the system at runtime. An 342 example is routing table changes made by routing protocols in 343 response to the ongoing traffic. 345 A YANG module for routing management is given in [I-D.ietf-netmod- 346 routing-cfg]. The core routing data model consists of three YANG 347 modules, ietf-routing, ietf-ipv4-unicast-routing, ietf- ipv6-unicast- 348 routing. The core routing data model has two trees: configuration 349 data and state data trees. "routing-instance" or "rib" trees have to 350 be populated with at least one entry in the device, and additional 351 entries may be configured by a client. Normally the server creates 352 the required item as an entry in state data. Additional entries may 353 be created in the configuration by a client via the NETCONF protocol 354 using RPC messages like edit-config and copy-config. 356 The user may provide supplemental configuration of system- controlled 357 entries by creating new entries in the configuration with the desired 358 contents. In order to bind these entries with the corresponding 359 entry in the state data list, the key of the configuration entry has 360 to be set to the same value as the key of the state entry. 362 RPC get message can be used to retrieve all or part of the running 363 configuration data store merged with the device's state data. RPC 364 get-config operation retrieves configuration data only. RPC fib- 365 route message defined in [RFC8022] retrieves a routing instance for 366 the active route in the Forwarding Information Base (FIB) which is 367 the route that is currently used for sending datagrams to a 368 destination host whose address is passed as an input parameter. So 369 fib-route message plays the role of show route command line interface 370 command. 372 NETCONF protocol and ietf-routing YANG module can be used for route 373 establishment after handover. As a result for MNs that handover, 374 upstream routing that takes place is not modified up to the lowest 375 level of routers. The lowest level of routers handle the mobility 376 but only proper modifications are needed so that the packets reach 377 the right Unified Gateway, i.e. nUGW. 379 I2RS Agent as NETCONF Server in nUGW and in pUGW inform the handover 380 to I2RS Clients as NETCONF Client upstream. I2RS Agent at pUGW 381 removes any routing information for MN by first using get-config to 382 retrieve the active route for MN and then an edit-config message with 383 delete operation to delete the active route making sure that the same 384 key is used. 386 I2RS Agent in nUGW after the handover needs to add a new routing 387 table entry for MN. Due to the topological correctness of MN's 388 prefix, the new route could be a host route. Next this route is 389 propagated upstream. In this case, nUGW starts the process. SDN 390 Controller as I2RS Client knows that MN handover is successfully 391 completed. SDN Controller starts the upstream route establishment 392 process starting with the I2RS Agent at the upstream router. Either 393 a new route or the host route is added with shorter prefix. Route 394 propagation continues until MN's prefix becomes topologically correct 395 at which point route propagation stops. 397 Route propagation at the lowest level starts with I2RS Agent as 398 NETCONF Server in nUGW informing the handover to I2RS Client as 399 NETCONF Client upstream. I2RS Client then checks any routing 400 information for MN by first using get-config to retrieve the active 401 route for MN to make sure that none exits and MN prefix is 402 topologically incorrect. Next I2RS client issues an edit-config 403 message with create operation to add a host route for the new MN. 404 I2RS Client then informs this route to I2RS Client upstream which 405 creates a similar route at the I2RS Agent upstream. 407 In Appendix A, we present our experimental work using YANG data 408 modelling language which has its own syntax and NETCONF protocol 409 which is XML-based remote procedure call (RPC) mechanism. HTTP based 410 RESTCONF could also be used in a similar way. Two RPC call examples 411 are given. RPC call in Appendix A.3 shows a get-config filter with 412 rtr0 as the key and it is used to retrieve a specific route with a 413 given destination prefix and next hop address. RPC call in 414 Appendix A.4 shows an example edit-config create operation to create 415 a new route with specific route parameters. 417 4.4. Authentication 419 Extensible Authentication Protocol (EAP)[RFC3748] is preferred for MN 420 authentication in IEEE 802.11 (Wi-Fi) network. When a MN tries to 421 connect to the WiFi, it needs to mutually authenticate with the 422 network server first. A successful EAP authentication procedure must 423 result in a Pairwise Master Key(PMK) (defined in [IEEE-802.11i]) for 424 the traffic encryption between the MN and the AR. 426 When a MN moves at home or in a hot spot from one AP to another AP in 427 the same UGW, it is possible that it may to undergo a full EAP 428 authentication (as defined in[RFC3748]). However, there are several 429 simplified authentication methods (defined in [IEEE-802.11-2007] ): 431 o Preauthentication: When The MN supplicant may authenticate with 432 both pRG and nRG at a time. Successful completion of EAP 433 authentication between the MN and nRG establishes a pair of PMKSA on 434 both the MN and nRG. When the MN moves to the nRG, the 435 authentication has already done, which is shown as follows. 437 +---------------+ 438 | Authentication| 439 | Server | 440 +--*----*-------+ 441 Preauthentication <..........* 442 / * 443 +---------*-----+ 444 |/ *UGW | 445 *---------*-----+ 446 ,' / * | `. 447 ( / Access *Network ) 448 `. / * | ,' 449 +-----* +-*---+ +-----+ 450 | RG /| ******* RG | | RG | 451 +----/+ ***** +-----+ +-----+ 452 +-----**** +-----+ 453 | MN | ----move-----> | MN | 454 +-----+ +-----+ 456 o Cached PMK: The RG reserves the PMK as a result of previous 457 authentication. When the MN is roaming back to the previous RG, if a 458 successful EAP authentication has happened. The MN can retain the 459 802.11 connection based on PMK information reserved. When the 460 authentication is handled by the UGW as an Authenticator. When the 461 MN moves to the nRG, a join report packet will be initiated from the 462 MN to nRG for IEEE802.11 connection to the same UGW. The nRG can 463 retain the PMK information from the UGW which is reserved during the 464 successful authentication procedure between the MN and the pRG, as 465 shown in Figure 4. 467 +---------------+ 468 | Authentication| 469 | Server | 470 +--*------------+ 471 Authentication <....* 472 / 473 *-------------+ 474 /| UGW | PMK Cache 475 / +-------------+ / 476 ,' / | / `. 477 ( / Access Network/ ) 478 `. / | / ,' 479 +-----* +-----+ | MN | 484 +-----+ +-----+ 486 Figure 4: Cached PMK-UGW Authenticator 488 When a MN moves at home or in a hot spot from one AP to another AP in 489 the same UGW, it is possible that it may to undergo a full EAP 490 authentication (as defined in[RFC3748]). However, there are several 491 simple authentication methods (defined in [IEEE-802.11-2007] ): 493 When MN moves from one UGW into another UGW, a join report packet 494 will be initiated from the MN to nRG for IEEE802.11 connection. It 495 is possible that it may to undergo a full EAP authentication (as 496 defined in[RFC3748]). However, because of service performance and 497 continuity requirement, the operators prefer to avoid the full EAP 498 authentication. There are several simplied authentication methods 499 (defined in [IEEE-802.11-2007] ): 501 o Preauthentication: MN supplicant may authenticate with both pRG and 502 nRG at a time. Successful completion of EAP authentication between 503 the MN and nRG establishes a pair of PMKSA on both the MN and nRG. 504 When the MN moves to the nRG, the authentication has already been 505 completed, which is shown as follows. 507 +---------------+ 508 | Authentication| 509 | Server | 510 +--*----*-------+ 511 Preauthentication <..........* 512 / * 513 +-------+ / +-*-----+ +-------+ 514 | UGW | / | *UGW | | UGW | 515 +-------+ / +-*-----+ +-------+ 516 ,' / * | `. 517 ( / Access *Network ) 518 `. / * | ,' 519 +-----* +-*---+ +-----+ 520 | RG /| ******* RG | | RG | 521 +----/+ ***** +-----+ +-----+ 522 +-----**** +-----+ 523 | MN | ----move-----> | MN | 524 +-----+ +-----+ 526 o Cached PMK: The RG reserves the PMK as a result of previous 527 authentication. When the MN is roaming back to the previous RG, if a 528 successful EAP authentication has happened. The MN can retain the 529 802.11 connection based on PMK information reserved. When the 530 authentication is handled by the UGW as an Authenticator. When the 531 MN moves to the nRG, a join report packet will be initiated from the 532 MN to nRG for IEEE802.11 connection to nUGW. The nRG can retain the 533 PMK information from the nUGW, the nUGW may can retain the reserved 534 PMK from the pUGW based on HI message. 536 +---------------+ 537 | Authentication| 538 | Server | 539 +--*------------+ 540 Authentication <..../ 541 / 542 +---------+ HI(PMK Q)+---------+ 543 PMK Cached| pUGW |<-------- | nUGW | 544 ++--------+ -------> +--------++ ^ Join Report Msg 545 ,' | / HAck(PMK) | | `. 546 ( | / | | ) 547 `. | / Access Network | | ,' 548 +----+* +-----+ ++--+-+ 549 | RG /| | RG | | RG | 550 +----/+ +-----+ +-----+ 551 +----- +-----+ 552 | MN | ----move--------------- | MN | 553 +-----+ +-----+ 555 The above Layer 2 operations do not affect Layer 3. MN does not 556 change the prefix assigned to it initially. 558 Note that charging solution is not described in this version. 560 5. Multicast Support 562 Multicast communication to the mobile nodes can be supported with an 563 Multicast Listener Discovery (MLD) Proxy at the Unified Gateway 564 [RFC4605]. Downstream protocol operations between the UGW and the 565 mobile nodes, is the MLD protocol [RFC3810]. Both any source and 566 source specific multicast are supported. 568 The mobile nodes send MLD Report message when joining a multicast 569 group [RFC3590]. UGW or MLD Proxy sends an aggregated join message 570 upstream. MN and UGW interface works as described in [RFC6224]. 571 After MN joins the group it starts to receive multicast data. 573 After a handover the mobile node moves to the next UGW, the next UGW 574 needs to get membership or listening state of this MN containing 575 group address and source list. For this purpose, Active Multicast 576 Subscription mobility option (Type 57 for IPv6) [RFC7161] can be used 577 to transfer mobile node's multicast context or subscription 578 information from the previous UGW to the next UGW, as explained 579 below. 581 In case of predictive handover, pUGW and nUGW follow the sequence of 582 steps shown in Figure 2. In case MN has multicast context 583 established before handover pUGW MUST transfer MN's multicast context 584 to nUGW. pUGW MUST add Active Multicast Subscription mobility option 585 to HI message. 587 For reactive handover pUGW and nUGW follow the sequence of steps 588 shown in Figure 3. In case MN has multicast context established 589 before handover pUGW MUST transfer MN's multicast context to nUGW. 590 pUGW MUST add Active Multicast Subscription mobility option to HAck 591 messeage. 593 After receiving the multicast context, nUGW upstream joins any new 594 multicast groups on behalf of MN. Downstream, nUGW maps downstream 595 point-to-point link to a proxy instance. 597 5.1. IPv4 Support 599 IPv4 can be supported similarly as in vEPC 600 [I-D.matsushima-stateless-uplane-vepc]. UGW stays as IPv6 node 601 receiving from all RGs IPv6 packets and forwarding them upstream. 603 IPv4 MN is supported at the RG. RG has B4 functionality of DS-Lite 604 [RFC6333], CLAT entity for 464XLAT [RFC6877], Lightweight B4 605 [RFC7596] or MAP Customer Edge [RFC7597]. RG encapsulates IPv4 606 packets using these protocols into IPv6 packets making sure that UGW 607 stays IPv6 only. 609 6. IANA Considerations 611 TBD. 613 7. Security Considerations 615 This document introduces no extra new security threat. Security 616 considerations stated in [RFC7921] and 617 [I-D.ietf-dmm-deployment-models] apply. 619 8. Acknowledgements 621 We would like to thank Ladislav Lhotka, Satoru Matsushima for 622 valuable advice. 624 9. References 626 9.1. Normative References 628 [I-D.ietf-dmm-deployment-models] 629 Gundavelli, S. and S. Jeon, "DMM Deployment Models and 630 Architectural Considerations", draft-ietf-dmm-deployment- 631 models-02 (work in progress), August 2017. 633 [IEEE-802.11-2007] 634 IEEE, "Institute of Electrical and Electronics Engineers, 635 "Telecommunications and information exchange between 636 systems-Local and metropolitan area networks specific 637 requirements -Part 11: Wireless LAN Medium Access Control 638 (MAC) and Physical Layer (PHY) Specifications", March 639 2007. 641 [IEEE-802.11i] 642 IEEE, "Institute of Electrical and Electronics Engineers, 643 "Unapproved Draft Supplement to Standard for 644 Telecommunications and Information Exchange Between 645 Systems-LAN/MAN Specific Requirements -Part 11: Wireless 646 LAN Medium Access Control (MAC) and Physical Layer (PHY) 647 Specifications: Specification for Enhanced Security,", 648 September 2004. 650 [ONFv1.5] ONF, "Open Networking Foundation, "OpenFlow Switch 651 Specification Version 1.5.0 ( Protocol version 0x06)", 652 January 2015. 654 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 655 Requirement Levels", BCP 14, RFC 2119, 656 DOI 10.17487/RFC2119, March 1997, 657 . 659 [RFC3590] Haberman, B., "Source Address Selection for the Multicast 660 Listener Discovery (MLD) Protocol", RFC 3590, 661 DOI 10.17487/RFC3590, September 2003, 662 . 664 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 665 Host Configuration Protocol (DHCP) version 6", RFC 3633, 666 DOI 10.17487/RFC3633, December 2003, 667 . 669 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 670 Levkowetz, Ed., "Extensible Authentication Protocol 671 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 672 . 674 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 675 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 676 DOI 10.17487/RFC3810, June 2004, 677 . 679 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 680 "Internet Group Management Protocol (IGMP) / Multicast 681 Listener Discovery (MLD)-Based Multicast Forwarding 682 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 683 August 2006, . 685 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 686 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 687 DOI 10.17487/RFC4861, September 2007, 688 . 690 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 691 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 692 RFC 5213, DOI 10.17487/RFC5213, August 2008, 693 . 695 [RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. 696 Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, 697 DOI 10.17487/RFC5949, September 2010, 698 . 700 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 701 the Network Configuration Protocol (NETCONF)", RFC 6020, 702 DOI 10.17487/RFC6020, October 2010, 703 . 705 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 706 Protocol (XMPP): Instant Messaging and Presence", 707 RFC 6121, DOI 10.17487/RFC6121, March 2011, 708 . 710 [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base 711 Deployment for Multicast Listener Support in Proxy Mobile 712 IPv6 (PMIPv6) Domains", RFC 6224, DOI 10.17487/RFC6224, 713 April 2011, . 715 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 716 and A. Bierman, Ed., "Network Configuration Protocol 717 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 718 . 720 [RFC6244] Shafer, P., "An Architecture for Network Management Using 721 NETCONF and YANG", RFC 6244, DOI 10.17487/RFC6244, June 722 2011, . 724 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 725 Stack Lite Broadband Deployments Following IPv4 726 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 727 . 729 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 730 Combination of Stateful and Stateless Translation", 731 RFC 6877, DOI 10.17487/RFC6877, April 2013, 732 . 734 [RFC7161] Contreras, LM., Bernardos, CJ., and I. Soto, "Proxy Mobile 735 IPv6 (PMIPv6) Multicast Handover Optimization by the 736 Subscription Information Acquisition through the LMA 737 (SIAL)", RFC 7161, DOI 10.17487/RFC7161, March 2014, 738 . 740 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 741 Interface Identifiers with IPv6 Stateless Address 742 Autoconfiguration (SLAAC)", RFC 7217, 743 DOI 10.17487/RFC7217, April 2014, 744 . 746 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 747 Farrer, "Lightweight 4over6: An Extension to the Dual- 748 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 749 July 2015, . 751 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 752 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 753 Port with Encapsulation (MAP-E)", RFC 7597, 754 DOI 10.17487/RFC7597, July 2015, 755 . 757 [RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 758 Management", RFC 8022, DOI 10.17487/RFC8022, November 759 2016, . 761 9.2. Informative References 763 [I-D.matsushima-stateless-uplane-vepc] 764 Matsushima, S. and R. Wakikawa, "Stateless user-plane 765 architecture for virtualized EPC (vEPC)", draft- 766 matsushima-stateless-uplane-vepc-06 (work in progress), 767 March 2016. 769 [IEEE-Paper] 770 "Jyotirmoy Banik, et al., "IEEE 24th International 771 Conference on Computer Communication and Network 2015, 772 "Enabling Distributed Mobility Management: A Unified 773 Wireless Network Architecture Based on Virtualized Core 774 Network", DOI: 10.1109/ICCCN.2015.7288404",", August 2015. 776 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 777 Korhonen, "Requirements for Distributed Mobility 778 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 779 . 781 [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 782 Nadeau, "An Architecture for the Interface to the Routing 783 System", RFC 7921, DOI 10.17487/RFC7921, June 2016, 784 . 786 Appendix A. YANG and RPC Programs 788 In this annex, we present our YANG and RPC solutions. 790 A.1. Host Routing Module 792 We first obtained host routing YANG module using IPv6 unicast routing 793 module (ietf-ipv6-unicast-routing) which is part of ietf-routing 794 module. This module defines a list of host routes which contain host 795 address/prefix and corresponding next hop address. 797 A.2. Route Establishment RPCs 799 This program runs on ietf-ipv6-unicast-host-routing YANG module which 800 has been obtained from ietf-ipv6-unicast-routing module by defining 801 the hostroute as a list of host routes. First issue a get-config on 802 the configuration data to extract the existing route for the host 803 whose prefix is destination-prefix and the next-hop is the next-hop 804 address. Delete the route at pUGW. This procedure deletes the route 805 at pUGW. 807 809 get-config(running, filter=(destination-prefix, next-hop-address)) 811 // check the reply, make sure it is OK, i.e. does not contain element. 814 edit-config(running, delete, config) 816 Add a new route for MN at nUGW. This route is based on MN's prefix, 817 destination-prefix and the upstream router to which MN's traffic 818 should routed, next-hop-address. 820 822 get-config(running, filter=(destination-prefix, next-hop-address)) 824 // check the reply, make sure it is an error, i.e. it contains element of type application and tag data-missing i.e. no route 826 exists 828 edit-config(running, create, config) 830 Add a new host route for MN at nUGW. This route is added in case 831 MN's prefix is not topologically correct at nUGW and routers above. 833 835 get-config(running, filter=(destination-prefix, next-hop-address)) 837 // check the reply, make sure it is an error, i.e. it contains element of type application and tag data-missing, i.e. no 839 route exists 841 edit-config(running, create, config) 843 We next show in Appendix A.3 and Appendix A.4 example RPC procedures 844 for get-config and edit-config. Some arbitrary values for 845 destination prefix and next hop address are used. 847 A.3. get-config RPC procedure for host routes 849 This RPC procedure shows a get-config filter to find a record in the 850 routing information base for a specific host whose prefix is 851 2001:db8:1:0::/64 and the next-hop is 2001:db8:0:1::2. It could be 852 used for the get-config's in Appendix A.2. We validated this 853 procedure using the public domain tool pyang. 855 862 863 864 865 866 867 868 rtr0 870 871 872 873 874 2001:db8:1:0::/64 875 876 eth1 877 878 2001:db8:0:1::2 879 880 881 882 883 884 885 886 888 A.4. edit-config RPC procedure to create a host route 890 This RPC procedure shows an edit-config procedure to create a new 891 host route in the routing information base for a specific host whose 892 prefix is 2001:db8:1:0::/64 and the next-hop is 2001:db8:0:1::2. It 893 could be used for the edit-config's in Appendix A.2. We validated 894 this procedure using the public domain tool pyang. 896 903 904 905 906 907 none 908 909 910 rtr0 911 912 913 914 915 2001:db8:1:0::/64 916 917 eth1 918 919 2001:db8:0:1::2 920 921 922 923 924 925 926 927 929 Authors' Addresses 931 Behcet Sarikaya 933 Email: sarikaya@ieee.org 935 Li 937 Email: xueliucb@gmail.com