idnits 2.17.1 draft-sarikaya-dmm-for-wifi-04.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 2 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 15, 2016) is 2962 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 720, 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 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 == Outdated reference: A later version (-25) exists of draft-ietf-netmod-routing-cfg-20 -- 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-05 == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-13 Summary: 6 errors (**), 0 flaws (~~), 6 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 Huawei 4 Intended status: Standards Track L. Xue 5 Expires: September 16, 2016 Unaffiliated 6 March 15, 2016 8 Distributed Mobility Management Protocol for WiFi Users in Fixed Network 9 draft-sarikaya-dmm-for-wifi-04.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 called Distributed Mobility 16 Management for Wi-Fi protocol. The protocol is based on mobility 17 aware virtualized routing system with software-defined network 18 support. Routing is in Layer 2 in the access network and in Layer 3 19 in the core network. Smart phones access the network over IEEE 20 802.11 (Wi-Fi) interface and can move in home, hotspot and enterprise 21 buildings. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 16, 2016. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Detailed Protocol Operation . . . . . . . . . . . . . . . . . 5 61 4.1. Layer 2 Mobility in Access Network . . . . . . . . . . . 5 62 4.2. Layer 3 Mobility and Routing in Core Network . . . . . . 6 63 4.3. Route Establishment . . . . . . . . . . . . . . . . . . . 8 64 4.4. Authentication and Charging . . . . . . . . . . . . . . . 10 65 4.4.1. Authentication . . . . . . . . . . . . . . . . . . . 10 66 4.4.2. Charging . . . . . . . . . . . . . . . . . . . . . . 13 67 5. Multicast Support . . . . . . . . . . . . . . . . . . . . . . 15 68 5.1. IPv4 Support for Multicast . . . . . . . . . . . . . . . 15 69 6. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . . 16 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 75 10.2. Informative references . . . . . . . . . . . . . . . . . 19 76 Appendix A. YANG and RPC Programs . . . . . . . . . . . . . . . 20 77 A.1. Host Routing Module . . . . . . . . . . . . . . . . . . . 20 78 A.2. Route Establishment RPCs . . . . . . . . . . . . . . . . 20 79 A.3. get-config RPC procedure for host routes . . . . . . . . 21 80 A.4. edit-config RPC procedure to create a host route . . . . 22 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 83 1. Introduction 85 Centralized mobility anchoring has several drawbacks such as single 86 point of failure, routing in a non optimal route, overloading of the 87 centralized data anchor point due to the data traffic increase, low 88 scalability of the centralized route and context management 89 [I-D.ietf-dmm-requirements]. 91 In this document, we define a routing based distributed mobility 92 management protocol. The protocol assumes a flat network 93 architecture as shown in Figure 1. No client software is assumed at 94 the mobile node. 96 IP level mobility signaling needs to be used even when MN is 97 connected to a home network or a hotspot. Distributed anchors in the 98 protocol are called Unified Gateways and they represent an evolution 99 from the Broadband Network Gateway (BNG) currently in use. 101 . 103 Cloud _.---------+----------. 104 ,' ' ---''Virtualized Control Plane---'-. 105 ( +---+ +---+ +---+ `. 106 `. |VM1| |VM2| |VM3| ) 107 +---+ +---+ +--,+ ,' 108 IP Routers | _.---------+----------. 109 with SDN Clients ,----'' | `---'-. 110 and Agents ,-' | | \ `-. 111 ,' | | ' `. 112 ( | IP Network| \ ) 113 `. | | ' ,' 114 `-. | ; ,\' 115 ;-----. ---------+------------------ 116 +-------+ +-------+ +-------+ 117 | UGW | | UGW | | UGW | 118 +-------+ +-------+ +-------+ 119 ,' | `. 120 ( Access Network ) 121 `. | ,' 122 +-----+ +-----+ +-----+ 123 | RG | | RG | | RG | 124 +-----+ +-----+ +-----+ 125 +-----+ +-----+ 126 | MN | ----move---------------> | MN | 127 +-----+ +-----+ 129 Figure 1: Architecture of DMM for Wi-Fi Protocol 131 2. Terminology 133 This document uses the terminology defined in 134 [I-D.matsushima-stateless-uplane-vepc]. 136 3. Overview 138 This section presents an overview of the protocol, Distributed 139 Mobility Management for Wi-Fi protocol (DMM4WiFi). See also 140 Figure 1. 142 Access routers (AR) are Unified Gateways (UGW) that are the access 143 network gateways that behave similarly as Evolved Packet Core (EPC) 144 Edge Router (EPC-E) in [I-D.matsushima-stateless-uplane-vepc]. UGW 145 is configured an anycast address on the interface facing the 146 Residential Gateway (RG). RGs use this address to forward packets 147 from the users. The fixed access network delivers the packets to 148 geographically closest UGW. 150 Wi-Fi smart phone, the mobile node (MN) is assigned a unique prefix 151 using either Stateless Address Auto Configuration (SLAAC) or by a 152 DHCP server which could be placed in the cloud. In case of SLAAC, RG 153 is delegated the prefixes by DHCP server using [RFC3633]. 155 Prefix assignments to MNs are consistent with the prefixes assigned 156 to UGWs that are shorter than /64. These prefixes are part of the 157 operator's prefix(es) which could be /32, /24, etc. 159 The mobile node can move at home or in a hot spot from one Access 160 Point (AP) to another AP and MN mobility will be handled in Layer 2 161 using IEEE 802.11k and 802.11r. Authentication is handled in Layer 2 162 using [IEEE-802.11i] and [IEEE-802.11-2007] (as described in 163 Section 4.4). 165 When MN moves from one UGW into another UGW, IP mobility signaling 166 needs to be introduced. In this document we use Handover Initiate/ 167 Handover Acknowledge (HI/HAck) messages defined in [RFC5949]. 168 Handover Initiate message can be initiated by either previous UGW 169 (predictive handover) or the next UGW (reactive UGW). In reactive 170 handover, RG establishes a new connection with the next UGW when MN 171 moves to this RG and provides previous UGW address. This will 172 trigger the next UGW to send HI message to the previous UGW. 173 Previous UGW sends HAck messages which establishes a tunnel between 174 previous and next UGWs. Previous UGW sends packets destined to MN to 175 the new UGW which in turn sends them to MN. 177 Note that the mobility signaling just described is control plane 178 functionality. Control plane in our document is moved to the cloud, 179 thus mobility signaling happens at the cloud, possibly between two 180 virtual machines (VM). 182 Upstream packets from MN at the new UGW establish the initial routing 183 path when MN first enters the system. This path needs to be updated 184 as MN moves from one UGW to another, i.e. MN handover. Since MN 185 keeps the prefix initially assigned, after handover, the new upstream 186 path establishment may establish host routes in the upstream routers. 187 This route is refreshed as long as MN stays under the same UGW. 188 Handover signaling and subsequent upstream path establishment is very 189 critical because the downstream packets may need to follow the path 190 that is established for MN. 192 Software-Defined Networking (SDN) is used in DMM4WiFi in both Layer 2 193 and Layer 3 routing management. In case of Layer 2 routing, the Open 194 Flow Switch Protocol is used as the south bound interface between the 195 SDN Controller and Layer 2 access network switches. Extensible 196 Messaging and Presence Protocol (XMPP) is used as the north bound 197 interface between the SDN controller and DMM4WiFi application. 198 DMM4WiFi Layer 3 routing is based on SDN controllers manipulating 199 Routing Information Bases (RIB) in a subset of the upstream routers. 200 In this case south bound interface is the NETCONF protocol which is 201 based on the Remote Procedure Call (RPC) protocol and YANG. I2RS 202 architecture is used in this context. 204 Mobile node generates interface identifier using [RFC7217] in SLAAC. 205 With this method, MN interface identifiers will be different when MN 206 moves from one UGW to another UGW. MN MAY have different IPv6 207 addresses due to this method of interface identifier generation. 209 4. Detailed Protocol Operation 211 In this section, Layer 2 and Layer 3 mobility procedures are 212 explained. 214 4.1. Layer 2 Mobility in Access Network 216 In the access network, RG MAC address acts as an identifier for the 217 MN. Access network switches are controlled by SDN. Controller to 218 Switch interface uses a protocol such as Extensible Messaging and 219 Presence Protocol (XMPP)[RFC6121]. XMPP is based on a general 220 subscribe-publish message bus. SDN controller publishes forwarding 221 instructions to the subscribing switch. Forwarding instructions 222 could be Open Flow like match-forward instructions. Open Flow 223 protocol can also be used [ONFv1.5]. 225 Access network is organized as interconnected switches. The switch 226 connected to the RG is called egress switch. The switch connected to 227 the UGW is called ingress switch. IEEE 802.1ad standard for VLAN (Q- 228 in-Q) is used in the access network, where S-VLAN denotes RG groups, 229 and C-VLAN determines traffic classes. One S-VLAN tag is assigned to 230 create one or more VLAN paths between egress and ingress switches. 232 MN mobility in the access network can be tracked by keeping a table 233 consisting of MN IP address and RG MAC address pairs. In this 234 document SDN controllers keep the mobility table. This table is used 235 to select proper S-VLAN downstream path from ingress switch to egress 236 switch and upstream path from egress switch to ingress switch. 238 After a new MN with WiFi associates with RG, RG sends an Unsolicited 239 Neighbor Advertisement (NA) message upstream. This NA message is 240 constructed as per [RFC4861] but the Source Address field is set to a 241 unicast address of MN. NA message is received by SDN controller and 242 it enables SDN controller to update the mobility table. SDN 243 controller selects proper path including S-VLAN and ingress switch to 244 forward the traffic from this MN. The controller establishes the 245 forwarding needed on these switches [UTD-Paper], i.e. Layer 2 route. 247 The packet eventually reaches the closest UGW due to the anycast 248 addressing used at the access network interfaces. UGW forwards this 249 packet to the upstream router and so on. The upstream router 250 establishes a route for MN in its routing table with MN's prefix and 251 with the UGW as the next hop. Prefixes in those routes get smaller 252 and smaller as the packet moves upstream in the routing hierarchy. 253 The routing protocol used could be BGP or other protocols like IS-IS. 255 4.2. Layer 3 Mobility and Routing in Core Network 257 MN moving from one RG to another may eventually require MN moving 258 from one UGW to another. This is Layer 3 mobility. 260 Predictive handover happens when MN just before leaving the previous 261 RG (pRG) for the next RG (nRG) MN is able to send an 802.11 message 262 containing MN MAC address and nRG MAC address, e.g. learned from 263 beacons to the pRG (called Leave Report in Figure 2. pRG then sends a 264 handover indication message to pUGW providing MN and nRG addresses 265 (called Leave Indication) and this could happen between two 266 respective virtual machines in the cloud. This message results in 267 pUGW getting nUGW information and then sending Handover Initiate 268 message to nUGW, which also could happen in the cloud. nUGW replies 269 with Handover Acknowledge message. pUGW sends any packets destined 270 to MN to nUGW after being alerted by the control plane. MN moves to 271 nRG and nUGW is informed about this from Layer 2 mobility 272 Section 4.1. uGW delivers MN's outstanding packets to MN. 274 MN P-RG N-RG (P-UGW) (N-UGW) Cloud 275 | Leave | | | | | 276 (a) |--Report-->| | | | | 277 | | | | | | 278 | | Leave | | | 279 (b) | |------indication------>| | | 280 | | | | | | 281 | | | | | | 282 (c) | | | |----HI---->| | 283 | | | | | | 284 | | | | | | 285 (d) | | | |<---HAck---| | 286 | | | |===========| | 288 Figure 2: Predictive Handover 290 Reactive handover handover happens when MN attaches the new RG from 291 the previous RG (called Join Report in Figure 3. MN is able to 292 signal in 802.11 association messages previous RG MAC address. nUGW 293 receives new association information together with pRG information, 294 possibly in the cloud (called Handover Indication). nUGW finds pUGW 295 address and sends HI message to pUGW, again happening between two 296 virtual machines in the cloud. pUGW after receiving indication from 297 the cloud server delivers any outstanding MN's packets to nUGW which 298 in turn delivers them to MN. 300 MN P-RG N-RG (P-UGW) (N-UGW) Cloud 301 | Join | | | | | 302 (a) |--Report------------->| | | | 303 | | | Handover | | 304 (b) | | |------Indication------->| | 305 | | | | | | 306 (c) | | | |<----HI----| | 307 | | | | | | 308 (d) | | | |----HAck-->| | 309 | | | | | | 310 (e) | | | |<--------->| | 311 | | | | | data | 312 (f) | | | |===========| | 314 Figure 3: Reactive Handover 316 Note that Handover Initiate and Handover Acknowledge messages used in 317 this document carry only a subset of parameters defined in [RFC5949]. 318 Also no involvement with the Local Mobility Anchor (LMA) is needed. 320 4.3. Route Establishment 322 After handover, SDN route establishment in upstream routers needs to 323 take place. In this case NETCONF protocol [RFC6241] and YANG 324 modeling [RFC6020] are used. 326 Client and Server exchange their capabilities using NETCONF message 327 layer message called hello messages. Client builds and sends an 328 operation defined in YANG module, encoded in XML, within RPC request 329 message [RFC6244]. Server verifies the contents of the request 330 against the YANG module and then performs the requested operation and 331 then sends a response, encoded in XML, in RPC reply message. 333 Defining configuration data is the primary focus of YANG. 334 Configuration data is writable (rw - read-write) data that is 335 required to transform a system from its initial default state into 336 its current state. There is also state data (ro - read-only) which 337 is a set of data that has been obtained by the system at runtime. An 338 example is routing table changes made by routing protocols in 339 response to the ongoing traffic. 341 A YANG module for routing management is given in 342 [I-D.ietf-netmod-routing-cfg]. The core routing data model consists 343 of three YANG modules, ietf-routing, ietf-ipv4-unicast-routing, ietf- 344 ipv6-unicast-routing. The core routing data model has two trees: 345 configuration data and state data trees. "routing-instance" or "rib" 346 trees have to be populated with at least one entry in the device, and 347 additional entries may be configured by a client. Normally the 348 server creates the required item as an entry in state data. 349 Additional entries may be created in the configuration by a client 350 via the NETCONF protocol using RPC messages like edit-config and 351 copy-config. 353 The user may provide supplemental configuration of system- controlled 354 entries by creating new entries in the configuration with the desired 355 contents. In order to bind these entries with the corresponding 356 entry in the state data list, the key of the configuration entry has 357 to be set to the same value as the key of the state entry. 359 RPC get message can be used to retrieve all or part of the running 360 configuration data store merged with the device's state data. RPC 361 get-config operation retrieves configuration data only. RPC fib- 362 route message defined in [I-D.ietf-netmod-routing-cfg] retrieves a 363 routing instance for the active route in the Forwarding Information 364 Base (FIB) which is the route that is currently used for sending 365 datagrams to a destination host whose address is passed as an input 366 parameter. So fib-route message plays the role of show route command 367 line interface command. 369 NETCONF protocol and ietf-routing YANG module can be used for route 370 establishment after handover. As a result for MNs that handover, 371 upstream routing that takes place is not modified up to the lowest 372 level of routers. The lowest level of routers handle the mobility 373 but only proper modifications are needed so that the packets reach 374 the right Unified Gateway, i.e. nUGW. 376 I2RS Agent as NETCONF Server in nUGW and in pUGW inform the handover 377 to I2RS Clients as NETCONF Client upstream. I2RS Agent at pUGW 378 removes any routing information for MN by first using get-config to 379 retrieve the active route for MN and then an edit-config message with 380 delete operation to delete the active route making sure that the same 381 key is used. 383 I2RS Agent in nUGW after the handover needs to add a new routing 384 table entry for MN. Due to the topological correctness of MN's 385 prefix, the new route could be a host route. Next this route is 386 propagated upstream. In this case, nUGW starts the process. SDN 387 Controller as I2RS Client knows that MN handover is successfully 388 completed. SDN Controller starts the upstream route establishment 389 process starting with the I2RS Agent at the upstream router. Either 390 a new route or the host route is added with shorter prefix. Route 391 propagation continues until MN's prefix becomes topologically correct 392 at which point route propagation stops. 394 Route propagation at the lowest level starts with I2RS Agent as 395 NETCONF Server in nUGW informing the handover to I2RS Client as 396 NETCONF Client upstream. I2RS Client then checks any routing 397 information for MN by first using get-config to retrieve the active 398 route for MN to make sure that none exits and MN prefix is 399 topologically incorrect. Next I2RS client issues an edit-config 400 message with create operation to add a host route for the new MN. 401 I2RS Client then informs this route to I2RS Client upstream which 402 creates a similar route at the I2RS Agent upstream. 404 In Appendix A, we present our experimental work using YANG data 405 modelling language which has its own syntax and NETCONF protocol 406 which is XML-based remote procedure call (RPC) mechanism. HTTP based 407 RESTCONF could also be used in a similar way. Two RPC call examples 408 are given. RPC call in Appendix A.3 shows a get-config filter with 409 rtr0 as the key and it is used to retrieve a specific route with a 410 given destination prefix and next hop address. RPC call in 411 Appendix A.4 shows an example edit-config create operation to create 412 a new route with specific route parameters. 414 4.4. Authentication and Charging 416 4.4.1. Authentication 418 Extensible Authentication Protocol (EAP)[RFC3748] is preferred for MN 419 authentication in IEEE 802.11 (Wi-Fi) network. When a MN tries to 420 connect to the WiFi, it needs to mutually authenticate with the 421 network server first. A successful EAP authentication procedure must 422 result in a Pairwise Master Key(PMK) (defined in [IEEE-802.11i]) for 423 the traffic encryption between the MN and the AR. 425 When a MN moves at home or in a hot spot from one AP to another AP in 426 the same UGW, it is possible that it may to undergo a full EAP 427 authentication (as defined in[RFC3748]). However, there are simplied 428 several authentication methods (defined in [IEEE-802.11-2007] ): 430 o Preauthentication: When The MN supplicant may authenticate with 431 both pRG and nRG at a time. Successful completion of EAP 432 authentication between the MN and nRG establishes a pair of PMKSA 433 on both the MN and nRG. When the MN moves to the nRG, the 434 authentication has already done, which is shown as follows. 436 +---------------+ 437 | Authentication| 438 | Server | 439 +--*----*-------+ 440 Preauthentication <..........* 441 / * 442 +---------*-----+ 443 |/ *UGW | 444 *---------*-----+ 445 ,' / * | `. 446 ( / Access *Network ) 447 `. / * | ,' 448 +-----* +-*---+ +-----+ 449 | RG /| ******* RG | | RG | 450 +----/+ ***** +-----+ +-----+ 451 +-----**** +-----+ 452 | MN | ----move-----> | MN | 453 +-----+ +-----+ 455 Preauthentication 457 o Cached PMK: The RG reserves the PMK as a result of previous 458 authentication. When the MN is roaming back to the previous RG, 459 if a successful EAP authentication has happened. The MN can 460 retain the 802.11 connection based on PMK information reserved. 462 When the authentication is handled by the UGW as an Authenticator. 463 When the MN moves to the nRG, a join report packet will be 464 initiated from the MN to nRG for IEEE802.11 connection to the same 465 UGW. The nRG can retain the PMK information from the UGW which is 466 reserved during the successful authentication procedure between 467 the MN and the pRG, as shown in Figure 4. 469 +---------------+ 470 | Authentication| 471 | Server | 472 +--*------------+ 473 Authentication <....* 474 / 475 *-------------+ 476 /| UGW | PMK Cache 477 / +-------------+ / 478 ,' / | / `. 479 ( / Access Network/ ) 480 `. / | / ,' 481 +-----* +-----+ | MN | 486 +-----+ +-----+ 488 Figure 4: Cached PMK-UGW Authenticator 490 When a MN moves at home or in a hot spot from one AP to another AP in 491 the same UGW, it is possible that it may to undergo a full EAP 492 authentication (as defined in[RFC3748]). However, there are several 493 simple authentication methods (defined in [IEEE-802.11-2007] ): 495 When MN moves from one UGW into another UGW, a join report packet 496 will be initiated from the MN to nRG for IEEE802.11 connection. It 497 is possible that it may to undergo a full EAP authentication (as 498 defined in[RFC3748]). However, because of service performance and 499 continuity requirement, the operators prefer to avoid the full EAP 500 authentication. There are several simplied authentication methods 501 (defined in [IEEE-802.11-2007] ): 503 o Preauthentication: MN supplicant may authenticate with both pRG 504 and nRG at a time. Successful completion of EAP authentication 505 between the MN and nRG establishes a pair of PMKSA on both the MN 506 and nRG. When the MN moves to the nRG, the authentication has 507 already been completed, which is shown as follows. 509 +---------------+ 510 | Authentication| 511 | Server | 512 +--*----*-------+ 513 Preauthentication <..........* 514 / * 515 +-------+ / +-*-----+ +-------+ 516 | UGW | / | *UGW | | UGW | 517 +-------+ / +-*-----+ +-------+ 518 ,' / * | `. 519 ( / Access *Network ) 520 `. / * | ,' 521 +-----* +-*---+ +-----+ 522 | RG /| ******* RG | | RG | 523 +----/+ ***** +-----+ +-----+ 524 +-----**** +-----+ 525 | MN | ----move-----> | MN | 526 +-----+ +-----+ 528 o Cached PMK: The RG reserves the PMK as a result of previous 529 authentication. When the MN is roaming back to the previous RG, 530 if a successful EAP authentication has happened. The MN can 531 retain the 802.11 connection based on PMK information reserved. 532 When the authentication is handled by the UGW as an Authenticator. 533 When the MN moves to the nRG, a join report packet will be 534 initiated from the MN to nRG for IEEE802.11 connection to nUGW. 535 The nRG can retain the PMK information from the nUGW, the nUGW may 536 can retain the reserved PMK from the pUGW based on HI message. 538 +---------------+ 539 | Authentication| 540 | Server | 541 +--*------------+ 542 Authentication <..../ 543 / 544 +---------+ HI(PMK Q)+---------+ 545 PMK Cached| pUGW |<-------- | nUGW | 546 ++--------+ -------> +--------++ ^ Join Report Msg 547 ,' | / HAck(PMK) | | `. 548 ( | / | | ) 549 `. | / Access Network | | ,' 550 +----+* +-----+ ++--+-+ 551 | RG /| | RG | | RG | 552 +----/+ +-----+ +-----+ 553 +----- +-----+ 554 | MN | ----move--------------- | MN | 555 +-----+ +-----+ 557 The above Layer 2 operations do not affect Layer 3. MN does not 558 change the prefix assigned to it initially. 560 4.4.2. Charging 562 When MN moves from one UGW into another UGW, the charging needs to be 563 considered. In this document we describe two cases, one operator and 564 two interworking operators. 566 One operator case. 568 Two operators case. If the pUGW and nUGW are belonging to two 569 different operators. 571 There are two possibilities. The traffic is directed to the visited 572 network, and traffic routed back to home. 574 Charging 575 +---------------+ +---------------+ 576 |pAuthentication|<-----------|nAuthentication| 577 | Server |----------->| Server | 578 +---------------+ ++--------------+ 579 Data *********************** Charging 580 | * ^ 581 | * | 582 | * | 583 +---------+ +-+----*-++ 584 | pUGW | | nUGW* | 585 ++--------+ +------*-++ ^ Join Report Msg 586 ,' | * | | `. 587 ( | * | | ) 588 `. | Access Network * | | ,' 589 +----++ +-----+ * ++--+-+ 590 | RG | | RG | * | RG | 591 +-----+ +-----+ * +-----+ 592 +----- +*----+ 593 | MN | ----move--------------- | MN | 594 +-----+ +-----+ 596 Two operators interworking - Traffic offload in visited network 597 +---------------+ charging +---------------+ 598 |pAuthentication|----------->|nAuthentication| 599 | Server | | Server | 600 +---------------+ ^ ++--------------+ 601 | 602 Data | charging | 603 ********** | | 604 * | | 605 +-------*-+ Charging +-+-------+ 606 | pUGW* |<---------+ nUGW | 607 ++------*-+ +--------++ ^ Join Report Msg 608 ,' | ******************** | | `. 609 ( | * | | ) 610 `. | Access Network * | | ,' 611 +----++ +-----+ * ++--+-+ 612 | RG | | RG | * | RG | 613 +-----+ +-----+ * +-----+ 614 +----- +*----+ 615 | MN | ----move--------------- | MN | 616 +-----+ +-----+ 618 Two operators interworking - Traffic routed back to home 620 +---------------+ 621 | Authentication| 622 | Server | 623 +-- ------------+ ^ 624 | Charging 625 | 626 +---------+ +----+----+ 627 | pUGW | | nUGW | 628 ++--------+ +--------++ ^ Join Report Msg 629 ,' | | | `. 630 ( | | | ) 631 `. | Access Network | | ,' 632 +----++ +-----+ ++--+-+ 633 | RG | | RG | | RG | 634 +-----+ +-----+ +-----+ 635 +----- +-----+ 636 | MN | ----move--------------- | MN | 637 +-----+ +-----+ 639 Charging in one operator 641 5. Multicast Support 643 Multicast communication to the mobile nodes can be supported with an 644 Multicast Listener Discovery (MLD) Proxy at the Unified Gateway 645 [RFC4605]. Downstream protocol operations between the UGW and the 646 mobile nodes, is the MLD protocol [RFC3810]. Both any source and 647 source specific multicast are supported. 649 The mobile nodes send MLD Report message when joining a multicast 650 group [RFC3590]. UGW or MLD Proxy sends an aggregated join message 651 upstream. MN and UGW interface works as described in [RFC6224]. 652 After MN joins the group it starts to receive multicast data. 654 After a handover the mobile node moves to the next UGW, the next UGW 655 needs to get membership or listening state of this MN containing 656 group address and source list. For this purpose, Active Multicast 657 Subscription mobility option (Type 57 for IPv6) [RFC7161] can be used 658 to transfer mobile node's multicast context or subscription 659 information from the previous UGW to the next UGW, as explained 660 below. 662 In case of predictive handover, pUGW and nUGW follow the sequence of 663 steps shown in Figure 2. In case MN has multicast context 664 established before handover pUGW MUST transfer MN's multicast context 665 to nUGW. pUGW MUST add Active Multicast Subscription mobility option 666 to HI message. 668 For reactive handover pUGW and nUGW follow the sequence of steps 669 shown in Figure 3. In case MN has multicast context established 670 before handover pUGW MUST transfer MN's multicast context to nUGW. 671 pUGW MUST add Active Multicast Subscription mobility option to HAck 672 messeage. 674 After receiving the multicast context, nUGW upstream joins any new 675 multicast groups on behalf of MN. Downstream, nUGW maps downstream 676 point-to-point link to a proxy instance. 678 5.1. IPv4 Support for Multicast 680 For MNs with IPv4 addresses, multicast communication to MNs can be 681 supported similar to the way explained above in Section 5. Multicast 682 group management is done using IGMP with IGMP Proxy at the UGW. 684 In case of handover, the Active Multicast Subscription option 685 compatible with IGMP-based format which transports the multicast 686 membership context of the mobile node is used in handover messaging. 687 Active Multicast Subscription option has type value of 56 for IPv4 688 [RFC7161]. 690 6. IPv4 Support 692 IPv4 can be supported similarly as in vEPC 693 [I-D.matsushima-stateless-uplane-vepc]. UGW stays as IPv6 node 694 receiving from all RGs IPv6 packets and forwarding them upstream. 696 IPv4 MN is supported at the RG. RG has B4 functionality of DS-Lite 697 [RFC6333], CLAT entity for 464XLAT [RFC6877], Lightweight B4 698 [RFC7596] or MAP Customer Edge [RFC7597]. RG encapsulates IPv4 699 packets using these protocols into IPv6 packets making sure that UGW 700 stays IPv6 only. 702 7. Security Considerations 704 This document introduces no extra new security threat. Security 705 considerations stated in [I-D.ietf-i2rs-architecture] apply. 707 8. IANA Considerations 709 TBD. 711 9. Acknowledgements 713 We would like to thank Ladislav Lhotka, Satoru Matsushima for 714 valuable advice. 716 10. References 718 10.1. Normative References 720 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 721 Requirement Levels", BCP 14, RFC 2119, 722 DOI 10.17487/RFC2119, March 1997, 723 . 725 [RFC3590] Haberman, B., "Source Address Selection for the Multicast 726 Listener Discovery (MLD) Protocol", RFC 3590, 727 DOI 10.17487/RFC3590, September 2003, 728 . 730 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 731 Host Configuration Protocol (DHCP) version 6", RFC 3633, 732 DOI 10.17487/RFC3633, December 2003, 733 . 735 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 736 Levkowetz, Ed., "Extensible Authentication Protocol 737 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 738 . 740 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 741 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 742 DOI 10.17487/RFC3810, June 2004, 743 . 745 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 746 "Internet Group Management Protocol (IGMP) / Multicast 747 Listener Discovery (MLD)-Based Multicast Forwarding 748 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 749 August 2006, . 751 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 752 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 753 DOI 10.17487/RFC4861, September 2007, 754 . 756 [RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. 757 Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, 758 DOI 10.17487/RFC5949, September 2010, 759 . 761 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 762 the Network Configuration Protocol (NETCONF)", RFC 6020, 763 DOI 10.17487/RFC6020, October 2010, 764 . 766 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 767 Protocol (XMPP): Instant Messaging and Presence", 768 RFC 6121, DOI 10.17487/RFC6121, March 2011, 769 . 771 [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base 772 Deployment for Multicast Listener Support in Proxy Mobile 773 IPv6 (PMIPv6) Domains", RFC 6224, DOI 10.17487/RFC6224, 774 April 2011, . 776 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 777 and A. Bierman, Ed., "Network Configuration Protocol 778 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 779 . 781 [RFC6244] Shafer, P., "An Architecture for Network Management Using 782 NETCONF and YANG", RFC 6244, DOI 10.17487/RFC6244, June 783 2011, . 785 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 786 Stack Lite Broadband Deployments Following IPv4 787 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 788 . 790 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 791 Combination of Stateful and Stateless Translation", 792 RFC 6877, DOI 10.17487/RFC6877, April 2013, 793 . 795 [RFC7161] Contreras, LM., Bernardos, CJ., and I. Soto, "Proxy Mobile 796 IPv6 (PMIPv6) Multicast Handover Optimization by the 797 Subscription Information Acquisition through the LMA 798 (SIAL)", RFC 7161, DOI 10.17487/RFC7161, March 2014, 799 . 801 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 802 Interface Identifiers with IPv6 Stateless Address 803 Autoconfiguration (SLAAC)", RFC 7217, 804 DOI 10.17487/RFC7217, April 2014, 805 . 807 [I-D.ietf-netmod-routing-cfg] 808 Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 809 Management", draft-ietf-netmod-routing-cfg-20 (work in 810 progress), October 2015. 812 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 813 Farrer, "Lightweight 4over6: An Extension to the Dual- 814 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 815 July 2015, . 817 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 818 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 819 Port with Encapsulation (MAP-E)", RFC 7597, 820 DOI 10.17487/RFC7597, July 2015, 821 . 823 [IEEE-802.11i] 824 "Institute of Electrical and Electronics Engineers, 825 "Unapproved Draft Supplement to Standard for 826 Telecommunications and Information Exchange Between 827 Systems-LAN/MAN Specific Requirements -Part 11: Wireless 828 LAN Medium Access Control (MAC) and Physical Layer (PHY) 829 Specifications: Specification for Enhanced Security" "", 830 September 2004. 832 [IEEE-802.11-2007] 833 "Institute of Electrical and Electronics Engineers, 834 "Telecommunications and information exchange between 835 systems-Local and metropolitan area networks specific 836 requirements -Part 11: Wireless LAN Medium Access Control 837 (MAC) and Physical Layer (PHY) Specifications"", March 838 2007. 840 [ONFv1.5] "Open Networking Foundation, "OpenFlow Switch 841 Specification Version 1.5.0 ( Protocol version 0x06)"", 842 January 2015. 844 10.2. Informative references 846 [I-D.ietf-dmm-requirements] 847 Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen, 848 "Requirements for Distributed Mobility Management", draft- 849 ietf-dmm-requirements-17 (work in progress), June 2014. 851 [I-D.matsushima-stateless-uplane-vepc] 852 Matsushima, S. and R. Wakikawa, "Stateless user-plane 853 architecture for virtualized EPC (vEPC)", draft- 854 matsushima-stateless-uplane-vepc-05 (work in progress), 855 September 2015. 857 [I-D.ietf-i2rs-architecture] 858 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 859 Nadeau, "An Architecture for the Interface to the Routing 860 System", draft-ietf-i2rs-architecture-13 (work in 861 progress), February 2016. 863 [UTD-Paper] 864 Jyotirmoy Banik, et al., "IEEE 24th International 865 Conference on Computer Communication and Network 2015, 866 "Enabling Distributed Mobility Management: A Unified 867 Wireless Network Architecture Based on Virtualized Core 868 Network", DOI: 10.1109/ICCCN.2015.7288404", August 2015. 870 Appendix A. YANG and RPC Programs 872 In this annex, we present our YANG and RPC solutions. 874 A.1. Host Routing Module 876 We first obtained host routing YANG module using IPv6 unicast routing 877 module (ietf-ipv6-unicast-routing) which is part of ietf-routing 878 module. This module defines a list of host routes which contain host 879 address/prefix and corresponding next hop address. 881 A.2. Route Establishment RPCs 883 This program runs on ietf-ipv6-unicast-host-routing YANG module which 884 has been obtained from ietf-ipv6-unicast-routing module by defining 885 the hostroute as a list of host routes. First issue a get-config on 886 the configuration data to extract the existing route for the host 887 whose prefix is destination-prefix and the next-hop is the next-hop 888 address. Delete the route at pUGW. This procedure deletes the route 889 at pUGW. 891 893 get-config(running, filter=(destination-prefix, next-hop-address)) 895 // check the reply, make sure it is OK, i.e. does not contain element. 898 edit-config(running, delete, config) 900 Add a new route for MN at nUGW. This route is based on MN's prefix, 901 destination-prefix and the upstream router to which MN's traffic 902 should routed, next-hop-address. 904 906 get-config(running, filter=(destination-prefix, next-hop-address)) 908 // 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 910 exists 912 edit-config(running, create, config) 914 Add a new host route for MN at nUGW. This route is added in case 915 MN's prefix is not topologically correct at nUGW and routers above. 917 918 get-config(running, filter=(destination-prefix, next-hop-address)) 920 // check the reply, make sure it is an error, i.e. it contains element of type application and tag data-missing, i.e. no 922 route exists 924 edit-config(running, create, config) 926 We next show in Appendix A.3 and Appendix A.4 example RPC procedures 927 for get-config and edit-config. Some arbitrary values for 928 destination prefix and next hop address are used. 930 A.3. get-config RPC procedure for host routes 932 This RPC procedure shows a get-config filter to find a record in the 933 routing information base for a specific host whose prefix is 934 2001:db8:1:0::/64 and the next-hop is 2001:db8:0:1::2. It could be 935 used for the get-config's in Appendix A.2. We validated this 936 procedure using the public domain tool pyang. 938 945 946 947 948 949 950 951 rtr0 953 954 955 956 957 2001:db8:1:0::/64 958 959 eth1 960 961 2001:db8:0:1::2 962 963 964 965 966 967 968 969 971 A.4. edit-config RPC procedure to create a host route 973 This RPC procedure shows an edit-config procedure to create a new 974 host route in the routing information base for a specific host whose 975 prefix is 2001:db8:1:0::/64 and the next-hop is 2001:db8:0:1::2. It 976 could be used for the edit-config's in Appendix A.2. We validated 977 this procedure using the public domain tool pyang. 979 986 987 988 989 990 none 991 992 993 rtr0 994 995 996 997 998 2001:db8:1:0::/64 999 1000 eth1 1001 1002 2001:db8:0:1::2 1003 1004 1005 1006 1007 1008 1009 1010 1012 Authors' Addresses 1014 Behcet Sarikaya 1015 Huawei 1016 5340 Legacy Dr. Building 175 1017 Plano, TX 75024 1019 Phone: +1 469 277 5839 1020 Email: sarikaya@ieee.org 1022 Li Xue 1023 Unaffiliated 1025 Email: 276076389@qq.com