Forwarding and Control Element Separation L. Zeng Internet Draft Tsinghua University Intended status: Informational May 18, 2014 Expires: November 2014 ForCES inter-FE Consistent Control Scheme draft-zeng-forces-interfe-consistent-control-00.txt 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on November 18, 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 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. Zeng Expires November 18, 2014 [Page 1] Internet-Draft ForCES inter-FE Consistent Control Scheme May 2014 Abstract This document addresses the inter-FE consistent control problem for ForCES in software-defined network (SDN), and proposes an inter-FE consistent control scheme through dynamic match-field selection. In detail, the control element (CE) analyzes the similarities and differences between both the old and rules. Then, CE dynamically determines appropriate match fields and, correspondingly, generates a set of transitional flow entries. After that, it deletes the old flow entries and writes the new ones. Finally, the consistent control is achieved after deleting the transitional flow entries. This scheme guarantees the inter-FE consistent control. Table of Contents 1. Introduction ................................................ 2 2. Conventions used in this document............................ 3 2.1. Requirements Language................................... 3 2.2. Definitions ............................................ 3 3. Software Defined Network Based ForCES Framework ..............4 4. Inter-FE Consistent Control Problem ..........................5 5. Inter-FE Consistent Control Scheme Frame .....................5 6. Preprocessing Phase (PP)..................................... 6 7. Transitional phase (TP)...................................... 7 8. Update phase (UP) ........................................... 7 9. Timing Diagram .............................................. 8 10. Security Considerations..................................... 9 11. IANA Considerations......................................... 9 12. Conclusions ................................................ 9 13. References ................................................. 9 13.1. Normative References................................... 9 14. Acknowledgments ........................................... 10 1. Introduction Forwarding and control element separation (ForCES) defines the architecture and corresponding protocols, interfaces, and other key technologies to standardize the separation between control plane and forwarding plane in network element, called ForCES NE. The control functions of ForCES NE are centralized in the control elements (CEs), while the forwarding elements are controlled by the CEs. The requirements and framework of ForCES are described in RFC 3654 and RFC 3746 respectively [RFC3654][RFC3746]. Software-defined network (SDN), just in its birth, is a promising technology consisting with ForCES. SDN makes it convenient and Zeng Expires November 18, 2014 [Page 2] Internet-Draft ForCES inter-FE Consistent Control Scheme May 2014 possible to achieve ForCES by introducing a centralized controller who makes the data processing rules of forwarding devices. ForCES method may result in a specific issue that different FEs may not update multiple flow entries simultaneously due to the different latency, which leads to a series of incorrect and uncontrollable problem. This issue is called as inter-FE consistent control problem. This document addresses this problem and proposes an inter-FE consistent control scheme. 2. Conventions used in this document 2.1. Requirements Language 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 RFC-2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. 2.2. Definitions This document follows the terminology defined by the ForCES protocol in [RFC5810]. The definitions below are repeated for clarity. Control Element (CE) - A logical entity that implements the ForCES protocol and uses it to instruct one or more FEs on how to process packets. CEs handle functionality such as the execution of control and signaling protocols. Forwarding Element (FE) - A logical entity that implements the ForCES protocol. FEs use the underlying hardware to provide per- packet processing and handling as directed/controlled by one or more CEs via the ForCES protocol. ForCES Protocol - While there may be multiple protocols used within the overall ForCES architecture, the terms "ForCES protocol" and "protocol" refer to the Fp reference points in the ForCES framework in [RFC3746]. This protocol does not apply to CE-to-CE communication, FE-to-FE communication, or communication between FE and CE managers. Basically, the ForCES protocol works in a master-slave mode in which FEs are slaves and CEs are masters. ForCES Network Element (NE) - An entity composed of one or more CEs and one or more FEs. To entities outside an NE, the NE represents a Zeng Expires November 18, 2014 [Page 3] Internet-Draft ForCES inter-FE Consistent Control Scheme May 2014 single point of management. Similarly, an NE usually hides its internal organization from external entities. 3. Software Defined Network Based ForCES Framework A logical view of the SDN based ForCES architecture is shown in Figure 1, which consists of three layers: infrastructure layer, control layer and application layer. +--------------------------------------------------------------+ | +--------------------------------------------------------+ | | | +---------------------+ | | | | | | | | | | Application +--+------------------+--+ | | | | | | | | | | Layer +--+------------------+--+ | | | | |Business Applications| | | | | +---*------*------*---+ | | | +------------------------|------|------|-----------------+ | | |API |API |API | | +------------------------|------|------|-----------------+ | | | +----------*------*------*---------------+ | | | | | +----------------+ | | | | | | SDN | | | | | | | | Control +--+-------------+--+ | | | | | Control | Software | | | | | | | Layer | +--+-------------+--+ | | | | | (CE) | |Network Services| | | | | | | +----------------+ | | | | | +------------**--------------------------+ | | | +--------------------------||-------------------------+ | | | ||Control Data Plane Interface| | | || (ForCES Protocol) | | | +--------------------------||----------------------------+ | | | Infrastructure || | | | | Layer || | | | | +--------------+ +-----**-------+ +--------------+ | | | | | FE | | FE | | FE | | | | | +--------------+ +--------------+ +--------------+ | | | | +--------------+ +--------------+ | | | | | FE | | FE | | | | | +--------------+ +--------------+ | | | +--------------------------------------------------------+ | +--------------------------------------------------------------+ Figure 1 Software-Defined Network Architecture Zeng Expires November 18, 2014 [Page 4] Internet-Draft ForCES inter-FE Consistent Control Scheme May 2014 The infrastructure layer is composed of multiple FEs that is only in charge of executing the forwarding functions. Network control intelligence is logically centralized in control layer, i.e. CE. In particular, a centralized SDN based CE, named controller, is in charge of controlling function. In the controller, different network control functions can be developed as customized. As to application layer, different kinds of business applications are deployed. Between application layer and control layer, a set of APIs (Application Programming Interfaces) are designed, which allows business applications to use network control services in control layer. Also, control data plane interface is designed between control layer and infrastructure layer, which is used to interchange control and forwarding information between the controller and network devices. In the SDN architecture, the controller uses flow entry to control multiple FEs, where the forwarding function is executed. In each network service, there exists a flow table to store flow entries sent by the controller. The controller can add/delete/modify flow entries to each FE. 4. Inter-FE Consistent Control Problem In SDN based ForCES framework, the CE uses flow entries to control forwarding behavior of different FEs. In particular, there are special security channel between the CE and FEs to transform flow entry information. Since multiple FEs make up a distributed system, control problem exists in SDN framework. In detail, it is difficult for the CE to update multiple flow entries simultaneously, due to different latency of different special security channels. If these flow entries are written into FEs at different time, data packets may follow the wrong control instruction and be incorrectly deal with, leading to system chaos, packets loss, service deteriorate, and etc. Due to this control problem, it is necessary to study consistent flow control mechanism for ForCES based on SDN framework. The consistent flow control problem is defined as follows: when the CE updates flow table in multiple FEs, each data packet flowing through the network must be processed according to a single network control configuration, either the old control configuration or the new control configuration, but not a mixture of both configurations, or other uncertain rules. 5. Inter-FE Consistent Control Scheme Frame To address the inter-FE consistent control problem, this section introduces the frame of dynamic match-field selection based inter-FE Zeng Expires November 18, 2014 [Page 5] Internet-Draft ForCES inter-FE Consistent Control Scheme May 2014 consistent control scheme. This scheme can be divided into three stages: preprocessing phase, transitional phase, and update phase. o Preprocessing Phase (PP) In the preprocessing phase, CE analyzes both the old and the new rules. According to the analytical result as well as the global flow table information, CE dynamically selects one (e.g. A0) or more match fields (e.g. A01+A02), and then dynamically selects one specific (Z) or more special addresses (a01+a02). o Transitional phase (TP) In the transitional phase, based on the preprocessing results from PP, CE generates a set of transitional flow entries by utilizing the selected special addresses. It is notable that the transitional flow entries act the same data processing functions with the new rules. After that, CE deletes the old flow entries belonging to the old rules. o Update phase (UP) In the update phase, CE writes the new flow entries belong to the new rules into the corresponding FEs, and then deletes the transitional flow entries generated in TP. After these three phases are finished, the inter-FE consistent control will be achieved. The next three sections depict these three phases respectively. 6. Preprocessing Phase (PP) This section details the processing procedure in the preprocessing Phase. It contains four steps. o Step PP-1 CE starts the inter-FE consistent control process. In the beginning, CE analyzes both the old and new rules. o Step PP-2 CE divides the FEs which needs to be written flow entries belonging to new rules into three groups: ingress FEs (FE-1), intermediate FEs (FE-2), egress FEs (FE-3). o Step PP-3 Zeng Expires November 18, 2014 [Page 6] Internet-Draft ForCES inter-FE Consistent Control Scheme May 2014 CE calculates the available value of each match field belonging to the new rules, and then dynamically selects one specific match field, denoted by A0. These specific match fields are named as available match fields. o Step PP-4 CE dynamically determines one specific address, denoted by Z from the unoccupied address in the available match field. 7. Transitional phase (TP) Without loss of generality, it is assumed that the flow entries belonging to the new rules adopt the match fields {A1,A2}, and the corresponding addresses are {a1,a2}. During PP, CE has determined that A0=A1, and the corresponding address is {Z,a2}. Then, the transitional phase consists of three steps. o Step TP-1 CE writes the transitional flow entries with Z+a2 as the match information. Then, CE writes the following flow entries into FE-3: IF packet header matches Z+a2, THEN change Z+a2--->a1+a2, and let FEs in FE-3 execute the corresponding data process. It is notable that the transitional flow entries correspond one-to-one with the new rules. o Step TP-2 CE writes the following flow entries into FE-1: IF packet header matches a1+a2, THEN change a1+a2--->Z+a2. Importantly, this kind of flow entries MUST possess the higher priority than a1+a2. In this case, FEs in FE-1 will process the packets by the transitional rules, and the old rules will no longer be used. o Step TP-3 CE waits an end-to-end latency in order to guarantee all the packets processed by the old rules have been processed completely. After that, CE deletes all the old flow entries in FE-1, FE-2, and FE-3. After the above steps, the transitional phase is finished. 8. Update phase (UP) The update phase replaces the transitional flow entries by the new rules. It contains three steps. Zeng Expires November 18, 2014 [Page 7] Internet-Draft ForCES inter-FE Consistent Control Scheme May 2014 o Step UP-1 CE writes the flow entries belonging to the new rules into FE-1, FE-2, and FE-3, i.e. a1+a2 as the match information. Importantly, this kind of flow entries MUST possess lower priority than the transitional flow entries: Z+a2. o Step UP-2 After all the flow entries in UP-1 have been written completely, CE deletes the all the transitional flow entries (Z+a2) in FE-1. After that, the packets will be processed by the new rules. o Step UP-3 CE waits an end-to-end latency in order to guarantee all the packets processed by the transitional rules have been processed completely. After that, CE deletes all the transitional flow entries in FE-1, FE- 2, and FE-3. After the above steps, the update phase is finished. Meanwhile, the inter-FE consistent control has been achieved. 9. Timing Diagram This section depicts the timing diagram of proposed inter-FE consistent control scheme, as shown in Figure 2. Zeng Expires November 18, 2014 [Page 8] Internet-Draft ForCES inter-FE Consistent Control Scheme May 2014 +---------------------------------------------------+ | | | | |Preprocessing Transitional Update phase | | Phase Phase Phase | | |<------>| |<------------>||<------------->| | | | | PP start TP-2 TP-3 UP-2 UP-3 | | * * * * * | | | | | | | | | | | | | | | | | t1 | t3 | t4 | t6 | | | ---*-----*---*---*---*-----*---*---*---*-------- | | t0 | t2 | t4 | t5 | t7 | | | | | | | | | | | | | | * * * * | | TP-1 end-to-end UP-1 end-to-end | | latency latency | | | | | +---------------------------------------------------+ Figure 2 Timing Diagram 10. Security Considerations This requirements document does not raise in itself any specific security issues. 11. IANA Considerations IANA does not need to take any action for this draft. 12. Conclusions Addressing the inter-FE consistent control problem for ForCES in SDN, this document introduces an inter-FE consistent control scheme through dynamic match-field selection. This scheme contains three phases, and guarantees the inter-FE consistent control. 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Zeng Expires November 18, 2014 [Page 9] Internet-Draft ForCES inter-FE Consistent Control Scheme May 2014 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, April 2004. [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, March 2010. 14. Acknowledgments This work is supported by Chinese National Major Scientific and Technological Specialized Project (No.~2013ZX03002001), National Basic Research Program of China (973 Program Grant No.~2013CB329105), China's Next Generation Internet (No.~CNGI-12-03-007), and ZTE Corporation. This document was prepared using 2-Word-v2.0.template.dot. Authors' Addresses Lieguang Zeng Department of Electronic Engineering, Tsinghua University Department of Electronic Engineering, Tsinghua University, Beijing, China Email: zenglg@mail.tsinghua.edu.cn Ye Zhou Department of Electronic Engineering, Tsinghua University Department of Electronic Engineering, Tsinghua University, Beijing, China Email: yepiero@gmail.com Mao Yang Department of Electronic Engineering, Tsinghua University Department of Electronic Engineering, Tsinghua University, Beijing, China Email: yangmao210@163.com Zeng Expires November 18, 2014 [Page 10] Internet-Draft ForCES inter-FE Consistent Control Scheme May 2014 Yong Li Department of Electronic Engineering, Tsinghua University Department of Electronic Engineering, Tsinghua University, Beijing, China Email: liyong07@tsinghua.edu.cn Depeng Jin Department of Electronic Engineering, Tsinghua University Department of Electronic Engineering, Tsinghua University, Beijing, China Email: jindp@mail.tsinghua.edu.cn Li Su Department of Electronic Engineering, Tsinghua University Department of Electronic Engineering, Tsinghua University, Beijing, China Email: lisu@tsinghua.edu.cn Zeng Expires November 18, 2014 [Page 11]