Software-Defined Networking A Comprehensive Survey --阅读_day2

3. 什么是SDN？(WHAT IS SOFTWARE-DEFINED NETWORKING?)

    The term SDN was originally coined to represent the ideas and work around OpenFlow at Stanford University, Stanford, CA, USA [24]. As originally defined, SDN refers to a network architecture where the forwarding state in the data plane is managed by a remotely controlled plane decoupled from the former. The networking industry has on many occasions shifted from this original view of SDN by referring to anything that involves software as being SDN.

    We therefore attempt, in this section, to provide a much less ambiguous definition of SDN. We define an SDN as a network architecture with four pillars.

    (1) The control and data planes are decoupled. Control functionality is removed from network devices that will become simple (packet) forwarding elements.

    (2) Forwarding decisions are flow based, instead of destination based. A flow is broadly defined by a set of packet field values acting as a match (filter) criterion and a set of actions (instructions). In the SDN/OpenFlow context, a flow is a sequence of packets between a source and a destination. All packets of a flow receive identical service policies at the forwarding devices [25], [26]. The flow abstraction allows unifying the behavior of different types of network devices, including routers, switches, firewalls, and middleboxes [27]. Flow programming enables unprecedented flexibility, limited only to the capabilities of the implemented flow tables [9].

    (3) Control logic is moved to an external entity, the so-called SDN controller or NOS. The NOS is a software platform that runs on commodity server technology and provides the essential resources and abstractions to facilitate the programming of forwarding devices based on a logically centralized, abstract network view. Its purpose is therefore similar to that of a traditional operating system.

    (4) The network is programmable through software applications running on top of the NOS that interacts with the underlying data plane devices. This is a fundamental characteristic of SDN, considered as its main value proposition.

    Note that the logical centralization of the control logic, in particular, offers several additional benefits. First, it is simpler and less error prone to modify network policies through high-level languages and software components, compared with low-level device specific configurations. Second, a control program can automatically react to spurious changes of the network state and thus maintain the high-level policies intact. Third, the centralization of the control logic in a controller with global knowledge of the network state simplifies the development of more sophisticated networking functions, services, and applications.

    Following the SDN concept introduced in [5], an SDN can be defined by three fundamental abstractions: forwarding, distribution, and specification. In fact, abstractions are essential tools of research in computer science and information technology, being already an ubiquitous feature of many computer architectures and systems [28].

    Ideally, the forwarding abstraction should allow any forwarding behavior desired by the network application (the control program) while hiding details of the underlying hardware. OpenFlow is one realization of such abstraction, which can be seen as the equivalent to a ‘‘device driver’’ in an operating system.

    The distribution abstraction should shield SDN applications from the vagaries of distributed state, making the distributed control problem a logically centralized one. Its realization requires a common distribution layer, which in SDN resides in the NOS. This layer has two essential functions. First, it is responsible for installing the control commands on the forwarding devices. Second, it collects status information about the forwarding layer (network devices and links), to offer a global network view to network applications.

    The last abstraction is specification, which should allow a network application to express the desired network behavior without being responsible for implementing that behavior itself. This can be achieved through virtualization solutions, as well as network programming languages. These approaches map the abstract configurations that the applications express based on a simplified, abstract model of the network, into a physical configuration for the global network view exposed by the SDN controller. Fig. 4 depicts the SDN architecture, concepts, and building blocks.

    As previously mentioned, the strong coupling between control and data planes has made it difficult to add new functionality to traditional networks, a fact illustrated in Fig. 5. The coupling of the control and data planes (and its physical embedding in the network elements) makes the development and deployment of new networking features (e.g., routing algorithms) very difficult, since it would imply a modification of the control plane of all network devicesVthrough the installation of new firmware and, in some cases, hardware upgrades. Hence, the new networking features are commonly introduced via expensive, specialized, and hard-to-configure equipment (also known as middleboxes) such as load balancers, intrusion detection systems (IDSs), and firewalls, among others. These middleboxes need to be placed strategically in the network, making it even harder to later change the network topology, configuration, and functionality.

    In contrast, SDN decouples the control plane from the network devices and becomes an external entity: the NOS or SDN controller. This approach has several advantages.

    • It becomes easier to program these applications since the abstractions provided by the control platform and/or the network programming languages can be shared.

    • All applications can take advantage of the same network information (the global network view), leading (arguably) to more consistent and effective policy decisions, while reusing control plane software modules.

    • These applications can take actions (i.e., reconfigure forwarding devices) from any part of the network. There is therefore no need to devise a precise strategy about the location of the new functionality.

    • The integration of different applications becomes more straightforward [29]. For instance, load balancing and routing applications can be combined sequentially, with load balancing decisions having precedence over routing policies.

SDN指的是一种网络结构，其中数据面中的转发状态由与前者解耦的远程控制面管理。

网络产业在许多场合已经从SDN最初的观点转变，将任何涉及软件的东西称为SDN。

SDN定义为具有四个核心的网络架构,分别为：

(1) 控制和数据平面是分离的。控制功能将从网络设备中删除，这些设备将成为简单的(数据包)转发元素。

(2) 转发决策是基于流的，而不是基于目标的。

(3) 控制逻辑被移动到外部实体。

(4) 网络是可编程的。

控制逻辑的逻辑集中化，还有几个额外的好处：

(1) 通过高级语言和软件组件修改网络策略更简单、错误更少

(2) 控制程序可以自动地对网络状态的虚假变化作出反应，从而保持高层策略的完整性。

(3) 简化了更复杂的网络功能、服务和应用程序的开发。

SDN可以通过三个基本的抽象概念来定义：

[forwarding, distribution, specification]

控制面和数据面之间的紧密耦合使得传统网络很难添加新功能。相反，SDN将控制面与网络设备分离，并成为外部实体。这种方法有几个优点：

(1) 可以共享控制平台和网络编程语言提供的抽象，所以编写这些应用程序变得更加容易。

(2) 在重用控制平面软件模块的同时，所有应用程序都可以利用相同的网络信息(全局网络视图)，导致更一致的和更有效的策略决策。

(3) 这些应用程序可以从网络的任何部分执行操作

(4) 不同应用程序的集成变得更加简单

    To identify the different elements of an SDN as unequivocally as possible, we now present the essential terminology used throughout this work.

    1) Forwarding Devices (FD): These are hardware- or software-based data plane devices that perform a set of elementary operations. The forwarding devices have welldefined instruction sets (e.g., flow rules) used to take actions on the incoming packets (e.g., forward to specific ports, drop, forward to the controller, rewrite some header). These instructions are defined by southbound interfaces (e.g., OpenFlow [9], ForCES [30], protocoloblivious forwarding (POF) [31]) and are installed in the forwarding devices by the SDN controllers implementing the southbound protocols.

    2) Data Plane (DP): Forwarding devices are interconnected through wireless radio channels or wired cables. The network infrastructure comprises the interconnected forwarding devices, which represent the data plane.

    3) Southbound Interface (SI): The instruction set of the forwarding devices is defined by the southbound API, which is part of the southbound interface. Furthermore, the SI also defines the communication protocol between forwarding devices and control plane elements. This protocol formalizes the way the control and data plane elements interact.

    4) Control Plane (CP): Forwarding devices are programmed by control plane elements through well-defined SI embodiments. The control plane can therefore be seen as the ‘‘network brain.’’ All control logic rests in the applications and controllers, which form the control plane.

    5) Northbound Interface (NI): The NOS can offer an API to application developers. This API represents a northbound interface, i.e., a common interface for developing applications. Typically, a northbound interface abstracts the low-level instruction sets used by southbound interfaces to program forwarding devices.

    6) Management Plane (MP): The management plane is the set of applications that leverage the functions offered by the NI to implement network control and operation logic. This includes applications such as routing, firewalls, load balancers, monitoring, and so forth. Essentially, a management application defines the policies, which are ultimately translated to southbound-specific instructions that program the behavior of the forwarding devices.

a: SDN中的一些基本术语：

(1) 转发装置（FD）

(2) 数据面(DP)

(3) 南向接口(SI)

(4) 控制面(CP)

(5) 北向接口(NI)

(6) 管理面(MP)

    Since its inception in 2010 [24], the original Open- Flow-centered SDN term has seen its scope broadened beyond architectures with a cleanly decoupled control plane interface. The definition of SDN will likely continue to broaden, driven by the industry business-oriented views on SDN-Virrespective of the decoupling of the control plane. In this survey, we focus on the original, ‘‘canonical’’ SDN definition based on the aforementioned key pillars and the concept of layered abstractions. However, for the sake of completeness and clarity, we acknowledge alternative SDN definitions [32], as follows. 

    1) Control Plane/Broker SDN: A networking approach that retains existing distributed control planes but offers new APIs that allow applications to interact (bidirectionally) with the network. An SDN controller-often called orchestration platform-acts as a broker between the applications and the network elements. This approach effectively presents control plane data to the application and allows a certain degree of network programmability by means of ‘‘plug-ins’’ between the orchestrator function and network protocols. This API-driven approach corresponds to a hybrid model of SDN, since it enables the broker to manipulate and directly interact with the control planes of devices such as routers and switches. Examples of this view on SDN include recent standardization efforts at the Internet Engineering Task Force (IETF) (see Section III-C) and the design philosophy behind the OpenDaylight project [13] that goes beyond the OpenFlow split control mode.

    2) Overlay SDN: This is a networking approach where the (software- or hardware-based) network edge is dynamically programmed to manage tunnels between hypervisors and/or network switches, introducing an overlay network. In this hybrid networking approach, the distributed control plane providing the underlay remains untouched. The centralized control plane provides a logical overlay that utilizes the underlay as a transport network. This flavor of SDN follows a proactive model to install the overlay tunnels. The overlay tunnels usually terminate inside virtual switches within hypervisors or in physical devices acting as gateways to the existing network. This approach is very popular in recent data center network virtualization [33], and are based on a variety of tunneling technologies (e.g., stateless transport tunneling [34], virtualized layer 2 networks (VXLAN) [35], network virtualization using generic routing encapsulation (NVGRE) [36], locator/ID separation protocol (LISP) [37], [38], and generic network virtualization encapsulation (GENEVE) [39]) [40]. 

    Recently, other attempts to define SDN in a layered approach have appeared [16], [41]. From a practical perspective and trying to keep backward compatibility with existing network management approaches, one initiative in the IRTF Software-Defined Networking Research Group (SDNRG) [41] proposes a management plane at the same level of the control plane, i.e., it classifies solutions in two categories: control logic (with control plane southbound interfaces) and management logic (with management plane southbound interfaces). In other words, the management plane can be seen as a control platform that accommodates traditional network management services and protocols, such as SNMP [18], BGP [42], path computation element communication protocol (PCEP) [43], and network configuration protocol (NETCONF) [44].

    In addition to the broadening definitions above, the term SDN is often used to define extensible network management planes (e.g., OpenStack [45]), whitebox/baremetal switches with open operating systems (e.g., Cumulus Linux), open-source data planes (e.g., Pica8 Xorplus [46], Quagga [47]), specialized programmable hardware devices (e.g., NetFPGA [48]), virtualized software-based appliances (e.g., open platform for network functions virtualization (OPNFV) [49]), in spite of lacking a decoupled control and data plane or common interface along its API. Hybrid SDN models are further discussed in Section V-G. 

b: 其他的和扩大的定义

自2010年创立以来，最初的以开放流为中心的SDN术语已经将其范围扩大到了架构之外，并具有一个清晰的分离控制面接口，且SDN的定义很可能会继续扩大。

本文提供了几个可选择的SDN定义：

(1) Control Plane/Broker SDN

(2) Overlay SDN

SDN一词还通常用于定义可扩展的网络管理平面

    The standardization landscape in SDN (and SDNrelated issues) is already wide and is expected to keep evolving over time. While some of the activities are being carried out in standard development organizations (SDOs), other related efforts are ongoing at industrial or community consortia (e.g., OpenDaylight, OpenStack, OPNFV), delivering results often considered candidates for de facto standards. These results often come in the form of open source implementations that have become the common strategy toward accelerating SDN and related cloud and networking technologies [50]. The reason for this fragmentation is due to SDN concepts spanning different areas of IT and networking, both from a network segmentation point of view (from access to core) and from a technology perspective (from optical to wireless. 

    Table 1 presents a summary of the main SDOs and organizations contributing to the standardization of SDN, as well as the main outcomes produced to date.

    The ONF was conceived as a member-driven organization to promote the adoption of SDN through the development of the OpenFlow protocol as an open standard to communicate control decisions to data plane devices. The ONF is structured in several working groups (WGs). Some WGs are focused on either defining extensions to the OpenFlow protocol in general, such as the extensibility WG, or tailored to specific technological areas. Examples of the latter include the optical transport (OT) WG, the wireless and mobile (W&M) WG, and the northbound interfaces (NBI) WG. Other WGs center their activity in providing new protocol capabilities to enhance the protocol itself, such as the architecture WG or the forwarding abstractions (FA) WG.

    Similar to how network programmability ideas have been considered by several IETF working groups (WGs) in the past, the present SDN trend is also influencing a number of activities. A related body that focuses on research aspects for the evolution of the Internet, IRTF, has created the SDNRG. This group investigates SDN from various perspectives with the goal of identifying the approaches that can be defined, deployed, and used in the near term, as well as identifying future research challenges.

    In the International Telecommunications Union’s Telecommunication sector (ITU–T), some study groups (SGs) have already started to develop recommendations for SDN, and a Joint Coordination Activity on SDN (JCASDN) has been established to coordinate the SDN standardization work.

    The Broadband Forum (BBF) is working on SDN topics through the Service Innovation & Market Requirements (SIMR) WG. The objective of the BBF is to release recommendations for supporting SDN in multiservice broadband networks, including hybrid environments where only some of the network equipment is SDN enabled.

    The Metro Ethernet Forum (MEF) is approaching SDN with the aim of defining service orchestration with APIs for existing networks.

    At the IEEE, the 802 LAN/MAN Standards Committee has recently started some activities to standardize SDN capabilities on access networks based on IEEE 802 infrastructure through the P802.1CF project, for both wired and wireless technologies to embrace new control interfaces.

    The Optical Internetworking Forum (OIF) Carrier WG released a set of requirements for transport SDN. The initial activities have as main goal to describe the features and functionalities needed to support the deployment of SDN capabilities in carrier transport networks. The Open Data Center Alliance (ODCA) is an organization working on unifying data center in the migration to cloud computing environments through interoperable solutions. Through the documentation of usage models, specifically one for SDN, the ODCA is defining new requirements for cloud deployment. The Alliance for Telecommunication Industry Solutions (ATIS) created a focus group for analyzing operational issues and opportunities associated with the programmable capabilities of network infrastructure.

    At the European Telecommunication Standards Institute (ETSI), efforts are being devoted to network function virtualization (NFV) through a newly defined Industry Specification Group (ISG). NFV and SDN concepts are considered complementary, sharing the goal of accelerating innovation inside the network by allowing programmability, and altogether changing the network operational model through automation and a real shift to softwarebased platforms.

    Finally, the mobile networking industry 3rd Generation Partnership Project consortium is studying the management of virtualized networks, an effort aligned with the ETSI NFV architecture and, as such, likely to leverage from SDN.

c: 标准化活动

SDN(和SDN相关问题)中的标准化领域已经很广，预计将随着时间的推移而不断发展。

造成分裂的原因是SDN概念跨越了IT和网络的不同领域，无论是从网络分割的角度还是从技术的角度。

主要组织：

(1) ONF

(2) IETF

(3) IRTF

(4) 国际电信联盟电信部门(ITU-T)

(5) 宽带论坛(BBF)

(6) 城域以太网论坛(MEF)

(7) IEEE

(8) 光互连论坛(OIF)

(9) 开放数据中心联盟(ODCA)

(10) 欧洲电信标准协会(ETSI)

(11) ATIS

    Albeit a fairly recent concept, SDN leverages on networking ideas with a longer history [17]. In particular, it builds on work made on programmable networks, such as active networks [81], programmable ATM networks [82], [83], and on proposals for control and data plane separation, such as the network control point (NCP) [84] and routing control platform (BCP) [85]. 

    In order to present a historical perspective, we summarize in Table 2 different instances of SDN-related work prior to SDN, splitting it into five categories. Along with the categories we defined, the second and third columns of the table mention past initiatives (pre-SDN, i.e., before the OpenFlow-based initiatives that sprung into the SDN concept) and recent developments that led to the definition of SDN. 

    Data plane programmability has a long history. Active networks [81] represent one of the early attempts on building new network architectures based on this concept. The main idea behind active networks is for each node to have the capability to perform computations on, or modify the content of, packets. To this end, active networks propose two distinct approaches: programmable switches and capsules. The former does not imply changes in the existing packet or cell format. It assumes that switching devices support the downloading of programs with specific instructions on how to process packets. The second approach, on the other hand, suggests that packets should be replaced by tiny programs, which are encapsulated in transmission frames and executed at each node along their path.

    ForCES [30], OpenFlow [9], and POF [31] represent recent approaches for designing and deploying programmable data plane devices. In a manner different from active networks, these new proposals rely essentially on modifying forwarding devices to support flow tables, which can be dynamically configured by remote entities through simple operations such as adding, removing, or updating flow rules, i.e., entries on the flow tables. 

    The earliest initiatives on separating data and control signaling date back to the 1980s and 1990s. The NCP [84] is probably the first attempt to separate control and data plane signaling. NCPs were introduced by AT&T to improve the management and control of its telephone network. This change promoted a faster pace of innovation of the network and provided new means for improving its efficiency, by taking advantage of the global view of the network provided by NCPs. Similarly, other initiatives such as Tempest [96], ForCES [30], RCP [85], and PCE [43] proposed the separation of the control and data planes for improved management in ATM, Ethernet, BGP, and multiprotocol label switching (MPLS) networks, respectively.

    More recently, initiatives such as SANE [100], Ethane [101], OpenFlow [9], NOX [26], and POF [31] proposed the decoupling of the control and data planes for Ethernet networks. Interestingly, these recent solutions do not require significant modifications on the forwarding devices, making them attractive not only for the networking research community, but even more to the networking industry. OpenFlow-based devices [9], for instance, can easily coexist with traditional Ethernet devices, enabling a progressive adoption (i.e., not requiring a disruptive change to existing networks).

    Network virtualization has gained a new traction with the advent of SDN. Nevertheless, network virtualization also has its roots back in the 1990s. The Tempest project [96] is one of the first initiatives to introduce network virtualization, by introducing the concept of switchlets in ATM networks. The core idea was to allow multiple switchlets on top of a single ATM switch, enabling multiple independent ATM networks to share the same physical resources. Similarly, MBone [102] was one of the early initiatives that targeted the creation of virtual network topologies on top of legacy networks, or overlay networks. This work was followed by several other projects such as Planet Lab [105], GENI [107], and VINI [108]. FlowVisor [119] is also worth mentioning as one of the first recent initiatives to promote a hypervisor-like virtualization architecture for network infrastructures, resembling the hypervisor model common for compute and storage. More recently, Koponen et al. proposed a network virtualization platform (NVP) [112] for multitenant data centers using SDN as a base technology.

    The concept of a NOS was reborn with the introduction of OpenFlow-based NOSs, such as NOX [26], Onix [7], and ONOS [117]. Indeed, NOSs have been in existence for decades. One of the most widely known and deployed is the Cisco IOS [113], which was originally conceived back in the early 1990s. Other NOSs worth mentioning are JUNOS [114], ExtremeXOS [115], and SR OS [116]. Despite being more specialized NOSs, targeting network devices such as high-performance core routers, these NOSs abstract the underlying hardware to the network operator, making it easier to control the network infrastructure as well as simplifying the development and deployment of new protocols and management applications.

    Finally, initiatives that can be seen as ‘‘technology pull’’ drivers are also worth recalling. Back in the 1990s, a movement toward open signaling [118] began to happen. The main motivation was to promote the wider adoption of the ideas proposed by projects such as NCP [84] and Tempest [96]. The open signaling movement worked toward separating the control and data signaling by proposing open and programmable interfaces. Curiously, a rather similar movement can be observed with the recent advent of OpenFlow and SDN, with the lead of the ONF [10]. This type of movement is crucial to promote open technologies into the market, hopefully leading equipment manufacturers to support open standards and thus fostering interoperability, competition, and innovation.

    For a more extensive intellectual history of programmable networks and SDN, we direct the reader to the recent paper by Feamster et al. [17].

d. SDN的历史

尽管这是一个相当新的概念，但是SDN促使其在网络思想方面的改变也有较长历史。尤其是它建立在可编程网络上的工作。

数据面可编程性有着悠久的历史。

最早的分离数据和控制面的举措可以追溯到1980年代和90年代。NCP可能是首次尝试分离控制和数据面。

最近的解决方案不需要对转发设备进行重大修改，这使得它们不仅对网络研究界有吸引力，而且对网络产业更有吸引力。例如，基于OpenFlow的设备可以很容易地与传统的以太网设备共存，从而实现逐步采用(即不需要对现有网络进行破坏性更改)。

随着SDN的出现，网络虚拟化得到了新的发展。然而，网络虚拟化也有它的根源在1990年代。

最近，Koponen等人提出了一种以SDN为基础技术的多租户数据中心网络虚拟化平台(NVP)