docs/user-guide/opendaylight-controller-overview.rst

   1 OpenDaylight Controller Overview
   2 ================================
   3
   4 The OpenDaylight controller is JVM software and can be run from any
   5 operating system and hardware as long as it supports Java. The
   6 controller is an implementation of the Software Defined Network (SDN)
   7 concept and makes use of the following tools:
   8
   9 -  **Maven**: OpenDaylight uses Maven for easier build automation. Maven
  10    uses pom.xml (Project Object Model) to script the dependencies
  11    between bundle and also to describe what bundles to load and start.
  12
  13 -  **OSGi**: This framework is the back-end of OpenDaylight as it allows
  14    dynamically loading bundles and packages JAR files, and binding
  15    bundles together for exchanging information.
  16
  17 -  **JAVA interfaces**: Java interfaces are used for event listening,
  18    specifications, and forming patterns. This is the main way in which
  19    specific bundles implement call-back functions for events and also to
  20    indicate awareness of specific state.
  21
  22 -  **REST APIs**: These are northbound APIs such as topology manager,
  23    host tracker, flow programmer, static routing, and so on.
  24
  25 The controller exposes open northbound APIs which are used by
  26 applications. The OSGi framework and bidirectional REST are supported
  27 for the northbound APIs. The OSGi framework is used for applications
  28 that run in the same address space as the controller while the REST
  29 (web-based) API is used for applications that do not run in the same
  30 address space (or even the same system) as the controller. The business
  31 logic and algorithms reside in the applications. These applications use
  32 the controller to gather network intelligence, run its algorithm to do
  33 analytics, and then orchestrate the new rules throughout the network. On
  34 the southbound, multiple protocols are supported as plugins, e.g.
  35 OpenFlow 1.0, OpenFlow 1.3, BGP-LS, and so on. The OpenDaylight
  36 controller starts with an OpenFlow 1.0 southbound plugin. Other
  37 OpenDaylight contributors begin adding to the controller code. These
  38 modules are linked dynamically into a **Service Abstraction Layer**
  39 (SAL).
  40
  41 The SAL exposes services to which the modules north of it are written.
  42 The SAL figures out how to fulfill the requested service irrespective of
  43 the underlying protocol used between the controller and the network
  44 devices. This provides investment protection to the applications as
  45 OpenFlow and other protocols evolve over time. For the controller to
  46 control devices in its domain, it needs to know about the devices, their
  47 capabilities, reachability, and so on. This information is stored and
  48 managed by the **Topology Manager**. The other components like ARP
  49 handler, Host Tracker, Device Manager, and Switch Manager help in
  50 generating the topology database for the Topology Manager.
  51
  52 For a more detailed overview of the OpenDaylight controller, see the
  53 *OpenDaylight Developer Guide*.
  54