ZSDN Modules

Core-Modules

|Name|ModuleTypeID|Summary| --- | --- | --- | --- |SwitchAdapter |0x0000| Wraps an OpenFlow switch as a module. | |SwitchRegistryModule |0x0001| Provides detailed information about all switches in the network. | |DeviceModule |0x0002| Knows about all devices in the network (excluding switches). | |LinkDiscoveryModule |0x0005| Finds out about links between switches. | |TopologyModule |0x0006| Provides a full topology of the network, including switches and links between them. | |StatisticsModule |0x0008| Collects port- and tablestatistics from Switches. |

Other Modules

| Name | ModuleTypeID | Summary | --- | --- | --- | --- | ARPModule | 0x0003 | Answers ARP-Requests directly to reduce flooding in the network. | | SimpleForwardingModule | 0x0004 | Packets are forwarded to their destinations using PacketOut messages. (Layer 2 forwarding) | | ForwardingModule | 0x0009 | Installs routes based on layer-2 info(dst-mac). | | LoggingModule | 0x0010 | Logs all zmf pub/sub traffic | | RestAdminModule | 0x0011 | REST Interface and Web UI| | Reserved | 0x001* | Reserved for new ZSDN modules |

Module dependencies:

 

Common Data Structures

Name	Summary
CommonTopology	Contains topology related data structures used by multiple topology discovery related modules.

Brief Architectural Summary

All Modules share a common pattern for MessageTypes and protobuf message formats. This is explained in more detail here:
MessageType and protobuf format

MessageTypes

These MessageTypes are reserved and all modules define their own MessageTypes as subtypes of these top-level types:

FROM.<MODULE>
TO.<MODULE>
REQUEST
REPLY

Container

Protobuf messages relating to these top-level types always use a top-level protobuf message. for example, all Messages FROM a specific module are bundled up like this:

message From {
    oneof FromMsg {
        <FromMsg_1_Type> <fromMsg_1_Name> = 1;
        <FromMsg_2_Type> <fromMsg_2_Name> = 2;
        ...
        <FromMsg_n_Type> <fromMsg_n_Name> = n;
    }
}

The same is true for TO, REQUEST and REPLY. This pattern allows easy extensions which can be handled at runtime - modules can depend on parsing the respective top-level message first, then check the actual Message they are interested in.

Third party Modules are free to send their data in any format they want - however, all standard components of ZSDN use google protocol buffers for communication.

Each ZSDN module has its own .proto file containing all messages belonging to the module. The top level messages are equal to the top level topics - To, From, Request, Reply. Using a top level message as container for exactly one subtype of message allows easy runtime checks on the type of a message - for example, a Module a can parse all its messages it receives as a request as a "Request" msg - and then look up the specific subtype.

IMPORTANT: Not every topic (see .topics / MessageType) has to have an associated protobuf message - there is no point in having hundreds of submessages for something that can be expressed as a single integer in a top level message, for example. Modules have to specify the kind of protobuf message expected/sent out for each topic in the topics file.

package ExampleModuleA_Proto;

// Main message type for messages TO ExampleModuleA

message To {

    oneof ToMsg {
        SomeEvent someEvent = 1;
        AnotherEvent anotherEvent = 2;
        SomeRequest someRequest = 3;
    }

    // SubMessage definition of ExampleModuleA

    message SomeEvent {
        required string foo = 1;
        optional uint32 bar = 2;
    }

    message AnotherEvent {
        required string foo = 1;
        optional uint32 bar = 2;
    }

    message SomeRequest {
        repeated uint64 bar = 1;
        repeated SomePayload payload = 2;
    }
}

// Main message type for messages FROM ExampleModuleA

message From {

    oneof FromMsg {
        RandomNumber randomNumbers = 1;
    }

    message RandomNumber {
        required uint64 randomNumber = 1; 
        optional SomePayload payload = 2;
    }
}

message Request {
    oneof Req {
        SomeRequest request = 1;
    }
    message SomeRequest {}
}

message Reply {
    oneof Rep {
         SomeReply reply = 1;
    }
    message SomeReply{}
}




// Message types used in both FROM and TO messages

message SomePayload {
    required string something = 1;
    required bytes payload = 2;
}

NOTE: Currently the controller doesn't handle VLAN tagged packets.