Internet DRAFT - draft-wei-sdnrg-framework-mobility-sdn
draft-wei-sdnrg-framework-mobility-sdn
Network Working Group X. Wei
Internet-Draft Huawei
Intended status: Standards Track J. Yin
Expires: December 19, 2014 D. Ni
K. Xue
USTC
S. Shen
CNNIC
June 17, 2014
Software Defined Network based General Mobility Management Framework
draft-wei-sdnrg-framework-mobility-sdn-00.txt
Abstract
This document proposes a general solution to support mobility
management in software defined network. In this draft, we divide the
controller plane into five function modules and explain the
achievement of these functions separately.
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 December 19, 2014.
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
Wei, et al. Expires December 19, 2014 [Page 1]
Internet-Draft SDN mobility management June 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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
2.1. Conventions Used in This Document . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of General Mobility Management Framework in SDN . . 4
4. Control-Plane Functions . . . . . . . . . . . . . . . . . . . 7
4.1. Event Trigger Function . . . . . . . . . . . . . . . . . 7
4.2. State Manager Function . . . . . . . . . . . . . . . . . 8
4.3. Mobility Management Decision Maker Function . . . . . . . 9
4.4. Tunnel Controller Function . . . . . . . . . . . . . . . 9
5. Case Study and Analysis . . . . . . . . . . . . . . . . . . . 10
5.1. Achievement of PMIPv6-like Mobility Management Scheme . . 11
5.2. Data-forwarding Process . . . . . . . . . . . . . . . . . 11
6. Advantage of General Mobility Management Architecture in SDN 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
With the rapid proliferation of mobile devices such as smart phones,
tablets, and laptop computers, the demand for mobility management is
becoming a primary challenge in current network. Several
representative approaches (e.g., Mobile IPv6 and Proxy Mobile IPv6)
have been proposed to address IP mobility problem. It is hard to
choose which proposal to deploy as every approach has its advantages
and disadvantages, so actually these approaches are coexisting in
Wei, et al. Expires December 19, 2014 [Page 2]
Internet-Draft SDN mobility management June 2014
current network. However, current approach is deployed in fixed
network devices (e.g., 3GPP deploys PMIPv6 in S-GW and P-GW) which
reveals some problems such as the difficulty to update existing
protocol or add new functions. How to fast implement a new mobility
management protocol in current network is a big challenge. Network
operators need to find a more flexible and easier way to manage and
control their networks.
Recently, software defined networking (SDN) is being actively
discussed and starts to attract considerable attention. Many SDN
based enhanced architectures are proposed to improve existing
networks, such as SDN based radio access networks and SDN based
cellular core networks. The main idea of SDN is to decouple data-
plane and control-plane. In SDN, switches (data-plane) are simple
data forwarding devices which are controlled and managed by SDN
controller (control-plane) via programmatic interfaces. The SDN
controller can easily expose and abstract various network functions
and operations to switches easily. It provides an easier way to
introduce new functions through software programmable controller.
Besides, it is more flexible to process data based on flow table
entries in switches. Therefore, it is significant to introduce SDN
concept to network mobility management.
Some related work have been discussed in IETF working group, such as,
draft [liu-sdn-mobility] tries to discuss mobility support in SDN
network and briefly proposes two solutions. Draft [yang-dmm-sdn-dmm]
applies SDN concept to optimize routing in DMM architecture.
Although both the two drafts have proposed the potential solutions to
support mobility management by applying SDN concept, there has been
little study of how to use existing or new defined operations to
realize the solutions. Furthermore, a practical system level
framework to support various mobility management protocols is not
completely presented and discussed.
In this document, we propose a general mobility management framework
based on SDN concept, consisting of a SDN controller and simple
switches. The framework provides better and more flexible solutions
to manage networks across various mobility management protocols. In
this general system level framework, besides the function of standard
SDN protocol, e.g., Openflow 1.0, 1.1,..., the controller mainly
achieves other four functions: event trigger, state manager, mobility
management decision maker and tunnel controller. Besides flow table
entries matching based data forwarding operation, core network
devices mainly have the function of tunnel processing. Upon
different mobility management protocols, the controller combines the
five functions to handle tunnel and insert different flow table
entries to switches. Based on this framework, the functions of
traditional network devices are converted to different logical
Wei, et al. Expires December 19, 2014 [Page 3]
Internet-Draft SDN mobility management June 2014
function designing in controller. The functions of different IP
mobility protocols can be easily realized in this framework.
Therefore, the key in our general framework is the design of
controller's logical functions. This document discusses the general
SDN based mobility management framework.
2. Conventions and Terminology
2.1. Conventions Used in This Document
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 [RFC2119].
2.2. Terminology
Software Defined Networking (SDN).
3. Overview of General Mobility Management Framework in SDN
In this specification, we present a general SDN based mobility
management framework which consists of a logically centralized
controller and simple network devices. Our general framework is
designed to support various mobility management functions based on
following principles:
o Scalable: The general framework is scalable to support various
mobility management protocols (e.g., MIP-like protocol and PMIP-like
protocol). New mobility management functions can be easily
introduced to the general framework too. In our general framework,
the controller inserts different flow table entries into network
devices based on different mobility management functions via
programmable interface.
o Flexible: The goal is to update or add mobility management
functions easily without changing network devices. Network devices
are just simple packet forwarding switches which process data upon
flow table entries. There is no need to develop specified network
devices to support different logical functions in SDN controller
according to different mobility management schemes. Furthermore,
different mobility management schemes can coexist in this framework.
In the general framework, the controller can dictate the overall
network behavior and manage traffic forwarding decisions, while
network devices (e.g., P-GW and S-GW in 3GPP) become simple packet
forwarding switches. The SDN protocol between the controller and
network devices can be various (e.g., OpenFlow, which is one of the
most common southbound protocols in SDN). Different with common SDN
Wei, et al. Expires December 19, 2014 [Page 4]
Internet-Draft SDN mobility management June 2014
architecture, the controller need to combine some other additional
functions (e.g., tunnel controller) to implement mobility management
in the general framework.
Figure 1 shows the overview of the proposed general mobility
management framework in SDN. To achieve general mobility management
in SDN, the controller mainly has five function modules (more details
are elaborated in the following section):
o Event Trigger: The event trigger manages mobility management
events, which is related to robustness optimization based mobility
management, such as mobile user's arriving and leaving, handoff, link
state changing. Different mobility management events will result in
different controller actions. The controller obtains event
information from this function which will be sent to Mobility
Management Decision Maker function module to make controller
decisions.
o State Manager: Controller can collect state information about
mobile user and network devices (e.g., user's current link state and
network device's user number) from this function module to obtain
overall network state information, which is related to Load Balancing
based mobility management. This state information will be used by
the Mobility Management Decision Maker module to make load balancing
related actions for mobility management events.
o Tunnel Controller: To implement tunnel related process in IP
mobility management, we add the tunnel controller function module in
the controller (in the network devices, we add the tunnel processer
function module). The tunnel controller manages tunnel set-up and
pull-down in the IP mobility management process. Controller uses
this function to inform network devices the tunnel process
information. For instance, to set up a tunnel, controller will use
this function to inform network devices tunnel related information
(e.g., for IP-in-IP tunnel, the information consists of the tunnel
endpoint address; furthermore, security related information).
o Mobility Management Decision Maker: The mobility management
decision maker forms the core function of the general framework.
Based on mobility management policies, it combines the other three
function modules and returns the final decisions to the SDN
Controller module. The State Manager module returns network state
information to this function, while the Event Trigger module returns
mobility event to it. The Mobility Management Decision Maker
function module will order the Tunnel Controller function module to
make corresponding operations (e.g., set-up or pull-down a tunnel) to
process tunnels which are related to mobility management event.
Wei, et al. Expires December 19, 2014 [Page 5]
Internet-Draft SDN mobility management June 2014
Besides, network operators can deploy various mobility management
policies in this module to achieve various management functions.
o SDN controller: Similar to common SDN controller function, it
collects state information from SDN switch (e.g., here, SDN switch is
called network devices too) and deals with messages which are sent
from network devices. Also, it tranlates the final decisions to
various control actions such as flow table entries which will be sent
to network devices.
While in core network devices, it mainly has three function modules
which are related to mobility management:
o Non-SDN State Collector: The controller needs to know information
about the whole network which is related to network devices and
network users. Besides SDN related state information (e.g., the
switch information, such as, network devices' manufacturer, the
number of users which access to network devices), the controller also
collects non-SDN state information (e.g., user state) from network
devices via this function module. The function obtains user state
information and sends them to the State Manager function module in
SDN controller via interface between controller and network devices.
o Tunnel Handler: Similar to the Tunnel Controller module in SDN
controller, the Tunnel Handler module is to set-up or pull-down
related tunnel in mobility management process. It obtains tunnel
information from the Tunnel Controller in SDN controller and adds (or
deletes) virtual interfaces in network devices. Also, it returns
tunnel's virtual interface information to SDN controller.
o SDN Switch: The SDN Switch function module is the same as common
SDN switch. It performs basic data forwarding function based on flow
table entries. This function is controlled and managed by SDN
controller using SDN protocol (e.g., OpenFlow protocol) via
programmable interfaces. SDN controller can collect basic switch
information from this function also.
Wei, et al. Expires December 19, 2014 [Page 6]
Internet-Draft SDN mobility management June 2014
+-----------------------------------------------------------------+
| +-----------------------------------------+ Controller|
| | | |
| | \|/ |
| +-------------+ +-------------+ +-------------------+ |
| +->|State Manager| +->|Event Trigger|--->|Mobility Management| |
| | +-------------+ | +-------------+ | Decision Maker | |
| | /|\ | +-------------------+ |
| | | | | | |
| | | | | | |
| | | | +----------+ | | +----------+|
| | | +------------| SDN |<-+ +->| Tunnel ||
| | +----------------------|Controller|<-+ +->|Controller||
| | +----------+ | | +----------+|
+-|---------------------------------------------|--|--------------+
| | |
| | |
| | |
+-|---------------------------------------------|--|-- ---------------+
| | | | Network device |
| | +-----------------------+ +----------+ | | +--------------+|
| +-|Non-SDN State Collector| |SDN Switch|<-+ +->|Tunnel Handler||
| +-----------------------+ +----------+ +--------------+|
+---------------------------------------------------------------------+
Figure 1: The General Mobility Management Framework in SDN.
4. Control-Plane Functions
4.1. Event Trigger Function
Event trigger function deals with the mobility management events such
as new mobile user's arriving, handoff, mobile user's leaving and
link state changing, which results in the controller's operations
(e.g., insert flow table entries to switch, tunnel set-up). The
mobility events are collected from network devices via programmable
interfaces using existing messages in SDN. Figure 2 shows the
interaction between the SDN controller and network devices to achieve
this function.
Wei, et al. Expires December 19, 2014 [Page 7]
Internet-Draft SDN mobility management June 2014
+------------------------------------------------------+
| Controller |
| +-------------+ mobility +-------------------+ |
| +-->|Event Trigger|----------->|Mobility Management| |
| | +-------------+ events | Decision Maker | |
| | +-------------|-----+ |
+-|--------------------------------------------|-------+
| |
Packet_in(L2 attachment) Add flow table entry message
| +---------------------+ |
| | +-------+ Network| |
+-----------|--| SDN | Device|<---------+
| |Switch |<----+ |
| +-------+ | |
+----------------|----+
|
Attachment to Network
+-----------+ |
|Mobile User|--+
+-----------+
Figure 2: Event Trigger Function.
For instance, with a new mobile user's attachment to network device
(S-GW in 3GPP), the device will send a message which is called
Packet_in in OpenFlow protocol to the Event Trigger function in SDN
controller as there is no matching flow table entry in the network
device. The Packet_in message contains attachment signaling (e.g.,
L2 attachment signaling). The Event Trigger function further trigger
Mobility Management Decision Maker function to makes mobility
decisions for it. The decisions are translated into flow table
entries by SDN Controller function, which are sent to network
devices.
4.2. State Manager Function
State Manager Function collects state information about mobile user
and network device (e.g., user's current link usage state and
device's user number). Together with mobility event, the state
information is used by the controller to make mobility policy
decisions. In this document, we propose two ways to collect state
information.
The first method depends on the interaction between the SDN
controller and network devices. Non-SDN State Collector collects
user information from mobile user, while SDN switch keeps network
device's state information. As Figure 3 shows, the controller
Wei, et al. Expires December 19, 2014 [Page 8]
Internet-Draft SDN mobility management June 2014
collects this state information by using messages called
status_request/status_reply in OpenFlow. The second method utilizes
some network components (e.g., 3GPP/ANDSF), which maintains a list of
users' available access networks.
+--------------------------------------------+
| Controller |
| +---------------+ |
| +------------>| State Manager |<---------+ |
| | +---------------+ | |
+-|----------------------------------------|-+
| |
+-|----------------------------------------|---+
| | +---------------+ +----------+ | |
| +--->| Non-SDN | |SDN Switch|<---+ |
| |State Collector| +----------+ |
| +---------------+ Network Device|
+----------------------------------------------+
Figure 3: State Information from Network Device.
4.3. Mobility Management Decision Maker Function
Mobility management Decision Maker function is used by the controller
to process various mobility events, which is the key part of
realizing current IP mobility management schemes-liked function. In
this function, network operators can deploy various mobility
management policies (e.g., handoff policy, admission control policy,
QoS-based policy). Based on these policies, this function combines
State Manager function with Event Trigger function to make proper
mobility decisions. This function can be extended to support
physical layer, link layer and network layer related mobility
management.
4.4. Tunnel Controller Function
Most of current mobility management protocols all introduce an
topology anchor point anchor to manage the mobile device's home
network prefix. Packets will arrive at the mobile device through a
tunnel which is set up between the anchor and the mobile device (or
access network device, like S-GW). In our proposed architecture, we
introduce Tunnel Controller function in the controller and Tunnel
Processer Function in network devices to process the tunnel set-up
and pull-down. New messages should be defined to support this tunnel
process. Based on the provided tunnel information, a bi-directional
tunnel can be setup between two network devices. A virtual interface
can be seen as a physical interface, which can be used in the flow
Wei, et al. Expires December 19, 2014 [Page 9]
Internet-Draft SDN mobility management June 2014
table entries. Figure 4 shows the new defined message between the
controller and network access devices in tunnel-related process.
+-----------------------------+
| Controller |
| +-----------------+ |
+---------|---->|Tunnel Controller|<----|---------------+
| | +-----------------+ | |
| +-----------------------------+ |
Tunnel_add/Tunnel_delete Tunnel_add/Tunnel_delete
| |
| +-------------------+ +--------------------+ |
| |+-----------------+| tunnel | +----------------+ | |
+->| Tunnel Processer|| ======= | |Tunnel Processer| <--+
|+-----------------+| ======= | +----------------+ |
| Network Device1 | | Network Device2 |
+-------------------+ +--------------------+
Figure 4: Tunnel Process
As in Figure 4, message Tunnel_add is defined to support tunnel set-
up process which contains tunnel information (e.g., in IP-in-IP
tunnel, the message contains the tunnel endpoints' addresses
including source address and destination address). Once Tunnel
Processer function in network device receives tunnel_add message, it
adds a virtual interface which is used for bi-directional tunnel.
Similarly, we define message Tunnel_delete to pull down existed
tunnels. When mobile device moves to a new access network device,
previous tunnel which is established between the anchor and previous
access device should be pulled down. Message Tunnel_delete is
defined to inform a network device to delete the tunnel, which
contains the tunnel information (e.g., tunnel descriptor). Once
Tunnel Processer receives the message and obtains tunnel information,
it will pull down the virtual interface used for the tunnel.
Detailed messages will be designed in the future work.
5. Case Study and Analysis
Traditional mobility management protocols mainly focus on two
aspects: location management which targets on location initial
registration and update, and handoff management which maintains
communication alive when mobile device moves from one access point to
another. Based on our proposed framework, the functions of different
mobility management schemes are only different in logical function
Wei, et al. Expires December 19, 2014 [Page 10]
Internet-Draft SDN mobility management June 2014
realization. Here we introduce to how to implement PMIP-like
mobility management.
5.1. Achievement of PMIPv6-like Mobility Management Scheme
Based on our proposed framework, we will illustrate how to implement
different mobility management function from two aspects. For
instance, to achieve PMIPv6-like mobility management function, we
explain the implement from two following aspects:
o Initial registration: This process will be considered when mobile
user first attaches to network. When SDN switch detects a new
attachment signal message from mobile user, it sends a Packet_in
message containing an original attachment signal message to the
controller (Event Trigger Function), then the Mobility Management
Decision Maker Function is triggered. Mobility Management Decision
Maker Function choose a appropriate access network and obtain a home
address prefix, then generate some flow table entries and send them
to relative network switches in SDN messages.
o Mobility handoff: Mobility handoff processes event that mobile user
moves from current access switch to another. Both Event Trigger and
State Manager functions can trigger Mobility Management Decision
Maker function to implement mobility handoff. The Mobility
Management Decision Maker function first triggers Tunnel Controller
function. Then Tunnel Controller function will inform two network
devices to set up a bi-directional tunnel between network devices
(e.g., S-GW and P-GW in 3GPP). Once Tunnel Processer function in
network device receives the tunnel information (e.g., tunnel
endpoints' addresses), it will add virtual interfaces in the two
network devices to set up the tunnel. Meanwhile, The Mobility
Management Decision Maker function generates some flow table entries
and sends them to relative network switches in SDN messages.
5.2. Data-forwarding Process
Figure 5 gives a simple example of data-forwarding in user mobility
process. As figure 5 shows, controller manages two kinds of network
devices, one is network access device (e.g., S-GW in 3GPP) while
another is anchor of home network (e.g., P-GW in 3GPP).
Wei, et al. Expires December 19, 2014 [Page 11]
Internet-Draft SDN mobility management June 2014
+----------+
+-------------------------->|Controller|<----------------------------+
| +----------+ |
| /|\ |
| | |
| | |
| \|/ |
| +--------------+ Tunnel +--------------+ Tunnel +--------------+ |
+->|Network Device|========|Network Device|========|Network Device|<-+
| (e.g.,S-GW) |========| (e.g.,P-GW) |========| (e.g.,S-GW) |
+--------------+ +--------------+ +--------------+
Switch1 Switch0 Switch2
Figure 5: Data-forwarding Process.
At the beginning of data forwarding, the data goes through Switch1 to
Switch0. After mobile user moves from Switch1 to Switch2, we discuss
the data path of up-link and down-link based on our general
framework. First, when mobile user accesses to Switch2, initial
registration of user to Switch2 will be implemented. A tunnel
between Switch0 and Switch2 is set up. Then the controller 1)
obtains user handoff event, 2) adds flow table entries in Switch2
(e.g., Entry1: [src address: pref1, action: the next hop is Switch0],
Entry2: [dst address: pref1, action: the next hop is mobile user's
interface]), 3) modify flow table entries in Switch0 (e.g., Entry3:
[dst address: pref1, action: the next hop is Switch2]).
Based on the analyzed process described above, the Up-link data path:
1) data first arrives at Switch2, 2) matches Entry1 in Switch2 and
forwards to Switch0, 3) finally goes to network by matching a common
routing related entry in Switch0. While considering Down-link path:
1) data first arrives at Switch0, 2) matches Entry3 in Switch0 and
forwards to Switch2, 3) when arrives at Switch2, based on Entry2 in
Switch2, data finally arrives at mobile user.
6. Advantage of General Mobility Management Architecture in SDN
Existing mobility management devices with poor scalability are
difficult to introduce and deploy new protocols. However, SDN
supports programmable interfaces between switch and controller which
provides a more scalable control-plane and flexible data-plane. In
our general architecture, the controller combines the five functions
and network devices combine the three functions to realize mobility
management in SDN. We use existing or newly defined messages to
achieve interaction between controller and network device.
Realization of different logical functions in controller can support
different mobility management functions (e.g., MIP-like, PMIP-like,
Wei, et al. Expires December 19, 2014 [Page 12]
Internet-Draft SDN mobility management June 2014
DMM-like, and so on). The controller inserts different flow table
entries in programmable network devices based on different protocols.
Besides, the controller only needs to modify flow-table entries when
network operators want to update mobility management protocols or add
new mobility management functions.
7. Security Considerations
TBD
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
8.2. Informative References
[I-D.liu-sdn-mobility]
Liu. D and H. Deng, "Mobility Support in Software Defined
Networking", draft-liu-sdn-mobility-00 (work in progress),
July 2013.
[I-D.yang-dmm-sdn-dmm]
H. Yang and Y. Kim, "Routing Optimization
with SDN", draft-yang-dmm-sdn-dmm-01 (work in progress),
April 2014.
Authors' Addresses
Xinpeng Wei
Huawei
Phone: +86 13436822355
Email: weixinpeng@huawei.com
Wei, et al. Expires December 19, 2014 [Page 13]
Internet-Draft SDN mobility management June 2014
Jing Yin
USTC
EEIS Department, USTC West Campus
Shushan District , Hefei 230027
P. R. China
Phone: +86-551-63601334
Email: yinj08@mail.ustc.edu.cn
Dan Ni
USTC
EEIS Department, USTC West Campus
Shushan District , Hefei 230027
P. R. China
Phone: +86-551-63601334
Email: nidan@mail.ustc.edu.cn
Kaiping Xue
USTC
EEIS Department, USTC West Campus
Shushan District , Hefei 230027
P. R. China
Phone: +86-551-63601334
Email: kpxue@ustc.edu.cn
Sean Shen
CNNIC
4, South 4th Street, Zhongguancun
Beijing 100190
P.R. China
Email: shenshuo@cnnic.cn
Wei, et al. Expires December 19, 2014 [Page 14]
