Skip to content
Snippets Groups Projects
Code owners
Assign users and groups as approvers for specific file changes. Learn more.

Conceptual Design of a SDN Controller as Network Supervisor

Conceptual Structures

This section discusses the conceptual organizationak forms of data networks, as this seems not to be clear in many contexts. The main purpose is to clarify what in a network has to be managed, how it has to be managed and by what entity it has to be managed.

Principal Network Domain (PND)

Definition

Any network consists out of basic components that are the collection of (network) elements used to form such particular network. These components, let it be any device attached to this network and the (physical) links, with their control-, data-, and management planes, form the Principal Network Domain (PND). Such a PND wil be typically under a single control, e.g., a University faculty, a company, or a data center owner.

The term PND does not express anything about logical network abstractions, such as VLANS, IP addresses, forwarding capabilities, etc. It is solely a construct to give all elements in a network a home.

For our purpose of managing a network from a network controller, we define that such a controller is

  • directly in charge of the devices in the PND and thus be able to manage these network elements directly or,
  • connected to a different lower network controller. The network controller would be only able to indirectly communicate with the network elements via the lower network controller or even, in case of a recursion of network controllers, only be able to talk to an even lower level network controller.

The differentiation between the PND and the following definitions of network domain, e.g., IP network, etc is important for the design of a network controller that is supervising a network in its whole.

A single controller may be in charge of multiple PNDs at the same time, though there may be multiple instances of this controller at the same time.

Any network element or host can only be part of a single PND. In case a device resides on the edge between two PNDs, e.g., a router, such a device will be under the control of only one of the PNDs, but it will be designated as a gateway device between these two (or more) PNDs.

An example for a PND:

  • Ethernet switches with Ethernet links
  • DWDM optical switches with fibre connections

Information to handle

  • principal element inventory

    This contains all known elements (such as end-hosts or network element as optical switches), independent of their relationship, of the network. This includes their hardware configuration, such as, interfaces attached to a particular host.

  • principal topology inventory

    This contains all known links and their connection to interfaces of elements out of the principal element inventory.

  • ** Southbound Interface (SBI) ** The SBI to be used for this PND. The intention is to have one SBI for any given PND in order to configure the members of the PND.

Logical Network Domain (LND)

Definition

A logical network domain (LND) is the implementation of a network domain within a PND or within a LND. Such a LND defines what protocols are to be used and builds on top of the structure of the underlying PND or LND. Two exemplary examples:

  • a LND on top a PND: a VLAN-enabled Ethernet switch where the VLANs from a logical topology on top of the physical infrastructure.
  • a LND on top of an underlying PND: an IP subnetwork based on a VLAN LND.

LNDs specify the operational parameters, such as forwarding capabilities (e.g., Ethernet, VLAN Ethernet, IP, etc), which elements of a PND are part of the LND, etc.

A logical network domain is bound to a single PND. Logical network domains can be part of logical network domains, i.e., this is a case of recursion.

Information to handle

  • domain element inventory

    contains the elements part of a particular network domain and it has to be a (sub)-set of the elements of the principal element inventory or a logical abstraction, such as a container or a virtual machine.

  • domain topology inventory

    This contains all known logical links and their connection to interfaces of elements out of the domain element inventory.

  • ** Southbound Interface (SBI) ** The SBI to be used for this LND. This may be different from the SBI of the PND and allow so to span logical networks with their own SBI-implementation. One possible example is that the PND may use Ansible-scripts to setup the basic configuration of the devices, e.g., switch-on interfaces, enable Openflow etc and allow the LND to use Openflow for its operation. A second LND may use a RESTCONF-approach to configure its devices.

Different Types of Southbound Interfaces

The communication with the network elements is facilitated via the Southbound Interface (SBI). The SBI allows an entity external to the network element (NE) to control all or certain behaviors of such NE. We differentiate between three basic SBI types for our further discussion:

  • Flow-based: a controller can instruct the NE to alter the forwarding of particular flows based on a fixed set of forwarding instructions and filters.
  • Topology-based: a controller can instruct the NE to alter the topology of a network, e.g., by switching interface on or off, but it may not be able to alter the forwarding of flows
  • Programmability-based: a controller can load the forwarding logic as a program on the NE and can include the forwarding rules as part of the program code.

It is important to note that the basic types of SBI can stand on their own, but they can also possibly appear in combinations, e.g., a combined flow- and programmability-based SBI sounds possible.

Core functions

The short description of core functionality of goSDN: Keep track of everything and be in control of everything.

An half-unsorted list of core functions:

  • manage SBIs
    • Load SBIs
    • Use predefined SBI-Interfaces
    • Configure SBI instance , e.g., IP/port of SBI server, certificates, etc
    • SBI generic error handling, such as, failure of connection to SBI server
    • Link between SBI errors and "SBI-content" (e.g., topology information), i.e., what to do if a SBI instance fails.
    • Denote PND to SBI relationsship
  • read-only access to network information (SBI-content)
    • learn about NEs, interfaces, links and hosts in a PND via the SBI
    • learn about NEs, interfaces, links and hosts in zero, one or more LND via the SBI
    • learn about changes with respect to NEs, interfaces, links and hosts in PNDs and LNDs
    • store information about NEs, interfaces, links and hosts in PNDs and LNDs
    • related this information to each other, such as, what interface is attached to what NE or what link is connecting which interfaces
  • write access to network information
    • use all functions of the "read-only" part above in order to learn about what's happening in the network
    • create a LND
    • use the topology information to calculate possible paths between parts of the network or between attached hosts in a PND or LND
    • write information to SBI
      • topology information
      • flow forwarding information
      • general configuration information, e.g., interface up (?)
    • handle feedback from SBI (success, failure, issues)
      • received this type of information
      • process it in a meaningful way
  • SBI-Interface things
    • PND/LND differentiation needed
    • Exchange of validity information, such as timer for information entries (i.e., NEs, interfaces, links and hosts )
  • Representation of network information (NEs, interfaces, links and hosts ) in the core
    • Representation should be independent of SBI but requires specific information provided by or via the SBI
    • Readling list for Representation
    • Storage in the graph database

Parking Lot for pending Stuff

  • host configuration

    This is based on the information provided by the host inventory and contains the actual operational configuration of the hosts. This will probably contain only the configuration of the network devices, such as, switches and routers, potentially also servers, but not end-hosts.

  • Network

  • Network Configuration)

  • Southbound Interface (SBI)

  • Northbound Interface (SBI)

  • East-West-bound Interface (SBI)

Applying Changes to What Plane?

Some basic thoughts to dissect how different approaches are applying changes to the various planes.

Changes to the Control Plane

Changes to the Data Plane

This is the use case for the SDN approach: A so-called SDN-controller applies policy rules to the data plane. These policy rules are defining the handling of the flows in the networks on a larger scale or to be more precise the handling of more less specified packets.

A change to the data plane will not directly trigger a change to other planes. Though the flow of packets on the data plane can be observed by the control plane and the control plane can take action depending on the data packets.

Changes to the Management Plane