idnits 2.17.1 draft-sarikaya-dmm-for-wifi-02.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 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 (May 25, 2015) is 3258 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 685, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-architecture' is defined on line 791, 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-18 -- 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-04 == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-09 Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Sarikaya 3 Internet-Draft L. Xue 4 Intended status: Standards Track Huawei 5 Expires: November 26, 2015 May 25, 2015 7 Distributed Mobility Management Protocol for WiFi Users in Fixed Network 8 draft-sarikaya-dmm-for-wifi-02.txt 10 Abstract 12 As networks are moving towards flat architectures, a distributed 13 approach is needed to mobility management. This document defines a 14 distributed mobility management protocol called Distributed Mobility 15 Management for Wi-Fi protocol. 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 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 November 26, 2015. 39 Copyright Notice 41 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . 5 60 4.1. Layer 2 Mobility in Access Network . . . . . . . . . . . 5 61 4.2. Layer 3 Mobility and Routing in Core Network . . . . . . 6 62 4.3. Route Establishment . . . . . . . . . . . . . . . . . . . 7 63 4.4. Authentication and Charging . . . . . . . . . . . . . . . 9 64 4.4.1. Authentication . . . . . . . . . . . . . . . . . . . 9 65 4.4.2. Charging . . . . . . . . . . . . . . . . . . . . . . 12 66 5. Multicast Support . . . . . . . . . . . . . . . . . . . . . . 14 67 5.1. IPv4 Support for Multicast . . . . . . . . . . . . . . . 14 68 6. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . . 15 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 71 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 74 10.2. Informative references . . . . . . . . . . . . . . . . . 17 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 77 1. Introduction 79 Centralized mobility anchoring has several drawbacks such as single 80 point of failure, routing in a non optimal route, overloading of the 81 centralized data anchor point due to the data traffic increase, low 82 scalability of the centralized route and context management 83 [I-D.ietf-dmm-requirements]. 85 In this document, we define a routing based distributed mobility 86 management protocol. The protocol assumes a flat network 87 architecture as shown in Figure 1. No client software is assumed at 88 the mobile node. 90 IP level mobility signaling needs to be used even when MN is 91 connected to a home network or a hotspot. Distributed anchors in the 92 protocol are called Unified Gateways and they represent an evolution 93 from the Broadband Network Gateway (BNG) currently in use. 95 . 97 Cloud _.---------+----------. 98 ,' ' ---''Virtualized Control Plane---'-. 99 ( +---+ +---+ +---+ `. 100 `. |VM1| |VM2| |VM3| ) 101 +---+ +---+ +--,+ ,' 102 IP Routers | _.---------+----------. 103 with SDN Clients ,----'' | `---'-. 104 and Agents ,-' | | \ `-. 105 ,' | | ' `. 106 ( | IP Network| \ ) 107 `. | | ' ,' 108 `-. | ; ,\' 109 ;-----. ---------+------------------ 110 +-------+ +-------+ +-------+ 111 | UGW | | UGW | | UGW | 112 +-------+ +-------+ +-------+ 113 ,' | `. 114 ( Access Network ) 115 `. | ,' 116 +-----+ +-----+ +-----+ 117 | RG | | RG | | RG | 118 +-----+ +-----+ +-----+ 119 +-----+ +-----+ 120 | MN | ----move---------------> | MN | 121 +-----+ +-----+ 123 Figure 1: Architecture of Wi-Fi DMM Protocol 125 2. Terminology 127 This document uses the terminology defined in 128 [I-D.matsushima-stateless-uplane-vepc]. 130 3. Overview 132 This section presents an overview of the protocol, Distributed 133 Mobility Management for Wi-Fi protocol (DMM4WiFi). See also 134 Figure 1. 136 Access routers (AR) are Unified Gateways (UGW) that are the access 137 network gateways that behave similarly as Evolved Packet Core (EPC) 138 Edge Router (EPC-E) in [I-D.matsushima-stateless-uplane-vepc]. UGW 139 is configured an anycast address on the interface facing the 140 Residential Gateway (RG). RGs use this address to forward packets 141 from the users. The fixed access network delivers the packets to 142 geographically closest UGW. 144 Wi-Fi smart phone, the mobile node (MN) is assigned a unique prefix 145 using either Stateless Address Auto Configuration (SLAAC) or by a 146 DHCP server which could be placed in the cloud. In case of SLAAC, RG 147 is delegated the prefixes by DHCP server using [RFC3633]. 149 Prefix assignments to MNs are consistent with the prefixes assigned 150 to UGWs that are shorter than /64. These prefixes are part of the 151 operator's prefix(es) which could be /32, /24, etc. 153 The mobile node can move at home or in a hot spot from one Access 154 Point (AP) to another AP and MN mobility will be handled in Layer 2 155 using IEEE 802.11k and 802.11r. Authentication is handled in Layer 2 156 using [IEEE-802.11i] and [IEEE-802.11-2007] (as described in 157 Section 4.4). 159 When MN moves from one UGW into another UGW, IP mobility signaling 160 needs to be introduced. In this document we use Handover Initiate/ 161 Handover Acknowledge (HI/HAck) messages defined in [RFC5949]. 162 Handover Initiate message can be initiated by either previous UGW 163 (predictive handover) or the next UGW (reactive UGW). In reactive 164 handover, RG establishes a new connection with the next UGW when MN 165 moves to this RG and provides previous UGW address. This will 166 trigger the next UGW to send HI message to the previous UGW. 167 Previous UGW sends HAck messages which establishes a tunnel between 168 previous and next UGWs. Previous UGW sends packets destined to MN to 169 the new UGW which in turn sends them to MN. 171 Note that the mobility signaling just described is control plane 172 functionality. Control plane in our document is moved to the cloud, 173 thus mobility signaling happens at the cloud, possibly between two 174 virtual machines (VM). 176 Upstream packets from MN at the new UGW establish the initial routing 177 path when MN first enters the system. This path needs to be updated 178 as MN moves from one UGW to another, i.e. MN handover. Since MN 179 keeps the prefix initially assigned, after handover, the new upstream 180 path establishment may establish host routes in the upstream routers. 181 This route is refreshed as long as MN stays under the same UGW. 182 Handover signaling and subsequent upstream path establishment is very 183 critical because the downstream packets may need to follow the path 184 that is established for MN. 186 Software-Defined Networking (SDN) is used in DMM4WiFi in both Layer 2 187 and Layer 3 routing management. In case of Layer 2 routing, the Open 188 Flow Switch Protocol is used as the south bound interface between the 189 SDN Controller and Layer 2 access network switches. Extensible 190 Messaging and Presence Protocol (XMPP) is used as the north bound 191 interface between the SDN controller and DMM4WiFi application. 193 DMM4WiFi Layer 3 routing is based on SDN controllers manipulating 194 Routing Information Bases (RIB) in a subset of the upstream routers. 195 In this case south bound interface is the NETCONF protocol which is 196 based on the Remote Procedure Call (RPC) protocol and north bound 197 interface is based on IETF I2RS architecture, i.e. it is YANG based. 199 Mobile node generates interface identifier using [RFC7217] in SLAAC. 200 With this method, MN interface identifiers will be different when MN 201 moves from one UGW to another UGW. MN MAY have different IPv6 202 addresses due to this method of interface identifier generation. 204 4. Detailed Protocol Operation 206 In this section, Layer 2 and Layer 3 mobility procedures are 207 explained. 209 4.1. Layer 2 Mobility in Access Network 211 In the access network, RG MAC address acts as an identifier for the 212 MN. Access network switches are controlled by SDN. Controller to 213 Switch interface uses a protocol such as Extensible Messaging and 214 Presence Protocol (XMPP)[RFC6121]. XMPP is based on a general 215 subscribe-publish message bus. SDN controller publishes forwarding 216 instructions to the subscribing switch. Forwarding instructions 217 could be Open Flow like match-forward instructions. Open Flow 218 protocol can also be used [ONFv1.5]. 220 Access network is organized as interconnected switches. The switch 221 connected to the RG is called egress switch. The switch connected to 222 the UGW is called ingress switch. IEEE 802.1ad standard for VLAN (Q- 223 in-Q) is used in the access network, where S-VLAN denotes RG groups, 224 and C-VLAN determines traffic classes. One S-VLAN tag is assigned to 225 create one or more VLAN paths between egress and ingress switches. 227 MN mobility in the access network can be tracked by keeping a table 228 consisting of MN IP address and RG MAC address pairs. In this 229 document SDN controllers keep the mobility table. This table is used 230 to select proper S-VLAN downstream path from ingress switch to egress 231 switch and upstream path from egress switch to ingress switch. 233 After a new MN with WiFi associates with RG, RG sends an Unsolicited 234 Neighbor Advertisement (NA) message upstream. This NA message is 235 constructed as per [RFC4861] but the Source Address field is set to a 236 unicast address of MN. NA message is received by SDN controller and 237 it enables SDN controller to update the mobility table. SDN 238 controller selects proper path including S-VLAN and ingress switch to 239 forward the traffic from this MN. The controller establishes the 240 forwarding needed on these switches [UTD-Paper], i.e. Layer 2 route. 242 The packet eventually reaches the closest UGW due to the anycast 243 addressing used at the access network interfaces. UGW forwards this 244 packet to the upstream router and so on. The upstream router 245 establishes a route for MN in its routing table with MN's prefix and 246 with the UGW as the next hop. Prefixes in those routes get smaller 247 and smaller as the packet moves upstream in the routing hierarchy. 248 The routing protocol used could be BGP or other protocols like IS-IS. 250 4.2. Layer 3 Mobility and Routing in Core Network 252 MN moving from one RG to another may eventually require MN moving 253 from one UGW to another. This is Layer 3 mobility. 255 Predictive handover happens when MN just before leaving the previous 256 RG (pRG) for the next RG (nRG) MN is able to send an 802.11 message 257 containing MN MAC address and nRG MAC address, e.g. learned from 258 beacons to the pRG (called Leave Report in Figure 2. pRG then sends a 259 handover indication message to pUGW providing MN and nRG addresses 260 (called Leave Indication) and this could happen between two 261 respective virtual machines in the cloud. This message results in 262 pUGW getting nUGW information and then sending Handover Initiate 263 message to nUGW, which also could happen in the cloud. nUGW replies 264 with Handover Acknowledge message. pUGW sends any packets destined 265 to MN to nUGW after being alerted by the control plane. MN moves to 266 nRG and nUGW is informed about this from Layer 2 mobility 267 Section 4.1. uGW delivers MN's outstanding packets to MN. 269 MN P-RG N-RG (P-UGW) (N-UGW) Cloud 270 | Leave | | | | | 271 (a) |--Report-->| | | | | 272 | | | | | | 273 | | Leave | | | 274 (b) | |------indication------>| | | 275 | | | | | | 276 | | | | | | 277 (c) | | | |----HI---->| | 278 | | | | | | 279 | | | | | | 280 (d) | | | |<---HAck---| | 281 | | | |===========| | 283 Figure 2: Predictive Handover 285 Reactive handover handover happens when MN attaches the new RG from 286 the previous RG (called Join Report in Figure 3. MN is able to 287 signal in 802.11 association messages previous RG MAC address. nUGW 288 receives new association information together with pRG information, 289 possibly in the cloud (called Handover Indication). nUGW finds pUGW 290 address and sends HI message to pUGW, again happening between two 291 virtual machines in the cloud. pUGW after receiving indication from 292 the cloud server delivers any outstanding MN's packets to nUGW which 293 in turn delivers them to MN. 295 MN P-RG N-RG (P-UGW) (N-UGW) Cloud 296 | Join | | | | | 297 (a) |--Report------------->| | | | 298 | | | Handover | | 299 (b) | | |------Indication------->| | 300 | | | | | | 301 (c) | | | |<----HI----| | 302 | | | | | | 303 (d) | | | |----HAck-->| | 304 | | | | | | 305 (e) | | | |<--------->| | 306 | | | | | data | 307 (f) | | | |===========| | 309 Figure 3: Reactive Handover 311 Note that Handover Initiate and Handover Acknowledge messages used in 312 this document carry only a subset of parameters defined in [RFC5949]. 313 Also no involvement with the Local Mobility Anchor (LMA) is needed. 315 4.3. Route Establishment 317 After handover, SDN route establishment in upstream routers needs to 318 take place. In this case NETCONF protocol [RFC6241] and YANG 319 modeling [RFC6020] are used. 321 Client and Server exchange their capabilities using NETCONF message 322 layer message called hello messages. Client builds and sends an 323 operation defined in YANG module, encoded in XML, within RPC request 324 message [RFC6244]. Server verifies the contents of the request 325 against the YANG module and then performs the requested operation and 326 then sends a response, encoded in XML, in RPC reply message. 328 Defining configuration data is the primary focus of YANG. 329 Configuration data is writable (rw - read-write) data that is 330 required to transform a system from its initial default state into 331 its current state. There is also state data (ro - read-only) which 332 is a set of data that has been obtained by the system at runtime. An 333 example is routing table changes made by routing protocols in 334 response to the ongoing traffic. A YANG module for routing 335 management is given in [I-D.ietf-netmod-routing-cfg]. The core 336 routing data model consists of three YANG modules, ietf-routing, 337 ietf-ipv4-unicast-routing, ietf-ipv6-unicast-routing. The core 338 routing data model has two trees: configuration data and state data 339 trees. "routing-instance" or "rib" trees have to be populated with at 340 least one entry in the device, and additional entries may be 341 configured by a client. Normally the server creates the required 342 item as an entry in state data. Additional entries may be created in 343 the configuration by a client via the NETCONF protocol using RPC 344 messages like edit-config and copy-config. 346 The user may provide supplemental configuration of system- controlled 347 entries by creating new entries in the configuration with the desired 348 contents. In order to bind these entries with the corresponding 349 entry in the state data list, the key of the configuration entry has 350 to be set to the same value as the key of the state entry. RPC get 351 message can be used to retrieve all or part of the running 352 configuration data store merged with the device's state data. RPC 353 get-config operation retrieves configuration data only. RPC fib- 354 route message retrieves a routing instance for the active route in 355 the Forwarding Information Base (FIB) which is the route that is 356 currently used for sending datagrams to a destination host whose 357 address is passed as an input parameter. 359 NETCONF protocol and ietf-routing YANG module can be used for route 360 establishment after handover. As a result for MNs that handover, 361 upstream routing that takes place is not modified up to the lowest 362 level of routers. The lowest level of routers handle the mobility 363 but only proper modifications are needed so that the packets reach 364 the right Unified Gateway, i.e. nUGW. 366 I2RS Agent as NETCONF Client in nUGW and in pUGW inform the handover 367 to I2RS Clients as NETCONF Server upstream. I2RS Agent at pUGW 368 removes any routing information for MN by first using fib-route to 369 retrieve the active route for MN and then an edit-config message with 370 delete operation to delete the active route making sure that the same 371 key is used. 373 I2RS Agent in nUGW after the handover needs to add a new routing 374 table entry for MN. Due to the topological correctness of MN's 375 prefix, the new route could be a host route. Next this route is 376 propagated upstream. In this case, nUGW starts the process by acting 377 as I2RS Client for the I2RS Agent at the upstream router. Either a 378 new route or the host route is added with shorter prefix. Route 379 propagation continues until MN's prefix becomes topologically correct 380 at which point route propagation stops. 382 4.4. Authentication and Charging 384 4.4.1. Authentication 386 Extensible Authentication Protocol (EAP)[RFC3748] is preferred for MN 387 authentication in IEEE 802.11 (Wi-Fi) network. When a MN tries to 388 connect to the WiFi, it needs to mutually authenticate with the 389 network server first. A successful EAP authentication procedure must 390 result in a Pairwise Master Key(PMK) (defined in [IEEE-802.11i]) for 391 the traffic encryption between the MN and the AR. 393 When a MN moves at home or in a hot spot from one AP to another AP in 394 the same UGW, it is possible that it may to undergo a full EAP 395 authentication (as defined in[RFC3748]). However, there are simplied 396 several authentication methods (defined in [IEEE-802.11-2007] ): 398 o Preauthentication: When The MN supplicant may authenticate with 399 both pRG and nRG at a time. Successful completion of EAP 400 authentication between the MN and nRG establishes a pair of PMKSA 401 on both the MN and nRG. When the MN moves to the nRG, the 402 authentication has already done, which is shown as follows. 404 +---------------+ 405 | Authentication| 406 | Server | 407 +--*----*-------+ 408 Preauthentication <..........* 409 / * 410 +---------*-----+ 411 |/ *UGW | 412 *---------*-----+ 413 ,' / * | `. 414 ( / Access *Network ) 415 `. / * | ,' 416 +-----* +-*---+ +-----+ 417 | RG /| ******* RG | | RG | 418 +----/+ ***** +-----+ +-----+ 419 +-----**** +-----+ 420 | MN | ----move-----> | MN | 421 +-----+ +-----+ 423 Preauthentication 425 o Cached PMK: The RG reserves the PMK as a result of previous 426 authentication. When the MN is roaming back to the previous RG, 427 if a successful EAP authentication has happened. The MN can 428 retain the 802.11 connection based on PMK information reserved. 430 When the authentication is handled by the UGW as an Authenticator. 431 When the MN moves to the nRG, a join report packet will be 432 initiated from the MN to nRG for IEEE802.11 connection to the same 433 UGW. The nRG can retain the PMK information from the UGW which is 434 reserved during the successful authentication procedure between 435 the MN and the pRG, as shown in Figure 4. 437 +---------------+ 438 | Authentication| 439 | Server | 440 +--*------------+ 441 Authentication <....* 442 / 443 *-------------+ 444 /| UGW | PMK Cache 445 / +-------------+ / 446 ,' / | / `. 447 ( / Access Network/ ) 448 `. / | / ,' 449 +-----* +-----+ | MN | 454 +-----+ +-----+ 456 Figure 4: Cached PMK-UGW Authenticator 458 When a MN moves at home or in a hot spot from one AP to another AP in 459 the same UGW, it is possible that it may to undergo a full EAP 460 authentication (as defined in[RFC3748]). However, there are several 461 simple authentication methods (defined in [IEEE-802.11-2007] ): 463 When MN moves from one UGW into another UGW, a join report packet 464 will be initiated from the MN to nRG for IEEE802.11 connection. It 465 is possible that it may to undergo a full EAP authentication (as 466 defined in[RFC3748]). However, because of service performance and 467 continuity requirement, the operators prefer to avoid the full EAP 468 authentication. There are several simplied authentication methods 469 (defined in [IEEE-802.11-2007] ): 471 o Preauthentication: MN supplicant may authenticate with both pRG 472 and nRG at a time. Successful completion of EAP authentication 473 between the MN and nRG establishes a pair of PMKSA on both the MN 474 and nRG. When the MN moves to the nRG, the authentication has 475 already been completed, which is shown as follows. 477 +---------------+ 478 | Authentication| 479 | Server | 480 +--*----*-------+ 481 Preauthentication <..........* 482 / * 483 +-------+ / +-*-----+ +-------+ 484 | UGW | / | *UGW | | UGW | 485 +-------+ / +-*-----+ +-------+ 486 ,' / * | `. 487 ( / Access *Network ) 488 `. / * | ,' 489 +-----* +-*---+ +-----+ 490 | RG /| ******* RG | | RG | 491 +----/+ ***** +-----+ +-----+ 492 +-----**** +-----+ 493 | MN | ----move-----> | MN | 494 +-----+ +-----+ 496 o Cached PMK: The RG reserves the PMK as a result of previous 497 authentication. When the MN is roaming back to the previous RG, 498 if a successful EAP authentication has happened. The MN can 499 retain the 802.11 connection based on PMK information reserved. 500 When the authentication is handled by the UGW as an Authenticator. 501 When the MN moves to the nRG, a join report packet will be 502 initiated from the MN to nRG for IEEE802.11 connection to nUGW. 503 The nRG can retain the PMK information from the nUGW, the nUGW may 504 can retain the reserved PMK from the pUGW based on HI message. 506 +---------------+ 507 | Authentication| 508 | Server | 509 +--*------------+ 510 Authentication <..../ 511 / 512 +---------+ HI(PMK Q)+---------+ 513 PMK Cached| pUGW |<-------- | nUGW | 514 ++--------+ -------> +--------++ ^ Join Report Msg 515 ,' | / HAck(PMK) | | `. 516 ( | / | | ) 517 `. | / Access Network | | ,' 518 +----+* +-----+ ++--+-+ 519 | RG /| | RG | | RG | 520 +----/+ +-----+ +-----+ 521 +----- +-----+ 522 | MN | ----move--------------- | MN | 523 +-----+ +-----+ 525 The above Layer 2 operations do not affect Layer 3. MN does not 526 change the prefix assigned to it initially. 528 4.4.2. Charging 530 When MN moves from one UGW into another UGW, the charging needs to be 531 considered. In this document we describe two cases, one operator and 532 two interworking operators. 534 One operator case. 536 Two operators case. If the pUGW and nUGW are belonging to two 537 different operators. 539 There are two possibilities. The traffic is directed to the visited 540 network, and traffic routed back to home. 542 Charging 543 +---------------+ +---------------+ 544 |pAuthentication|<-----------|nAuthentication| 545 | Server |----------->| Server | 546 +---------------+ ++--------------+ 547 Data *********************** Charging 548 | * ^ 549 | * | 550 | * | 551 +---------+ +-+----*-++ 552 | pUGW | | nUGW* | 553 ++--------+ +------*-++ ^ Join Report Msg 554 ,' | * | | `. 555 ( | * | | ) 556 `. | Access Network * | | ,' 557 +----++ +-----+ * ++--+-+ 558 | RG | | RG | * | RG | 559 +-----+ +-----+ * +-----+ 560 +----- +*----+ 561 | MN | ----move--------------- | MN | 562 +-----+ +-----+ 564 Two operators interworking - Traffic offload in visited network 565 +---------------+ charging +---------------+ 566 |pAuthentication|----------->|nAuthentication| 567 | Server | | Server | 568 +---------------+ ^ ++--------------+ 569 | 570 Data | charging | 571 ********** | | 572 * | | 573 +-------*-+ Charging +-+-------+ 574 | pUGW* |<---------+ nUGW | 575 ++------*-+ +--------++ ^ Join Report Msg 576 ,' | ******************** | | `. 577 ( | * | | ) 578 `. | Access Network * | | ,' 579 +----++ +-----+ * ++--+-+ 580 | RG | | RG | * | RG | 581 +-----+ +-----+ * +-----+ 582 +----- +*----+ 583 | MN | ----move--------------- | MN | 584 +-----+ +-----+ 586 Two operators interworking - Traffic routed back to home 588 +---------------+ 589 | Authentication| 590 | Server | 591 +-- ------------+ ^ 592 | Charging 593 | 594 +---------+ +----+----+ 595 | pUGW | | nUGW | 596 ++--------+ +--------++ ^ Join Report Msg 597 ,' | | | `. 598 ( | | | ) 599 `. | Access Network | | ,' 600 +----++ +-----+ ++--+-+ 601 | RG | | RG | | RG | 602 +-----+ +-----+ +-----+ 603 +----- +-----+ 604 | MN | ----move--------------- | MN | 605 +-----+ +-----+ 607 Charging in one operator 609 5. Multicast Support 611 Multicast communication to the mobile nodes can be supported with an 612 Multicast Listener Discovery (MLD) Proxy at the Unified Gateway 613 [RFC4605]. Downstream protocol operations between the UGW and the 614 mobile nodes, is the MLD protocol [RFC3810]. Both any source and 615 source specific multicast are supported. 617 The mobile nodes send MLD Report message when joining a multicast 618 group [RFC3590]. UGW or MLD Proxy sends an aggregated join message 619 upstream. MN and UGW interface works as described in [RFC6224]. 620 After MN joins the group it starts to receive multicast data. 622 After a handover the mobile node moves to the next UGW, the next UGW 623 needs to get membership or listening state of this MN containing 624 group address and source list. For this purpose, Active Multicast 625 Subscription mobility option (Type 57 for IPv6) [RFC7161] can be used 626 to transfer mobile node's multicast context or subscription 627 information from the previous UGW to the next UGW, as explained 628 below. 630 In case of predictive handover, pUGW and nUGW follow the sequence of 631 steps shown in Figure 2. In case MN has multicast context 632 established before handover pUGW MUST transfer MN's multicast context 633 to nUGW. pUGW MUST add Active Multicast Subscription mobility option 634 to HI message. 636 For reactive handover pUGW and nUGW follow the sequence of steps 637 shown in Figure 3. In case MN has multicast context established 638 before handover pUGW MUST transfer MN's multicast context to nUGW. 639 pUGW MUST add Active Multicast Subscription mobility option to HAck 640 messeage. 642 After receiving the multicast context, nUGW upstream joins any new 643 multicast groups on behalf of MN. Downstream, nUGW maps downstream 644 point-to-point link to a proxy instance. 646 5.1. IPv4 Support for Multicast 648 For MNs with IPv4 addresses, multicast communication to MNs can be 649 supported similar to the way explained above in Section 5. Multicast 650 group management is done using IGMP with IGMP Proxy at the UGW. 652 In case of handover, the Active Multicast Subscription option 653 compatible with IGMP-based format which transports the multicast 654 membership context of the mobile node is used in handover messaging. 655 Active Multicast Subscription option has type value of 56 for IPv4 656 [RFC7161]. 658 6. IPv4 Support 660 IPv4 can be supported similarly as in vEPC 661 [I-D.matsushima-stateless-uplane-vepc]. UGW stays as IPv6 node 662 receiving from all RGs IPv6 packets and forwarding them upstream. 664 IPv4 MN is supported at the RG. RG has B4 functionality of DS-Lite 665 [RFC6333] or CLAT entity for 464XLAT [RFC6877]. RG encapsulates IPv4 666 packets in DS-Lite or translates IPv4 packets in 464XLAT into IPv6 667 packets making sure that UGW stays IPv6 only. 669 7. Security Considerations 671 TBD. 673 8. IANA Considerations 675 TBD. 677 9. Acknowledgements 679 TBD. 681 10. References 683 10.1. Normative References 685 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 686 Requirement Levels", BCP 14, RFC 2119, March 1997. 688 [RFC3590] Haberman, B., "Source Address Selection for the Multicast 689 Listener Discovery (MLD) Protocol", RFC 3590, September 690 2003. 692 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 693 Host Configuration Protocol (DHCP) version 6", RFC 3633, 694 December 2003. 696 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 697 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 698 3748, June 2004. 700 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 701 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 703 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 704 "Internet Group Management Protocol (IGMP) / Multicast 705 Listener Discovery (MLD)-Based Multicast Forwarding 706 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 708 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 709 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 710 September 2007. 712 [RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. 713 Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, 714 September 2010. 716 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 717 Network Configuration Protocol (NETCONF)", RFC 6020, 718 October 2010. 720 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 721 Protocol (XMPP): Instant Messaging and Presence", RFC 722 6121, March 2011. 724 [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base 725 Deployment for Multicast Listener Support in Proxy Mobile 726 IPv6 (PMIPv6) Domains", RFC 6224, April 2011. 728 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 729 Bierman, "Network Configuration Protocol (NETCONF)", RFC 730 6241, June 2011. 732 [RFC6244] Shafer, P., "An Architecture for Network Management Using 733 NETCONF and YANG", RFC 6244, June 2011. 735 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 736 Stack Lite Broadband Deployments Following IPv4 737 Exhaustion", RFC 6333, August 2011. 739 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 740 Combination of Stateful and Stateless Translation", RFC 741 6877, April 2013. 743 [RFC7161] Contreras, LM., Bernardos, CJ., and I. Soto, "Proxy Mobile 744 IPv6 (PMIPv6) Multicast Handover Optimization by the 745 Subscription Information Acquisition through the LMA 746 (SIAL)", RFC 7161, March 2014. 748 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 749 Interface Identifiers with IPv6 Stateless Address 750 Autoconfiguration (SLAAC)", RFC 7217, April 2014. 752 [I-D.ietf-netmod-routing-cfg] 753 Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 754 Management", draft-ietf-netmod-routing-cfg-18 (work in 755 progress), April 2015. 757 [IEEE-802.11i] 758 "Institute of Electrical and Electronics Engineers, 759 "Unapproved Draft Supplement to Standard for 760 Telecommunications and Information Exchange Between 761 Systems-LAN/MAN Specific Requirements -Part 11: Wireless 762 LAN Medium Access Control (MAC) and Physical Layer (PHY) 763 Specifications: Specification for Enhanced Security" "", 764 September 2004. 766 [IEEE-802.11-2007] 767 "Institute of Electrical and Electronics Engineers, 768 "Telecommunications and information exchange between 769 systems-Local and metropolitan area networks specific 770 requirements -Part 11: Wireless LAN Medium Access Control 771 (MAC) and Physical Layer (PHY) Specifications"", March 772 2007. 774 [ONFv1.5] "Open Networking Foundation, "OpenFlow Switch 775 Specification Version 1.5.0 ( Protocol version 0x06)"", 776 January 2015. 778 10.2. Informative references 780 [I-D.ietf-dmm-requirements] 781 Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen, 782 "Requirements for Distributed Mobility Management", draft- 783 ietf-dmm-requirements-17 (work in progress), June 2014. 785 [I-D.matsushima-stateless-uplane-vepc] 786 Matsushima, S. and R. Wakikawa, "Stateless user-plane 787 architecture for virtualized EPC (vEPC)", draft- 788 matsushima-stateless-uplane-vepc-04 (work in progress), 789 March 2015. 791 [I-D.ietf-i2rs-architecture] 792 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 793 Nadeau, "An Architecture for the Interface to the Routing 794 System", draft-ietf-i2rs-architecture-09 (work in 795 progress), March 2015. 797 [UTD-Paper] 798 Jyotirmoy Banik, et al., "IEEE Vehicular Technology 799 Conference Fall 2015, "A Software Defined Semi Distributed 800 Mobility Management System Based on Layer 2 Backhaul 801 Network"", September 2015. 803 Authors' Addresses 805 Behcet Sarikaya 806 Huawei 807 5340 Legacy Dr. Building 175 808 Plano, TX 75024 810 Phone: +1 469 277 5839 811 Email: sarikaya@ieee.org 813 Li Xue 814 Huawei 815 NO.156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan, 816 Beijing, HaiDian District 100095 817 China 819 Email: xueli@huawei.com