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.

ALL COMMUNICATION BASED ON PROTOBUFFERS IS HANDLED THIS WAY. NEVER TRY TO DIRECTLY PARSE A SUBMESSAGE!

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