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]