IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 3, THIRD QUARTER2014
`
`
`
`
`
`
`
`
`
`
`
`
`
`1617
`
`
`
`
`
`
`
`
`
`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-
`
`
`
`
`
`
`
`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 SDN-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
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`OMPUTER networks are typically built from a large
`numberof 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 commandswhile 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-
`
`
`
`
`
`
`vices are usually vertically-integrated black boxes exacerbates
`
`
`
`
`
`
`
`the challenge network operators and administrators face.
`
`
`
`
`
`Another almost unsurmountable challenge network practi-
`tioners and researchers face has beenreferred 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 powergrids), the Internet has
`
`
`
`
`
`
`
`
`
`
`becomeextremely difficult to evolve both in termsofits phys-
`
`
`
`
`
`
`
`
`
`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-
`
`
`
`
`
`
`
`
`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 networkintelligence 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 [1], OpenFlow [2], etc).
`
`
`
`
`
`
`
`SDN is currently attracting significant attention from both
`
`
`
`
`
`
`
`
`academia and industry. A group of network operators, ser-
`
`
`
`
`
`
`
`
`
`vice providers, and vendors have recently created the Open
`
`
`
`
`
`
`
`Network Foundation [3], an industrial-driven organization, to
`
`
`
`
`
`
`
`
`
`promote SDN and standardize the OpenFlowprotocol [2]. On
`
`
`
`
`
`
`
`
`
`the academicside, 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 earlyefforts
`
`
`
`
`
`
`
`
`focusing on programmable networks. Section III provides an
`overview of SDN andits 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-
`
`
`
`
`
`
`
`
`
`
`ate, and OpenFlowin particular has been touted as a “radical
`
`
`
`
`
`
`
`
`new idea in networking” [5]. The proposed benefits range
`
`
`
`
`
`from centralized control, simplified algorithms, commoditiz-
`
`
`
`
`
`
`ing network hardware, eliminating middleboxes, to enabling
`
`
`
`
`
`
`
`the design and deployment of third-party ‘apps’.
`
`
`
`
`
`
`
`While OpenFlowhas received considerable attention from
`
`
`
`
`
`
`
`
`
`
`industry, it is worth noting that the idea of programmable
`
`
`
`
`
`
`
`
`
`networks and decoupled control logic has been around for
`
`
`
`
`
`
`
`
`
`
`
`many years. In this section, we provide an overview of early
`
`
`
`
`
`
`
`programmable networking efforts, precursors to the current
`
`1553-877X/14/$31.00 © 2014 IEEE
`
`
`
`
`Manuscript received June 14, 2013; revised October 28, 2013.
`
`
`
`
`
`
`
`
`
`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)
`
`
`
`
`M. Mendonca and K. Obraczka are with UC Santa Cruz (e-mail: {msm,
`
`
`
`
`
`
`
`
`
`
`
`katia} @soe.ucsc.edu)
`
`
`Digital Object Identifier 10.1109/SURV.2014.012214.00180
`
`
`
`
`
`
`
`
`
`
`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
`
`Exhibit 1009
`Cisco v. Orckit – IPR2023-00554
`Page 1 of 18
`
`

`

`1618
`
`
`
`IEEE COMMUNICATIONS 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 necessarybut 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 deploymentof new services through a distributed program-
`
`
`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-
`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 groupis officially concluded and the latest standards
`
`
`
`
`
`
`
`proposal, GSMPv3, was published in June 2002.
`
`
`
`
`
`
`
`
`
`the
`b) Active Networking: Also in the mid 1990s,
`
`
`
`
`
`
`
`
`
`Active Networking [8],
`initiative proposed the idea of
`[9]
`
`
`
`
`
`
`
`
`a network infrastructure that would be programmable for
`
`
`
`
`
`
`
`
`customized services. There were two main approaches being
`
`
`
`
`
`
`considered, namely: (1) user-programmable switches, with in-
`
`
`
`
`
`
`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-
`
`
`
`
`
`
`
`
`ical mass and transferred to widespread use and industry
`
`
`
`
`
`
`
`deployment, mainly due to practical security and performance
`concerns [10].
`
`
`
`
`
`
`
`
`
`
`
`took place in the
`c) DCAN: Another initiative that
`mid 1990s
`the Devolved Control of ATM Networks
`is
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`(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-
`
`
`
`
`
`
`
`
`
`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 externalentities dedicated
`
`
`
`
`
`
`
`
`
`
`to that purpose, which is basically the concept behind SDNs.
`
`
`
`
`
`
`
`
`DCANassumes a minimalist protocol between the manager
`
`
`
`
`
`
`
`
`
`
`
`and the network,
`in the lines of what happens today in
`
`
`
`
`
`
`
`
`
`
`proposals such as OpenFlow. More on the DCANproject 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],
`
`
`
`
`
`
`
`
`
`[16] advocated a clean slate design that emphasized
`
`
`
`
`
`
`
`
`
`separation between the routing decision logic and the pro-
`
`
`
`
`
`
`
`tocols governing the interaction between network elements.
`
`
`
`
`
`
`
`
`
`
`
`It proposed giving the “decision” plane a global view ofthe
`
`
`
`
`
`
`
`
`network, serviced by a “dissemination” and “discovery”plane,
`
`
`
`
`
`
`
`
`
`
`for controlof a “data” plane for forwardingtraffic. 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:
`the IETF Network Configu-
`In 2006,
`
`
`
`
`
`
`
`
`
`ration Working Group proposed NETCONF [18] as a man-
`
`
`
`
`
`
`
`
`agementprotocol 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 managementprotocol, 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
`
`
`
`
`
`
`
`managementprotocol, 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 configurationsettings.
`
`
`
`
`
`
`
`
`
`
`
`
`It later became apparentthat in spite of what it was originally
`
`
`
`
`
`
`
`
`
`
`intended for, SNMP wasnotbeing 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 wasits lack
`
`
`
`
`
`
`
`
`
`
`
`
`of strong security. This was addressed in a later version of the
`
`protocol.
`
`
`
`
`
`
`
`
`
`
`the time it was proposed by IETF, was
`NETCONF, at
`
`
`
`
`
`
`
`
`
`
`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 NETCONFshould 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
`
`
`
`
`
`
`
`
`
`
`maybe used in parallel on hybrid switches supporting other
`
`
`
`
`
`solutions that enable programmable networking.
`
`
`
`
`
`
`
`
`The NETCONFworking group is currently active and the
`
`
`
`
`
`
`
`
`latest proposed standard was published in June 2011.
`
`
`
`
`
`
`
`
`J) Ethane: The immediate predecessor to OpenFlow was
`
`
`
`
`
`
`
`
`
`the SANE / 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 exampleis providing identity-
`
`
`
`
`
`
`
`
`
`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 Ethanein the context of
`
`
`
`
`
`
`
`today’s SDN paradigm, Ethane’s identity-based access control
`
`
`
`[15],
`
`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
`
`Exhibit 1009
`Cisco v. Orckit – IPR2023-00554
`Page 2 of 18
`
`

`

`NUNESer 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
`SDNcontroller such as NOX [17], Maestro [21], Beacon [22],
`
`
`
`
`
`
`
`
`
`SNAC [23], Helios [24], etc.
`
`
`
`
`
`
`
`
`
`I. SOFTWARE-DEFINED NETWORKING
`
`
`ARCHITECTURE
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`7) 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 newforwarding 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 ForCESprotocolto instruct FEs on
`
`
`
`
`
`
`
`
`
`how to handle packets. The protocol works based on a master-
`slave model, where FEs are slaves and CEs are masters.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Animportant building block of the ForCESarchitecture is
`
`
`
`
`
`
`
`
`
`
`the LFB (Logical Function Block). The LFB is a well-defined
`
`
`
`
`
`
`
`
`
`
`
`functional block residing on the FEsthat is controlled by CEs
`
`
`
`
`
`
`
`
`
`
`
`via the ForCESprotocol. The LFB enables the CEsto 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.
`
`
`
`
`
`
`
`
`
`the
`In the OpenFlowarchitecture, illustrated in Figure 2,
`
`
`
`
`
`
`
`
`
`forwarding device, or OpenFlowswitch, contains one or more
`
`
`
`
`
`
`
`
`flowtables 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 ofinstructions,
`
`
`
`
`
`
`
`
`
`
`
`
`or actions, to be applied upon a match; they dictate how to
`
`
`
`handle matching packets.
`
`
`
`
`
`
`
`
`
`Upon a packetarrival at an OpenFlowswitch, 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 flowentry. 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
`
`
`
`
`
`
`
`
`
`
`
`bythe table-miss flow entry. Every flow table must contain a
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`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,
`is quite difficult for current
`it
`
`
`
`
`
`
`
`network infrastructure to evolve; in other words, deploying
`
`
`
`
`
`
`
`
`
`new versionsof 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 meansthat 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 networkinfrastructure 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 fromthe control logic allows easier
`
`
`
`
`
`
`
`deploymentof 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.
`
`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
`
`Exhibit 1009
`Cisco v. Orckit – IPR2023-00554
`Page 3 of 18
`
`

`

`1620
`
`IEEE COMMUNICATIONS SURVEYS & TUTORIALS,VOL. 16, NO. 3, THIRD QUARTER 2014
`
`decoupled control>4 embedded control
`
`.
`
`Software
`Control
`=j
`
`i'
`
`|=5 SDN Controller
`
`¥ Middlebox(e.g. Firewall)
`| Forwarding device with Fagg
`Forwardingdevice with
`
`“
`
`‘
`
`.
`
`''' S
`
`Traditional Network
`(with distributed control and middleboxes)
`
`oftware-Defined Network
`(with decoupled control)
`
`|. The SDNarchitecture decouples control logic from the forwarding hardware, and enables the consolidation of middleboxes, simpler policy management,
`Fig.
`and newfunctionalities. The solid lines define the data-plane links and the dashed lines the control-plane links.
`
`CONTROLLER
`
`OpenFlow Protocol
`
` OPENFLOW CLIENT
`
`OPENFLOW
`SWITCH
`
` IP src/dst , MAC src/dst,
`
`Transport Src/Dst, VLAN ...
`
` Packets, Bytes, Duration
`
`Forwardto port(s)
`Forward to the controller
`Modify headerfields
`Drop
`
`Fig. 2. Communication between the controller and the forwarding devices happens 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 flowstatistics.
`
`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-OpenFlowports, 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 betweenthese 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.
`the similarities and differences
`3) Discussion:
`In [26],
`between ForCES and OpenFlow are discussed. Among the
`differences, they highlight the fact that the forwarding model
`used by ForCESrelies 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
`
`

`

`NUNESer al.: A SURVEY OF SOFTWARE-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-
`
`
`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-
`
`
`
`
`
`
`
`
`
`sive. The resulting critical mass from these different sectors
`
`
`
`
`
`
`
`
`
`
`has produceda significant numberof 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-
`
`
`
`
`
`
`bound communication) and network applications (northbound
`
`
`
`
`
`
`
`
`
`
`communication). Section IV also has an OpenFlow focusasit
`
`
`
`
`
`
`
`
`describes existing platforms for SDN developmentandtesting,
`
`
`
`
`
`
`
`including emulation and simulation tools, SDN controller im-
`
`
`
`
`
`
`
`
`
`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-
`
`
`
`
`
`
`
`
`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-
`
`
`
`
`
`
`
`
`
`
`
`ware accessible via an open interface at an abstraction layer, as
`
`
`
`
`
`
`
`
`
`
`the control logic and algorithmsare off-loaded to a controller.
`
`
`
`
`
`
`
`
`
`Such forwarding devices are commonlyreferred to, in SDN
`
`
`
`
`
`
`
`
`
`terminology, simply as “switches”, as illustrated in Figure 3.
`
`
`
`
`
`
`
`
`In an OpenFlow network, switches come in two vari-
`
`
`
`
`
`
`
`
`
`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
`
`
`
`
`
`
`
`
`OpenFlowin addition to traditional operation and protocols.
`
`
`
`
`
`
`
`Most commercial switches available today are hybrids.
`
`
`
`
`
`
`1) Processing Forwarding Rules: Flow-based SDN archi-
`
`
`
`
`
`
`
`
`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-
`
`
`
`
`
`
`
`
`
`
`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 greaterflexibility 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 OpenFlowswitching in
`
`
`
`
`
`
`
`Linux was proposed, Preliminary results reported showed a
`packet switching throughput increase of up to