The current topology discovery service uses standard LLDP packets for discovery, i.e., packets are sent to destination mac 01:80:c2:00:00:0e (nearest bridge) with ethtype 0x88cc.

This is fine for an OpenFlow-only domain, where all switches are owned by the controller, but it fails, when OF switches are connected through regular Ethernet (non-OF) switches. Example topology with OF switches A and D, and regular Ethernet (non-OF) switches B and C:

OF-A — Eth-B — Eth-C — OF-D

The controller is only aware of OF-A and OF-D, and tries to determine if there is connectivity. So it sends out an LLDP packet from OF-A towards Eth-B. If this is a standard LLDP packet sent to destination mac 01:80:c2:00:00:0e (nearest bridge) with ethtype 0x88cc, then the packet will be consumed/dropped by Eth-B, and will never get to OF-D.

OFDP simply diverges from the standard by using an arbitrary regular multicast destination address and/or using an arbitrary ethertype for LLDP packets. This will cause the intermediate non-OpenFlow switches to simply forward those packets on all active ports. This way the LLDP packet reaches OF-D, and so the topology can be detected.

Other than that, there is no difference between the two methods. Sending and receiving LLDP packets is done exactly the same way in both cases.

------------

Currently the destination mac and ethertype to be used is hardcoded in the topology discovery code (grep for LLDP.LLDPMulticastMac and EtherTypes.LLDP).

The simplest solution would be to expose (1) the destination mac and (2) the ethertype to be used as configuration options, keeping the current values as default.

Then users could use OFDP without the need to edit code, and they could specify these values in a way that it is compatible with their existing non-OF infrastructure.

------------

ref: http://groups.geni.net/geni/wiki/OpenFlowDiscoveryProtocol