Network Working Group B. Sarikaya
Internet-Draft L. Xue
Intended status: Standards Track Huawei
Expires: January 3, 2016 July 2, 2015
Distributed Mobility Management Protocol for WiFi Users in Fixed Network
draft-sarikaya-dmm-for-wifi-03.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 called Distributed Mobility
Management for Wi-Fi protocol. 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 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 3, 2016.
Copyright Notice
Copyright (c) 2015 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 3, 2016 [Page 1]
Internet-Draft DMM4WiFi July 2015
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 . . . . . . . . . . . . . . . . . 5
4.1. Layer 2 Mobility in Access Network . . . . . . . . . . . 5
4.2. Layer 3 Mobility and Routing in Core Network . . . . . . 6
4.3. Route Establishment . . . . . . . . . . . . . . . . . . . 7
4.4. Authentication and Charging . . . . . . . . . . . . . . . 9
4.4.1. Authentication . . . . . . . . . . . . . . . . . . . 9
4.4.2. Charging . . . . . . . . . . . . . . . . . . . . . . 12
5. Multicast Support . . . . . . . . . . . . . . . . . . . . . . 14
5.1. IPv4 Support for Multicast . . . . . . . . . . . . . . . 14
6. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative references . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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 3, 2016 [Page 2]
Internet-Draft DMM4WiFi July 2015
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 DMM for Wi-Fi 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, 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.
Sarikaya & Xue Expires January 3, 2016 [Page 3]
Internet-Draft DMM4WiFi July 2015
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 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 establish the initial routing
path when MN first enters the system. This path needs to be updated
as MN moves from one UGW 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 UGW.
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.
Sarikaya & Xue Expires January 3, 2016 [Page 4]
Internet-Draft DMM4WiFi July 2015
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 UGW to another UGW. 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.
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 [UTD-Paper], i.e. Layer 2 route.
Sarikaya & Xue Expires January 3, 2016 [Page 5]
Internet-Draft DMM4WiFi July 2015
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 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 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
receives new association information together with pRG information,
possibly in the cloud (called Handover Indication). nUGW finds pUGW
Sarikaya & Xue Expires January 3, 2016 [Page 6]
Internet-Draft DMM4WiFi July 2015
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.
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
Sarikaya & Xue Expires January 3, 2016 [Page 7]
Internet-Draft DMM4WiFi July 2015
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 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 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.
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 fib-route 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 by acting
as I2RS Client for 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 January 3, 2016 [Page 8]
Internet-Draft DMM4WiFi July 2015
4.4. Authentication and Charging
4.4.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.
+---------------+
| 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.
Sarikaya & Xue Expires January 3, 2016 [Page 9]
Internet-Draft DMM4WiFi July 2015
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.
+---------------+
| 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 January 3, 2016 [Page 10]
Internet-Draft DMM4WiFi July 2015
+---------------+
| 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 January 3, 2016 [Page 11]
Internet-Draft DMM4WiFi July 2015
The above Layer 2 operations do not affect Layer 3. MN does not
change the prefix assigned to it initially.
4.4.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 January 3, 2016 [Page 12]
Internet-Draft DMM4WiFi July 2015
+---------------+ 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 January 3, 2016 [Page 13]
Internet-Draft DMM4WiFi July 2015
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 for Multicast
For MNs with IPv4 addresses, multicast communication to MNs can be
supported similar to the way explained above in Section 5. Multicast
group management is done using IGMP with IGMP Proxy at the UGW.
In case of handover, the Active Multicast Subscription option
compatible with IGMP-based format which transports the multicast
membership context of the mobile node is used in handover messaging.
Active Multicast Subscription option has type value of 56 for IPv4
[RFC7161].
Sarikaya & Xue Expires January 3, 2016 [Page 14]
Internet-Draft DMM4WiFi July 2015
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], CLAT entity for 464XLAT [RFC6877], Lightweight B4
[I-D.ietf-softwire-lw4over6] or MAP Customer Edge
[I-D.ietf-softwire-map]. RG encapsulates IPv4 packets using these
protocols into IPv6 packets making sure that UGW stays IPv6 only.
7. Security Considerations
TBD.
8. IANA Considerations
TBD.
9. Acknowledgements
We would like to thank Satoru Matsushima for valuable advice.
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.
[RFC3590] Haberman, B., "Source Address Selection for the Multicast
Listener Discovery (MLD) Protocol", RFC 3590, September
2003.
[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.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
Sarikaya & Xue Expires January 3, 2016 [Page 15]
Internet-Draft DMM4WiFi July 2015
[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, August 2006.
[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.
[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.
[RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base
Deployment for Multicast Listener Support in Proxy Mobile
IPv6 (PMIPv6) Domains", RFC 6224, April 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.
[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, March 2014.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, April 2014.
Sarikaya & Xue Expires January 3, 2016 [Page 16]
Internet-Draft DMM4WiFi July 2015
[I-D.ietf-netmod-routing-cfg]
Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
Management", draft-ietf-netmod-routing-cfg-19 (work in
progress), May 2015.
[I-D.ietf-softwire-lw4over6]
Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and
I. Farrer, "Lightweight 4over6: An Extension to the DS-
Lite Architecture", draft-ietf-softwire-lw4over6-13 (work
in progress), November 2014.
[I-D.ietf-softwire-map]
Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, "Mapping of Address and Port
with Encapsulation (MAP)", draft-ietf-softwire-map-13
(work in progress), March 2015.
[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.
[ONFv1.5] "Open Networking Foundation, "OpenFlow Switch
Specification Version 1.5.0 ( Protocol version 0x06)"",
January 2015.
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 January 3, 2016 [Page 17]
Internet-Draft DMM4WiFi July 2015
[I-D.matsushima-stateless-uplane-vepc]
Matsushima, S. and R. Wakikawa, "Stateless user-plane
architecture for virtualized EPC (vEPC)", draft-
matsushima-stateless-uplane-vepc-04 (work in progress),
March 2015.
[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-09 (work in
progress), March 2015.
[UTD-Paper]
Jyotirmoy Banik, et al., "IEEE Vehicular Technology
Conference Fall 2015, "A Software Defined Semi Distributed
Mobility Management System Based on Layer 2 Backhaul
Network"", September 2015.
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 January 3, 2016 [Page 18]