法律状态公告日
法律状态信息
法律状态
2016-03-30
授权
授权
2013-09-18
实质审查的生效 IPC(主分类):H04L12/741 申请日:20130524
实质审查的生效
2013-08-21
公开
公开
技术领域
本发明涉及网络通信技术领域，特别涉及一种OFS带内通信方法及 OFS。
背景技术
控制面与转发面相分离，是SDN（Software Defined Network，软件定义 网络）/OpenFlow（开放流）的一个基本特征。控制面基于全网视图制定路 由策略，转发面根据收到的路由决策处理数据包。OFS(OpenFlow Switch， 开放流交换机)与OFC(OpenFlow Controller，开源控制器)之间建立TCP连 接是OpenFlow网络能够正常工作的一个基本前提。
目前，OFS与OFC之间一般采用带外连接模式。图1是一种现有的带 外连接模式组网图，控制面与转发面分别由两个不同的物理网组成。其中， 控制面由交换机Switch、OFS1、OFS2、OFS3、OFS4、OFS5、OFS6及控 制器OF_Controller组成；数据面则有交换机OFS1、OFS2、OFS3、OFS4、 OFS5及OFS6组成。
在图1所示网络中，Switch首先在传统交换机的工作模式下，基于LLDP 及STP等协议打通控制面，也即通过STP等协议生成的MAC表实现各种 OpenFlow控消息的转发，控制消息指OpenFlow规范定义的各种 Controller-to-Switch消息、Asynchronous消息及Symmetric消息。控制面打 通后，OFC便可以向OFS下发初始的流表项，OFS接收到流表项后，将其 添加到相应的流表中，进而便可以根据流表处理数据包。
该方案的缺点主要在于，需要维护两个单独的物理网络和两个网络管理 系统（一个用于管理控制面的网络，另一个用于管理转发面的流交换的网 络），成本比较高。
发明内容
（一）要解决的技术问题
本发明要解决的技术问题是：如何提供一种OFS带内通信方法及OFS，， 以降低组网成本。
（二）技术方案
第一方面，本发明提供一种OFS带内通信方法，其由OFS执行，所述OFS 包括控制器列表，所述控制器列表用于保存一个或多个控制器列表表项，所 述控制器列表表项包括本地开放流控制器OFC的MAC、IP以及与所述本地 OFC的MAC、IP对应的所述OFS接收所述OFC发送的链路层发现协议LLDP 数据包时的端口号，所述方法包括：
接收所述LLDP数据包，所述LLDP数据包包含发送方的MAC、IP以及用 于标识发送方类型的角色子字段；
当通过所述角色子字段判断接收到的所述LLDP数据包的发送方类型为 OFC时，新建或更新所述控制器列表表项，新建或更新的控制器列表表项包 括所述LLDP数据包中携带的所述本地OFC的MAC、IP以及收到所述LLDP 数据包的端口in_port；
所述方法还包括：
获取用于建立TCP连接的第一次TCP握手包，根据所述TCP握手包中携 带的目的MAC以及目的IP查找所述控制器列表中是否有对应的控制器列表 表项，如果有，则根据所述控制器列表中对应的控制器列表表项中的MAC、 IP以及in_port更新流表项，使得所述OFS能够通过流表将发往OFC的包转发 到OFC。
在第一方面的第一种可能的实现方式中，所述方法还包括步骤：
广播发送方类型为OFC的所述LLDP数据包，使得其他OFS也能够执 行，所述接收所述LLDP数据包，所述LLDP数据包包含发送方的MAC、 IP以及用于标识发送方类型的角色子字段，和，当通过所述角色子字段判断 接收到的所述LLDP数据包的发送方类型为OFC时，新建或更新所述控制 器列表表项，新建或更新的控制器列表表项包括所述LLDP数据包中携带的 所述本地OFC的MAC、IP以及收到所述LLDP数据包的端口in_port的步 骤。
在第一方面的第二种可能的实现方式中，所述角色子字段位于所述 LLDP数据包中的标签长度值TLV字段。
在第一方面的第三种可能的实现方式中，所述OFS包括硬件模块以及 软件模块；
所述接收所述LLDP数据包，具体为：所述OFS的硬件模块接收所述 LLDP数据包，根据接收到的所述LLDP数据包查询所述流表产生LLDP类型 的packet_in消息，并将所述LLDP类型的packet_in消息发送到所述软件模块；
所述角色子字段的获得过程如下：
所述OFS的软件模块接收所述硬件模块发送的packet_in消息，解析所 述packet_in消息，判断所述packet_in消息是否是所述LLDP类型的packet_in 消息；
当判断所述packet_in消息是所述LLDP类型的packet_in消息时，所述 OFS的软件模块从所述LLDP类型的packet_in消息中解析出所述LLDP数 据包，并从所述LLDP数据包的TLV字段中解析出所述角色子字段；
所述新建或更新所述控制器列表表项，具体包括：
所述OFS的软件模块从所述LLDP数据包的TLV字段中解析出发送方 的MAC、IP，并从所述LLDP类型的packet_in消息中解析出所述OFS收到 所述LLDP数据包的端口in_port；
所述OFS的软件模块查询所述控制器列表，判断是否存在与解析得到 的MAC、IP相匹配的控制器列表表项，如果不存在，新建控制器列表表项 以记录解析得到的MAC、IP、in_port，并设置预定的老化时间，然后使用 packet_out消息将所述LLDP数据包FLOOD；如果存在，
所述OFS的软件模块判断与解析得到的MAC、IP相匹配的控制器列表 表项中的in_port是否与解析得到的in_port相同，如果相同，则将该控制器 列表表项对应的老化时间重置为预定的老化时间，然后使用packet_out消息 将所述LLDP数据包FLOOD，如果不同，
所述OFS的软件模块进一步判断该控制器列表表项对应的老化时间是 否到达，如果到达，将该控制器列表表项中的in_port修改为解析得到的 in_port，然后使用packet_out消息将所述LLDP数据包FLOOD，如果未到 达，
所述OFS的软件模块丢弃所述LLDP数据包。
在第一方面的第四种可能的实现方式中，所述OFS包括硬件模块以及 软件模块；
获取用于建立TCP连接的第一次TCP握手包，根据所述TCP握手包中 携带的目的MAC以及目的IP查找所述控制器列表中是否有对应的控制器列 表表项，如果有，则根据所述控制器列表中对应的控制器列表表项中的 MAC、IP以及in_port更新流表项，使得所述OFS能够通过流表将发往OFC 的包转发到OFC，具体包括：
所述OFS的硬件模块接收用于建立TCP连接的第一次TCP握手包，解 析所述第一次TCP握手包得到目的MAC和目的IP，根据解析到的目的MAC 和目的IP查询所述流表，产生TCP类型的packet_in消息，并将所述TCP 类型的packet_in消息发送到所述软件模块；
所述OFS的软件模块接收从所述硬件模块发送的packet_in消息，解析 所述packet_in消息，判断所述packet_in消息是否是所述TCP类型的 packet_in消息；
当判断所述packet_in消息是所述TCP类型的packet_in消息时，所述 OFS的软件模块从所述TCP类型的packet_in消息中解析出所述第一次TCP 握手包，并从所述第一次TCP握手包中解析出源MAC、源IP、目的MAC 和目的IP；
所述OFS的软件模块根据解析出的目的MAC和目的IP查询所述控制 器列表，判断是否存在与解析出的目的MAC和目的IP相匹配的控制器列表 表项，如果存在，生成第一流表项和第二流表项，并将所述第一流表项和第 二流表项发送给所述OFS的硬件模块，所述第一流表项中记录源MAC为解 析出的源MAC，源IP为解析出的源IP，目的MAC为解析出的目的MAC， 目的IP为解析出的目的IP，转发端口为与解析出的目的MAC和目的IP相 匹配的控制器列表表项中的in_port，所述第二表项中记录源MAC为解析出 的目的MAC，源IP为解析出的目的IP，目的MAC为解析出的源MAC， 目的IP为解析出的源IP，转发端口为所述TCP类型的packet_in消息中的 in_port字段；
所述OFS的硬件模块，接收所述第一流表项和第二流表项，并将所述第 一流表项和第二流表项添加至所述流表。
在第一方面的第五种可能的实现方式中，当所述控制器列表存在与解析 出的目的MAC和目的IP相匹配的控制器列表表项时，还包括步骤：
所述OFS的软件模块产生packet-out消息，将所述packet-out消息发送 给所述OFS的硬件模块，所述packet-out消息的执行动作action字段指向所 述流表；
所述OFS的硬件模块解析所述packet-out消息，得到其中的所述第一次 TCP握手包，解析所述第一次TCP握手包得到目的MAC和目的IP，根据 解析到的目的MAC和目的IP查询所述流表，找到与解析到的目的MAC和 目的IP相匹配的流表项，根据该流表项中的转发端口转发所述第一次TCP 握手包。
在第一方面的第六种可能的实现方式中，当所述控制器列表不存在与解 析出的目的MAC和目的IP相匹配的表项时，还包括步骤：
所述OFS的软件模块通过所述OFS的管理端口发送所述TCP类型的 packet_in消息。
在第一方面的第七种可能的实现方式中，所述OFS向所述流表中添加第 一初始流表项，所述第一初始流表项的目的地址为LLDP协议的组播地址， 协议类型为LLDP协议的类型编码，转发端口指向OFC，数据包长度为全包 长度，优先级为最低。
在第一方面的第八种可能的实现方式中，所述OFS向所述流表中添加第 二初始流表项，所述第二初始流表项的目的地址为本地地址，协议类型为 TCP协议的类型编码，转发端口指向所述OFS的管理端口，数据包长度为全 包长度，优先级为最低。
在第一方面的第九种可能的实现方式中，所述OFS还包括邻居列表，所 述邻居列表包括一个或多个邻居列表表项，所述邻居列表表项包括其他OFS 的MAC、IP以及与所述其他OFS的MAC、IP对应的所述OFS接收所述其他 OFS发送的LLDP数据包时的端口号；
当通过所述角色子字段判断接收到的所述LLDP数据包的发送方类型为 OFS时，所述方法还包括步骤：
所述OFS的软件模块从所述LLDP数据包的TLV字段中解析出发送方 MAC、IP，并从所述LLDP类型的packet_in消息中解析出所述OFS收到所 述LLDP数据包的端口in_port；
所述OFS的软件模块查询所述邻居列表，判断是否存在与解析得到的 MAC、IP相匹配的邻居列表表项，如果不存在，在所述邻居列表中新建邻 居列表表项以记录解析得到的MAC、IP和in_port，然后使用packet_out消 息将所述LLDP数据包FLOOD；如果存在，
则判断与解析得到的MAC、IP相匹配的邻居列表表项对应的in_port 是否与解析得到的in_port相同，如果相同，使用packet_out消息将所述LLDP 数据包FLOOD，如果不同，
将该邻居列表表项对应的in_port修改为解析得到的in_port，然后丢弃所 述LLDP数据包。
在第一方面的第十种可能的实现方式中，所述OFS将所述邻居列表发送 至OFC，以供所述OFC根据邻居列表建立全网的网络拓扑；
当所述邻居列表改变时，所述OFS将改变后的邻居列表发送给所述 OFC，以供所述OFC根据改变后的邻居列表更新全网的网络拓扑。
在第一方面的第十一种可能的实现方式中，所述发往OFC的包既包括第 三次TCP握手包，也包括其他OFS发往所述OFC的数据包。
第二方面，提供一种OFS，包括：
控制器列表存储单元，用于保存一个或多个控制器列表表项，所述控制 器列表表项包括本地开放流控制器OFC的MAC、IP以及与所述本地OFC 的MAC、IP对应的所述OFS接收所述OFC发送的链路层发现协议LLDP 数据包时的端口号；
数据包接收单元，用于接收所述LLDP数据包，所述LLDP数据包包含发 送方的MAC、IP以及用于标识发送方类型的角色子字段；
数据包处理单元，用于当通过所述角色子字段判断接收到的所述LLDP 数据包的发送方类型为OFC时，新建或更新所述控制器列表表项，新建或 更新的控制器列表表项包括所述LLDP数据包中携带的所述本地OFC的 MAC、IP以及收到所述LLDP数据包的端口in_port；
握手包单元，用于获取用于建立TCP连接的第一次TCP握手包，根据所 述TCP握手包中携带的目的MAC以及目的IP查找所述控制器列表中是否有 对应的控制器列表表项，如果有，则根据所述控制器列表中对应的控制器列 表表项中的MAC、IP以及in_port更新流表项，使得所述OFS能够通过流表将 发往OFC的包转发到OFC。
在第二方面的第一种可能的实现方式中，所述OFS还包括：
数据包广播单元，用于广播发送方类型为OFC的所述LLDP数据包，使 得其他OFS也能够接收所述LLDP数据包，所述LLDP数据包包含发送方的 MAC、IP以及用于标识发送方类型的角色子字段，和，当通过所述角色子字 段判断接收到的所述LLDP数据包的发送方类型为OFC时，新建或更新所述 控制器列表表项，新建或更新的控制器列表表项包括所述LLDP数据包中携 带的所述本地OFC的MAC、IP以及收到所述LLDP数据包的端口in_port。
在第二方面的第二种可能的实现方式中，所述角色子字段位于所述 LLDP数据包中的标签长度值TLV字段。
在第二方面的第三种可能的实现方式中，所述数据包接收单元，具体用 于接收所述LLDP数据包，根据接收到的所述LLDP数据包查询所述流表产 生LLDP类型的packet_in消息，并将所述LLDP类型的packet_in消息发送 到数据通道；
所述数据包处理单元，具体用于从所述数据通道中获取packet_in消息， 解析所述packet_in消息，判断所述packet_in消息是否是所述LLDP类型的 packet_in消息，
当所述packet_in消息的是所述LLDP类型的packet_in消息时，从所述 LLDP类型的packet_in消息中解析出所述LLDP数据包，并从所述LLDP 数据包的TLV字段中解析出所述角色子字段，以及，
从所述LLDP数据包的TLV字段中解析出发送方的MAC、IP，并从所 述LLDP类型的packet_in消息中解析出所述OFS收到所述LLDP数据包的 端口in_port，
查询所述控制器列表，判断是否存在与解析得到的MAC、IP相匹配的 控制器列表表项，如果不存在，新建控制器列表表项以记录解析得到的 MAC、IP、in_port，并设置预定的老化时间，然后使用packet_out消息将所 述LLDP数据包FLOOD；如果存在，
判断与解析得到的MAC、IP相匹配的控制器列表表项中的in_port是否 与解析得到的in_port相同，如果相同，则将该控制器列表表项对应的老化 时间重置为预定的老化时间，然后使用packet_out消息将所述LLDP数据包 FLOOD，如果不同，
进一步判断该控制器列表表项对应的老化时间是否到达，如果到达，将 该控制器列表表项中的in_port修改为解析得到的in_port，然后使用 packet_out消息将所述LLDP数据包FLOOD，如果未到达，
丢弃所述LLDP数据包。
在第二方面的第四种可能的实现方式中，所述握手包单元包括：第一握 手包模块和第二握手包模块；
所述第一握手包模块，用于接收用于建立TCP连接的第一次TCP握手 包，解析所述第一次TCP握手包得到目的MAC和目的IP，根据解析到的 目的MAC和目的IP查询所述流表，产生TCP类型的packet_in消息，并将 所述TCP类型的packet_in消息发送到数据通道；
所述第二握手包模块用于从所述数据通道中获取packet_in消息，解析 所述packet_in消息，判断所述packet_in消息是否是所述TCP类型的 packet_in消息，
当所述packet_in消息是所述TCP类型的packet_in消息时，从所述TCP 类型的packet_in消息中解析出所述第一次TCP握手包，并从所述第一次TCP 握手包中解析出源MAC、源IP、目的MAC和目的IP，以及，
根据解析出的目的MAC和目的IP查询所述控制器列表，判断是否存在 与解析出的目的MAC和目的IP相匹配的控制器列表表项，如果存在，生成 第一流表项和第二流表项，并将所述第一流表项和第二流表项发送给所述第 一握手包模块，所述第一流表项中记录源MAC为解析出的源MAC，源IP 为解析出的源IP，目的MAC为解析出的目的MAC，目的IP为解析出的目 的IP，转发端口为与解析出的目的MAC和目的IP相匹配的控制器列表表 项中的in_port，所述第二表项中记录源MAC为解析出的目的MAC，源IP 为解析出的目的IP，目的MAC为解析出的源MAC，目的IP为解析出的源 IP，转发端口为所述TCP类型的packet_in消息中的in_port字段；
所述第一握手包模块，还用于接收所述第一流表项和第二流表项，并将 所述第一流表项和第二流表项添加至所述流表。
在第二方面的第五种可能的实现方式中，所述第二握手包模块，还用于 当所述控制器列表存在与解析出的目的MAC和目的IP相匹配的控制器列表 表项时，产生packet-out消息，将所述packet-out消息发送给所述第一握手 包模块，所述packet-out消息的执行动作action字段指向所述流表；
所述第一握手包模块，还用于解析所述packet-out消息，得到其中的所 述第一次TCP握手包，解析所述第一次TCP握手包得到目的MAC和目的IP， 根据解析到的目的MAC和目的IP查询所述流表，找到与解析到的目的MAC 和目的IP相匹配的流表项，根据该流表项中的转发端口转发所述第一次TCP 握手包。
在第二方面的第六种可能的实现方式中，所述第二握手包模块，还用于 当所述控制器列表不存在与解析出的目的MAC和目的IP相匹配的表项时，通 过所述OFS的管理端口发送所述TCP类型的packet_in消息。
在第二方面的第七种可能的实现方式中，所述OFS还包括：
第一流表项单元，用于向所述流表中添加第一初始流表项，所述第一初 始流表项的目的地址为LLDP协议的组播地址，协议类型为LLDP协议的类 型编码，转发端口指向OFC，数据包长度为全包长度，优先级为最低。
在第二方面的第八种可能的实现方式中，所述OFS还包括：
第二流表项单元，用于向所述流表中添加第二初始流表项，所述第二初 始流表项的目的地址为本地地址，协议类型为TCP协议的类型编码，转发 端口指向所述OFS的管理端口，数据包长度为全包长度，优先级为最低。
在第二方面的第九种可能的实现方式中，所述OFS还包括：
邻居列表存储单元，用于包括一个或多个邻居列表表项，所述邻居列表 表项包括其他OFS的MAC、IP以及与所述其他OFS的MAC、IP对应的所 述OFS接收所述其他OFS发送的LLDP数据包时的端口号；
所述数据包处理单元，还用于当通过所述角色子字段判断接收到的所述 LLDP数据包的发送方类型为OFS时，从所述LLDP数据包的TLV字段中解析 出发送方MAC、IP，并从所述LLDP类型的packet_in消息中解析出所述OFS 收到所述LLDP数据包的端口in_port，以及，
查询所述邻居列表，判断是否存在与解析得到的MAC、IP相匹配的邻 居列表表项，如果不存在，在所述邻居列表中新建邻居列表表项以记录解析 得到的MAC、IP和in_port，然后使用packet_out消息将所述LLDP数据包 FLOOD；如果存在，
则判断与解析得到的MAC、IP相匹配的邻居列表表项对应的in_port 是否与解析得到的in_port相同，如果相同，使用packet_out消息将所述LLDP 数据包FLOOD，如果不同，
将该邻居列表表项对应的in_port修改为解析得到的in_port，然后丢弃所 述LLDP数据包。
在第二方面的第十种可能的实现方式中，所述OFS还包括：
邻居列表发送单元，用于将所述邻居列表发送至OFC，以供所述OFC根 据邻居列表建立全网的网络拓扑，以及，
当所述邻居列表改变时，将改变后的邻居列表发送给所述OFC，以供所 述OFC根据改变后的邻居列表更新全网的网络拓扑。
在第二方面的第十一种可能的实现方式中，所述发往OFC的包既包括第 三次TCP握手包，也包括其他OFS发往所述OFC的数据包。
（三）有益效果
本发明所述OFS带内通信方法及OFS中，所述方法包括：接收LLDP数据 包，所述LLDP数据包包含发送方的MAC、IP以及用于标识发送方类型的角 色子字段；当通过所述角色子字段判断接收到的所述LLDP数据包的发送方 类型为OFC时，新建或更新所述控制器列表表项，新建或更新的控制器列表 表项包括所述LLDP数据包中携带的所述本地OFC的MAC、IP以及收到所述 LLDP数据包的端口in_port；获取用于建立TCP连接的第一次TCP握手包，根 据所述TCP握手包中携带的目的MAC以及目的IP查找所述控制器列表中是 否有对应的控制器列表表项，如果有，则根据所述控制器列表中对应的控制 器列表表项中的MAC、IP以及in_port更新流表项，使得所述OFS能够通过流 表将发往OFC的包转发到OFC。通过采用本发明的OFS带内通信方法及OFS， 控制面信令和转发面数据承载于同一个OpenFlow网络中，仅需维护一个网 管系统，即可实现网络通信，降低了组网成本。
附图说明
图1是一种现有的带外连接模式组网图；
图2a是本发明实施例1所述OFS带内通信方法的流程图；
图2b是本发明实施例1所述OFS带内通信方法的步骤220的细化流程图；
图2c是本发明实施例1所述OFS带内通信方法的步骤230的细化流程图；
图2d是实现本发明实施例1所述OFS带内通信方法的带内连接模式组网 图；
图3是本发明实施例三所述OFS的内部模块结构示意图；
图4是本发明实施例三所述握手包单元的内部模块结构示意图；
图5是本发明实施例四所述OFS的内部模块结构示意图；
图6是本发明所述OFS的硬件结构示意图。
具体实施方式
下面结合附图和实施例，对本发明的具体实施方式作进一步详细描述。 以下实施例用于说明本发明，但不用来限制本发明的范围。
本发明旨在利用现有的OpenFlow（v1.2）规范及LLDP（Link Layer Discovery Protocol，链路层发现协议）协议，实现一种OFS带内通信方法， 该方法中，每个OFS对其所转发的数据包的内容（是控制信息或者数据信息） 不作区分，每个OFS的控制信息均作为其他OFS的数据信息在网络中转发， 只有当某个数据包的目的地址指向自身时，该OFS解析该数据包获得其中的 控制信息。因此，上述方法基于一个物理网络，仅需维护一个网管系统，即 可实现带内通信，有效降低了实施成本。
接下来，结合具体实施例详细说明本发明的OFS带内通信方法及OFS。
实施例一
图2a是本发明实施例1所述OFS带内通信方法的流程图，如图2a所示，所 述方法由OFS执行，所述方法包括步骤：
210：接收所述LLDP数据包，所述LLDP数据包包含发送方的MAC、IP 以及用于标识发送方类型的角色子字段。
具体地，所述LLDP数据包可能由OFC发送，也可以由其他OFS发送， 为了使接收方能够识别发送方的类型，在所述LLDP数据包中包含有用于标 识发送方类型的角色子字段。
优选地，所述角色子字段位于所述LLDP数据包中的标签长度值TLV字 段。下面表3是LLDP数据包的字段示例，所述LLDP数据包包括：Eth_dst字 段、Eth_src字段、Eth_type字段和标签长度值TLV（BER编码一种，ASN1 标准，全称Tag，Length，Value）字段；该TLV字段包括：MAC（Media Access Control，硬件地址）子字段、IP（Internet Protocol，网络之间互连的协议） 子字段、角色子字段、端口子字段。其中，表3中第一行表示由OFC发出的 LLDP数据包，其角色子字段对应于OFC，其端口子字段对应OFC的监听端 口；表3中第二行表示由OFS发出的LLDP数据包，其角色子字段对应于OFS， 其端口子字段对应OFS的物理端口号。
表3 LLDP数据包的字段示例
所述OFS包括硬件模块以及软件模块，硬件模块（基于一些专用的硬件 定制器件，如FPGA、ASIC等）用于在OFS收到包后进行流表匹配，即收到 包后通过硬件模块匹配流表，如果能匹配，则按匹配项中的指令进行转发， 如果不匹配，则将包送至软件模块（基于CPU）。其中，所述接收所述LLDP 数据包，具体为：所述OFS的硬件模块接收所述LLDP数据包，根据接收到 的所述LLDP数据包查询流表，匹配不成功后，产生packet_in消息，并将 packet_in消息发送到软件模块。
220：当通过所述角色子字段判断接收到的所述LLDP数据包的发送方类 型为OFC时，新建或更新所述控制器列表表项，新建或更新的控制器列表表 项包括所述LLDP数据包中携带的所述本地OFC的MAC、IP以及收到所述 LLDP数据包的端口in_port。
具体地，所述OFS包括控制器列表，所述控制器列表用于保存一个或多 个控制器列表表项，所述控制器列表表项包括本地开放流控制器OFC的 MAC、IP以及与所述本地OFC的MAC、IP对应的所述OFS接收所述OFC发送 的链路层发现协议LLDP数据包时的端口号。所述OFS根据接收到的所述 LLDP数据包新建或更新所述控制器列表表项，进而根据控制器列表表项更 新流表项，以建立所述OFS与OFC之间的连接。
图2b是本发明实施例1所述OFS带内通信方法的步骤220的细化流程图， 所述步骤220具体包括：
221：OFS的软件模块接述硬件模块发送的packet_in消息（硬件模块查 流表不成功时会生成packet_in消息），解析packet_in消息，判断packet_in 消息是否是LLDP类型的packet_in消息。
222：当packet_in消息的是LLDP类型的packet_in消息时，OFS的软 件模块从LLDP类型的packet_in消息中解析出LLDP数据包，并从LLDP 数据包的TLV字段中解析出角色子字段。
223：当根据角色子字段判断接收到的LLDP数据包的发送方类型为 OFC时，OFS的软件模块从LLDP数据包的TLV字段中解析出发送方的 MAC、IP，并从LLDP类型的packet_in消息中解析出OFS收到LLDP数据 包的端口in_port。
224：OFS的软件模块查询控制器列表，判断是否存在与解析得到的 MAC、IP相匹配的控制器列表表项，如果不存在，新建控制器列表表项以 记录解析得到的MAC、IP、in_port，并设置预定的老化时间，然后使用 packet_out消息将LLDP数据包FLOOD（FOOD即从入端口以外的所有可用 端口转发）；如果存在，执行步骤225。
225：OFS的软件模块判断与解析得到的MAC、IP相匹配的控制器列 表表项中的in_port是否与解析得到的in_port相同，如果相同，则将该控制 器列表表项对应的老化时间重置为预定的老化时间，然后使用packet_out消 息将LLDP数据包FLOOD，如果不同，执行步骤226。
226：OFS的软件模块进一步判断该控制器列表表项对应的老化时间是 否到达，如果到达，将该控制器列表表项中的in_port修改为解析得到的 in_port，然后使用packet_out消息将LLDP数据包FLOOD，如果未到达， OFS的软件模块丢弃LLDP数据包。
方法还包括：
230：获取用于建立TCP连接的第一次TCP握手包，根据TCP握手包中携 带的目的MAC以及目的IP查找控制器列表中是否有对应的控制器列表表项， 如果有，则根据控制器列表中对应的控制器列表表项中的MAC、IP以及 in_port更新流表项，使得OFS能够通过流表将发往OFC的包转发到OFC。
其中，流表建立后，OFS基于流表完成与OFC之间的TCP握手通信，建 立与OFC之间的TCP连接。发往OFC的包既包括第三次TCP握手包，也包括 其他OFS发往OFC的数据包。
图2c是本发明实施例1OFS带内通信方法的步骤230的细化流程图，步骤 230具体包括：
231：OFS的硬件模块接收用于建立TCP连接的第一次TCP握手包， 解析第一次TCP握手包得到目的MAC和目的IP，根据解析到的目的MAC 和目的IP查询流表，产生TCP类型的packet_in消息，并将TCP类型的 packet_in消息发送到软件模块；
232：OFS的软件模块接收硬件模块发送中获取packet_in消息，解析 packet_in消息，判断packet_in消息是否是TCP类型的packet_in消息；
233：当判断packet_in消息是TCP类型的packet_in消息时，OFS的软 件模块从TCP类型的packet_in消息中解析出第一次TCP握手包，并从第一 次TCP握手包中解析出源MAC、源IP、目的MAC和目的IP；
234：OFS的软件模块根据解析出的目的MAC和目的IP查询控制器列 表，判断是否存在与解析出的目的MAC和目的IP相匹配的控制器列表表项， 如果存在，执行步骤235，237，不存在时执行239。
235：生成第一流表项和第二流表项，并将第一流表项和第二流表项发 送给OFS的硬件模块，第一流表项中记录源MAC为解析出的源MAC，源 IP为解析出的源IP，目的MAC为解析出的目的MAC，目的IP为解析出的 目的IP，转发端口为与解析出的目的MAC和目的IP相匹配的控制器列表 表项中的in_port，第二表项中记录源MAC为解析出的目的MAC，源IP为 解析出的目的IP，目的MAC为解析出的源MAC，目的IP为解析出的源IP， 转发端口为TCP类型的packet_in消息中的in_port字段。
236：OFS的硬件模块，接收第一流表项和第二流表项，并将第一流表 项和第二流表项添加至流表。
另外，当控制器列表存在与解析出的目的MAC和目的IP相匹配的控制 器列表表项时，还包括步骤：
237：OFS的软件模块产生packet-out消息，将packet-out消息发送给 OFS的硬件模块，packet-out消息的执行动作action字段指向流表。
238：OFS的硬件模块解析packet-out消息，得到其中的第一次TCP握 手包，解析第一次TCP握手包得到目的MAC和目的IP，根据解析到的目 的MAC和目的IP查询流表，找到与解析到的目的MAC和目的IP相匹配 的流表项，根据该流表项中的转发端口转发第一次TCP握手包。
当控制器列表不存在与解析出的目的MAC和目的IP相匹配的表项时， 还包括步骤：
239：OFS的软件模块通过OFS的管理端口发送TCP类型的packet_in 消息。
图2d是实现本发明实施例OFS带内通信方法的带内连接模式组网图， 如图2d所示，本发明实施例中，每个OFS对其所转发的数据包的内容（是 控制信息或者数据信息）不作区分，每个OFS的控制信息均作为其他OFS 的数据信息在网络中转发，只有当某个数据包的目的地址指向自身时，该 OFS解析该数据包获得其中的控制信息。因此，上述方法基于一个物理网络， 仅需维护一个网管系统，即可实现带内通信，有效降低了实施成本。另外， OFS通过解析来自OFC的LLDP包，可以实现OFS对OFC的自发现，减 少了交换机配置时间。
实施例二
本实施例二基于实施例1进行描述。
可选地，所述方法在步骤210之前还可以包括：
所述OFS向所述流表中添加第一初始流表项，所述第一初始流表项的目 的地址为LLDP协议的组播地址，协议类型为LLDP协议的类型编码，转发端 口指向OFC，数据包长度为全包长度，优先级为最低。
所述OFS向所述流表中添加第二初始流表项，所述第二初始流表项的目 的地址为本地地址，协议类型为TCP协议的类型编码，转发端口指向所述OFS 的管理端口，数据包长度为全包长度，优先级为最低。
具体地，下面表1是第一初始流表项示例，，其中，01:80:c2:00:00:0e表 示LLDP协议的组播地址，其为MAC地址；0x88CC表示LLDP协议的类型编 码；Controller表示指向OFC的转发端口；OFPR_NO_BUFFER表示数据包长 度为全包长度
表1 第一初始流表项示例
下面表2是第二初始流表项示例，其中，第一个Self表示指向本地的MAC 地址；0x0800表示TCP协议的类型编码；第二个Self表示指向本地的IP地址； LOCAL表示转发端口指向所述OFS的管理端口；OFPR_NO_BUFFER表示数 据包长度为全包长度。
表2 第二初始流表项示例
通过设置所述第一初始流表项后，所述OFS的硬件模块接收所述LLDP 数据包，根据接收到的所述LLDP数据包查询所述流表产生LLDP类型的 packet_in消息，并将所述LLDP类型的packet_in消息发送到软件模块，进而 触发所述OFS的软件模块对LLDP类型的packet_in消息进行后续处理。
通过设置所述第二初始流表项后，所述OFS的硬件模块接收用于建立 TCP连接的第一次TCP握手包，解析所述第一次TCP握手包得到目的MAC和 目的IP，根据解析到的目的MAC和目的IP查询所述流表，产生TCP类型的 packet_in消息，并将所述TCP类型的packet_in消息发送到软件模块，进而触 发所述OFS的软件模块对TCP类型的packet_in消息进行后续处理。
可选地，所述方法中，当通过所述角色子字段判断接收到的所述LLDP 数据包的发送方类型为OFC时，还包括：
广播发送方类型为OFC的所述LLDP数据包，使得其他OFS也能够执行， 所述接收所述LLDP数据包，所述LLDP数据包包含发送方的MAC、IP以及用 于标识发送方类型的角色子字段，和，当通过所述角色子字段判断接收到的 所述LLDP数据包的发送方类型为OFC时，新建或更新所述控制器列表表项， 新建或更新的控制器列表表项包括所述LLDP数据包中携带的所述本地OFC 的MAC、IP以及收到所述LLDP数据包的端口in_port的步骤。
可选地，所述OFS还包括邻居列表，所述邻居列表包括一个或多个邻居 列表表项，所述邻居列表表项包括其他OFS的MAC、IP以及与所述其他OFS 的MAC、IP对应的所述OFS接收所述其他OFS发送的LLDP数据包时的端口 号。
所述步骤210之后，还包括步骤：
当通过所述角色子字段判断接收到的所述LLDP数据包的发送方类型为 OFS时，所述OFS的软件模块从所述LLDP数据包的TLV字段中解析出发送方 MAC、IP，并从所述LLDP类型的packet_in消息中解析出所述OFS收到所述 LLDP数据包的端口in_port；
所述OFS的软件模块查询所述邻居列表，判断是否存在与解析得到的 MAC、IP相匹配的邻居列表表项，如果不存在，在所述邻居列表中新建邻 居列表表项以记录解析得到的MAC、IP和in_port，然后使用packet_out消 息将所述LLDP数据包FLOOD；如果存在，
则判断与解析得到的MAC、IP相匹配的邻居列表表项对应的in_port 是否与解析得到的in_port相同，如果相同，使用packet_out消息将所述LLDP 数据包FLOOD，如果不同，
将该邻居列表表项对应的in_port修改为解析得到的in_port，然后丢弃所 述LLDP数据包。
另外，在所述步骤230之后还可以包括：
所述OFS将所述邻居列表发送至OFC，以供所述OFC根据邻居列表建立 全网的网络拓扑；
当所述邻居列表改变时，所述OFS将改变后的邻居列表发送给所述 OFC，以供所述OFC根据改变后的邻居列表更新全网的网络拓扑。
也就是说，OFS与OFC之间的TCP连接建立后，各OFS主动将其所掌握 的邻居列表发送给OFC，OFC汇总后可以得到全网的网络拓扑。另外，当邻 居列表改变时，OFS将改变后的邻居列表发送给OFC，OFC根据改变后的邻 居列表更新全网的网络拓扑。
本实施例中，由OFS代替OFC来完成网络拓扑的发现，大大减小了网络 拓扑发现的时间。
实施例三
图3是本发明实施例三所述OFS的内部模块结构示意图，如图3所示， 所述OFS300包括：控制器列表存储单元310、数据包接收单元320、数据 包处理单元330和握手包单元340。
所述控制器列表存储单元310，用于保存一个或多个控制器列表表项， 所述控制器列表表项包括本地开放流控制器OFC的MAC、IP以及与所述本 地OFC的MAC、IP对应的所述OFS接收所述OFC发送的链路层发现协议 LLDP数据包时的端口号。
所述数据包接收单元320，用于接收所述LLDP数据包，所述LLDP数据 包包含发送方的MAC、IP以及用于标识发送方类型的角色子字段。
其中，所述角色子字段位于所述LLDP数据包中的标签长度值TLV字段。
所述数据包接收单元320，具体用于接收所述LLDP数据包，根据接收到 的所述LLDP数据包查询所述流表产生LLDP类型的packet_in消息，并将所述 LLDP类型的packet_in消息发送到数据通道。
所述数据包处理单元330，用于当通过所述角色子字段判断接收到的所 述LLDP数据包的发送方类型为OFC时，新建或更新所述控制器列表表项， 新建或更新的控制器列表表项包括所述LLDP数据包中携带的所述本地 OFC的MAC、IP以及收到所述LLDP数据包的端口in_port。
所述数据包处理单元330，具体用于从所述数据通道中获取packet_in 消息，解析所述packet_in消息，判断所述packet_in消息是否是所述LLDP 类型的packet_in消息，
当判断所述packet_in消息的是所述LLDP类型的packet_in消息时，从 所述LLDP类型的packet_in消息中解析出所述LLDP数据包，并从所述 LLDP数据包的TLV字段中解析出所述角色子字段，以及，
从所述LLDP数据包的TLV字段中解析出发送方的MAC、IP，并从所 述LLDP类型的packet_in消息中解析出所述OFS收到所述LLDP数据包的 端口in_port，
查询所述控制器列表，判断是否存在与解析得到的MAC、IP相匹配的 控制器列表表项，如果不存在，新建控制器列表表项以记录解析得到的 MAC、IP、in_port，并设置预定的老化时间，然后使用packet_out消息将所 述LLDP数据包FLOOD；如果存在，
判断与解析得到的MAC、IP相匹配的控制器列表表项中的in_port是否 与解析得到的in_port相同，如果相同，则将该控制器列表表项对应的老化 时间重置为预定的老化时间，然后使用packet_out消息将所述LLDP数据包 FLOOD，如果不同，
进一步判断该控制器列表表项对应的老化时间是否到达，如果到达，将 该控制器列表表项中的in_port修改为解析得到的in_port，然后使用 packet_out消息将所述LLDP数据包FLOOD，如果未到达，
丢弃所述LLDP数据包。
所述握手包单元340，用于获取用于建立TCP连接的第一次TCP握手 包，根据所述TCP握手包中携带的目的MAC以及目的IP查找所述控制器 列表中是否有对应的控制器列表表项，如果有，则根据所述控制器列表中对 应的控制器列表表项中的MAC、IP以及in_port更新流表项，使得所述OFS 能够通过流表将发往OFC的包转发到OFC。
参见图4，所述握手包单元340包括：第一握手包模块341和第二握手 包模块342。
所述第一握手包模块341，用于接收用于建立TCP连接的第一次TCP 握手包，解析所述第一次TCP握手包得到目的MAC和目的IP，根据解析 到的目的MAC和目的IP查询所述流表，产生TCP类型的packet_in消息， 并将所述TCP类型的packet_in消息发送到数据通道。
所述第二握手包模块342，用于从所述数据通道中获取packet_in消息， 解析所述packet_in消息，判断所述packet_in消息是否是所述TCP类型的 packet_in消息，
当所述packet_in消息是所述TCP类型的packet_in消息时，从所述TCP 类型的packet_in消息中解析出所述第一次TCP握手包，并从所述第一次TCP 握手包中解析出源MAC、源IP、目的MAC和目的IP，以及，
根据解析出的目的MAC和目的IP查询所述控制器列表，判断是否存在 与解析出的目的MAC和目的IP相匹配的控制器列表表项，如果存在，生成 第一流表项和第二流表项，并将所述第一流表项和第二流表项发送给所述第 一握手包模块，所述第一流表项中记录源MAC为解析出的源MAC，源IP 为解析出的源IP，目的MAC为解析出的目的MAC，目的IP为解析出的目 的IP，转发端口为与解析出的目的MAC和目的IP相匹配的控制器列表表 项中的in_port，所述第二表项中记录源MAC为解析出的目的MAC，源IP 为解析出的目的IP，目的MAC为解析出的源MAC，目的IP为解析出的源 IP，转发端口为所述TCP类型的packet_in消息中的in_port字段。
所述第一握手包模块341，还用于接收所述第一流表项和第二流表项， 并将所述第一流表项和第二流表项添加至所述流表。
所述第二握手包模块342，还用于当所述控制器列表存在与解析出的目 的MAC和目的IP相匹配的控制器列表表项时，产生packet-out消息，将所 述packet-out消息发送给所述第一握手包模块，所述packet-out消息的执行 动作action字段指向所述流表。
所述第一握手包模块341，还用于解析所述packet-out消息，得到其中 的所述第一次TCP握手包，解析所述第一次TCP握手包得到目的MAC和 目的IP，根据解析到的目的MAC和目的IP查询所述流表，找到与解析到 的目的MAC和目的IP相匹配的流表项，根据该流表项中的转发端口转发所 述第一次TCP握手包。
所述第二握手包模块342，还用于当所述控制器列表不存在与解析出的 目的MAC和目的IP相匹配的表项时，通过所述OFS的管理端口发送所述 TCP类型的packet_in消息。
实施例四
本实施例基于实施例三进行描述。图5是本发明实施例四所述OFS的 内部模块结构示意图，如图5所示，本实施例所述OFS500除包括：控制器 列表存储单元510、数据包接收单元520、数据包处理单元530和握手包单 元540之外，还包括：数据包广播单元550、第一流表项单元560、第二流 表项单元570、邻居列表存储单元580和邻居列表发送单元590。
所述数据包广播单元550，用于广播发送方类型为OFC的所述LLDP 数据包，使得其他OFS也能够接收所述LLDP数据包，所述LLDP数据包 包含发送方的MAC、IP以及用于标识发送方类型的角色子字段，和，当通 过所述角色子字段判断接收到的所述LLDP数据包的发送方类型为OFC时， 新建或更新所述控制器列表表项，新建或更新的控制器列表表项包括所述 LLDP数据包中携带的所述本地OFC的MAC、IP以及收到所述LLDP数据 包的端口in_port。
所述第一流表项单元560，用于向所述流表中添加第一初始流表项，所 述第一初始流表项的目的地址为LLDP协议的组播地址，协议类型为LLDP 协议的类型编码，转发端口指向OFC，数据包长度为全包长度，优先级为最 低。
所述第二流表项单元570，用于向所述流表中添加第二初始流表项，所 述第二初始流表项的目的地址为本地地址，协议类型为TCP协议的类型编 码，转发端口指向所述OFS的管理端口，数据包长度为全包长度，优先级 为最低。
所述邻居列表存储单元580，用于包括一个或多个邻居列表表项，所述 邻居列表表项包括其他OFS的MAC、IP以及与所述其他OFS的MAC、IP 对应的所述OFS接收所述其他OFS发送的LLDP数据包时的端口号。
所述数据包处理单元530，还用于当通过所述角色子字段判断接收到的 所述LLDP数据包的发送方类型为OFS时，从所述LLDP数据包的TLV字段中 解析出发送方MAC、IP，并从所述LLDP类型的packet_in消息中解析出所述 OFS收到所述LLDP数据包的端口in_port，以及，
查询所述邻居列表，判断是否存在与解析得到的MAC、IP相匹配的邻 居列表表项，如果不存在，在所述邻居列表中新建邻居列表表项以记录解析 得到的MAC、IP和in_port，然后使用packet_out消息将所述LLDP数据包 FLOOD；如果存在，
则判断与解析得到的MAC、IP相匹配的邻居列表表项对应的in_port 是否与解析得到的in_port相同，如果相同，使用packet_out消息将所述LLDP 数据包FLOOD，如果不同，
将该邻居列表表项对应的in_port修改为解析得到的in_port，然后丢弃 所述LLDP数据包。
所述邻居列表发送单元590，用于将所述邻居列表发送至OFC，以供所 述OFC根据邻居列表建立全网的网络拓扑，以及，
当所述邻居列表改变时，将改变后的邻居列表发送给所述OFC，以供所 述OFC根据改变后的邻居列表更新全网的网络拓扑。
本发明实施例中的OFS可以基于计算机系统来实现，图2a、图2b、图2c 所示的方法均可在基于计算机系统的OFS来实现。图6示出了基于计算机系 统来实现的OFS的实施例。本实施例中OFS可以包括：处理器601、存储器602 和通信接口603，其中：
通信接口603，用于与OFC或其他OFS通信。具体地，通信接口603用于 接收LLDP数据包和第一次TCP握手包；存储器602用于存储程序指令、控制 器列表和流表等；处理器601用于在接收所述LLDP数据包之后，调用存储器 602中存储的程序指令，执行如下操作：当通过所述角色子字段判断接收到 的所述LLDP数据包的发送方类型为OFC时，新建或更新所述控制器列表表 项，新建或更新的控制器列表表项包括所述LLDP数据包中携带的所述本地 OFC的MAC、IP以及收到所述LLDP数据包的端口in_port；以及，在接收用 于建立TCP连接的第一次TCP握手包后，调用存储器602中存储的程序指令， 执行如下操作：根据所述TCP握手包中携带的目的MAC以及目的IP查找所述 控制器列表中是否有对应的控制器列表表项，如果有，则根据所述控制器列 表中对应的控制器列表表项中的MAC、IP以及in_port更新流表项，使得所述 OFS能够通过流表将发往OFC的包转发到OFC。
其中，处理器601可以是中央处理器（central processing unit,CPU）、专 用集成电路（application-specific integrated circuit,ASIC）等。其中，本实施 例中的OFS可以包括总线604。处理器601、存储器602以及通信接口603之间 可通过总线604连接并通信。其中，存储器602可以包括：随机存取存储器 （random access memory,RAM），只读存储器（read-only memory,ROM）， 磁盘等具有存储功能的实体；
处理器601还可以用于执行方法实施例二中描述的各步骤，本发明实施 例在此不再详述。
本发明所述OFS带内通信方法及OFS中，所述方法包括：接收LLDP数据 包，所述LLDP数据包包含发送方的MAC、IP以及用于标识发送方类型的角 色子字段；当通过所述角色子字段判断接收到的所述LLDP数据包的发送方 类型为OFC时，新建或更新所述控制器列表表项，新建或更新的控制器列表 表项包括所述LLDP数据包中携带的所述本地OFC的MAC、IP以及收到所述 LLDP数据包的端口in_port；获取用于建立TCP连接的第一次TCP握手包，根 据所述TCP握手包中携带的目的MAC以及目的IP查找所述控制器列表中是 否有对应的控制器列表表项，如果有，则根据所述控制器列表中对应的控制 器列表表项中的MAC、IP以及in_port更新流表项，使得所述OFS能够通过流 表将发往OFC的包转发到OFC。通过采用本发明的OFS带内通信方法及OFS， 控制面信令和转发面数据承载于同一个OpenFlow网络中，仅需维护一个网 管系统，即可实现网络通信，降低了组网成本。
本领域普通技术人员将会理解，本发明的各个方面、或各个方面的可能 实现方式可以被具体实施为系统、方法或者计算机程序产品。因此，本发明 的各方面、或各个方面的可能实现方式可以采用完全硬件实施例、完全软件 实施例(包括固件、驻留软件等等)，或者组合软件和硬件方面的实施例的 形式，在这里都统称为“电路”、“模块”或者“系统”。此外，本发明的各方面、 或各个方面的可能实现方式可以采用计算机程序产品的形式，计算机程序产 品是指存储在计算机可读介质中的计算机可读程序代码。
计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。 计算机可读存储介质包含但不限于电子、磁性、光学、电磁、红外或半导体 系统、设备或者装置，或者前述的任意适当组合，如随机存取存储器 (RAM)、只读存储器(ROM)、可擦除可编程只读存储器（EPROM或者快闪 存储器）、光纤、便携式只读存储器(CD-ROM)。
计算机中的处理器读取存储在计算机可读介质中的计算机可读程序代 码，使得处理器能够执行在流程图中每个步骤、或各步骤的组合中规定的功 能动作；生成实施在框图的每一块、或各块的组合中规定的功能动作的装置。
计算机可读程序代码可以完全在用户的计算机上执行、部分在用户的计 算机上执行、作为单独的软件包、部分在用户的计算机上并且部分在远程计 算机上，或者完全在远程计算机或者服务器上执行。也应该注意，在某些替 代实施方案中，在流程图中各步骤、或框图中各块所注明的功能可能不按图 中注明的顺序发生。例如，依赖于所涉及的功能，接连示出的两个步骤、或 两个块实际上可能被大致同时执行，或者这些块有时候可能被以相反顺序执 行。
显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本 发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要 求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。
机译： OFS带内通信方法和OFS
机译： OFS带内通信方法和OFS
机译： OFS带内通信方法和OFS
