基于LLDP协议的OLT设备拓扑发现研究

('基于LLDP协议的OLT设备拓扑发现研究崔太祥;赵咸红;陈玉霞;陈辉辉【摘要】阐述了OLT设备上实现LLDP(LinkLayerDiscoveryProtocol,LLDP)协议的相关原理,实现了一种深度可控的拓扑发现算法.针对PON系统与其它设备的一种特殊的连接情形,提出了一种合理的解决方案.【期刊名称】《光通信技术》【年(卷),期】2015(039)011【总页数】3页(P1-3)【关键词】拓扑发现;链路层发现协议;无源光网络;光线路终端【作者】崔太祥;赵咸红;陈玉霞;陈辉辉【作者单位】武汉邮电科学研究院,武汉430074;武汉烽火网络有限责任公司,武汉430074;武汉烽火网络有限责任公司,武汉430074;武汉邮电科学研究院,武汉430074;武汉烽火网络有限责任公司,武汉430074;武汉邮电科学研究院,武汉430074;武汉烽火网络有限责任公司,武汉430074【正文语种】中文【中图分类】TP393随着网络技术的飞速进步，网络种类与数量也快速增多，虽然这使得网络容量与功能都得到了很大的提升，但错综复杂的网络的结构却给网络管理带来了巨大的难度。能够获得网络的拓扑信息，尤其是自动发现拓扑的能力，对网络设备的管理配置、故障定位和性能分析都具有十分重要的现实意义。虽然当前也有一些网络管理软件通过借助设备上运行的其它协议，可以达到发现拓扑的目的，但大多只是在第三层上，比如利用DNS、ARP、ICMP、RIP等协议的三层拓扑发现，它们的算法大多非常复杂，并且对其它协议的依赖性较强，甚至给网络带来不少额外的开销。第二层发现更完整地触及到了第二层设备，尤其近年来几乎所有的二层设备开始增加支持管理IP和管理VLAN的配置以及远程TELNET能力，更多二层设备的发现和远程管理成为了可能，因而对二层设备的发现和统一管理有了更进一步的要求。在二层设备拓扑发现中，有借助交换机地址转发表或STP（SpanningTreeProtocol,STP）的，但还存在难以获得完备的转发表和依赖STP的问题。当然，也有一些厂商独自开发了自己的发现协议[1]，但在多设备厂商混合连接的情况下，它们将达不到预期的效果。因此，作为一种发现多厂商设备的链路层发现协议——LLDP(LinkLayerDiscoveryProtocol,LLDP)应运而生，它由IEEE标准所定义。LLDP是未来行业内的标准和发展趋势，现在越来越多的接入层的交换机开始支持LLDP协议，同样作为接入层的OLT设备也应该结合自身特点提供相应的LLDP功能支持。1.1协议目标当前，网络设备的生产厂家和种类不一，而且其配置错综复杂，为了统一化设备发现方式，并使各设备能正常交互配置信息，需要标准化链路层的拓扑发现，LLDP协议就提供了这样一种标准的链路层发现方式。LLDP包由多个TLV（Type/Length/Value，即类型/长度/值）构成，TLV是最小的信息承载单位，它先将本端设备的管理地址、管理VLAN、端口连接情况以及设备能力等LLDP定义的信息类型加以封装，最终组成链路层发现协议数据单元（LinkLayerDiscoveryProto-colDataUnit，LLDPDU）。然后，直接相连的设备之间互相向对端公告本端的LLDPDU信息，双方将接受的信息加以解析，并以标准管理信息库（ManagementInformationBase，MIB）的形式保存起来。网络管理中心通过SNMP可以远程读取设备存储在MIB库中的信息，据此可以生成物理拓扑图[2]，其工作原理如图1所示。1.2支持的TLV类型LLDP可以封装的TLV包括基本TLV、802.1组织定义TLV、802.3组织定义TLV和媒体终端发现（MediaEndpointDiscovery，LLDP-MED）TLV[3]。基本TLV为LLDP实现所必须包含的TLV，后3种为TLV扩展系列，每一种通过组织唯一标识符（organizationallyuniqueidentifier,OUI）来标识[4]。TLV类型及说明见表1。1.3工作模式与老化机制1.3.1LLDP有4种工作模式①TxRx模式：发送同时接收LLDP报文。②Tx模式：只发送不接收LLDP报文。③Rx模式：不发送只接收LLDP报文。④Disable模式：不发送也不接收LLDP报文。1.3.2老化机制端口在接收到邻居的LLDP包后，对其进行解析，然后将解析得到的信息存放在管理信息库中，供远端网管访问。接收到报文的端口根据其携带的TTL值，在TTL时间内将信息予以保存。如果在TTL时间内再收到LLDP报文，则重新更新TTL值；否则，就把此邻居信息从管理信息库中删除。这样做的目的是尽快使对端知道发送端发生的事件，让对方老化掉无效信息。老化机制的引入，是使拓扑信息能在一定程度上得到实时更新的关键。2.1信息获取方式LLDP设备拓扑发现主要依靠SNMP协议来完成，SNMP由网管工作站(networkmanagementstation)和网管代理(networkmanagementagent)两部分组成。网管工作站负责控制和监视网络设备，代理在各处的网络设备上，通过获取本端设备的信息，并且按通用的标准将其分类存入本地标准信息库MIB中供网管工作站访问。根据指定的管理IP和管理VLAN，网管工作站与网管代理可以进行远程通信。网管工作站通过对LLDP设备进行相关信息查询，根据获取到的设备连接信息，再运用一定的算法就可以自动生成链路层拓扑信息，并能据此对设备进行管理维护。2.2算法选择及实现流程选择一个LLDP设备作为根设备或者种子设备，则整个管理域内的设备就像一颗树。针对LLDP协议的特点，拓扑发现可以选择深度优先算法或者广度优先算法。前者使用队列，占内存少速度相对慢；后者使用栈，占内存多而速度快。在此，广度优先算法更符合实际网络管理由近及远的现实情境，并且利用广度优先算法可以同时引入深度控制。这样，如果面对大量有较高深度的需要管理的设备，可以通过深度控制选择管理域内特定深度的设备，更方便设备的管理，不至于使生成的拓扑界面变得繁杂冗余。引入深度控制的广度优先算法的流程图如图2所示，其中深度N为大于或者等于0的整数，N为0时，N赋值为65535（因为正常情况下深度远小于65535），表示不进行深度控制，对全部域内的设备进行发现；Level为节点数据结构中的深度信息，从1开始计数，也就是说种子节点的深度为1，向下依次累加。Level=Level+1表示在所在父节点的基础上将其直连子节点的深度也即Level递增1；BREAK和CONTINUE所处的循环域为每个节点进行搜寻临近节点的循环域。2.3拓扑实现搭建的测试环境如图3所示，采用OLT设备和交换机混接，均开启收发模式，每台OLT下挂数量不等的几台到几十台ONU，采用SpirentSmartBits给设备打流模拟现网环境。考虑设备数量不多，不进行深度控制，最终得到如图4所示的拓扑图，对其进行深度控制测试同样可得到正确的拓扑图。双击即可查看OLT设备的LLDP配置信息，并得到管理IP和VLAN，据此可以进行远程管理。以上测试的拓扑为现网最常用的连接方式，即交换机与OLT同一等级的上联口相连，但也可能出现用户将一些小型交换机接在ONU端口下面的情况。如果要处理这种特殊的情形，不仅需要升级主控盘版本，还要对线卡盘和各种类型的ONU版本都做相应的升级。考虑到各地现网的版本类型，尤其是ONU的软硬件版本类型都各不相同，要做全面升级，工程量很大，且一般OLT下挂的ONU较多，需要虚拟大量的端口，占用系统资源较多。由于工程上暂未提出需求，因而这里只是尝试性地提出一种理论上可行而不加验证的解决方案。若现网工程上有需求，该方案将是一种很好的解决办法，具体处理方法如下。收方向：ONU收到下接其它设备的LLDP报文后，修改报文，增加ONU的ID和UNI号信息。OLT线卡盘收到修改后的LLDP报文后，根据接收报文的PON口号，通过PON口号+（ONUID）+（ONUUNI号）就可以虚拟出唯一一个LLDP接口供SNMP工作站调用。对于没有能力修改LLDP报文的ONU，可根据LLDP报文的源MAC地址，通过OAM消息查询ONU的MAC地址表来获取UNI号信息，同样可以达到相同的效果。发方向：不能修改LLDP标准帧，而需要OLT线卡将PON口号+（ONUID）+（ONUUNI号）信息虚拟成唯一接口填入接口TLV里，并将封装的报文发往相应的ONU端口，对端设备将毫无障碍地解析到本地LLDP信息。由于LLDP对网络拓扑的精确发现以及它的标准化，越来越多的以太网设备开始支持LLDP协议。本文通过对LLDP在OLT设备上实现的研究，运用带有深度控制的拓扑发现算法，成功地绘制出可进行管理的拓扑图。针对设备的一种特殊连接情况，我们尝试性地提出了一种合理的解决方案，此方案对其它类似PON系统设备的有主从关系的以太网设备（如EoC设备）也有很好的借鉴意义。【相关文献】[1]王宇.以太网链路层拓扑发现软件的设计与实现[D].成都：电子科技大学，2009.[2]曾干.基于链路层发现协议（LLDP）的物理网络拓扑发现[J].电脑知识与技术，2006（20）:45-48.[3]IEEEStd803.1AB-2005.IEEEStandardforLocalandMetropolitanAreaNetworks:StationandMediaAccessControlConnectivityDiscovery[S].2005.[4]ANSI/TIA-1057-2006.TIAStandard,Telecommunications,IPTelephonyInfrastructure,LinkLayerDiscorveryProtocolforMediaEndpointDevices[S].2006.',)