docs/user-guide/didm-user-guide.rst

   1 DIDM User Guide
   2 ===============
   3
   4 Overview
   5 --------
   6
   7 The Device Identification and Driver Management (DIDM) project addresses
   8 the need to provide device-specific functionality. Device-specific
   9 functionality is code that performs a feature, and the code is
  10 knowledgeable of the capability and limitations of the device. For
  11 example, configuring VLANs and adjusting FlowMods are features, and
  12 there may be different implementations for different device types.
  13 Device-specific functionality is implemented as Device Drivers. Device
  14 Drivers need to be associated with the devices they can be used with. To
  15 determine this association requires the ability to identify the device
  16 type.
  17
  18 DIDM Architecture
  19 -----------------
  20
  21 The DIDM project creates the infrastructure to support the following
  22 functions:
  23
  24 -  **Discovery** - Determination that a device exists in the controller
  25    management domain and connectivity to the device can be established.
  26    For devices that support the OpenFlow protocol, the existing
  27    discovery mechanism in OpenDaylight suffices. Devices that do not
  28    support OpenFlow will be discovered through manual means such as the
  29    operator entering device information via GUI or REST API.
  30
  31 -  **Identification** – Determination of the device type.
  32
  33 -  **Driver Registration** – Registration of Device Drivers as routed
  34    RPCs.
  35
  36 -  **Synchronization** – Collection of device information, device
  37    configuration, and link (connection) information.
  38
  39 -  **Data Models for Common Features** – Data models will be defined to
  40    perform common features such as VLAN configuration. For example,
  41    applications can configure a VLAN by writing the VLAN data to the
  42    data store as specified by the common data model.
  43
  44 -  **RPCs for Common Features** – Configuring VLANs and adjusting
  45    FlowMods are example of features. RPCs will be defined that specify
  46    the APIs for these features. Drivers implement features for specific
  47    devices and support the APIs defined by the RPCs. There may be
  48    different Driver implementations for different device types.
  49
  50 Atrium Support
  51 --------------
  52
  53 The Atrium implements an open source router that speaks BGP to other
  54 routers, and forwards packets received on one port/vlan to another,
  55 based on the next-hop learnt via BGP peering. A BGP peering application
  56 for the Open Daylight Controller and a new model for flow objective
  57 drivers for switches integrated with the Open Daylight Atrium
  58 distribution was developed for this project. The implementation has the
  59 same level of feature partly that was introduced by the Atrium 2015/A
  60 distribution on the ONOS controller. An overview of the architecture is
  61 available at here
  62 (https://github.com/onfsdn/atrium-docs/wiki/ODL-Based-Atrium-Router-16A).
  63
  64 Atrium stack is implemented in OpenDaylight using Atrium and DIDM
  65 project. Atrium project provides the application implementation for BGP
  66 peering and the DIDM project provides implementation for FlowObjectives.
  67 FlowObjective provides an abstraction layer and present the pipeline
  68 agnostic api to application to consume.
  69
  70 FlowObjective
  71 ~~~~~~~~~~~~~
  72
  73 Flow Objectives describe an SDN application’s objective (or intention)
  74 behind a flow it is sending to a device.
  75
  76 Application communicates the flow installation requirement using Flow
  77 Objectives. DIDM drivers translates the Flow Objectives to device
  78 specific flows as per the device pipeline.
  79
  80 There are three FlowObjectives (already implemented in ONOS controller)
  81 :
  82
  83 -  Filtering Objective
  84
  85 -  Next Objective
  86
  87 -  Forwarding Objective
  88
  89 Installing DIDM
  90 ---------------
  91
  92 To install DIDM, download OpenDaylight and use the Karaf console to
  93 install the following features:
  94
  95 -  odl-openflowplugin-all
  96
  97 -  odl-didm-all
  98
  99 odl-didm-all installs the following required features:
 100
 101 -  odl-didm-ovs-all
 102
 103 -  odl-didm-ovs-impl
 104
 105 -  odl-didm-util
 106
 107 -  odl-didm-identification
 108
 109 -  odl-didm-drivers
 110
 111 -  odl-didm-hp-all
 112
 113 Configuring DIDM
 114 ----------------
 115
 116 This section shows an example configuration steps for installing a
 117 driver (HP 3800 OpenFlow switch driver).
 118
 119 Install DIDM features:
 120 ----------------------
 121
 122 ::
 123
 124     feature:install odl-didm-identification-api
 125     feature:install odl-didm-drivers
 126
 127 In order to identify the device, device driver needs to be installed
 128 first. Identification Manager will be notified when a new device
 129 connects to the controller.
 130
 131 Install HP driver
 132 -----------------
 133
 134 feature:install odl-didm-hp-all installs the following features
 135
 136 -  odl-didm-util
 137
 138 -  odl-didm-identification
 139
 140 -  odl-didm-drivers
 141
 142 -  odl-didm-hp-all
 143
 144 -  odl-didm-hp-impl
 145
 146 Now at this point, the driver has written all of the identification
 147 information in to the MD-SAL datastore. The identification manager
 148 should have that information so that it can try to identify the HP 3800
 149 device when it connects to the controller.
 150
 151 Configure the switch and connect it to the controller from the switch
 152 CLI.
 153
 154 Run REST GET command to verify the device details:
 155 --------------------------------------------------
 156
 157 `http://<CONTROLLER-IP:8181>/restconf/operational/opendaylight-inventory:nodes <http://<CONTROLLER-IP:8181>/restconf/operational/opendaylight-inventory:nodes>`__
 158
 159 Run REST adjust-flow command to adjust flows and push to the device
 160 -------------------------------------------------------------------
 161
 162 **Flow mod driver for HP 3800 device is added in Beryllium release.**
 163
 164 This driver adjusts the flows and push the same to the device. This API
 165 takes the flow to be adjusted as input and displays the adjusted flow as
 166 output in the REST output container. Here is the REST API to adjust and
 167 push flows to HP 3800 device:
 168
 169 `http://<CONTROLLER-IP:8181>/restconf/operations/openflow-feature:adjust-flow <http://<CONTROLLER-IP:8181>/restconf/operations/openflow-feature:adjust-flow>`__
 170
 171 FlowObjectives API
 172 ------------------
 173
 174 FlowObjective presents the OpenFlow pipeline agnostic API to Application
 175 to consume. Application communicate their intent behind installation of
 176 flow to Drivers using the FlowObjective. Driver translates the
 177 FlowObjective in device specific flows and uses the OpenFlowPlugin to
 178 install the flows to the device.
 179
 180 Filter Objective
 181 ~~~~~~~~~~~~~~~~
 182
 183 `http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:filter <http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:filter>`__
 184
 185 Next Objective
 186 ~~~~~~~~~~~~~~
 187
 188 `http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:next <http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:next>`__
 189
 190 Forward Objective
 191 ~~~~~~~~~~~~~~~~~
 192
 193 `http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:forward <http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:forward>`__
 194