1. How to Implement Vendor Specific Extensions based on ODL Experimenter Framework
Gaurav Bhagwani (Senior Software Engineer)
Arunprakash D (Technical Lead)
Hema Gopalkrishnan (Senior Technical Lead)
Manohar SL (Senior Technical Lead)
Sharath Kumar V (Senior Software Engineer)
- Ericsson
November 17, 2016

2. INTRODUCTION
OpenFlow specification defines Experimenter as the way of allowing vendor defined extensions.
Experimenter messages provide a standard way for OpenFlow switches to offer additional functionality within the OpenFlow message type space.
OpenDaylight needs a experimenter framework defined, which will allow end user to integrate their extension seamlessly.

3. “Experimentation is the least arrogant method of gaining knowledge”
-Issac Asimov

4. Experimenter Message The Experimenter message is defined as follows:
Header -OpenFlow header
Experimenter bit value that uniquely identifies the experimenter.
Exp_type – Experimenter Defined Data

5. Extensibility support
OF protocol defines following experimenter messages:
experimenter action
experimenter match
symmetric experimenter message
multipart experimenter message
experimenter meter (..to be supported)
Support of those messages is covered by extensibility framework.
Extensibility Framework is part of OpenFlowPlugin and defines registry points for Vendor converters towards applications.

6. Extensibility Workflow (1/3)
There is two step conversion:
Between MD-SAL Models and OFJava Models
Between OFJava Models and wire protocol

7. Extensibility Workflow (2/3)
Augmented MD-SAL model containing Vendor message
OF Plugin looks up for suitable converter and convert it into OFJava-API model.
OFJava looks up for suitable serializer and apply it to augmentation.
Result is Binary data sent via netty to device.

8. Extensibility Workflow (3/3)
Device sends an experimenter message to OFJava.
OFJava looks up for suitable vendor codec and deserializes the message into OFJava-API model. Augmented model is delivered to OF Plugin
OF Plugin looks up for suitable converter and apply it to vendor augmentation. Result is packed as augmentation in MD-SAL model and sent to MD-SAL.
MD-SAL delivers the model to vendor application.

9. Extensibility Framework – Registering (de)serializer
SwitchConnectionProvider contains methods for (de)serializer registration.
Registering Serializer
openflowSwitchConnectionProvider.registerExperimenterM essageSerializer(serializerKey, <Impl>)
Registering De-Serializer
openflowSwitchConnectionProvider. registerExperimenterMessageDeserializer(deserializerKe y, <Impl>)
If (de)serializer was not registered, the library will throw IllegalArgumentException.

10. Deserialization extensibility

11. Serialization extensibility

12. Deserialization Registration Key

13. Serialization Registration Key

14. Plugin Converter Registration
ExtensionConverterRegistrator has registerMessageConvertor APIs.
Registering ConvertorMessageFromOFJava :
extensionConverterRegistrator.registerMessageConvert or(key, <specific converter>)
Registering ConvertorMessageToOFJava :

15. Sample Experimenter Message

16. Augmenting Extension Registry/SwitchConnectionProvider

17. Registration

18. Serializer and De-Serializer

19. Plugin Convertors

20. Experimenter Message and Notification

21. CONCLUSION
OpenFlow specification defines Experimenter as the way of allowing Vendor defined extensions.
Vendor Message needs Specific Serializer and De-serializer registration to serialize and deserializes the message.
Plugin Converters registration is needed to/from OFJava
Experimenter Messages are sent using SalExperimenterMessage Service while Experimenter Notifications are recieved using SalExperimenterMessageListener

22. Thank You …