一种网络流转发异常检测方法
阅读：1发布：2020-11-25
专利汇可以提供一种网络流转发异常检测方法专利检索，专利查询，专利分析的服务。并且本 发明 公开了一种检测网络流转发异常的方法，所述网络流是在动态配置的 软件 定义网络中的网络流，包括两部分：一部分为基于Packet‑In的异常转发检测机制，控制层收到一个Packet‑In后，通过流表项查找引擎查找产生该Packet‑In的交换机及其前一跳交换机，及所述交换机处理该Packet‑In对应的流的流表项；将查找结果传递给验证逻辑判断该Packet‑In是否由被异常转发的网络流导致；一部分为流表项编辑机制，在基于目的地址转发的网络中，流表项编辑机制在控制层下发的流表项中强制加入对应交换机的端口号的入端口匹配域。本发明具有开销小、实现简单以及不依赖于厂商专有软 硬件 设备的优点。，下面是一种网络流转发异常检测方法专利的具体信息内容。
1.一种检测网络流转发异常的方法，所述网络流是在动态配置的软件定义网络中的网络流，其特征在于，
在每一条流表项的匹配字段中加入数据包的入端口域来使其匹配网络流的入端口，使得被错误转发的网络流一定会产生Packet-In；
基于Packet-In，采用流表项查找引擎和验证逻辑来判断网络流是否被异常转发；控制器将收到的Packet-In发送给所述流表项查找引擎，所述流表项查找引擎查找产生所述Packet-In的交换机PIS和产生Packet-In的交换机的前一跳交换机BPIS；所述验证逻辑验证BPIS是否确实将网络流转发到PIS，以及PIS是否确实不存在能够处理所述网络流的流表项，进而判断网络流是否发生转发错误。
2.根据权利要求1所述网络流转发异常检测方法，其特征在于，所述流表项查找引擎根据交换机上的流表项，为每一个交换机构建两棵前缀Trie树，所述前缀Trie树包括正向查找树和反向查找树，所述正向查找树能够快速查找匹配一个数据包或者Packet-In的流表项；而反向查找树能够快速查找哪些流表项会输出给定数据包到给定端口；快速获取所述PIS、BPIS以及它们上转发所述Packet-In对应的数据包的流表项，所述流表项查找引擎会随着所述流表项的下发或者修改而更新。
3.根据权利要求1所述网络流转发异常检测方法，其特征在于，所述验证逻辑包括：
如果所述BPIS不存在，即所述PIS的前一跳设备是主机，PIS上能够转发对应数据包的流表项CFR也不存在，则说明所述Packet-In是一条新流导致，是正常产生的；
如果BPIS存在，但BCFR不存在，则说明所述Packet-In是被错误转发的网络流触发的；
如果BPIS存在，BCFR存在，但是这条流表项不将数据包转发到PIS，则说明所述Packet-In是被错误转发的网络流触发的；
如果BPIS存在，且BCFR存在，且将数据包转发到PIS，CFR也不存在；则说明所述Packet-In是正常的网络流产生的。
4.根据权利要求1所述网络流转发异常检测方法，其特征在于，通过编辑控制层下发到数据层的流表项来确保被异常转发的网络流一定会产生Packet-In。
5.根据权利要求4所述网络流转发异常检测方法，其特征在于：在基于目的地址转发的网络中，控制器在它下发的流表项的匹配域中强制加入入端口域，入端口域字段所匹配的值等于所述流表项需要转发的网络流进入目的地址交换机的端口号，当所述入端口域字段与所述交换机端口号不一致时，在所述交换机上，被错误转发的网络流触发Packet-In。
6.根据权利要求4所述网络流转发异常检测方法，其特征在于：在基于目的地址转发的网络中，控制器在它下发的流表项的匹配域中强制加入入端口域，入端口域所匹配的值等于所述流表项需要转发的网络流进入目的地址交换机的端口号，当所述入端口域字段与所述交换机端口号不一致时，在所述交换机上，被错误转发的网络流触发Packet-In。
一种网络流转发异常检测方法
技术领域
[0001] 本发明涉及网络控制领域，特别是涉及一种网络流转发异常检测方法。
背景技术
[0002] 自软件定义网络(Software-Defined Networking,SDN)的概念提出以来，越来越多的实际应用(Google数据中心、Stanford校园网)证明了它在网络配置和管理上的巨大优势。越来越多的数据中心、大学校园以及大型企业都开始在自己的内部网络中部署SDN以提高网络效率、降低运营成本。从网络架构的角度来说，网络可以分为两个层：数据层和控制层。数据层描述交换机如何转发数据包，即如何将一个数据包从一个端口输出到另一个端口，它属于交换机的实现逻辑；而控制层描述的是网络应当如何将网络流交付到目的，即规划网络流的转发路径。在传统的IP网络中，数据层和控制器层都由分布式的交换机实现。这种方式提高了网络的容错能力，但却使得网络配置和网络管理非常复杂。SDN的核心思想在于分离网络的数据层与控制层。这样，SDN将数据层继续留在分布式的交换机上，而将控制层集中到远程的控制器上。
[0003] SDN通过流表项来控制网络流的转发。流表项由控制层生成，并配置到相应的交换机上。每一个交换机有一个或多个流表，每一个流表可以包含多条流表项。流表项的格式如图1所示。Match Fields指明如何匹配数据包，它支持匹配数据包的包头，比如MAC源地址(mac_src)、MAC目的地址(mac_dst)、以太网帧类型(eth_type)、IP源地址(ip_src)、IP目的地址(ip_dst)等。同时，它支持按照网络流的入端口(in_port)进行匹配；Priority表示流表项被匹配的优先级，当多条流表项被匹配成功时，优先级最高的流表项被最终匹配；Counters表示被这条流表项匹配的数据包的总数、总字节数；Instructions指明需要对被匹配数据包执行的一些操作，比如修改数据包；Timeouts指明这条流表项的过期时间，一旦流表项过期，交换机会自动删除它；控制层可以利用Cookie存储额外的数据；Flags指明交换机如何管理流表项，比如FPFF_SEND_FLOW_REM表示交换机在删除流表项是必须通知控制器。此外，每一条流表项可以关联一组动作(Actions)，这些动作包括修改数据包包头(包括IP源地址、IP目的地址、区分服务等)、设定数据包输出端口(out_port)等。
[0004] 当一个数据包到达交换机时，交换机尝试将它与第一张流表中的流表项进行匹配。如果匹配成功，则执行被匹配流表项的Instruction并更新流表项的Counters，如果数据包需要继续匹配剩下的流表，被匹配的流表项需要指定接下来到哪一张流表里去继续匹配。如果第一张流表里没有任何流表项与数据包匹配，交换机为这个数据包执行默认的未找到匹配流表项操作(Table Miss)。这个操作可以是将数据包以Packet-In的方式转发到控制器或者直接丢弃。本申请提供要求默认的Table Miss操作是Packet-In。
[0005] SDN支持两种配置方式：静态配置(Proactive Configuration)和动态配置(Reactive Configuration)。在静态配置的环境下，控制器预先为网络中的交换机配置流表项，这些流表项使得交换机能转发可能到达这个交换机的所有网络流。而在动态配置中，控制器仅将交换机未找到匹配流表项的操作(Table Miss)配置为Packet-In。当交换机找不到匹配的流表项时，它会将数据包封装到一个Packet-In消息中，然后发送到控制器。控制器根据这个Packet-In和网络拓扑来计算这个流的转发路径、生成流表项，最后将这些流表项下发到转发路径上的交换机。在这些流表项下发之后，这个流就能够在它的转发路径上的交换机上找到匹配的流表项，进而被正常转发。静态配置适合于拓扑结构设计优良、设备固定的网络中，比如数据中心网络；而动态配置适合于设备随时可能移动的网络中，比如校园网络、企业网络等。
[0006] SDN分离了网络的数据层和控制层。数据层由交换机构成，它们根据交换机上的流表项来转发数据包。控制层实现网络转发逻辑，它将转发逻辑转化为流表项，并将流表项配置到相应的交换机上。在多数情况下，交换机上的流表项都是被控制层正确配置的，但当网络设备发生故障或者网络出现配置错误时，交换机上的流表项可能会在控制层不知情的情况下发生改变，比如某些流的输出端口可能被错误更改。在这种情况下，某些网络流就会在交换机上发生转发异常：控制层根据自己下发的流表项认为这个流应从一个端口输出，而交换机根据自己的流表项认为这个流应从另一个不同的端口输出。转发异常导致网络流不按照控制器规定的路径转发，而是偏离到了另一个错误的转发路径。这些网络流可能最后成功到达目的地或者在某个交换机上被丢弃。
[0007] 转发异常导致网络流沿着错误的转发路径转发，这导致这条错误路径上的交换机可以监听被错误转发的网络流。它们可以从这条网络流中提取用户隐私，比如网络账号、密码等。同时转发异常也给网络增加了不确定性，使得网络难以管理，网络服务提供商(Internet Service Provider,ISP)不得不花费更多的成本来完成网络调度、硬件升级。
[0008] 目前，检测转发异常的研究工作可以分为两个种类：基于探测包和基于流量统计。基于探测包的方案利用探测包来探测网络中所有的流表项。如果存在转发异常，那么某些探测包就会被错误的转发，在目的设备也就不会收到这些探测包。如果一个探测包没有被收到，则说明负责转发它的流表项存在异常。基于探测包的检测方案包括ATPG、SDN Traceroute等。而基于流量统计的检测方案利用流的转发路径上转发这个流的流表项的流量统计信息，即Counters域的值来判断流是否出现转发异常。如果网络流没有出现转发异常，那么转发路径上的所有流表项转发了同一组数据包，它们的Counters域的值应该相等。
如果这些Counters域的值存在很大的差别，则说明这个网络流出现了转发异常。基于流量统计的检测方案包括SPHINX等。接下来，我们以ATPG和SPHINX来说明这两种检测方案。
如果这些Counters域的值存在很大的差别，则说明这个网络流出现了转发异常。基于流量统计的检测方案包括SPHINX等。接下来，我们以ATPG和SPHINX来说明这两种检测方案。
[0009] ATPG是Automatic Test Packet Generation(自动测试数据包生成)的简写。它结合网络拓扑结构分析网络中所有的流表项，进而确定每一条网络流会被哪些流表项转发。然后它寻找一组最少的流，这组流使得网络中任意流表项至少会转发这组流中的某一个。
其实这是一个子集覆盖问题：用与流相关的流表项(子集)来覆盖所有的流表项。然后ATPG从每一个选择的流中随机抽取一个数据包作为探测包。ATPG发送这些探测包，并在这些数据包的目的主机上接收这些探测包。如果探测包被正常收到，说明转发这个测试数据包对应的流的流表项正常工作。否则说明转发这个流的流表项存在异常。
其实这是一个子集覆盖问题：用与流相关的流表项(子集)来覆盖所有的流表项。然后ATPG从每一个选择的流中随机抽取一个数据包作为探测包。ATPG发送这些探测包，并在这些数据包的目的主机上接收这些探测包。如果探测包被正常收到，说明转发这个测试数据包对应的流的流表项正常工作。否则说明转发这个流的流表项存在异常。
[0010] SPHINX使用流量统计数据来检测转发异常，它假定流都按照源、目的MAC对进行转发。即网络中每一条流表项都会匹配源MAC地址、目的MAC地址。这样的好处就是不存在流聚合的问题。所以为一条流下发的流表项仅转发这条流，并有着相同的流量统计数据。SPHINX为每一个条构建转发路径，并定期提取转发路径上转发这个流的流表项的流量统计信息，然后比较这些流量统计信息。如果这些流量统计信息大致相同，则说明流表项工作正常；否则认为流表项存在转发异常。
[0011] 基于探测包的检测方案使用探测包来检测流表项。ATPG由于需要结合拓扑分析流表项之间的关系，它的时间复杂度非常高。同时考虑到注入和接收探测包的开销，它的性能不会很高。同时，探测包仅仅是一条网络流的数据包的一个特例，探测包的正常转发无法保证网络流的正常转发。所以存在漏报。
[0012] 基于流量统计的方法需要频繁读取流量统计数据，开销大。同时由于控制器到各个交换机的时延不同、各个交换机的时钟也有差异，网络流的流量统计数据只能是估计值，容易带来误差。而且这个误差可能随着时间而累加。出于同样的原因，基于流量统计的机制无法检测小流。因为对于一个小流，无论是否有转发异常，交换机上的流量统计数据都大致相等，因此，提出一种快速检测网络转发异常的方法是亟待解决的问题。
发明内容
[0013] 本发明目的就是为了解决检测网络转发异常的问题。
[0014] 在动态配置的SDN网络中，Packet-In的产生和前一跳交换机上处理这条流的流表项的输出端口、当前交换机上的流表项有关。本申请通过验证产生Packet-In的上一跳交换机(BPIS,Before the Packet-In Switch)和产生Packet-In的交换机(PIS,Packet-In Switch)的流表项来检测网络转发异常。
[0015] 每一个网络流有其规定的转发路径，网络流仅应该出现在它规定的转发路径上。所以当一个网络流在某个交换机上触发Packet-In时，这两个条件一定能够满足：1)BPIS上转发这个流的流表项将这条网络流输出到PIS上；2)PIS上没有能够转发这条网络流的流表项。如果以上两点中的任意一点不成立，那么说明这个Packet-In是由被错误转发的网络流产生的。也就是说，这个Packet-In对应的网络流出现了转发异常。
[0016] 尽管上述部分能通过Packet-In检测到被错误转发的网络流。但是，并不是所有被错误转发的网络流都会产生Packet-In。为了保证这点，我们可以编辑控制层下发到数据层的流表项，使得为不同网络流生成的流表项有一定程度的差异，进而保证被错误转发的网络流尽可能的触发Packet-In。本申请结合两个实施例来说明如何在基于源、目的地址转发网络和基于目的地址转发的网络中编辑流表项。
[0017] 综上，本申请的要点包括：1)一种基于Packet-In的产生位置来判断网络是否发生了转发异常。2)一种流表项编辑机制，在每一条流表项的匹配字段中加入数据包的入端口域来使其匹配网络流的入端口，进而使得被错误转发的网络流一定会产生Packet-In。
[0018] 本发明的技术问题通过以下的技术方案予以解决：
[0019] 一种检测网络流转发异常的方法，所述网络流是在动态配置的软件定义网络中的网络流，包括以下两个方面：
[0020] A1:基于Packet-In来判断网络流是否被异常转发，用于根据Packet-In发现异常；
[0021] A2:一种流表项编辑机制，确保被异常转发的网络流一定会产生Packet-In。
[0022] 根据本发明的另一个具体方面A1中采用流表项查找引擎和验证逻辑来判断网络流是否被异常转发；控制器将收到的Packet-In发送给所述流表项查找引擎，所述流表项查找引擎查找这个产生这个Packet-In的交换机PIS和产生Packet-In的交换机的前一跳交换机BPIS。所述验证逻辑验证BPIS是否确实将网络流转发到PIS，以及PIS是否确实不存在能够处理这个流的流表项，进而判断网络流是否发生转发错误。
[0023] 根据本发明的另一个具体方面所述表项查找引擎根据交换机上的流表项，为每一个交换机构建两棵前缀Trie树(正向查找树和反向查找树，所述正向查找树和反向查找树用于根据一个数据包或者Packet-In快速获取所述PIS、BPIS以及它们上转发所述Packet-In对应的数据包的流表项，所述流表项查找引擎会随着所述流表项的下发或者修改而更新。
[0024] 根据本发明的另一个具体方面，所述验证逻辑包括：
[0025] 如果所述BPIS不存在，即所述PIS的前一跳设备是主机，PIS上能够转发对应数据包的流表项CFR也不存在，则说明这个Packet-In是一条新流导致，是正常产生的；
[0026] 如果BPIS不存在，但PIS上存在CFR，则说明CFR可能没有工作；假设控制器在一段时间内(τ)收到N个Packet-In；如果N的值很大，则说明CFR确实没有正常工作；否则只能发出警告，让管理员手动验证这类问题。
[0027] 如果BPIS存在，但BCFR不存在，则说明这个Packet-In是被错误转发的网络流触发的；
[0028] 如果BPIS存在，BCFR存在，但是这条流表项不将数据包转发到PIS，则说明这个Packet-In是被错误转发的网络流触发的；
[0029] 如果BPIS存在，且BCFR存在，且将数据包转发到PIS，CFR也不存在；则说明这个Packet-In是正常的网络流产生的；
[0030] 如果BPIS存在，BCFR存在，且将数据包转发到PIS，但PIS上存在CFR，则CFR可能没有工作；假设控制器在一段时间内(τ)收到N个Packet-In；如果N的值很大，则说明CFR确实没有正常工作；否则只能发出警告，让管理员手动验证这类问题。
[0031] 根据本发明的另一个具体方面，A2中，通过编辑控制层下发到数据层的流表项来确保被异常转发的网络流一定会产生Packet-In。
[0032] 根据本发明的另一个具体方面，在基于目的地址转发的网络中，控制器在它下发的流表项的匹配域中强制加入入端口域，入端口域字段所匹配的值等于所述流表项需要转发的网络流进入目的地址交换机的端口号，当所述入端口域字段与所述交换机端口号不一致时，在所述交换机上，被错误转发的网络流触发Packet-In。
[0033] 根据本发明的另一个具体方面，在基于源地址、目的地址转发的网络中，控制器不需要做任何其他额外操作。
[0034] 本发明与现有技术对比的有益效果是：
[0035] 本发明的检测方法，监测SDN网络中的Packet-In，对它们进行一系列合法性分析，并根据分析结果判断产生Packet-In的交换机是否位于网络流的转发路径上，整个操作所需要的计算资源、内存资源都非常低，具有开销小、不依赖于厂商专有软硬件设备的优点，实现简单。附图说明
[0036] 图1是流表项的格式图；
[0037] 图2本发明检测方法结构示意图；
[0038] 图3是本发明检测方法逻辑流程图；
[0040] 图5是本发明技术方案的有效性阐述。
具体实施方式
[0041] 在检测转发异常的方案中，控制层可以主动探测转发异常，也可以被动监测转发异常。主动探测方案必然要求控制层花费额外的代价来进行探测操作，而被动监测方案仅需要注意到发生转发异常之后的异常事件。本申请提出的是一个被动监测方案，它监测SDN网络中的Packet-In，对它们进行一系列合法性分析，并根据分析结果判断这个Packet-In对应的网络流是否被错误转发。
[0042] 直观上来看，转发异常存在副作用：一旦网络流离开控制层规定的转发路径，它可能在交换机上找不到匹配的流表项，如果交换机默认Table Miss操作是Packet-In，那么被错误转发的网络流就会触发Packet-In。所以分析Packet-In的产生位置能检测到网络中的转发异常。根据OpenFlow协议的规定：正常情况下，如果一条网络流在某一个交换机上触发Packet-In，那么必须保证两点：
[0043] 1)产生Packet-In的交换机的前一跳交换机(BPIS)确实将网络流转发到这个交换机(PIS)；
[0044] 2)这个交换机(PIS)上没有能够处理这条网络流的流表项(CFR)。
[0045] 如果某个Packet-In使这两点中的任意一点不成立，那么说明这条网络流被错误转发了。本申请基于这个事实，监视SDN网络中的Packet-In消息，然后分析产生Packet-In的交换机的前一跳交换机(BPIS)是否确实将这条网络流转发到产生Packet-In的交换机(PIS)，以及产生Packet-In的交换机(PIS)是否确实不存在能够处理这个流的流表项，进而判断网络流是否发生转发错误。
[0046] 本申请提出的检测机制可以分为两个部分：流表项查找引擎和验证逻辑。流表项查找引擎根据交换机上的流表项，为每一个交换机构建两棵Trie树：正向查找树、反向查找树。正向查找树能够快速查找匹配一个数据包或者Packet-In的流表项；而反向查找树能够快速查找哪些流表项会输出给定数据包到给定端口。利用这两个能力，能够快速获取BPIS、PIS以及这两个交换机上转发一个Packet-In对应的数据包的流表项。由于网络中的流表项会动态地更新，所以流表项查找引擎也会随着流表项更新消息(FlowMod消息)而更新。验证逻辑根据BPIS和PIS上转发Packet-In对应的数据包的流表项来判断这个Packet-In是否是被错误转发的网络流产生的。本检测方法中各个模块的结构示意图如图2所示。其中，实线代表同步逻辑，虚线代表异步逻辑。接下来，将详细介绍整个过程的每一步。
[0047] 由于网络中的流表项随时在更新，流表项查找引擎也必须随着流表项的更新而更新。这个更新逻辑是异步的，独立于本申请的验证逻辑。为了能够快速查找交换机上能够匹配数据包的流表项，正向查找树根据数据包的所有匹配域建立Trie树。而考虑到流表项可能会更改数据包，反向查找树的索引是流表项的输入数据包的匹配域和输出数据包对应的域。当控制器向某个交换机增加一条流表项时，这个交换机的正向查找树和反向查找树都必须同时插入一条数据。正向查找树的键值为这条流表项匹配的包头空间，而反向查找树的键值为这条流表项匹配的包头空间和输出的数据包包头空间。这里，所谓的包头空间指的是一组数据包的所有包头集合，这个集合可以采用通配符的形式进行合并，进而在正向查找树或反向查找树中仅体现为一个节点。当控制器删除一条流表项时，对应交换机的正向查找树和反向查找树都必须删除对应的流表项。流表项的更新可以使用先删除对应流表项，然后再增加这条流表项来实现。
[0048] 当控制层收到一个Packet-In后，它将收到的Packet-In交给本申请的检测机制进行分析。本申请首先用这个Packet-In去查询流表项查找引擎，流表项查找引擎根据这个Packet-In返回BPIS、PIS以及这两个交换机上转发对应的数据包的流表项。
[0049] 验证逻辑根据BPIS是否存在，BPIS上是否存在能够转发对应数据包的流表项(BCFR)，以及PIS上是否存在能够转发对应数据包的流表项(CFR)流表项来判断是否出现转发异常。根据BPIS、BCFR、CFR的存在与否来检测转发异常的检测流程如图3所示，具体分为六种情况：
[0050] 如果BPIS不存在，即PIS的前一跳设备是主机，CFR也不存在，则说明这个Packet-In是一条新流导致，是正常产生的。
[0051] 如果BPIS不存在，但PIS上存在CFR，则说明CFR可能没有工作。假设控制器在一段时间内(τ)收到N个Packet-In。如果N的值很大，则说明CFR确实没有正常工作。否则只能发出警告，让管理员手动验证这类问题。
[0052] 如果BPIS存在，但BCFR不存在，则说明这个Packet-In是被错误转发的网络流触发的。
[0053] 如果BPIS存在，BCFR存在，但是这条流表项的不将数据包转发到PIS，则说明这个Packet-In是被错误转发的网络流触发的。
[0054] 如果BPIS存在，且BCFR存在，且将数据包转发到PIS，CFR也不存在。这说明这个Packet-In是正常的网络流产生的。
[0055] 如果BPIS存在，BCFR存在，且将数据包转发到PIS，但PIS上存在CFR，则CFR可能没有工作。其处理方式与B相同。当然，这里的τ和N是无法直接给出固定值的，不同的网络有着不同的最优值。
[0056] 本申请提出的触发机制是：通过控制流表项的匹配域来确保被异常转发的网络流一定会产生Packet-In。
[0057] 上述检测机制保证了本发明能够根据Packet-In精准检测到网络转发异常，但是并不是所有的网络转发异常都会产生Packet-In。本发明通过编辑流表项来保证几乎所有的被错误转发的网络流都会产生Packet-In。具体来说，在基于目的地址转发的网络中，控制器在它下发的流表项的匹配域中强制加入入端口域，入端口域所匹配的值等于所述流表项需要转发的网络流进入目的地址交换机的端口号，当所述入端口域字段与所述交换机端口号不一致时，在所述交换机上，被错误转发的网络流触发Packet-In。而在基于源地址、目的地址转发的网络中，控制器不做任何操作。
[0058] 具体实施例一
[0059] 为了保证网络流在被错误转发时能够产生Packet-In，必须保证为不同的网络流生成的流表项要存在一定的差异。这样，当网络流离开由控制器规定的转发路径时，它会在交换机上找不到匹配的流表项，进而产生Packet-In。
[0060] 本实施例1说明如何在基于源、目的地址转发的网络中使用本技术方案。
[0061] 基于源、目的地址转发的网络有一个特点：任何被错误转发而离开规定的转发路径的网络流都会触发Packet-In。这使得我们提出的检测机制能够直接应用于这种网络。为了简要说明，本实施例以基于源MAC地址、目的MAC地址进行转发的二层网络为例。在基于源MAC地址、目的MAC地址进行转发的网络中，所有流表项都会同时匹配源MAC地址、目的MAC地址。
[0062] 网络必须基于源MAC地址和目的MAC地址转发的原因在于：在这样的网络中，被错误转发的网络流在偏离原转发路径一定会找不到与它相匹配的流表项，进而一定会触发Packet-In。被错误转发的网络流在偏离原转发路径后一定找不到与它相匹配的流表项的原因在于：
[0063] 控制器为这条网络流下发的所有流表项能够转发这条网络流，但是这些流表项仅位于这条控制器为这条网络流规定的转发路径上；
[0064] 控制器为其他网络流下发的任何流表项都无法转发这条网络流，因为其他网络流要么源MAC地址与这条网络流的源MAC地址不同，要么目的MAC地址与这条网络流的目的MAC地址不同。(假设源MAC地址和目的MAC地址都相同，那么根据网络基于源MAC地址、目的MAC地址转发的假设，这两条网络流应该是同一条流)。
[0065] 所以在基于源MAC地址、目的MAC地址转发的网络中，被错误转发的网络流在偏离控制器规定的转发路径后一定会触发Packet-In。一旦本技术方案提出的检测方案检测到这个Packet-In，它会根据上述基于Packet-In的转发异常检测机制来完成检测。即根据BPIS是否存在、BCFR是否存在、PIS是否存在、CFR是否存在来判断这个Packet-In是否由于网络流被错误转发是产生。
[0066] 本实施例开销小，不用更改流表项；但它的适用范围窄，同时存在漏报的问题。
[0067] 具体实施例二
[0068] 本实施例解决在基于目的地址转发的网络中，如何修改流表项才能保证被错误转发的网络流一定会产生Packet-In。
[0069] 比如在一个类似传统IP网络的基于目的地址转发的SDN网络中，如图4所示的网络和表1所示的流表项。网络中最初有两条网络流f1和f2。网络流f1从主机h1流到主机h3，依次经过交换机s1,s2和s4；网络流f2从主机h2流到主机h3，分别流经交换机s3和s4。在某个时间点，交换机s2发生配置错误，导致网络流f1被转发到2号端口。这个被错误转发的网络流接着流到交换机s3。但是在交换机s3上，它并不会触发任何Packet-In，因为原本为网络流f2准备的流表项恰好能够转发这个被错误转发的网络流。所以，实施例1尽管能够部分解决按照源MAC地址、目的MAC地址转发的二层网络中的转发异常问题，但是它并不具有通用性。
[0070]
[0071]
[0072] 表1.图5中的所有流表项
[0073] 为了解决实施例1产生漏报的问题，本实施例研究如何设计流表项才能使本技术方案提出的转发错误检测方案适用于基于目的地址转发的网络中。
[0074] 在为每一条网络流下发的每一条流表项中强制匹配这条网络流的入端口(ingress port)便能解决此问题，在本实施例中强制每一条控制器下发的流表项使用入端口来匹配网络流。这样，这些流表项仅会匹配来自正确的上一跳交换机的网络流。在这种要求下，本申请提出的转发异常检测机制就能够适用于基于目的地址转发的网络，同时具有很低的漏报率和很高的精确度。
[0075]
[0076] 表2.图4所示拓扑中使用的流表项
[0077] 比如在网络拓扑如图4流表项为表1所示的网络中，实施例1采用的方案并不能检测到转发异常。但是我们可以强制使每一个流表项匹配网络流的入端口，比如交换机s1上处理网络流f1的流表项应当匹配入端口in_port＝1。所以，在图4所示的网络拓扑及网络流f1、f2的场景下，利用本申请提出的技术方案，应当为这两条网络流生成的流表项如表2所示。对比表2和表1可以看出，在本技术方案中，所有流表项都必须使用入端口匹配字段，入端口字段所匹配的值等于这条流表项需要转发的网络流进入本交换机的端口号。在使用表2所示的流表项配置图4所示的交换机后，被错误转发的网络流f1在交换机s3上就无法找到匹配的流表项，因为交换机s3上处理目的IP地址为10.0.0.3的流表项仅处理从2号端口进入交换机的数据包，而被错误转发的网络流从4号端口进入这个交换机。所以在这个交换机上，被错误转发的网络流f1会触发Packet-In。
[0078] 接下来本申请以形式化方式说明技术方案的有效性。如图5所示，假设有一个网络流f1依次流经两个交换机s1和s2，在这两个交换机上它依次被流表项r11和流表项r21转发。match11和match21分别是流表项r11和流表项r21的匹配字段。假设网络流f1在交换机s1上遇到转发异常，它的输出端口改变，现在将这个网络流输出到交换机s3。假设这个流在被错误转发之后并没有触发Packet-In，那么在交换机s3上，必有流表项能够匹配这条网络流或者它的一部分。假设匹配这个网络流的流表项是r31，它的匹配字段为match31，同时根据本申请技术方案的限制，r31应当仅处理从1号端口进入网络的数据包。这说明交换机s1上本身有一条流转发到交换机s3，这条流在交换机s3上被流表项r31处理，假定这条流在交换机s1上被流表项r12转发。需要注意的是，流表项r12和r11不可能是同一条流表项，否则流表项r11同时将网络流输出到交换机s2和s3(SDN中利用组表实现的组播)，那么这种情况下网络流被转发到交换机s3并不算转发异常。假设流表项r11和流表项r12可能输出的数据包集合分别为out11和out12。由于流表项r11输出的数据包能被流表项r21和流表项r31处理，流表项r21输出的数据包能被流表项r31处理，同时考虑到SDN中流表项不存在聚合问题。那么以下公式成立(其中φ代表空集)：
[0079] out11＝match21
[0080] out11∩match31≠φ
[0081] out12＝match31
[0082] 根据这三个等式能够推断出out11∩out12≠φ。接下来，本申请根据流表项r11和r12是否修改数据包包头来讨论：
[0083] 1)不修改包头：这种情况下，流表项能够匹配的数据包也就是它能够输出的数据包，也就是说match11＝out11，match12＝out12。那么match11∩match12≠φ。也就说，流表项r11和流表项r12能够匹配同一组数据包。由于本申请假定了一个没有流表聚合的SDN场景，那么这种情况不可能存在。
[0084] 2)修改包头：也就是说，流表项r11和r12不能匹配同一组数据包。但是经过修改包头，这两条流表项的输出数据包集合存在交集。从网络流的角度来看，这两条流表项处理不同的网络流，但是它们通过修改网络流的数据包头，使得不同的网络流经过它们的处理后变成了同一条网络流，但是它们又将这同一条网络流转发到两个不同的交换机。这种应用场景在现实网络中非常罕见，甚至没有。
[0085] 所以根据以上推导，在本申请的不存在地址聚合的前提下，如果一条被错误转发的网络流没有触发Packet-In，那么一定能够推导出网络存在地址聚合或者一种不存在的网络应用场景。所以，使用本申请的技术方案能够使网络中被错误转发的网络流一定会触发Packet-In。
[0086] 以上内容是结合具体的/优选的实施方式对本发明所作的进一步详细说明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说，在不脱离本发明构思的前提下，其还可以对这些已描述的实施例做出若干替代或变型，而这些替代或变型方式都应当视为属于本发明的保护范围。
| 标题 | 发布/更新时间 | 阅读量 |
|---|---|---|
| 兴趣特征分布获取方法及装置 | 2021-07-24 | 0 |
| 一种用于主机的kvm虚拟机网卡直通方法及其装置 | 2022-06-03 | 0 |
| 碳纳米管的制备方法，碳纳米管纤维 | 2022-08-18 | 0 |
| 一种过滤杯、过滤装置及其在拉曼光谱面扫描检测方法中的应用 | 2022-09-26 | 2 |
| 用于数据中心网络延迟的检测方法及装置 | 2020-12-04 | 1 |
| 一种机器人应用的下发方法、获取方法及装置 | 2020-07-28 | 1 |
| 一种具有互联网功能的智能自动售药机 | 2023-01-14 | 2 |
| 一种智慧工地管理平台 | 2020-05-28 | 1 |
| 一种充电器 | 2023-07-22 | 0 |
| 一种KT板垂直分板取料专用物料架 | 2020-11-30 | 1 |
高效检索全球专利专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台，是提供专利分析，专利查询，专利检索等数据服务功能的知识产权数据服务商。
我们的产品包含105个国家的1.26亿组数据，免费查、免费专利分析。
分析报告
专利汇分析报告产品可以对行业情报数据进行梳理分析，涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度，系统通过AI智能系统对图表进行解读，只需1分钟，一键生成行业专利分析报告。
QQ群二维码
意见反馈
意见反馈