NUNES et al:A SURVEY OF SOFTWARE-DEFINED NETWORKING:PAST.PRESENT.AND FUTURE OF PROGRAMMABLE NETWORKS 1619 would likely be implemented as an application on top of an 1)ForCES:The approach proposed by the IETF ForCES SDN controller such as NOX [17],Maestro [211.Beacon [22]. (Forwarding and Control Element Separation)Working Group, SNAC [23],Helios [24],etc. redefines the network device's internal architecture having the control element separated from the forwarding element. However,the network device is still represented as a single III.SOFTWARE-DEFINED NETWORKING entity.The driving use case provided by the working group ARCHITECTURE considers the desire to combine new forwarding hardware with third-party control within a single network device.Thus,the Data communication networks typically consist of end- control and data planes are kept within close proximity (e.g., user devices,or hosts interconnected by the network infras- same box or room).In contrast,the control plane is ripped tructure.This infrastructure is shared by hosts and employs entirely from the network device in "OpenFlow-like"SDN switching elements such as routers and switches as well as systems. communication links to carry data between hosts.Routers ForCES defines two logic entities called the Forwarding and switches are usually "closed"systems,often with limited- Element(FE)and the Control Element(CE),both of which and vendor-specific control interfaces.Therefore,once de- implement the ForCES protocol to communicate.The FE ployed and in production,it is quite difficult for current is responsible for using the underlying hardware to provide network infrastructure to evolve;in other words,deploying per-packet handling.The CE executes control and signaling new versions of existing protocols(e.g.,IPv6),not to mention functions and employs the ForCES protocol to instruct FEs on deploying completely new protocols and services is an almost how to handle packets.The protocol works based on a master- insurmountable obstacle in current networks.The Internet, slave model,where FEs are slaves and CEs are masters. being a network of networks,is no exception. An important building block of the ForCES architecture is As mentioned previously,the so-called Internet "ossifica- the LFB (Logical Function Block).The LFB is a well-defined tion"[2]is largely attributed to the tight coupling between functional block residing on the FEs that is controlled by CEs the data-and control planes which means that decisions about via the ForCES protocol.The LFB enables the CEs to control data flowing through the network are made on-board each the FEs'configuration and how FEs process packets. network element.In this type of environment,the deployment ForCES has been undergoing standardization since 2003 of new network applications or functionality is decidedly non- and the working group has published a variety of documents trivial,as they would need to be implemented directly into including:an applicability statement,an architectural frame- the infrastructure.Even straightforward tasks such as config- work defining the entities and their interactions,a modeling uration or policy enforcement may require a good amount language defining the logical functions within a forwarding of effort due to the lack of a common control interface to element,and the protocol for communication between the the various network devices.Alternatively,workarounds such control and forwarding elements within a network element. as using "middleboxes"(e.g.,firewalls,Intrusion Detection The working group is currently active. Systems,Network Address Translators,etc.)overlayed atop 2)OpenFlow:Driven by the SDN principle of decoupling the underlying network infrastructure have been proposed and the control and data forwarding planes,OpenFlow [2],like deployed as a way to circumvent the network ossification ForCES,standardizes information exchange between the two effect.Content Delivery Networks (CDNs)[25]are a good planes. example. In the OpenFlow architecture,illustrated in Figure 2,the Software-Defined Networking was developed to facilitate forwarding device,or OpenFlow switch,contains one or more innovation and enable simple programmatic control of the flow tables and an abstraction layer that securely communi- network data-path.As visualized in Figure 1,the separation of cates with a controller via OpenFlow protocol.Flow tables the forwarding hardware from the control logic allows easier consist of flow entries,each of which determines how packets deployment of new protocols and applications,straightforward belonging to a flow will be processed and forwarded.Flow network visualization and management,and consolidation of entries typically consist of:(1)match fields,or matching various middleboxes into software control.Instead of enforc- rules,used to match incoming packets;match fields may ing policies and running protocols on a convolution of scat- contain information found in the packet header,ingress port, tered devices,the network is reduced to "simple"forwarding and metadata;(2)counters,used to collect statistics for the hardware and the decision-making network controller(s). particular flow,such as number of received packets,number of bytes and duration of the flow;and (3)a set of instructions, or actions,to be applied upon a match;they dictate how to A.Current SDN Architectures handle matching packets. Upon a packet arrival at an OpenFlow switch,packet header In this section,we review two well-known SDN architec- fields are extracted and matched against the matching fields tures,namely ForCES [1]and Openflow [21.Both OpenFlow portion of the flow table entries.If a matching entry is and ForCES follow the basic SDN principle of separation found,the switch applies the appropriate set of instructions, between the control and data planes;and both standardize or actions,associated with the matched flow entry.If the flow information exchange between planes.However,they are table look-up procedure does not result on a match,the action technically very different in terms of design,architecture, taken by the switch will depend on the instructions defined forwarding model,and protocol interface. by the table-miss flow entry.Every flow table must contain aNUNES et al.: A SURVEY OF SOFTWARE-DEFINED NETWORKING: PAST, PRESENT, AND FUTURE OF PROGRAMMABLE NETWORKS 1619 would likely be implemented as an application on top of an SDN controller such as NOX [17], Maestro [21], Beacon [22], SNAC [23], Helios [24], etc. III. SOFTWARE-DEFINED NETWORKING ARCHITECTURE Data communication networks typically consist of end￾user devices, or hosts interconnected by the network infras￾tructure. This infrastructure is shared by hosts and employs switching elements such as routers and switches as well as communication links to carry data between hosts. Routers and switches are usually “closed” systems, often with limited￾and vendor-specific control interfaces. Therefore, once de￾ployed and in production, it is quite difficult for current network infrastructure to evolve; in other words, deploying new versions of existing protocols (e.g., IPv6), not to mention deploying completely new protocols and services is an almost insurmountable obstacle in current networks. The Internet, being a network of networks, is no exception. As mentioned previously, the so-called Internet “ossifica￾tion” [2] is largely attributed to the tight coupling between the data– and control planes which means that decisions about data flowing through the network are made on-board each network element. In this type of environment, the deployment of new network applications or functionality is decidedly non￾trivial, as they would need to be implemented directly into the infrastructure. Even straightforward tasks such as config￾uration or policy enforcement may require a good amount of effort due to the lack of a common control interface to the various network devices. Alternatively, workarounds such as using “middleboxes” (e.g., firewalls, Intrusion Detection Systems, Network Address Translators, etc.) overlayed atop the underlying network infrastructure have been proposed and deployed as a way to circumvent the network ossification effect. Content Delivery Networks (CDNs) [25] are a good example. Software-Defined Networking was developed to facilitate innovation and enable simple programmatic control of the network data-path. As visualized in Figure 1, the separation of the forwarding hardware from the control logic allows easier deployment of new protocols and applications, straightforward network visualization and management, and consolidation of various middleboxes into software control. Instead of enforc￾ing policies and running protocols on a convolution of scat￾tered devices, the network is reduced to “simple” forwarding hardware and the decision-making network controller(s). A. Current SDN Architectures In this section, we review two well-known SDN architec￾tures, namely ForCES [1] and Openflow [2]. Both OpenFlow and ForCES follow the basic SDN principle of separation between the control and data planes; and both standardize information exchange between planes. However, they are technically very different in terms of design, architecture, forwarding model, and protocol interface. 1) ForCES: The approach proposed by the IETF ForCES (Forwarding and Control Element Separation) Working Group, redefines the network device’s internal architecture having the control element separated from the forwarding element. However, the network device is still represented as a single entity. The driving use case provided by the working group considers the desire to combine new forwarding hardware with third-party control within a single network device. Thus, the control and data planes are kept within close proximity (e.g., same box or room). In contrast, the control plane is ripped entirely from the network device in “OpenFlow-like” SDN systems. ForCES defines two logic entities called the Forwarding Element (FE) and the Control Element (CE), both of which implement the ForCES protocol to communicate. The FE is responsible for using the underlying hardware to provide per-packet handling. The CE executes control and signaling functions and employs the ForCES protocol to instruct FEs on how to handle packets. The protocol works based on a master￾slave model, where FEs are slaves and CEs are masters. An important building block of the ForCES architecture is the LFB (Logical Function Block). The LFB is a well-defined functional block residing on the FEs that is controlled by CEs via the ForCES protocol. The LFB enables the CEs to control the FEs’ configuration and how FEs process packets. ForCES has been undergoing standardization since 2003, and the working group has published a variety of documents including: an applicability statement, an architectural frame￾work defining the entities and their interactions, a modeling language defining the logical functions within a forwarding element, and the protocol for communication between the control and forwarding elements within a network element. The working group is currently active. 2) OpenFlow: Driven by the SDN principle of decoupling the control and data forwarding planes, OpenFlow [2], like ForCES, standardizes information exchange between the two planes. In the OpenFlow architecture, illustrated in Figure 2, the forwarding device, or OpenFlow switch, contains one or more flow tables and an abstraction layer that securely communi￾cates with a controller via OpenFlow protocol. Flow tables consist of flow entries, each of which determines how packets belonging to a flow will be processed and forwarded. Flow entries typically consist of: (1) match fields, or matching rules, used to match incoming packets; match fields may contain information found in the packet header, ingress port, and metadata; (2) counters, used to collect statistics for the particular flow, such as number of received packets, number of bytes and duration of the flow; and (3) a set of instructions, or actions, to be applied upon a match; they dictate how to handle matching packets. Upon a packet arrival at an OpenFlow switch, packet header fields are extracted and matched against the matching fields portion of the flow table entries. If a matching entry is found, the switch applies the appropriate set of instructions, or actions, associated with the matched flow entry. If the flow table look-up procedure does not result on a match, the action taken by the switch will depend on the instructions defined by the table-miss flow entry. Every flow table must contain a