[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
Internet Draft                                                  S.Hares
Intended status: Informational                                   Huawei
Expires: January 6, 2013
                                                           July 6, 2012


          Analysis of Comparisons between OpenFlow and ForCES
                 draft-hares-forces-vs-openflow-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 January 6, 2013.

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.

Abstract





Hares                   Expires March 12, 2013                 [Page 1]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


   While both ForCES and OpenFlow follow the basic idea of
   separations of forwarding plane and control plane in network
   elements, they are technically different. ForCES specification
   contains both a modeling language [RFC5812] which allows flexible
   definition of the Flow tables and flow logic. ForCES flow logic
   include Logical Functional Blocks (LFBs) connected in flow logic
   that is described in logic of direct graphs augmented by passage
   of Metadata and grouping concepts.

   OpenFlow's specifications contain a specific instantiation of
   Flow tables and flow logic which has emerged from the research
   community theories.  OpenFlow's logic varies based on the
   revision of the specification (OpenFlow-Paper [McKeown2008],
   OpenFlow Switch Specification 1.0 [OpenFlow1-0], OpenFlow 1.1
   [OpenFlow-1.1] Open Configuration 1.0 [OpenFlowConfig-1.0]).

Table of Contents


   1. Introduction...................................................3
      1.1. ForcES Introduction.......................................4
      1.2. OpenFlow Introduction.....................................4
   2. Definitions....................................................5
      2.1. New Common Configurations.................................6
      2.2. Forces Definitions........................................8
      2.3. Open Flow Definitions....................................10
   3. Comparisons between ForCES and OpenFlow.......................12
      3.1. Difference in Historical setting.........................12
      3.2. Difference in Goals......................................14
      3.3. Difference in Architectural Requirements.................14
         3.3.1. ForCES System Building Blocks.......................15
         3.3.2. OpenFlow Building blocks............................17
            3.3.2.1. Match Fields in OFS............................18
            3.3.2.2. Flow Logic - Flow Table and Group tables.......18
         3.3.3. ForCES FE types.....................................22
         ForCES and OpenFlow FEs can operate either new switching
         entities or integrated with existing processing as a hybrid.
         In OFS-1.2, the Ships-in-the-Night (SIN) mode divides
         existing ports into groups controlled by specific ports
         (see figure x) or VLANs (figure-x).........................22
         3.3.4. ForCES Pre-Association..............................23
         3.3.5. Architectural requirements..........................25
         3.3.6. ForCES versus OpenFlow - A Central Controller.......33
      3.4. Difference in Forwarding Model...........................33
         3.4.1. Looping.............................................34
         3.4.2. Handling unicast and multicast......................35
      3.5. Difference in Logical Forwarding Block Libraries.........36


Hares, et al.          Expires November, 6 2012                [Page 2]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


      3.6. Difference in Protocol Interface.........................36
         3.6.1    Secure Transport..................................37
   4. Use of ForCES and OFS in Applications.........................41
   5. The use of ForCES or OpenFlow in S(D)N or CSO/SOP.............41
   6. Security Considerations.......................................42
   7. IANA Considerations...........................................42
   8. Conclusions...................................................42
   9. References....................................................43
      9.1. Normative References.....................................43
      9.2. Informative References...................................43
   10. Acknowledgments..............................................44

1. Introduction

   This document analyzes the differences between OpenFlow and
   ForCES technically from the aspects of goals, architecture,
   forwarding models, forwarding policy, control plane interaction,
   configuration of nodes, and applications (firewalls, load-
   balancers, High-availability nodes). This informational document
   compares OpenFlow and Forces as of March, 2012 seeking to provide
   clarity for other discussions of controller/forwarding split,
   Software Defined Networking, Software Driven Networking, Cloud
   Service Oriented networking (CSO), and a host of orchestrators
   for virtualized network devices.

   A fellow Engineer provided inspiration for this deeper comparison
   by saying: "OpenFlow-0 is the Diff-Serv Tspec, OpenFlow-1.0 is
   Forces--, and OpenFlow 1.1 is Forces++." Jamal Salim suggests
   Open Flow 1.1 does not have the same functionality[Jamal-01].

   While this summary brings the expert listener quickly into heart
   of the issues, this document examines:

   -  Is OpenFlow Switch 1.1.0 really "ForCES++", and "is the group
     table safe ++ logic? What direction does Open Flow Switch 1.2
     and 1.3 take us?

   -  Where does Open Flow's Config fit in the picture?

   -  How does this help us get to Clouds Service Oriented Networks
     (CSO) enable by Software defined networks (SDN) or software
     driven networks (SDN)?

   And that, as the saying goes is the "rest of the story" of this
   draft.  Here's hoping the readers of this document will decide
   and argue with the author to refine the next-generation of
   hardware devices.


Hares, et al.          Expires November, 6 2012                [Page 3]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


1.1. ForcES Introduction

   ForCES (Forwarding and Control Element Separation) work in IETF
   has defined a new environment to build network devices that split
   the network devices into control plane and forwarding plane into
   units. For example, a router could be considered a network
   element (NE) with a control plane running router protocol and a
   data plane forwarding IP traffic.

   The drive to have ForCES NE device split arose from the desire to
   build hardware forwarding blades out of flexible hardware
   components. These hardware devices included Network Processors
   and network specific ASICs.

   The ForCES environment defines requirements [RFC3654], goals
   [RFC3565], architecture and protocol requirements [RFC3654], a
   controller-forwarder communication protocol [RFC 5810]. ForCES
   also describes a policy on how to building the forwarding engine
   out of a set of logical functional blocks (LFBs)which are
   connected as a directed graph [RFC5812]. ForCES allows many
   different Forwarding Engines (FE) to linked to Controller Engines
   (CE) via the protocols. ForCES provides a modeling language [RFC-
   5812] to describe these FE devices so that controllers can load
   control the devices, load forwarding tables, and keep track of
   statistics. ForCES RFCs also define how the ForCES protocol runs
   over SCTP [RFC5811.

1.2. OpenFlow Introduction

   OpenFlow[McKeown2001, p. 1]] arose out of the frustration that
   network research projects felt at not being able to experiment
   with new protocols on large-scale networks. Experimentation on
   research networks did not have a large enough scale to provide a
   reasonable test-bed for new research ideas for the Internet. Pure
   commercial networks would not allow experimental protocols, and
   commercial router vendors took 3-5 years to create a new protocol
   features. The OpenFlow researchers suggested an alternative to
   allow the research to creating a slice out of commercial network
   to try out new ideas for network.

   OpenFlow's initial paper grew into OpenFlow Switch Specification
   versions 1.0 [OFS-1.0], 1.1 [OFS-1.1], 1.2[OFS-1.2], 1.3[OFS-1.3],
   and (likely) 1.4 [OFS-1.4]. Additionally a Config and Management
   Protocol version 1.0[OFC-1.0] and version 1.1 [OFC-1.1], and a
   set of papers and application notes on implementations.  A hybrid
   Specification [OFHy-1.0] suggests how Open Flow may be combined
   with existing network OpenFlow switches which mix existing


Hares, et al.          Expires November, 6 2012                [Page 4]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


   network devices (routers/switches) with OpenFlow controlled
   switches in either a Ships-in-the Night (SIN) or a hybrid model

   OpenFlow's host of specifications and ForCES flexible
   reprogramming of the network element architecture can be
   considered the first wave of Software-Defined Networking (SDfN)
   where software can alter how the forwarding engine's logic
   operates. This work arises out of the GENI research
   [GENI][McKeown2008]. The current industry discussion regarding
   Software-Defined Networking (SDfN) or Software-Driven Networking
   (SDrN), Network Virtualized Overlays [NVO3], Service-Oriented
   Protocols (SoP)[SoP] or network orchestrators of Cloud Service
   Oriented Network (CSO)forwarding [CSO-Arch] have a great deal
   confusions as they apply the terms to ForCES and OpenFlow. Rather
   than carefully define each of these terms explicitly at the
   outset, we will give brief expansions of the abbreviations and
   return to the definitions later in the draft after examining the
   FORCES draft.

   This document will examine ForCES and OpenFlow goals,
   architecture, forwarding conceptual models, Controller-forwarder
   communication mechanisms and protocols, the policies in the
   loading of forwarding state, configurations of nodes, and sanity
   checking of the forwarding.

   These basic concepts will be then examined in terms of specific
   implementations (switch, hybrid router/switch, wireless, load-
   balancer, firewall) as described by ForCES and OpenFlow reports.

   Finally, the document will return to defining S[*]N, SOP, and
   Cloud-Oriented Services (CSO).

2.  Definitions

   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 RFC2119 definitions used in this document are:

   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].


Hares, et al.          Expires November, 6 2012                [Page 5]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


   ForCES definitions relevant to this documents discussion are
   taken from [RFC3654][RFC3746][RFC5810] as noted below. The quoted
   italized definitions come from the ForCES RFC, and the non-quoted
   text applies ForCES RFC text to this document.

2.1. New Common Configurations

   Controlling Entity (CE): is defined as an entity which remote
   controls the forwarding engine. This Entity can be either a
   ForCES CE or a Open Flow Controller.

   Controlling Entity Manager (CE-MGR): This documents loosens the
   ForCES CE-Manager definition to allow Open Flow and ForCES to be
   compared. This document defines the CE manager as a logical
   entity (distributed or located in physical or virtual device)
   which controls which controllers attach to which logical
   Forwarding Entities.  The Controllers can be in the same physical
   switch/device in the control plane or other logical software. A
   CE-Mgr may also be within a VM hypervisor, a VM hypervisor
   manager, or other virtual software. The CE-Mgr logical function
   may be distributed across many CE as a defined function. This
   definitional Allows both ForCES CE-Mgrs and Open Flow Controller
   collaboration/management via coordinated remote configuration of
   OF Capable Switches.

   Controlled Router-Switch (CRSW): A Controlled Switch is a network
   entity performing switching capability that is controlled by
   remotely by either the ForCES protocol (FP) or the Open Flow
   Protocol (OFP). This switch can perform IP routing, MPLS
   switching, Trill Switching or Layer 2 Switching.

   Forwarding Entity (FE): is defined as an entity which forwarding
   packets or frames under the control of the CE.  This entity can
   be an ForCES FE (F-FE) or an Open Flow Capable Switch (OF-CS). An
   Open Flow Capable switch can either be a hybrid switch or a Open-
   Flow Only switch.

   FE Manager (FE-MGR): The FE-Manager controls the FEs assignments.
   This document defines FE-Manager's logical entity may be a
   logical software process residing within local switch/device in
   the control plane or management plane. The FE-Mgr can also within
   a VM hypervisor, or a VM hypervisor manager, or other virtual
   software. The FE-Mgr can be a remote service managing the
   forwarding engine.  The Open Flow Configuration [OFC-1.0]
   Configuration Service point with its logical configuration
   function may also have a FE-MGR function. This FE-Mgr capability
   is an capability outside the [OFC-1.0] specification.


Hares, et al.          Expires November, 6 2012                [Page 6]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


   Pre-Association Phase (Pre-A): This document defines a Pre-
   Association Phase (Pre-A) as the period during which a CE-
   Management(Forces CE-Mgr or OF controller groups) and FE-Managers
   (Forces FE-MGR (F-FE-MGR)or OF-CS management) determines which
   Controlling entity (CE)controls which Forwarding Entity (FE).


Hares, et al.          Expires November, 6 2012                [Page 7]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


2.2.  Forces Definitions

   Force Forwarding Element (F-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." [RFC3654] ForCES forwarding FE
   supports forwarding rules insertion.

   ForCES Control Element (F-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." [RFC3654] The
   ForCES CE controller may be located within the same hardware box
   on a different blade or across an Ethernet connection, or across
   a L3 Link (if security used).

   ForCES Network Element(F-NE)- "An entity composed of one or more
   CEs and one or more FEs. To entities outside a NE, the NE
   represents a single point of management. An NE usually hides its
   internal organization from external entities and represents a
   single point of management to entities outside the NE." [RFC3654]
   The NE's single point of management can be at the IP layer, the
   Ethernet layer, and at a virtual layer. In this document, the
   network element is examined as being the set of network functions
   in the hardware that collaborates to act like a switch.  This
   less strict definition allows ForCES to be compared with the Open
   Flow work.

   ForCES Pre-Association Phase (F-Pre-A): ForCES defines the Pre-
   Association Phase (F-Pre-A) as "the period of time during which a
   FE Manager(see below)and a CE Manager (see below) are determining
   which FE is a part of the network element" [RFC3654].

   FE Manager(F-FE-Mgr)- ForCES (F-FE-Mgr)is "A logical entity that
   operates in the Pre-Association Phase and is responsible for
   determining to which CE(s) a FE should communicate. This process
   is called CE Discovery and may involve the FE manager learning
   capabilities of available CEs." [RFC3654]

   CE Manager (CE-Mgr) - Forces CE-MGR[F-CE-Mgr] is "A logical
   entity that operates in the pre-associaation phase and is
   responsible for determining to which FE(s) a CE should
   communicate. This process is called FE discovery and may involve
   the CE manager learning the capabilities of available FEs. The CE
   manager may use anything from statics configuration to a pre-
   association phase protocol." [RFC3654]



Hares, et al.          Expires November, 6 2012                [Page 8]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


   ForCES Protocol (ForCES-Proto) - "While there may be multiple
   protocols used within the overall ForCES architecture, the term
   "ForCES protocol" refers to only the post-association phase
   protocol." [RFC3654] The ForCES protocol operates between the "Fp
   reference points" of the ForCES architecture (as shown in figure
   1) [RFC5810]. "Basically, the ForCES protocol works in a master-
   slave mode in which the FEs are slaves and the CEs are
   masters." [RFC5810] The location and exact instantiation of the
   CE logical entities associated with the FE logical entity is
   flexible. The CE entities could reside on a process on a local
   switch communicating to other process off the local switch.

   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 (including requirements of ForCES TML)"
   [RFC5810] This layer is defined in 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." [RFC5810, p. x]. The ForCES TMLs focused on are
   STCP [STCP] and SSL[SSL].  TM handles transport of messages
   [reliable or non-reliable], "congestion control", "multicast",
   ordering, and other things [RFC5810, p. 14].

   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,



Hares, et al.          Expires November, 6 2012                [Page 9]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


   an LFB class ID associated with an LFB instance ID uniquely
   specifies an LFB existence.

   Physical Forwarding Element - The physical element that forwards
   the packets.

2.3.  Open Flow Definitions

   Open Flow (OF): [McKeown-xx] defines OF as a "way for researchers
   to run experiments in networks they use every day"[McKeown-2008,
   p.1].

   Open Flow Action [OF-Act]: [OF-1.1.0] defines an OF-Act as an
   action that may: "forward the packet to a port", or modifies the
   packet".  Actions may be specified in "Open Flow Instruction"
   [OF-Inst] in Flow Table Entry or "action buckets in Group Table
   Entry"[OF-1.1.0,p.4].

   Open Flow Action Set [OF-ActSet]: [OF-1.1] defines an OF-ActSet
   as "a set of actions associated with the packet that are
   accumulated while the packet is processed by each table, and are
   executed when the packet exits the processing Pipeline."[OF-1.1.0,
   p. 5].

   Open Flow Capable switch [OF-CS]: [One or more physical or
   virtual switch device which can act as an operational context for
   an Open Flow Logical Switch [OF-LS]. A OF-CS hosts an Open Flow
   Data Path [OF-DP].

   Open Flow Configuration and Management Protocol [OFCMP]: [OFC-1.0]
   states the [OFCMP-1.0]enables the remote configuration of Open
   Flow Data Path (OF-DP). The OFCMP allows a controller to
   configure the OF-DP on the Open Flow Logical Switch (OF-LS) "so
   that the controller can communicate and contro" the OF-LS via
   Open Flow Protocol (OFP). The OFCMP allows dynamic association of
   resources with OF-LS in an OF-CS. [OFC-1.0] defines the protocol,
   but not the resource allocation mechanisms.

   Open Flow Configuration Point (OFCPT): [OFC-1.0] defines an OFCPT
   as "a service" which sends OFCMP messages to a OF-CS with an OF-
   LS inside.

   Open Flow Controller [OF-CTLER]: [McKeown-2008] defines the OF-
   CTLER as a "controller that adds and deletes Flow entries on
   behalf of experiments" [McKeown-2008, p. 3].




Hares, et al.          Expires November, 6 2012               [Page 10]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


   Open Flow Datapath [OF-DP]: [OFC-1.0] defines OF-DP as an
   abstraction called Open Flow Logical Switch [OF-LS].

   Open Flow Dedicated Switches [OF-DS]: [McKeown-2008] defines OF-
   DS as a "dumb datapath element that forwards packets between
   ports as defined by a remote process" [McKeown-2008, p3.] The
   Open Flow process programs the forwarding engine for this dumb
   datapath switch.

   Open Flow Enable Switches [OF-ES]: [McKeown-2008] defines OF-ES
   as "commercial switches, routers or access points" enhanced by
   adding the OF feature

   Open Flow Feature [OF-Feature]: Open Flow[McKeown2008] and [OF-
   1.0.0] defines the OF-Feature as adding the features of an Open
   Flow Logical Switch [OF-LS]. These features are the Open Flow
   "Flow Tables", "Secure Channel that connects the switch to the
   controller", and "the Open Flow Protocol" [McKeown-2008, p.
   3][OF-1.0.0, p.2].

   Open Flow's Flow Table (OF-FT): [McKeown-2008] defines a Flow
   table in OF as having "an action with every flow table entry to
   tell the switch how to process the flow" [McKeown-2008, p. 2]

   Open Flow's Flow Table Entry (OF-FTE): [McKeown-2008], [OF-1.0.0],
   [OF-1.1.1], [OF-1.1.2], and [OF-1.1.3] define the specific of an
   single entry in a flow table. See Section x.x for a detailed
   comparison of this entry.

   Open Flow Group (OF-G): [OF-1.2] defines an OF group (OF-G) as a
   list of Open Flow "action buckets" and "a means to choose one or
   more buckets to apply on a per-packet basis" [OF-1.2, p. 5].

   Open Flow Group Table (OF-GT):

   Open Flow Logical Switch[OF-LS]: OFC-1.0 defines the OF-LS as an
   abstraction of the "open flow datapath".

   Open Flow Packet (OF-Pkt): [OF-1.1.0] defines OF-Pkt as "ethernet
   frame including header and payload" [OF-1.1.0, p. 4].

   Open Flow Pipeline [OF-PipeLine]: [OF-1.2] defines OF-Pipeline as
   "a set of linked tables that matching, forwarding, and

   Open Flow Port [OF-Port]: [OF-1.2] defines an Open Flow port as a
   place where packets enter and exit the Open Flow Pipeline.



Hares, et al.          Expires November, 6 2012               [Page 11]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


   Open Flow Protocol (OFP): OF 1.0 defines "an open protocol to
   program the flow table in switches and routers" in which "a
   controller communicates with a switch"[McKeown-2008,p. 2-3].

   Open Flow Switch (OFS): [McKeown-2008] defines an Open Flow
   Switch as a ethernet switch with "at least" the following three
   functions: "(1) a Flow Table","(2) "a secure channel that
   connects the" controller with the switch over which the open flow
   protocol runs, and (3)an "open flow protocol" [McKeown-2008,p
   2.][OF-1.0.0,p.2].

   [OF-1.1.0] defines an OFS as "one or more flow tables and a group
   table which perform packet look-ups and forwarding", and an open
   flow channel to an external controller"[OF-1.1.0,p.3]. The
   external controller controls the switch via the Open Flow
   protocol (OF-Proto)[OF-1.1.0, p.3]. [OF-1.3.0] adds that the
   "switch communicates with the controller, and the controller
   controls the switch"[OF-1.3.0, Section 2, paragraph 1.]

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
   history, goals, architecture, forwarding model and protocol
   interface.

3.1. Difference in Historical setting

   ForCES work began during the 1995-2000 timeframe with the
   development of netlink [RFC3549]. The linux netlink began its
   linux driver history as first a "character device /dev/netlink
   for Linux kernel 1.3.31" but was superceded by "Alexey
   Kunzetsov's socket-based af_netlink.c in Linux v 2.1.15"
   [Englehardt-2010].  The rtnetlink brought configuration and
   router queries to links.  The netlink socket allowed messages
   between kernel and user space regarding routes, firewalls, and
   monitoring.



Hares, et al.          Expires November, 6 2012               [Page 12]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


   The historical context of the 1995-2002 timeframe saw the initial
   growth of the US Internet and spread into non-US sites. The
   historical changes included changes that began the split of tight
   binding of control plane to data plane.  Forwarding plane
   elements (ASICs, TCAMs, Network processors) and backplanes began
   the growth of non-stop forwarding with high-availability. ForCES
   notes that the data processors have "forwarding tables", "per-
   flow Qos Tables and access control lists" [RFC365]. ForCES had
   control processors were general-purpose processors that support
   route calculations.

   ForCES began in quasi-commercial realm of linux development where
   linux developers used routing software with netlink to build
   early Internet networks. Alexey's early work was deployed in
   Russian and European networks to turn linux boxes into Routers.
   By early 2000, this work had migrated to router boxes seeking to
   harden routers to provide non-stop forwarding.  Netlink
   implementations were provided with many commercial OEM standards
   for switches and routers.

   ForCES work came out of the desire to expand the basic netlink
   protocol into an architecture that allow quick modeling of new
   forwarding hardware and an extensible control-plane to forwarding
   plane communication. Early discussions in ForCES look to allow
   coordination of multiple control planes as well as control plane
   to forwarding plane functionality. However, the IETF decision was
   to restrict the first versions of ForCES to architecture, CE-FE
   communication and FE modeling.

   OpenFlow arises out of the academic's communities realization
   that the hardening of commercial of network infrastructure [1995-
   2006] to support businesses, caused a "reluctance to experiment
   with production traffic"[McKeown-2008, p. 1]. The GENI (Global
   Environments for Network Research)[2006-2007] suggested that:
   a)Internet's infrastructure faced "serious problems" in "security,
   reliability, manageability, and evolvability" and "possible
   solutions" existed in research, but there were "severe
   experimental barriers" to test new ideas in wide-spread
   deployments [GENI-2007, p. vii].  A new US research network would
   allow slices of routers to be used for researcher's experiments
   in network protocols. McKeown and colleagues work examined how
   these experiments could be extended to run [McKeown-2008] on
   local campuses. McKeown and colleagues examined persuading
   commercial routers to provide an open interface for
   experimentation or using existing open source solutions (linux,
   XORP[XORP-2008]). Their conclusion was that "commercial solutions
   are too closed", and "research solutions have insufficient


Hares, et al.          Expires November, 6 2012               [Page 13]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


   performance or fanout, and are too expensive." [McKeown-2008, p.
   2].

3.2. Difference in Goals

   RFC3654 lists the the architectural goals of ForCES. OpenFlow
   Switch (OFS) Specification version 1.0.0[OFS-1.0.0] and OFS
   version 1.1.0 [OF-1.1.0] refer to [McKeown-2008] as the basis of
   these specifications. This document's goal comparison compares
   the four goals [McKeown-2008] sets against [RFC3654].

   The goal ForCES is to define the "architecture", "architectural
   modeling" and protocols to "logically separate control and data
   forwarding plans of an IP (IPv4, IPv6, etc.) networking device"
   [RFC3654, p. 1]. ForCES network device (aka. network element (NE))
   can be a router, IP switch, firewall, switch. ForCES redefines
   network elements to be logical relationships placed on physical
   devices.

   McKeown et al. state the goals of the OpenFlow approach was to
   find "high-performance and lost-cost implementations" of new
   network algorithms, capable of being used in "broad range of
   research", adaptable to commercial "close platforms", and able to
   "isolate experimental traffic from production traffic [McKeown-
   2008, p. 2].

   Difference in goals underscores the original commercial focus of
   ForCES and the experimental focus of OpenFlow.

3.3. Difference in Architectural Requirements

   Architecture sets the building blocks for system, and
   architectural requirements sets rules for interconnecting the
   building blocks.

   Building blocks for ForCES include the CE(s), FE(s), ForCES
   protocol (CE to/from FE), FE-Manager, CE-Manager, and logical
   input flows. Within the FEs there are Logical Forwarding Blocks
   connected together in a directed graph. The flow processing
   passes along input port, (modified)frame, metadata (which may
   include actions). The flow stream may be output to interfaces
   (logical or physical).

   Building blocks for OpenFlow include Controllers (~CEs) and
   Forwarding Units (~FEs) with OpenFlow processing. OpenFlow logic
   is designed in terms of Flow Processing controlled by Flow Tables
   (McKeown-2008][OFS-1.0][OFS-1.1], and Group tables [OFS-1.1]which


Hares, et al.          Expires November, 6 2012               [Page 14]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


   operate on the modified frame, metadata, or group of actions via
   actions or instructions (a group of actions and forwarding
   commands).

   Both flow streams Flow processing may cause the flow to multiple
   into several streams or combine multiple streams into one.

3.3.1. ForCES System Building Blocks

   The building blocks within the ForCES architecture are the CEs
   (controller elements), FEs (forwarding elements), and an
   interconnect protocol between CE(s) and FE(s). ForCES also
   recognized the logical functions of a FE-Manager and a CE-
   Manager.  Figure 1 shows a diagram from RFC5810 that details
   interaction between all these components.

   The ForCES CE controls switching, signaling, routing, and
   management protocols. Each CE is a logical unit which may be
   located within the same box, different boxes, or across the
   network. ForCES architecture [RFC3746] allows CEs to control
   forwarding in multiple FEs.

   ForCES defines logical Forwarding Elements (FEs) that reside on a
   variety of physical forwarding elements (PFE) such as a "single
   blade (PFE)", partition within blade, or multiple PFEs in a
   single box, or among multiple boxes [RFC3746, p. 2]. The ForCES
   logical FEs could also be run within Virtual Machines (VMs)
   within a single box or a set of boxes or a cloud. A single FE may
   be connected to multiple CEs providing strong redundancy. FE
   internal processing is described in terms of Logical Forwarding
   Blocks (LFBs) connected together in a directed graph that
   "receive, process, modify and transmit packets along with
   metadata"[RFC5810, p. 6]. The FE model determines the LFBs, the
   topological description, the operational characteristics, and the
   configuration parameters of each FE.

   The Forces Logical Forwarding Block (LFBs) Library [FORCES-LFB]
   provides the class descriptions for Ethernet, IP Packet
   Validation, IP Forwarding LFBs, and Redirection, MetaData, and
   Scheduling. Forces-LFB document demonstrates how these logical
   blocks can be placed within a machine to support IP Forwarding
   (IPv4/IPv6)for unicast & multicast and ARP processing[Forces-LFB,
   p. 17].

   ForCES architecture [RFC3746] allows CEs to control forwarding in
   multiple FEs. ForCES also recognized the logical functions of a
   FE-Manager and a CE-Manager. The FE manager determines the CE(s)


Hares, et al.          Expires November, 6 2012               [Page 15]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


   each FE should communicate with. The CE manager determines which
   FEs each CE should communicate with. The ForCES defines the FE-
   Manager and CE-Manager to operate in a "pre-association" phase of
   the communication to set-up the FORCES communication path.
   Similarities between the functions of the CE-Mangers and FE
   managers of ForCES and modern hypervisors may come from the
   creative interplay of early open source communities [1995-2005].
   Applications directly interacting with ForCES components (CEs or
   CE-Managers or FE-Manager) could be described as interactions
   with the CEs or CE-Managers.

   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]





Hares, et al.          Expires November, 6 2012               [Page 16]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


3.3.2. OpenFlow Building blocks

   OpenFlow architecture consists of set of OpenFlow Switches with a
   Flow Table, a Secure Channel between controller and switch, and
   an Open flow protocol.  OpenFlow switches can either be only
   controlled by OpenFlow, enabled by Open Flow [OFS 1.0] (shared),
   or hybrid Switches (OFS 1.2).

               ----------------  ----------------
                | 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: OpenFlow Architectural Diagram
                       by Using the terms NEs, FEs, CEs

   The Flow table provides entries on how to process a flow whose
   header fields match a pattern in the header field [OFS-1.0.0] or



Hares, et al.          Expires November, 6 2012               [Page 17]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


   a set of meta data generated from pipeline processing of a
   header[OFS-1.1.0, figure 4][OFS-1.3].

   The matching of a packet in OFS-1.0.0 based on first exact match
   of header and/or meta data, and secondly wild-card entries.  The
   wild-card entries contain a priority field to order the process
   of matching. For example, a priority of "1" will be the first
   wild card processed.

3.3.2.1. Match Fields in OFS

   The match field has been expanding as the ONF specifications
   evolve - from a 10-tuple [McKowen-2008], to 12-tuple [OFS-1.0],
   and to a OFS-1.1.0 a 15-tuple, to 39-tuple in OFS-1.3[OFS-1.3]
   (14 required and 25 optional).

   The original 10-tuple includes ingress port, VLAN ID, Ethernet
   source address, destination address and type, the IPv4
   source/destination address, and IP protocol, TCP/UDP source &
   destination port.  The 12-tuple adds VLAN priority, and IP Tos
   bits.  The 15-tuple adds: metadata, MPLS label, MPLS traffic
   class.  The TCP/UDP source & destination port have redefined for
   ICMP packets to have instead he the ICMP Type and ICMP code.
   [OFS-1.3-pre]required matches include the 10-tuple plus IPv6
   source and destination addresses and UDP source and destination
   ports.

3.3.2.2. Flow Logic - Flow Table and Group tables

   The flow table operation and data structures vary based on the
   version of OpenFlow Switch specification.

   OFS in versions [McKeown-2008] and [OFS-1.0.0] operate on logic
   in flow tables which are executed in ascending order. Each Flow
   Table ID must be greater than the current Flow table id.  [OFS-
   1.1.0][OFS-1.3] flow logic operates on flow tables and group
   tables which allow jumps based on "Goto table" logic or
   combinations of flows.



   |=============|    |==============|      |=============|

   |Flow table 0 |---.|Flow Table 1 | _ -. |Flow Table n |

   |=============|    |==============|      |=============|



Hares, et al.          Expires November, 6 2012               [Page 18]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


   Figure 3: Flow Table [OFS-0.9][OFS-1.0]



   All OFS Flow tables match on data and perform actions [OFS-
   0.8][OFS-0.9][OFS-1.0][OFS-1.1][OFS-1.2][OFS-1.3]. Later versions
   [OFS-1.1.0][OFS-1.2][OFS-1.3] use instructions to immediately
   perform actions or to queue specific actions for later
   processing. These same later versions also allow metadata to be
   stored to be passed along to additional processing.



                   |----------------|

                   | Group table 1  |

          |------. |action-bucket1 |----. egress-port-1

          |        | action-bucket2 ]

          |        |----------------|

          |

   |=============|    |==============|      |=============|

   |Flow table 0 |---.|Flow Table 1 | _ -. |Flow Table n |

   |=============|    |==============|      |=============|

   Figure 3: Flow Table [OFS-1.1]

   1) Action Specifics

   [McKeown-2008] has three actions in the flow tables: forwarding
   of a matched packet to a specific port or ports, sending the
   packet to the controller, or dropping the packet. This simply
   processing is why some engineers suggest that OFS-2008 is similar
   to the RSVP T-Spec [RFC2870].

   [OFS 1.0.0] actions direct switch processing to forward packet,
   drop packet, enqueue packet (optional), and modify-field in
   packet (optional).  Forwarding packets can be sent to all ports,
   the controller, local switches forwarding stack, send out input
   port, and specific ports after performing table actions & send
   out specified port, send via normal (L2/L3/VLAN) processing, and


Hares, et al.          Expires November, 6 2012               [Page 19]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


   flood (via minimum spanning tree) ports. This causes some
   engineers to consider OFS 1.0 equivalent to be Forces--.

   [OFS-1.1.0] uses instructions within each flow entry to determine
   how a packet and associated data is processed. These associated
   data includes: ingress port packet came in on, the generated
   meta-data and an action set. The action set is a set of commands
   to execute prior to sending the packet out.  The [OFS-1.1.0]
   instructions are: "Apply-Actions", "Clear-Actions", "Write-
   Actions", "Write-metadata", "Goto Table" [OFS-1.1.0, p. 14].
   Actions are either applied immediately with apply action command,
   or stored (via an Write-Action)in action sets for later
   processing in the action-set via a Write-Action.  The existing
   actions can be cleared with a "Clear-Action". [OFS-1.1.0] actions
   are output packet, set queue, drop packet, process via group
   table, push/pop tags, and set-field. [OFS-1.1.0] action sets
   include single entries for any of the following: copy TTL inward
   in packet, pop/push actions to packet, copy TTL outwards,
   decrement TTL, set fields in packet, apply QoS Actions (e.g. set
   queue), and apply group actions, and output packet.

   2) Flow Logic Encoding

   [OFS-1.0.0] encodes the ForCES LFB in table sequences. The LFB
   directed graph of ForCES modeling is encoded in sequences of Flow
   Table.  OFS 1.0 specifies that the Ethernet header (similar to
   ForCES Ethernet II) is the basic frame for all input. A fixed
   processing ARP, IPv4, TCP/UDP, and ICMP packets are specified
   based matches beyond the Ethernet header. The Forces LFB library
   provides building blocks for matches beyond the Ethernet to ARP,
   IPv4 and IPv6 packets, and Meta data. The OFS-1.0.0 does not have
   Metadata.

   [OFS-1.1.0] match of a flow goes against specific table 15-tuple
   header. If the frame/packet matches, the flow table can alter the
   packet (via immediate actions), add metadata (for later
   handling), set an actions in action set, pass the processing to a
   specific table (Flow Table or Group Table), or pass the
   processing to the next table in the sequence.  The information
   passed on to the next processing is [ingress port, (post-
   modification) frame/packet, metadata, and action set.

   [OFS-1.1.0] allows processing between tables to carry the ingress
   port, the packet, generated metadata, and an action set. An
   action set is a set of commands to execute prior to sending the
   packet out. [OFS-1.1.0] uses Flow table with instruction. The
   instructions can be which can be "Apply-Actions", "Clear-


Hares, et al.          Expires November, 6 2012               [Page 20]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


   Actions", "Write-Actions",
   "Write-metadata", "Goto Table" [OFS-1.1.0, p. 14]. Actions are
   either applied immediately with apply action command, or stored
   (via an Write-Action) for later processing in the action-set via
   a Write-Action.  The existing actions can be cleared with a
   Clear-Action.

   [OFS-1.1.0] supports two types of tables: flow tables, and group
   tables. The group table structure has a group identifier, group
   type, counters, and an order list action buckets. Action buckets
   contain a set of actions with parameters. If the group table has
   "zero" action buckets, then no processing occurs.

   [OFS-1.1.0] group type field specifies how the action buckets
   operate on the packet.  The group can be "all", "select",
   "indirect", and "fast-failover" [p.7]. The "all" bucket provides
   multicast and/or broadcast support execute all buckets. The
   packet is effectively cloned and sent out.  The select, indirect,
   and fast-failover execute one bucket. In select, the switch
   determines which port via internal algorithm (e.g. round-robin).
   In "indirect", the group table logic selects the bucket.  The
   "fast-failover", the first live bucket is chosen. The single-
   bucket choses may restrict flows if the specified buckets and/or
   output ports are down.

   This new sequential logic is the basis of some engineers comment
   that OpenFlow 1.1 is ForCES++.

   ForCES people indicate that that the group table logic plus "Go
   to" logic is simply a LFB model of a specific type.  [Haleplidis-
   2012] demonstrates on the LFB library concept can be used to
   capture all of the OFS-1.1.0 specification.






Hares, et al.          Expires November, 6 2012               [Page 21]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


3.3.3. ForCES FE types

   ForCES and OpenFlow FEs can operate either new switching entities
   or integrated with existing processing as a hybrid. In OFS-1.2,
   the Ships-in-the-Night (SIN) mode divides existing ports into
   groups controlled by specific ports (see figure x) or VLANs
   (figure-x)



   |=============|    |==============|      |=============|

   | standard    |    | Open Flow    |      |  Forces     |

   |   CE        |    | controller   |      |    CE       |

   |=============|    |==============|      |=============|

        ||                 ||                    ||

        ||                 ||                    ||  (forwarding)

   |-----------------------------------------------------------

   |  |==========|    |==============|      |=============|    |

   |  | standard |    | Open Flow    |      |  Forces FE  |    |

   |  | FE board |    |  FE          |      |             |    |

   |  |==|==|====|    |====|==|======|      |====|===|====|    |

   |-----|--|--------------|--|------------------|---|----------

   Standard ports         OFS ports         ForCES ports

   Figure x - Hybrid mode per port






Hares, et al.          Expires November, 6 2012               [Page 22]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012




   |=============|    |==============|      |=============|

   | standard    |    | Open Flow    |      |  Forces     |

   |   CE        |    | controller   |      |    CE       |

   |=============|    |==============|      |=============|

        ||                 ||                     ||

        ||                 ||    (forwarding)     ||

   |-----------------------------------------------------------|

   |  |==========|    |==============|      |=============|    |

   |  | standard |    | Open Flow    |      |  Forces FE  |    |

   |  | FE board |    |  FE          |      |             |    |

   |  |==|==|====|    |====|==|======|      |====|===|====|    |

   |     |  |              |  |                 |       |      |

   |  vlan1 vlan10     vlan2  vlan15          vlan3   vlan7    |

   |   | |   | |         | |   | |             | |   | |       |

   |---|-|---|-|---------|-|---|-|-------------|-|---|-|-------|

   S      OFS ports         ForCES ports

   Figure x - Hybrid mode per port



3.3.4. ForCES Pre-Association

   Neither the ForCES protocol nor the OFS protocols [McKeown-
   2008/OFS-0, OFS-1.0.0, OFS-1.1.1] specify how the CEs/controllers
   and FEs/forwarding switch meet.

   Do CEs go to the FEs meeting place and CEs pick up the FE that
   delights their forwarding fancy? How do they found out where



Hares, et al.          Expires November, 6 2012               [Page 23]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


   eligible FEs are meeting? Do FEs have choice on which CEs select
   them, and if so what are the criteria?

   The forming of intimate relationships between CEs and FEs remains
   to the readers of the specification as mysterious as the pre-
   association stages of human group dating or clique forming.

   ForCES specifications specifically call this phase a pre-
   association phase. The ForCES architecture names the entity that
   coordinates the forming of associations (like a Jewish match-
   maker) for CEs and for FEs. The CE-Manager determines which FEs
   each CE should talk to.  The FE-Manager determines which CEs each
   FE should talk to.  Only when the associations between each CE
   and its FEs, and each FE and its CEs are complete, does the
   system complete pass from pre-association phase to association
   phase.

   It is assumed that some protocol interactions within the logical
   ForCES network entity (or entities) determine how CEs will
   coordinate their work. However, the IETF work specifically
   denoted this CE-CE coordination work as a second phase of work.

   OpenFlow Switch specifications ([McKeown-200][OFS-0.8][OFS-
   0.9][OFS- 1.0] OFS-1.1] ignore the concept of this dynamic
   meeting processing.

   Either OFS specification missed this concept. Perhaps the OFS
   specifications assumed a static configuration as part of a boot
   process of the hybrid switch will set-up some basics. It is
   possible that the lack specification may come from the sponsors
   of the specification wanting proprietary pre-association
   interactions. If so, this provides an interesting line of
   demarcation between standards and OFS standard.

   In any case, this oddity from the OFS proponents leaves one to
   ask "What is the rest of the story on the pre-association phase?"


Hares, et al.          Expires November, 6 2012               [Page 24]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


3.3.5. Architectural requirements

   RFC3654 specifies 15 architectural requirements. Table 15
   provides summary of this requirements and possible OFS (McKeown-
   2008/OFS 0, OFS 1.0, OFS 1.1).

   ForCES Architectural Requirement    OpenFlow Switch Architecture

   --------------------------------    ----------------------------

  1. CE/FEs connect via variety of     Controllers/switch
     communicate
     interconnect technologies.        over a secure connection
     [RFC3654, p. 5]                   [McKeown-2008][OFS-1.0][OFS-1.1]

     FE can use different technology   not specified
     than CE/FE topologies.

  2. "FEs MUST support a minimal       [McKeown-2008][OFS-1.0][OFS-1.1]
     set of capabilities necessary     specify a set of required
     for establishing network          actions, instructions, Flow
     connectivity (e.g. interface      actions, and an implied set of
     discovery, port up/down           port functions(e.g.interface
     functions.)                       discovery, port up/down).
     Beyond this minimal set, the      These OFS specifications
     ForCES architecture MUST          also declare some set of
     NOT restrict the types of         features optional.
     numbers of capabiliti8es
     that FEs may contain.
     [RF3654, p.5]

  3. "Packets MUST be able to arrive   [OFS-1.0][OFS-1.1]specifies
     at the NE by one FE and leave     in ofp_port the OFPP_IN_PORT
     the NE via different FE."         flag which allows the port to
     [RFC3654, p.5]                    explicitly send it back out the
                                       input port [OFS-1.0, p. 18]
                                       [OFS-1.1, p. 26]



Hares, et al.          Expires November, 6 2012               [Page 25]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012




   ForCES Architectural Requirement    OpenFlow Switch Architecture

   --------------------------------    ----------------------------
  4. "A NE must support the            [OFS-1.0][OFS-1.1] describes
      appearance of a single           the devices as an individual
      functional device."              switch, and provides
      (e.g. single IP TTL reduction.)  the capability to reduce TTL
      [RFC3654,p. 5]                   [OFS-1.1,section 4.7, p. 12]


                                       such as push/pop of VLAN IDs
                                       and/or MPLS headers [OFS-1.1,
                                       p. 12]


   4b. However, external entities      4b. No pre-association logic has
   (e.g. FE managers and                been defined.
    CE managers) MAY have direct
    Access to individual ForCES
    protocol elements for providing
    information to transition
    [RFC3654, p. 5]


  5."The architecture MUST provide    Beyond a secure channel
     a way to prevent unauthorized    between some "controller
     FORCES protocol elements         entity and switch"
     from joining an NE."             no prevention of unauthorized
     [RFC3654, p. 5]                  access has been encoded.

  6. A FE must be able to               [OFS-1.0][OFS-1.1] have
     asynchronously inform the CE      "three message types:
     of a failure or                   controller-to-switch,
     increase/decrease in available asynchronous,
     resources or capabilities         symmetric [OFS-1.0, p. 10]
     on the FE.                        [OFS-1.1, p. 16].
                                       Asynchronous messages


Hares, et al.          Expires November, 6 2012               [Page 26]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


   ForCES Architectural Requirement    OpenFlow Switch Architecture

   --------------------------------    ----------------------------
                                       Switches send a controller (CE)
                                       Messages with  a  received
                                       packet
                                       (packet-in), notification of
                                       a removed flow table entry
                                       (flow-removed), changes in
                                       port
                                       status  (port-status),  and
                                       error
                                       conditions (error) [OFS-1.0,
                                       pp-10-12)][OFS-1.1, p. 16-
                                       17]



     "Thus, the FE MUST support        The change in port status
     error monitoring and reporting"   is covered,but memory status
     (e.g.  "number of physical ports  is not covered
      Or "memory changes").
     [RFC3654,p. 5]

  7. "The Architecture MUST support    [McKeown-2008], [OFS-1.0]
     mechanisms for CE redundancy      [OFS-1.1]do not specifically
      or CE failover.                  provide CE Redundancy or
                                       CE failover.

       1. This includes the            The OFS protocol supports
          ability for CE and FEs       echo request/reply
          to determine when there      message [OFS-1.0, p. 41]
          is a loss of association     [OFS-1.1, p. 55-56].
          between them, ability
          to restore the association   The OFS-1.1 provides a
          and efficient state          barrier message that
          (re)synchronization          provides synchronization
          mechanisms.                  [OFS-1.1, p. 50].



Hares, et al.          Expires November, 6 2012               [Page 27]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


  ForCES Architectural Requirement    OpenFlow Switch Architecture

   --------------------------------    ----------------------------
                                       The OFS-1.1 protocol supports
                                       query by the controller of the
                                       switch features, capabilities,
                                       configuration, flow table
                                       configuration, flow table
                                       entries, group table  entries,
                                       port configuration (pp. 36-42).
                                       FS-1.1 also provides
                                       Statistics on description of
                                       Switch (OFPST_DESC),
                                       Flow table status
                                       (OFPST_FLOW),aggregate flow
                                       statistics (OFPST_AGGREGATE),
                                       port statistics (OFPST_PORT),
                                       queue statistics (OFSPST_QUEUE),
                                       group statistics (OFSPST_GROUP),
                                       and experimenter extension
                                       (OFPST_EXPERIMENTER) (p.43-49).


   7. (CE redundancy - continued).
       2. This also includes the        OFS-1.1 states:
          ability to preset the        "In the case the switch loses




Hares, et al.          Expires November, 6 2012               [Page 28]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012
          actions an FE will take      contact with the current
          in reaction to loss of       controller, as a result of an
          association to its CE        echo request timeout,
          (e.g., whether the FE        TLS  session timeout, or other
          will continue to forward     disconnection, it should
          packets or whether it        attempt to contact one or more
          will halt operations."       backup controllers.
          [RFC3654, p.  6.]            The ordering of the backup
                                       Controllers is not specified by
                                       the protocol."

                                       "The switch should immediately
                                       enter either "fail secure mode",
                                       or "fail standalone mode" if it
                                       loses connection to the
                                       controller, depending on the
                                       switch implementation and
                                       configuration." [OFS-1.1, p.18]

                                       In "fail secure mode", the
                                       FE behavior remains the same
                                       except FE drops "packets and
                                       messages" destined for CE.
                                       In "fail-standalone mode",
                                       FE processes all packets
                                       acts as a "legacy switch
                                       or router." [OFS-1.1, p. 18]




   ForCES Architectural Requirement    OpenFlow Switch Architecture


Hares, et al.          Expires November, 6 2012               [Page 29]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


   --------------------------------    ----------------------------


                                        Flow entries persist over
                                        Failure in either fail secure
                                        Mode or fail standalone mode.


  8. "FEs must be able to redirect     [McKeown-2008][OFS-1.0][OFS-1.1]
     control packets addressed to      allow packets to forward to
     their interfaces to the CE.       Controller for processing.
     The (FE) MUST also redirect
     other relevant packets
     (E.g., such as those
     with Router Alert Option set)
     to their CE.
     The CEs MUST be able              [OFS-1.0][OFS-1.1] Flow tables
     to configure the packet           allow packet redirection filters
     redirections information/filters  on the FEs with action Forward
     on the FEs.                       controller (OFS-1.0, p. 6),
                                       (OFS-1.1, p. 13).

     The CEs MUST also be able         [OFS-1.0][OFS-1.1] allow a
     to create packets and have        CE to FE message (packet-out)
     its FEs deliver them.             to send frames/packets out
                                       a specific port
                                       [OFS-1.0, p. 10], [OFS-1.1,p.17]

  9."Any proposed ForCES               [OFS-1.0][OFS-1.1] do not
     architecture MUST explain         consider this requirement.
     how that architecture supports    Future OFS work may consider
     all the router functions as       this set of features.
     defined in [RFC1812]."
       1. Includes: IPv4 Forwarding Options

       2. Should include: IPv6 forwarding options




Hares, et al.          Expires November, 6 2012               [Page 30]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


   ForCES Architectural Requirement    OpenFlow Switch Architecture

   --------------------------------    ----------------------------


  10.    "In a ForCES NE, the CE(s)    [OFS-1.0][OFS-1.1] do not
     MUST be able to learn the         consider this requirement.
     topology by which the FEs
     in the NE are connected."




  11.    The ForCES NE architecture    [McKeown-2008], [OFS-1.0]
     MUST be capable of supporting      [OFS-1.1] do not consider
     (i.e. must scale to) at least      scale        of        CE/FE
     communications.
      hundred of FEs and tens of
      thousands of ports.


  12.    "The ForCES NE architecture   [McKeown-2008], [OFS-1.0],
      MUST allow FEs and CEs to join   [OFS-1.1] do not consider
      and leave NEs dynamically."      issues relating to
                                        active join/leaving of
                                        CEs and FEs in communication.


  13.    "The ForCES architecture      [McKeown-2008],[OFS-1.0],
     MUST support multiple CEs         [OFS-1.1] do not directly
     and FEs. However, coordination    discuss how multiple CEs
     between CEs is out of scope       will attach to FE. Or FEs
     of ForCES.                        attach to a CE.

     [Historical note:
      The restriction of CE
      coordination was a desired
      phase 2 work of the ForCES group.]



Hares, et al.          Expires November, 6 2012               [Page 31]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012



   ForCES Architectural Requirement    OpenFlow Switch Architecture

   --------------------------------    ----------------------------

  14.    For pre-association phase     [McKeown-2008], [OFS-1.0],
     set-up, monitoring,               [OFS-1.1] do not consider
     configuration issues, it MAY      issues relating setting up
     be useful to use standard         the links between CEs and
     management mechanisms for         FEs. Some "magic" occurs
     CEs and FEs.                      and the CE is talking to
                                       a particular FE.
     The ForCES architecture and
     requirements do not preclude
     this.

                                       [OFS-1.0][OFS-1.1] give
     In general, for                   no discussion on other
     post-association phase,           management process (SNMP)
     most management tasks SHOULD      outside the [OFC-1.0]
     be done through interactions      using netconf and beep
     with the CE.
     In certain conditions
     (e.g., CE/FE disconnection),
     it may be useful to allow
     management tools (E.g., SNMP)
     to diagnose and repair problems.

     The following guidelines MUST
     be observed:
       1. The ability for a
          management tool (e.g., SNMP)
          to be used to read
          (but not change) the state
          of FE SHOULD NOT be precluded.
       2. IT MUST NOT be possible



Hares, et al.          Expires November, 6 2012               [Page 32]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


          for management tools
          (e.g., SNMP, etc) to
          change the state of an
          FE in a manner that
          affects overall NE behavior
          without the CE being notified.


3.3.6. ForCES versus OpenFlow - A Central Controller

   ForCES and OpenFlow seek to split the control plane and the
   forwarding engine.  Both protocols using a secure connection can
   be used to interact with a central controller.  ForCES has spent
   more time determining how CEs and FEs might find one or more
   central controllers.  OpenFlow Specifications are just beginning
   to rediscover the need for this work.

   Both Forces an OpenFlow can provide the ability of a logically
   centralized controller to:

   o  Collect the network view and make decisions according to
      control logics (or applications);

   o  Interact with forwarding hardware (FE) to install forwarding
      policy and state,

   o  Provide open APIs to users to add new features.

   ForCES has considered security issues (such as Denial of Service
   (DOS)) and the mechanisms for grouping CEs with an FE, or FEs
   with a CE, Forwarding Models, and Forwarding Libraries.

   OFS specifications have focused on defining one simple
   functionality that can be implemented in specific networks. For
   example, many discussions point to code deployed in Google.

3.4. Difference in Forwarding Model

   ForCES and OFS pipeline processing of frames/packets include the
   basic steps of matching framing, processing frame, and
   outputting/dropping frame.  The processing of a frame occurs in a
   pipeline of processes where initially processing adds the
   metadata and actions that subsequent processing will use to
   create the final packet that will be sent via output port or
   dropped.



Hares, et al.          Expires November, 6 2012               [Page 33]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


   Key ingredients of a good pipeline process are:

   1)    a deterministic logic based that doesn't loop,

   2)    handles both unicast and multicast traffic,

   3)    Flexible matching that can growth with new features,

   4)    Metadata to allow passing of results to subsequent stages,

   5)    Logic that allows some stages to be skipped, and

   6)    Allows for no match (Table Miss).

3.4.1. Looping

   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. The directed graph model prevents the recycle
   of processing in a loop. Each LFB defines a set of processing on
   handling frames/packets. For example, typical LFBs include
   IPv4/IPv6 Longest Prefix Matching, etc. XML is used to describe
   LFB model formally.

   In [OFS-0.8][OFS-0.9][OFS-1.0] the forwarding model has been
   static defining specific functions for early experimentation of
   the switch. Loops have been prevent

   [OFS-1.0] defines the Flow tables identified by a sequential
   number [0,1,2_n]. Processing loops are prevent by defining that a
   flow table can only transfer to a higher flow table.

   [OFS-1.1] provides a Group table to augment the Flow Table logic
   described above.  If a flow matches, instructions in the flow
   table may direct the packet toward specific table (group table or
   flow table).  This jumping provides skips in sequential process
   unlike [OFS-1.0].  In addition, the "goto" action allows skips
   between tables.



Hares, et al.          Expires November, 6 2012               [Page 34]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


3.4.2.  Handling unicast and multicast

   [OFS-0.9][OFS-1.0] do not provide an easy to provide cloning for
   multicast. The group table in [OFS-1.1] provides the necessary
   cloning for multiple outputs of a single packet.

   A ForCES IPv4MultiLPB and IPv6MultiLPB could be defined beyond
   today's ForCES standards.  These LFBs would use an LPM to match
   the multicast address, and generate a list of "L3PortID" metadata
   to identify a set of ports the cloned packet could be sent out.
   This metadata could be passed to the EthernetEncap LFB.



3.4.3. Flexible matching

   All OFS specifications ([OFS-0.8][OFS-0.9][OFS-
   1.0][OFS1.1][OFS1.3-pre] seeks to match the header data against
   the flow table's match field. Ranging from a 10-29 possible
   matches in the header and metadata, the OFS provides flexible
   matching within the data packet (Ethernet, MPLS, IP, TCP, UDP).

   [Heleplidis-Forces-LFB] shows the matching capability in OFS-1.1
   can be implemented in ForCES LFBs.

3.4.4. Metadata to allow passing of results to subsequent stages,

   Both ForCES and OFS ([OFS-1.1][OFS-1.3-pre]) allow metadata to be
   passed to subsequent spaces.

3.4.5. Optionally skipping logic

   [OFS-1.1] provides a Group table to augment the Flow Table logic
   described above.  If a flow matches, instructions in the flow
   table may direct the packet toward specific table (group table or
   flow table).  This jumping provides skips in sequential process
   unlike [OFS-1.0]. The Group Table concepts provides the ability
   to group flows for execution, single out a single flow for
   additional processing, and use port liveness mechanisms for fast-
   failover. [OFS-1.1,p, 7].

   The ForCES directed graph model can also allow the skips in
   processing by having multiple exits from.

3.4.6. Table Miss

   A frame may not match any table in the forwarding pipeline.


Hares, et al.          Expires November, 6 2012               [Page 35]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


   [OFS-0.9] states "if no matching entry can be found for a packet,
   the packet will be sent to the controller over the secure
   channel"[p. 8].

   Experience has taught the OpenFlow community this can be
   problematic.

   [OFS-1.0.0-errta] states the following exceptions: "Sending the
   packet to the controller on table-miss may overload the switch or
   the controller, and some of those packets may have to be dropped,
   and this may be an issue in some deployments" [p., 3].

   The OFS-1.0.0-errta suggests that the vendor extension may allow
   the packet to be dropped or forwarded via pipeline. However, due
   to many application use of table-miss to do topology discovery or
   watch traffic - this feature is continued.

   ForCES does not define a global Table-Miss, but allows the LFB
   model to define these issues.



3.5. Difference in Logical Forwarding Block Libraries

   The Open-Flow group is beginning to consider flexible description
   of the next OFS switches using a modeling language. No modeling
   language has been approved as yet.

   The Force LFB Library [ForCES-LFB-Lib] has been defined and
   implemented. [Heleplidis-Forces-LFB] shows the modeling language
   can support OFS-1.1 definitions.

3.6. Difference in Protocol Interface

   The OFS protocol and the ForCES protocol both use:

     .  Secure transport protocols over which they operate (3.6.1)

     .  Messages to establish the Controller/CE - FE connections,

     .  Messages to Loading of forwarding logic (3.6.3)

     .  Messages to Configuration the box (3.6.4),

     .  Error handling messages (3.6.5),

     .  Liveness protocols (3.6.6), and


Hares, et al.          Expires November, 6 2012               [Page 36]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


     .  Sending packets for processing to/from controller (3.6.8).

3.6.1 Secure Transport

   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.

   OpenFlow defines the protocol between controller and OpenFlow
   switches, i.e. OpenFlow protocol.  OFS-1.1 states that the data
   channel is "usually encrypted using TLS, but may be run over
   TCP"[OFS-1.1.0,p. 16]

3.6.2 Types of Messages

   As Table-x shows, ForCES and OFS protocol are remarkably similar.
   Many OFS authors indicate the influence of the ForCES protocol on
   the OFS work.  Due to the IETF review, ForCES protocol's top
   level is carefully designed with orthogonal features of
   association setup, association teardown, config, query, events,
   packet redirect, and heartbeat.

   The OFS protocols [OFS-0.8][OFS-0.9][OFS-1.0][OFS-1.1] provide
   similar features, but have some overlapping functions. Similarly,
   the OFS protocol has

        o Hello (initial association),

        o Reading of switch Features (read/response),

        o config of switch and flow pipeline's via Flow tables
          [OFPT_FLOW_MOD), group tables [OFPT_GROUP_MOD], ports
          [OFPT_PORT_MOD].

        o Flow Removed [OFPT_FLOW_REMOVED] - Flow entry is removed
          due to either an idle timer or a hard timeout.

        o Query of statistics (OFPT_STATS_REQUEST,
          OFPT_STATS_RESPONSE),



Hares, et al.          Expires November, 6 2012               [Page 37]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


        o Packet-OUT- redirect of packet from controller out a port,

        o PACKET-IN - redirect packet inbound port to controller,

        o Echo request/reply - heartbeat from OFS switches.

   In addition, the OFS protocol has a Barrier Request/reply message
   that allows the controller to synchronize message processing.
   This general (but lose) definitional has allowed experimentation
   with OFS switches.

   Due to IETF review, the similar ForCES protocol has a clear
   orthogonal set of actions described in terms of execution and
   transaction models.  The CE can set execution flags on sets on
   transactions (groups of functions).  The execution of
   transactions can be: execute-all-or-none, continue-execute-on-
   failure, and execute-until failure.  A transaction set is must me
   the ACDity test (atomicity, consistency, isolation, and
   durability)[RFC5810,section 4.3.1.2]. Transaction sets have an
   start, middle, and end. The transaction can also signal an abort.

   The notification messages for Error and Port status are uniquely
   specified in the OFS as a notification. In ForCES this is
   included with the general notification category.

   Table-x  ForCES vs. OFS messages

   Message:           ForCES   OFS-0.9  OFS-1.0  OFS-1.1

   ================   ======================================

   Associate                   ----------Hello----------

    CE/FE (Req/Rsp)     X        X        X         X

   Association                 -----Feature Request/Response---

   Stop (Req/Rsp)       X        X        X         X

   Query/               X      ----Feature or STATS(Req/Rsp)---

   Query Response       X        X        X         X

   Config [Switch]             ---Config (non-flow table)-----

     (Req/Rsp)          X        X        X         X



Hares, et al.          Expires November, 6 2012               [Page 38]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


   Config (Req/Rsp)     X        ------ FLOW_MOD-------

                        X        X        X         X



   Table-x  ForCES vs. OFS messages

   Message:           ForCES   OFS-0.9 OFS-1.0  OFS-1.1

   ================   ======================================

   Heartbeat(Forces)    X        ---Echo-Request/Response---

   /Echo-Request(OFS)   X          X      X         X

   Redirect                      ---Packet_in  & Packet-Out)

                        X                 X         X

   Execution flags      X               ----Barrier-Set-Queue

                                          X         X

   Notification         x                 X         X

3.6.3 Loading of forwarding logic

   ForCES and OFS both use TLVS to add, modify, and delete the flow
   entry. In addition, ForCES has a concept of "commit" to a set of
   changes to allow multiple stages of set.

   OFS has the concept of modifying or deleting only strictly
   matching flows (OFPFC_MODIFY_STRICT, OFPFC_DELETE_STRICT). This
   is different that the OFS default of modifying all flows with
   that match (with wildcard).

3.6.4  Configuration

   ForCES defines changing configuration of the switching Forwarding
   pipeline within the protocol.  OF-Config-1.0 has provided a
   protocol to use an OpenFlow Configuration Point (logical mode)
   that can configure one or more OFS via the OpenFlow configuration
   protocol.  The configuration protocol runs on top of TLS or TCP.
   The configuration protocol sets the following information:

     o  Failure standby mode (fail secure or fail standalone)


Hares, et al.          Expires November, 6 2012               [Page 39]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


     o  Encryption mode (TLS or not),

     o  Queue configurations (min-rate, max-rate, experimenter),

     o  Ports (speed, no-receive, no forward, no packet-in, link-
        down, blocked, life) and optionally (duplex-mode, copper-
        medium, fiber-medium auto-negotiation, pause, asymmetric-
        pause),

     o  Data path id of switch.

3.6.5 Error handling and sanity checking

     The error handling indicates errors that occur within the
     protocol. The Error handling includes message form and action
     failure. For OFS the action failure includes all interactions
     such as: hello failure, bad request, bad flow action, bad flow
     instruction, bad match, cannot modify entry in flow table,
     cannot modify entry in group table, cannot modify port.

     Due to IETF review, the ForCES errors and notifications are
     define to contain all cases within the protocol. The error
     processing contains sanity checking.

3.6.6 Failure of CE/FE connection

   Heart beat messages in both ForCES and OFS insure "liveness" of
   the CE/FE connection.  The ForCES heartbeats are traffic
   sensitive, and are only sent if no traffic has occurred.

   OFS predefines that switches should enter the following based on
   losing connections with controller: "Fail secure mode" or "fail
   standalone mode" [OFS-1.1.0,section 5.3]. In Fail secure mode,
   forwarding continues as previous with the only change that no
   packets can be uploaded to the processor.

   In fail standalone mode, the OSF switch drops into the Ethernet
   legacy mode [OFPP_NORMAL].

   If the ForCES protocol is supporting the high-availability
   function, the begins the engage the high-availability statement
   machine. OpenFlow specifications have not yet described how High-
   availability will work in Open-Flow.






Hares, et al.          Expires November, 6 2012               [Page 40]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


4. Use of ForCES and OFS in Applications

   ForCES and OFS [OFS-1.0][OFS-1.1] have been encoding in a variety
   of applications. These application include:

     .  Firewalls,

     .  Loads balancers,

     .  Switches

     .  High-availability routers,

     .  Wireless devices.

     .  Table-x  ForCES vs. OFS messages

5. The use of ForCES or OpenFlow in S(D)N or CSO/SOP

   This section will contain a summary of the common capabilities of
   ForCES and OpenFLow in environments of centralized controllers,
   distributed controllers, and hybrid (centralized/distributed
   control) suggested by open flow.

   5.1 - Centralized controller logic

   ForCES and OFS have been designed for centralized controller
   logic. ForCES has considered the pre-association and association
   phase of the CE-FE relationship with all the timing issues. The
   execution and transaction model provide a strongly reviewed model
   to provide roll-forward and roll-back of transactions. The high-
   availability drafts for ForCES provide a clear case on how to
   keep high-availability of forwarding and CE processing while
   distributing the flows.

   ForCES has a clear body of work developed over years of
   implementation experience.

   OFS specifications do not deal with how controllers find FEs.
   However, numerous companies are developing centralized
   controllers. The standardization efforts for Hybrid (OFS-1.2) and
   the next generation OFS switch (OFS-1.3) indicate an effort to
   capture this growing body of wisdom.

   5.2 - Distributed controller logic




Hares, et al.          Expires November, 6 2012               [Page 41]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


   ForCES was built to distribute the controller logic to
   automonomous network elements that operate either as ForCES
   controlled or as integrated hybrid controller.

   OFS has created distributed logic per switch, but considers
   grouping of these switches outside the OFS specifications. The
   Hybrid [OFS-1.2] provides use cases for Ships-in-the-Night and
   integrated. The Ships-in-the-Night provide per port allocation to
   either OFS or standard processing. The Integrated seeks to run
   both on a set of ports.



   5.3 - Hybrid controllers

   ForCES was built for the hybrid environment where routing and
   switching protocol.

   OFS is now entering the processing of standardizing for hybrid
   controllers [OFS-1.2].

6. Security Considerations

   No security considerations.

   This is an informational comparison used to inform clarify ForCES
   work.

7. IANA Considerations

   No IANA considerations.

8. Conclusions

   Both ForCES and OpenFlow follow the basic idea of separations of
   forwarding plane and control plane in network elements. Both are
   capable of operating for centralized control, distributed control,
   and hybrid control.

   [OFS-1.1] Flow Table Logic with the instructions and Group Tables
   is the major difference between the ForCES RFCs.  As this paper
   has shown, the full ramifications of this difference need to be
   considered in terms of differences in capability of
   implementation. The author welcomes any additional implementation
   experience.




Hares, et al.          Expires November, 6 2012               [Page 42]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


   [OFS-1.0][OFS-1.1] lacks a forwarding model, a standardized LFB
   library and the concepts of FE-CE associations (FE-Manger, CE-
   Manager, pre/post association phase). It appears the OpenFlow
   work is starting to invent the equivalent of existing ForCES work
   as OpenFlow work. The guide of this reinventing seems to be the
   Google code snippets passed to the OpenFlow Forum as examples of
   "running code" to provide rough consensus.

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.

   [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

9.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.

   [OFS-1.0.0]

             OpenFlow Switch Specification - Version 1.0.0 (Wire
             Protocol 0x01), December 31, 2009.

   [OFS-1.0.1-rc3] OpenFlow Switch Errata - Version 1.0.1-r3, June
             12, 2012.





Hares, et al.          Expires November, 6 2012               [Page 43]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


   [OFS-1.1.0]
             OpenFlow Switch Specification Version 1.1.0 (Wire
             Protocol 0x02). February 2011.
             (http://www.openflow.org/documents/openflow-spec-
             v1.1.0.pdf)

   [OpenFlow-1.2] Open Flow 1.2 - Hybrid Switch (Terminology, Use
             cases, etc), April-May notes, work-in-progress.

   [OFS-1.3-rc4[ OpenFlow Switch Specification 1.3 (version 1.3-rc4)
             (Wire Protocol 0x04)  April4, 2012.  [OpenFlow members
             only]

   [OFS-1.1.0]
             OpenFlow Switch Specification Version 1.1.0 (Wire
             Protocol 0x02). February 2011.
             (http://www.openflow.org/documents/openflow-spec-
             v1.1.0.pdf)



   [OFC-1.0] OpenFlow Configuration and Management Protocol OF-
             CONFIG 1.0 (January 15, 2012).

   [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-06, Work in Progress.



10. Acknowledgments

   The author would like to thank Tina Tsou, Zhiliang Wang,Jing
   Huang, Xingang Shi, and Xia Yin. Their earlier draft comparing
   the FORCES and ONF Technology inspired this draft providing an
   opposing viewpoint.  It is said that "iron sharpens iron" so that
   in our debates we sharpen our understandings.




Hares, et al.          Expires November, 6 2012               [Page 44]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


   The author also acknowledges Edward Crabbe's succinct comments
   which also inspired the in-depth comparison found in this draft.
   I only hope that this "wordy" draft proves worth of his pithy and
   concise insights.









Hares, et al.          Expires November, 6 2012               [Page 45]


Internet-Draft           OpenFlow vs. ForCES              July 12, 2012


Authors' Addresses

   Susan Hares
   Huawei Technologies (USA)
   2330 Central Expressway
   Santa Clara, CA  95050
   USA

   Email: Susan Hares Susan.Hares@huawei.com


Hares, et al.          Expires November, 6 2012               [Page 46]