Contents

Introduction

A southbound plugin that can configure off-the-shelf commodity Ethernet switches via SNMP and CLI.

Release Deliverables

NameDescription
SNMP SouthBound PluginA southbound plugin that configures Ethernet switches via SNMP.
CLI supportFor SNMP SouthBound Plugin to be also capable of configuring Ethernet switches via CLI.
Extension To SALExtensions to the SAL configuration APIs.

Release Milestones

MilestoneOffset 1 DateDeliverables
M17/24/2013


NameDescription
Release PlanCandidate Release Plan


M28/21/2013


NameDescription
Release PlanFinal Release Plan


M39/18/2013


NameDescription
SNMP SouthBound PluginA southbound plugin that configures Ethernet switches via SNMP.


M410/16/2013


NameDescription
CLI supportFor SNMP SouthBound Plugin to be also capable of configuring Ethernet switches via CLI.
Extension To SALExtensions to the SAL configuration APIs.
API Freeze


M511/13/2013


NameDescription
Code Freeze
Testing1. Continuous Integration Testing

2. Continuous System Testing


RC011/20/2013


NameDescription
Bug fixes


RC111/27/2013


NameDescription
Bug fixes


RC212/4/2013


NameDescription
Bug fixes


Formal Release12/11/2013


NameDescription



Expected Dependencies on Other Projects

Depends OnDependency DescriptionNeeded ByIs in Other Project Release Plan
ControllerSouthbound plugin interfaceM2False

Compatibility with Previous Releases

Themes and Priorities

1. Existing SAL API's semantics on Ethernet switch as well as the implementation with the aid of SNMP and CLI.

2. The required extensions to SAL API to take advantage of some things that can be done via SNMP and CLI.

Release Note

Release Note on M3

For the target of being an OpenDayLight SAL plugin to enable Ethernet switch on the SDN paradigm, we support SNMP & CLI as the south bound protocol, also we propose new mechanisms for switch discovery and topology discovery for Ethernet switch in SDN.

So, there are three things to work out as just mentioned, (1) SNMP CLI, (2) switch discovery, and (3) topology discovery. The architecture and design has been posted on wiki. For the first one, SNMP and CLI are used for flow configuration on Ethernet switch. We have completed the implementation of using SNMP to configured flows on the forwarding table. As to using CLI to configured flows on ACL, it will be done by milestone M4.

For the second task, switch discovery, it will be achieved via SNMP trap sent from the switch. Simply speaking, every switch is set to automatically send SNMP trap to the controller after it boot up. We had introduced this approach in the mailing list, and the feedbacks include: agreeing with this approach since it is very similar to how OpenFlow switch is set to join the controller in initial, or other ideas such as using LLDP or using DNS-SD. And then their limitations or concern of prerequisite had been discussed. So we will still use the approach of SNMP trap, which will be done by M4.

For the third task, topology discovery, the plugin queries each switch by SNMP, and each switch responds with its LLDP data, then the switches' topology could be resolved. Now the implementation is done, and passed the unit test. Then, together with when the implementation of switch discovery is done, after milestone M4, the Ethernet switch should be able to appear in the GUI dashboard.

Finally, in terms of SAL API implementation, including the APIs under ContainerListener, the flowprogrammer, flowreader, topology, inventory, and datapacket, most of them will be done by M4, and then by milestone M5 those works related to system integration to make the plugin runnable will be done, and the extended APIs for specific purposes such as disabling STP and broadcast will also be done by milestone M5.

Release Note on M4

1. Functionalities implementation: the functionalities of this plugin, including API implementations using SNMP and CLI, and the solutions for Ethernet switch discovery in SDN, including switch discovery and topology discovery. API implementations using SNMP had been done by M3, and so does the topology discovery. Switch discovery is also done by M4. Their unit tests with a real subnet of Ethernet switches also passed. Then, the rest of the aforementioned functionalities will be done by M5.

2. Integration test: we had written and pushed the code for integration test for flow programming, but we have difficulties to make it work. We plan to meet our original release plan for M4, which is about CLI and API extension, and then after M4 we can continue on solving the integration test problem.

3. API extension implementation: we had proposed some API extension for the purposes of such as disabling STP and flooding. Then as suggested that extensions to be done via MD-SAL, we will expose these APIs through MD-SAL. API freeze is now moved to M5, because that in addition to the API extensions we had proposed, we will add some new API, but we are still working on writing models to create new APIs in MD-SAL. We will propose our design though MD-SAL after M4, and then complete the implementation by M5.

Release Note on M5

1. API implementation using SNMP had been done by M3. As to API implementation using CLI, including IConfigService and some of the existing OpenDaylight APIs, IConfigService is done by M5, and the others will be done in the end of this year (including flow configuration on ACL as well as reading node's or nodeConnector's properties and statistics).

2. The proposed API extension is exposed in the IConfigService, whose implementation depends on switch's own CLI. The implementation for D-link DES-3200 switch is done as an example of IConfigService implementation. The API extension with MD-SAL will be done in January of next year.

Release Note for the Formal Release

Features

Non-Code Aspects (user docs, examples, tutorials, articles)

Security Issues

Quality Assurance (test coverage, etc)

Standards (summary of standard compliance)

Schedule (initial schedule and changes over the release cycle)