Changes between Version 3 and Version 4 of Internal/OpenFlow/VendorTutorial


Ignore:
Timestamp:
Dec 22, 2012, 7:27:21 PM (12 years ago)
Author:
akoshibe
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Internal/OpenFlow/VendorTutorial

    v3 v4  
    11= How-To: Extending OpenFlow with Vendor messages =
    2 !OpenFlow provides a vendor message type as a way to offer third parties a way to customize the protocol without going out of spec. This tutorial attempts to describe how to create custom vendor messages using openflowj (the Java !OpenFlow implementation) and to use them in Floodlight.
     2!OpenFlow provides a vendor message type as a way to offer third parties a way to customize the protocol without going out of spec. This tutorial attempts to describe the openflowj implementations of the vendor type message and how to use them in Floodlight.
    33
    44== Overview ==
     
    1515
    1616== In openflowj ==
    17 `OFVendorData`, located in package org.openflow.protocol.vendor, is the interface for the generic vendor message payload. All vendor type message payloads must implement `OFVendorData`. The vendor ID is also typically defined in the implementing class, as we see here in `OFNiciraVendorData`, the base class for all Nicira vendor messages:
     17The base interface and framework needed for defining vendor messages are found in the package org.openflow.protocol.vendor.
     18
     19`OFVendorData`, is the Java interface for the generic vendor message payload. All vendor type message payloads must implement `OFVendorData`. The vendor ID is also typically defined in the implementing class, as we see here in `OFNiciraVendorData`, the base class for all Nicira vendor messages:
    1820{{{
    1921public class OFNiciraVendorData implements OFVendorData {
     
    2224...
    2325}}}
    24 This base class can then be subclassed to implement the various types of this message. 
     26This base class is then typically subclassed to implement the various types of this message. 
    2527
    26 The Vendor ID and message classes must be registered before it can properly be parsed. This is a two step process. Using the method initVendorMessages() from Floodlight's core controller class `Controller`, we see that the vendor ID is registered first:
     28The Vendor ID and message classes must be registered before it can properly be parsed. This is a two step process. If we take a look at the method ''initVendorMessages()'' from Floodlight's core controller class `Controller`, we see that the vendor ID is registered first:
    2729{{{
    2830    // Configure openflowj to be able to parse the role request/reply vendor messages.
    2931    // first register the vendor ID
    3032        OFBasicVendorId niciraVendorId = new OFBasicVendorId(             
    31                 OFNiciraVendorData.NX_VENDOR_ID, 4);
     33                OFNiciraVendorData.NX_VENDOR_ID, 4);               (1)
    3234        OFVendorId.registerVendorId(niciraVendorId);
    3335}}}
    34 Vendor IDs may vary in length - we indicate that the Nicira vendor ID is an Integer (4B) when we instantiate the !OFBasicVendorId, Next is the registration of each subclass representing a message type:
     36Since vendor IDs may vary in length, we indicate the length in bytes that the vendor ID is when we instantiate the OFBasicVendorId. In (1) we can see that the Nicira vendor ID is 4B long (an Integer).
     37
     38Next is the registration of each subclass representing a message type:
    3539{{{
    3640    // then each data type, starting with reqest
     
    5054Where NXT_ROLE_REQUEST and NXT_ROLE_REPLY are the request and reply data type values for the two Nicira vendor message types. 
    5155
    52 As seen above in the instantiation of the OFBasicVendorDataType, the class implementing the vendor data should be instantiable, so that it can be registered properly by the controller. The method getInstantiable() should be available in your message class for this purpose, and look like this:
     56As seen above in the instantiation of the OFBasicVendorDataType, the class implementing the vendor data should be instantiable, so that it can be registered properly. The method getInstantiable() should be available in your message classes for this purpose:
    5357{{{
    5458    protected static Instantiable<OFVendorData> instantiable =
     
    6973A non-registered Vendor message data payload is interpreted simply as a byte array (OFByteArrayVendorData to be precise), and cannot be cast to your message (sub)class(es) for further handling.
    7074
    71 Each class implementing OFVendorData has a readFrom(!ChannelBuffer data, int length) and writeTo(!ChannelBuffer data) method for reading and writing the data from/to a !ChannelBuffer. A getLength() method that returns the size of the messaes is also required for reading. This value does not count the !OpenFlow header, which is added in by helper methods to produce the total message length. The message length must be correct in order for it to be processed by the !OpenFlow channel pipeline.
     75Each class implementing OFVendorData has a readFrom(!ChannelBuffer data, int length) and writeTo(!ChannelBuffer data) method for reading and writing the data from/to a !ChannelBuffer. A getLength() method that returns the size of the messages is also required for reading. This value does not count the !OpenFlow header, which is added in by helper methods to produce the full message length. The message length must be correct in order for it to be processed by the !OpenFlow channel pipeline.
     76
     77== In Floodlight ==
     78Floodlight uses openflowj as its !OpenFlow implementation. Custom vendor messages are usually placed in their own packages, such as org.openflow.vendor.nicira for Nicira messages. Message registration occurs, as mentioned before, in method ''initVendorMessages()'' in `Controller.java`, found in net.floodlightcontroller.core.internal.