Internet DRAFT - draft-wang-forces-compare-openflow-forces
draft-wang-forces-compare-openflow-forces
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]
