manuals/developer-guide/src/main/asciidoc/core/odl-controller-controller-overview.adoc

   1 == OpenDaylight controller overview\r
   2 \r
   3 The OpenDaylight controller is a JVM software and can be run from any operating system and hardware as long as it supports Java. It is a implementation of the concept of Software Defined Network (SDN).\r
   4 \r
   5 === Background to the emergence of SDN\r
   6 \r
   7 Current generation networks and architectures are statically configured and vertically integrated. New generation applications require networks to be agile and flexibly adapt to application requirements. As networks get larger, especially in massively scalable datcenters and cloud, there is a large requirement for ease-of-management and orchestration.\r
   8 \r
   9 The following are the requirements of modern consumers of the networking industry:\r
  10 \r
  11 \r
  12 * *Agile networks*: As application programmers require their applications to be moved around in a datacenter or across clouds, it becomes imperative that the network becomes agile in meeting the requirements (bandwidth, services like load balancing, firewall) of the applications.\r
  13 \r
  14 * *Vendor neutrality*: Network abstraction and virtualization is required as it allows the network operators to operate the network at a higher level without worrying about the quirkiness of different products from the same or different vendors.\r
  15 \r
  16 \r
  17 * *Ease of building new applications*: Network operators require that they be able to influence the forwarding and other network behavior based on their own algorithms and business logic. That means there is a need for the network to not be vertically integrated with the networking control logic coming only from the networking vendor.\r
  18 \r
  19 \r
  20 === SDN architecture principles\r
  21 \r
  22 SDN consists of a network applications layer on the top written to open API. There is a controller in the middle interacting with and managing network devices. Clearly there needs to be some sort of API or protocol needed for the controller and the network devices to communicate with each other. OpenFlow is one such protocol which has come out of the efforts of Open Networking Foundation (ONF). The network devices support agents which interpret the protocol and the API.\r
  23 \r
  24 \r
  25 Central to the SDN effort is the controller which provides the ability to deploy software to control the network gear and redeploy as needed. The vision is to have a modular controller with a well published Northbound API for network applications to write towards while utilizing southbound protocols such as OpenFlow to communicate with supported downstream network nodes. The industry and end users will benefit immensely by having an OpenSource controller with contributions from various industry players.\r
  26 \r
  27 The OpenDaylight controller supports not only the OpenFlow protocol but also other open protocols to allow communication with devices which have OpenFlow and/or respective agents. It also includes Northbound APIs to allow customer applications (software) to work with the controller in controlling the network. The customer applications cover a wide spectrum of solutions for solving customer needs across different vertical market segments.\r
  28 \r
  29 The controller architecture supports both the hybrid switch model as well as the classical OpenFlow model of having a fully centralized control plane.\r
  30 \r
  31 === OpenDaylight controller framework\r
  32 \r
  33 The following image shows the framework of the OpenDaylight controller.\r
  34 \r
  35 \r
  36 image::odl-framework.jpg[title="Framework of OpenDaylight", alt="Framework of OpenDaylight"]\r
  37 \r
  38 OpenDaylight uses the following tools or paradigms:\r
  39 \r
  40 * *Maven*: OpenDaylight uses Maven for easier build automation. Maven uses pom.xml (Project Object Model) to script the dependencies between bundle and also to describe what bundles to load and start.\r
  41 \r
  42 * *OSGi*: This framework is the back-end of OpenDaylight as it allows dynamically loading bundles and packages JAR files, and binding bundles together for exchanging information.\r
  43 \r
  44 * *JAVA interfaces*: Java interfaces are used for event listening, specifications, and forming patterns. This is the main way in which specific bundles implement call-back functions for events and also to indicate awareness of specific state.\r
  45 \r
  46 * *REST APIs*: These are northbound APIs such as topology manager, host tracker, flow programmer, static routing, and so on.\r
  47 \r
  48 The controller exposes open northbound APIs which are used by applications. The OSGi framework and bidirectional REST are supported for the northbound APIs. The OSGi framework is used for applications that run in the same address space as the controller while the REST (web-based) API is used for applications that do not run in the same address space (or even the same system) as the controller. The business logic and algorithms reside in the applications. These applications use the controller to gather network intelligence, run its algorithm to do analytics, and then orchestrate the new rules throughout the network.\r
  49 \r
  50 On the southbound, multiple protocols are supported as plugins, e.g. OpenFlow 1.0, OpenFlow 1.3, BGP-LS, and so on. The OpenDaylight controller starts with an OpenFlow 1.0 southbound plugin. Other OpenDaylight contributors begin adding to the controller code. These modules are linked dynamically into a *Service Abstraction Layer* (SAL). \r
  51 \r
  52 The SAL exposes services to which the modules north of it are written. The SAL figures out how to fulfil the requested service irrespective of the underlying protocol used between the controller and the network devices. This provides investment protection to the applications as OpenFlow and other protocols evolve over time. For the controller to control devices in its domain, it needs to know about the devices, their capabilities, reachability, and so on. This information is stored and managed by the *Topology Manager*. The other components like ARP handler, Host Tracker, Device Manager, and Switch Manager help in generating the topology database for the Topology Manager.\r
  53 \r
  54 The controller has a built in GUI. The GUI is implemented as an application using the same Northbound API as would be available for any other user application.\r
  55 \r
  56 See the sections below for an overview of the main components of the OpenDaylight controller.\r
  57 \r
  58 === Service Abstraction Layer framework\r
  59 \r
  60 Service Abstraction Layer (SAL) is at the heart of the modular design of the controller and allows it to support multiple protocols on the southbound. SAL also provides consistent services for modules and applications where the business logic is embedded.\r
  61 \r
  62 image::SAL.jpg[title="Framework of SAL", alt="Framework of SAL"]\r
  63 \r
  64 The OSGi framework allows dynamically linking plugins for the evolving southbound protocols. The SAL provides basic services such as device discovery which is used by modules like Topology Manager to build the topology and device capabilities. Services are constructed using the features exposed by the plugins (based on the presence of a plugin and capabilities of a network device). Based on the service request, the SAL maps to the appropriate plugin and uses the most appropriate southbound protocol to interact with a given network device. Each plugin is independent of others and is loosely coupled with the SAL.\r
  65 \r
  66 NOTE: The OpenFlow 1.0 plugin is currently provided with OpenDaylight and other plugins shown in the images are examples of the extensibility of the SAL framework. The SAL framework is included in the OpenDaylight controller contribution.\r
  67 \r
  68 === SAL architecture\r
  69 \r
  70 \r
  71 image::sal_architecture.jpg[title="SAL system architecture", alt="SAL system architecture"]\r
  72 \r
  73 \r
  74 The subsystems in the above figure are as follows:\r
  75 \r
  76 * *Provider*: A component that exhibits functionality to applications and other providers (plugins) through its northbound API. A provider can be a consumer of other providers. There are two types of providers:\r
  77 \r
  78 ** *Binding Independent Providers*: Their functionality is exhibited in the binding-independent Data DOM format.\r
  79 \r
  80 ** *Binding Aware Providers*: Their functionality is exposed in a format compiled against one or more generated binding interfaces.\r
  81 \r
  82 * *Consumer*:  A component that consumes functionality provided by one or more providers. There are two types of consumers:\r
  83 \r
  84 ** *Binding Independent Consumers*: Their functionality is consumed in the binding-independent Data DOM format.\r
  85 \r
  86 ** *Binding Independent Consumers*: Their functionality is consumed using one or more generated binding interfaces.\r
  87 \r
  88 * *Binding Independent Broker*: The core component of the model-driven SAL. It routes RPCs, notifications and data changes between various providers and consumers.\r
  89 \r
  90 * *Binding Aware Broker*: Provides programmatic APIs and Java language support to both consumers such as controller applications or plugins and providers. It is a façade or proxy built on top of the Binding Independent Broker that simplifies access to data and services provided by Binding-Independent providers and Binding-Aware providers.\r
  91 \r
  92 \r
  93 * *BI Data Repository*: A binding-independent infrastructure component of SAL that is responsible for storage of configuration and transient data.\r
  94 \r
  95 * *Binding Schema Repository*: An infrastructure component responsible for storing specifications of YANG–Java relationships and mapping between language-binding APIs to binding-independent API calls.\r
  96 \r
  97 * *Binding Generator*: A SAL infrastructure component which generates implementations of binding interfaces and data mappers to the binding-independent format.\r
  98 \r
  99 === SAL architecture subsystems\r
 100 \r
 101 In context of the controller architecture, two subsystem categories are defined:\r
 102 \r
 103 \r
 104 * *Top-Level Subsystems*:  Subsystems such as a data store, or a validator. There is typically only a single instance of a top-level subsystem per API revision. Top-level subsystems can be controller components or applications (providers or consumers) deployed in the controller that use the controller SAL to communicate with other controller components, applications, and plugins.\r
 105 Top-Level Subsystems usually have either a single instance per system or API, or multiple versioned instances, where each instance is unique to a revision of the contract defined by YANG models. In the latter case, each instance represents a single closed system. Prime examples for top-level subsystem are brokers and data repositories.\r
 106 \r
 107 * *Nested Subsystems*: A subsystem which could be local or remote. It can expose a set of functionality at multiple places or in multiple instances. A network element, such as a router or switch, is an example of a nested subsystem. Data of a nested subsystem is attached or mounted under a node in the controller’s datastore. The data in a nested subsystem may represent data present in another system or in a local controller component, such as a plugin. It may also be dynamically generated by a controller component, or translated from other protocols.\r
 108 \r
 109 NOTE: Consumers may need to invoke the functionality provided by nested subsystems. An RPC Broker must provide functionality that enableS nested RPC functionality in Providers. Furthermore, a Broker must be able to route RPCs to the Providers of nested subsystems for further processing.\r
 110 \r
 111 \r
 112 === SAL service sets\r
 113 \r
 114 * *Topology services* is a set of services that allow to convey topology information such as discovering a new node, a new link, and so on.\r
 115 \r
 116 * *Data Packet services* are SAL services that deliver the packets coming from the agents to applications.\r
 117 \r
 118 * *Flow Programming services* provide the necessary logic to program different match-actions rules.\r
 119 \r
 120 * *Statistics services* export APIs to collect statistics per flow, node connector, queue, and so on.\r
 121 \r
 122 * *Inventory services* provide APIs for returning inventory information about the node and node connectors for example.\r
 123 \r
 124 * *Resource services* is a placeholder to query resource status.\r
 125 \r
 126 \r
 127 ==== Data packet service as example of SAL service implementation\r
 128 \r
 129 As an example of a SAL service implementation, see the Data Packet Service with OpenFlow 1.0 plugin in the section below.\r
 130 \r
 131 image::data_packet_service.jpg[title="Data packet service ", alt="Data packet service"]\r
 132 \r
 133 \r
 134 * *IListenDataPacket* is a service implemented by the upper layer module or application (ARP Handler is one such module) which wants to receive data packets.\r
 135 \r
 136 \r
 137 * *IDataPacketService* is an interface that provides the service of sending and receiving packets from the agent. This service is registered in the OSGi service registry so that an application can retrieve it.\r
 138 \r
 139 * *IPluginOutDataPacketService* is an interface that is exported by SAL when a protocol plugin wants to deliver a packet toward the application layer.\r
 140 \r
 141 * *IPluginInDataPacketService* is an interface that is exported by the protocol plugin and is used to send out the packets through SAL towards the agent on the network devices.\r
 142 \r
 143 The process followed by the SAL is described as follows:\r
 144 \r
 145 . The OpenFlow plugin receives an ARP packet that must be dispatched to the ARP handler application.\r
 146 \r
 147 . The OpenFlow Plugin calls *IPluginOutDataPacketService* to get the packet to the SAL.\r
 148 \r
 149 . The ARP handler application is registered to the *IListenDataPacket Service*. The SAL hands over the packet to the ARP handler application.\r
 150 \r
 151 \r
 152 . The application now processes the packet.\r
 153 \r
 154 \r
 155 For the reverse process of the application sending a packet out, the process followed is described below:\r
 156 \r
 157 . The application constructs the packet and calls the interface *IDataPacketService* to send the packet. The destination network device is to be provided as part of the API.\r
 158 \r
 159 . SAL calls the *IPluginInDataPacketService* interface for a given protocol plugin based on the destination network device, the protocol is OpenFlow in this case.\r
 160 \r
 161 . The protocol plugin  then ships the packet to the appropriate network element. The plugin handles all protocol-specific processing.\r
 162 \r
 163 NOTE: For more information on other service sets, see the Java and API documentation.\r
 164 \r
 165 === Northbound and southbound plugins\r
 166 \r
 167 See the images below for examples of SAL northbound and southbound plugins.\r
 168 \r
 169 image::SAL_NB_Plugins.jpg[title="SAL northbound plugins", alt="SAL northbound plugins"]\r
 170 \r
 171 \r
 172 image::SAL_sb.jpg[title="SAL southbound plugins", alt="SAL southbound plugins"]\r
 173 \r
 174 === OpenDaylight modules\r
 175 \r
 176 The following are the OpenDaylight modules. See the relevant sections for an overview of each module.\r
 177 \r
 178 * AD-SAL - API-Driven Service Abstraction Layer\r
 179 \r
 180 * AD-SAL Network Service Functions for OpenFlow-capable nodes:\r
 181 \r
 182 ** Switch Manager\r
 183 \r
 184 ** Statistics Manager\r
 185 \r
 186 ** Host Tracker\r
 187 \r
 188 ** ARP Handler\r
 189 \r
 190 ** Forwarding Rules Manager (FRM)\r
 191 \r
 192 ** Topology Manager\r
 193 \r
 194 * Clustering and High-Availability Services for AD-SAL\r
 195 \r
 196 * MD-SAL - Model-Driven Service Adaptation Layer\r
 197 \r
 198 * MD-SAL Base Network Functions:\r
 199 \r
 200 ** Topology Exporters\r
 201 \r
 202 ** Inventory Managers\r
 203 \r
 204 * MD-SAL Network Service Functions for OpenFlow-capable nodes:\r
 205 \r
 206 ** Forwarding Rules Manager (FRM)\r
 207 \r
 208 ** Statistics Manager\r
 209 \r
 210 * MD-SAL NETCONF Connector (Southbound NETCONF Plugin)\r
 211 \r
 212 * MD-SAL RESTCONF Connector (Northbound RESTCONF Plugin) - an infrastructure component that renders REST APIs for device/service models loaded into the controller\r
 213 \r
 214 * Config Subsystem - NETCONF/YANG based framework for configuration, performance and fault management of controller infrastructure and plugins deployed into the controller\r
 215 \r
 216 * NSF Adapters - Network Service Function Adapter that allow the MD-SAL based OF1.0/1.3 Plugin to talk with AS-SAL based Network Service Functions\r
 217 \r
 218 \r
 219 === OpenDaylight controller GUI\r
 220 \r
 221 The GUI is implemented as an application and uses the northbound REST API to interact with the other modules of the controller. The architecture thus ensures that whatever is available with the GUI is also available using the REST API. The controller can be integrated easily into other management or orchestration systems.\r
 222 \r
 223 === High Availability\r
 224 \r
 225 The OpenDaylight controller supports a cluster-based high availability model. There are several instances of the OpenDaylight controller which logically act as one logical controller. This not only gives redundancy but also allows a scale-out model for linear scalability. To make the controller highly available, resilience needs to be added at the controller, OpenFlow-enabled switches, and the applications.\r
 226 \r
 227 The OpenFlow enabled switches connect to two or more instances of the controller using persistent point-to-point TCP/IP connection. On the northbound side, between the controller and the applications, the interaction is done using RESTful webservices. This is applicable for all the request-response types of interaction. The interactions based on HTTP and being HTTP based on non-persistent connections between the server and the client, it's possible to leverage all the high-available techniques used to give resilience on the web such as:\r
 228 \r
 229 * Providing the cluster of controller with a virtual IP to be reached using an anycast type of solution\r
 230 \r
 231 \r
 232 * Having the application to talk to the cluster after a DNS request is done using a DNS round-robin technique\r
 233 \r
 234 * Deploying between the applications and the cluster of controller an HTTP load-balancer that can not only  provide resilience but also distributed the workload accordingly to the URL requested.\r
 235 \r
 236 The interaction between the controller(s) and the Open-Flow enabled switches is essentially to have one Openflow switch multi-homed to multiple controller, so if one of the controller goes down another is ready to control the switch. This interaction has already been specified in the OpenFlow 1.2 specifications in particular Section 6.3 of Openflow 1.2 specifications. To summarize it when having multiple controllers connected to one switch, the openflow 1.2 specification specify two mode of operations:\r
 237 \r
 238 * Equal interaction: in this case all the controllers have read/write access to the switch, which means they have to syncronize in order no to step on each other feet.\r
 239 \r
 240 \r
 241 * Master/Slave interaction: in this case there will be one master and multiple slaves (there could be still multiple equal as well)\r
 242 \r
 243 \r
 244 For more information, see the OpenDaylight wiki.\r
 245 \r
 246 \r
 247 \r
 248 \r
 249 \r
 250 \r
 251 \r