Network Working Group B. Sarikaya
Internet-Draft Huawei USA
Intended status: Standards Track L. Xue
Expires: January 4, 2015 Huawei
July 3, 2014
Distributed Mobility Management Protocol for WiFi Users in Fixed Network
draft-sarikaya-dmm-for-wifi-00.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 January 4, 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
Sarikaya & Xue Expires January 4, 2015 [Page 1]
Internet-Draft DMM4WiFi July 2014
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. 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. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 7
9.2. Informative references . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
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 January 4, 2015 [Page 2]
Internet-Draft DMM4WiFi July 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 January 4, 2015 [Page 3]
Internet-Draft DMM4WiFi July 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.
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
(XMPP)[RFC6121]. XMPP is based on a general subscribe-publish
message bus. SDN controller publishes forwarding instructions to the
Sarikaya & Xue Expires January 4, 2015 [Page 4]
Internet-Draft DMM4WiFi July 2014
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 January 4, 2015 [Page 5]
Internet-Draft DMM4WiFi July 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 January 4, 2015 [Page 6]
Internet-Draft DMM4WiFi July 2014
After handover, SDN route establishment in upstream routers needs to
take place. I2RS Agent as XMPP Client in nUGW and in pUGW inform the
handover to I2RS Clients as XMPP Server upstream. I2RS Agent at pUGW
removes any routing information for MN. XMPP Clients and Servers
engage in structured request-response 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.
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. 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.
6. Security Considerations
TBD.
7. IANA Considerations
TBD.
8. Acknowledgements
TBD.
9. References
9.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.
Sarikaya & Xue Expires January 4, 2015 [Page 7]
Internet-Draft DMM4WiFi July 2014
[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.
[RFC6121] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence", RFC
6121, March 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.
9.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.
[I-D.matsushima-stateless-uplane-vepc]
Matsushima, S. and R. Wakikawa, "Stateless user-plane
architecture for virtualized EPC (vEPC)", draft-
matsushima-stateless-uplane-vepc-02 (work in progress),
February 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-04 (work in
progress), June 2014.
Authors' Addresses
Behcet Sarikaya
Huawei USA
5340 Legacy Dr. Building 175
Plano, TX 75024
Phone: +1 469 277 5839
Email: sarikaya@ieee.org
Sarikaya & Xue Expires January 4, 2015 [Page 8]
Internet-Draft DMM4WiFi July 2014
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 January 4, 2015 [Page 9]