Technical white paper HPN SDN Controller Link Discovery

When the controller is configured for hybrid.mode=true, the controller installs a flow rule on every OpenFlow instance to steal these packets:

Packets which match this flow rule are forwarded to the controller from the OpenFlow instance and port where they were received. Using the origin information contained within the received packet, the controller derives the source and destination of the link that this packet traversed and records a link between the OpenFlow instances. The link type is derived from the destination MAC address of the packet (direct or multi-hop). If a link is direct, it will be discovered as both “direct” and “multi- hop” from the reporting OpenFlow instance, but the type of “direct” has precedence over the type of “multi-hop”, so the link is recorded as “direct”.

Keys to Correct Link Discovery

In order to ensure that the desired link topology is correctly discovered, configure the switches such that all OpenFlow instances are configured for the same vlan mapping throughout the topology AND one of the following conditions are met:

•The link discovery packet is correctly tagged by the OpenFlow instance when it egresses the port to which it is injected.

•The untagged link discovery packet is stolen to the controller by the correct OpenFlow instance agent on a switch when it is received.

Though the HPN SDN Controller link discovery method works well in many network configurations, there are some situations where links are not discovered as intended. This may include missing links, links with an incorrect type, or discovering a link where one should not exist. If the untagged discovery packets can’t be associated with the correct OpenFlow instance on the destination switch, then the discovery packet will be dropped or associated with the wrong OpenFlow instance. This can occur for reasons explained in the following sections, including ambiguous vlan association across all OpenFlow instances in the topology.

The consequences of link discovery problems will be observed as impacts to other functionality, such as node discovery or topology calculation. For instance, a missing link in the middle of the network may cause a node’s location to bounce from the edge of the network to the middle of the network.

Known issues

All known link discovery problems relate to one of the following situations:

•The received link discovery packet is dropped by a switch in the network, because the packet is untagged and received on a tagged-only port.

•The received link discovery packet is associated with the wrong OpenFlow instance, because the packet is untagged and received on a port which associates untagged packets with a vlan not in the OpenFlow instance. Another manifestation of this situation occurs when the OpenFlow instance configurations across all switches are not configured with the same vlan set and a discovery packet gets associated with only one OpenFlow instance (see switch C in the example below).

Vendors follow various interpretations in their association of vlans to OpenFlow instances. Various implementations allow a single vlan per OpenFlow instance, multiple vlans per OpenFlow instance, or all vlans in a single OpenFlow instance. Thus when the controller injects an untagged packet into an OpenFlow instance, the vlan association for the packet is sometime ambiguous in the OpenFlow instance.

3