IEEE COMMUNICATIONS SURVEYS & TUTORIALS , VOL. 16, NO. 3, THIRD QUARTER 2014
`
`161 7
`
`A Survey of Software-Defined Networking: Past,
`Present, and Future of Programmable Networks
`
`Bruno Astuto A. Nunes, Marc Mendonca, Xuan-Nam Nguyen, Katia Obraczka, and Thierry Turletti
`
`Abstract-The idea of programmable networks has recently
`re-gained considerable momentum due to the emergence of
`the Software-Defined Networking (SDN) paradigm. SDN, often
`referred to as a "radical new idea in networking", promises
`to dramatically simplify network management and enable in(cid:173)
`novation through network programmability. This paper surveys
`the state-of-the-art in programmable networks with an emphasis
`on SDN. We provide a historic perspective of programmable
`networks from early ideas to recent developments. Then we
`present the SDN architecture and the OpenFlow standard in
`particular, discuss current alternatives for implementation and
`testing of SON-based protocols and services, examine current
`and future SDN applications, and explore promising research
`directions based on the SDN paradigm.
`Index Terms-Software-Defined Networking, programmable
`networks, survey, data plane, control plane, virtualization.
`
`I. INTRODUCTION
`
`C OMPUTER networks are typically built from a large
`
`number of network devices such as routers, switches and
`numerous types of middleboxes (i.e., devices that manipulate
`traffic for purposes other than packet forwarding, such as a
`firewall) with many complex protocols implemented on them.
`Network operators are responsible for configuring policies to
`respond to a wide range of network events and applications.
`They have to manually transform these high level-policies into
`low-level configuration commands while adapting to changing
`network conditions. Often, they also need to accomplish these
`very complex tasks with access to very limited tools. As a
`result, network management and performance tuning is quite
`challenging and thus error-prone. The fact that network de(cid:173)
`vices are usually vertically-integrated black boxes exacerbates
`the challenge network operators and administrators face.
`Another almost unsurmountable challenge network practi(cid:173)
`tioners and researchers face has been referred to as "Internet
`ossification". Because of its huge deployment base and the
`fact it is considered part of our society's critical infrastructure
`(just like transportation and power grids), the Internet has
`become extremely difficult to evolve both in terms of its phys(cid:173)
`ical infrastructure as well as its protocols and performance.
`However, as current and emerging Internet applications and
`services become increasingly more complex and demanding,
`it is imperative that the Internet be able to evolve to address
`these new challenges.
`The idea of "programmable networks" has been proposed as
`a way to facilitate network evolution. In particular, Software
`
`Defined Networking (SDN) is a new networking paradigm
`in which the forwarding hardware is decoupled from con(cid:173)
`trol decisions. It promises to dramatically simplify network
`management and enable innovation and evolution. The main
`idea is to allow software developers to rely on network
`resources in the same easy manner as they do on storage
`and computing resources. In SDN, the network intelligence is
`logically centralized in software-based controllers (the control
`plane), and network devices become simple packet forwarding
`devices (the data plane) that can be programmed via an open
`interface (e.g., ForCES [l] , OpenFlow [2] , etc).
`SDN is currently attracting significant attention from both
`academia and industry. A group of network operators, ser(cid:173)
`vice providers, and vendors have recently created the Open
`Network Foundation [3] , an industrial-driven organization, to
`promote SDN and standardize the OpenFlow protocol [2]. On
`the academic side, the OpenFlow Network Research Center [4]
`has been created with a focus on SDN research. There have
`also been standardization efforts on SDN at the IETF and IRTF
`and other standards producing organizations.
`The field of software defined networking is quite recent,
`yet growing at a very fast pace. Still, there are important
`research challenges to be addressed. In this paper, we survey
`the state-of-the-art in programmable networks by providing a
`historic perspective of the field and also describing in detail
`the SDN paradigm and architecture. The paper is organized
`as follows: in Section II, it begins by describing early efforts
`focusing on programmable networks. Section III provides an
`overview of SDN and its architecture. It also describes the
`OpenFlow protocol. Section IV describes existing platforms
`for developing and testing SDN solutions including emulation
`and simulation tools, SDN controller implementations, as well
`as verification and debugging tools. In Section V, we discuss
`several SDN applications in areas such as data centers and
`wireless networking. Finally, Section VI discusses research
`challenges and future directions.
`
`II. EARLY PROGRAMMABLE NETWORKS
`
`SDN has great potential to change the way networks oper(cid:173)
`ate, and OpenFlow in particular has been touted as a "radical
`new idea in networking" [5]. The proposed benefits range
`from centralized control, simplified algorithms, commoditiz(cid:173)
`ing network hardware, eliminating middleboxes, to enabling
`the design and deployment of third-party 'apps'.
`While OpenFlow has received considerable attention from
`Manu script received June 14, 201 3; revi sed October 28, 2013.
`industry, it is worth noting that the idea of programmable
`B. A. A. Nunes, X. Nguyen and T. Turletti are with INRIA, France (e-mail:
`{bruno.astuto-arouche-nunes, xuan-nam.nguyen , thierry.turletti } @inria.fr)
`networks and decoupled control logic has been around for
`M . Mendonca and K. Obraczka are with UC Santa Cruz (e-mail: {msm,
`many years. In this section, we provide an overview of early
`katia} @soe.ucsc.edu)
`programmable networking efforts, precursors to the current
`Digital Object Identifier 10. 1109/SURV.2014.012214.00180
`155 3-877X/14/$31.00 © 2014 IEEE
`
`Authorized licensed use limited to: John Wootress. Downloaded on August 09,2022 at 23: 13: 11 UTC from IEEE Xplore. Restrictions apply.
`
`Exhibit 1009
`Cisco v. Orckit – IPR2023-00554
`Page 1 of 18
`
`

`

`161 8
`
`IEEE COMM UNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 3, THIRD QUARTER 2014
`
`SDN paradigm that laid the foundation for many of the ideas
`we are seeing today.
`a) Open Signaling: The Open Signaling (OPENSIG)
`working group began in 1995 with a series of workshops
`dedicated to "making ATM, Internet and mobile networks
`more open, extensible, and programmable" [6]. They believed
`that a separation between the communication hardware and
`control software was necessary but challenging to realize; this
`is mainly due to vertically integrated switches and routers,
`whose closed nature made the rapid deployment of new
`network services and environments impossible. The core of
`their proposal was to provide access to the network hardware
`via open, programmable network interfaces; this would allow
`the deployment of new services through a distributed program(cid:173)
`ming environment.
`Motivated by these ideas, an IETF working group was
`created, which led to the specification of the General Switch
`Management Protocol (GSMP) [7] , a general purpose pro(cid:173)
`tocol to control a label switch. GSMP allows a controller
`to establish and release connections across the switch, add
`and delete leaves on a multicast connection, manage switch
`ports, request configuration information, request and delete
`reservation of switch resources, and request statistics. The
`working group is officially concluded and the latest standards
`proposal, GSMPv3 , was published in June 2002.
`b) Active Networking: Also in the mid 1990s, the
`Active Networking [8] , [9] initiative proposed the idea of
`a network infrastructure that would be programmable for
`customized services. There were two main approaches being
`considered, namely: (1) user-programmable switches, with in(cid:173)
`band data transfer and out-of-band management channels;
`and (2) capsules, which were program fragments that could
`be carried in user messages; program fragments would then
`be interpreted and executed by routers. Despite considerable
`activity it motivated, Active Networking never gathered crit(cid:173)
`ical mass and transferred to widespread use and industry
`deployment, mainly due to practical security and performance
`concerns [ 10].
`c) DCAN: Another initiative that took place in the
`mid 1990s is the Devolved Control of ATM Networks
`(DCAN) [11]. The aim of this project was to design and
`develop the necessary infrastructure for scalable control and
`management of ATM networks. The premise is that con(cid:173)
`trol and management functions of the many devices (ATM
`switches in the case of DCAN) should be decoupled from the
`devices themselves and delegated to external entities dedicated
`to that purpose, which is basically the concept behind SDNs.
`DCAN assumes a minimalist protocol between the manager
`and the network, in the lines of what happens today in
`proposals such as OpenFlow. More on the DCAN project can
`be found at [ 12].
`Still in the lines of SDNs and the proposed decoupling of
`control and data plane over ATM networks, amongst others,
`in the work proposed in [13] multiple heterogeneous control
`architectures are allowed to run simultaneously over single
`physical ATM network by partitioning the resources of that
`switch between those controllers.
`d) 4D Project: Starting in 2004, the 4D project [14],
`[15] , [16] advocated a clean slate design that emphasized
`
`separation between the routing decision logic and the pro(cid:173)
`tocols governing the interaction between network elements.
`It proposed giving the "decision" plane a global view of the
`network, serviced by a "dissemination" and "discovery" plane,
`for control of a "data" plane for forwarding traffic. These ideas
`provided direct inspiration for later works such as NOX [17] ,
`which proposed an "operating system for networks" in the
`context of an OpenFlow-enabled network.
`e) NETCONF: In 2006, the IETF Network Configu(cid:173)
`ration Working Group proposed NETCONF [18] as a man(cid:173)
`agement protocol for modifying the configuration of network
`devices. The protocol allowed network devices to expose an
`API through which extensible configuration data could be sent
`and retrieved.
`Another management protocol, widely deployed in the past
`and used until today, is the SNMP [19]. SNMP was proposed
`in the late 80's and proved to be a very popular network
`management protocol, which uses the Structured Management
`Interface (SMI) to fetch data contained in the Management
`Information Base (MIB). It could be used as well to change
`variables in the MIB in order to modify configuration settings.
`It later became apparent that in spite of what it was originally
`intended for, SNMP was not being used to configure network
`equipment, but rather as a performance and fault monitoring
`tool. Moreover, multiple shortcomings were detected in the
`conception of SNMP, the most notable of which was its lack
`of strong security. This was addressed in a later version of the
`protocol.
`NETCONF, at the time it was proposed by IETF, was
`seen by many as a new approach for network management
`that would fix the aforementioned shortcomings in SNMP.
`Although the NETCONF protocol accomplishes the goal of
`simplifying device (re)configuration and acts as a building
`block for management, there is no separation between data
`and control planes. The same can be stated about SNMP.
`A network with NETCONF should not be regarded as fully
`programmable as any new functionality would have to be
`implemented at both the network device and the manager so
`that any new functionality can be provided; furthermore, it is
`designed primarily to aid automated configuration and not for
`enabling direct control of state nor enabling quick deployment
`of innovative services and applications. Nevertheless, both
`NETCONF and SNMP are useful management tools that
`may be used in parallel on hybrid switches supporting other
`solutions that enable programmable networking.
`The NETCONF working group is currently active and the
`latest proposed standard was published in June 2011.
`f) Ethane: The immediate predecessor to OpenFlow was
`the SANE I Ethane project [20] , which, in 2006, defined
`a new architecture for enterprise networks. Ethane's focus
`was on using a centralized controller to manage policy and
`security in a network. A notable example is providing identity(cid:173)
`based access control. Similar to SDN, Ethane employed two
`components: a controller to decide if a packet should be
`forwarded , and an Ethane switch consisting of a flow table
`and a secure channel to the controller.
`Ethane
`laid
`the foundation for what would become
`Software-Defined Networking. To put Ethane in the context of
`today 's SDN paradigm, Ethane's identity-based access control
`
`Authorized licensed use limited to: John Wootress. Downloaded on August 09,2022 at 23: 13: 11 UTC from IEEE Xplore. Restrictions apply.
`
`Exhibit 1009
`Cisco v. Orckit – IPR2023-00554
`Page 2 of 18
`
`

`

`NUNES et al. : A SURVEY OF SOFfWARE-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.
`
`Ill. SOFTWARE-DEFINED NETWORKING
`ARCHITECTURE
`
`Data communication networks typically consist of end(cid:173)
`user devices, or hosts interconnected by the network infras(cid:173)
`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(cid:173)
`and vendor-specific control interfaces. Therefore, once de(cid:173)
`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(cid:173)
`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(cid:173)
`trivial, as they would need to be implemented directly into
`the infrastructure. Even straightforward tasks such as config(cid:173)
`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(cid:173)
`ing policies and running protocols on a convolution of scat(cid:173)
`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(cid:173)
`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(cid:173)
`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(cid:173)
`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(cid:173)
`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
`
`Authorized licensed use limited to: John Wootress. Downloaded on August 09,2022 at 23: 13: 11 UTC from IEEE Xplore. Restrictions apply.
`
`Exhibit 1009
`Cisco v. Orckit – IPR2023-00554
`Page 3 of 18
`
`

`

`1620
`
`IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 3, THIRD QUARTER 2014
`
`...a SDN Controller
`
`Middlebox (e.g. Firewall)
`
`Forwarding device with ~ Forwarding device with
`1!!.!!11 embedded contro l
`decoupled cont rol
`
`;
`
`;
`
`;
`
`;
`
`;
`
`Software
`Control
`
`; l...&...i
`
`Traditional Network
`(with distributed control and middleboxes)
`
`Software-Defined Network
`(with decoupled control)
`
`Fig. I. The SDN architecture decouples control logic from the forwarding hardware, and enables the consolidation of middleboxes, simpler policy management,
`and new functionalities. The solid lines define the data-plane links and the dashed lines the control-plane links.
`
`CONTROLLER
`I
`OpenFlow Protocol
`
`OPENFLOW CLIENT
`1----------------------t OPENFLOW
`FLOW TABLE
`RULE
`
`STATISTICS
`
`ACTIONS
`
`PORT i---+--1 PORT i--+------1 PORT i-----
`2
`N
`
`IP src/dst, MAC src/dst,
`Transport Src/Dst, VLAN ...
`
`Forward to port(s)
`Forward to the controller
`Modify header fields
`Drop
`
`Packets , Bytes, Duration
`
`Fig. 2. Communication between the controller and the forwarding devices happen s via OpenFlow protocol. The flow tables are composed by matching rules,
`actions to be taken when the flow matches the rules, and counters for collecting flow statistics.
`
`table-miss entry in order to handle table misses. This particular
`entry specifies a set of actions to be performed when no
`match is found for an incoming packet, such as dropping the
`packet, continue the matching process on the next flow table,
`or forward the packet to the controller over the OpenFlow
`channel. It is worth noting that from version 1.1 OpenFlow
`supports multiple tables and pipeline processing. Another
`possibility, in the case of hybrid switches, i.e., switches that
`have both OpenFlow- and non-OpenFlow ports, is to forward
`non-matching packets using regular IP forwarding schemes.
`The communication between controller and switch happens
`via OpenFlow protocol, which defines a set of messages that
`
`can be exchanged between these entities over a secure channel.
`Using the OpenFlow protocol a remote controller can, for
`example, add, update, or delete flow entries from the switch's
`flow tables. That can happen reactively (in response to a packet
`arrival) or proactively.
`3) Discussion:
`In [26], the similarities and differences
`between ForCES and OpenFlow are discussed. Among the
`differences, they highlight the fact that the forwarding model
`used by ForCES relies on the Logical Function Blocks (LFBs),
`while OpenFlow uses flow tables. They point out that in
`OpenFlow actions associated with a flow can be combined
`to provide greater control and flexibility for the purposes
`
`Authorized licensed use limited to: John Wootress. Downloaded on August 09,2022 at 23: 13: 11 UTC from IEEE Xplore. Restrictions apply.
`
`Exhibit 1009
`Cisco v. Orckit – IPR2023-00554
`Page 4 of 18
`
`

`

`NUNES et al. : A SURVEY OF SOFfWARE-DEFINED NETWORKING: PAST, PRESENT, AND FUTURE OF PROGRAMMABLE NETWORKS
`
`1621
`
`of network management, administration, and development. In
`ForCES the combination of different LFBs can also be used
`to achieve the same goal.
`We should also re-iterate that ForCES does not follow the
`same SDN model underpinning OpenFlow, but can be used
`to achieve the same goals and implement similar functional(cid:173)
`ity [26].
`The strong support from industry, research, and academia
`that the Open Networking Foundation (ONF) and its SDN
`proposal, OpenFlow, has been able to gather is quite impres(cid:173)
`sive. The resulting critical mass from these different sectors
`has produced a significant number of deliverables in the form
`of research papers, reference software implementations, and
`even hardware. So much so that some argue that OpenFlow's
`SDN architecture is the current SDN de-facto standard. In
`line with this trend, the remainder of this section focuses on
`OpenFlow's SDN model. More specifically, we will describe
`the different components of the SDN architecture, namely:
`the switch, the controller, and the interfaces present on the
`controller for communication with forwarding devices (south(cid:173)
`bound communication) and network applications (northbound
`communication). Section IV also has an OpenFlow focus as it
`describes existing platforms for SDN development and testing,
`including emulation and simulation tools, SDN controller im(cid:173)
`plementations, as well as verification and debugging tools. Our
`discussion of future SDN applications and research directions
`is more general and is SDN architecture agnostic.
`
`B. Forwarding Devices
`
`The underlaying network infrastructure may involve a num(cid:173)
`ber of different physical network equipment, or forwarding
`devices such as routers, switches, virtual switches, wireless
`access points, to name a few. In a software-defined network,
`such devices are often represented as basic forwarding hard(cid:173)
`ware accessible via an open interface at an abstraction layer, as
`the control logic and algorithms are off-loaded to a controller.
`Such forwarding devices are commonly referred to, in SDN
`terminology, simply as "switches", as illustrated in Figure 3.
`In an OpenFlow network, switches come in two vari(cid:173)
`eties: pure and hybrid. Pure OpenFlow switches have no
`legacy features or on-board control, and completely rely on a
`controller for forwarding decisions. Hybrid switches support
`OpenFlow in addition to traditional operation and protocols.
`Most commercial switches available today are hybrids.
`1) Processing Forwarding Rules: Flow-based SDN archi(cid:173)
`tectures such as OpenFlow may utilize additional forwarding
`table entries, buffer space, and statistical counters that are
`difficult to implement in traditional ASIC switches. Some
`recent proposals [27] , [28] have advocated adding a general(cid:173)
`purpose CPU, either on-switch or nearby, that may be used
`to supplement or take over certain functions and reduce the
`complexity of the ASIC design. This would have the added
`benefit of allowing greater flexibility for on-switch processing
`as some aspects would be software-defined.
`In [29] , network processor based acceleration cards were
`used to perform OpenFlow switching. They proposed and
`described the design options and reported results that showed a
`20% reduction on packet delay. In [30] , an architectural design
`
`to improve look-up performance of OpenFlow switching in
`Linux was proposed. Preliminary results reported showed a
`packet switching throughput increase of up to 25% com(cid:173)
`pared to the throughput of regular software-based OpenFlow
`switching. Another study on data-plane performance over
`Linux based Openflow switching was presented in [31] , which
`compared OpenFlow switching, layer-2 Ethernet switching
`and layer-3 IP routing performance. Fairness, forwarding
`throughput and packet latency in diverse load conditions were
`analyzed. In [32], a basic model for the forwarding speed
`and blocking probability of an OpenFlow switch was derived,
`while the parameters for the model were drawn from mea(cid:173)
`surements of switching times of current OpenFlow hardware,
`combined with an OpenFlow controller.
`
`2) Installing Forwarding Rules: Another issue regarding
`the scalability of an OpenFlow network is memory limitation
`in forwarding devices. OpenFlow rules are more complex
`than forwarding rules in traditional IP routers. They support
`more flexible matchings and matching fields and also differ(cid:173)
`ent actions to be taken upon packet arrival. A commodity
`switch normally supports between a few thousand up to tens
`of thousands forwarding rules [33]. Also, Ternary Content(cid:173)
`Addressable Memory (TCAM) has been used to support
`forwarding rules, which can be expensive and power-hungry.
`Therefore, the rule space is a bottleneck to the scalability of
`OpenFlow, and the optimal use of the rule space to serve
`a scaling number of flow entries while respecting network
`policies and constraints is a challenging and important topic.
`
`Some proposals address memory limitations in OpenFlow
`switches. Devoflow [34] is an extension to OpenFlow for high(cid:173)
`performance networks. It handles mice flows (i.e. short flow s)
`at the OpenFlow switch and only invokes the controller in
`order to handle elephant flows (i.e larger flow s). The perfor(cid:173)
`mance evaluation conducted in [34] showed that Devoflow
`uses 10 to 53 times less flow table space. In DIFANE [35] ,
`"ingress" switches redirect packets to "authority" switches that
`store all the forwarding rules while ingress switches cache
`flow table rules for future use. The controller is responsible
`for partitioning rules over authority switches.
`
`Palette [36] and One Big Switch [37] address the rule
`placement problem. Their goal is to minimize the number
`of rules that need to be installed in forwarding devices and
`use end-to-end policies and routing policies as input to a rule
`placement optimizer. End-to-end policies consist of a set of
`prioritized rules dictating, for example, access control and
`load balancing, while viewing the whole network as a single
`virtual switch. Routing policies, on the other hand, dictate
`through what paths traffic should flow in the network. The
`main idea in Palette is to partition end-to-end policies into
`sub tables and then distribute them over the switches. Their
`algorithm consists of two steps: determine the number k of
`tables needed and then partition the rules set over k tables.
`One Big Switch, on the other hand, solves the rule placement
`problem separately for each path, choosing the paths based on
`network metrics (e.g. latency, congestion and bandwidth), and
`then combining the result to reach a global solution.
`
`Authorized licensed use limited to: John Wootress. Downloaded on August 09,2022 at 23: 13: 11 UTC from IEEE Xplore. Restrictions apply.
`
`Exhibit 1009
`Cisco v. Orckit – IPR2023-00554
`Page 5 of 18
`
`

`

`1622
`
`IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 3, THIRD QUARTER 2014
`
`Applications
`
`Network OS
`
`Decoupled
`Control Logic
`
`j ~
`
`Secure
`17 Channel
`
`Abstraction Layer
`
`A~
`
`1 7
`~ 11 Flow Table 11
`I
`~ I
`
`SWITCH
`
`....
`
`~
`
`Fig. 3. The separated control logic can be viewed as a network operating
`system, upon which applications can be built to "program" the network.
`
`C. The Controller
`The decoupled system has been compared to an operating
`system [17] , in which the controller provides a programmatic
`interface to the network. That can be used to implement
`management tasks and offer new functionalities. A layered
`view of this model is illustrated in Figure 3. This abstraction
`assumes the control is centralized and applications are written
`as if the network is a single system. It enables the SDN
`model to be applied over a wide range of applications and
`heterogeneous network technologies and physical media such
`as wireless (e.g. 802.11 and 802.16), wired (e.g. Ethernet) and
`optical networks.
`As a practical example of the layering abstraction accessi(cid:173)
`ble through open application programming interfaces (APis),
`Figure 4 illustrates the architecture of an SDN controller
`based on the OpenFlow protocol. This specific controller is
`a fork of the Beacon controller [22] called Floodlight [38].
`In this figure it is possible to observe the separation between
`the controller and the application layers. Applications can be
`written in Java and can interact with the built-in controller
`modules via a JAVA APL Other applications can be written in
`different languages and interact with the controller modules
`via the REST APL This particular example of an SDN
`controller allows the implementation of built-in modules that
`can communicate with their implementation of the OpenFlow
`controller (i.e. OpenFlow Services). The controller, on the
`other hand, can communicate with the forwarding devices via
`the OpenFlow protocol through the abstraction layer present
`at the forwarding hardware, illustrated in Figure 3.
`While the aforementioned layering abstractions accessible
`via open APis allow the simplification of policy enforce(cid:173)
`ment and management tasks, the bindings must be closely
`maintained between the control and the network forwarding
`elements. The choices made while implementing such layering
`architectures can dramatically influence the performance and
`
`scalability of the network. In the following, we address some
`such scalability concerns and go over some proposals that aim