[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05                                             
Network Working Group                                        B. Sarikaya
Internet-Draft                                                    L. Xue
Intended status: Standards Track                                  Huawei
Expires: April 27, 2015                                 October 24, 2014


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

Abstract

   As networks are moving towards flat architectures, a distributed
   approach is needed to mobility management.  This document defines a
   distributed mobility management protocol.  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 http://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 April 27, 2015.

Copyright Notice

   Copyright (c) 2014 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
   (http://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
   to this document.  Code Components extracted from this document must



Sarikaya & Xue           Expires April 27, 2015                 [Page 1]


Internet-Draft                  DMM4WiFi                    October 2014


   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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Detailed Protocol Operation . . . . . . . . . . . . . . . . .   4
     4.1.  Layer 2 Mobility in Access Network  . . . . . . . . . . .   4
     4.2.  Layer 3 Mobility and Routing in Core Network  . . . . . .   5
   5.  Authentication and Charging . . . . . . . . . . . . . . . . .   7
     5.1.  Authentication  . . . . . . . . . . . . . . . . . . . . .   7
     5.2.  Charging  . . . . . . . . . . . . . . . . . . . . . . . .  11
   6.  IPv4 Support  . . . . . . . . . . . . . . . . . . . . . . . .  13
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     10.2.  Informative references . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

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
   [I-D.ietf-dmm-requirements].

   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 April 27, 2015                 [Page 2]


Internet-Draft                  DMM4WiFi                    October 2014


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

               Figure 1: Architecture of Wi-Fi DMM Protocol

2.  Terminology

   This document uses the terminology defined in
   [I-D.matsushima-stateless-uplane-vepc].

3.  Overview

   This section presents an overview of the protocol.  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 closes UGW.

   Wi-Fi smart phone, the mobile node (MN) is assigned a unique prefix
   using either Stateless Address Auto Configuration (SLAAC) or by a



Sarikaya & Xue           Expires April 27, 2015                 [Page 3]


Internet-Draft                  DMM4WiFi                    October 2014


   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 5).

   When MN moves from one UGW into another UGW, 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).  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.  Control plane in our document is moved to the cloud,
   thus mobility signaling happens at the cloud, possibly between two
   virtual machines (VM).

   Upstream packets from MN at the new UGW are sent as usual but
   downstream packets may need special path establishment if MN's prefix
   is not hosted at the new UGW.  In this case Software-Defined
   Networking (SDN) is used.  SDN allows Routing Information Bases (RIB)
   in a subset of the upstream routers to be modified to enable the
   downstream packets to be routed to the new UGW but not to the
   previous UGW.

4.  Detailed Protocol Operation

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

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 Extensible Messaging and Presence Protocol



Sarikaya & Xue           Expires April 27, 2015                 [Page 4]


Internet-Draft                  DMM4WiFi                    October 2014


   (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.

   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) messages 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.

4.2.  Layer 3 Mobility and Routing in Core Network

   MN moving from one RG to another may eventually require MN moving
   from one UGW 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
   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 nUGA 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.






Sarikaya & Xue           Expires April 27, 2015                 [Page 5]


Internet-Draft                  DMM4WiFi                    October 2014


           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
   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.

           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) is needed.




Sarikaya & Xue           Expires April 27, 2015                 [Page 6]


Internet-Draft                  DMM4WiFi                    October 2014


   After handover, SDN route establishment in upstream routers needs to
   take place.  In this case NETCONF protocol [RFC6241] and YANG
   modeling [RFC6020]  are used.  I2RS Agent as NETCONF Client in nUGW
   and in pUGW inform the handover to I2RS Clients as NETCONF Server
   upstream.  I2RS Agent at pUGW removes any routing information for MN.
   NETCONF Clients and Servers engage in simple Remote Procedure Call
   (RPC) request-reply interactions.  These interactions are needed for
   these purposes: I2RS Client publishes the new route for this MN to
   nUGW at the router upstream.  I2RS Agent at nUGW adds new routing
   information for this MN into its RIB.

   A YANG module for DMM for WiFi is TBD.  Detailed NETCONF operations
   using this module is TBD.  We explain how the two can be used
   together.  Client and Server exchange their capabilities using 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.  The request could be to add a host
   route and the reply is the result of this request.

   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 proper modifications so that the
   packets reach the right Unified Gateway.  One way to achive this
   could be using host routes.

5.  Authentication and Charging

5.1.  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 simplied
   several 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 April 27, 2015                 [Page 7]


Internet-Draft                  DMM4WiFi                    October 2014


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


                             Preauthentication

   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 April 27, 2015                 [Page 8]


Internet-Draft                  DMM4WiFi                    October 2014


                        +---------------+
                        | 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
   contiunity 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 April 27, 2015                 [Page 9]


Internet-Draft                  DMM4WiFi                    October 2014


                           +---------------+
                           | 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 April 27, 2015                [Page 10]


Internet-Draft                  DMM4WiFi                    October 2014


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

5.2.  Charging

   When MN moves from one UGW into another UGW, the charging needs to be
   considered.  In this document we describe two cases, one operator and
   two interworking operators.

   One operator case.

   Two operators case.  If the pUGW and nUGW are belonging to two
   different operators.

   There are two possibilities.  The traffic is directed to the visited
   network, and traffic routed back to home.

                         Charging
      +---------------+            +---------------+
      |pAuthentication|<-----------|nAuthentication|
      |    Server     |----------->|    Server     |
      +---------------+            ++--------------+
            Data   ***********************  Charging
                                    |    * ^
                                    |    * |
                                    |    * |
             +---------+          +-+----*-++
             |   pUGW  |          |  nUGW*  |
             ++--------+          +------*-++ ^  Join Report Msg
        ,'    |                         *  |  |     `.
       (      |                         *  |  |        )
        `.    |      Access Network     *  |  |     ,'
         +----++           +-----+      * ++--+-+
         | RG  |           | RG  |      * | RG  |
         +-----+           +-----+      * +-----+
       +-----                          +*----+
       | MN  | ----move--------------- | MN  |
       +-----+                         +-----+

      Two operators interworking - Traffic offload in visited network











Sarikaya & Xue           Expires April 27, 2015                [Page 11]


Internet-Draft                  DMM4WiFi                    October 2014


       +---------------+   charging +---------------+
       |pAuthentication|----------->|nAuthentication|
       |    Server     |            |    Server     |
       +---------------+ ^          ++--------------+
                         |
       Data              | charging  |
             **********  |           |
                      *  |           |
              +-------*-+ Charging +-+-------+
              |   pUGW* |<---------+  nUGW   |
              ++------*-+          +--------++ ^  Join Report Msg
         ,'    |      ********************  |  |     `.
        (      |                         *  |  |        )
         `.    |      Access Network     *  |  |     ,'
          +----++           +-----+      * ++--+-+
          | RG  |           | RG  |      * | RG  |
          +-----+           +-----+      * +-----+
        +-----                          +*----+
        | MN  | ----move--------------- | MN  |
        +-----+                         +-----+

         Two operators interworking - Traffic routed back to home

                    +---------------+
                    | Authentication|
                    |    Server     |
                    +-- ------------+ ^
                                      |    Charging
                                      |
            +---------+          +----+----+
            |   pUGW  |          |  nUGW   |
            ++--------+          +--------++ ^  Join Report Msg
       ,'    |                            |  |     `.
      (      |                            |  |        )
       `.    |      Access Network        |  |     ,'
        +----++           +-----+        ++--+-+
        | RG  |           | RG  |        | RG  |
        +-----+           +-----+        +-----+
      +-----                          +-----+
      | MN  | ----move--------------- | MN  |
      +-----+                         +-----+

                         Charging in one operator








Sarikaya & Xue           Expires April 27, 2015                [Page 12]


Internet-Draft                  DMM4WiFi                    October 2014


6.  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.

   IPv4 MN is supported at the RG.  RG has B4 functionality of DS-Lite
   [RFC6333] or CLAT entity for 464XLAT [RFC6877].  RG encapsulates IPv4
   packets in DS-Lite or translates IPv4 packets in 464XLAT into IPv6
   packets making sure that UGW stays IPv6 only.

7.  Security Considerations

   TBD.

8.  IANA Considerations

   TBD.

9.  Acknowledgements

   TBD.

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              December 2003.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
              3748, June 2004.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC5949]  Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F.
              Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949,
              September 2010.






Sarikaya & Xue           Expires April 27, 2015                [Page 13]


Internet-Draft                  DMM4WiFi                    October 2014


   [RFC6020]  Bjorklund, M., "YANG - A Data Modeling Language for the
              Network Configuration Protocol (NETCONF)", RFC 6020,
              October 2010.

   [RFC6121]  Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Instant Messaging and Presence", RFC
              6121, March 2011.

   [RFC6241]  Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
              Bierman, "Network Configuration Protocol (NETCONF)", RFC
              6241, June 2011.

   [RFC6244]  Shafer, P., "An Architecture for Network Management Using
              NETCONF and YANG", RFC 6244, June 2011.

   [RFC6333]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
              Stack Lite Broadband Deployments Following IPv4
              Exhaustion", RFC 6333, August 2011.

   [RFC6877]  Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
              Combination of Stateful and Stateless Translation", RFC
              6877, April 2013.

   [IEEE-802.11i]
              "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.

   [IEEE-802.11-2007]
              "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.

10.2.  Informative references

   [I-D.ietf-dmm-requirements]
              Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen,
              "Requirements for Distributed Mobility Management", draft-
              ietf-dmm-requirements-17 (work in progress), June 2014.





Sarikaya & Xue           Expires April 27, 2015                [Page 14]


Internet-Draft                  DMM4WiFi                    October 2014


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

   [I-D.ietf-i2rs-architecture]
              Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
              Nadeau, "An Architecture for the Interface to the Routing
              System", draft-ietf-i2rs-architecture-05 (work in
              progress), July 2014.

Authors' Addresses

   Behcet Sarikaya
   Huawei
   5340 Legacy Dr. Building 175
   Plano, TX  75024

   Phone: +1 469 277 5839
   Email: sarikaya@ieee.org


   Li Xue
   Huawei
   NO.156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan,
   Beijing, HaiDian District  100095
   China

   Email: xueli@huawei.com





















Sarikaya & Xue           Expires April 27, 2015                [Page 15]