Common Control and Measurement Plane L. Zeng Internet Draft Tsinghua University Intended status: Informational June 10, 2014 Expires: December 2014 Common Joint Control of Middleboxes and Forwarding Elements draft-zeng-ccamp-joint-control-mid-fwd-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 10, 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 December 10, 2014 [Page 1] Internet-Draft Common Joint Control of Middleboxes and Forwarding Elements June 2014 Abstract Network services become increasingly multifarious. To efficiently guarantee the quality of services and fully utilize the network resources, network operators need to process the traffic flows through more fine-grained way. It is a promising way to deploy a series of middleboxes integrating various functions. However, this results in two challenges: 1) how to control such increasingly different middleboxes; 2) how can networks provide a common joint control scheme for both the middleboxes and forwarding elements. This document proposes a common joint scheme for middleboxes and forwarding elements. This scheme adopts logically centralized control method and utilizes standard control interfaces, which makes it flexible and efficient for the networks to determine the most optimizing path and the most appropriate functions in the middleboxes for traffic flows. It guarantees the quality of services and significantly improves resource utilization. Table of Contents 1. Introduction ................................................ 2 2. Conventions used in this document............................ 3 2.1. Requirements Language................................... 3 2.2. Definitions ............................................ 3 3. Joint Control Architecture................................... 4 4. Joint Control Strategy and Protocol.......................... 5 4.1. Protocol Frame ......................................... 5 4.2. FEs Control Protocol.................................... 6 4.3. G-Mids Control Protocol................................. 6 5. Flow Control ................................................ 7 6. Security Considerations...................................... 7 7. IANA Considerations ......................................... 7 8. Conclusions ................................................. 7 9. References .................................................. 8 9.1. Normative References.................................... 8 9.2. Informative References.................................. 8 10. Acknowledgments ............................................ 8 1. Introduction Network services become increasingly multifarious. To efficiently guarantee the quality of services and fully utilize the network resources, network operators need to process the traffic flows through more fine-grained way. It is a promising way to deploy a series of middleboxes integrating various functions, such as firewall, Zeng Expires December 10, 2014 [Page 2] Internet-Draft Common Joint Control of Middleboxes and Forwarding Elements June 2014 IDS, and proxy. In current networks, one middlebox always implements just one specific function. Given that different network services call for quite different data process functions middleboxes deployed in the networks are extremely heterogeneous, makes it inflexible to control. Therefore, two solutions emerge and have captured increasing attentions: 1) integrate multiple functions in one middlebox, named general middlebox (G-Mid); 2) G-Mid is controlled and configured by a centralized monitor through software defining. This document introduces the fundamental problem of G-Mid: how to achieve joint control of G-Mid and forwarding elements. 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 The definitions of this document are summarized as follows: General Middlebox (G-Mid) - A type of middlebox that implements multiple network functions based on one general architecture. The specific function is controlled and configured by one centralized control element through software defining. Forwarding Element (FE) - A logical entity that implements the control protocols. FEs use the underlying hardware to provide per- packet processing and handling as directed/controlled by the centralized control element through software defining. Joint Control Element (JCE) - A network element that takes charge of joint controlling and configuring both FEs and G-Mids via software defining. On one hand, JCE configures the function and the parameters of both FEs and G-Mid; On the other hand, it possesses the global information, which makes it possible to dynamically optimize the whole network via software-defined centralized control. Zeng Expires December 10, 2014 [Page 3] Internet-Draft Common Joint Control of Middleboxes and Forwarding Elements June 2014 Joint Control Protocol (JCP) - Joint control protocol indicates the detailed control strategy which is implemented via software and followed by JCE, FEs and G-Mids. 3. Joint Control Architecture A logical view of the joint control architecture is shown in Figure 1, which consists of three types of elements: joint control element (JCE), general middleboxes (G-Mids) and forwarding elements (FEs). +--------------------------------------------------------------+ | | | +---------------------------------------------------------+ | | | +--------------------------------------+ | | | | Joint +--+ Optimizing and Determination Layer +--+ | | | | Control | +------+------------------------+------+ | | | | | Element | | | | | | | | (JCE) | |Global Information Layer| | | | | | | +------+----------+ +---------+------+ | | | | | | |Function Database| |Network Database| | | | | | | +------+----------+ +--------+-------+ | | | | | | | | | | | | | | | Control Ability Layer | | | | | | | +------+----------+ +--------+-------+ | | | | | +--+ G-Mid Control | | FE Control +--+ | | | | ++-----+------+---+ +----+-----+----++ | | | +--------------|-----|------|------------|-----|----|-----+ | | | | |Joint Contrl|Protocol | | | | | | | | | | | +--------+-+ | +----+-----+ +--+---+ | +-+----+ | | |Function A| | |Function B| | FE ****** FE | | | +----------+ | +----------+ +---*--+ | +--*---+ | | G-Mid | G-Mid * | * | | | * | * | | +----*-----+ +*-+--*+ | | |Function C| | FE | | | +----------+ +------+ | | G-Mid | | | +--------------------------------------------------------------+ Figure 1 Joint Control Architecture JCE contains three layer: control ability layer, global information layer, and the optimizing and determination layer. The control ability layer is comprised of G-Mid control module and FE control Zeng Expires December 10, 2014 [Page 4] Internet-Draft Common Joint Control of Middleboxes and Forwarding Elements June 2014 module. They provide lots of control functions. For example, the G- Mid control module may offer functions such as setting the function of one G-Mid, configuring the parameters of one G-Mid, and etc. While, the FE control module may possess the functions such as setting the forwarding rules, adjusting the priority of rules, and etc. The control ability layer is the cornerstones of JCE since all the optimization and the determination are implemented by these abilities. The global information layer consists of two databases: the function database and the network database. The information in function database includes the function sets of each G-Mid, the current function running in each G-Mid, the parameter of each G-Mid, and etc. The network database reflects the network features, e.g. network topology, the forwarding rules of each FE, the priorities of forwarding rules in each FE, and etc. Without this global information, it is impossible for the optimizing and determination layer to make the most appropriate determination. The optimizing and determination layer is the control center of JCE. Normally, after accessing two databases in the global information layer, the optimizing and determination layer optimizes and makes the determination from the global perspective, and then it sends the corresponding rules to the G-Mids and FEs via control ability layer. This joint control architecture provides a centralized method to jointly control both of the G-Mids and FEs. Therefore, it is convenient to optimize the network and significantly improves resource utilization. 4. Joint Control Strategy and Protocol This section addresses the problem that how to efficiently control both the G-Mids and FEs. 4.1. Protocol Frame The joint control protocol in this architecture follows match-action strategy. After optimizing and determining, the JCE makes the rules of G-Mids and FEs and sends these rules to them via standard interfaces. In each network element, including G-Mid and FE, there exists a flow table to store flow entries sent by the controller. After receiving the rules, G-Mids and FEs will generate or update their flow tables. When data packets arrive at any G-Mid or FE, match-field in the packet headers will be checked. If match-field matches the flow entries, the data packets will be processed according to the corresponding rules and actions. Otherwise, these Zeng Expires December 10, 2014 [Page 5] Internet-Draft Common Joint Control of Middleboxes and Forwarding Elements June 2014 packets SHOULD be dropped or sent to the JCE. This match-action strategy based protocol applies to both of G-Mid and FE. But, given that the functions of G-Mid and FE are quite different, the next two subsections illustrate them respectively. 4.2. FEs Control Protocol The proposed architecture directly adopts the SDN (Software-defined Network) protocol, e.g. OpenFlow, to control FEs. The JCE uses flow entries to control multiple FEs, where the forwarding function is executed. The controller can add/delete/modify flow entries to each FE. Reference [CCAMP-SDN] depicts the detailed SDN protocol. 4.3. G-Mids Control Protocol The G-Mids control abstraction is shown in Figure 2. +------------------------------------------------------+ | | | +-----------+-------------+---------+---------+ | | |MID-FUNC-ID|MID-FUNC-NAME|CTRL-LIST|PAPA-LIST| | | |-----------+-------------+---------+---------+ | | | +------------------------------------------------------+ Figure 2 G-MID Control Abstract The MID-FUNC-ID field refers to the function ID in each middlebox. MID-FUNC-ID is the unique identification being used to distinguish different functions. For example, firewall, IDS, and Proxy functions MUST have different MID-FUNC-ID. It is notable that one G-MID may integrate several functions, and the JCE may guide different data packets to be processed by different functions. The MID-FUNC-NAME field depicts the function, which corresponds to MID-FUNC-ID. The CTRL-LIST field refers to the current state of each function such as active, available, sleep, deleted, and etc. Active means this function is configured as a part of process for at least one table entry; Available means this function is available but not used now, but it may turn to active state immediately by easily sending some control message; Sleep means this function can be used only after installing; Deleted means this function ever emerged but no longer exists. Zeng Expires December 10, 2014 [Page 6] Internet-Draft Common Joint Control of Middleboxes and Forwarding Elements June 2014 The PAPA-LIST field contains a series of parameters required by different functions. Different functions may have quite different parameters. Similar as FE control, G-Mid control also utilizes the math-action strategy. All the actions in FEs are related to forwarding features, while the actions in G-Mids are different network functions by calling functions through G-MID control abstract in Figure 2. 5. Flow Control This section introduces the network flow control process. o Stage 1: Calculate the path When one network flow comes, the JCE SHOULD calculate and optimizing the path of this flow. It contains two items: 1) calculate the forwarding path that the flow goes through; 2) optimize the functions of G-Mids which are necessary along the path. o Stage 2: Configure the G-Mids In this stage, the JCE SHOULD configure the functions in each G-Mid. o Stage 3: Configure the G-Mids and send rules&action In this stage, the JCE SHOULD configure FEs and send the rules and actions to each G-Mid and FE. After these three phases are finished, the network is able to deploy this network flow. 6. Security Considerations This requirements document does not raise in itself any specific security issues. 7. IANA Considerations IANA does not need to take any action for this draft. 8. Conclusions This document proposes a common joint scheme for middleboxes and forwarding elements. This scheme adopts logically centralized control method and utilizes standard control interfaces, which makes it Zeng Expires December 10, 2014 [Page 7] Internet-Draft Common Joint Control of Middleboxes and Forwarding Elements June 2014 flexible and efficient for the networks to determine the most optimizing path and the most appropriate functions in the middleboxes for traffic flows. It guarantees the quality of services and significantly improves resource utilization. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [CCAMP-SDN] McKeown N, Anderson T, Balakrishnan H, et al, "OpenFlow: enabling innovation in campus networks", ACM SIGCOMM Computer Communication Review, 2008, 38(2): 69-74. 10. 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. Zeng Expires December 10, 2014 [Page 8] Internet-Draft Common Joint Control of Middleboxes and Forwarding Elements June 2014 Authors' Addresses Lieguang Zeng Department of Electronic Engineering, Tsinghua University Department of Electronic Engineering, Tsinghua University, Beijing, China Email: zenglg@mail.tsinghua.edu.cn Jiaqiang Liu Department of Electronic Engineering, Tsinghua University Department of Electronic Engineering, Tsinghua University, Beijing, China Email: nxjql@126.com Mao Yang Department of Electronic Engineering, Tsinghua University Department of Electronic Engineering, Tsinghua University, Beijing, China Email: yangmao210@163.com 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 December 10, 2014 [Page 9]