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

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