Modern Network Requirements

The Open Data Center Alliance (ODCA) provides a good, concise list of requirements for a modern networking approach, which includes the following [ODCA14]:

• Adaptability: Networks must adjust and respond dynamically, based on application needs, business policy, and network conditions.

• Automation: Policy changes must be automatically propagated so that manual work and errors can be reduced.

• Maintainability: Introduction of new features and capabilities (e.g., software upgrades, patches), must be seamless, with minimal disruption of operations.

• Model management: Network management software must allow management of the network at a model level rather than implementing conceptual changes by reconfiguring individual network elements.

• Mobility: Control functionality must accommodate mobility, including mobile user devices and virtual servers.

• Integrated security: Network applications must integrate seamless security as a core service instead of as an add-on solution.

• On-demand scaling: Implementations must have the ability to scale up or scale down the network and its services to support on-demand requests.

SDN Architecture

The central concept behind SDN is to enable developers and network managers to have the same type of control over network equipment that they have had over x86 servers. The SDN approach splits the switching function between a data plane and a control plane that are on separate devices (see Figure 7.1b). The data plane is simply responsible for forwarding packets, and the control plane provides the “intelligence” in designing routes, setting priority and routing policy parameters to meet quality of service (QoS) and quality of experience (QoE) requirements, and coping with the shifting traffic patterns. Open interfaces are defined so that the switching hardware presents a uniform interface, regardless of the internal implementation details. Similarly, open interfaces are defined to enable networking applications to communicate with the SDN controllers.

Figure 7.2 illustrates the SDN architecture. The data plane consists of physical switches and virtual switches, both of which are responsible for forwarding packets. The internal implementation of buffers, priority parameters, and other data structures related to forwarding can be vendor dependent. However, each switch must implement a model, or an abstraction, of packet forwarding that is uniform and open to the SDN controllers. This model is defined in terms of an open API between the control plane and the data plane (i.e., the southbound API). The most prominent example of such an open API is OpenFlow, discussed later in this chapter. The OpenFlow specification defines both a protocol between the control and data planes and an API by which the control plane can invoke the OpenFlow protocol.

It should be noted that SDN is capable of dealing with physical switches for both wireless (e.g., Wi-Fi, cellular) and wired (e.g., Ethernet) transmission links.

Similarly, SDN controllers can be implemented directly on a server or on a virtual server. OpenFlow or some other open API is used to control the switches in the data plane. In addition, controllers use information about capacity and demand obtained from the networking equipment through which the traffic flows. SDN controllers also expose northbound APIs, which means developers and network managers can deploy a wide range of off-the-shelf and custom-built network applications, many of which were not feasible prior to the advent of SDN. As yet there is no standardized northbound API, and there is no consensus on an open northbound API.

In simple terms, the SDN controller manages the forwarding state of the switches in the software-defined network. This management is done through a vendor-neutral API that allows the controller to address a wide variety of operator requirements without changing any of the lower-level aspects of the network, including topology.

With the decoupling of the control and data planes, SDN enables applications to deal with a single abstracted network device, without concern for the details of how the device operates. Network applications see a single API to the controller. Thus it is possible to quickly create and deploy new applications to orchestrate network traffic flow to meet specific enterprise requirements for performance or security.

There are also horizontal (peer-to-peer) APIs. These APIs are of two types:

• Eastbound API: Enables communication and cooperation among groups or federations of controllers.

• Westbound API: Provides communication between SDN and non-SDN (or legacy) networks.

At the application plane, a variety of applications interact with SDN controllers. SDN applications are programs that may use an abstract view of the network for their decision-making goals. These applications convey their network requirements and desired network behavior to the SDN controller via a northbound API. Examples of applications are energy-efficient networking, security monitoring, access control, and network management.

Characteristics of Software-Defined Networking

The key characteristics of SDN are as follows:

• The control plane is separated from the data plane. Data plane devices are simple packet-forwarding devices (refer to Figure 7.1).

• The control plane is implemented in a centralized controller or set of coordinated centralized controllers. The SDN controller has a centralized view of the network or networks under its control. The controller is portable software that can run on commodity servers and is capable of programming the forwarding devices based on a centralized view of the network.

• Open interfaces are defined between the devices in the control plane (controllers) and those in the data plane.

• The network is programmable by applications running on top of the SDN controllers. The SDN controllers present an abstract view of network resources to the applications.

Data Plane Functions

Figure 7.3 illustrates the functions performed by the data plane network devices (also called data plane network elements, or switches).

The principal functions of the network device are the following:

• Control support function: Interacts with the SDN control layer to support programmability via resource-control interfaces. The switch communicates with the controller, and the controller manages the switch via the OpenFlow switch protocol.

• Data forwarding function: Accepts incoming data flows from other network devices and end systems and forwards them along the data forwarding paths that have been computed and established according to the rules defined by the SDN applications.

The forwarding rules used by the network device are embodied in forwarding tables that indicate for given categories of packets what the next hop in the route should be. In addition to simple forwarding of a packet, the network device can alter the packet header before forwarding, or discard the packet. As shown, arriving packets may be placed in an input queue, where they await processing by the network device. Forwarded packets are generally placed in an output queue, where they await transmission.

The network device in Figure 7.3 is shown with three I/O ports: one providing control communication with an SDN controller, and two for the input and output of data packets. This is a simple example. A network device may have multiple ports to communicate with multiple SDN controllers and may have more than two I/O ports for packet flows into and out of the device.

Data Plane Protocols

Figure 7.3 suggests the protocols supported by the network device. Data packet flows consist of streams of IP packets. It may be necessary for the forwarding table to define entries based on fields in upper-level protocol headers, such as headers for Transmission Control Protocol (TCP), User Datagram Protocol (UDP), or some other transport or application protocol. The network device examines the IP header and possibly other headers in each packet and makes a forwarding decision.

The other important flow of traffic is via the southbound API, consisting of OpenFlow protocol data units (PDUs) or some similar southbound API protocol traffic.

Flow Table Structure

The basic building block of the logical switch architecture is the flow table. Each packet that enters a switch passes through one of more flow tables. Each flow table consists of a number of rows, called entries, consisting of seven components (see Figure 7.6a). The entry components are as follows:

• Match fields: These fields are used to select packets that match the values in the fields. The match fields (see Figure 7.6b) identify ingress and egress addresses at various protocol levels. Each of the fields in the match fields component either has a specific value or a wildcard value that matches any value in the corresponding packet header field. A flow table may include a table-miss flow entry, in which case wildcards match all fields (i.e., every field is a match, regardless of value), and the entry has the lowest priority.

• Priority: This field shows the relative priority of table entries. It is a 16-bit field with 0 corresponding to the lowest priority. In principle, there could be 216 = 64,000 priority levels.

• Counters: This field is updated for matching packets. The OpenFlow specification defines a variety of counters. Table 7.1 lists the required counters that must be supported by an OpenFlow switch.

  

  Counter	Usage	Bit Length
  Reference count (active entries)	Per flow table	32
  Duration (seconds)	Per flow entry	32
  Received packets	Per port	64
  Transmitted packets	Per port	64
  Duration (seconds)	Per port	32
  Transmit packets	Per queue	64
  Duration (seconds)	Per queue	32
  Duration (seconds)	Per group	32

• Instructions: This field contains instructions to be performed if a match occurs.

• Timeouts: This field indicates the maximum amount of idle time before a flow is expired by the switch. Each flow entry has an idle_timeout and a hard_timeout associated with it. A nonzero hard_timeout field causes the flow entry to be removed after the given number of seconds, regardless of how many packets it has matched. A non-zero idle_timeout field causes the flow entry to be removed when it has matched no packets in the given number of seconds.

• Cookie: This field contains a 64-bit opaque data value chosen by the controller. It may be used by the controller to filter flow statistics, flow modification, and flow deletion; it is not used when processing packets.

• Flags: Flags alter the way flow entries are managed; for example, the flag OFPFF_SEND_FLOW_REM triggers Flow Removed messages (and removes the flow entry) for a flow entry.

It is now possible to offer a more precise definition of the term flow. From the point of view of an individual switch, a flow is a sequence of packets that matches a specific entry in a flow table. The definition is packet oriented in the sense that it is a function of the values of header fields of the packets that constitute the flow and not a function of the path the packets follow through the network. A combination of flow entries on multiple switches defines a flow that is bound to a specific path.

The instructions component of a table entry consists of a set of instructions that are executed if the packet matches the entry. Before describing the types of instructions, we need to define the terms action and action set. Actions describe packet forwarding, packet modification, and group table processing operations. The OpenFlow specification includes the following actions:

• Output: This action forwards a packet to the specified port. The port could be an output port to another switch or the port to the controller. In the latter case, the packet is encapsulated in a message to the controller.

• Set-Queue: This action sets the queue ID for a packet. When the packet is forwarded to a port using the output action, the queue ID determines which queue attached to this port is used for scheduling and forwarding the packet. Forwarding behavior is dictated by the configuration of the queue and is used to provide basic QoS support.

• Group: This action processes a packet through the specified group.

• Push-Tag/Pop-Tag: This action pushes or pops a tag field for a VLAN or Multiprotocol Label Switching (MPLS) packet.

• Set-Field: The various Set-Field actions are identified by their field type and modify the values of the respective header fields in a packet.

• Change-TTL: The various Change-TTL actions modify the values of the IPv4 TTL (time to live), IPv6 hop limit, or MPLS TTL in the packet.

• Drop: There is no explicit action to represent drops. Instead, packets whose action sets have no output action should be dropped.

An action set is a list of actions associated with a packet that are accumulated while the packet is processed by each table and that are executed when the packet exits the processing pipeline.

The types of instructions can be grouped into four categories:

• Direct packet through pipeline: The Goto-Table instruction directs a packet to a table farther along in the pipeline. The Meter instruction directs a packet to a specified meter.

• Perform action on packet: Actions may be performed on a packet when it is matched to a table entry. The Apply-Actions instruction applies the specified actions immediately, without any change to the action set associated with this packet. This instruction may be used to modify the packet between two tables in the pipeline.

• Update action set: The Write-Actions instruction merges specified actions into the current action set for this packet. The Clear-Actions instruction clears all the actions in the action set.

• Update metadata: A metadata value can be associated with a packet. It is used to carry information from one table to the next. The Write-Metadata instruction updates an existing metadata value or creates a new value.

Flow Table Pipeline

A switch includes one or more flow tables. If there is more than one flow table, they are organized as a pipeline, with the tables labeled with increasing numbers starting with 0. The use of multiple tables in a pipeline, rather than a single flow table, provides the SDN controller with considerable flexibility.

The OpenFlow specification defines two stages of processing:

• Ingress processing: Ingress processing always happens, and it begins with table 0 and uses the identity of the input port. Table 0 may be the only table, in which case the ingress processing is simplified to the processing performed on that single table, and there is no egress processing.

• Egress processing: Egress processing is the processing that happens after the determination of the output port. It happens in the context of the output port. This stage is optional. If it occurs, it may involve one or more tables. The separation of the two stages is indicated by the numeric identifier of the first egress table. All tables with a number lower than the first egress table must be used as ingress tables, and no table with a number higher than or equal to the first egress table can be used as an ingress table.

Pipeline processing always starts with ingress processing at the first flow table: The packet must first be matched against flow entries of flow table 0. Other ingress flow tables may be used, depending on the outcome of the match in the first table. If the outcome of ingress processing is to forward the packet to an output port, the OpenFlow switch may perform egress processing in the context of that output port.

When a packet is presented to a table for matching, the input consists of the packet, the identity of the ingress port, the associated metadata value, and the associated action set. For Table 0, the metadata value is blank, and the action set is null. At each table, processing proceeds as follows:

• If there is a match on one or more entries other than the table-miss entry, then the match is defined to be with the highest-priority matching entry. As mentioned in the preceding discussion, the priority is a component of a table entry and is set via OpenFlow; the priority is determined by the user or application invoking OpenFlow. The following steps may then be performed:

Step 1. Update any counters associated with this entry.

Step 2. Execute any instructions associated with this entry. This may include updating the action set, updating the metadata value, and performing actions.

Step 3. The packet is then forwarded to a flow table further down the pipeline, to the group table, to the meter table, or to an output port.

• If there is a match only on a table-miss entry, the table entry may contain instructions, as with any other entry. In practice the table-miss entry specifies one of three actions:

  • Send the packet to the controller. This enables the controller to define a new flow for this and similar packets or decide to drop the packet.

  • Direct the packet to another flow table farther down the pipeline.

  • Drop the packet.

• If there is no match on any entry and there is no table-miss entry, the packet is dropped.

For the final table in the pipeline, forwarding to another flow table is not an option. If and when a packet is finally directed to an output port, the accumulated action set is executed and then the packet is queued for output. Figure 7.7 illustrates the overall ingress pipeline process.

If egress processing is associated with a particular output port, then after a packet is directed to an output port at the completion of the ingress processing, the packet is directed to the first flow table of the egress pipeline. Egress pipeline processing proceeds in the same fashion as for ingress processing, except that there is no group table processing at the end of the egress pipeline.

The Use of Multiple Tables

The use of multiple tables enables the nesting of flows or, put another way, it allows a single flow to be broken down into a number of parallel subflows. For example, an entry in Table 0 defines a flow consisting of packets traversing the network from a specific source IP address to a specific destination IP address. Once a least-cost route between these two endpoints is established, it may make sense for all traffic between these two endpoints to follow that route, and the next hop on that route from this switch can be entered in Table 0. In Table 1, separate entries for this flow can be defined for different transport-layer protocols, such as TCP and UDP. For these subflows, the same output port might be retained so that the subflows all follow the same route. However, TCP includes elaborate congestion control mechanisms not normally found with UDP, so it might be reasonable to handle the TCP and UDP subflows differently in terms of QoS-related parameters. Any of the Table 1 entries could immediately route its respective subflow to the output port, but some or all of the entries may invoke Table 2, further dividing each subflow.

Group Table

In the course of pipeline processing, a flow table may direct a flow of packets to the group table rather than to another flow table. The group table and group actions enable OpenFlow to represent a set of ports as a single entity for forwarding packets. Different types of groups are provided to represent different forwarding abstractions, such as multicasting and broadcasting.

Each group table consists of a number of rows, called group entries, each of which has four components (refer to Figure 7.6c):

• Group identifier: This is a 32-bit unsigned integer that uniquely identifies the group. A group is defined as an entry in the group table.

• Group type: This component determines the group semantics, as explained later in this chapter.

• Counters: This component is updated when packets are processed by a group.

• Action buckets: This is an ordered list of action buckets, where each action bucket contains a set of actions to execute and associated parameters.

Each group includes a set of one or more action buckets. Each bucket contains a list of actions. Unlike the action set associated with a flow table entry, which is a list of actions that accumulate while the packet is processed by each flow table, the action list in a bucket is executed when a packet reaches a bucket. The action list is executed in sequence and generally ends with the output action, which forwards the packet to a specified port. The action list may also end with the group action, which sends the packet to another group. This enables the chaining of groups for more complex processing.

OpenFlow Protocol

The OpenFlow protocol describes message exchanges that take place between an OpenFlow controller and an OpenFlow switch. Typically, the protocol is implemented on top of TLS, providing a secure OpenFlow channel.

The OpenFlow protocol enables the controller to perform add, update, and delete actions to the flow entries in the flow tables. It supports three types of messages:

• Controller-to-switch: These messages are initiated by the controller and, in some cases, require a response from the switch. This class of messages enables the controller to manage the logical state of the switch, including its configuration and details of flow and group table entries. Also included in this class is the packet-out message, which is sent by the controller to a switch when that switch sends a packet to the controller and the controller decides not to drop the packet but to direct it to a switch output port.

• Asynchronous: These types of messages are sent without solicitation from the controller. This class includes various status messages to the controller. Also included is the packet-in message, which may be used by the switch to send a packet to the controller when there is no flow table match.

• Symmetric: These messages are sent without solicitation from either the controller or the switch. They are simple yet helpful. Hello messages are typically sent back and forth between the controller and switch when the connection is first established. Echo request and reply messages can be used by either the switch or controller to measure the latency or bandwidth of a controller-switch connection or just verify that the device is up and running. The experimenter message is used to stage features to be built in to future versions of OpenFlow.

In general terms, the OpenFlow protocol provides the SDN controller with three types of information to be used in managing the network:

• Event-based messages: Sent by the switch to the controller when a link or port change occurs.

• Flow statistics: Generated by the switch based on traffic flow. This information enables the controller to monitor traffic, reconfigure the network as needed, and adjust flow parameters to meet QoS requirements.

• Encapsulated packets: Sent by the switch to the controller either because there is an explicit action to send this packet in a flow table entry or because the switch needs information for establishing a new flow.

The OpenFlow protocol enables the controller to manage the logical structure of a switch without regard to the details of how the switch implements the OpenFlow logical architecture.

Control Plane Functions

Figure 7.8 illustrates the functions performed by SDN controllers.

The figure illustrates the essential functions that any controller should provide, which include the following:

• Shortest path forwarding: Uses routing information collected from switches to establish preferred routes.

• Notification manager: Receives, processes, and forwards to an application events such as alarm notifications, security alarms, and state changes.

• Security mechanisms: Provide isolation and security enforcement between applications and services.

• Topology manager: Builds and maintains switch interconnection topology information.

• Statistics manager: Collects data on traffic through the switches.

• Device manager: Configures switch parameters and attributes and manages flow tables.

The functionality provided by the SDN controller can be viewed as a network operating system (NOS).² As with a conventional OS, an NOS provides essential services, common APIs, and an abstraction of lower-layer elements to developers. The functions of an SDN NOS, such as those listed above, enable developers to define network policies and manage networks without concern for the details of the network device characteristics, which may be heterogeneous and dynamic. The northbound interface, discussed subsequently, provides a uniform means for application developers and network managers to access SDN service and perform network management tasks. Further, well-defined northbound interfaces enable developers to create software that is not only independent of data plane details but to a great extent usable with a variety of SDN controller servers.

2. An NOS is a server-based operating system oriented to computer networking. It may include directory services, network management, network monitoring, network policies, user group management, network security, and other network-related functions.

Southbound Interface

The functionality of the control plane is visible through four interfaces, which are given geographic names [LATI20]. The southbound interface (SBI) provides the logical connection between the SDN controller and the data plane switches, as shown in Figure 7.9. Some controller products and configurations support only a single southbound protocol. A more flexible approach is the use of a southbound abstraction layer that provides a common interface for the control plane functions while supporting multiple southbound APIs.

The most commonly implemented southbound API is OpenFlow.

Northbound Interface

The northbound interface (NBI) enables applications to access control plane functions and services without needing to know the details of the underlying network switches. The northbound interface is typically viewed as a software API rather than as a protocol.

Unlike OpenFlow for the SBI, there is no single API or protocol that different developers/vendors can use for the northbound interface. One reason for this lack of standardization is the variation in applications and their requirements. However, there is consensus on the architectural approach known as intent NBI, and a number of open source SDN packages use it [PHAM16].

There are essentially two approaches for developing an NBI:

• Prescriptive: The application specifies or constrains the selection and allocation, virtualization and abstraction, or assembly and concatenation of resources needed to satisfy the request.

• Nonprescriptive: This is also referred to as intent NBI. The application describes its requirements in application-oriented language, and the controller becomes an intelligent black box that integrates core network services to construct network applications to serve users’ requests.

An important reference on intent NBI is a document issued by the Open Networking Foundation [ONF16], which describes the intent NBI paradigm, its utility and properties, and its potential implementation structure. Figure 7.10, from that document, provides a schematic representation of the architecture.

The architecture makes use of mappings that can translate intent NBI requests into forms that lower-level entities can understand. Mappings are an information intermediation mechanism that effectively permits consumer and provider systems to communicate in terms that are natural to each. The intent environment is dynamic. The intent system, which is essentially middleware between applications and the SDN controller, continuously evaluates the relationship among a number of elements:

• Existing and new intent requests

• Mappings

• Controlled resource sets and states

The intent engine in Figure 7.10 is a middleware component that has an NBI interface with the controller and an NBI interface with the applications that are managed by a consumer service manager component. The intent engine has five major components:

• Information repository (repo): This contains the set of active service intents and mapping lookup values.

• Map_Read API handler: This is responsible for reflecting to the repo an up-to-date capture of mapping lookup values.

• Intent NBI handler: This is responsible for receiving service intents from the consumer system and reflecting them to the repo (in native form) and for reflecting notifications to the consumer system.

• Intent active loop: This element is responsible for continuously evaluating active service intents and mappings from the repo and network information from the SBI handler and taking actions required to instantiate new, or appropriately modify existing, service configurations as a function of detected intent changes (repo), and/or of mapping changes (repo), and/or of network changes (reflected by the SBI handler). Computing appropriate inputs to be reflected to the SBI handler results in the following:

  • Inputs to the SBI handler may adhere to some model-based form, such as specifying one or more pairs of endpoints for piece-wise interconnection, along with parametric constraints on such interconnections. The function of the intent active loop would then include any required and appropriate parsing and translation of intent request terms into such model form. Instructions relayed to the SBI handler would be based on this model and use the specific terms that result from mapping lookups.

  • Where network conditions do not permit instructions that deliver all aspects of specified service intents, appropriate notifications are synthesized to be reflected to the intent NBI handler.

• Controller-specific SBI handler: This is the only controller-specific component of the intent engine and has the following functions:

  • It receives inputs from the intent active loop and provides an appropriately modified form of those inputs, as provisioning instructions, to the SDN controller.

  • It receives information (e.g., topology information) from the SDN controller and forwards it to the intent active loop in an appropriately modified form.

The figure also depicts a mapping information source system. Conceptually, this system associates intent NBI–specific terms, called keys or indices, with controller NBI objects and operations.

This architecture has a number of strengths and benefits:

• Intent declarations are declarative and serve to separate consumer and provider system implementations. They are intended to make human and/or machine consumer requests that are forwarded to provider systems as simple as possible. The SDN controller can calculate the optimal result to fulfill the intent request.

• The intent request is independent of the controller platforms and implementations. It only expresses the requirements for the application layer and uses application-related vocabulary and information. One intent request can be implemented on different controllers with various algorithms. This makes applications portable.

• The intent NBI approach may reduce resource allocation conflicts. Because intent NBI requests do not indicate specific resources to be allocated to specific services, the provider can assign resources to services in ways that reduce the possibility of resource contention.

An example of the types of objects that can be referenced in intent declarations is provided in the intent framework ONOS, which is an open source SDN controller. An intent describes an application’s request to the ONOS core to alter the network’s behavior. At the lowest levels, intents may be described in terms of:

• Network resources: A set of object models, such as links, that tie back to the parts of the network affected by an intent.

• Constraints: Weights applied to a set of network resources, such as bandwidth, optical frequency, and link type.

• Criteria: Packet header fields or patterns that describe a slice of traffic. For example, an intent’s TrafficSelector carries criteria as a set of objects that implement the Criterion interface.

• Instructions: Actions to apply to a slice of traffic, such as header field modifications or outputting through specific ports. For example, an intent’s TrafficTreatment carries instructions as a set of objects that implement the Instruction interface.

Eastbound Interface

Eastbound interfaces are used to import and export information among distributed controllers. The eastbound interface supports the creation of multiple domains. In a large enterprise network, the deployment of a single controller to manage all network devices would be unwieldy or undesirable. A more likely scenario is that the operator of a large enterprise or carrier network divides the whole network into a number of nonoverlapping SDN domains, as shown in Figure 7.11.

Reasons for using SDN domains include the following:

• Scalability: The number of devices an SDN controller can feasibly manage is limited. Thus, a reasonably large network may need to deploy multiple SDN controllers.

• Privacy: A carrier may choose to implement different privacy policies in different SDN domains. For example, an SDN domain may be dedicated to a set of customers that implement their own highly customized privacy policies, requiring that some networking information in this domain (e.g., network topology) should not be disclosed to an external entity.

• Incremental deployment: A carrier’s network may consist of portions of legacy and nonlegacy infrastructure. Dividing the network into multiple individually manageable SDN domains allows for flexible incremental deployment.

The existence of multiple domains creates a requirement for individual controllers to communicate with each other via a standardized protocol to exchange routing information. No single approach has gained widespread acceptance, and there have been a wide variety of implementations on both open source and proprietary systems [LATI20].

Westbound Interface

The westbound interface enables communication between an SDN controller and a non-SDN network. These interfaces typically use Border Gateway Protocol (BGP) to bridge the gap between SDN and traditional networks.

Application Plane Architecture

The application plane contains applications and services that define, monitor, and control network resources and behavior. These applications interact with the SDN control plane via application control interfaces in order for the SDN control layer to automatically customize the behavior and the properties of network resources. The programming of an SDN application makes use of the abstracted view of network resources provided by the SDN control layer by means of information and data models exposed via the application control interface.

This section provides an overview of application plane functionality, which is illustrated in Figure 7.12.

Northbound Interface

As described in Section 7.5, the northbound interface enables applications to access control plane functions and services without needing to know the details of the underlying network switches. Typically, the northbound interface provides an abstract view of network resources controlled by the software in the SDN control plane.

Figure 7.12 indicates that the northbound interface can be a local or remote interface. For a local interface, the SDN applications are running on the same server as the control plane software (i.e., the controller network operating system). Alternatively, the applications can be run on remote systems, in which case the northbound interface is a protocol or an API that connects the applications to the controller NOS running on a central server. Both architectures are likely to be implemented.

Network Services Abstraction Layer

RFC 7426 (Software-Defined Networking [SDN]: Layers and Architecture Terminology, January 2015) from the Internet Engineering Task Force (IETF) defines a network services abstraction layer between the control and application planes and describes it as a layer that provides service abstractions that can be used by applications and services. Several functional concepts are suggested by the placement of this layer in the SDN architecture:

• This layer could provide an abstract view of network resources that hides the details of the underlying data plane devices.

• This layer could provide a generalized view of control plane functionality so that applications could be written that would operate across a range of controller network operating systems. This functionality is similar to that of a hypervisor or virtual machine monitor that decouples applications from the underlying OS and underlying hardware.

• This layer could provide a network virtualization capability that allows different views of the underlying data plane infrastructure.

Arguably, this layer could be considered to be part of the northbound interface, with the functionality incorporated in the control plane or the application plane.

A wide range of schemes have been developed that roughly fall into this layer, although discussing them is beyond the scope of this chapter.

Network Applications

Many network applications could be implemented for a software-defined network. Different published surveys of SDN have come up with different lists and even different general categories of SDN-based network applications. Figure 7.12 includes six categories that encompass the majority of SDN applications. The following sections discuss these six categories.

User Interface

The user interface enables a user to configure parameters in SDN applications and to interact with applications that support user interaction. Again, there are two possible interfaces. A user that is collocated with the SDN application server (which may or may not include the control plane) can use the server’s keyboard/display. More typically, a user logs on to the application server over a network or communications facility.

Key Terms

Review Questions

1. List the key requirements for a modern networking approach.

2. How does SDN split the functions of a switch?

3. Describe the elements of an SDN architecture.

4. Explain the function of the northbound, southbound, eastbound, and westbound interfaces.

5. What are the two main data plane functions?

6. Explain the difference between an OpenFlow switch, an OpenFlow port, and an OpenFlow channel.

7. Explain the difference between an OpenFlow physical port, an OpenFlow logical port, and an OpenFlow reserved port.

8. Explain the difference between an OpenFlow flow table, an OpenFlow group table, and an OpenFlow meter table.

9. Define flow.

10. Define action and action set.

11. Describe OpenFlow ingress and egress processing.

12. List and briefly define the essential functions of an SDN controller.

13. Characterize the operation of an intent NBI.

14. List key reasons for using SDN domains.

15. Describe the application plane architecture.

16. What is the purpose of a network services abstraction layer?

17. List and briefly describe six network application areas.

References

KREU15 Kreutz, D., et al. “Software-Defined Networking: A Comprehensive Survey.” Proceedings of the IEEE, January 2015.

LATI20 Latif, Z., et al. “A Comprehensive Survey of Interface Protocols for Software Defined Networks.” Journal of Network and Computer Applications, volume 145, April 15, 2020.

ODCA14 Open Data Center Alliance. Open Data Center Alliance Master Usage Model: Software-Defined Networking Rev. 2.0. ODCA white paper. 2014.

ONF12 Open Networking Foundation. Software-Defined Networking: The New Norm for Networks. ONF white paper, April 12, 2012.

ONF15 Open Networking Foundation. OpenFlow Switch Specification Version 1.5.1. March 26, 2015.

ONF16 Open Networking Foundation. Intent NBI: Definition and Principles. ONF-TR-523, October 2016.

PHAM16 Pham, M., and Hoang, D. “SDN Applications: The Intent-Based Northbound Interface Realisation for Extended Applications.” 2016 IEEE NetSoft Conference and Workshops, May 2016.

STAL16 Stallings, W. Foundations of Modern Networking: SDN, NFV, QoE, IoT, and Cloud. Upper Saddle River, NJ: Pearson Addison Wesley, 2016.

Documents

RFC 7426 Software-Defined Networking (SDN): Layers and Architecture Terminology. January 2015.

ITU-T Y.3300 Framework of Software-Defined Networking. June 2014.