[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05

Network Working Group                                        B. Sarikaya
Internet-Draft
Intended status: Standards Track                                  L. Xue
Expires: May 3, 2018                                    October 30, 2017


Distributed Mobility Management Protocol for WiFi Users in Fixed Network
                   draft-sarikaya-dmm-for-wifi-05.txt

Abstract

   As networks are moving towards flat architectures, a distributed
   approach is needed to mobility management.  This document presents a
   use case distributed mobility management protocol called Distributed
   Mobility Management for Wi-Fi.  The protocol is based on mobility
   aware virtualized routing system with software-defined network
   support.  Routing is in Layer 2 in the access network and in Layer 3
   in the core network.  Smart phones access the network over IEEE
   802.11 (Wi-Fi) interface and can move in home, hotspot and enterprise
   buildings.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 3, 2018.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Sarikaya & Xue             Expires May 3, 2018                  [Page 1]


Internet-Draft            DMM for Wifi Use Case             October 2017


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   3
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Detailed Protocol Operation . . . . . . . . . . . . . . . . .   5
     4.1.  Layer 2 Mobility in Access Network  . . . . . . . . . . .   6
     4.2.  Layer 3 Mobility and Routing in Core Network  . . . . . .   6
     4.3.  Route Establishment . . . . . . . . . . . . . . . . . . .   8
     4.4.  Authentication  . . . . . . . . . . . . . . . . . . . . .  10
   5.  Multicast Support . . . . . . . . . . . . . . . . . . . . . .  14
     5.1.  IPv4 Support  . . . . . . . . . . . . . . . . . . . . . .  14
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  18
   Appendix A.  YANG and RPC Programs  . . . . . . . . . . . . . . .  19
     A.1.  Host Routing Module . . . . . . . . . . . . . . . . . . .  19
     A.2.  Route Establishment RPCs  . . . . . . . . . . . . . . . .  19
     A.3.  get-config RPC procedure for host routes  . . . . . . . .  20
     A.4.  edit-config RPC procedure to create a host route  . . . .  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

1.  Introduction

   Centralized mobility anchoring has several drawbacks such as single
   point of failure, routing in a non optimal route, overloading of the
   centralized data anchor point due to the data traffic increase, low
   scalability of the centralized route and context management
   [RFC7333].

   In this document, we define a routing based distributed mobility
   management protocol.  The protocol assumes a flat network
   architecture as shown in Figure 1.  No client software is assumed at
   the mobile node.

   IP level mobility signaling needs to be used even when MN is
   connected to a home network or a hotspot.  Distributed anchors in the
   protocol are called Unified Gateways and they represent an evolution
   from the Broadband Network Gateway (BNG) currently in use.




Sarikaya & Xue             Expires May 3, 2018                  [Page 2]


Internet-Draft            DMM for Wifi Use Case             October 2017


2.  Conventions and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   This document uses the terminology defined in
   [I-D.ietf-dmm-deployment-models] and
   [I-D.matsushima-stateless-uplane-vepc].

3.  Overview

   This section presents an overview of the protocol, Distributed
   Mobility Management for Wi-Fi protocol (DMM4WiFi).  See also
   Figure 1.

   Access routers (AR) are Unified Gateways (UGW) that are the access
   network gateways that behave similarly as Evolved Packet Core (EPC)
   Edge Router (EPC-E) in [I-D.matsushima-stateless-uplane-vepc].  UGW
   is configured an anycast address on the interface facing the
   Residential Gateway (RG).  RGs use this address to forward packets
   from the users.  The fixed access network delivers the packets to
   geographically closest UGW.  UGW plays the role of Access Data Plane
   Node (A-DPN) defined in [I-D.ietf-dmm-deployment-models].  A-DPN and
   UGW are interchangeably used in this document.


























Sarikaya & Xue             Expires May 3, 2018                  [Page 3]


Internet-Draft            DMM for Wifi Use Case             October 2017


       Cloud                       _.---------+----------.
                         ,' ' ---''Virtualized Control Plane---'-.
                        (    +---+          +---+         +---+   `.
                         `.  |VM1|          |VM2|         |VM3|      )
                             +---+          +---+         +--,+    ,'
       IP Routers              |     _.---------+----------.
       with SDN Clients       ,----''           |           `---'-.
       and Agents         ,-'  |               |                \ `-.
                       ,'      |              |                '   `.
                      (        |    IP Network|                 \     )
                       `.     |               |                  '  ,'
                         `-. |                 ;                  ,\'
                            ;-----. ---------+------------------
                       +-------+         +-------+      +-------+
                       | A-DPN |         | A-DPN |      | A-DPN |
                       +-------+         +-------+      +-------+
                      ,'                     |                    `.
                     (             Access Network                    )
                      `.                     |                    ,'
                       +-----+           +-----+        +-----+
                       | RG  |           | RG  |        | RG  |
                       +-----+           +-----+        +-----+
                     +-----+                          +-----+
                     | MN  | ----move---------------> | MN  |
                     +-----+                          +-----+

            Figure 1: SDN Based Architecture of Wi-Fi Protocol

   Wi-Fi smart phone, the mobile node (MN) is assigned a unique prefix
   using either Stateless Address Auto Configuration (SLAAC) or by a
   DHCP server which could be placed in the cloud.  In case of SLAAC, RG
   is delegated the prefixes by DHCP server using [RFC3633].

   Prefix assignments to MNs are consistent with the prefixes assigned
   to UGWs that are shorter than /64.  These prefixes are part of the
   operator's prefix(es) which could be /32, /24, etc.

   The mobile node can move at home or in a hot spot from one Access
   Point (AP) to another AP and MN mobility will be handled in Layer 2
   using IEEE 802.11k and 802.11r.  Authentication is handled in Layer 2
   using [IEEE-802.11i] and [IEEE-802.11-2007] (as described in
   Section 4.4).

   When MN moves from one A-DPN into another A-DPN, IP mobility
   signaling needs to be introduced.  In this document we use Handover
   Initiate/ Handover Acknowledge (HI/HAck) messages defined in
   [RFC5949].  Handover Initiate message can be initiated by either
   previous UGW (predictive handover) or the next UGW (reactive UGW).



Sarikaya & Xue             Expires May 3, 2018                  [Page 4]


Internet-Draft            DMM for Wifi Use Case             October 2017


   In reactive handover, RG establishes a new connection with the next
   UGW when MN moves to this RG and provides previous UGW address.  This
   will trigger the next UGW to send HI message to the previous UGW.
   Previous UGW sends HAck messages which establishes a tunnel between
   previous and next UGWs.  Previous UGW sends packets destined to MN to
   the new UGW which in turn sends them to MN.

   Note that the mobility signaling just described is control plane
   functionality, i.e. between Access-Control Plane Nodes (A-CPN).
   Control plane in our document is moved to the cloud, thus mobility
   signaling happens at the cloud, possibly between two virtual machines
   (VM), A-CPNs.

   Upstream packets from MN at the new A-DPN establish the initial
   routing path when MN first enters the system.  This path needs to be
   updated as MN moves from one A-DPN to another, i.e. MN handover.
   Since MN keeps the prefix initially assigned, after handover, the new
   upstream path establishment may establish host routes in the upstream
   routers.  This route is refreshed as long as MN stays under the same
   A-DPN.  Handover signaling and subsequent upstream path establishment
   is very critical because the downstream packets may need to follow
   the path that is established for MN.

   Software-Defined Networking (SDN) is used in DMM4WiFi in both Layer 2
   and Layer 3 routing management.  In case of Layer 2 routing, the Open
   Flow Switch Protocol is used as the south bound interface between the
   SDN Controller and Layer 2 access network switches.  Extensible
   Messaging and Presence Protocol (XMPP) is used as the north bound
   interface between the SDN controller and DMM4WiFi application.
   DMM4WiFi Layer 3 routing is based on SDN controllers manipulating
   Routing Information Bases (RIB) in a subset of the upstream routers.
   In this case south bound interface is the NETCONF protocol which is
   based on the Remote Procedure Call (RPC) protocol and YANG.  I2RS
   architecture is used in this context.

   Mobile node generates interface identifier using [RFC7217] in SLAAC.
   With this method, MN interface identifiers will be different when MN
   moves from one A-DPN to another A-DPN.  MN MAY have different IPv6
   addresses due to this method of interface identifier generation.

4.  Detailed Protocol Operation

   In this section, Layer 2 and Layer 3 mobility procedures are
   explained.







Sarikaya & Xue             Expires May 3, 2018                  [Page 5]


Internet-Draft            DMM for Wifi Use Case             October 2017


4.1.  Layer 2 Mobility in Access Network

   In the access network, RG MAC address acts as an identifier for the
   MN.  Access network switches are controlled by SDN.  Controller to
   Switch interface uses a protocol such as Extensible Messaging and
   Presence Protocol (XMPP) [RFC6121].  XMPP is based on a general
   subscribe-publish message bus.  SDN controller publishes forwarding
   instructions to the subscribing switch.  Forwarding instructions
   could be Open Flow like match-forward instructions.  Open Flow
   protocol can also be used [ONFv1.5].

   Access network is organized as interconnected switches.  The switch
   connected to the RG is called egress switch.  The switch connected to
   the UGW is called ingress switch.  IEEE 802.1ad standard for VLAN (Q-
   in-Q) is used in the access network, where S-VLAN denotes RG groups,
   and C-VLAN determines traffic classes.  One S-VLAN tag is assigned to
   create one or more VLAN paths between egress and ingress switches.

   MN mobility in the access network can be tracked by keeping a table
   consisting of MN IP address and RG MAC address pairs.  In this
   document SDN controllers keep the mobility table.  This table is used
   to select proper S-VLAN downstream path from ingress switch to egress
   switch and upstream path from egress switch to ingress switch.

   After a new MN with WiFi associates with RG, RG sends an Unsolicited
   Neighbor Advertisement (NA) message upstream.  This NA message is
   constructed as per [RFC4861] but the Source Address field is set to a
   unicast address of MN.  NA message is received by SDN controller and
   it enables SDN controller to update the mobility table.  SDN
   controller selects proper path including S-VLAN and ingress switch to
   forward the traffic from this MN.  The controller establishes the
   forwarding needed on these switches [IEEE-Paper], i.e. Layer 2 route.

   The packet eventually reaches the closest UGW due to the anycast
   addressing used at the access network interfaces.  UGW forwards this
   packet to the upstream router and so on.  The upstream router
   establishes a route for MN in its routing table with MN's prefix and
   with the UGW as the next hop.  Prefixes in those routes get smaller
   and smaller as the packet moves upstream in the routing hierarchy.
   The routing protocol used could be BGP or other protocols like IS-IS.

4.2.  Layer 3 Mobility and Routing in Core Network

   MN moving from one RG to another may eventually require MN moving
   from one A-DPN to another.  This is Layer 3 mobility.

   Predictive handover happens when MN just before leaving the previous
   RG (pRG) for the next RG (nRG) MN is able to send an 802.11 message



Sarikaya & Xue             Expires May 3, 2018                  [Page 6]


Internet-Draft            DMM for Wifi Use Case             October 2017


   containing MN MAC address and nRG MAC address, e.g. learned from
   beacons to the pRG (called Leave Report in Figure 2. pRG then sends a
   handover indication message to pUGW providing MN and nRG addresses
   (called Leave Indication) and this could happen between two
   respective virtual machines in the cloud.  This message results in
   pUGW getting nUGW information and then sending Handover Initiate
   message to nUGW, which also could happen in the cloud. nUGW replies
   with Handover Acknowledge message.  pUGW sends any packets destined
   to MN to nUGW after being alerted by the control plane.  MN moves to
   nRG and nUGW is informed about this from Layer 2 mobility
   Section 4.1. uGW delivers MN's outstanding packets to MN.

            MN         P-RG       N-RG        (P-UGW)     (N-UGW)   Cloud
            |   Leave   |          |            |           |        |
       (a)  |--Report-->|          |            |           |        |
            |           |          |            |           |        |
            |           |       Leave           |           |        |
       (b)  |           |------indication------>|           |        |
            |           |          |            |           |        |
            |           |          |            |           |        |
       (c)  |           |          |            |----HI---->|        |
            |           |          |            |           |        |
            |           |          |            |           |        |
       (d)  |           |          |            |<---HAck---|        |
            |           |          |            |===========|        |

                       Figure 2: Predictive Handover

   Reactive handover handover happens when MN attaches the new RG from
   the previous RG, called Join Report in Figure 3.  MN is able to
   signal in 802.11 association messages previous RG MAC address.  nUGW
   or A-CPN receives new association information together with pRG
   information, possibly in the cloud (called Handover Indication). nUGW
   finds pUGW address and sends HI message to pUGW, again happening
   between two virtual machines in the cloud. pUGW after receiving
   indication from the cloud server delivers any outstanding MN's
   packets to nUGW which in turn delivers them to MN.














Sarikaya & Xue             Expires May 3, 2018                  [Page 7]


Internet-Draft            DMM for Wifi Use Case             October 2017


           MN         P-RG       N-RG        (P-UGW)     (N-UGW)   Cloud
            |   Join    |          |            |           |        |
       (a)  |--Report------------->|            |           |        |
            |           |          |       Handover         |        |
       (b)  |           |          |------Indication------->|        |
            |           |          |            |           |        |
       (c)  |           |          |            |<----HI----|        |
            |           |          |            |           |        |
       (d)  |           |          |            |----HAck-->|        |
            |           |          |            |           |        |
       (e)  |           |          |            |<--------->|        |
            |           |          |            |           |   data |
       (f)  |           |          |            |===========|        |


                        Figure 3: Reactive Handover

   Note that Handover Initiate and Handover Acknowledge messages used in
   this document carry only a subset of parameters defined in [RFC5949].
   Also no involvement with the Local Mobility Anchor (LMA) [RFC5213] is
   needed.

4.3.  Route Establishment

   After handover, SDN route establishment in upstream routers needs to
   take place.  In this case NETCONF protocol [RFC6241] and YANG
   modeling [RFC6020]  are used.

   Client and Server exchange their capabilities using NETCONF message
   layer message called hello messages.  Client builds and sends an
   operation defined in YANG module, encoded in XML, within RPC request
   message [RFC6244].  Server verifies the contents of the request
   against the YANG module and then performs the requested operation and
   then sends a response, encoded in XML, in RPC reply message.

   Defining configuration data is the primary focus of YANG.
   Configuration data is writable (rw - read-write) data that is
   required to transform a system from its initial default state into
   its current state.  There is also state data (ro - read-only) which
   is a set of data that has been obtained by the system at runtime.  An
   example is routing table changes made by routing protocols in
   response to the ongoing traffic.

   A YANG module for routing management is given in [I-D.ietf-netmod-
   routing-cfg].  The core routing data model consists of three YANG
   modules, ietf-routing, ietf-ipv4-unicast-routing, ietf- ipv6-unicast-
   routing.  The core routing data model has two trees: configuration
   data and state data trees. "routing-instance" or "rib" trees have to



Sarikaya & Xue             Expires May 3, 2018                  [Page 8]


Internet-Draft            DMM for Wifi Use Case             October 2017


   be populated with at least one entry in the device, and additional
   entries may be configured by a client.  Normally the server creates
   the required item as an entry in state data.  Additional entries may
   be created in the configuration by a client via the NETCONF protocol
   using RPC messages like edit-config and copy-config.

   The user may provide supplemental configuration of system- controlled
   entries by creating new entries in the configuration with the desired
   contents.  In order to bind these entries with the corresponding
   entry in the state data list, the key of the configuration entry has
   to be set to the same value as the key of the state entry.

   RPC get message can be used to retrieve all or part of the running
   configuration data store merged with the device's state data.  RPC
   get-config operation retrieves configuration data only.  RPC fib-
   route message defined in [RFC8022] retrieves a routing instance for
   the active route in the Forwarding Information Base (FIB) which is
   the route that is currently used for sending datagrams to a
   destination host whose address is passed as an input parameter.  So
   fib-route message plays the role of show route command line interface
   command.

   NETCONF protocol and ietf-routing YANG module can be used for route
   establishment after handover.  As a result for MNs that handover,
   upstream routing that takes place is not modified up to the lowest
   level of routers.  The lowest level of routers handle the mobility
   but only proper modifications are needed so that the packets reach
   the right Unified Gateway, i.e. nUGW.

   I2RS Agent as NETCONF Server in nUGW and in pUGW inform the handover
   to I2RS Clients as NETCONF Client upstream.  I2RS Agent at pUGW
   removes any routing information for MN by first using get-config to
   retrieve the active route for MN and then an edit-config message with
   delete operation to delete the active route making sure that the same
   key is used.

   I2RS Agent in nUGW after the handover needs to add a new routing
   table entry for MN.  Due to the topological correctness of MN's
   prefix, the new route could be a host route.  Next this route is
   propagated upstream.  In this case, nUGW starts the process.  SDN
   Controller as I2RS Client knows that MN handover is successfully
   completed.  SDN Controller starts the upstream route establishment
   process starting with the I2RS Agent at the upstream router.  Either
   a new route or the host route is added with shorter prefix.  Route
   propagation continues until MN's prefix becomes topologically correct
   at which point route propagation stops.





Sarikaya & Xue             Expires May 3, 2018                  [Page 9]


Internet-Draft            DMM for Wifi Use Case             October 2017


   Route propagation at the lowest level starts with I2RS Agent as
   NETCONF Server in nUGW informing the handover to I2RS Client as
   NETCONF Client upstream.  I2RS Client then checks any routing
   information for MN by first using get-config to retrieve the active
   route for MN to make sure that none exits and MN prefix is
   topologically incorrect.  Next I2RS client issues an edit-config
   message with create operation to add a host route for the new MN.
   I2RS Client then informs this route to I2RS Client upstream which
   creates a similar route at the I2RS Agent upstream.

   In Appendix A, we present our experimental work using YANG data
   modelling language which has its own syntax and NETCONF protocol
   which is XML-based remote procedure call (RPC) mechanism.  HTTP based
   RESTCONF could also be used in a similar way.  Two RPC call examples
   are given.  RPC call in Appendix A.3 shows a get-config filter with
   rtr0 as the key and it is used to retrieve a specific route with a
   given destination prefix and next hop address.  RPC call in
   Appendix A.4 shows an example edit-config create operation to create
   a new route with specific route parameters.

4.4.  Authentication

   Extensible Authentication Protocol (EAP)[RFC3748] is preferred for MN
   authentication in IEEE 802.11 (Wi-Fi) network.  When a MN tries to
   connect to the WiFi, it needs to mutually authenticate with the
   network server first.  A successful EAP authentication procedure must
   result in a Pairwise Master Key(PMK) (defined in [IEEE-802.11i]) for
   the traffic encryption between the MN and the AR.

   When a MN moves at home or in a hot spot from one AP to another AP in
   the same UGW, it is possible that it may to undergo a full EAP
   authentication (as defined in[RFC3748]).  However, there are several
   simplified authentication methods (defined in [IEEE-802.11-2007] ):

   o Preauthentication: When The MN supplicant may authenticate with
   both pRG and nRG at a time.  Successful completion of EAP
   authentication between the MN and nRG establishes a pair of PMKSA on
   both the MN and nRG.  When the MN moves to the nRG, the
   authentication has already done, which is shown as follows.












Sarikaya & Xue             Expires May 3, 2018                 [Page 10]


Internet-Draft            DMM for Wifi Use Case             October 2017


                             +---------------+
                             | Authentication|
                             |    Server     |
                             +--*----*-------+
        Preauthentication <..........*
                              /      *
                           +---------*-----+
                           |/        *UGW  |
                           *---------*-----+
                ,'        /          * |                    `.
               (         /   Access  *Network                  )
                `.      /            * |                    ,'
                 +-----*           +-*---+        +-----+
                 | RG /|     ******* RG  |        | RG  |
                 +----/+ *****     +-----+        +-----+
               +-----****             +-----+
               | MN  | ----move-----> | MN  |
               +-----+                +-----+

   o Cached PMK: The RG reserves the PMK as a result of previous
   authentication.  When the MN is roaming back to the previous RG, if a
   successful EAP authentication has happened.  The MN can retain the
   802.11 connection based on PMK information reserved.  When the
   authentication is handled by the UGW as an Authenticator.  When the
   MN moves to the nRG, a join report packet will be initiated from the
   MN to nRG for IEEE802.11 connection to the same UGW.  The nRG can
   retain the PMK information from the UGW which is reserved during the
   successful authentication procedure between the MN and the pRG, as
   shown in Figure 4.






















Sarikaya & Xue             Expires May 3, 2018                 [Page 11]


Internet-Draft            DMM for Wifi Use Case             October 2017


                           +---------------+
                           | Authentication|
                           |    Server     |
                           +--*------------+
         Authentication <....*
                            /
                           *-------------+
                          /|    UGW      | PMK Cache
                         / +-------------+   /
              ,'        /            |      /             `.
             (         /   Access   Network/                 )
              `.      /              |    /               ,'
               +-----*           +-----+</      +-----+
               | RG /|           | RG  |        | RG  |
               +----/+           +-----+        +-----+
             +-----                 +-----+
             | MN  | ----move-----> | MN  |
             +-----+                +-----+

                  Figure 4: Cached PMK-UGW Authenticator

   When a MN moves at home or in a hot spot from one AP to another AP in
   the same UGW, it is possible that it may to undergo a full EAP
   authentication (as defined in[RFC3748]).  However, there are several
   simple authentication methods (defined in [IEEE-802.11-2007] ):

   When MN moves from one UGW into another UGW, a join report packet
   will be initiated from the MN to nRG for IEEE802.11 connection.  It
   is possible that it may to undergo a full EAP authentication (as
   defined in[RFC3748]).  However, because of service performance and
   continuity requirement, the operators prefer to avoid the full EAP
   authentication.  There are several simplied authentication methods
   (defined in [IEEE-802.11-2007] ):

   o Preauthentication: MN supplicant may authenticate with both pRG and
   nRG at a time.  Successful completion of EAP authentication between
   the MN and nRG establishes a pair of PMKSA on both the MN and nRG.
   When the MN moves to the nRG, the authentication has already been
   completed, which is shown as follows.












Sarikaya & Xue             Expires May 3, 2018                 [Page 12]


Internet-Draft            DMM for Wifi Use Case             October 2017


                              +---------------+
                              | Authentication|
                              |    Server     |
                              +--*----*-------+
         Preauthentication <..........*
                               /      *
                  +-------+   /     +-*-----+      +-------+
                  |  UGW  |  /      | *UGW  |      |  UGW  |
                  +-------+ /       +-*-----+      +-------+
                 ,'        /          * |                    `.
                (         /   Access  *Network                  )
                 `.      /            * |                    ,'
                  +-----*           +-*---+        +-----+
                  | RG /|     ******* RG  |        | RG  |
                  +----/+ *****     +-----+        +-----+
                +-----****             +-----+
                | MN  | ----move-----> | MN  |
                +-----+                +-----+


   o Cached PMK: The RG reserves the PMK as a result of previous
   authentication.  When the MN is roaming back to the previous RG, if a
   successful EAP authentication has happened.  The MN can retain the
   802.11 connection based on PMK information reserved.  When the
   authentication is handled by the UGW as an Authenticator.  When the
   MN moves to the nRG, a join report packet will be initiated from the
   MN to nRG for IEEE802.11 connection to nUGW.  The nRG can retain the
   PMK information from the nUGW, the nUGW may can retain the reserved
   PMK from the pUGW based on HI message.

                           +---------------+
                           | Authentication|
                           |    Server     |
                           +--*------------+
         Authentication <..../
                            /
                   +---------+ HI(PMK Q)+---------+
         PMK Cached|   pUGW  |<-------- |  nUGW   |
                   ++--------+ -------> +--------++ ^  Join Report Msg
              ,'    |   /      HAck(PMK)         |  |     `.
             (      |  /                         |  |        )
              `.    | /    Access   Network      |  |     ,'
               +----+*           +-----+        ++--+-+
               | RG /|           | RG  |        | RG  |
               +----/+           +-----+        +-----+
             +-----                          +-----+
             | MN  | ----move--------------- | MN  |
             +-----+                         +-----+



Sarikaya & Xue             Expires May 3, 2018                 [Page 13]


Internet-Draft            DMM for Wifi Use Case             October 2017


   The above Layer 2 operations do not affect Layer 3.  MN does not
   change the prefix assigned to it initially.

   Note that charging solution is not described in this version.

5.  Multicast Support

   Multicast communication to the mobile nodes can be supported with an
   Multicast Listener Discovery (MLD) Proxy at the Unified Gateway
   [RFC4605].  Downstream protocol operations between the UGW and the
   mobile nodes, is the MLD protocol [RFC3810].  Both any source and
   source specific multicast are supported.

   The mobile nodes send MLD Report message when joining a multicast
   group [RFC3590].  UGW or MLD Proxy sends an aggregated join message
   upstream.  MN and UGW interface works as described in [RFC6224].
   After MN joins the group it starts to receive multicast data.

   After a handover the mobile node moves to the next UGW, the next UGW
   needs to get membership or listening state of this MN containing
   group address and source list.  For this purpose, Active Multicast
   Subscription mobility option (Type 57 for IPv6) [RFC7161] can be used
   to transfer mobile node's multicast context or subscription
   information from the previous UGW to the next UGW, as explained
   below.

   In case of predictive handover, pUGW and nUGW follow the sequence of
   steps shown in Figure 2.  In case MN has multicast context
   established before handover pUGW MUST transfer MN's multicast context
   to nUGW. pUGW MUST add Active Multicast Subscription mobility option
   to HI message.

   For reactive handover pUGW and nUGW follow the sequence of steps
   shown in Figure 3.  In case MN has multicast context established
   before handover pUGW MUST transfer MN's multicast context to nUGW.
   pUGW MUST add Active Multicast Subscription mobility option to HAck
   messeage.

   After receiving the multicast context, nUGW upstream joins any new
   multicast groups on behalf of MN.  Downstream, nUGW maps downstream
   point-to-point link to a proxy instance.

5.1.  IPv4 Support

   IPv4 can be supported similarly as in vEPC
   [I-D.matsushima-stateless-uplane-vepc].  UGW stays as IPv6 node
   receiving from all RGs IPv6 packets and forwarding them upstream.




Sarikaya & Xue             Expires May 3, 2018                 [Page 14]


Internet-Draft            DMM for Wifi Use Case             October 2017


   IPv4 MN is supported at the RG.  RG has B4 functionality of DS-Lite
   [RFC6333], CLAT entity for 464XLAT [RFC6877], Lightweight B4
   [RFC7596] or MAP Customer Edge [RFC7597].  RG encapsulates IPv4
   packets using these protocols into IPv6 packets making sure that UGW
   stays IPv6 only.

6.  IANA Considerations

   TBD.

7.  Security Considerations

   This document introduces no extra new security threat.  Security
   considerations stated in [RFC7921] and
   [I-D.ietf-dmm-deployment-models] apply.

8.  Acknowledgements

   We would like to thank Ladislav Lhotka, Satoru Matsushima for
   valuable advice.

9.  References

9.1.  Normative References

   [I-D.ietf-dmm-deployment-models]
              Gundavelli, S. and S. Jeon, "DMM Deployment Models and
              Architectural Considerations", draft-ietf-dmm-deployment-
              models-02 (work in progress), August 2017.

   [IEEE-802.11-2007]
              IEEE, "Institute of Electrical and Electronics Engineers,
              "Telecommunications and information exchange between
              systems-Local and metropolitan area networks specific
              requirements -Part 11: Wireless LAN Medium Access Control
              (MAC) and Physical Layer (PHY) Specifications", March
              2007.

   [IEEE-802.11i]
              IEEE, "Institute of Electrical and Electronics Engineers,
              "Unapproved Draft Supplement to Standard for
              Telecommunications and Information Exchange Between
              Systems-LAN/MAN Specific Requirements -Part 11: Wireless
              LAN Medium Access Control (MAC) and Physical Layer (PHY)
              Specifications: Specification for Enhanced Security,",
              September 2004.





Sarikaya & Xue             Expires May 3, 2018                 [Page 15]


Internet-Draft            DMM for Wifi Use Case             October 2017


   [ONFv1.5]  ONF, "Open Networking Foundation, "OpenFlow Switch
              Specification Version 1.5.0 ( Protocol version 0x06)",
              January 2015.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3590]  Haberman, B., "Source Address Selection for the Multicast
              Listener Discovery (MLD) Protocol", RFC 3590,
              DOI 10.17487/RFC3590, September 2003,
              <https://www.rfc-editor.org/info/rfc3590>.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              DOI 10.17487/RFC3633, December 2003,
              <https://www.rfc-editor.org/info/rfc3633>.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, Ed., "Extensible Authentication Protocol
              (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
              <https://www.rfc-editor.org/info/rfc3748>.

   [RFC3810]  Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
              Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
              DOI 10.17487/RFC3810, June 2004,
              <https://www.rfc-editor.org/info/rfc3810>.

   [RFC4605]  Fenner, B., He, H., Haberman, B., and H. Sandick,
              "Internet Group Management Protocol (IGMP) / Multicast
              Listener Discovery (MLD)-Based Multicast Forwarding
              ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605,
              August 2006, <https://www.rfc-editor.org/info/rfc4605>.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              DOI 10.17487/RFC4861, September 2007,
              <https://www.rfc-editor.org/info/rfc4861>.

   [RFC5213]  Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
              Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
              RFC 5213, DOI 10.17487/RFC5213, August 2008,
              <https://www.rfc-editor.org/info/rfc5213>.







Sarikaya & Xue             Expires May 3, 2018                 [Page 16]


Internet-Draft            DMM for Wifi Use Case             October 2017


   [RFC5949]  Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F.
              Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949,
              DOI 10.17487/RFC5949, September 2010,
              <https://www.rfc-editor.org/info/rfc5949>.

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              <https://www.rfc-editor.org/info/rfc6020>.

   [RFC6121]  Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Instant Messaging and Presence",
              RFC 6121, DOI 10.17487/RFC6121, March 2011,
              <https://www.rfc-editor.org/info/rfc6121>.

   [RFC6224]  Schmidt, T., Waehlisch, M., and S. Krishnan, "Base
              Deployment for Multicast Listener Support in Proxy Mobile
              IPv6 (PMIPv6) Domains", RFC 6224, DOI 10.17487/RFC6224,
              April 2011, <https://www.rfc-editor.org/info/rfc6224>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC6244]  Shafer, P., "An Architecture for Network Management Using
              NETCONF and YANG", RFC 6244, DOI 10.17487/RFC6244, June
              2011, <https://www.rfc-editor.org/info/rfc6244>.

   [RFC6333]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
              Stack Lite Broadband Deployments Following IPv4
              Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,
              <https://www.rfc-editor.org/info/rfc6333>.

   [RFC6877]  Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
              Combination of Stateful and Stateless Translation",
              RFC 6877, DOI 10.17487/RFC6877, April 2013,
              <https://www.rfc-editor.org/info/rfc6877>.

   [RFC7161]  Contreras, LM., Bernardos, CJ., and I. Soto, "Proxy Mobile
              IPv6 (PMIPv6) Multicast Handover Optimization by the
              Subscription Information Acquisition through the LMA
              (SIAL)", RFC 7161, DOI 10.17487/RFC7161, March 2014,
              <https://www.rfc-editor.org/info/rfc7161>.







Sarikaya & Xue             Expires May 3, 2018                 [Page 17]


Internet-Draft            DMM for Wifi Use Case             October 2017


   [RFC7217]  Gont, F., "A Method for Generating Semantically Opaque
              Interface Identifiers with IPv6 Stateless Address
              Autoconfiguration (SLAAC)", RFC 7217,
              DOI 10.17487/RFC7217, April 2014,
              <https://www.rfc-editor.org/info/rfc7217>.

   [RFC7596]  Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
              Farrer, "Lightweight 4over6: An Extension to the Dual-
              Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596,
              July 2015, <https://www.rfc-editor.org/info/rfc7596>.

   [RFC7597]  Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
              Murakami, T., and T. Taylor, Ed., "Mapping of Address and
              Port with Encapsulation (MAP-E)", RFC 7597,
              DOI 10.17487/RFC7597, July 2015,
              <https://www.rfc-editor.org/info/rfc7597>.

   [RFC8022]  Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
              Management", RFC 8022, DOI 10.17487/RFC8022, November
              2016, <https://www.rfc-editor.org/info/rfc8022>.

9.2.  Informative References

   [I-D.matsushima-stateless-uplane-vepc]
              Matsushima, S. and R. Wakikawa, "Stateless user-plane
              architecture for virtualized EPC (vEPC)", draft-
              matsushima-stateless-uplane-vepc-06 (work in progress),
              March 2016.

   [IEEE-Paper]
              "Jyotirmoy Banik, et al., "IEEE 24th International
              Conference on Computer Communication and Network 2015,
              "Enabling Distributed Mobility Management: A Unified
              Wireless Network Architecture Based on Virtualized Core
              Network", DOI: 10.1109/ICCCN.2015.7288404",", August 2015.

   [RFC7333]  Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J.
              Korhonen, "Requirements for Distributed Mobility
              Management", RFC 7333, DOI 10.17487/RFC7333, August 2014,
              <https://www.rfc-editor.org/info/rfc7333>.

   [RFC7921]  Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
              Nadeau, "An Architecture for the Interface to the Routing
              System", RFC 7921, DOI 10.17487/RFC7921, June 2016,
              <https://www.rfc-editor.org/info/rfc7921>.






Sarikaya & Xue             Expires May 3, 2018                 [Page 18]


Internet-Draft            DMM for Wifi Use Case             October 2017


Appendix A.  YANG and RPC Programs

   In this annex, we present our YANG and RPC solutions.

A.1.  Host Routing Module

   We first obtained host routing YANG module using IPv6 unicast routing
   module (ietf-ipv6-unicast-routing) which is part of ietf-routing
   module.  This module defines a list of host routes which contain host
   address/prefix and corresponding next hop address.

A.2.  Route Establishment RPCs

   This program runs on ietf-ipv6-unicast-host-routing YANG module which
   has been obtained from ietf-ipv6-unicast-routing module by defining
   the hostroute as a list of host routes.  First issue a get-config on
   the configuration data to extract the existing route for the host
   whose prefix is destination-prefix and the next-hop is the next-hop
   address.  Delete the route at pUGW.  This procedure deletes the route
   at pUGW.































Sarikaya & Xue             Expires May 3, 2018                 [Page 19]


Internet-Draft            DMM for Wifi Use Case             October 2017


   <rpc message-id="101" ... >

   get-config(running, filter=(destination-prefix, next-hop-address))

   // check the reply, make sure it is OK, i.e. does not contain <rpc-
   error> element.

   edit-config(running, delete, config)

   Add a new route for MN at nUGW.  This route is based on MN's prefix,
   destination-prefix and the upstream router to which MN's traffic
   should routed, next-hop-address.

   <rpc message-id="101" ... >

   get-config(running, filter=(destination-prefix, next-hop-address))

   // check the reply, make sure it is an error, i.e. it contains <rpc-
   error> element of type application and tag data-missing i.e. no route
   exists

   edit-config(running, create, config)

   Add a new host route for MN at nUGW.  This route is added in case
   MN's prefix is not topologically correct at nUGW and routers above.

   <rpc message-id="101" ... >

    get-config(running, filter=(destination-prefix, next-hop-address))

   // check the reply, make sure it is an error, i.e. it contains <rpc-
   error> element of type application and tag data-missing, i.e. no
   route exists

   edit-config(running, create, config)

   We next show in Appendix A.3 and Appendix A.4 example RPC procedures
   for get-config and edit-config.  Some arbitrary values for
   destination prefix and next hop address are used.

A.3.  get-config RPC procedure for host routes

   This RPC procedure shows a get-config filter to find a record in the
   routing information base for a specific host whose prefix is
   2001:db8:1:0::/64 and the next-hop is 2001:db8:0:1::2.  It could be
   used for the get-config's in Appendix A.2.  We validated this
   procedure using the public domain tool pyang.




Sarikaya & Xue             Expires May 3, 2018                 [Page 20]


Internet-Draft            DMM for Wifi Use Case             October 2017


      <rpc message-id="101"
               xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
      xmlns:v6ur="urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing"
      xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"
      xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"
      xmlns:ip="urn:ietf:params:xml:ns:yang:ietf-ip"
      xmlns:rt="urn:ietf:params:xml:ns:yang:ietf-routing">
       <get-config>
         <source>
           <running/>
         </source>
         <filter type="subtree">
          <t:top xmlns:t="urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-host-routing">
         <t:routing-instance> rtr0 </t:routing-instance>


           <t:rib>
           <t:routes>
           <t:route>
             <t:destination-prefix>
            2001:db8:1:0::/64
           </t:destination-prefix>
             <t:outgoing-interface>eth1</t:outgoing-interface>
           <t:next-hop-address>
                         2001:db8:0:1::2
             </t:next-hop-address>
             </t:route>
           </t:routes>
         </t:rib>
       </t:top>
     </filter>
       </get-config>
     </rpc>

A.4.  edit-config RPC procedure to create a host route

   This RPC procedure shows an edit-config procedure to create a new
   host route in the routing information base for a specific host whose
   prefix is 2001:db8:1:0::/64 and the next-hop is 2001:db8:0:1::2.  It
   could be used for the edit-config's in Appendix A.2.  We validated
   this procedure using the public domain tool pyang.










Sarikaya & Xue             Expires May 3, 2018                 [Page 21]


Internet-Draft            DMM for Wifi Use Case             October 2017


         <rpc message-id="101"
               xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
      xmlns:v6ur="urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing"
      xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"
      xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"
      xmlns:ip="urn:ietf:params:xml:ns:yang:ietf-ip"
      xmlns:rt="urn:ietf:params:xml:ns:yang:ietf-routing">
       <edit-config>
         <target>
           <running/>
         </target>
         <default-operation>none</default-operation>
         <config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
          <top xmlns="urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-host-routing">
           <routing-instance> rtr0 </routing-instance>
           <rib>
           <routes>
            <route xc:operation="create">
             <destination-prefix >
            2001:db8:1:0::/64
             </destination-prefix>
             <outgoing-interface>eth1</outgoing-interface>
             <next-hop-address>
                         2001:db8:0:1::2
              </next-hop-address>
             </route>
           </routes>
         </rib>
       </top>
     </config>
    </edit-config>
   </rpc>

Authors' Addresses

   Behcet Sarikaya

   Email: sarikaya@ieee.org


   Li

   Email: xueliucb@gmail.com








Sarikaya & Xue             Expires May 3, 2018                 [Page 22]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/