forces Z. Wang Internet Draft Tsinghua University Intended status: Informational T. Tsou Expires: September 2012 J. Huang Huawei X. Shi X. Yin Tsinghua University March 11, 2012 Analysis of Comparisons between OpenFlow and ForCES draft-wang-forces-compare-openflow-forces-01.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 September 11, 2012. Copyright Notice Copyright (c) 2012 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. Wang, et al. Expires September 11, 2012 [Page 1] Internet-Draft OpenFlow vs. ForCES March 2012 Abstract While both ForCES and OpenFlow follow the basic idea of separations of forwarding plane and control plane in network elements, they have some technical differences. This document analyzes the differences between OpenFlow and ForCES technically from the aspects of goals, architecture, forwarding model and protocol interface. The two techniques can learn much from each other in their standardization process. Table of Contents 1. Introduction ................................................ 2 2. Definitions used in this document............................ 3 3. Comparisons between ForCES and OpenFlow...................... 4 3.1. Comparisons in Goals.................................... 5 3.2. Comparisons in Architecture............................. 5 3.3. Comparisons in Forwarding Model......................... 8 3.4. Comparisons in Protocol Interface....................... 9 4. Security Considerations..................................... 10 5. IANA Considerations ........................................ 10 6. Conclusions ................................................ 10 7. References ................................................. 11 7.1. Normative References................................... 11 7.2. Informative References................................. 11 8. Acknowledgments ............................................ 12 1. Introduction ForCES (Forwarding and Control Element Separation) [RFC5810] defines a framework and associated protocols to standardize information exchange between the control and forwarding plane in a ForCES network element (NE). OpenFlow [McKeown2008][OpenFlow1.2] is a concrete implementation of some components of so-called SDN (Software-Defined Networking), including forwarding plane abstraction (i.e., OpenFlow switches) and the standard protocol between forwarding plane and control plane (i.e., controller). In network elements, i.e., OpenFlow switches, control plane has been separated from forwarding plane and only forwarding plane is retained. The centralized controller is used to control the behavior of OpenFlow switches by adding, updating and deleting flow table entries in switches. ONF (Open Networking Foundation, Website: https://www.opennetworking.org/) has been founded in March of 2011 to promote the SDN, and especially Wang, et al. Expires September 11, 2012 [Page 2] Internet-Draft OpenFlow vs. ForCES March 2012 Standardize OpenFlow protocol. The latest version of OpenFlow switch specification is 1.2 [OpenFlow1.2]. Both ForCES and OpenFlow follow the basic idea of forwarding plane and control plane separation in network elements, and result in the new architecture of network devices, e.g., routers and switches. However, they are technically different in many aspects. It is necessary to compare the two techniques so that they can learn much from each other. This document gives an initial analysis of the differences and similarities between ForCES and OpenFlow from design goals, architecture, forwarding model and protocol interface. 2. Definitions 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 RFC-2119 [RFC2119]. The following definitions related to ForCES and relevant to this document are taken from [RFC3654][RFC3746][RFC5810]. 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 by a CE via the ForCES Protocol. 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. ForCES Network Element (NE) - An entity composed of one or more CEs and one or more FEs. An NE usually hides its internal organization from external entities and represents a single point of management to entities outside the NE. ForCES Protocol - While there may be multiple protocols used within the overall ForCES architecture, the term "ForCES protocol" refers 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 Protocol Layer (ForCES PL) - A layer in the ForCES protocol architecture that defines the ForCES protocol messages, the protocol state transfer scheme, and the ForCES protocol architecture itself Wang, et al. Expires September 11, 2012 [Page 3] Internet-Draft OpenFlow vs. ForCES March 2012 (including requirements of ForCES TML as shown below). Specifications of ForCES PL are defined by [RFC5810]. ForCES Protocol Transport Mapping Layer (ForCES TML) - A layer in ForCES protocol architecture that uses the capabilities of existing transport protocols to specifically address protocol message transportation issues, such as how the protocol messages are mapped to different transport media (like TCP, IP, ATM, Ethernet, etc.), and how to achieve and implement reliability, multicast, ordering, etc. The ForCES TML specifications are detailed in separate ForCES documents, one for each TML. LFB (Logical Function Block) - The basic building block that is operated on by the ForCES protocol. The LFB is a well-defined, logically separable functional block that resides in an FE and is controlled by the CE via the ForCES protocol. The LFB may reside at the FE's data path and process packets or may be purely an FE control or configuration entity that is operated on by the CE. Note that the LFB is a functionally accurate abstraction of the FE's processing capabilities, but not a hardware-accurate representation of the FE implementation. LFB Class and LFB Instance - LFBs are categorized by LFB classes. An LFB instance represents an LFB class (or type) existence. There may be multiple instances of the same LFB class (or type) in an FE. An LFB class is represented by an LFB class ID, and an LFB instance is represented by an LFB instance ID. As a result, an LFB class ID associated with an LFB instance ID uniquely specifies an LFB existence. 3. Comparisons between ForCES and OpenFlow ForCES and OpenFlow are very similar in the following aspects: o Both ForCES and OpenFlow are efforts to separate control plane from forwarding plane; o Both ForCES and OpenFlow protocols standardize information exchange between the control and forwarding plane. Although both ForCES and OpenFlow can be considered as the solutions for forwarding and control plane separation, they are different in many aspects. This section compares them in their goals, architecture, forwarding model and protocol interface. Wang, et al. Expires September 11, 2012 [Page 4] Internet-Draft OpenFlow vs. ForCES March 2012 3.1. Comparisons in Goals The goal of ForCES is to break the closed box of network elements. After separation of forwarding elements and control elements, it is natural to define the standard, open communication interface between the two kinds of elements. By using ForCES, the two kinds of functional elements can be developed independently, provided both of them implement the standard ForCES protocol. In this way, innovations of network devices can be speeded up. In ForCES, there are two kinds of physical separations: blade level and box level [RFC3746]. In blade level, current network devices, e.g., routers, use proprietary interfaces for communication between CEs and FEs, so "the goal of ForCES is to replace such proprietary interfaces with a standard protocol" [RFC3746]. In box level, the CEs and FEs in one NE can be in physically separated boxes, all of which form one network element together. The basic idea of OpenFlow is also separation of control plane and forwarding plane. But the goal of OpenFlow is beyond the new architecture of network devices. In the view of ONF, OpenFlow is a concrete implementation of some components that can be used to build SDN, and the goal is to separate control plane from network devices and use a logically centralized controller to act as the control plane of the whole network. The controller can provide open APIs for users to add new features in the form of applications running on the controller. Such a separation simplifies the control functions and speeds up innovations in the network. That is just the idea of software defined networking. OpenFlow provides the standard protocol between OpenFlow controller and OpenFlow switches. 3.2. Comparisons in Architecture ForCES proposes a new architecture for network devices (NEs). It separates control plane and forwarding plane in one network element and allows multiple instances of CEs and FEs inside one NE. ForCES protocol defines the standard communication interface between CEs and FEs. But in ForCES, network architecture remains unchanged [RFC3746]: o The interfaces between two ForCES NEs are identical to the interfaces between two conventional routers; o ForCES NEs can connect to existing routers transparently; o ForCES still uses distributed protocols for control functions, e.g., routing protocols. Wang, et al. Expires September 11, 2012 [Page 5] Internet-Draft OpenFlow vs. ForCES March 2012 Figure 1 shows ForCES Architectural Diagram [RFC5810]. --------------------------------------- | ForCES Network Element | -------------- Fc | -------------- -------------- | | CE Manager |---------+-| CE 1 |------| CE 2 | | -------------- | | | Fr | | | | | -------------- -------------- | | Fl | | | Fp / | | | Fp| |----------| / | | | | |/ | | | | | | | | | Fp /|----| | | | | /--------/ | | -------------- Ff | -------------- -------------- | | FE Manager |---------+-| FE 1 | Fi | FE 2 | | -------------- | | |------| | | | -------------- -------------- | | | | | | | | | | | ----+--+--+--+----------+--+--+--+----- | | | | | | | | | | | | | | | | Fi/f Fi/f Fp: CE-FE interface Fi: FE-FE interface Fr: CE-CE interface Fc: Interface between the CE manager and a CE Ff: Interface between the FE manager and an FE Fl: Interface between the CE manager and the FE manager Fi/f: FE external interface Figure 1: ForCES Architectural Diagram [RFC5810] Compared to ForCES, OpenFlow aims to change the architecture of both network devices and even network itself. OpenFlow switch specification [OpenFlow1.2] defines two types of OpenFlow switches: OpenFlow-Only, and OpenFlow-hybrid. OpenFlow-hybrid switches support both OpenFlow switch specification and normal Ethernet switch functionality. To use OpenFlow-only switch, the current Internet architecture will be different. In "pure" OpenFlow, network elements (OpenFlow-only Switches) only retain forwarding plane to forward packets by using flow tables, and provide open interfaces to the logically centralized controller. There is no need to run control functions such as routing protocols, signaling protocols, etc., in OpenFlow-only switches. The logically centralized controller serves as the control plane in OpenFlow networking. It will Wang, et al. Expires September 11, 2012 [Page 6] Internet-Draft OpenFlow vs. ForCES March 2012 o Collect the network view and make decisions according to control logics (or applications); o Interact with OpenFlow switches to install their flow tables; o Provide open APIs to users, and users can program by using these APIs to implement new applications. Using the terms NEs (Network Elements), FEs (Forwarding Elements) and CEs (Control Elements), the "pure" OpenFlow architectural diagram can be shown in Figure 2. In this architecture, it should be noted that here NE is not the same concept in ForCES and we just borrow the term from ForCES, rather it means a network element (device) located in the network to forward data packets, i.e., OpenFlow-only switches, which act as both FEs and NEs. The OpenFlow controllers can be centralized or distributed with multiple ones, which form the CEs in OpenFlow networking, although in most of current deployments, only one controller is used. Wang, et al. Expires September 11, 2012 [Page 7] Internet-Draft OpenFlow vs. ForCES March 2012 ---------------- ---------------- | Application1 | | Application2 | ...... ---------------- ---------------- | APIs | ---------------------------------------- CE | --------------- --------------- | | | OpenFlow |------| OpenFlow | | | | Controller | | Controller | | | --------------- --------------- | ---------------------------------------- | | | | OpenFlow Protocol | | | | NE&FE | | | NE&FE -------------- | -------------- | OpenFlow | | | OpenFlow | | Switch | | | Switch | -------------- | -------------- | | | | | | | | | | | | | | | | | | | | | | | | | | | Fi/f | NE&FE | | Fi/f | -------------- | | | OpenFlow | | | | Switch | | | -------------- | | | | | | | | | | | | | -------- | | -------- Fi/f Fi/f: FE external interface Figure 2: "Pure" OpenFlow Architectural Diagram by Using the terms NEs, FEs, CEs 3.3. Comparisons in Forwarding Model In ForCES, [RFC5812] defines the FE (Forwarding Element) model based on an abstraction of Logical Functional Blocks (LFBs). In this model, each FE is composed of multiple LFBs that are interconnected in a directed graph, which is represented by the LFB topology model. Each LFB defines a single action of how to handle the passing packets. For example, typical LFBs include IPv4/IPv6 Longest Prefix Matching, etc. XML is used to describe LFB model formally. Wang, et al. Expires September 11, 2012 [Page 8] Internet-Draft OpenFlow vs. ForCES March 2012 In current version of OpenFlow, the forwarding model is abstract to flow table manipulations. The current OpenFlow specification (version 1.1.0) [OpenFlow1.1] defines multiple flow tables structure in one OpenFlow Switch. Each flow entry contains three parts: match fields, counters and a set of instructions. Match fields are used to match packets. Counters are used for statistics of matching packets. If a packet is matched, it will be processed according to the instructions of the corresponding flow entry. In OpenFlow networking, the controller controls the behavior of OpenFlow switches by adding, updating and deleting flow table entries in switches. OpenFlow switches process packets in the granularity of "flow": Match fields contained in each flow entry, such as, Ethernet source/destination addresses, IPv4 source/destination addresses, TCP/UDP source/destination ports, etc. In the current OpenFlow version, the possible actions can be output (which means forwarding a packet to a specified port), Set-Queue (which is used for Quality-of- Service support), Set-field, Push-Tag/Pop-Tag, Drop, etc. By associating various actions in a given order with each flow, OpenFlow controller can control the behavior of OpenFlow networking flexibly. However, in ForCES, the combination of multiple LFB instances with specified topology forms each FE. [LFB-Lib] has defined various LFB classes in LFBs base library, which can be used to implement functions of the current network devices. Compared to ForCES, in OpenFlow, it is more difficult to implement some current typical network functions in OpenFlow. OpenFlow can learn from ForCES to predefine some functional blocks to simplify the implementation of its applications. In fact, OpenFlow-Future working group in ONF is working for providing a more generic forwarding model and something similar with LFBs in the future version of OpenFlow. On the other hand, by using ForCES architecture, one can also define LFBs whose functions are similar with flow tables in OpenFlow, which reflects the flexibility of ForCES forwarding model. 3.4. Comparisons in Protocol Interface ForCES defines two layers of protocols: ForCES Protocol Layer (ForCES PL) and ForCES Protocol Transport Mapping Layer (ForCES TML). ForCES PL defines Protocol between FEs and CEs (Fp Reference Point). ForCES Protocol Transport Mapping Layer (ForCES TML) is defined to transport the PL messages. It is expected that more than one TML will be standardized and interoperability is guaranteed as long as both endpoints support the same TML. [RFC5811] has defined a SCTP-based TML for ForCES. This means that there will be various standard ForCES TML protocols with different weights, heavy or light, and vendors can choose an appropriate one from them. Wang, et al. Expires September 11, 2012 [Page 9] Internet-Draft OpenFlow vs. ForCES March 2012 OpenFlow defines the protocol between controller and OpenFlow switches, i.e. OpenFlow protocol. Like ForCES, OpenFlow protocols also use TLVs (Type-Length-Value structure) formats for message encapsulation. For massage transportation, OpenFlow controller and switches communicate through a TLS/SSL connection or a TCP connection in the current version. ForCES has longer history and is more mature than OpenFlow. OpenFlow can learn much from the protocol standardization of ForCES, for example: o Defining Capabilities negotiation and configuration mechanism, just as ForCES can do by using LFBs, which is the OF-config and OpenFlow-Future working group in ONF is trying to do; o Defining Protocol Transport Mapping Layer to allow various standard transportation protocols. 4. Security Considerations TBD 5. IANA Considerations No IANA considerations. 6. Conclusions Both ForCES and OpenFlow follow the basic idea of separations of forwarding plane and control plane in network elements. This document gives an initial analysis of the comparisons between OpenFlow and ForCES technically from the aspects of goals, architecture, forwarding model and protocol interface. From goals and architecture, OpenFlow has some differences than ForCES. ForCES results in a new architecture of network devices, while "pure" OpenFlow aims to result in a new NETWORK architecture. In forwarding model and protocol interface, ForCES and OpenFlow are similar, but from the point of view of protocol standardization, ForCES are more mature and well- defined. OpenFlow can learn much from ForCES protocol in its standardization process. At last, we can point out the potentials of ForCES protocol in SDN. Although ForCES is not designed for SDN, perhaps it can also be used to design a new protocol in SDN, because it is a well-defined communication protocol between CEs and FEs. Wang, et al. Expires September 11, 2012 [Page 10] Internet-Draft OpenFlow vs. ForCES March 2012 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", RFC 5812, March 2010. [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol", RFC 5811, March 2010. 7.2. Informative References [McKeown2008] McKeown, N., Anderson, T., Balakrishnan, H., et al, "Openflow: enabling innovation in campus networks", ACM SIGCOMM Computer Communication Review. 2008, 38(2):69-74. [OpenFlow1.2] OpenFlow Switch Specification Version 1.2 (Wire Protocol 0x03). December 5, 2011. (https://www.opennetworking.org/images/stories/downloads/op enflow/openflow-spec-v1.2.pdf) [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation of IP Control and Forwarding", RFC 3654, November 2003. [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, April 2004. [LFB-Lib] Wang W., Haleplidis E., Ogawa K., Li C., J. Halpern, "ForCES Logical Function Block (LFB) Library", draft-ietf- forces-lfb-lib-08, Work in Progress. Wang, et al. Expires September 11, 2012 [Page 11] Internet-Draft OpenFlow vs. ForCES March 2012 8. Acknowledgments The authors would like to thank Susan Hares, who inspired us to write a Draft to indicate how ForCES compares with OpenFlow. Wang, et al. Expires September 11, 2012 [Page 12] Internet-Draft OpenFlow vs. ForCES March 2012 Authors' Addresses Zhiliang Wang Network Research Center, Tsinghua University Beijing 100084 P. R. China Email: wzl@csnet1.cs.tsinghua.edu.cn Tina Tsou (Ting Zou) Huawei Technologies (USA) 2330 Central Expressway Santa Clara, CA 95050 USA Email: Tina.Tsou.Zouting@huawei.com Jing Huang Huawei Email: james.huang@huawei.com Xingang Shi Network Research Center, Tsinghua University Beijing 100084 P. R. China Email: shixg@csnet1.cs.tsinghua.edu.cn Xia Yin Department of Computer Science and Technology Tsinghua University Beijing 100084 P. R. China Email: yxia@csnet1.cs.tsinghua.edu.cn Wang, et al. Expires September 11, 2012 [Page 13]