-
Notifications
You must be signed in to change notification settings - Fork 7
ForwardingModule
| ModuleTypeID (hex) | 0x0009 |
|---|---|
| ModuleTypeID (decimal) | 9 |
| Distribution support | multiple, load-balancing instances |
| Dependencies |
TopologyModule DeviceModule |
Note: This is a demo module demonstrating the possibility to install flows on switches for OpenFlow 1.0 and 1.3.
The SimpleForwardingModule receives PacketIn messages and does layer 2 forwarding (looking up the destination MAC address of the Ethernet frame and installing flows in the network from the source of the packet to the desired target, if the target is known).
Config variable: ZSDN_FORWARDING_MODULE_MULTICAST_GROUPS_FOR_INSTANCE_ID_
Type: Comma separated list of integers (decimal)
Description: this config is specific to a single instance of a Forwarding module (). The config is for the multicast groups the forwarding module will subscribe to. This allows multiple ForwardingModules to run in parallel without receiving the same packetIns. See SwitchAdapter for more details on multicast groups.
Config variable: ZSDN_FORWARDING_MODULE_IGNORE_ETHERTYPES_FOR_INSTANCE_ID_
Type: Comma separated list of integers (decimal)
Description: This instance-specific config for instance will cause the module to ignore all packets with an ethertype contained in the list of ignored ethertypes.
Config variable: ZSDN_FORWARDING_MODULE_RULE_EXPIRE_THRESHOLD
Type: Integer
Description: Cooldown time in milliseconds for installing of flow rules for routes with the same source and destination MAC. This protects against the attempt to install multiple flow rules for the same path. A value of 0 or less will result in no caching at all.
- Put new Topologies into zsdn::NetworkGraph
- if route already exists (map sourceMac -> targetMac) ignore (simpleForwarding can handle that)
- when packetIn comes in, do shortestPath from sourceAttachmentPoint to targetAttachmentPoint
- if path is found, install flow rules accordingly.
- if no path found, ignore
This module does not have any error handling, neither does it react to topology changes. Flow Rules have an idle timeout, the module itself caches already requested routes in order to avoid multiple install of flows.
MessageType: FROM.TOPOLOGY_MODULE.TOPOLOGY_CHANGED_EVENT
Comment: Always require the latest topology through this event.
MessageType: REQUEST.TOPOLOGY_MODULE.GET_TOPOLOGY
Comment: Initially request the current topology.