CN1612562A - 用策略流实现不同因特网协议数据包转发的方法和设备 - Google Patents
用策略流实现不同因特网协议数据包转发的方法和设备 Download PDFInfo
- Publication number
- CN1612562A CN1612562A CNA2003101017904A CN200310101790A CN1612562A CN 1612562 A CN1612562 A CN 1612562A CN A2003101017904 A CNA2003101017904 A CN A2003101017904A CN 200310101790 A CN200310101790 A CN 200310101790A CN 1612562 A CN1612562 A CN 1612562A
- Authority
- CN
- China
- Prior art keywords
- address
- ipv6
- ipv4
- stream
- tunnel
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Abstract
本发明提出了一种采用策略流方式实现在同一物理管道中同时支持IPv4和IPv6转发的方法和装置。其中,根据不同的目的IP的数据流类型,提取相应的数据包的多元属性组,计算出策略流标识ID,据此精确查找策略流转发表目。如果发现有相匹配的策略流转发表目,则按照该表目对数据包进行相关内容修改和转发操作。如果没有,则由控制平面根据该数据包的属性对数据包进行相应的处理,并综合控制平面中和各种应用相关的表目信息生成相应的唯一的一条本地策略流转发表目。将该策略流转发表目分发到所述转发平面供后面的数据包使用。从而,避免了复杂的IPv4和IPv6的逐包查找,提高了转发效率,并且避免了引入额外的信令,不会影响互联网的互联互通性。
Description
技术领域
本发明涉及一种数字通信设备,特别涉及一种数据包转发的方法和设备,其采用策略流方式在同一物理管道中同时支持IPv4和IPv6转发。
背景技术
随着互联网技术的不断发展,现有的IPv4网络的许多缺陷逐渐暴露出来,其中最突出的是IP地址空间将被耗尽和主干路由表不断增长的问题。按照目前互联网的发展速度,IPv4地址将在2005至2010年间分配完毕。为了彻底解决目前IPv4遇到的问题并对未来的应用提供更好的支持,Intemet工程组(IETF)的IPng工作组(IPng Working Group)提出了修改IP协议的建议。新的建议是IP的第6个版本,因此也称为IPv6。IPv6具有长达128位的地址空间,可以彻底解决IPv4地址资源不足的问题。除此之外,IPv6还采用分级地址模式、高效IP包头、服务质量、主机地址自动配置、认证和加密等多项技术。
此外,第三代移动通信3GPP和3GPP2已经把IPv6规定为未来的移动网络核心技术。由于移动通信用户的增长要比固定网用户快得多,特别是各种具有联网功能的移动终端的迅猛发展,使得在推进IPv6的过程中,移动网起着先导作用,固定网会随后跟进。
有关专家预测,到2010年,和IPv6相关的产业规模将至少达到200亿美元。由于IPv6技术具有巨大的市场前景,全球各个国家展开了对IPv6的研究,并取得一定的进展。在日本、欧洲和美国,各大公司分别推出了基于IPv6的路由器,并开始了试验网络的搭建。而在中国由于互联网用户增长迅速,中国政府也意识到了IPv6的重要性,在863计划和国家计委的项目中也对IPv6的研发和部署进行了大力支持。
如何完成从现有的IPv4到IPv6的转换是IPv6发展需要解决的第一个问题。现有的几乎每个网络及其连接设备都支持IPv4,因此要想一夜间就完成从IPv4到IPv6的转换是不切实际的。IPv6必须能够支持和处理IPv4体系的遗留问题。因此,在可预见的将来,能否实现IPv4向IPv6的平滑的过渡将是决定IPv6能否大规模商用的最紧要的问题。而解决这一问题的关键就在于如何在网络设备上实现在同一个物理管道中进行IPv4和IPv6转发的共存。
下面描述本发明涉及内容的原有解决方案及不足。
首先描述基于数据包的IP转发的问题和不足。
在现有的网络设备中,绝大多数采用了基于包的IP转发。传统的路由查找是基于目的IP地址的最长匹配查找,即在路由中找到一个和目的IP地址前缀最长的匹配条目。例如在路由表(表1)中有以下三条条目:
表1路由表
Prefix(12bit) | Output Index |
P1=0101000000 | Ethernet 1/1 |
P2=0101110100 | POS 2/0 |
P3=0101101011 | FDDI 3/1 |
如果有一个数据包,它的前12个bit为01010110111,则它将会匹配P1,从Ethemet 1/1中发出。而如果它的前12个bit为0101101011,则它会匹配前缀P3,从FDDI 3/1中发出。在最常用的最长前缀匹配方案中,主要是基于Radix Trie表的查找方案,这种算法实现起来较为简单,但效率较低,在最差的情况下,需要32或128次内存访问(分别对应于IPv4或IPv6)。而某些改进的算法中,查找的效率大为提高,但仍然需要O(log2W)次,其中W为IP地址的bit位数。也即如果在IPv4情况下需要5次,而在IPV6情况下需要8次。
这种基于最长匹配的的查找方式,无法采用同一张表来IPv4/IPv6共存的环境,必须采用多张路由表来分别支持IPv4和IPv6的查找。这样就导致了查找效率的低下和设备开发的困难。此外,最长匹配方式无法针对用户的每个流进行处理,导致运营商难以提供增值业务和保证用户流的QoS。
接下来描述MPLS转发的问题和不足。
MPLS技术是目前流行的IP交换技术,它目前也被用来解决IPv4、IPv6转发和服务质量问题。所谓MPLS,即多协议标记交换。标记交换,指的是底层的转发机制采用了简单的标记交换,而标记将作为交换的标识。当标记交换以ATM或FR(帧中继)作为其链路层协议时,标记也相应采用VPI/VCI或DLCI。当标记交换的链路层是FDDI、Ethernet或PPP时,因为它们原有的格式中完全不具有标记信息,必须加上额外的封装,标记交换采用的是Shim的格式。
MPLS采用拓扑驱动的二层转发技术。但是采用MPLS转发时,它同样需要在边缘节点完成转发等效类(FEC,Forwarding Equal Class)到标记(Label)的映射,而在核心节点则执行基于标记的快速转发。因此,这意味着在网络边缘的节点同样需要对每一个数据包进行最长匹配查找和复杂的策略处理(如VPN、NAT和PPPOE)。此外,为了支持节点间的信令交互,它引入了复杂的信令协议,如LDP(CR-LDP)或RSVP-TE,就导致了设备的软件复杂度增高,并且由于目前MPLS的两大标准分别为不同厂家所支持,这也导致了网络互操作性的困难。
虽然,MPLS方案和传统的IP转发相比在中间节点提高了转发的效率,但仍然存在以下不足:
1、MPLS在边缘节点对数据包的复杂处理,和基于包的IP转发相同,它仍然需要在LER上进行最长匹配查找,完成从FEC到Label的映射,因此同样导致的边缘设备的开发周期长和设备复杂。
2、MPLS的实现需要引入复杂的MPLS信令,大大增加设备的开发成本和维护费用。与MPLS相关的IETF RFC和草案多达80余个,设备开发商实现起来极为复杂,而运营商也难以进行维护。
3、由于MPLS的标准中支持两种信令协议,LDP(CR-LDP)和RSVP,而这两大标志分别为不同的厂商所支持。所以使用MPLS协议,会导致网络设备的互通性存在问题。
4、MPLS中对服务质量的保证采用区分服务时,无法针对每一个流保证服务质量。
5、MPLS无法支持网络地址/协议转换(NAT-PT),因此无法实现IPv4和IPv6网络之间的直接互联。
发明内容
本发明的目的在于提供一种采用策略流方式在同一物理管道中同时支持IPv4和IPv6转发的方法和装置,其能够避免复杂查找,提高转发效率。
根据本发明,提供了一种在网络设备中以策略流方式实现数据包转发的方法,所述网络设备至少包括转发平面和控制平面。该方法包括以下步骤:(a)接收数据流中的数据包,该数据流中包括至少一个数据包;(b)在转发平面判断目的IP地址的类型;(c)在转发平面根据不同的目的IP的数据流类型,提取相应的数据包的多元属性组,计算出标识该数据流的本地唯一的策略流标识ID;(d)转发平面根据本地策略流ID精确查找策略流转发表目,如果发现有相匹配的策略流转发表目则进行步骤(e),否则转到步骤(f);(e)如果发现有相匹配的策略流转发表目,则在转发平面按照所述策略流转发表目对该数据包进行相关内容修改和转发操作,并转到步骤(i);(f)如果未发现有相匹配的策略流转发表目,则说明这个数据包是数据流的第一个包或者是策略流转发表目已经老化,转发平面将该数据包送到控制平面进行处理;(g)控制平面在本地根据该数据包的目的IP地址的类型、入端口与应用相关的配置以及该目的IP地址所对应的下一跳的出端口与应用相关的配置中至少一个,与转发平面共同来对数据包进行相应的处理,并综合控制平面中和各种应用相关的表目信息生成相应的唯一的一条本地策略流转发表目;(h)控制平面将该策略流转发表目分发到所述转发平面,供后面的数据包使用;(i)处理下一个数据包。
在本发明中,当未发现有相匹配的策略流转发表目时,控制平面并不需要和其它网络设备进行交互信令。此外,当控制平面生成新的策略流转发表目时,也不需要将该表目通告给其它网络设备。
根据本发明,还提供了一种以策略流方式转发数据的数据转发设备,其中包括至少一转发平面和一控制平面,其中每个转发平面接收数据流中的数据包,该数据流中包括至少一个数据包,该数据转发设备包括:本地策略流转发表目存储部分,用于存储本地策略流转发表目,其中,所述转发平面包括:目的IP地址类型判断部分,用于判断目的IP地址的数据流类型;本地策略流ID计算单元,用于根据不同的目的IP的类型,选择相应的数据包的多元属性组,来计算出标识该数据流的本地策略流标识ID;查找单元,用于根据本地策略流ID精确查找所述本地策略流转发表目存储部分中存储的本地策略流转发表目,看是否有与该数据包的本地策略流ID相匹配的策略流转发表目;修改和转发单元,如果在查找单元发现匹配的策略流转发表目,则按照所述策略流转发表目对该数据包进行相关内容修改和转发操作;如在查找单元未发现匹配的策略流转发表目,则将该数据包送到控制平面,所述控制平面包括:策略处理单元,根据目的IP地址的类型、入端口的配置以及该目的IP地址所对应的下一跳的出端口的配置中至少一个,对数据包进行相应的处理;策略流转发表目生成单元,根据对数据包进行的处理生成相应的策略流转发表目,并将该策略流转发表目分发到所述策略流转发表目存储单元,供后面的数据包使用。
本发明不同于传统的逐包(Packet-based)转发的方式,而采用了基于数据流(Stream-based)处理的IP包转发的思想,并且通过设置不同的策略类型实现了在同一个物理管道中同时进行IPv4和IPv6数据的转发。本发明避免了复杂的IPv4和IPv6的逐包查找,大大提高了转发效率,并且避免了引入其他额外的信令,不会影响互联网的互联互通性。此外,本发明采用同一张表支持多种应用,针对每一个流进行处理,使得运营商针对用户的每一个流提供业务和服务质量成为可能。
附图说明
图1至图4是从IPv4向IPv6演进的过程中不同阶段网络示意图;
图5是支持IPv4和IPv6转发策略流表数据结构
图6显示出本发明的应用的逻辑视图;
图7显示出本发明的应用的线卡结构;
图8是数据包处理的基本流程;
图9显示了采用网络处理器的线卡;
图10是网络处理器的内部结构框图;
图11显示了包处理流程;
图12示意性展示了调度处理的原理;
图13显示了采用VOQ的N端口输入队列的交换模型;
图14是采用Crossbar交换技术的系统结构;
图15是队列管理器的内部结构;
图16显示了Crossbar Chip的结构方框图;
图17展示了MSR设备机箱前视图;
图18给出了本发明的应用设备的逻辑结构图
图19是带远程监控功能的电源整流系统的原理框图;
图20示意性显示了嵌入式以太网体系的结构图
图21是采用双交换结构的R8002设备交换系统原理图;
图22给出了本发明的应用设备的通用线卡结构图;
图23给出了POS通用线卡结构图;
图24给出了本发明的应用设备的软件分层结构;
图25是本发明的应用设备的系统适配层示意图;
图26是本发明的应用设备的系统适配层示意图;
图27是接口映射关系图;
图28是示出了本发明的以策略流方式转发数据的数据转发设备的方框图;
图29是本发明的数据转发设备的转发平面中的策略流ID计算单元的方框图;
图30是本发明的数据转发设备的转发平面中的修改和转发单元的方框图;
图31是图30中的分类转发单元的方框图;
图32是图28中的策略处理单元的方框图;
图33是本发明的数据转发方法的流程图;
图34是当目的IP为IPv4地址时,确定应对该数据包所在的数据流进行何种业务操作的方法的流程图;以及
图35是当目的IP为IPv4兼容的IPv6地址时,确定应对该数据包所在的数据流进行何种业务操作的方法的流程图。
具体实施方式
首先介绍IPv4和IPv6共存情况下的三种技术方案和四种典型网络拓扑,然后介绍一种能够满足以上三种技术方案和四种网络拓扑的IPv4和IPv6转发的算法,最后介绍如何用策略流方式实现该算法。
IEFT关于IPv4和IPv6如何共存提出了三种技术方案:IPv4/IPv6双栈方式、隧道方式和网络地址/协议转换方式。它们具体说明如下:
IPv4/IPv6双栈方式:双协议栈的解决方案实际上就是在一个路由器设备中维护IPv6和IPv4两套路由协议栈,使网络中的主机可以分别支持IPv6和IPv4协议,也可以同时支持这两种协议,路由器既能与IPv4主机也能与IPv6主机通信,分别支持独立的IPv6和IPv4路由协议,IPv4和IPv6路由信息按照各自的路由协议进行计算,维护不同的路由表。IPv6数据报(包括与IPv4地址兼容的IPv6数据报)按照IPv6路由协议得到的路由表转发,IPv4数据报按照IPv4路由协议得到的路由表转发。
网络地址/协议转换方式:该方案通常用于纯IPv4节点与IPv6节点之间的通信,对于纯IPv6节点与双栈节点中的IPv4协议通信不建议采用此方案。地址/协议转换采用了直接明了的转化方式,不用修改上层协议即能互相通信。该方案的中心设备,又称为NAT-PT网关,能够实现IPv4和IPv6协议栈的互相转换,包括网络层协议、传输层协议以及一些应用层协议之间的互相转换。
隧道方式:所谓隧道技术就是利用现有网络设施中运行的IPv4协议为载体建立IPv6的通信机制,隧道两头的节点间数据报的传送通过IPv4机制进行,隧道被看成一个直接连接的通道,隧道技术是IPv4向IPv6过渡的初期最易于采用的技术。隧道可以在路由器与路由器之间,路由器与主机之间以及主机与主机之间建立,隧道可以手工配置建立也可以自动建立。隧道策略的思路简要说来就是,路由器将IPv6的数据分组封装入IPv4,IPv4分组的源地址和目的地址分别对应隧道入口和出口的IPv4地址,在隧道的出口处,再将IPv6分组取出转发给目的站点。隧道技术只要求在隧道的入口和出口处进行修改,对其他部分没有要求,因而比较容易实现。
以上为三种解决IPv4和IPv6共存的技术方案,而下面这是采用这三种方式的四种典型网络拓扑。
如图1,为IPv4向IPv6演进的过程中,网络的骨干节点已经成为IPv6节点,而边缘网络仍为IPv4的网络。此时,图中IPv4网络互相访问时需要通过中间的IPv6网络,此时将采用IPv4 in IPv6的隧道方式,而通常隧道的终端节点地址为为手工配置的隧道地址。
如图2,为IPv4向IPv6演进的过程中,两个IPv6的孤岛需要通过IPv4的网络进行互相访问。此时需要采用IPv4 In IPv6的隧道方式,其中根据目的IPv6地址的类型不同,又可以分为自动配置隧道和手工配置隧道。即如果目的IPv6地址为IPv4兼容的IPv6地址,则为自动配置隧道,否则为手工配置隧道。
如图3,为IPv4向IPv6演进过程中的最后阶段,此时所有的网络均为IPv6网络,因此整个网络只需要采用纯IPv6转发即可。
如图4,为IPv4向IPv6过程中,IPv4和IPv6网络之间的直接互相访问。此时,必须采用网络地址/协议转换方式,来实现两者的互通。
接下来,首先介绍本发明提供的一种IPv4/IPv6节点均可以使用的在同一个物理管道中实现的IPv4和IPv6兼容的转发的算法IPFA(Ipv4 and IPv6compatible Forwarding Algorithm or IPFA)。该算法将用来决定网络设备何时采用IPv4转发,何时采用IPv6转发,何时采用自动隧道、何时采用手工配置隧道,以及何时采用地址转换方式(NAT-PT)。该算法主要是基于以下考虑:网络设备对数据包的处理方式将取决于数据包的目的IP地址类型、入端口的配置以及查找该目的IP地址所对应的下一跳(Next Hop)所在的出端口(OutputPort)。该算法可以有效地支持以上提到的三种方式和四种拓扑。
该算法描述如下:
1.如果目的IP地址为IPv4地址:
1)首先判断入端口是否使能了NAT-PT且目的IPv4地址是否为地址池内地址,如果没有则转向步骤2),否则转向步骤4);
2)进行IPv4相关的转发信息查找转发表,判断下一跳的接口类型,如果为IPv4,则完成IPv4转发,否则进行步骤3);
3)如果下一跳对应的接口为IPv6,进行IPv4 in IPv6的隧道操作,其中目的地址可以为该IPv4地址对应的IPv4兼容的IPv6地址也可以为手工配置的隧道地址;
4)进行NAT-PT操作,将IPv4包转换为IPv6的包;
2.如果目的地址为IPv4兼容的IPv6地址
1)首先判断入端口是否使能了NAT-PT而且目的地址是否为地址池内地址,如果没有则转向步骤2),否则转向步骤5)
2)进行IPv6相关的转发消息查找转发表,判断下一跳的出接口类型,如果为IPv6,则进行IPv6转发,否则进行步骤3)
3)如果下一跳的类型为IPv4,则首先判断出端口是否使能了NAT-PT,如果有NAT-PT操作的标识则进行步骤5),否则进行步骤4)
4)进行IPv6 in IPv4操作,其中目的地址为原有IPv6目的地址的低32位。
5)进行NAT-PT操作,其中转换后源地址为NAT地址池内的地址,转换后的目的IP地址为原有IPv6目的地址的低32位。
3.如果目的地址为IPv6地址
1)根据IPv6相关的转发消息表查找转发表,并判断下一跳所对应的接口类型。如果为IPv6,则进行IPv6转发。
2)否则为IPv4,则需要进行IPv6 in IPv4的隧道操作,其中IPv4的目的地址为配置的隧道的IPv4地址。
接下来,描述本发明用策略流实现IPFA的方法和设备。
策略流转发采用了完全基于流处理的思路而不是基于数据包处理的思想,主要作法是:对于同一个数据流中的不同数据包,网络设备对它的行为(Action)应该是完全相同的。此外,对于转发平面来说,它并不需要知道自己对数据包应该采用何种查找算法(单播、组播、IPv4或Ipv6),相反,它只需要知道它的出端口和下一跳信息,以及该采用何种策略对数据包进行修改。因此,策略流转发在转发平面中采用了统一的转发表目和单一高效的查找算法(Exact Match),这样就简化了转发平面的处理,提高了查找效率。
具体来说,所谓策略流交换,它并非针对某一个具体的IP数据包进行查找交换,而是采用了对特定的IP数据流进行转发处理的思想。策略流交换采用了根据特定的多元组来唯一确定一个流(Stream)。针对特定的Stream,网络设备只需要将该流的第一个包送控制平面进行处理,为该数据流分配唯一的流ID(Stream ID),而该流随后的包只需要转发平面进行简单的转发操作即可。因此,策略流转发只需要对该数据流的第一个数据包进行复杂的查表查找,并由用户定制对它的特定业务操作。控制平面在完成查找和定制完业务类型后,生成策略流转发表目(Policy Stream Forwarding Table),并由路由引擎将该表目分发(Distribute)到转发平面。表目包含有下一跳的出接口信息和标明业务种类的策略类型字段。而数据包转发时将根据这一业务操作的策略类型对该Stream做统一的处理。由于对于转发平面来说,它将不关心查找的策略,而只是关心该数据流是否能够被转发和应该被转发到那个出接口,这样就大大简化的转发平面的处理过程。
本发明所采用的策略流转发算法与MPLS的主要区别如下表2:
表2-策略流转发算法与MPLS的主要区别
策略流转发 | ||
对Ipv4/v6包的转发效率 | LER采用最长匹配、低;LSR采用精确查找、高 | 采用精确查找、高 |
与其它厂商设备的接口协议、互联互通性和接口 | 引入额外的复杂信令(即MPLS整套控制平面协议,包括CR-LDP和RSVP两大类),带来互联互通变得复杂,协议选项很多和信令 | 只需改变设备内部的数据流的逻辑流程,不需增加任何协议,而只需根据统一的路由表项, |
复杂性 | 协议的一致性操作等问题 | 升级内部软件 |
可以采用区分服务或RSVP方式,但区分服务无法保证每个流的带宽 | 在单个节点内,可以针对每个流保证带宽,粒度可以到64Kbps | |
支持应用 | 无法直接支持ACL(访问控制列表)或NAT(网络地址转换)等应用,当运营商提出要增加其它增值业务时,需要增加其它表项,表项的种类增多,复杂性增加 | 同一张表项支持所有应用(包括ACL和NAT等),便于提供增值功能 |
本发明采用的策略流表(PSFB)的基本数据结构:
Source IPv4 Address(4字节):数据流的源IPv4地址。
Destination IPv4 Address(4字节):数据流的目的IPv4地址
Source IPv6 Address(16字节):数据流的源IPv6地址
Destination IPv6 Address:(16字节):数据流的目的IPv6地址
Protocol Type(2字节):协议类型
Source Protocol Port(2字节):源协议端口,由协议类型来决定为何种协议的端口
Destination Protocol Port(2字节):目的协议端口,由协议类型来决定为何种协议的端口
Flow Label(2字节):IPv6中的包头字段,表示同一个源地址中的不同流流,该字段为可选用字段,为0是表示忽略其使用。
Stream ID(4字节):表示一个流的唯一的ID
Alias Port(2字节):伪端口,转换后的协议端口,用于网络地址转换
Alias IPv4 Address(4字节):伪IP地址,转换后的IPv4地址,用于网络地址转换
Alias IPv6 Address:(16字节):伪IPv6地址,转换后的IPv6地址,用于网络地址转换
Tunnel ID(2字节):隧道ID,用于IPv6 to IPv4或IPv4 to IPv6隧道
Policy Type(2字节):策略类型,表明对数据流流该进行的何种业务操作类型,可由网管灵活配置或用户进行业务定制。
QoS(2字节):服务质量,表明对该流的服务质量参数。
Expired Timer(1字节):超时定时器,判断该流转发表目是否超时。
TCP Flag(1字节):TCP标志位,用来判断TCP流是否结束。
Ouput Port Index(2字节):出端口索引,用来指定该数据包的发送出端口
Next Hop IPv4 Address(4字节):下一跳IPv4地址
Next Hop IPv6 Address(16字节):下一跳IPv6地址
Tunnel end IPv4 Address(4字节):隧道终点IPv4地址,和伪IPv4地址复用。
Tunnel end IPv6 Address(16字节):隧道终点IPv6地址,和伪IPv6地址复用。
注:以上数据结构仅是本发明的基本数据结构,用户可以根据实际的应用对该数据结构进行扩展。
下面参考附图说明本发明基于策略流实现IPv4和IPv6双栈数据包转发的方法和设备。
首先参考图28-32描述本发明的以策略流方式转发数据的数据转发设备。图28是示出了本发明的以策略流方式转发数据的数据转发设备的方框图。如图28所示,该数据转发设备包括至少一转发平面和一控制平面,其中每个转发平面接收数据流中的数据包,该数据流中包括至少一个数据包,该数据转发设备还包括:PSFB表目存储单元,用于存储PSFB表目。
转发平面包括:目的IP地址类型判断单元,用于判断目的IP地址的类型;策略流ID计算单元,用于根据不同的目的IP的类型,选择相应的数据包的多元属性组,来计算出标识该数据流的策略流ID;查找单元,用于根据策略流ID精确查找PSFB表目存储单元中存储的PSFB表目,看是否有与该数据包的策略流ID相匹配的PSFB表目;修改和转发单元,如果在查找单元发现匹配的PSFB表目,则按照PSFB表目对该数据包进行相关内容修改和转发操作;如在查找单元未发现匹配的PSFB表目,则将该数据包送到控制平面。
控制平面包括:策略处理单元,根据目的IP地址的类型、入端口的配置以及该目的IP地址所对应的下一跳的出端口的配置中至少一个,对数据包进行相应的处理;PSFB表目生成单元,根据对数据包进行的处理生成相应的PSFB表目,并将该PSFB表目分发到PSFB表目存储单元,供后面的数据包使用。
本发明的数据转发设备所处理的数据包的目的IP地址的类型可以是IPv4地址、IPv4兼容的IPv6地址或非IPv4兼容的IPv6地址。
图29是本发明的数据转发设备的转发平面中的策略流ID计算单元的方框图。如图29所示,策略流ID计算单元包括:第一计算部分,用于在目的IP地址为IPv4地址时,根据由源IPv4地址、目的IPv4地址、源协议端口、目的协议端口、协议类型组成的五元属性组计算策略流ID;IPv6流标记Flow_Label检测单元,用于在目的IP地址为IPv4兼容的IPv6地址或非IPv4兼容的IPv6地址时,判断数据包头中的IPv6流标记Flow_Label是否为0;第二计算部分,用于在判断出IPv6流标记Flow_Label为0时,根据由源IPv6地址、目的IPv6地址、源协议端口、目的协议端口、协议类型组成的五元属性组计算策略流ID;以及第三计算部分,用于在判断出IPv6流标记Flow_Label为0时,根据由源IPv6地址、IPv6流标记Flow_Label组成的二元属性组计算策略流ID。
在PSFB表目存储单元中存储的PSFB表目中记录有表明应该对数据流进行何种业务操作类型的策略类型、用来指定该数据包的发送出端口的出端口索引以及下一跳IP地址。
图30是本发明的数据转发设备的转发平面中的修改和转发单元的方框图。如图30所示,修改和转发单元包括:策略类型获取单元,用于从与数据包匹配的PSFB表目中获取对应于该数据流的策略类型;以及分类转发单元,根据对应于该数据流的策略类型对数据包根据进行相应的转发操作,根据PSFB表目中的出端口索引表项和下一跳IP地址所指向的邻接表表项得出出端口和对应的链路层信息,将该数据包从出端口发出。
图31是图30中的分类转发单元的方框图。如图31所示,分类转发单元包括:IPv4转发操作单元,当策略类型为纯IPv4转发IPv4_FORWARD时,执行IPv4的转发操作,修改TTL,并重新计算校验和;IPv6转发操作单元,当策略类型为纯IPv6转发IPv6_FORWARD时,执行IPv6的转发操作,修改TTL;NAT-PT操作单元,当策略类型为网络地址转换NAT_PT时,执行NAT-PT操作,根据PSFB表目中的伪IP地址和伪端口,对数据包的内容进行修改;IPv4 to IPv6自动隧道操作单元,当策略类型为IPv4 in IPv6的自动隧道模式IPv4_IN_IPv6_AUTO时,执行IPv4 to IPv6的自动隧道操作,根据PSFB表目中的隧道ID(Tunnel ID)封装数据包,隧道的目的IPv6地址为目的IPv4地址对应的IPv6兼容地址;IPv4 to IPv6手工隧道操作单元,当策略类型为IPv4 in IPv6的手工隧道模式IPv4_IN_IPv6_MANU时,执行IPv4 to IPv6的手工隧道操作,根据PSFB表目中的Tunnel ID封装数据包,隧道的目的IPv6地址为PSFB表目中的地址;IPv6 to IPv4自动隧道操作单元,当策略类型为IPv6 in IPv4的自动隧道模式IPv6_IN_IPv4_AUTO时,执行IPv6 to IPv4的自动隧道操作,根据PSFB表目中的Tunnel ID封装数据包,隧道的目的IPv4地址为IPv4兼容的IPv6地址所对应的IPv4地址;以及IPv6 to IPv4手工隧道操作单元,当策略类型为IPv6 in IPv4的手动隧道模式IPv6_IN_IPv4_MANU时,执行IPv6 to IPv4的隧道操作,根据PSFB表目中的Tunnel ID封装数据包,隧道的目的IPv4地址为IPv4兼容的IPv6地址所对应的IPv4地址。
图32是图28中的策略处理单元的方框图。如图32所示,策略处理单元包括:策略类型确定单元,用于确定应对该数据包所在的数据流进行何种业务操作的策略类型;以及策略类型信息返回单元,用于将有关策略类型的信息发送回转发平面,从而由转发平面的分类转发单元中对应于该策略类型的操作单元对数据包进行转发操作。而策略类型确定单元包括:第一判断部分,用于判断入端口是否使能了NAT-PT;第二判断部分,用于判断目的IPv4地址是否为地址池内地址;转发信息查找单元,用于查找转发表,判断下一跳的接口类型。
其中,当目的IP地址为IPv4地址时,首先由第一判断部分判断入端口是否使能了NAT-PT,并由第二判断部分判断目的IPv4地址是否为地址池内地址,如果至少一项判断结果为是,则确定应在转发平面进行NAT-PT操作,将IPv4包转换为IPv6的包;如果判断结果都为否,则由转发信息查找单元进行IPv4相关的转发信息查找转发表,判断下一跳的接口类型,如果下一跳的接口类型为IPv4,则确定应在转发平面完成IPv4转发,如果下一跳对应的接口为IPv6,则确定应在转发平面进行IPv4 in IPv6的隧道操作,其中目的地址可以为该IPv4地址对应的IPv4兼容的IPv6地址也可以为手工配置的隧道地址。
当目的IP地址为IPv4兼容的IPv6地址时,首先由第一判断部分判断入端口是否使能了NAT-PT,并由第二判断部分判断目的IPv4地址是否为地址池内地址,如果至少一项判断结果为是,则确定应在转发平面进行NAT-PT操作,其中转换后的目的IP地址为原有IPv6目的地址的低32位;如果判断结果都为否,则由转发信息查找单元进行IPv6相关的转发信息查找转发表,判断下一跳的出接口类型,如果为IPv6,则确定应在转发平面进行IPv6转发,如果下一跳的类型为IPv4,则首先由第一判断部分判断出端口是否使能了NAT-PT,如果有则确定应在转发平面进行NAT-PT操作,其中源地址为地址池内的地址,而目的地址为原有IPv6目的地址的低32位进行步骤(gb4),否则确定应在转发平面进行IPv6 in IPv4操作,其中目的地址为原有IPv6目的地址的低32位。
当目的IP地址为非IPv4兼容的IPv6地址时,由转发信息查找单元根据IPv6相关的转发信息查找转发表,并判断下一跳所对应的接口类型,如果为IPv6,则确定应在转发平面进行IPv6转发;否则为IPv4,则应在转发平面进行IPv6 in IPv4的隧道操作,其中IPv4的目的地址为配置的隧道的IPv4地址。
PSFB表目生成单元包括:第一表目生成部分,在对数据包进行IPv4转发时,策略类型为IPv4_FORWARD,生成的PSFB表目的内容包括策略类型、流ID、出端口索引、下一跳IPv6地址;第二表目生成部分,在对数据包进行IPv6转发时,策略类型为IPv6_FORWARD,生成的PSFB表目的内容包括策略类型、流ID、出端口索引、下一跳IPv6地址;第三表目生成部分,在对数据包进行网络地址/协议地址转换时,策略类型为NAT_PT,生成的PSFB表目的内容包括策略类型、流ID、Alias IPv6 Address、Source IPv4 Address、Destination IPv4 Address、Source Port、Destination Port、Alias Port、Protocol Type等,出端口索引和下一跳IPv6地址等;第四表目生成部分,在对数据包进行自动的IPv4 in IPv6隧道操作时,策略类型为IPv4_IN_IPv6_AUTO,生成的PSFB表目的内容包括策略类型、流ID、出端口索引、下一跳IPv6地址、隧道ID;第五表目生成部分,在对数据包进行手工配置的IPv4 in IPv6隧道操作时,策略类型为IPv4_IN_IPv6_MANU,生成的PSFB表目的内容包括策略类型、流ID、出端口索引、下一跳IPv6地址、隧道ID以及隧道的终点地址;第六表目生成部分,在对数据包进行IPv6 in IPv4自动隧道操作时,策略类型为IPv6_IN_IPv4_AUTO,生成的PSFB表目的内容包括策略类型、流ID、出端口索引和隧道ID;第七表目生成部分,在对数据包进行IPv6 in IPv4手工隧道操作时,策略类型为IPv6_IN_IPv4_MANU,生成的PSFB表目的内容包括策略类型、流ID、出端口索引和隧道ID。
下面参考附图33-35描述本发明在网络设备中以策略流方式实现数据包转发的方法,该网络设备至少包括转发平面和控制平面。
图33是本发明的数据转发方法的流程图。如图33所示,在步骤S1,接收数据流中的数据包,该数据流中包括至少一个数据包。然后在步骤S2,转发平面判断目的IP地址的类型。本发明中目的IP地址的类型可以是IPv4地址、IPv4兼容的IPv6地址或非IPv4兼容的IPv6地址。在步骤S3,转发平面根据不同的目的IP的类型,选择相应的数据包的多元属性组,来计算出标识该数据流的策略流ID。其中当目的IP地址为IPv4地址时,多元属性组包括源IPv4地址、目的IPv4地址、源协议端口、目的协议端口、协议类型;当目的IP地址为IPv4兼容的IPv6地址或非IPv4兼容的IPv6地址时,判断数据包头中的IPv6流标记Flow_Label是否为0,如果数据包头中的IPv6流标记Flow_Label为0,则多元属性组包括源IPv6地址、目的IPv6地址、源协议端口、目的协议端口、协议类型,如果数据包头中的IPv6流标记Flow_Label不为0,则多元属性组包括源IPv6地址、IPv6流标记Flow_Label。
在步骤S3,转发平面根据策略流ID精确查找PSFB表目。如果发现匹配则进入步骤S8,在转发平面按照PSFB表目对该数据包进行相关内容修改和转发操作,然后转到步骤S9处理下一个数据包;如果在步骤S3没有发现匹配的PSFB表目则说明这是数据流的第一个包或者是PSFB表目已经老化,则转到步骤S5,转发平面将把该数据包送到控制平面。
前面已指出,PSFB表目中记录有表明应该对数据流进行何种业务操作类型的策略类型、用来指定该数据包的发送出端口的出端口索引以及下一跳IP地址。步骤S5的操作具体说来,包括从PSFB表目中获知该数据流的策略类型,并进行相应的转发操作,根据PSFB表目中的出端口索引表项和下一跳IP地址所指向的邻接表表项得出出端口和对应的链路层信息,将该数据包从出端口发出。
更具体地说,当目的IP地址为IPv4地址时,如果策略类型为纯IPv4转发IPv4_FORWARD,则执行IPv4的转发操作,修改TTL,并重新计算校验和;如果策略类型为IPv4 in IPv6的自动隧道模式IPv4_IN_IPv6_AUTO,则执行IPv4 to IPv6的自动隧道操作,根据PSFB表目中的Tunnel ID封装数据包,隧道的目的IPv6地址为目的IPv4地址对应的IPv6兼容地址;如果策略类型为IPv4 in IPv6的手工隧道模式IPv4_IN_IPv6_MANU,则执行IPv4 toIPv6的手工隧道操作,根据PSFB表目中的Tunnel ID封装数据包,隧道的目的IPv6地址为PSFB表目中的地址;如果策略类型为网络地址转换NAT PT,则执行NAT-PT操作,根据PSFB表目中的伪IP地址和伪端口,对数据包的内容进行修改。
当目的IP地址为IPv4兼容的IPv6地址时,如果策略类型为纯IPv6转发IPv6_FORWARD,则执行IPv6的转发操作,修改TTL;如果策略类型为IPv6in IPv4的自动隧道模式IPv6_IN_IPv4_AUTO,则执行IPv6 to IPv4的自动隧道操作,根据PSFB表目中的Tunnel ID封装数据包,隧道的目的IPv4地址为IPv4兼容的IPv6地址所对应的IPv4地址;如果策略类型为网络地址转换NAT_PT,则执行NAT-PT操作,根据PSFB表目中的伪IP地址和伪端口,对数据包的内容进行修改。
当目的IP地址为非IPv4兼容的IPv6地址时,如果策略类型为纯IPv6转发IPv6_FORWARD,则执行IPv6的转发操作,修改TTL;如果策略类型为IPv6 in IPv4的手动隧道模式IPv6_IN_IPv4_MANU,则执行IPv6 to IPv4的隧道操作,根据PSFB表目中的Tunnel ID封装数据包,隧道的目的IPv4地址为IPv4兼容的IPv6地址所对应的IPv4地址。
在步骤S6,控制平面根据目的IP地址的类型、入端口的配置以及该目的IP地址所对应的下一跳的出端口的配置中至少一个,与转发平面合作来对数据包进行相应的处理,并生成相应的PSFB表目。具体说来确定应对该数据包所在的数据流进行何种业务操作的策略类型,并将有关策略类型的信息发送回转发平面,以便由转发平面根据所确定的策略类型处理数据包。下文中将具体描述有关确定应对该数据包所在的数据流进行何种业务操作及生成相应的PSFB表目的操作的具体方式。
然后在步骤S7,控制平面将该PSFB表目分发到转发平面,供后面的数据包使用。最后进入步骤S9,处理下一个数据包。
下面分别描述当当目的IP地址为IPv4地址、IPv4兼容的IPv6地址、非IPv4兼容的IPv6地址时,确定应对该数据包所在的数据流进行何种业务操作的具体方法。
图34是当目的IP为IPv4地址时,确定应对该数据包所在的数据流进行何种业务操作的方法的流程图。如图34所示,当目的IP地址为IPv4地址时,在步骤S611,首先判断入端口是否使能了NAT-PT且目的IPv4地址是否为地址池内地址,如果没有则转向步骤S612,否则转向步骤S613,在转发平面进行NAT-PT操作,将IPv4包转换为IPv6的包。在步骤S612,进行IPv4相关的转发信息查找转发表,判断下一跳的接口类型,如果为IPv4,则在步骤S614,转发平面完成IPv4转发,如果下一跳对应的接口为IPv6,则进入步骤S615,在转发平面进行IPv4 in IPv6的隧道操作,其中目的地址可以为该IPv4地址对应的IPv4兼容的IPv6地址也可以为手工配置的隧道地址。
图35是当目的IP为IPv4兼容的IPv6地址时,确定应对该数据包所在的数据流进行何种业务操作的方法的流程图。如图35所示,当目的IP地址为IPv4兼容的IPv6地址时,在步骤S621,首先判断入端口是否使能了NAT-PT而且目的地址是否为地址池内地址,如果没有则转向步骤S622,否则转向步骤S626,在转发平面进行NAT-PT操作,其中转换后的目的IP地址为原有IPv6目的地址的低32位。在步骤S622,进行IPv6相关的转发信息查找转发表,判断下一跳的出接口类型,如果为IPv6,则转向S624,转发平面进行IPv6转发。如果下一跳的类型为IPv4,则转向步骤S623,首先判断出端口是否使能了NAT-PT。如果是,则转向步骤S626,在转发平面进行NAT-PT操作,其中源地址为地址池内的地址,而目的地址为原有IPv6目的地址的低32位;否则转向步骤S625,在转发平面进行IPv6 in IPv4操作,其中目的地址为原有IPv6目的地址的低32位。
当目的IP地址为非IPv4兼容的IPv6地址时,根据IPv6相关的转发信息查找转发表,并判断下一跳所对应的接口类型,如果为IPv6,则在转发平面进行IPv6转发。否则为IPv4,则需要在转发平面进行IPv6 in IPv4的隧道操作,其中IPv4的目的地址为配置的隧道的IPv4地址。
下面说明根据对数据包所进行的不同的处理,相应地生成PSFB表目的具体方式。
●如果对数据包进行IPv4转发时,策略类型为IPv4_FORWARD,生成的PSFB表目的内容包括策略类型、策略流ID、出端口索引、下一跳IPv6地址。
●如果对数据包进行IPv6转发时,策略类型为IPv6_FORWARD,生成的PSFB表目的内容包括策略类型、策略流ID、出端口索引、下一跳IPv6地址。
●如果对数据包进行NAT/PT转换,则策略类型为NAT_PT,生成的PSFB表目的内容包括策略类型、策略流ID、Alias IPv6 Address、Source IPv4Address、Destination IPv4 Address、Source Port、Destination Port、Alias Port、Protocol Type等,出端口索引和下一跳IPv6地址等。
●如果对数据包进行自动的IPv4 in IPv6隧道操作,则策略类型为IPv4_IN_IPv6_AUTO,生成的PSFB表目的内容包括策略类型、策略流ID、出端口索引、下一跳IPv6地址、隧道ID。
●如果对数据包进行手工配置的IPv4 in IPv6隧道操作,则策略类型为IPv4_IN_IPv6_MANU,生成的PSFB表目的内容包括策略类型、策略流ID、出端口索引、下一跳IPv6地址、隧道ID以及隧道的终点地址。
●如果对数据包进行IPv6 in IPv4自动隧道操作,则策略类型为IPv6_IN_IPv4_AUTO,生成的PSFB表目的内容包括策略类型、策略流ID、出端口索引和隧道ID。
●如果对数据包进行IPv6 in IPv4手工隧道操作,则策略类型为IPv6_IN_IPv4_MANU,生成的PSFB表目的内容包括策略类型、策略流ID、出端口索引和隧道ID。
此外,PSFB表目中记录有表明该PSFB表目是否超时的超时标识,每当该PSFB表目被匹配的数据包使用一次即刷新该超时标识,控制平面每隔一定时间去检查该标识,如果该标识在一定时间内没有被刷新,说明该PSFB表目已经老化,则删除该PSFB表目。
下面分别描述目的IP地址为IPv4地址、IPv4兼容的IPv6地址、非IPv4地址兼容的IPv6地址的情况下具体的处理。
1.如果目的IP地址为IPv4地址:
(1)数据包进入网络节点后,转发平面首先根据<源IPv4地址、目的IPv4地址、源协议端口、目的协议端口、协议类型>计算出对应的Stream ID。
其中,由五元组计算出策略流ID的算法可以有多种,只需要能够实现元组和流ID一一映射和便于硬件或微码实现即可。以下是其中一种算法说明:
具体计算方法如下:
设所有可用的策略流ID空间的大小为P。
将五元组源IPv4地址、目的IPv4地址、源协议端口、目的协议端口、协议类型按照上述顺序以二进制方式从低位到高位进行排列,并计算排列出二进制组合所对应的CRC32校验和。假定该校验和为M。则由M对P取模(即M取模P),就可以得到一个策略流ID L。
(2)转发平面根据(1)所得出的流ID按照精确查找(Exact Match)去查找流转发表(PSFB)。如果发现匹配则进行(3),否则则说明该表目没有生成或已经老化,需要送控制平面进行处理,进行(9)。
(3)如果发现匹配,则开始判断策略类型,如果策略类型为纯IPv4转发IPv4_FORWARD,则转向(4),如果为IPv4 in IPv6的自动隧道模式IPv4_IN_IPv6_AUTO,则转向(5),如果是IPv4 in IPv6的手工隧道模式IPv4_IN_IPv6_MANU,则转向(6),如果为网络地址转换NAT_PT,则转向(7)。
(4)执行IPv4的转发操作,修改TTL,并重新计算校验和,转向(8)。
(5)执行IPv4 to IPv6的自动隧道操作,根据PSFB中的Tunnel ID封装数据包,隧道的目的IPv6地址为目的IPv4地址对应的IPv6兼容地址,转向(8)。
(6)执行IPv4 to IPv6的手工隧道操作,根据PSFB中的Tunnel ID封装数据包,隧道的目的IPv6地址为PSFB表目中的地址,转向(8)。
(7)执行NAT-PT操作,根据PSFB中的伪IP地址和伪端口,对数据包的内容进行修改,并继续执行(8)。
(8)然后根据PSFB中的Output Port Index表项和下一跳IP地址所指向的邻接表(Adjacency Table)表项得出出端口(Output Port)和对应的链路层消息(如MAC地址),将该数据包从出端口发出,并将超时标志位Expired Flag位重新置位,并转向(12)
(9)如果没有表目匹配,则说明这是数据流的第一个包或者是PSFB流转发表目已经老化,转发平面需要通过数据交互消息(PEM)则对数据流的第一个数据包送到控制平面。
(10)控制平面按照上文中所描述的IPv4和IPv6的处理算法IPFA的第一部分对数据包进行处理,并根据不同的处理方式,生成不同的表目,具体如下:
如果是IPv4转发,则策略类型为IPv4_FORWARD,生成的PSFB表的内容包括流ID、出端口索引、下一跳IPv4地址;
如果是NAT-PT,则策略类型为NAT_PT,生成的PSFB表的内容包括流ID、Alias IPv6 Address、Source IPv4 Address、Destination IPv4 Address、SourcePort、Destination Port、Alias Port、Protocol Type等,出端口索引和下一跳IPv6地址等;
如果是自动的IPv4 in IPv6 Tunnel,则策略类型为IPv4_IN_IPv6_AUTO,生成的表目包括流ID、出端口索引、下一跳IPv6地址、隧道ID。
如果是手工配置的IPv4 in IPv6 Tunnel,则策略类型为IPv4_IN_IPv6_MANU,生成的表目包括流ID、出端口索引、下一跳IPv6地址、隧道ID以及隧道的终点地址。
(11)控制平面通过流表目添加消息将该表目分发到转发平面。
(12)结束操作,处理下一个数据包。
2.如果目的IP地址为IPv4兼容的IPv6地址:
(1)数据包进入网络节点后,转发平面首先判断IPv6包头中的IPv6流标记Flow_Label是否为0,如果为0则根据<源IPv6地址、目的IPv6地址、源协议端口、目的协议端口、协议类型>计算出对应的Stream ID;否则,则根据<源IPv6地址、IPv6流标记Flow_Label>计算出相应的Stream ID。
其中,由元组计算出策略流ID的算法可以有多种,只需要能够实现元组和流ID一一映射和便于硬件或微码实现即可。以下是其中一种算法说明:
具体计算方法如下:
设所有可用的策略流ID空间的大小为P。
将五元组源IPv6地址、目的IPv6地址、源协议端口、目的协议端口、协议类型或者二元组源IPv6地址、IPv6流标记Flow_Label按照上述顺序从低位到高位以二进制方式进行排列,并计算排列出的二进制组合所对应的CRC32的校验和。假定该校验和为M。则由M对P取模(即M取模P),就可以得到一个策略流ID L。
(2)转发平面根据(1)所得出的流ID按照精确查找(Exact Match)去查找流转发表(PSFB)。如果发现匹配则进行(3),否则则说明该表目没有生成或已经老化,需要送控制平面进行处理,进行(8)。
(3)如果发现匹配,则开始判断策略类型,如果策略类型为纯IPv6转发IPv6_FORWARD,则转向(4),如果为IPv6 in IPv4的自动隧道模式IPv6_IN_IPv4_AUTO,则转向(5),如果为网络地址转换NAT_PT,则转向(6)。
(4)执行IPv6的转发操作,修改TTL,转向(7)。
(5)执行IPv6 to IPv4的自动隧道操作,根据PSFB中的Tunnel ID封装数据包,隧道的目的IPv4地址为IPv4兼容的IPv6地址所对应的IPv4地址,转向(7)。
(6)执行NAT-PT操作,根据PSFB中的伪IP地址和伪端口,对数据包的内容进行修改,继续(7)。
(7)然后根据PSFB中的Output Port Index表项和下一跳IP地址所指向的邻接表(Adjacency Table)表项得出出端口(Output Port)和对应的链路层消息(如MAC地址),将该数据包从出端口发出,并将超时标志位Expired Flag位重新置位,并转向(11)
(8)如果没有表目匹配,则说明这是数据流的第一个包或者是PSFB表目已经老化,转发平面需要通过数据交互消息(PEM)则对数据流的第一个数据包送到控制平面。
(9)控制平面按照上文中所描述的IPv4和IPv6的处理算法IPFA的第二部分对数据包进行处理,并根据不同的处理方式,生成不同的表目,具体如下:
如果是IPv6转发,则策略类型为IPv6_FORWARD,生成的PSFB表的内容包括流ID、出端口索引、下一跳IPv6地址;
如果是NAT-PT,则策略类型为NAT_PT,生成的PSFB表的内容包括流ID、Alias IPv6 Address、Source IPv4 Address、Destination IPv4 Address、SourcePort、Destination Port、Alias Port、Protocol Type等,出端口索引和下一跳IPv6地址等;
如果是IPv6 in IPv4自动Tunnel,则策略类型为IPv6_IN_IPv4_AUTO,生成的表目包括流ID、出端口索引和隧道ID。
(10)控制平面通过流表目添加消息将该表目分发到转发平面。
(11)结束操作,处理下一个数据包。
3.如果目的IP地址非IPv4地址兼容的IPv6地址:
(1)数据包进入网络节点后,转发平面首先判断包头中的IPv6流标记Flow_Label是否为0,如果为0则根据<源IPv6地址、目的IPv6地址、源协议端口、目的协议端口、协议类型>计算出对应的Stream ID;否则,则根据<源IPv6地址、IPv6流标记Flow_Label>计算出相应的Stream ID。
其中,由元组计算出策略流ID的算法可以有多种,只需要能够实现元组和流ID一一映射和便于硬件或微码实现即可。以下是其中一种算法说明:
具体计算方法如下:
设所有可用的策略流ID空间的大小为P。
将五元组源IPv6地址、目的IPv6地址、源协议端口、目的协议端口、协议类型或者二元组源IPv6地址、IPv6流标记Flow_Label按照从低位到高位进行排列,并计算出排列出的二进制组合所对应的的CRC32的校验和。设该校验和为M。则由M对P取模,就可以得到一个策略流ID L。
(2)转发平面根据(1)所得出的流ID按照精确查找(Exact Match)去查找流转发表(PSFB)。如果发现匹配则进行(3),否则则说明该表目没有生成或已经老化,需要送控制平面进行处理,进行(7)。
(3)如果发现匹配,则开始判断策略类型,如果策略类型为纯IPv6转发IPv6_FORWARD,则转向(4),如果为IPv6 in IPv4的手动隧道模式IPv6_IN_IPv4_MANU,则转向(5)。
(4)执行IPv6的转发操作,修改TTL,转向(6)。
(5)执行IPv6 to IPv4的隧道操作,根据PSFB中的Tunnel ID封装数据包,隧道的目的IPv4地址为IPv4兼容的IPv6地址所对应的IPv4地址,继续(6)。
(6)然后根据PSFB中的Output Port Index表项和下一跳IP地址所指向的邻接表(Adjacency Table)表项得出出端口(Output Port)和对应的链路层消息(如MAC地址),将该数据包从出端口发出,并将超时标志位Expired Flag位重新置位,并转向(10)
(7)如果没有表目匹配,则说明这是数据流的第一个包或者是PSFB表目已经老化,转发平面需要通过数据交互消息(PEM)则对数据流的第一个数据包送到控制平面。
(8)控制平面按照上文中所描述的IPv4和IPv6的处理算法IPFA的第三部分对数据包进行处理,并根据不同的处理方式,生成不同的表目,具体如下:
如果是IPv6转发,则策略类型为IPv6_FORWARD,生成的PSFB表的内容包括流ID、出端口索引、下一跳IPv6地址;
如果是IPv6 in IPv4手工Tunnel,则策略类型为IPv6_IN_IPv4_MANU,生成的表目包括流ID、出端口索引和隧道ID。
(9)控制平面通过流表目添加消息将该表目分发到转发平面。
(10)结束操作,处理下一个数据包。
本发明中关于策略流中表目的添加、删除、老化和维护,以及控制平面和转发平面通信的方式参照专利“用策略流方式提高路由表查找速度的方法”。
下面描述本发明的上述设备的应用实例,即在武汉烽火网络公司的R8002上的具体应用。
武汉烽火网络公司研制的R8002是定位于城域网汇聚层和主干层的IPv4和IPv6兼容的路由交换设备,它支持多种接口种类和具有灵活的业务生成能力。当R8002定位于城域网汇聚层的网络设备时,它主要完成对城域网中接入层上联链路的汇接(Metro Aggregation),在用户侧能够接入Fast Ethernet、Gigabit Ethernet和低速ATM等信号,并提供智能业务生成(Service Creation)功能,为运营商提供各种增值功能,而在网络层通过GE或POS和城域网主干层设备相连。此外,R8002也可以通过POS接口和SDH本地环连接,或者通过GE组成环形或星形网络,组成城域网的主干,并通过OC-48 POS和主干网设备相连。
从组网的需求来看,R8002上需要实现RIP、RIPv6和OSPF、OSPFv6等域内协议和BGP一4、BGP4+等域间协议,在链路层支持PPP、Ethernet、LAPS和HDLC等协议。从应用的角度来说,R8002能够提供实现单播、组播和MPLS转发,并提供NAT、Firewall、VPN、Virtual Router和移动IP等应用。此外,考虑到目前国内接入层的组网方式,R8002上该能够提供二层应用(VLAN)的支持。作为提供给运营商的增值功能,R8002目前可以提供基于端口和PPPoE Session的带宽限制和QoS保证。从对用户的管理角度来说,R8002目前可以提供基于PPPoE的认证方式,并能通过Radius来实现对用户流量的计费。此外,还支持VLAN+IP+MAC的三级绑定和Web认证。
R8002的机架采用工业标准的19英寸机箱,盘位间距25.4mm,总共16个槽位,其中主控CPU和交换盘占用7号和8号槽位,为1+1的备份,而剩余14个槽位提供给线卡使用,线卡为9U。
图6显示出本发明的应用的逻辑视图。图中,黑色箭头代表高速数据总线,绿色箭头代表高速控制总线。其中,高速的数据总线提供的大容量的数据通道,而控制总线中提供了管理消息的通道,并提供了监控硬件状态的Health#、Present#和Alarm#等信号。整个系统采用3∶1的风扇备份和1∶1的电源备份,提供了硬件的高可用性冗余支持。
此外,R8002采用了控制和转发分离的体系结构,其中控制和管理功能运行在主控CPU上,它上面运行了故障检测模块(FDM)、容错模块(FTM)以及和每个协议相关的协议相关单元(PSE),实现主用和备用之间的故障检测和恢复。而线卡采用了基于网络处理器转发的体系架构,如图7,在每个线卡的核心为一个高性能的网络处理器,它在SRAM和SDRAM中维护有全局的转发消息库(FIB),因此在主备切换过程中,只要有流量进入,仍能进行正常的转发。
当采用策略流转发时,每个数据流的第一个数据包将被网络处理器送到线路接口卡的RISC处理器上,由它完成路由表的查找和其它业务操作(如移动IP)。然后,它将生成一条PSFB表目,并将它下载到SRAM和SDRAM中。由于采用了精确查找,而PSFB的表目的存储采用了两级存储的方式,首先在SRAM上存有对应每一个Stream ID的索引,而由这一索引指向SDRAM中的实际表项,而这一表项的索引采用了Hash的算法。目前情况下,每条流转发表目为128Bytes,在R8002上,每个接口卡支持64K个Stream,因此PSFB所占用的SDRAM空间为128*64K=8M空间,本发明使用的空间是从SDRAM起始地址0x3ff0000开始的8MBytes空间。而SRAM由于只需要存放相关表目的索引,因此只需要64K*4=256KBytes空间,本发明使用的SRAM中的起始地址为0xcl20000。而由于每个流都是单向的,因此每个流仅存在于各个线卡中,所以整个系统可以支持64K*14=896K个Stream。如果考虑到每个用户上网时平均有20个Stream,则R8002共可以支持45K,即45,000个用户同时在线。
以下为典型的R8002中对IPv6数据包的处理流程:
(1)数据包通过物理层芯片和成帧器进入R8002后,网络处理器中的微码首先判断包头中的IPv6流标记Flow_Label是否为O,如果为0则根据<源IPv6地址、目的IPv6地址、源协议端口、目的协议端口、协议类型>计算出对应的Stream ID;否则,则根据<源IPv6地址、IPv6流标记Flow_Label>计算出相应的Stream ID。
(2)微码根据(1)所得出的流ID按照精确查找(Exact Match)去查找流转发表(PSFB)。如果发现匹配则进行(3),否则进行(5)。
(3)如果发现匹配,则开始判断策略类型,如果策略类型为IPv6_FORWARD,则转向(4),如果为IPv6_IN_IPv4_MANU,则转向(5)。
(4)微码执行IPv6的转发操作,修改TTL,转向(6)。
(5)微码执行IPv6 to IPv4的隧道操作,根据PSFB中的Tunnel ID封装数据包,隧道的目的IPv4地址为IPv4兼容的IPv6地址所对应的IPv4地址,转向(6)。
(6)微码根据PSFB中的Output Port Index表项和下一跳IP地址所指向的邻接表(Adjacency Table)表项得出出端口(Output Port)和对应的链路层消息(如MAC地址),将该数据包从出端口发出,并将Expired Flag位重新置位,并转向(10)
(7)如果没有表目匹配,则说明这是数据流的第一个包或者是PSFB表目已经老化,微码需要内部高速总线将数据流的第一个数据包送到主控RSP的RISC上进行处理。
(8)运行在RISC处理器上的控制平面按照IPv4和IPv6的处理算法IPFA的第三部分对数据包进行处理,并根据不同的处理方式,生成不同的表目,具体如下:
如果是IPv6转发,则策略类型为IPv6_FORWARD,PSFB表的内容包括流ID、出端口索引、下一跳IPv6地址;
如果是IPv6 in IPv4手工Tunnel,则策略类型为IPv6_IN_IPv4_MANU,表目包括流ID、出端口索引和隧道ID。
(9)控制平面通过高速内部总线将该表目分发到转发平面。
(10)结束操作,处理下一个数据包。
总之,由于采用了基于策略流的IPv4和IPv6兼容的转发算法,烽火网络公司的R8002具有以下特点:
1.支持在同一个物理管道中的IPv4和IPv6的转发,使得IPv4向IPv6的平滑过渡成为可能。
2.与MPLS技术不同,在不改变设备硬件结构和不引入其他网络间信令的前提下,只是通过改变设备内部的逻辑流程,提高了转发性能,并支持多种应用。
3.和传统的基于包IP转发不同,采用了基于流处理而不是基于每个数据包处理的思想,对一个数据流只需要做一次复杂处理即可,避免了复杂的最长匹配查找,大大提高了转发性能。
4.采用同一张策略流转发表同时支持IPv4和IPv6共存的多种方式,避免了采用多张表的复杂数据结构。
5.采用多元组来标识一个IP业务流,在转发平面采用统一的策略流转发表PSFB,并提供丰富的可扩展的表项,可以根据业务操作类型来决定对数据包的处理,可以用来增长用户的各种需要应用,并为用户提供定制业务的接口,使得用户定制业务成为可能,并使得运营商可以根据用户每一个流提供不同的业务和服务质量。
一、R8002的硬件体系设计方案
武汉烽火网络公司基于RPR的城域网多业务环R8002设备是新一代的多业务光交换和传输平台,它对交换和传输进行简化,同时也对交换和传输这两项技术进行了有机的集成,使之成为一个整体,R8002设备采用最新的ITU-T建议X.87,并基于网络处理器、大容量Switch-Fabric、高性能协议处理引擎、自主知识产权的FPGA和ASIC、光波分复用等先进技术,在同一个平台上实现了多种业务的融合,提高了城域和区域网络中的带宽效率,极大地降低了电信运营成本,可以获得最巨大的营收潜力,使运营商能够以最大的网络架构灵活性对其基础设施进行低成本、高效率地升级,为电信运营商提供丰富的服务组合。
R8002设备可提供以太网、千兆以太网、DVB、ATM、POS、X.85和X.86支路业务,同时还能以动态数据分组环的方式工作,像路由器一样在环上转发包括IP包在内的分组业务,在环上运行的业务可提供单播、组播和广播模式。采用R8002的组网方式使网络费用和维护工作量大大减少。
1.基于网络处理器(NP)的分布式转发
网络处理器是一种专为Gbps或Tbps速度下进行分组过滤和转发处理而优化的可编程的专用硬件ASIC。转发引擎能够以线速对协议进行分类和分析,减少了系统的复杂性,极大的提高了系统的性能。网络处理器完成的高级功能包括:分组分类、区分优先级、调整、流量整形、转换、业务调度、加密/解密、转发、排序和路由、网络互联、收集统计信息等。网络处理器也支持DiffServ服务、QOS、MPLS等。对于较低层次的功能,网络处理器可以对分组头部和负荷进行分析和分类;在事先定义的表中作基于内容的查找;把分组指派到适当的输出端口或队列;调整分组域以支持VLAN和QOS。
转发引擎的实现可以有两种方式:一种是转发引擎和线路接口分开,通过交换机构互联,这种设计的优点是可以充分利用转发引擎,提高转发引擎的利用效率,缺点是增大了交换结构的负荷而且负载平衡算法比较复杂;另一种方式为每块线路接口单元配备一个转发引擎,这样作的好处是降低了交换结构的负荷而且不需要动态负载平衡。因此在实际设计中我们采用第二种设计方案,即基于NP的分布式分组转发。
为了提高R8002设备查表效率,采用了二个关键技术:分布式路由表和硬件查找。在每一个转发引擎中都有一份和全局路由表相同条目的局部转发表,转发引擎独立的查找本地转发表确定分组的发送路径。为了实现局部转发表与全局路由表的同步和一些管理功能,转发引擎中还有通用CPU和本地存储器。
烽火网络R8002设备高度可编程的网络处理器提供了灵活的智能业务生成能力和丰富的安全功能,可以实现AAA功能、地址转换(NAT)和分配功能、服务质量保证QOS和带宽控制功能、PBR、WEB认证、PPPoE、基于ACL的安全机制、虚拟专用网VPN功能等等,并可以根据不同的策略流为用户提供Diffsev服务。
NP是线卡的核心部份,它首先从MAC层接收到数据包,然后通过解析器,取出包头中的关键码信息,并根据该关键码在转发表中按照特定算法(如Hash算法)来查找到相关的转发表目,再由该表目改写包头,重作校验,设置优先级,最后转发数据包到交换核心。
图8是数据包处理的基本流程。首先转发引擎解析出数据包目的MAC地址,并由此判断是否需要进行第三层交换;若目的MAC地址不是转发引擎所对应的端口MAC地址,则说明需要进行第二层的交换处理(桥接),此时,目的MAC目标就是数据包的最终目的地址。如果目的MAC地址是此端口的MAC地址,则判断它的目的IP地址是否为路由器的IP地址,如果是,则认为这是一个管理信息包(如主从CPU之间的通信包),并将它通过交换核心发往主CPU。若IP地址不是路由器的IP地址,那么就使用特定算法(如Hash算法)在SDRAM中找出此IP地址对应的MAC地址,并在转发表中查找到对应的出端口,在修改包中源MAC地址、目标MAC地址以及TTL计数器,重新计算IP包头的校验和后,被发送到交换核心。若转发表中无这个IP地址,则由主CPU查找其全局路由表,如果找到此地址,则由主CPU完成后续处理,并将根据新的路由信息将转发表更新。若主CPU找不到此地址,则将其传到缺省路由器或把它丢弃。(在边缘路由器中,如果主CPU仍找不到IP地址对应的表目,就会把它传到缺省路由器,而在核心路由器中,由于主CPU中有整个网络的全局路由表,如果仍然找不到,将认为IP地址有误,并把它抛弃。)
R8002设备中的NP是采用CMOS技术的高度集成的可编程转发引擎,支持2.5Gbps的线路接口,以后可以升级到10Gbps的接口速率。NP通过高带宽的数据总线与MAC/Framer连接,可以灵活的组成多种不同接口类型的线卡,例如FE、GE、POS、Ethernet over SDH、R8002等,可以满足光传输网、WAN、MAN、3G等应用。一个NP在线卡上的典型应用如图9:
NP是基于可编程的微引擎结构,采用了流水线技术,可以将转发引擎(Forwarding Engine)的功能分为五大部份:包解析、关键码查找、包头修改、包排队和调度,并采用单独的引擎来实现这五大功能。在包处理的过程中,这些引擎将按照固定的顺序对包进行单独处理。这条每个数据包必须经过的过程就是包流水线。由于采用了流水线作业,每个引擎在完成自己的任务后,就可以将该包发送到流水线上的下一个引擎,而可以开始处理新的数据包。这就意味着每个引擎不需要等待NP完成对一个包的完整处理,就可以处理下一个新的数据包,从而大大提高了执行效率。图10是网络处理器的内部结构框图。
NP中有两条内部流水线,分别是Incoming包流水线和Outcoming包流水线。Incoming流水线是每个从MAC层到交换核心的包必须遍历的。而Outcoming流水线则是从交换核心到MAC层的逆向的全过程。下面将以Incoming包流水线为例,说明NP的工作流程。
入流水线工作流程:
当一个包从Incoming Stream Interface进入NP并发送到交换核心的过程中,它必须按固定顺序经过以下引擎:输入流调度器、接收流解析器、查找和更新引擎、接收编辑器和输入队列管理器,如图11:
其中,三个引擎是可编程的AFP,它们通过执行引擎上存储的微代码指令来实现功能。这三个引擎是:接收解析器、查找和更新引擎、接收编辑器。每个引擎可以通过NP的CPU接口下载微代码,从而可以根据以后的需要扩展功能。而另外两个不能编程的引擎是高度集成的专用的状态机。这样就在具有灵活性的同时,又保证了执行的高效率。
入流水线功能描述如下:
·调度
当一个包到达Input Stream Interface时,调度器将把它存储到对应于32个Stream的32个内部FIFO中的一个。然后,调度器将对数据流进行判决。调度器首先要对各个物理端口进行加权,然后基于轮转法(Round Robin)进行调度。所谓轮转法,就是让每个进程在就绪队列中的等待时间和享受服务的时间成正比。轮转法的基本概念是将CPU的时间分成固定的时间片。如果一个进程在被调度选中之后用完了系统规定的时间片,但仍未完成任务,它将自己释放占有的CPU资源而排到就绪队列的末尾,等待下一次调度。同时进程调度程序又去调度当前就绪队列中的第一个进程或作业。其原理如图12所示:
此外,调度器还要将包分段。其中,第一个段叫做SOP(Start of Packet)。在SOP段中,含有整个包分段情况的完整信息,并包含全部关键码信息。因此流水线下一个引擎(查找和更新引擎)可以只需通过处理SOP就能正确地处理包。
·解析
解析器主要是执行包的解析和提取功能。由于SOP中已经包含有全部包的关键码信息,所以解析器只需通过对SOP的处理就可以完成包的解析过程。这样,包处理的效率就大大提高。NP的核心是解析器和查找&更新引擎,它们实现了转发引擎的主要功能。解析器的主要功能在于向查找和更新引擎提供查找的关键码。由于它是可编程的AFP,所以可以通过从CPU下载的微代码来决定关键码是IP目的地址、MAC地址还是UCP/TCP端口号,甚至是更高层信息。当得到这些信息后,并根据需要再加上一些其它信息(如MPLS标签)后,解析器将生成转发头(Forwarding header),并把它发向查找和更新引擎。
·查找和更新
查找和更新引擎作为转发引擎的核心,它的查找算法和执行效率决定了转发引擎的包转发率。查找引擎首先从解析引擎中获得转发头,然后执行查找算法,并在外部的SDRAM中的转发表中查找到所需表目。如果查找引擎找到关键码相关的表目,它将把该表目发往接收编辑引擎进行下一步处理。
由于转发表在外部的SDRAM中是基于Hash的存储方式,因此,在查找过程中,查找引擎首先将关键码处理为一个独特的Hash,并用该Hash按照最长前缀匹配在转发表中进行查找。如果该条目存在,查找引擎将把它的Data payload域传送到编辑引擎。
从结构上看,NP的查找引擎由两部份组成,并按主-从模式运行。主引擎部份是基于微代码的AFP,而从引擎部份是一系列的有限状态机,其中每一个状态机执行某一个特定的查找操作。由于主引擎是基于微代码的,所以具有相当的灵活性,并可以根据需要随时加以扩展。而固定的从引擎则可以快速完成固定的查找操作。
查找引擎同样支持DML(Data Manipulation Layer)头的产生和添加,这样可以就很方便地进行流分类、服务分类和排队。
此外,根据点击次数和老化计数,更新引擎还将把SDRAM中的转发表项进行更新。这样,使得外部转发表中的表项始终和全局的路由表保持一致,并有较高的查找效率。
·编辑
编辑引擎从查找引擎中得到相关信息,并据此对数据包的相关域进行修改。首先,它要将TTL(Time to live)域减一,并且重新生成IP包的校验和,完成对TCP/UDP包头校验和的更新和对源和目的MAC地址进行改写,其中,将目的MAC地址更新为转发表目中下一Hop的MAC地址,而将源MAC地址更新为转发引擎所对应的路由器端口的MAC地址。此外,编辑器还要插入或删除VLAN标志,并产生单播或组播头。
·队列管理
输入队列管理器是Incoming流水线的最后一步。输入管理器完成的功能就是从编辑引擎处接收到包,按照调度策略将它们队列化,并发往交换核心。输入管理器通过输入包内存接口和Fabric接口这两个外部接口来管理输入的数据包。其中,输入包内存接口是一个SDRAM接口,它最多可以支持128Mbytes和264个逻辑输入队列。
当队列器接收到一个数据包时,首先根据包头前的本地接收队列头(LQRHeader)进行判断。在LQR头中,存有出Crossbar的端口ID,优先级ID和组播信息。它是由解析器、查找引擎和编辑引擎共同作用后所生成的。在作出判断后,队列器将把包存储到264个输入队列中的一个。只要264个队列有队列不空,队列器根据轮转法算法对队列进行调度,反复将队列中的等待发送的包发往交换核心。这样,就完成了从NP到交换核心的转发。
2.大容量交换核心Switch-Fabric
交换结构是R8002设备中的关键部分,是解决高速报文转发的关键节点,它的性能直接决定了整机的性能。R8002设备的交换结构采用交叉开关的方式来实现。交叉开关能够达到很高的速率,扩展性好,易于系统的扩展和升级,但是需要设计完善的调度算法并用高速硬件实现调度器。随着人们对交叉开关调度算法研究的深入,已经设计并实现了许多性能良好、实现简单的调度算法,因此,在R8002设备中我们采用了高性能的交叉开关作为交换结构,下面我们将重点讨论交叉开关的设计与实现。
使用交叉开关主要基于如下的考虑:首先,交叉开关可以在网络接口卡之间建立点到点的连接,这就意味着网络接口卡之间可以高速传递数据。目前,在商用产品中,芯片到芯片的线路速度已经可以达到3.6Gb/s,在实验室中已经可以达到4~10Gb/s。其次,交叉开关可以同时提供多路传送,只要源和目的地不冲突,就可以同时传送,这样可以极大地增加带宽。
在使用交叉开关时,需要把报文变成定长的分组。在使用定长的分组时,可以根据分组的大小划分时间片,根据时间片一步一步地处理。如果使用变长的分组,那么分组通过交叉开关的时间就是随机的,调度器就必须知道所有输入和输出的状态,这使调度器的设计相当复杂,而且很难做到公平调度。
在使用交叉开关时,需要解决以下几个主要问题。
当使用交叉开关作为交换结构时,可能会遇到以下3种阻塞。
第1种是线路头部阻塞。如果输入端口等待交换的分组都使用同一个队列排队,就会出现线路头部阻塞问题。举例来说,如果队列头部的分组要去的端口正忙,那么此分组只能在队列中等待。这时即使它后面的分组要去的端口是空闲的,也没有机会发送。这种阻塞会极大地降低交叉开关的流量。采用虚拟输出队列(virtual output queuing,简称VOQ)的机制可以解决线路头部阻塞问题。思路是:假设系统中有n个输入端口和n个输出端口,那么每个输入端口都有n个队列分别对应每个输出端口。这样,若一个输出端口发生阻塞对其他的输出端口不会产生影响。当然,在实际输出时,每个端口只对应于交叉开关中的一条线,因此称之为虚拟输出队列。
第2种是输入阻塞。由于虚拟输出队列对应的交叉开关的线只有1条,因此,每次只能交换一个分组。当虚拟输出队列中有多个分组时,得不到交换机会的队列头部分组就处于输入阻塞状态。输入阻塞不影响交叉开关的流量,只会增大被阻塞的分组的延迟。
第3种是输出阻塞。如果两个输入端口的分组都要去同一个输出端口,就会发生输出阻塞。这种阻塞和输入阻塞一样,不会影响交叉开关的流量,只增大被阻塞的分组的延迟。为了解决输入阻塞和输出阻塞,提出了两种解决方案:第一,带优先级的虚拟输出队列。给每个输出队列划分4个优先级,相应的输出队列也就变成4条,高优先级的分组优先发送。这种方案并不能完全解决输入阻塞问题,比如优先级相同的分组之间还是有阻塞,但是它可以保证高优先级的分组的延迟比较小;第二,加快交叉开关的交换速度(Speedup)。如果交叉开关的交换速度是端口速度的两倍,那么,相对于端口来说,交叉开关能够一次交换两个分组。从理论上说,如果有n个输入端口和n个输出端口,那么交叉开关的速度必须是端口速度的n倍才能保证没有输出阻塞。在实际使用中,只要交叉开关的速度是端口速度的两倍,就可以基本保证不出现输出阻塞。
交叉开关的另一个重要问题就是调度算法,调度算法可以分成输入排队的调度算法和输出排队的调度算法。调度算法设计的基本要求是:
(1)效率高。高效率的调度算法应该能够同时匹配尽可能多的输入队列。一般来说,使用硬件很难快速计算出最佳匹配,因此,一般在设计调度算法时总是尽力寻找次优的算法。
(2)稳定性。无论输入队列的情况如何,调度算法都应该迅速找到可行的调度。
(3)不会出现某些队列永远得不到响应的情况。
(4)快速。调度算法必须快速执行,否则将会抵消交叉开关带来的带宽的增加。
(5)易于实现。调度算法应该易于用硬件实现。实现的复杂性包括调度器维护的状态的数量,基于这些状态作出决策的逻辑的复杂度和修改状态时的通信开销。
烽火网络R8002设备采用80Gbps的大容量智能交换矩阵(Crossbar),结合队列管理引擎共同构造了一个高性能的路由、交换系统,支持完善的可编程QOS算法和单播与组播业务,提供业务优先级分类,采用VOQ队列和Speedup因子优化交换结构的性能。交换系统支持冗余保护功能,支持端口的热插拔操作,采用多个Crossbar结构可以方便的倍增系统交换容量,便于系统的升级。
广义上的交换结构由三部分构成:线路接口卡上的队列管理器、高带宽的交换式背板、Crossbar交换核心。图14是采用Crossbar交换技术的系统结构:
线卡上的队列管理器主要完成VOQ队列的管理、业务优先级的调度、组播和单播带宽的分配、串/并转换功能,它把网络处理器送来的并行数据按照一定的数据格式进行封装,然后把并行数据流转换成高速的串行数据流,通过背板传送到交换线卡。反之,它接收从交换线卡来的串行数据,按照开销比特的指示进行数据解封装,然后把高速的串行数据转换为低速的并行数据。图15是队列管理器的内部结构。
交换式背板是线路接口卡与交换线卡进行连接的物理通道。交换芯片组通过时钟同步过程确定背板上数据通道的可用性,并且随时检测通道的信号质量。从线卡到中央交换结构的连接是简单的点到点的连接,这意味着可以采用高速连接。每个线路使用单独的收发器,因而可以对信号反射进行控制,从而允许信号有更短的建立时间。短的点到点的连接有利于控制时钟Skew、信号完整性和减少电磁干扰。而且,目前在高速串行线路中广泛采用差分技术,既提高了线路在高速传输时的抗干扰能力,又较低了功耗,极大的减小了EMI/EMC。
Crossbar交换核心是整个Switch-Fabric中的关键部分(见图16)。R8002设备中的交换线卡采用自路由的同步串行分组交换技术。首先,在接收线卡上,从交换芯片发来的数据被重新定时,这消除了任何占空比的变化或数据相关性的影响,交换芯片必须提供重定时时钟去同步多有的线卡,可以采用把交换芯片作为重定时时钟源的方法。时钟频率信息嵌入在串行数据流中发送给所有线卡上的收发器。交换芯片的字时钟被时钟倍频单元(CMU)倍频去产生主比特时钟BCLK,比特时钟用于串行化发送给收发器的数据。收发器利用一个时钟恢复单元(CRU)去恢复比特时钟的频率和相位信息,然后利用恢复的时钟向交换芯片发送串行数据。在交换芯片处,只需要利用数据恢复单元(DRU)去恢复相位信息,因为交换芯片恢复的串行数据与它发送给线卡的串行数据是同频率的,可以设计DRU去吸收因温度或电源等因素变化而产生的相位变化。交换芯片和收发器之间一旦长时间的建立了比特时序,在每次交换芯片重配置后不再需要额外的相位采样时间。同步方式的另一个优点是除了比特同步,在交换芯片和收发器之间还会执行字同步和信元同步,然后命令字和信息就可以在它们之间传送。
传统的串行交叉结构只有单个控制端口,从而成为路由变长分组的瓶颈。在异步交换的方案中,交换芯片不能接收和产生数据,因为它仅仅为串行数据流提供通道服务。与之不同,字同步的串行交换背板可以在收发器和交换芯片之间传送完整的数据或者命令字。利用交换芯片的内部简单的Round-Robin仲裁单元,背板可以实现自路由。
除了硬件的设计外,交换单元的调度算法也是实现高吞吐率的一个关键方面,在执行完字同步后,在发送数据时,交换芯片与收发器之间进行连接请求——仲裁——确认的传输机制,在线卡上进行队列的调度,在交换芯片上进行轮转优先权的仲裁算法,并采用基于信用的调度算法,解决交换线卡的数据阻塞问题,最终实现高效率的交换单元。
3.高性能路由处理引擎
R8002设备采用高性能的嵌入式微处理器作为路由处理引擎,支持丰富的协议种类,收集网络拓扑信息生成全局路由表。此外,它支持通用的SNMP网络管理协议,支持TELNET用于对路由器的管理和配置,另外还支持MIBII信息数据库。R8002设备的系统维护和管理功能也由微处理器完成。
二、R8002设备的系统结构
R8002设备采用标准的19英寸机架,可以方便的安装在电信机房内,采用前面插卡的背板和机架系统。图17中总共有14个槽位,其中系统盘占用两个槽位7和8,提供冗余保护;其他12个槽位支持各种线卡的混插,方便用户根据需要选配不同的线卡,线卡可以提供FE、GE、POS、MSR/RPR、CWDM接口。
为满足电信级高可靠性的要求,硬件系统具备高可靠性,支持线卡的热插拔,并配合软件完成主/备部件的热倒换,系统维护时不会中断业务。电源和冷却系统都具备N+1冗余保护功能,并可以纳入网管进行管理。硬件系统提供完善的系统状态检测和故障定位能力,为系统维护提供了快捷有效的手段。
R8002设备在软件上采用了系统适配层和操作系统适配层的方式解决了物理资源到逻辑资源的映射,它从逻辑上可以分为以下部分:
1.控制平面:提供路由和信令功能,和其他网络设备交互并处理协议包,同管理平面一起为数据平面生成转发时依照的各种表目和策略,处理异常或其它选项包。
2.数据平面:完成per-packet处理,实现对转发数据包的layer 2到layer 7的处理,提供多种转发方式(layer 2、IP、MPLS等)和安全策略处理(PBR、ACL和VPN),完成对统计变量的计数。
3.管理平面:完成对协议和系统的的配置和管理,,管理方式主要包括命令行(CLI),串口图形界面,SNMP网管工作站和基于WEB的图形管理界面。它主要完成的功能有:对路由器的配置管理,性能的查看,告警和日志的记录,用户安全的认证,数据库信息的维护和管理。
4.操作系统适配层:为上层的控制平面和管理平面提供统一的接口,屏蔽操作系统的实现细节;提供通用的系统调用,如单链表、多链表和哈希表的添加、删除和建立;提供对系统内存和缓存区的管理调用。
5.系统适配层:完成控制平面到数据平面的适配,对控制平面屏蔽系统硬件结构细节,提供通用的上层API接口。完成数据平面和控制平面信息的交互,包括转发表目、协议包和网管数据等。
其中,R8002设备软件的核心部分为多处理器通信协议(MPCP)。它完成数据平面和控制平面、管理平面的适配,使得整个路由器能够对外是一个完整的有机体。为协议包和网管数据提供数据通道,并实现线卡和主控处理器上关键数据结构的同步。
综上所述,R8002设备逻辑结构如图18:
机械结构技术路线:
1、子架结构及电路板与连接器的基本要求符合如下标准:
IEC STANDARD Publication 297 Dimensions of mechanical structure of482.6mm(19inch)series
IEEE(1101.1,1101.10,1101.11)Equipment Practice Eurocard packagingIEC-61076-4-101 Specification for 2mm Connector Systems
2、机箱结构:
机械结构采用AutoCAD、Pro/E等软件设计,采用理论计算、软件仿真、仪表测试等方法进行散热系统分析,确保散热系统满足电路设计的要求,保证整个系统长期稳定可靠的运行。
R8002设备机箱的基本特性如下:
Size:19英寸(482.6mm)工业标准机架宽度(包含安装用的凸沿),13U(578mm)高度(不包含交流整流单元),585mm深度(从前部安装凸沿开始计算)
用户可选配的19英寸宽度,3U高度的110/220V交流自适应整流电源
Mounting:使用标准的EIA RS-310-C 19英寸机架安装凸沿
Slot:14个具备热插拔能力的9U(400mm)插槽
Power Supplies:3~4个可热插拔、N+1冗余交流整流电源(110/220V AC自适应),从机架前面操作。机箱后部可选的-48V DC输入插座。
Fans:可热插拔风扇模块。
Air Flow:两侧和前面进风,后部出风。
ESD Grounding:两个ESD接地点,前、后各一个。
Metal:Aluminum alloy,T5052-H32
Metal Plating:Chemical film per MIL-C-5541,clear
机箱的上方有个1U高度的风扇单元,为整个系统散热。风扇单元总共有7个风扇组成,构成一个整体的风扇单元,风扇单元上安放风扇控制电路和热插拔控制电路,系统可以随时监控机箱内部的温度、各风扇的转速、风扇状态等信息,如果被监控量超过设定的域值,则系统自动启动告警和故障保护机制。在系统风道入口处安装防尘滤网,防止灰尘吸附在电路板上。
机箱提供-48V DC和110/220V AC两种外部电源输入方式。如果整个系统需要使用交流输入,则需要在整个子架(包括风扇单元)的下方选配一个3U高度的19英寸通信电源,这个19”的电源整流部分提供宽范围的交流输入能力,可以自动适应110V和220V交流输入,输出48VDC,总输出功率约1200W。此电源整流部分提供完善的电源保护和监控功能,具备冗余和热插拔能力,并可以通过RS-232接口由系统板进行管理。所有线卡采用分散式供电方法,电源部分具有过压、欠压、过流、防雷等完善的保护机制。
图19是带远程监控功能的电源整流系统的原理框图:
嵌入式以太网控制总线
R8002设备借鉴PICMG协会发布的关于系统结构相关规范的思想,结合R8002
设备的体系需求,设计了嵌入式以太网控制总线,支持10/100M Base-Tx自适应,以后可以升级到Gigabit Ethernet的速率。采用星型拓扑的以太网结构极大的提升了系统的性能,简化了系统的控制结构,增强了系统控制能力,使系统结构更加灵活。
为了增强系统的高可靠性,R8002系统采用两个以太网交换板提供冗余保护。R8002设备嵌入式以太网作为两个系统盘之间的“握手协议”的信道,MPCP多处理器通信协议和HA软件协议信息都在以太网通道上传送信息。此外,以太网还作为转发表更新和软件在线升级的通道。
交换结构是整个设备的分组数据交换中心。R8002设备的交换结构由线路接口卡上的队列管理器、背板、Crossbar芯片组三个环节构成。线卡上的的队列管理器进行分组的一级调度,维护VOQ队列,利用SeDes把网络处理器的并行总线转换成串行的2.6Gbps的多个高速串行总线,多个串行通道具有冗余保护、加速因子、负载均衡的功能。在背板上采用带状线设计,支持2.6Gbps的高速差分信号传输。Crossbar是一个80Gbps交换容量的同步交换矩阵结构,执行二级轮转优先权调度算法,同时监控高速链路的状态。R8002设备共有两个交换盘,提供冗余保护,能够在HA软件的控制下进行快速自动保护倒换,提高了系统的高可靠性。
图21是采用双交换结构的R8002设备交换系统原理图:
对于高可靠性的千兆路由器,要求系统具备99.999%的可靠性。要达到这个要求,必须采用相应的故障保护和部件冗余技术以及HA软件。Crossbar芯片组中的Transceiver具有多个高速串行端口,实现主/备冗余功能,可以通过简单的配置切换工作信道,提高可靠性。而且,系统主控盘、Switch-Fabric、以太网交换节点都采用了1∶1热备份的方法,两个CPU之间通过Heartbeat协议进行通信,监控彼此的状态;两个CPU的状态保持完全同步,当主CPU出现故障时,备份CPU将立即接管系统的控制权,实现自动保护倒换。此外,系统的供电部分、散热风扇和用户线卡都要采用冗余备份的方法。系统主控CPU负责监控和维护整个系统并收集各部分的状态信息,一旦系统某个部分出现故障,CPU会马上监测到,并立即启用冗余的部件接替失效部件的工作,同时CPU将向系统管理员报告故障信息。采用故障保护措施之后,整个系统的可靠性有显著的提高,在不中断正常业务的条件下任何失效部件都可以方便的在线(on-line)更换。
系统的所有状态信息都可以通过网管的GUI界面进行查看。在每个线卡上设置几个关键的状态指示LED。在主控CPU的面板上通过状态指示LED表明系统的工作状态。如果需要,可以再另外添加部分指示信号。系统板可以对风扇单元和交流输入电源部分进行监控,还可以监测系统温度。通过自定义的系统维护总线与网管系统的结合,R8002设备可以快捷的反映系统的运行状态,供用户本地或远程监控。
三、R8002设备线卡结构
武汉烽火网络公司基于RPR的城域网多业务环R8002设备是新一代的多业务光交换和传输平台,它对交换和传输这两项技术进行了有机的集成,使之成为一个整体。R8002设备第一步首先提供以下功能的电路板:
①16 Port 10/100M Base-TX/FX
②2 Port Gigbit Ethernet
③2 port MSR/RPR(最高速率STM-16/OC-48或STM-4/OC12)
④系统主控盘,80Gbps交换容量的Switch-Fabric
R8002设备的线卡采用统一的结构,除CWDM线卡外,其他线卡都采用了网络处理器和队列管理器的公共技术,不同之处主要位于网络处理器前端。图是R8002设备通用线卡的结构如图22所示。
在OSI7层网络模型中,PHY位于物理层,它负责和某一特定介质类型之间的物理、电气接口,保证物理比特的正确传输。
介质存取控制(MAC)子层对数据流进行成帧处理,保证帧的无差错传输,同时具有介质分配、冲突处理和寻址的功能。
网络处理器完成对数据分组的解析,分类、区分优先级、调整、流量整形、转换、业务调度、转发、排序等功能。
适配FPGA主要完成网络处理器接口到队列管理器的接口适配。
队列管理器维护虚拟输出队列(VOQ),进行业务优先级调度,根据算法进行带宽分配,采用SerDes接口通过背板与Switch-Fabric互联。
对于POS线卡,线卡结构略有改变如下(如图23):
收发器完成线路编/解码,进行光/电信号的转换。成帧器完成IP到Sonet/SDH帧的映射。
四、软件的总体结构
R8002的软件从逻辑上可以分为以下五个部分(图24-软件分层结构):
1.控制平面:提供路由和信令功能,和其他网络设备交互并处理协议包,同管理平面一起为数据平面生成转发时依照的各种表目和策略,处理异常或其它选项包。
2.数据平面:完成per-packet处理,实现对转发数据包的layer 2到layer7的处理,提供多种转发(layer 2、IP、MPLS和PPPoE)方式和安全(NAT和VPN)策略处理。完成对统计变量的计数。
3.管理平面:完成对协议和系统的的配置和管理,,管理方式主要包括命令行(CLI),串口图形界面,SNMP网管工作站和基于WEB的图形管理界面。它主要完成的功能有:对路由器的配置管理,性能的查看,告警和日志的记录,用户安全的认证,数据库信息的维护和管理。
4.操作系统适配层:为上层的控制平面和管理平面提供统一的接口,屏蔽操作系统的实现细节;提供通用的系统调用,如单链表、多链表和哈希表的添加、删除和建立;提供对系统内存和缓存区的管理调用。
5.系统适配层:完成控制平面到数据平面的适配,对控制平面屏蔽系统硬件结构细节,提供通用的上层API接口。完成数据平面和控制平面信息的交互,包括转发表目、协议包和网管数据等。
五、系统通用适配层(UAL)
系统适配层示意见图25。
R8002上的系统适配层分为三部分:
(1)为协议提供的通用上层API接口。
(2)主控卡和线路卡的多处理器通信协议。
(3)网络处理器私有的和自己开发的API接口。
(4)系统适配层在协议栈中的位置
R8002的UAL模块的目标是作为联系物理层和上层的纽带(如图26所示),对上层屏蔽物理层的操作,向上层提供提取和设置物理层各项特性的统一的函数调用,并且向物理层提供统一的收包函数以及物理层向上层的状态通知函数调用。
通用适配层位于物理层之上,为所有上层代码对物理层的调用提供通用的调用函数,作用是屏蔽不同的物理层对上层代码的影响,实现上层代码的平台无关性和可移植性。
(5)适配层中的接口映射关系
接口映射关系是整个R8002代码中中很重要的关系。其关系如图27所示:
(6)系统适配层接口设计说明
(6.1)底层API接口定义
系统适配层通用(UAL)API接口包括以下内容:路由表修改、NAT表修改、发送和接收数据包、MPLS转发表目修改、二层桥接表修改、网管信息、接口管理和QoS管理。
本发明可以用于所有支持IPv4、IPv6和IPv4/IPv6的网络设备和芯片,包括并不局限于以下设备:路由器、交换机、移动终端、智能终端、RNC、NODE B、GGSN、SGSN、PDSN、信息家电、二三层交换芯片和网络处理器等。
本发明的使用范围主要在基于Ipv4/v6的路由器类设备、三层以太网交换机类设备、宽带综合接入类设备、具有三层交换、路由功能的多业务传送平台(MSTP)类设备和由弹性分组环(RPR)作为MAC(介质访问控制)所实现的城域网双纤环类设备和无线领域所属的Ipv4/V6设备,也包括由此相关的转发引擎(Network Processor)和三层以太网交换芯片所实现的第一次查找、随后多次转发(按IPv6流标记Flow_Label生成的标识ID)的功能。
本发明不同于传统的逐包(Packet-based)转发的方式,而采用了基于数据流(Stream-based)处理的IP包转发的思想,并且通过设置不同的策略类型实现了在同一个物理管道中同时进行IPv4和IPv6数据的转发。这种方法可以既支持IPv4和IPv6环境下的双栈方式、隧道方式和地址转换方式,也可以用于单纯的IPv4或IPv6的转发。由于采用了策略流方式,本方法避免了采用不同的表结构和复杂的IPv4和IPv6的逐包查找,而是采用同一张表来支持多种应用,通过策略流表中的策略类型来决定采用何种具体的操作,大大简化的设备开发的周期,提高了转发效率(在IPv6情况下可以比普通方式提高5倍以上),有效的实现了在同一个物理管道中的IPv4和IPv6转发的共存。此外,本方法不需引入任何额外的信令,在不改变IETF和IEEE任何标准建议的前提下,实现了转发性能的提高,同时不会影响互联网的互联互通性。最后,本发明可以针对用户的每一个的流进行处理,使得运营商提供增值服务和保证服务质量成为可能。本发明可以用于IPv4向IPv6过渡环境下的IPv4/IPv6双栈节点和纯IPv4或IPv6节点。
尽管参考本发明的优选实施例具体展示和描述了本发明,但是本领域一般技术人员应该明白,在不脱离所附权利要求限定的本发明的精神和范围的情况下,可以对其进行形式和细节上的各种修改。
Claims (20)
1.一种在网络设备中以策略流方式实现数据包转发的方法,所述网络设备至少包括转发平面和控制平面,该方法包括以下步骤:
(a)接收数据流中的数据包,该数据流中包括至少一个数据包;
(b)在转发平面判断目的IP地址的类型;
(c)在转发平面根据不同的目的IP的数据流类型,提取相应的数据包的多元属性组,计算出标识该数据流的本地唯一的策略流标识ID;
(d)转发平面根据本地策略流标识ID精确查找策略流转发表目,如果发现有相匹配的策略流转发表目则进行步骤(e),否则转到步骤(f);
(e)如果发现有相匹配的策略流转发表目,则在转发平面按照所述策略流转发表目对该数据包进行相关内容修改和转发操作,并转到步骤(i);
(f)如果未发现有相匹配的策略流转发表目,则说明这个数据包是数据流的第一个包或者是策略流转发表目已经老化,转发平面将该数据包送到控制平面进行处理;
(g)控制平面在本地根据该数据包的目的IP地址的类型、入端口与应用相关的配置以及该目的IP地址所对应的下一跳的出端口与应用相关的配置中至少一个,对数据包进行相应的处理,并综合控制平面中和各种应用相关的表目信息生成相应的唯一的一条本地策略流转发表目;
(h)控制平面将该策略流转发表目分发到所述转发平面,供后面的数据包使用;
(i)处理下一个数据包。
2.如权利要求1所述的方法,其中目的IP地址的类型可以是IPv4地址、IPv4兼容的IPv6地址或非IPv4兼容的IPv6地址。
3.如权利要求2所述的方法,其中当目的IP地址为IPv4地址时,所述多元属性组至少包括源IPv4地址、目的IPv4地址、源协议端口、目的协议端口、协议类型;当目的IP地址为IPv4兼容的IPv6地址或非IPv4兼容的IPv6地址时,判断数据包头中的IPv6流标记Flow_Label是否为0,如果所述数据包头中的IPv6流标记Flow_Label为0,则所述多元属性组至少包括源IPv6地址、目的IPv6地址、源协议端口、目的协议端口、协议类型,如果所述数据包头中的IPv6流标记Flow_Label不为0,则所述多元属性组至少包括源IPv6地址、IPv6流标记Flow_Label。
4.如权利要求1所述的方法,其中所述策略流转发表目中记录有表明应该对数据流进行何种业务操作类型的策略类型、用来指定该数据包的发送出端口的出端口索引以及下一跳IP地址,所述步骤(e)包括:
(e1)从所述本地策略流转发表目中获知该数据流的策略类型;
(e2)进行相应的转发操作,根据本地策略流转发表目中的出端口索引表项和下一跳IP地址所指向的邻接表表项得出出端口和对应的链路层信息,将该数据包从出端口发出。
5.如权利要求4所述的方法,其中目的IP地址的类型可以是IPv4地址、IPv4兼容的IPv6地址或非IPv4兼容的IPv6地址,并且其中步骤(e2)包括:
当目的IP地址为IPv4地址时,如果策略类型为纯IPv4转发IPv4_FORWARD,则执行IPv4的转发操作,修改TTL,并重新计算校验和;如果策略类型为IPv4 in IPv6的自动隧道模式IPv4_IN_IPv6_AUTO,则执行IPv4 to IPv6的自动隧道操作,根据本地策略流转发表目中的隧道ID封装数据包,隧道的目的IPv6地址为目的IPv4地址对应的IPv6兼容地址;如果策略类型为IPv4 in IPv6的手工隧道模式IPv4_IN_IPv6_MANU,则执行IPv4 toIPv6的手工隧道操作,根据本地策略流转发表目中的隧道ID封装数据包,隧道的目的IPv6地址为本地策略流转发表目中的地址;如果策略类型为网络地址转换NAT_PT,则执行NAT-PT操作,根据策略流转发表目中的伪IP地址和伪端口,对数据包的内容进行修改;
当目的IP地址为IPv4兼容的IPv6地址时,如果策略类型为纯IPv6转发IPv6_FORWARD,则执行IPv6的转发操作,修改TTL;如果策略类型为IPv6 in IPv4的自动隧道模式IPv6_IN_IPv4_AUTO,则执行IPv6 to IPv4的自动隧道操作,根据本地策略流转发表目中的隧道ID封装数据包,隧道的目的IPv4地址为IPv4兼容的IPv6地址所对应的IPv4地址;如果策略类型为网络地址转换NAT_PT,则执行NAT-PT操作,根据本地策略流转发表目中的伪IP地址和伪端口,对数据包的内容进行修改;
当目的IP地址为非IPv4兼容的IPv6地址时,如果策略类型为纯IPv6转发IPv6_FORWARD,则执行IPv6的转发操作,修改TTL;如果策略类型为IPv6 in IPv4的手动隧道模式IPv6_IN_IPv4_MANU,则执行IPv6 to IPv4的隧道操作,根据本地策略流转发表目中的隧道ID封装数据包,隧道的目的IPv4地址为IPv4兼容的IPv6地址所对应的IPv4地址。
6.如权利要求2所述的方法,其中所述步骤(g)中对数据包进行相应的处理包括:
(g1)确定应对该数据包所在的数据流进行何种业务操作的策略类型;以及
(g2)将有关策略类型的信息发送回转发平面,以便由转发平面根据所确定的策略类型处理数据包。
7.如权利要求6所述的方法,其中,
(A)当目的IP地址为IPv4地址时,
(ga1)首先判断入端口是否使能了NAT-PT且目的IPv4地址是否为地址池内的地址,如果没有则转向步骤(ga2),否则转向步骤(ga4);
(ga2)进行IPv4相关的转发信息查找转发表,判断下一跳的接口类型,如果为IPv4,则在转发平面完成IPv4转发,否则进行步骤(ga3);
(ga3)如果下一跳对应的接口为IPv6,在转发平面进行IPv4 in IPv6的隧道操作,其中目的地址可以为该IPv4地址对应的IPv4兼容的IPv6地址也可以为手工配置的隧道地址;
(ga4)在转发平面进行NAT-PT操作,将IPv4包转换为IPv6的包;
(B)当目的IP地址为IPv4兼容的IPv6地址时,
(gb1)首先判断入端口是否使能了NAT-PT而且目的地址是否为地址池内的地址,如果没有则转向步骤(gb2),否则转向步骤(gb5);
(gb2)进行IPv6相关的转发信息查找转发表,判断下一跳的出接口类型,如果为IPv6,则在转发平面进行IPv6转发,否则进行步骤(gb3);
(gb3)如果下一跳的类型为IPv4,则首先判断出端口是否使能了NAT-PT,如果有NAT-PT操作的标识则进行步骤(gb5),否则进行步骤(gb4);
(gb4)在转发平面进行IPv6 in IPv4操作,其中源地址为NAT地址池内的地址,而转换后的目的IP地址为原有IPv6目的地址的低32位;
(gb5)在转发平面进行NAT-PT操作,其中转换后的目的IP地址为原有IPv6目的地址的低32位;
(C)当目的IP地址为非IPv4兼容的IPv6地址时,
(gc1)根据IPv6相关的转发信息查找转发表,并判断下一跳所对应的接口类型,如果为IPv6,则在转发平面进行IPv6转发;
(gc2)否则为IPv4,则需要在转发平面进行IPv6 in IPv4的隧道操作,其中IPv4的目的地址为配置的隧道的IPv4地址。
8.如权利要求7所述的方法,其中,
如果对数据包进行IPv4转发时,策略类型为IPv4_FORWARD,生成的本地策略流转发表目的内容至少包括策略类型、策略流ID、出端口索引、下一跳IPv6地址;
如果对数据包进行IPv6转发时,策略类型为IPv6_FORWARD,生成的本地策略流转发表目的内容至少包括策略类型、策略流ID、出端口索引、下一跳IPv6地址;
如果对数据包进行网络地址/协议地址转换,则策略类型为NAT_PT,生成的策略流转发表目的内容至少包括策略类型、策略流ID、Alias IPv6Address、Source IPv4 Address、Destination IPv4 Address、Source Port、Destination Port、Alias Port、Protocol Type等,出端口索引和下一跳IPv6地址等;
如果对数据包进行自动的IPv4 in IPv6隧道操作,则策略类型为IPv4_IN_IPv6_AUTO,生成的本地策略流转发表目的内容包括策略类型、策略流ID、出端口索引、下一跳IPv6地址、隧道ID;
如果对数据包进行手工配置的IPv4 in IPv6隧道操作,则策略类型为IPv4_IN_IPv6_MANU,生成的本地策略流转发表目的内容包括策略类型、策略流ID、出端口索引、下一跳IPv6地址、隧道ID以及隧道的终点地址;
如果对数据包进行IPv6 in IPv4自动隧道操作,则策略类型为IPv6_IN_IPv4_AUTO,生成的本地策略流转发表目的内容包括策略类型、策略流ID、出端口索引和隧道ID;
如果对数据包进行IPv6 in IPv4手工隧道操作,则策略类型为IPv6_IN_IPv4_MANU,生成的策略流转发表目的内容包括策略类型、策略流ID、出端口索引和隧道ID。
9.如权利要求1所述的方法,其中所述策略流转发表目中记录有表明该策略流转发表目是否超时的超时标识,每当该策略流转发表目被匹配的数据包使用一次即刷新该超时标识,所述控制平面每隔一定时间去检查该标识,如果该标识在一定时间内没有被刷新,说明该策略流转发表目已经老化,则删除该策略流转发表目。
10.如权利要求1所述的方法,其中所述策略流转发表目中记录有:
Source IPv4 Address(4字节):数据流的源IPv4地址;
Destination IPv4 Address(4字节):数据流的目的IPv4地址;
Source IPv6 Address(16字节):数据流的源IPv6地址;
Destination IPv6 Address;(16字节):数据流的目的IPv6地址;
Protocol Type(2字节):协议类型;
Source Protocol Port(2字节):源协议端口,由协议类型来决定为何种协议的端口;
Destination Protocol Port(2字节):目的协议端口,由协议类型来决定为何种协议的端口;
Flow Label(2字节):IPv6中的流标记Flow_Label;
Stream ID(4字节):表示一个流的唯一的ID;
Alias Port(2字节):伪端口,转换后的协议端口,用于网络地址转换;
Alias IPv4 Address(4字节):伪IP地址,转换后的IPv4地址,用于网络地址转换;
Alias IPv6 Address:(16字节):伪IPv6地址,转换后的IPv6地址,用于网络地址转换;
Tunnel ID(2字节):隧道ID,用于IPv6 to IPv4或IPv4 to IPv6隧道;
Policy Type(2字节):策略类型,表明对数据流该进行的何种业务操作类型,可由网管灵活配置或用户进行业务定制;
QoS(2字节):服务质量,表明对该数据流的服务质量参数;
Expired Timer(1字节):超时定时器,判断该数据流转发表目是否超时;
TCP Flag(1字节):TCP标志位,用来判断TCP流是否结束;
Output Port Index(2字节):出端口索引,用来指定该数据包的发送出端口;
Next Hop IPv4 Address(4字节):下一跳IPv4地址;
Next Hop IPv6 Address(16字节):下一跳IPv6地址;
Tunnel end IPv4 Address(4字节):隧道终点IPv4地址,和伪IPv4地址复用;以及
Tunnel end IPv6 Addddress(16字节):隧道终点IPv6地址,和伪IPv6地址复用。
11.一种以策略流方式转发数据的数据转发设备,其中包括至少一转发平面和一控制平面,其中每个转发平面接收数据流中的数据包,该数据流中包括至少一个数据包,该数据转发设备包括:
本地策略流转发表目存储部分,用于存储本地策略流转发表目,
其中,所述转发平面包括:
目的IP地址类型判断部分,用于判断目的IP地址的数据流类型;
本地策略流ID计算单元,用于根据不同的目的IP的类型,选择相应的数据包的多元属性组,来计算出标识该数据流的本地策略流标识ID;
查找单元,用于根据本地策略流ID精确查找所述本地策略流转发表目存储部分中存储的本地策略流转发表目,看是否有与该数据包的本地策略流ID相匹配的策略流转发表目;
修改和转发单元,如果在查找单元发现匹配的策略流转发表目,则按照所述策略流转发表目对该数据包进行相关内容修改和转发操作;如在查找单元未发现匹配的策略流转发表目,则将该数据包送到控制平面,
所述控制平面包括:
策略处理单元,根据目的IP地址的类型、入端口的配置以及该目的IP地址所对应的下一跳的出端口的配置中至少一个,对数据包进行相应的处理;
策略流转发表目生成单元,根据对数据包进行的处理生成相应的策略流转发表目,并将该策略流转发表目分发到所述策略流转发表目存储单元,供后面的数据包使用。
12.如权利要求11所述的数据转发设备,其中目的IP地址的类型可以是IPv4地址、IPv4兼容的IPv6地址或非IPv4兼容的IPv6地址。
13.如权利要求12所述的数据转发设备,其中所述策略流ID计算单元包括:
第一计算部分,用于在目的IP地址为IPv4地址时,根据由至少源IPv4地址、目的IPv4地址、源协议端口、目的协议端口、协议类型组成的五元属性组计算所述策略流ID;
IPv6流标记Flow_Label检测单元,用于在目的IP地址为IPv4兼容的IPv6地址或非IPv4兼容的IPv6地址时,判断数据包头中的IPv6流标记Flow_Label是否为0;
第二计算部分,用于在判断出所述IPv6流标记Flow_Label为0时,根据由至少源IPv6地址、目的IPv6地址、源协议端口、目的协议端口、协议类型组成的五元属性组计算所述策略流ID;以及
第三计算部分,用于在判断出所述IPv6流标记Flow_Label为0时,根据由至少源IPv6地址、IPv6流标记Flow_Label组成的二元属性组计算所述策略流ID。
14.如权利要求11所述的数据转发设备,其中所述策略流转发表目存储单元中存储的策略流转发表目中记录有表明对数据流进行何种业务操作类型的策略类型、用来指定该数据包的发送出端口的出端口索引以及下一跳IP地址,并且所述修改和转发单元包括:
策略类型获取部分,用于从与所述数据包匹配的策略流转发表目中获取对应于该数据流的策略类型;以及
分类转发单元,根据对应于该数据流的策略类型对数据包根据进行相应的转发操作,根据策略流转发表目中的出端口索引表项和下一跳IP地址所指向的邻接表表项得出出端口和对应的链路层信息,将该数据包从出端口发出。
15.如权利要求14所述的数据转发设备,其中目的IP地址的类型可以是IPv4地址、IPv4兼容的IPv6地址或非IPv4兼容的IPv6地址,并且所述分类转发单元包括:
IPv4转发操作单元,当策略类型为纯IPv4转发IPv4_FORWARD时,执行IPv4的转发操作,修改TTL,并重新计算校验和;
IPv6转发操作单元,当策略类型为纯IPv6转发IPv6_FORWARD时,执行IPv6的转发操作,修改TTL;
NAT-PT操作单元,当策略类型为网络地址转换NAT_PT时,执行NAT-PT操作,根据本地策略流转发表目中的伪IP地址和伪端口,对数据包的内容进行修改;
IPv4 to IPv6自动隧道操作单元,当策略类型为IPv4 in IPv6的自动隧道模式IPv4_IN_IPv6_AUTO时,执行IPv4 to IPv6的自动隧道操作,根据本地策略流转发表目中的隧道ID封装数据包,隧道的目的IPv6地址为目的IPv4地址对应的IPv6兼容地址;
IPv4 to IPv6手工隧道操作单元,当策略类型为IPv4 in IPv6的手工隧道模式IPv4_IN_IPv6_MANU时,执行IPv4 to IPv6的手工隧道操作,根据本地策略流转发表目中的隧道ID封装数据包,隧道的目的IPv6地址为策略流转发表目中的地址;
IPv6 to IPv4自动隧道操作单元,当策略类型为IPv6 in IPv4的自动隧道模式IPv6_IN_IPv4_AUTO时,执行IPv6 to IPv4的自动隧道操作,根据本地策略流转发表目中的隧道ID封装数据包,隧道的目的IPv4地址为IPv4兼容的IPv6地址所对应的IPv4地址;以及
IPv6 to IPv4手工隧道操作单元,当策略类型为IPv6 in IPv4的手动隧道模式IPv6_IN_IPv4_MANU时,执行IPv6 to IPv4的隧道操作,根据本地策略流转发表目中的隧道ID封装数据包,隧道的目的IPv4地址为IPv4兼容的IPv6地址所对应的IPv4地址。
16.如权利要求15所述的数据转发设备,其中所述策略处理单元包括:
策略类型确定单元,用于确定应对该数据包所在的数据流进行何种业务操作的策略类型;以及
策略类型信息返回单元,用于将有关策略类型的信息发送回转发平面,从而由转发平面的分类转发单元中对应于该策略类型的操作部分对数据包进行转发操作。
17.如权利要求15所述的数据转发设备,其中所述策略类型确定单元包括:
第一判断部分,用于判断入端口是否使能了NAT-PT;
第二判断部分,用于判断目的IPv4地址是否为地址池内地址;
转发信息查找单元,用于查找转发表,判断下一跳的接口类型,
其中,当目的IP地址为IPv4地址时,首先由第一判断部分判断入端口是否使能了NAT-PT,并由第二判断部分判断目的IPv4地址是否为地址池内地址,如果至少一项判断结果为是,则确定应在转发平面进行NAT-PT操作,将IPv4包转换为IPv6的包;如果判断结果都为否,则由转发信息查找单元进行IPv4相关的转发信息查找转发表,判断下一跳的接口类型,如果下一跳的接口类型为IPv4,则确定应在转发平面完成IPv4转发,如果下一跳对应的接口为IPv6,则确定应在转发平面进行IPv4 in IPv6的隧道操作,其中目的地址可以为该IPv4地址对应的IPv4兼容的IPv6地址也可以为手工配置的隧道地址,
当目的IP地址为IPv4兼容的IPv6地址时,首先由第一判断部分判断入端口是否使能了NAT-PT,并由第二判断部分判断目的IPv4地址是否为地址池内地址,如果至少一项判断结果为是,则确定应在转发平面进行NAT-PT操作,其中转换后的目的IP地址为原有IPv6目的地址的低32位;如果判断结果都为否,则由转发信息查找单元进行IPv6相关的转发信息查找转发表,判断下一跳的出接口类型,如果为IPv6,则确定应在转发平面进行IPv6转发,如果下一跳的类型为IPv4,则首先由第一判断部分判断出端口是否使能了NAT-PT,如果有则确定应在转发平面进行NAT-PT操作,其中源地址为地址池内的地址,而目的地址为原有IPv6目的地址的低32位进行步骤(gb4),否则确定应在转发平面进行IPv6 in IPv4操作,其中目的地址为原有IPv6目的地址的低32位;
当目的IP地址为非IPv4兼容的IPv6地址时,由转发信息查找单元根据IPv6相关的转发信息查找转发表,并判断下一跳所对应的接口类型,如果为IPv6,则确定应在转发平面进行IPv6转发;否则为IPv4,则应在转发平面进行IPv6 in IPv4的隧道操作,其中IPv4的目的地址为配置的隧道的IPv4地址。
18.如权利要求17所述的数据转发设备,其中所述本地策略流转发表目生成单元包括:
第一表目生成部分,在对数据包进行IPv4转发时,策略类型为IPv4_FORWARD,生成的本地策略流转发表目的内容至少包括策略类型、流ID、出端口索引、下一跳IPv6地址;
第二表目生成部分,在对数据包进行IPv6转发时,策略类型为IPv6_FORWARD,生成的本地策略流转发表目的内容至少包括策略类型、流ID、出端口索引、下一跳IPv6地址;
第三表目生成部分,在对数据包进行网络地址/协议地址转换时,策略类型为NAT_PT,生成的本地策略流转发表目的内容至少包括策略类型、流ID、Alias IPv6 Address、Source IPv4 Address、Destination IPv4 Address、SourcePort、Destination Port、Alias Port、Protocol Type等,出端口索引和下一跳IPv6地址等;
第四表目生成部分,在对数据包进行自动的IPv4 in IPv6隧道操作时,策略类型为IPv4_IN_IPv6_AUTO,生成的本地策略流转发表目的内容至少包括策略类型、流ID、出端口索引、下一跳IPv6地址、隧道ID;
第五表目生成部分,在对数据包进行手工配置的IPv4 in IPv6隧道操作时,策略类型为IPv4_IN_IPv6_MANU,生成的本地策略流转发表目的内容至少包括策略类型、流ID、出端口索引、下一跳IPv6地址、隧道ID以及隧道的终点地址;
第六表目生成部分,在对数据包进行IPv6 in IPv4自动隧道操作时,策略类型为IPv6_IN_IPv4_AUTO,生成的本地策略流转发表目的内容至少包括策略类型、流ID、出端口索引和隧道ID;
第七表目生成部分,在对数据包进行IPv6 in IPv4手工隧道操作时,策略类型为IPv6_IN_IPv4_MANU,生成的本地策略流转发表目的内容至少包括策略类型、流ID、出端口索引和隧道ID。
19.如权利要求11所述的数据转发设备,其中所述本地策略流转发表目存储单元中存储的本地策略流转发表目中记录有表明该策略流转发表目是否超时的超时标识,每当该本地策略流转发表目被匹配的数据包使用一次即刷新该超时标识,所述控制平面每隔一定时间去检查该标识,如果该标识在一定时间内没有被刷新,说明该本地策略流转发表目已经老化,则删除该策略流转发表目。
20.如权利要求11所述的数据转发设备,其中所述本地策略流转发表目存储单元中存储的本地策略流转发表目中记录有:
Source IPv4 Address(4字节):数据流的源IPv4地址;
Destination IPv4 Address(4字节):数据流的目的IPv4地址;
Source IPv6 Address(16字节):数据流的源IPv6地址;
Destination IPv6 Address:(16字节):数据流的目的IPv6地址;
Protocol Type(2字节):协议类型;
Source Protocol Port(2字节):源协议端口,由协议类型来决定为何种协议的端口;
Destination Protocol Port(2字节):目的协议端口,由协议类型来决定为何种协议的端口;
Flow Label(2字节):IPv6中的流标记Flow_label;
Stream ID(4字节):表示一个流的唯一的ID;
Alias Port(2字节):伪端口,转换后的协议端口,用于网络地址转换;
Alias IPv4 Address(4字节):伪IP地址,转换后的IPv4地址,用于网络地址转换;
Alias IPv6 Address:(16字节):伪IPv6地址,转换后的IPv6地址,用于网络地址转换;
Tunnel ID(2字节):隧道ID,用于IPv6 to IPv4或IPv4 to IPv6隧道;
Policy Type(2字节):策略类型,表明对数据流该进行的何种业务操作类型,可由网管灵活配置或用户进行业务定制;
QoS(2字节):服务质量,表明对该数据流的服务质量参数;
Expired Timer(1字节):超时定时器,判断该数据流转发表目是否超时;
TCP Flag(1字节):TCP标志位,用来判断TCP流是否结束;
Output Port Index(2字节):出端口索引,用来指定该数据包的发送出端口;
Next Hop IPv4 Address(4字节):下一跳IPv4地址;
Next Hop IPv6 Address(16字节):下一跳IPv6地址;
Tunnel end IPv4 Address(4字节):隧道终点IPv4地址,和伪IPv4地址复用;以及
Tunnel end IPv6 Addddress(16字节):隧道终点IPv6地址,和伪IPv6地址复用。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2003101017904A CN100409646C (zh) | 2003-10-28 | 2003-10-28 | 用策略流实现不同因特网协议数据包转发的方法和设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2003101017904A CN100409646C (zh) | 2003-10-28 | 2003-10-28 | 用策略流实现不同因特网协议数据包转发的方法和设备 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN1612562A true CN1612562A (zh) | 2005-05-04 |
CN100409646C CN100409646C (zh) | 2008-08-06 |
Family
ID=34756249
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNB2003101017904A Expired - Fee Related CN100409646C (zh) | 2003-10-28 | 2003-10-28 | 用策略流实现不同因特网协议数据包转发的方法和设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN100409646C (zh) |
Cited By (43)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2007147340A1 (fr) * | 2006-06-16 | 2007-12-27 | Huawei Technologies Co., Ltd. | Procédé, système et dispositif de la technique ethernet d'échange et de transfert |
WO2009021424A1 (en) * | 2007-08-13 | 2009-02-19 | Hangzhou H3C Technologies Co., Ltd. | A device and method for handling messages |
WO2009043239A1 (fr) * | 2007-09-29 | 2009-04-09 | Huawei Technologies Co., Ltd. | Procédé et dispositif de relais de flux vers l'avant |
CN101304383B (zh) * | 2008-07-07 | 2010-10-27 | 杭州华三通信技术有限公司 | 交换网报文交换方法和交换系统 |
CN101938452A (zh) * | 2009-07-01 | 2011-01-05 | 大唐移动通信设备有限公司 | 一种通信装置 |
CN101969698A (zh) * | 2010-10-25 | 2011-02-09 | 中山大学 | 一种移动ip应用层网关的移动ip表的设立和使用的方法 |
CN101325597B (zh) * | 2008-07-30 | 2011-04-06 | 北京星网锐捷网络技术有限公司 | 一种数据处理的方法、装置及系统 |
CN102025644A (zh) * | 2010-12-31 | 2011-04-20 | 华为技术有限公司 | 一种负载分担方法及设备 |
CN102036334A (zh) * | 2009-09-30 | 2011-04-27 | 北京中能普瑞技术有限公司 | 矿井用无线传感器网络的路由控制方法 |
CN101155196B (zh) * | 2006-09-27 | 2011-05-11 | 中国电信股份有限公司 | 面向业务的IPv6地址分类与分配方法及实现该方法的终端和系统 |
CN101335689B (zh) * | 2007-06-26 | 2011-11-02 | 华为技术有限公司 | 跟踪路由的实现方法及设备 |
CN101582851B (zh) * | 2009-06-12 | 2011-11-30 | 中兴通讯股份有限公司 | 一种实现双栈路由器上共享路由容量的方法和系统 |
CN101273590B (zh) * | 2005-12-29 | 2012-01-18 | 中兴通讯股份有限公司 | 报文快速转发方法和系统 |
CN102377654A (zh) * | 2010-08-17 | 2012-03-14 | 国基电子(上海)有限公司 | 路由器及在IPv4路由器上实现IPv6报文穿越的方法 |
CN102420772A (zh) * | 2011-12-31 | 2012-04-18 | 杭州华三通信技术有限公司 | 隧道报文收发方法和装置 |
CN102497385A (zh) * | 2011-12-31 | 2012-06-13 | 曙光信息产业股份有限公司 | 一种网络流量审计方法及审计系统 |
CN101322341B (zh) * | 2005-11-30 | 2012-06-20 | 思科技术公司 | 提供边界网关协议转发信息库的优先级区分式递归解析的方法和装置 |
CN102546405A (zh) * | 2011-12-27 | 2012-07-04 | 华为技术有限公司 | 协议栈的业务处理方法及装置 |
CN102594680A (zh) * | 2012-02-15 | 2012-07-18 | 迈普通信技术股份有限公司 | 一种报文分段处理系统及处理方法 |
US8295279B2 (en) | 2008-12-02 | 2012-10-23 | Electronics And Telecommunications Research Institute | Routing method and apparatus for providing different path by service |
CN102760114A (zh) * | 2011-04-29 | 2012-10-31 | 无锡江南计算技术研究所 | 多处理器系统的通信仿真方法、引擎及系统 |
CN103179031A (zh) * | 2011-12-23 | 2013-06-26 | 上海博达数据通信有限公司 | 基于流方式的多业务转发和处理方法 |
CN103414594A (zh) * | 2013-08-23 | 2013-11-27 | 烽火通信科技股份有限公司 | 一种用于计费和监控的ip流信息统计方法 |
CN103460675A (zh) * | 2013-01-14 | 2013-12-18 | 华为技术有限公司 | 集群以及转发方法 |
CN103716253A (zh) * | 2013-12-27 | 2014-04-09 | 广州华多网络科技有限公司 | 一种请求数据的方法及装置 |
WO2014067486A1 (zh) * | 2012-11-05 | 2014-05-08 | 华为技术有限公司 | 一种报文转发的方法及相应设备 |
CN101904136B (zh) * | 2007-12-21 | 2014-05-28 | 微软公司 | 提供用于分布式路由表的安全模式的方法和系统 |
WO2015081551A1 (zh) * | 2013-12-06 | 2015-06-11 | 华为技术有限公司 | 一种网络中实现报文路由的方法、设备和系统 |
CN104735073A (zh) * | 2015-03-30 | 2015-06-24 | 广州杰赛科技股份有限公司 | IPv4-IPv6过渡协议调度方法和装置 |
CN104954288A (zh) * | 2014-03-28 | 2015-09-30 | 华为技术有限公司 | 信息发送方法、装置及通信系统 |
CN105072038A (zh) * | 2015-08-28 | 2015-11-18 | 深圳市华讯方舟科技有限公司 | 一种数据报文转发方法及装置 |
WO2016023148A1 (zh) * | 2014-08-11 | 2016-02-18 | 华为技术有限公司 | 报文的控制方法、交换机及控制器 |
CN105391704A (zh) * | 2015-10-29 | 2016-03-09 | 国网智能电网研究院 | 一种基于业务类型的配置端口隔离交换设备及应用方法 |
CN106657436A (zh) * | 2016-11-29 | 2017-05-10 | 杭州迪普科技股份有限公司 | 报文处理方法和装置 |
CN107888521A (zh) * | 2017-10-20 | 2018-04-06 | 深圳市楠菲微电子有限公司 | 多协议共享表项资源池的方法和装置 |
CN109361782A (zh) * | 2018-11-02 | 2019-02-19 | 迈普通信技术股份有限公司 | 一种报文转发方法及网络设备 |
CN111147519A (zh) * | 2019-12-31 | 2020-05-12 | 奇安信科技集团股份有限公司 | 数据检测方法、装置、电子设备和介质 |
CN111385212A (zh) * | 2018-12-29 | 2020-07-07 | 华为技术有限公司 | 数据传输技术及神经网络系统 |
CN111711679A (zh) * | 2020-06-09 | 2020-09-25 | 宏图智能物流股份有限公司 | 一种仓库网络统一管理平台方法 |
CN112003792A (zh) * | 2020-07-23 | 2020-11-27 | 烽火通信科技股份有限公司 | 一种软硬件协同的报文加速方法和装置 |
CN112422695A (zh) * | 2020-12-07 | 2021-02-26 | 重庆忽米网络科技有限公司 | 一种支持多协议多规则的工业设备数据转发方法 |
CN112559246A (zh) * | 2020-12-10 | 2021-03-26 | 盛科网络(苏州)有限公司 | 一种交换机热备份平滑阶段的数据比较方法及装置 |
CN115086233A (zh) * | 2022-08-17 | 2022-09-20 | 北京左江科技股份有限公司 | 一种基于fpga的网络报文关键信息提取转发的方法 |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11886325B2 (en) * | 2022-06-30 | 2024-01-30 | Browserstack Limited | Network status simulation for remote device infrastructure |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1773013B1 (en) * | 1996-11-01 | 2013-05-22 | Hitachi, Ltd. | Communicating method between IPv4 terminal and IPv6 terminal and IPv4-IPv6 converting apparatus |
WO2002045375A2 (en) * | 2000-12-01 | 2002-06-06 | Nortel Networks Limited | Auto-tunnelling in a heterogenous network |
-
2003
- 2003-10-28 CN CNB2003101017904A patent/CN100409646C/zh not_active Expired - Fee Related
Cited By (72)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101322341B (zh) * | 2005-11-30 | 2012-06-20 | 思科技术公司 | 提供边界网关协议转发信息库的优先级区分式递归解析的方法和装置 |
CN101273590B (zh) * | 2005-12-29 | 2012-01-18 | 中兴通讯股份有限公司 | 报文快速转发方法和系统 |
US8072984B2 (en) | 2006-06-16 | 2011-12-06 | Huawei Technologies Co., Ltd. | Ethernet switching and forwarding method, system and apparatus |
CN100461732C (zh) * | 2006-06-16 | 2009-02-11 | 华为技术有限公司 | 一种以太技术交换和转发的方法、系统和设备 |
WO2007147340A1 (fr) * | 2006-06-16 | 2007-12-27 | Huawei Technologies Co., Ltd. | Procédé, système et dispositif de la technique ethernet d'échange et de transfert |
CN101155196B (zh) * | 2006-09-27 | 2011-05-11 | 中国电信股份有限公司 | 面向业务的IPv6地址分类与分配方法及实现该方法的终端和系统 |
CN101335689B (zh) * | 2007-06-26 | 2011-11-02 | 华为技术有限公司 | 跟踪路由的实现方法及设备 |
WO2009021424A1 (en) * | 2007-08-13 | 2009-02-19 | Hangzhou H3C Technologies Co., Ltd. | A device and method for handling messages |
US8908689B2 (en) | 2007-08-13 | 2014-12-09 | Hangzhou H3C Technologies Co., Ltd. | Apparatus and method for processing packet |
WO2009043239A1 (fr) * | 2007-09-29 | 2009-04-09 | Huawei Technologies Co., Ltd. | Procédé et dispositif de relais de flux vers l'avant |
CN101904136B (zh) * | 2007-12-21 | 2014-05-28 | 微软公司 | 提供用于分布式路由表的安全模式的方法和系统 |
CN101304383B (zh) * | 2008-07-07 | 2010-10-27 | 杭州华三通信技术有限公司 | 交换网报文交换方法和交换系统 |
CN101325597B (zh) * | 2008-07-30 | 2011-04-06 | 北京星网锐捷网络技术有限公司 | 一种数据处理的方法、装置及系统 |
US8295279B2 (en) | 2008-12-02 | 2012-10-23 | Electronics And Telecommunications Research Institute | Routing method and apparatus for providing different path by service |
CN101582851B (zh) * | 2009-06-12 | 2011-11-30 | 中兴通讯股份有限公司 | 一种实现双栈路由器上共享路由容量的方法和系统 |
CN101938452A (zh) * | 2009-07-01 | 2011-01-05 | 大唐移动通信设备有限公司 | 一种通信装置 |
CN101938452B (zh) * | 2009-07-01 | 2013-01-09 | 大唐移动通信设备有限公司 | 一种通信装置 |
CN102036334A (zh) * | 2009-09-30 | 2011-04-27 | 北京中能普瑞技术有限公司 | 矿井用无线传感器网络的路由控制方法 |
CN102377654A (zh) * | 2010-08-17 | 2012-03-14 | 国基电子(上海)有限公司 | 路由器及在IPv4路由器上实现IPv6报文穿越的方法 |
CN102377654B (zh) * | 2010-08-17 | 2014-06-18 | 国基电子(上海)有限公司 | 路由器及在IPv4路由器上实现IPv6报文穿越的方法 |
CN101969698B (zh) * | 2010-10-25 | 2014-02-12 | 中山大学 | 一种移动ip应用层网关的移动ip表的设立和使用的方法 |
CN101969698A (zh) * | 2010-10-25 | 2011-02-09 | 中山大学 | 一种移动ip应用层网关的移动ip表的设立和使用的方法 |
CN102025644B (zh) * | 2010-12-31 | 2012-10-17 | 华为技术有限公司 | 一种负载分担方法及设备 |
CN102025644A (zh) * | 2010-12-31 | 2011-04-20 | 华为技术有限公司 | 一种负载分担方法及设备 |
CN102760114A (zh) * | 2011-04-29 | 2012-10-31 | 无锡江南计算技术研究所 | 多处理器系统的通信仿真方法、引擎及系统 |
CN102760114B (zh) * | 2011-04-29 | 2015-07-08 | 无锡江南计算技术研究所 | 多处理器系统的通信仿真方法、引擎及系统 |
CN103179031A (zh) * | 2011-12-23 | 2013-06-26 | 上海博达数据通信有限公司 | 基于流方式的多业务转发和处理方法 |
CN103179031B (zh) * | 2011-12-23 | 2016-05-11 | 上海博达数据通信有限公司 | 基于流方式的多业务转发和处理方法 |
CN102546405B (zh) * | 2011-12-27 | 2015-05-13 | 华为技术有限公司 | 协议栈的业务处理方法及装置 |
CN102546405A (zh) * | 2011-12-27 | 2012-07-04 | 华为技术有限公司 | 协议栈的业务处理方法及装置 |
CN102497385B (zh) * | 2011-12-31 | 2015-09-16 | 曙光信息产业股份有限公司 | 一种网络流量审计方法及审计系统 |
CN102420772B (zh) * | 2011-12-31 | 2014-05-14 | 杭州华三通信技术有限公司 | 隧道报文收发方法和装置 |
CN102420772A (zh) * | 2011-12-31 | 2012-04-18 | 杭州华三通信技术有限公司 | 隧道报文收发方法和装置 |
CN102497385A (zh) * | 2011-12-31 | 2012-06-13 | 曙光信息产业股份有限公司 | 一种网络流量审计方法及审计系统 |
CN102594680A (zh) * | 2012-02-15 | 2012-07-18 | 迈普通信技术股份有限公司 | 一种报文分段处理系统及处理方法 |
CN102594680B (zh) * | 2012-02-15 | 2015-06-17 | 迈普通信技术股份有限公司 | 一种报文分段处理方法 |
WO2014067486A1 (zh) * | 2012-11-05 | 2014-05-08 | 华为技术有限公司 | 一种报文转发的方法及相应设备 |
CN103460675A (zh) * | 2013-01-14 | 2013-12-18 | 华为技术有限公司 | 集群以及转发方法 |
US9847929B2 (en) | 2013-01-14 | 2017-12-19 | Huawei Technologies Co., Ltd. | Cluster and forwarding method |
WO2014107905A1 (zh) * | 2013-01-14 | 2014-07-17 | 华为技术有限公司 | 集群以及转发方法 |
CN103460675B (zh) * | 2013-01-14 | 2016-09-28 | 华为技术有限公司 | 集群以及转发方法 |
CN103414594A (zh) * | 2013-08-23 | 2013-11-27 | 烽火通信科技股份有限公司 | 一种用于计费和监控的ip流信息统计方法 |
US9614754B2 (en) | 2013-12-06 | 2017-04-04 | Huawei Technologies Co., Ltd | Method, device, and system for packet routing in a network |
WO2015081551A1 (zh) * | 2013-12-06 | 2015-06-11 | 华为技术有限公司 | 一种网络中实现报文路由的方法、设备和系统 |
US9860170B2 (en) | 2013-12-06 | 2018-01-02 | Huawei Technologies Co., Ltd. | Method, device, and system for packet routing in a network |
CN103716253A (zh) * | 2013-12-27 | 2014-04-09 | 广州华多网络科技有限公司 | 一种请求数据的方法及装置 |
US9973352B2 (en) | 2014-03-28 | 2018-05-15 | Huawei Technologies Co., Ltd. | Information sending method, apparatus, and communications system |
WO2015144018A1 (zh) * | 2014-03-28 | 2015-10-01 | 华为技术有限公司 | 信息发送方法、装置及通信系统 |
CN104954288A (zh) * | 2014-03-28 | 2015-09-30 | 华为技术有限公司 | 信息发送方法、装置及通信系统 |
US10305783B2 (en) | 2014-08-11 | 2019-05-28 | Huawei Technologies Co., Ltd. | Packet control method, switch, and controller |
CN105684382A (zh) * | 2014-08-11 | 2016-06-15 | 华为技术有限公司 | 报文的控制方法、交换机及控制器 |
WO2016023148A1 (zh) * | 2014-08-11 | 2016-02-18 | 华为技术有限公司 | 报文的控制方法、交换机及控制器 |
CN104735073A (zh) * | 2015-03-30 | 2015-06-24 | 广州杰赛科技股份有限公司 | IPv4-IPv6过渡协议调度方法和装置 |
WO2017036267A1 (zh) * | 2015-08-28 | 2017-03-09 | 华讯方舟科技有限公司 | 一种数据报文转发方法及装置 |
CN105072038A (zh) * | 2015-08-28 | 2015-11-18 | 深圳市华讯方舟科技有限公司 | 一种数据报文转发方法及装置 |
CN105072038B (zh) * | 2015-08-28 | 2018-12-21 | 华讯方舟科技有限公司 | 一种数据报文转发方法及装置 |
CN105391704A (zh) * | 2015-10-29 | 2016-03-09 | 国网智能电网研究院 | 一种基于业务类型的配置端口隔离交换设备及应用方法 |
CN106657436A (zh) * | 2016-11-29 | 2017-05-10 | 杭州迪普科技股份有限公司 | 报文处理方法和装置 |
CN106657436B (zh) * | 2016-11-29 | 2019-07-09 | 杭州迪普科技股份有限公司 | 报文处理方法和装置 |
CN107888521A (zh) * | 2017-10-20 | 2018-04-06 | 深圳市楠菲微电子有限公司 | 多协议共享表项资源池的方法和装置 |
CN107888521B (zh) * | 2017-10-20 | 2021-01-01 | 深圳市楠菲微电子有限公司 | 多协议共享表项资源池的方法和装置 |
CN109361782A (zh) * | 2018-11-02 | 2019-02-19 | 迈普通信技术股份有限公司 | 一种报文转发方法及网络设备 |
CN111385212A (zh) * | 2018-12-29 | 2020-07-07 | 华为技术有限公司 | 数据传输技术及神经网络系统 |
CN111385212B (zh) * | 2018-12-29 | 2021-08-31 | 华为技术有限公司 | 数据传输技术及神经网络系统 |
CN111147519A (zh) * | 2019-12-31 | 2020-05-12 | 奇安信科技集团股份有限公司 | 数据检测方法、装置、电子设备和介质 |
CN111711679A (zh) * | 2020-06-09 | 2020-09-25 | 宏图智能物流股份有限公司 | 一种仓库网络统一管理平台方法 |
CN112003792A (zh) * | 2020-07-23 | 2020-11-27 | 烽火通信科技股份有限公司 | 一种软硬件协同的报文加速方法和装置 |
CN112422695A (zh) * | 2020-12-07 | 2021-02-26 | 重庆忽米网络科技有限公司 | 一种支持多协议多规则的工业设备数据转发方法 |
CN112559246A (zh) * | 2020-12-10 | 2021-03-26 | 盛科网络(苏州)有限公司 | 一种交换机热备份平滑阶段的数据比较方法及装置 |
CN112559246B (zh) * | 2020-12-10 | 2024-02-27 | 苏州盛科通信股份有限公司 | 一种交换机热备份平滑阶段的数据比较方法及装置 |
CN115086233A (zh) * | 2022-08-17 | 2022-09-20 | 北京左江科技股份有限公司 | 一种基于fpga的网络报文关键信息提取转发的方法 |
CN115086233B (zh) * | 2022-08-17 | 2022-11-11 | 北京左江科技股份有限公司 | 一种基于fpga的网络报文关键信息提取转发的方法 |
Also Published As
Publication number | Publication date |
---|---|
CN100409646C (zh) | 2008-08-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN1612562A (zh) | 用策略流实现不同因特网协议数据包转发的方法和设备 | |
CN1466340A (zh) | 以策略流方式转发数据的方法和数据转发设备 | |
CN1181654C (zh) | 使用网络处理器的网络交换机和方法 | |
CN1197305C (zh) | 联网系统 | |
CN1310478C (zh) | 具有独立协议堆栈体系结构的多业务网络交换机 | |
CN1155205C (zh) | 分组中继设备 | |
CN1104687C (zh) | 传输网络中在包路由选择和包交换之间动态转换的改进方法及设备 | |
CN1757210A (zh) | 用于在光网络上传输分组数据的方法和装置 | |
CN1204509C (zh) | 通信网络装置 | |
CN1201242C (zh) | 数据传送控制装置和电子装置 | |
CN1311377C (zh) | 转寄信息封包的方法 | |
CN1204503C (zh) | 用于通信网络的装置、系统及其操作方法 | |
CN1239984C (zh) | Vlsi网络处理器和方法 | |
CN1890943A (zh) | 用于服务器和存储区网络之间的光学连网的方法和架构 | |
CN1149794C (zh) | 以太网直接与物理信道适配的接口装置和方法 | |
CN1608366A (zh) | 用于交换数据分组或帧的装置和方法 | |
CN1159888C (zh) | 物理层与网络层侧设备间传输数据的数据传输装置和方法 | |
CN1859242A (zh) | 支持多业务传输的宽带接入设备 | |
CN1496632A (zh) | 用在扩展局域网中的以优先级为基础的负载平衡方法和设备 | |
CN1829195A (zh) | 分组转发装置 | |
CN1682500A (zh) | 网络中的帧传送方法以及节点、帧传送程序 | |
CN1866922A (zh) | 一种以太网中的控制系统和数据报文传输方法 | |
CN1592259A (zh) | 网络用交换装置、路径管理服务器、网络接口装置及其控制方法 | |
CN1499794A (zh) | 通信设备中在第三层处理数据包的方法 | |
CN101053208A (zh) | 宽带协议 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
TR01 | Transfer of patent right | ||
TR01 | Transfer of patent right |
Effective date of registration: 20170411 Address after: 430074 East Lake high tech Development Zone, Hubei Province, No. 6, No., high and new technology development zone, No. four Patentee after: Fenghuo Communication Science &. Technology Co., Ltd. Address before: 430074 Hubei, Wuhan Patentee before: Wuhan Fenghuo Network Co., Ltd. |
|
CF01 | Termination of patent right due to non-payment of annual fee | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20080806 Termination date: 20191028 |