Changes between Version 1 and Version 2 of Internal/OpenFlow/VendorTutorial


Ignore:
Timestamp:
Dec 21, 2012, 10:36:11 PM (12 years ago)
Author:
akoshibe
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Internal/OpenFlow/VendorTutorial

    v1 v2  
    2424This base class can then be subclassed to implement the various types of this message. 
    2525
    26 The Vendor ID and VendorData must be registered before it can properly be parsed by your controller. Floodlight's core controller class, `Controller`, registers each vendor message and its subtypes during startup by calling initVendorMessages():
     26The Vendor ID and !VendorData must be registered before it can properly be parsed by your controller. Floodlight's core controller class, `Controller`, registers each vendor message and its subtypes during startup by calling initVendorMessages():
    2727{{{
    2828    private void initVendorMessages() {
    29         // Configure openflowj to be able to parse the role request/reply
    30         // vendor messages.
    31         OFBasicVendorId niciraVendorId = new OFBasicVendorId(             (1)
     29        // Configure openflowj to be able to parse the role request/reply vendor messages.
     30        // first register the vendor ID
     31        OFBasicVendorId niciraVendorId = new OFBasicVendorId(             
    3232                OFNiciraVendorData.NX_VENDOR_ID, 4);
    3333        OFVendorId.registerVendorId(niciraVendorId);
    34         OFBasicVendorDataType roleRequestVendorData =                     (
     34        // then each data type
     35        OFBasicVendorDataType roleRequestVendorData =                     
    3536                new OFBasicVendorDataType(
    3637                        OFRoleRequestVendorData.NXT_ROLE_REQUEST,
     
    4445    }
    4546}}}
     47Where NXT_ROLE_REQUEST and NXT_ROLE_REPLY are the request and reply data types.
    4648
     49As seen above in the instantiation of the OFBasicVendorDataType,
     50the class implementing the vendor data should be instantiable, so that
     51it can be registered properly by the controller. It seems customary to
     52provide a method, getInstantiable(), for this purpose. This belongs in
     53the subclass that defines the actual vendor data payload. The code that
     54does this may look like this:
    4755{{{
    48    // register vendor ID
    49     OFBasicVendorId ofvid = new OFBasicVendorId(CPL_VENDOR_ID, 4);
    50     OFVendorId.registerVendorId(ofvid);
     56    protected static Instantiable<OFVendorData> instantiable =
     57            new Instantiable<OFVendorData>() {
     58                public OFVendorData instantiate() {
     59                    return new OFExportsReply();
     60                }
     61            };
    5162
    52     // and then the message types
    53     OFBasicVendorDataType ofvdt = new OFBasicVendorDataType(20,
    54             OFExportsReply.getInstantiable());
    55     ofvid.registerVendorDataType(ofvdt);
     63    /**
     64     * @return a subclass of Instantiable<OFVendorData> that instantiates
     65     *         an instance of OFRoleRequestVendorData.
     66     */
     67    public static Instantiable<OFVendorData> getInstantiable() {
     68        return instantiable;
     69    }
    5670}}}
     71The above sample was modified slightly to fit my vendor message, but
     72was almost taken, word-for-word, from the Nicira vendor messages.
    5773
    5874A non-registered Vendor message data payload is interpreted simply as a byte array (OFByteArrayVendorData to be precise), and is not easily processed e.g. the methods in your VendorData classes would not be applicable as you would not be able to cast the byte array to your message (sub)class(es).