An overview of SDN & Openflow

Editor's Notes

• #4: Computer networks can be divided in three planes of functionality: the data, control and management planes. The data plane corresponds to the networking devices, which are responsible for (efficiently) forwarding data. The control plane represents the protocols used to populate the forwarding tables of the data plane elements. The management plane includes the software services, such as SNMP-based tools Network policy is defined in the management plane, the control plane enforces the policy, and the data plane executes it by forwarding data accordingly. In traditional IP networks, the control and data planes are tightly coupled, embedded in the same networking devices, and the whole structure is highly decentralized. This was considered important for the design of the Internet in the early days: it seemed the best way to guarantee network resilience, However, the outcome is a very complex and relatively static architecture
• #5: The control and data planes are decoupled. Control functionality is removed from network devices that will become simple (packet) forwarding elements. 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. The flow abstraction allows unifying the behavior of different types of network devices, including routers, switches, firewalls, and middleboxes. Flow programming enables unprecedented flexibility, limited only to the capabilities of the implemented flow tables Control logic is moved to an external entity, the socalled SDN controller or Network Operating System (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. 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
• #6: 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 hide the distributed nature of the network from SDN applications, making the distributed control problem a logically centralized one. To do this, we need 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. Figure depicts the SDN architecture, concepts and building blocks.
• #7: This figure presents a tri-fold perspective of SDNs. The SDN layers are represented in the center of the figure, as explained above. Figures to the left and right, depict a plane-oriented view and a system design perspective, respectively. We are going to explain each of the layers from bottom to top in the next slides.
• #8: An SDN infrastructure, similarly to a traditional network, is composed of a set of networking equipment (switches, routers and middlebox appliances). The main difference resides in the fact that those traditional physical devices are now simple forwarding elements without embedded control or software to take autonomous decisions. The network intelligence is removed from the data plane devices to a logically-centralized control system, i.e., the network operating system and applications. More importantly, these new networks are built (conceptually) on top of open and standard interfaces (e.g., OpenFlow), a crucial approach for ensuring configuration and communication compatibility and interoperability among different data and control plane devices. In other words, these open interfaces enable controller entities to dynamically program heterogeneous forwarding devices, something difficult in traditional networks, due to the large variety of proprietary and closed interfaces and the distributed nature of the control plane.
• #9: An OpenFlow-enabled forwarding device is based on a pipeline of flow tables where each entry of a flow table has three parts: (1) a matching rule, (2) actions to be executed on matching packets, and (3) counters that keep statistics of matching packets.
• #10: Southbound interfaces (or southbound APIs) are the connecting bridges between control and forwarding elements, thus being the crucial instrument for clearly separating control and data plane functionality. However, these APIs are still tightly tied to the forwarding elements of the underlying physical or virtual infrastructure. OpenFlow is the most widely accepted and deployed open southbound standard for SDN. The OpenFlow protocol provides three information sources for network operating systems. First, event-based messages are sent by forwarding devices to the controller when a link or port change is triggered. Second, flow statistics are generated by the forwarding devices and collected by the controller. Third, packet-in messages are sent by forwarding devices to the controller when they do not known what to do with a new incoming flow or because there is an explicit “send to controller” action in the matched entry of the flow table. These information channels are the essential means to provide flow-level information to the network operating system.
• #11: To enhance understanding of network operation systems, its good to look at a desktop computer operating system. Traditional operating systems provide abstractions (e.g., high-level programming APIs) for accessing lower-level devices. These functionalities, make the life of system and application developers easier. In contrast, networks have so far been managed and configured using lower level, device-specific instruction sets and mostly closed proprietary network operating systems (e.g., Cisco IOS and Juniper JunOS). For instance, nowadays designers of routing protocols need to deal with complicated distributed algorithms when solving networking problems.
• #12: SDN is solving networking problems by means of the centralized control offered by a network operating system. As with traditional operating systems, the crucial value of a NOS is to provide abstractions, essential services, and common application programming interfaces (APIs) to developers. Generic functionality as network state and network topology information, device discovery, and distribution of network configuration can be provided as services of the NOS. With NOSs, to define network policies a developer no longer needs to care about the low-level details of data distribution among routing elements, for instance.
• #13: Existing controllers can be categorized based on many aspects. From an architectural point of view, one of the most relevant is if they are centralized or distributed. A centralized controller is a single entity that manages all forwarding devices of the network. Naturally, it represents a single point of failure and may have scaling limitations. But they can be designed as highly concurrent systems, to achieve the throughput required by enterprise class networks and data centers. A distributed controller can be a centralized cluster of nodes or a physically distributed set of elements. While the first alternative can offer high throughput for very denseVERSION 2.01 16 data centers, the latter can be more resilient to different kinds of logical and physical failures. Most distributed controllers offer weak consistency semantics, which means that data updates on distinct nodes will eventually be updated on all controller nodes. This implies that there is a period of time in which distinct nodes may read different values (old value or new value) for a same property. Another common property of distributed controllers is fault tolerance. When one node fails, another neighbor node should take over the duties and devices of the failed node.
• #15: The base network service functions are what we consider the essential functionality all controllers should provide. these functions are like base services of operating systems, such as program execution, I/O operations control, communications, protection, and so on. In a similar way, functions such as topology, statistics, notifications and device management, together with shortest path forwarding and security mechanisms are essential network control functionalities that network applications may use in building its logic. For instance, the notification manager should be able to receive, process, and forward events
• #16: On the lower-level of control platforms, the southbound APIs can be seen as a layer of device drivers. They provide a common interface for the upper layers, while allowing a control platform to use different southbound APIs (e.g., OpenFlow, OVSDB, ForCES) . This is essential both for backward compatibility and heterogeneity, i.e., to allow multiple protocols and device management connectors. Therefore, on the data plane, a mix of physical devices, virtual devices and a variety of device interfaces (e.g., OpenFlow, OVSDB, NetConf, and SNMP) can co-exist
• #17: East/westbound APIs, are a special case of interfaces required by distributed controllers. The functions of these interfaces include import/export data between controllers, algorithms for data consistency models, and monitoring/notification capabilities (e.g., check if a controller is up or notify a take over on a set of forwarding devices).
• #18: So to wrap up, controller is one of the critical points for the success of SDN and in a controller the most important parts are southbound and northbound APIs because they provide interoperability between different hardware and applications.
• #19: The North- and Southbound interfaces are two key abstractions of the SDN ecosystem. The southbound interface has already a widely accepted proposal (OpenFlow), but a common northbound interface is still an open issue. At this moment it may still be a bit too early to define a standard northbound interface, as use-cases are still being worked out. An abstraction that would allow network applications not to depend on specific implementations is important to explore the full potential of SDN The northbound interface is mostly a software ecosystem, not a hardware one as is the case of the southbound APIs. In these ecosystems, the implementation is commonly the forefront driver, while standards emerge later and are essentially driven by wide adoption. A northbound API can be compared to the POSIX standard in operating systems, representing an abstraction that guarantees programming language and controller independence. NOSIX [245] is one of the first examples of an effort in this direction. It tries to define portable low-level (e.g., flow model) application interfaces, making southbound APIs such as OpenFlow look like “device drivers”.
• #21: Network applications can be seen as the “network brains”. They implement the control-logic that will be translated into commands to be installed in the data plane, dictating the behavior of the forwarding devices. Take a simple application as routing as an example. The logic of this application is to define the path through which packets will flow from a point A to a point B. To achieve this goal a routing application has to, based on the topology input, decide on the path to use and instruct the controller to install the respective forwarding rules in all forwarding devices on the chosen path, from A to B