此前一直不能理解，Openflow中discovery的流程里，非OF设备是如何发现的。最近终于解决了这个问题，总结如下。

【【Discovery】】

LLDP用于通告自己的信息，没有传递性，即经过一个设备后会“消耗掉”，不会继续转发。
传统的交换机/网络设备对LLDP的处理方式：主要针对某个端口开启/不开启，即是否主动发送LLDP。发送与接收一般无逻辑关系。（很少有逻辑要求“收到LLDP才发送”）
若传统设备已主动发起LLDP，OF交换机收到后会上传到控制器，控制器可以判断出这个LLDP是非OF设备发出的，但不能判定该非OF设备存在于OF区域中。因此不管传统设备对LLDP如何处理，都按统一的算法进行判断。
【前提条件】算法必须满足2个假设：

  1. 非OF设备对广播包有转发能力（即在2层环境里）

  2. 非OF设备不会传递LLDP包（即消耗）

【流程】控制器利用output指令要求OF交换机发送LLDP包和BDDP到所有的端口，LLDP先发送。

1 LLDP

 1.1 支持OF协议的交换机会上传LLDP，证明是OF设备
 1.2 没收到LLDP，有可能是主机，也可能是非OF设备，依赖BDDP包判断
2 BBDP
  若广播包从一个在[LLDP阶段判断出无直连关系的OF设备]收到它用paketIn封装的broadcast包，证明两个OF设备间有非OF的区域存在（而不是边缘）。否则，该端口连接的是主机，或者是非内部包含的非OF区域。

简单来说：收到LLDP与BDDP，则是OF交换机。仅收到BDDP，就是非OF交换机。都收不到是主机或边缘非OF区域。

补充一个在floodlight官方文档中摘过来的描述
Description
The link discovery service is responsible for discovering and maintaining the status of links in the OpenFlow network.
How it works
The link discovery services uses both LLDPs and broadcast packets (aka BDDPs) to detect links. The LLDP destination MAC is 01:80:c2:00:00:0e and the BDDP destination MAC is ff:ff:ff:ff:ff:ff (broadcast address). The ether type for LLDPs and BDDPs is 0x88cc and 0x8999. There are two assumptions made in order for the topology to be learned properly.
   Any switch (including OpenFlow switches) will consume a link-local packet (LLDP).
   Honors layer 2 broadcasts.
Links can either be "direct" or "broadcast". A direct link will be established if an LLDP is sent out one port and the same LLDP is received on another port. This implies that the ports are directly connected. A broadcast link is created if a BDDP is sent out a port and received on another. This implies that there is another layer 2 switch not under the control of the controller between these two ports.