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
22 The DIDM project creates the infrastructure to support the following
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.
32 - **Identification** – Determination of the device type.
34 - **Driver Registration** – Registration of Device Drivers as routed
37 - **Synchronization** – Collection of device information, device
38 configuration, and link (connection) information.
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.
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.
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
63 (https://github.com/onfsdn/atrium-docs/wiki/ODL-Based-Atrium-Router-16A).
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.
74 Flow Objectives describe an SDN application’s objective (or intention)
75 behind a flow it is sending to a device.
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.
81 There are three FlowObjectives (already implemented in ONOS controller)
88 - Forwarding Objective
93 To install DIDM, download OpenDaylight and use the Karaf console to
94 install the following features:
96 - odl-openflowplugin-all
100 odl-didm-all installs the following required features:
108 - odl-didm-identification
117 This section shows an example configuration steps for installing a
118 driver (HP 3800 OpenFlow switch driver).
120 Install DIDM features:
121 ----------------------
125 feature:install odl-didm-identification-api
126 feature:install odl-didm-drivers
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.
135 feature:install odl-didm-hp-all installs the following features
139 - odl-didm-identification
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.
152 Configure the switch and connect it to the controller from the switch
155 Run REST GET command to verify the device details:
156 --------------------------------------------------
158 http://<CONTROLLER-IP:8181>/restconf/operational/opendaylight-inventory:nodes
160 Run REST adjust-flow command to adjust flows and push to the device
161 -------------------------------------------------------------------
163 **Flow mod driver for HP 3800 device**
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:
170 http://<CONTROLLER-IP:8181>/restconf/operations/openflow-feature:adjust-flow
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.
184 http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:filter
189 http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:next
194 http://<CONTROLLER-IP>:8181/restconf/operations/atrium-flow-objective:forward