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

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