CN1466340A - 以策略流方式转发数据的方法和数据转发设备 - Google Patents
以策略流方式转发数据的方法和数据转发设备 Download PDFInfo
- Publication number
- CN1466340A CN1466340A CNA021248931A CN02124893A CN1466340A CN 1466340 A CN1466340 A CN 1466340A CN A021248931 A CNA021248931 A CN A021248931A CN 02124893 A CN02124893 A CN 02124893A CN 1466340 A CN1466340 A CN 1466340A
- Authority
- CN
- China
- Prior art keywords
- packet
- entry
- psfb
- forwarding
- stream
- 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、MPLS、虚拟专用网、二层转发、GTP(GPRS Tunneling Protocol)和移动IP等。在不额外引入节点间路由等信令协议、保证原Internet网中所有互联互通协议(如IETF系列协议)不变和完全不改变路由交换设备体系结构和硬件设计的前提下,大大提高了转发效率,可以适用于目前和未来的宽带IP网络中的接入层、汇聚层和骨干层等二三层路由交换设备等。
Description
技术领域
本发明涉及网络中数据传输技术,具体地说,涉及一种在网络中以策略流方式转发数据的方法和数据转发设备,它能够提高提高路由表或转发表查找速度和转发效率,并可以适用于目前和未来的宽带IP网络中的接入层、汇聚层和骨干层等二三层路由交换设备以及移动互联网络中的SGSN、GGSN、IGSN、和PDSN等设备。
背景技术
传统的IP路由器上采用了基于目的IP地址查找的最长匹配算法(LPM,Longest Prefix Match),并且针对每个数据包进行逐包转发或处理,其查找效率较低且无法支持复杂的和可变的业务需求。用户如果有新的业务需求,如策略路由、防火墙和移动IP等,因为不同的应用需要不同的查找策略和算法,必须构造不同的表目来支持不同的应用,这样就导致了数据包转发效率的低下和设备开发周期的延长,并且设备也难以实现线速转发。而目前日益流行MPLS技术采用了在网络边缘节点用定长的二层标记(Label)来映射三层的选路和QoS等信息,这样就在网络的核心节点提高了转发的效率,但同样导致了引入了复杂的MPLS信令系统,增加了路由器的负担,提高了维护量和开发成本,使设备之间的互通性变得更复杂。其它一些厂家的私有解决方案,如Cisco的Netflow部分采用了基于流处理的思想,但是它仅应用于计费和应用加速,而不能适用于数据包的转发中,因此它仍然需要和逐包处理的其它技术(如Cisco Express Forwarding)一起使用。鉴于此,本发明提出了基于策略流的线速转发(Wirespeed Policy Stream Forwarding)的概念,本发明在不额外引入节点间路由等信令协议、保证原Intemet网中所有互联互通协议(如IETF系列协议)不变和完全不改变路由器体系结构和硬件设计的前提下,大大提高了IP表项的查找效率,减少了设备开发的成本和时间,并可以为用户提供了动态裁剪的业务定制接口。本发明可以适用于目前和未来的宽带IP网络中的接入层、汇聚层和骨干层等二三层路由交换设备,本发明的方法对基于Ipv6的网络中的接入层、汇聚层和骨干层等二三层路由交换设备以及移动互联网络中的SGSN、GGSN、IGSN(GPRS/WCDMA)和PDSN(CDMA 2000/1X)等设备同样适用。
现有技术的一般描述
目前网络的发展趋势趋向于:智能化的边缘和接入节点加上简单的核心节点(Intelligent Edge & Dumb Core),即在边缘和接入节点完成智能的和电信级的业务生成和对用户流的控制,而在核心节点完成简单高速的IP转发。在城域网的组网拓扑中,接入节点和汇聚层节点就需要能够汇聚终端用户的流量,并能根据运营商的需求提供各种增值服务。但是,由于用户的业务需求具有不确定性(Uncertainty)和多样性(Versatility),所以这就要求边缘和接入侧的网络设备必须具有高可扩展性和能够向用户提供良好的定制业务的能力。
目前的汇聚层和边缘网络设备中,为了支持各种应用,往往采用了可编程的网络处理器(NPU)和多CPU并行处理的方式。针对每种具体应用,网络设备构造不同规格的路由表目,由每个数据包进行查找,随着应用的增加这就导致了查找性能的线性降低和编程复杂度的指数增长。不同的业务类型意味着在数据包的转发平面将使用不同的查找策略和方法,如单播路由采用最长前缀匹配(LPM);策略路由和ACL(访问控制列表)采用了逐条匹配(List by List Match),而组播路由根据协议的不同(PIM或DVMRP)和拓扑的不同(Shared Tree or Source Tree),采用了<*,G>,<S,G>等不同的查找策略;MPLS则是在边缘节点采用了LPM,而在核心节点采用了精确查找(Exact Match)。而不同的查找策略就必然导致了设备实现的复杂度增加、转发效率降低和维护工作量加大。
现有技术不足所体现的几个方面
I.基于数据包的IP转发的问题和不足
在现有的网络设备中,绝大多数采用了基于包的IP转发。而在包转发的过程中,需要在路由表中查找IP包的目的IP地址、修改TTL(Time To Live)、对数据包进行修改和重新计算校验和等操作。在这些步骤之中,修改TTL值和重新计算CRC校验和等所需要花费的时间较少,而路由表的查找是其中最耗时的。传统的路由查找是基于目的IP地址的最长匹配查找,即在路由中找到一个和目的IP地址前缀最长的匹配条目。例如在路由表(表1)中有以下三条条目:
Prefix(12bit) | Output Index |
P1=0101000000 | Ethernet 1/1 |
P2=0101110100 | POS 2/0 |
P3=0101101011 | FDDI 3/1 |
表1路由表
如果有一个数据包,它的前12个bit为01010110111,则它将会匹配P1,从Ethernet 1/1中发出。而如果它的前12个bit为0101101011,则它会匹配前缀P3,从FDDI 3/1中发出。在最常用的最长前缀匹配方案中,主要是基于Radix Trie表的查找方案,这种算法实现起来较为简单,但效率较低,在最差的情况下,需要32或128次内存访问(分别对应于IPv4或IPv6)。而某些改进的算法中,查找的效率大为提高,但仍然需要O(log2W)次,其中W为IP地址的bit位数。也即如果在IPv4情况下需要5次,而在IPV6情况下需要7次。
为了提高查找的速率,有些厂家或研究机构采用了特殊的存储器,如Content Addressable Memory(CAM)或者是Ternary CAM,但这些存储器价钱十分昂贵,并且需要对路由器已有的硬件结构再行设计。此外,有些厂家采用了高速路由缓存技术(Cache),即将最近访问的路由条目存入高速缓存中,IP包进入路由器时,首先查找Cache中的路由,找不到时才去访问路由表。在某些流量比较均衡的环境下,采用路由Cache可以大大提高访问速度,但是在大多数应用情况下(企业网和Internet的核心),往往目的地址呈现随机性和突发性,因此路由Cache技术往往只适用于小型的路由器。
随着因特网上业务的增加,在IP包转发和查找的过程中,可能并不简单地需要LPM,而需要进行逐条匹配(List by List),这种情况下传统的IP转发的性能会急剧下降。如在ACL(访问控制列表)应用中,如果ACL的条目为300条,考虑到最坏的情况下,一个包含有300个数据包的IP数据流在最后一条表目(第三百条)才能够得到匹配,这样该数据流中的每一个数据包就需要进行300次内存访问,而整个数据流则需要300*300=90,000次访问才能完成ACL表项查找。
此外,不同的业务往往需要不同的查找策略,这更加导致了在基于数据包转发的方式下,转发平面实现复杂且效率低下。由于目前的高性能路由器或接入设备,往往在转发的过程中采用了转发平面和控制平面的分离,在转发的过程中采用了ASIC或网络处理器来实现,这就导致了转发平面的芯片实现极其困难或者编程开发周期及长,难以支持复杂的应用。对于那些基于Ipv6和移动互联的网络设备也同样有类似不足。
由上可知,基于数据包的IP转发存在以下问题:
1.在对IP地址的查找过程中,基于最长匹配的查找策略导致查找效率低下。此外,在需要逐条进行查找的应用中,查找效率更为低下。
2.难以支持网络边缘侧和接入侧节点复杂而多变的应用。各种应用的不同查找算法导致设备需要重新编程或重新设计ASIC的功能。但即使这样作也无法跟上应用和需求的快速变化,例如目前的很多三层交换机设备无法支持NAT或PPPoE等应用就是一个例证。
3.无法提供业务定制的接口,由于现有设备中在转发平面采用复杂的查找算法而不是统一的转发策略,这样即使实现了目前已有的功能也无法具有可扩展性,无法具备支持其它未来可能出现的新业务的能力。
4.对于那些基于Ipv6和移动互联的网络设备也同样有以上1-3点类似不足。
II、MPLS转发的问题和不足
MPLS技术是目前流行的IP交换技术。所谓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的两大标准分别为不同厂家所支持,这也导致了网络互操作性的困难。
如图1可以看出一个MPLS网络的基本组成。一个典型的MPLS域由以下几部分组成:LER(label edge router)、LSR(label switch router)和LSP(labelswitch path)。其中,LER是位于MPLS域的边缘路由器,它按照一定的规则把进入MPLS域的数据包分成不同的转发等效类FEC(ForwardingEquivalence Classes),并根据不同的FEC对数据包进行添加(入LER)或删除(出LER)标记的操作;LSR是MPLS域的中间交换节点,它完成标记的查找和替换过程;而LSP(Label Switching Path)则是由LSR和LER按照LDP建立起来的标记交换通路。其中LSR和LER可以由传统的ATM和FR交换机扩展了IP路由功能,也可以是运行MPLS协议的高速IP路由器。
如图2显示了一个典型的IP包通过MPLS网络情况。当一个目的地址为192.4.2.1的IP包到达MPLS域的边界节点LERin时,LERin将首先对该包进行网络层解析并进行FEC分类,分类的标准可以有以下三种:目的地址前缀、主机地址或是主机地址+QoS。然后,通过查找FTN(FEC to NHILE)表来找到出口标记,并完成FEC到一条LSP上的映射。当包经过每个中间节点时,LSR将按照最长匹配算法查找ILM(Incoming Label Mapping),完成(入标记+入接口)到(出标记+出接口)的映射,将入标记替换成出标记,并将IP包转发到出接口。当IP包最后到达LERout时,LERout首先将标记弹出栈,然后根据目的地址对IP包进行IP层转发。
虽然,MPLS方案和传统的IP转发相比在边缘节点提高了转发的效率,但仍然存在以下不足:
l、MPLS在边缘节点对数据包的复杂处理,和基于包的IP转发相同,它仍然需要进行最长匹配查找,完成从FEC到Label的映射,因此同样导致的边缘设备的开发周期长和设备复杂。
2、MPLS的实现需要引入复杂的MPLS信令,大大增加设备的开发成本和维护费用。与MPLS相关的IETF RFC和草案多达80余个,设备开发商实现起来极为复杂,而运营商也难以进行维护。
3、由于MPLS的标准中支持两种信令协议,LDP(CR-LDP)和RSVP,而这两大标志分别为不同的厂商所支持。所以使用MPLS协议,会导致网络设备的互通性存在问题。
4、由于MPLS与现有IP数据网络协议不兼容,需要重新建设新的MPLS网络,对于路由和三层交换节点的设备而言,如果实现MPLS功能,就需要引入额外节点间信令协议,原Internet网中所有互联互通协议(如IETF系列协议)因为要支持MPLS而发生变化,需要改变路由器软件体系结构和全部软件设计;
5、对于那些基于Ipv6和移动互联的网络设备也同样有类似不足。III、CEF+Netflow(技术)的问题和不足
图3示出了Cisco的Ciscol2000路由器上采用的CEF技术。Cisco在高端路由器中采用了CEF(Cisco Express Forwarding)技术。CEF技术不同于传统的route-cache机制,即将最近经常访问的路由条目放入Cache中,以提高IP包的查找速度,而采用了全新的转发机制。CEF中共有两种表,转发信息库(FIB,Forwarding Information Base)和邻接表(Adjacency Table)。如下图四,首先,路由引擎运行路由协议(包括单播和组播),并产生路由表,然后由路由表导出FIB表,可以认为FIB是路由表的一个子集(shadow),它包含对目的IP前缀的下一跳的IP地址和对应的出端口。FIB和路由表中的条目是一一对应的关系。当网络拓扑发生变化时,FIB将发生相应的变化,路由引擎随时把更新信息下载到各个线卡。而邻接表则包含有针对每个出端口所连接的下一跳的链路层(layer 2)地址(可参见下图,可以用来完成所发出数据包的封装。快速转发目前支持的链路层介质有:ATM,Frame Relay,Ethernet,FDDI,PPP,LAPS和HDLC。一般来说,邻接表可以通过运行ARP得到。而在实现组播路由时,快速转发表的数据结构与单播不同,组播路由表将源IP地址和组播组的pair映射为一个入端口到一组出端口的pair。
为了支持计费和ACL加速等应用,Cisco在使用CEF的同时还使用了还采用了NetFlow技术,也即采用了基于Flow的处理方式。NetFlow本身并不对IP数据进行转发,它需要和Cisco的CEF一起使用。它采用了<源地址、目的地址、源端口、目的端口、协议类型、TOS、入物理端口>来标识一个Flow,然后针对每一个Flow进行包和字节的统计,而当针对某些应用(如ACL)时,它采用了将每个Flow的第一个数据包送至软件处理,生成表目之后加速以后的转发。
由于NetFlow技术的设计只是为了针对计费应用和提供某些应用的加速功能,它不能够单独对数据包进行转发,此外,它的表目设计并没有考虑对复杂应用如认证和隧道协议的支持和扩展,例如,没有源物理地址和VLAN ID等字段。由于NetFlow技术本身并不提供转发数据包的功能(在表目中并没有指向下一跳的链路层信息),它必须和Cisco的其它基于数据包的转发技术(如CEF或Fast Switching)一起使用(这是NetFlow与本发明为最大不同之处)。
由上可见,Cisco的CEF技术和NetFlow技术存在以下不足:
1.CEF技术仍然是基于包的IP转发技术,它仍然采用了最长匹配查找的方式,并针对每个数据包进行处理,查找效率较低且难以支持复杂应用。
2.NetFlow技术中引入了基于Flow处理的思想,但是,它本身的设计思想并不是为了提供快速的策略流转发而设计,因此它只能支持计费等应用,并对ACL等处理进行加速处理。而在一般的单播和组播转发中,仍然采用了CEF或Cisco其它的快速转发技术。
3.CEF+NetFlow采用了固定的七元组来映射FlowID,技术支持的应用较少且缺少灵活性,它是单纯的基于三层处理的技术,没有考虑对二层协议的支持,表项中缺少必要的二层信息,无法支持基于二层的认证功能(如源端口、VLAN ID和源MAC)、二层转发以及移动互联网络应用。此外,NetFlow目前不支持NAT等应用。
4.对于那些基于Ipv6和移动互联的网络设备也同样有类似不足。
发明内容
因此,本发明的目的是提供一种在网络设备中以策略流方式转发数据的方法和数据转发设备,它能够提高提高路由表查找速度和转发效率,并可以适用于目前和未来的宽带IP网络中的接入层、汇聚层和骨干层等二三层路由交换设备以及移动互联网络中的SGSN、GGSN、IGSN和PDSN等设备。
本发明提供一种在网络设备中以策略流方式转发数据的方法,所述网络设备包括至少一转发平面和一控制平面,该方法包括以下步骤:(a)在一转发平面接收至少一数据流的数据包;(b)在转发平面根据该数据包的多元属性组计算出标识该数据流的流ID;(c)转发平面根据步骤(b)所得出的流ID按照精确匹配去查找一策略流转发表(PSFB),如果发现匹配则进行步骤(d),否则进到步骤(e);(d)如果发现匹配,则按照所述PSFB表目对该数据包进行相关内容修改和转发操作,然后进到步骤(h)处理下一个数据包;(e)如果没有表目匹配,则说明这是数据流的第一个包或者是PSFB表目已经老化,转发平面将把该数据包送到控制平面;(f)控制平面为该数据包查找相关的路由表和业务表目,得到下一跳所对应的转发信息和业务相关信息,并生成用于该数据流的PSFB表目,该PSFB表包括对所述数据包计算出的流ID、下一跳所对应的转发信息和业务相关信息;(g)控制平面将该PSFB表目分发到所述转发平面;和(h)对该数据流中随后的数据包,在所述转发平面使用该PSFB表目进行所述步骤(c)和(d)的转发操作,以将其转发到相应的接收方。
本发明还提供一种以策略流方式转发数据的数据转发设备,包括至少一转发平面,其每个接收至少一数据流的数据包;和一控制平面,所述转发平面包括:流ID计算部分,用于根据该数据包的多元属性组计算出计算出标识该数据流的流ID;查找部分,用于按照精确匹配去查找一存储器中的策略流转发表(PSFB),看是否有与该数据包的流ID相匹配的PSFB表目;修改和转发部分,如果发现匹配,则按照所述PSFB表目对该数据包进行相关内容修改和转发操作,然后转发平面转向处理下一个数据包如不匹配,将该数据包送到控制平面;其中,所述控制平面中存有与数据转发相关的路由表和业务表目,并且包括:PSFB表生成部分,用于为所述未匹配的数据包查找相关的路由表和业务表目,得到下一跳所对应的转发信息和业务相关信息,并生成用于该数据流的PSFB表目,该PSFB表包括对所述数据包计算出的流ID、下一跳所对应的转发信息和业务相关信息与数据转发相关的路由表和业务表目,并将该PSFB表目分发到所述转发平面;存储器,用于存储所述生成的PSFB表目,并供所述转发平面为同一数据流的随后的数据包查找使用。
附图简述
以下结合附图的对本发明的具体实施例的描述将使本发明的上述和其它特点和优点更为清楚。
图1示出了现有技术中MPLS网络的基本组成;
图2示出了现有技术中一个典型的IP包通过MPLS网络的情况;
图3示出了现有技术中Cisco的Ciscol2000路由器上采用的CEF技术。
图4A和4B示出了本发明的在网络设备中以策略流方式转发数据的方法的一个实施例的流程图。
图5示出了本发明的以策略流方式转发数据的数据转发设备的构成的示意方框图。
图6示出本发明的应用的通用机架布局图;
图7示出本发明的数据转发设备的线路接口卡布局图。
具体实施方式
以下结合附图对本发明的优选实施例作详细描述。
首先描述作为本发明的基础的策略流转发的概念。策略流转发采用了完全基于流处理的思路而不是基于数据包处理的思想,主要作法是:对于同一个数据流中的不同数据包,网络设备对它的行为(Action)应该是完全相同的。此外,对于转发平面来说,它并不需要知道自己对数据包应该采用何种查找算法(单播、组播、IPv4或Ipv6),相反,它只需要知道它的出端口和下一跳信息,以及该采用何种策略对数据包进行修改。因此,策略流转发在转发平面中采用了统一的转发表目和单一高效的精确查找算法(ExactMatch),这样就简化了转发平面的处理,提高了查找效率。
具体来说,所谓策略流交换,它并非针对某一个具体的IP数据包进行查找交换,而是采用了对特定的IP数据流进行转发处理的思想。策略流交换采用了<源IP地址,目的IP地址,源协议端口,目的协议端口,协议类型等>的多元组(在本发明的实施例中采用五元组举例说明)来标识一个数据流,因为这一多元组已经能够而且唯一地标识了一个数据流,它已经能唯一确定一个流的入物理端口和ToS字段,因此并需要像Cisco NetFlow那样用一个七元组来标识一个数据流。针对特定的Stream,网络设备为该数据流分配唯一的流ID(Stream ID),并且只需要对该数据流的第一个数据包进行复杂的查表查找,并由用户定制对它的特定业务操作。控制平面在完成查找和定制完业务类型后,生成策略流转发表目(Policy Stream Forwarding Table),并由路由引擎将该表目分发(Distribute)到转发平面。表目包含有下一跳的出接口信息和标明业务种类的策略类型字段。而数据包转发时将根据这一业务操作的策略类型对该Stream做统一的处理。由于对于转发平面来说,它将不关心查找的策略,而只是关心该数据流是否能够被转发和应该被转发到那个出接口,这样就大大简化的转发平面的处理过程。
在以上所提到的例子中,对于一个300个数据包的流,进行同样的ACL查找操作,本发明的基于流转发的网络设备只需要进行(300+299)次内存访问,也即平均一个数据包只需要进行(300+299)/300次查找,即1.99次查找。转发性能和基于每个数据包进行处理的网络设备(最差情况)相比提高了将近150倍。本发明的方法对基于Ipv6的网络中的接入层、汇聚层和骨干层等二三层路由交换设备和等GGSN、SGSN、IGSN和PDSN移动互联网络设备同样适用。
3以下给出本发明相关术语的解释:
Control Plane(控制平面):提供路由和信令功能,和其他网络设备交互并处理协议包,根据用户的配置一起为转发平面生成转发时所依照的各种表目和策略,处理异常或其它选项包。它可以是集中或分布式,
Forwarding Plane(转发平面):完成per-packet处理,实现对转发数据包的layer 2到layer 7的处理,提供多种转发(layer 2、IP、MPLS和PPPoE)方式和安全(NAT和VPN)策略处理,完成对统计变量的计数。
Policy Stream Forwarding Base(PSFB,策略流转发表):本表仅存在于转发平面(Forwarding Plane),它包括多元组(如五元组)、流ID、对流操作的策略类型以及和转发应用相关的所有信息。
Link-layer Adjacency Table(链路邻接表):本表仅存在于转发平面,存放出端口和相应的链路层信息(如MAC地址)。
Uni-cast Routing Table(URT,单播路由表):本表仅存在于控制平面,本表包括有由RIP、OSPF和BGP等路由协议生成的单播选路信息,表目的查找采用最长匹配。
Multicast Routing Table(MRT,组播路由表):本表仅存在于控制平面,本表包含有由PIM SM/DM和DVMRP等路由协议生成组播选路信息,表目的查找根据组播协议的不同而不同。
Access Control List(访问控制列表):本表仅存在于控制平面,本表包含有对包过滤的基本信息,表目的查找采用逐条匹配。
Policy-Based Routing Table(策略路由表):本表仅存在于转发平面和控制平面,所谓策略路由是指对路由表的查找不是基于目的地址的最长匹配查找,而是基于策略(如源地址)的查找,它的查找方式采用了逐条查找。本发明的方法对基于Ipv6的网络中的接入层、汇聚层和骨干层等二三层路由交换设备以及移动互联网络中的SGSN、GGSN、IGSN和PDSN设备中的相关术语同样适用。
基本功能和操作
图4A和4B示出了本发明的在网络设备中以策略流方式转发数据的方法的一个实施例的流程图。
如图4A和4B所示,本发明的方法一个完整的策略流转发过程的例子如下(以五元组为例):
(1)数据包首先进入网络设备后,转发平面首先根据例如<源地址、目的地址、源协议端口、目的协议端口、协议类型>的五元属性组按照HASH算法,计算出对应的Stream ID。
这里,五元组计算流ID的算法的一个例子如下:
如果可用于存储表目的存储空间的大小为m,小于m的最大质数为t。而流转发表的存储采用hash+链地址的算法来解决冲突,即将key值相同的表目放在同一个链表中,表目在链表中的位置为p。
首先通过(源IP地址×1+目的IP地址×3+协议类型×5+源协议端口×7+目的协议端口×9)计算出一个32位的整数num,然后由num对t取模就可以算出出hash的关键码(key),由于hash算法可能会有冲突,因此同一个key值可能会对应多个num,但是它们在链表中的位置唯一,所以将key值作为Stream ID的高24位,p作为Stream ID的低8位就可以唯一标识一个32位的Stream ID。
也即Stream ID=((源IP地址×1+目的IP地址)×3+协议类型×5+源协议端口×7+目的协议端口×9) MOD t)<<8(左移8位)+p。
当然,该流ID的算法也可以采用其它形式或其它算法,只要其能够对应于一个数据流的多元属性组计算出一个唯一的流ID值。
(2)转发平面根据(1)所得出的流ID按照精确查找精确匹配(ExactMatch)或散列算法去查找策略流转发表(PSFB)。如果发现匹配则进行(3),否则进行(5)。
(3)如果发现匹配,首先根据策略类型知道需要何种业务操作,然后根据Output Port Index表项所指向的邻接表(Adiacency Table)表项得出出端口(Output Port)和对应的链路层消息(如MAC地址)(注:如果是组播转发,此处则是出端口列表)。
(4)转发平面进行对数据包的策略操作,并进行TTL减一和计算校验和等操作后,将该数据包从出端口发出,并将Expired Flag位重新置位,并到(9)
(5)如果没有表目匹配,则说明这是数据流的第一个包或者是PSFB表目已经老化,转发平面将把该数据包送到控制平面。
(6)转发平面查找相关的路由表和业务表目(如PPPoE、NAT),得到下一跳所对应的出端口和链路层信息和业务相关信息,并构造PSFB表目(如下图5),表目的内容包括流ID、出端口索引(在组播中为出端口列表)和策略类型等信息。
(7)控制平面把该表目分发到转发平面。
(8)数据流随后的数据包查找该PSFB表目并做(3)和(4)操作即可。
(9)结束操作,处理下一个策略流或数据包。
对于其它多元组(可能是六元组或八元组),将根据应用和实际路由表目的不同,作类似处理即可。本发明的方法对基于Ipv6的网络中的接入层、汇聚层和骨干层等二三层路由交换设备和SGSN、GGSN、IGSN和PDSN等移动互联的网络同样适用。
策略流转发表目描述
下面以五元组为例给出策略流转发表目的详细定义的一个实例。对于其它多元属性组,将根据应用和实际路由表目的不同,作类似处理即可。
Source IP(4字节/32字节):数据流的源IP地址,Ipv4时为4字节,Ipv6时为32字节。
Destination IP(4字节):数据流的目的IP地址,Ipv4时为4字节,Ipv6时为32字节。
Protocol Type(2字节):协议类型
Source Protocol Port(2字节):源协议端口,由协议类型来决定为何种协议的端口
Destination Protocol Port(2字节):目的协议端口,由协议类型来决定为何种协议的端口
Stream ID(4字节):由以上五元组所对应的数据流的唯一的流ID
Start of Time(4字节):起始时间,数据流的起始时间,用于计费。
End of Time(4字节):结束时间,数据流的结束时间,用于计费。
Alias Port(2字节):伪端口,转换后的协议端口,用于网络地址转换
Alias Address(4字节):伪IP地址,转换后的IP地址,用于网络地址转换
Session ID(2字节):会话ID,用于PPPoE
Quality of Services(4字节):QoS/CoS参数,用于对数据流的调度。
Multicast Port(32字节):组播端口标识,通过位操作来指示组播端口,共支持32*8=256个端口
Source MAC(6字节):表示数据流的源IP地址所对应的MAC Address,用于源MAC过滤、WEB认证和802.1x
Source Port(2字节):标识数据流所来自的源物理端口,用于WEB认证和802.1X
Tunnel ID(2字节):隧道ID,用于支持VPN协议,如L2TP。
Gateway IP(4字节):网关IP地址,用于支持移动IP。
Transmit Packet(4字节):传送的数据包的个数,用于计费
Transmit Byte(4字节):发送的字节个数,用于计费
VLAN ID(4字节):VLAN ID,用于支持802.1Q和认证协议(如WEB认证)
Forwarding Flag(1字节):转发标志位,决定是否转发该包,用于认证和ACL。
DSCP(4字节):用于区分业务。
Policy Type(4字节):策略类型,表明对数据流流该进行的何种业务操作类型,可由网管灵活配置或用户进行业务定制。
Expired Timer(1字节):超时定时器,判断该流转发表目是否超时。
TCP Flag(1字节):TCP标志位,用来判断TCP流是否结束。
本节的方法对基于Ipv6和移动互联网络中的策略流转发表目描述同样适用。
突发的TCP流和非TCP流的处理策略
由于PSFB(Policy Stream Forwarding Base)的表目的大小受限于SDRAM(或其它种类的内存)的大小,所以在Intemet网上瞬间突发的流很多的情况下,可能导致策略流转发表目超过硬件限制,因此本发明采用特有的机制来平滑瞬间的流量。为此,本发明采用以下两种机制来避免这一情况发送。
首先,本发明在转发平面送往控制平面的数据流的第一个数据包的过程中,采用了排队机制,也即控制单位时间内排队的数据包长度,而队列的深度由剩余的SDRAM(或其它种内存)空间来决定,这样当PSFB表目过大时,本发明通过降低队列深度来减少单位时间内排队的数据包个数。此外,本发明采用的作法是缩短新建表目的老化时间,即表目的老化时间随着表目空间的变小而缩短。这样表目就会加快老化速度,使表目空间相对加大。
流交换中的另一大技术问题就是如何解决表目的更新问题。数据流中,面向TCP的连接,可以通过TCP的FIN包来完成对数据流的拆链。但是,由于因特网应用中大量的流是基于IP或UDP的无连接数据流,这样就无法根据特定的数据包来判断一个数据流是否结束。为此,本发明采用了两种方式:对于正常的TCP连接,本发明通过判断FIN包和RESET包来决定是否删除该条目。而对于基于非连接的数据流和非正常关闭的TCP流,本发明采用定期刷新的方式,即在控制平面启动一个定时器(初始值的大小可由网管进行配置),周期性的去检查转发平面的PSFB中表目的Expired Flag,该Expired Flag初始化时为一固定值(该值可以根据协议类型不同而不同,并根据表空间的大小动态调整),并做减一操作,如果该值被减为零,则删除该条目。
本节的方法对基于Ipv6和移动互联网络中的突发的TCP流和非TCP流的处理策略同样适用。
ISMP的内部通信实例
ISMP(Intelligent Stream Management Protocol)是用于策略流转发节点内部的设备资源管理的简单、通用的协议(一个五元组实例)。它是策略流转发技术的重要组成部分。它主要用于控制平面和转发平面的数据交换和信息控制,它采用Master-Slave方式,由Master控制流转发表目的添加、删除,完成用户对数据流的业务定制和属性修改。此外,转发平面也可以主动向控制平面提供事件消息,如统计信息和流状态。ISMP消息的编码采用TLV的编码方式,即类型、长度和值的方式。
ISSMP支持四种消息:表目管理,流属性管理,状态管理消息和数据交换消息,对每一种消息类型的作用和功能说明如下:
表目管理(Table Management):定位在控制平面,用于管理表目的建立和删除。1.流表目添加(Add Table):
本消息完成由控制平面向转发平面添加一条流转发表目。消息格式和说明如下表2: 0 7 15 31
版本 | 类型 | 长度 |
Flow ID(流ID) | ||
目的卡号 | 保留位 | 序列号 |
流转发表目(128字节) | ||
CRC 32(校验和) |
表2流表目添加消息格式
其中,版本号为1,表示目前的版本为1;类型为1,即流表目添加;长度字段为32位,即整个消息的长度;目的卡号:即消息要发送的卡号,如果为0xff,即广播到所有的卡;保留位:预留字段,用于字节对齐;序列号:16位,用于重传,保证消息的可靠传输。2.流表目删除(Delete Table):
本消息完成控制平面通告转发平面删除一条流转发表目。消息格式和说明如下表3:
版本 | 类型 | 长度 |
Flow ID(流ID) | ||
目的卡号 | 保留位 | 序列号 |
流转发表目(128字节) | ||
CRC 32(校验和) |
表3流表目删除消息格式
其中,除了类型字段为2,表示流表目删除以外,其它表项内容和流表目添加相同。3.分支删除(Delete Branch):
本消息由控制平面通告转发平面删除和某个出端口相关的所有表目,格式如下表4:
版本 | 类型 | 长度 |
Flow ID(流ID) | ||
目的卡号 | 出端口号 | 序列号 |
CRC 32(校验和) |
表4分支删除消息格式
其中,版本号为1;类型为3,即分支表目删除;长度字段为32位,即整个消息的长度;
目的卡号:即消息要发送的卡号,如果为0xff,即广播到所有的卡;出端口:需要删除相关的条目相关的端口;序列号:16位,用于重传,保证消息的可靠传输。4.删除所有表目(Delete All):
本消息完成控制平面通告转发平面删除所有的转发表目,格式如下表5:
版本 | 类型 | 长度 |
Flow ID(流ID) | ||
目的卡号 | 保留位 | 序列号 |
CRC 32(校验和) |
表5删除所有表目消息格式
其中,版本号为1;类型为4,即全表目删除;长度字段为32位,即整个消息的长度;
目的卡号:即消息要发送的卡号,如果为0xff,即广播到所有的卡;出端口:需要删除相关的条目相关的端口;序列号:16位,用于重传,保证消息的可靠传输。
流属性管理(Attribute Management):定位在控制平面,完成对流的业务定制和属性修改功能。1.流表目业务定制(Services customization):
本表目完成控制平面定制转发平面业务类型的功能。消息的编码和说明如下表6:
版本 | 类型 | 长度 |
Flow ID(流ID) | ||
目的卡号 | 保留位 | 序列号 |
业务类型 | 长度 | 业务值 |
CRC 32(校验和) |
表6流表目业务定制消息格式
其中,版本号为1;类型为5,即业务定制;长度字段为32位,即整个消息的长度;
目的卡号:即消息要发送的卡号,如果为0xff,即广播到所有的卡;消息需要定制的业务采用了TLV编码,最多在同一条消息中支持64种业务类型;序列号:16位,用于重传,保证消息的可靠传输。2.业务属性修改(Service Attribute Modification):
本消息完成控制平面通告转发平面的业务属性的修改,如流的速率和QoS参数。消息的编码格式和说明如下表7:
版本 | 类型 | 长度 |
Flow ID(流ID) | ||
目的卡号 | 保留位 | 序列号 |
业务属性 | 长度 | 修改的业务属性值 |
CRC 32(校验和) |
表7业务属性修改消息格式
其中,版本号为1;类型为6,即业务属性修改;长度字段为32位,即整个消息的长度;
目的卡号:即消息要发送的卡号,如果为0xff,即广播到所有的卡;业务属性:采用了TLV编码,最多在同一条消息中支持64种业务属性修改;序列号:16位,用于重传,保证消息的可靠传输。
状态和统计消息(State and Statistics Message):定位在控制平面,状态和统计消息能够使控制平面得到和每个流相关的统计计数和状态信息。1.流统计计数(Report Stream Statistics)
完成转发平面向控制平面通告数据流在起始时间内的包和字节的统计计数。消息的编码和格式如下表8:
版本 | 类型 | 长度 |
Flow ID(流ID) | ||
序列号 | 保留位 | |
起始时间(4字节) | ||
结束时间(4字节) | ||
包统计计数(4字节) | ||
字节计数(4字节) | ||
CRC 32(校验和) |
表8流统计消息格式
其中,版本号为1;类型为7,即统计信息上报;长度字段为32位,即整个消息的长度;
起始时间:即数据流创建的时间;结束时间:数据流的结束时间;包统计计数:在起始和结束时间内所通过的数据包个数;字节计数:在起始和结束时间内所通过的数据包个数;序列号:16位,用于重传,保证消息的可靠传输。CRC 32:用于校验该数据包内容的完整性。2.流状态上报(Report Stream State)
完成转发平面向控制平面通告数据流的状态。其消息格式和说明如下表9:
其中,版本号为1;类型为8,即流状态上报;长度字段为32位,即整个消息的长度;
上报的业务流状态采用了TLV编码,最多在同一条消息中支持64种业务类型;序列号:16位,用于重传,保证消息的可靠传输。
版本 | 类型 | 长度 |
Flow ID(流ID) | ||
序列号 | 保留位 | |
业务类型 | 长度 | 业务值 |
CRC 32(校验和) |
表9流状态上报消息格式
数据交换消息(Packet Exchange Message):用于控制平面和转发平面的协议包(控制包)的交互。消息的格式和说明如下表10
版本 | 类型 | 长度 | |
序列号 | 目的卡号 | 保留位 | |
数据包内容 | |||
CRC 32(校验和) |
表10数据交换消息格式其中,版本号为1;类型为9,即交换的数据包;长度字段为32位,即数据包的长度;
目的卡号:即目的卡的编号,如果为0,则表示是主控卡,为0xff,则表示是广播包。序列号:16位,用于重传,保证消息的可靠传输。
对于其它多元组,将根据应用和实际路由表目的不同,作类似处理即可。本节的方法对基于Ipv6和移动互联的网络中的ISMP的内部通信实例同样适用。
多种接入和转发方式的实现
以下以五元组为例描述怎样通过策略流转发技术在路由器或三层交换设备上支持目前的几种业务以及它所特有的高可扩展性。1.支持IPv4单播转发:
(1)数据包进入路由器或三层交换设备后,转发平面首先根据<源地址、目的地址、源协议端口、目的协议端口、协议类型>计算出对应的Stream ID。
(2)转发平面根据(1)所得出的流ID按照精确查找(Exact Match)去查找流转发表(PSFB)。如果发现匹配则进行(3),否则进行(5)。
(3)如果发现匹配,首先根据策略类型知道需要进行单播IPv4转发,然后根据Output Port Index表项所指向的邻接表(Adiacency Table)表项得出出端口(Output Port)和对应的链路层消息(如MAC地址)。
(4)转发平面进行对数据包进行TTL减一和计算校验和等操作后,将该数据包从出端口发出,并将Expired Flag位重新置位,并到(9)
(5)如果没有表目匹配,则说明这是数据流的第一个包或者是PSFB表目已经老化,转发平面需要通过数据交互消息(PEM)则对数据流的第一个数据包送到控制平面。
(6)控制平面查找URT(单播路由表),通过最长匹配算法查到下一跳所对应的出端口和链路层信息,并构造PSFB表目,表目的内容包括流ID、出端口索引和策略类型(单播路由)。
(7)控制平面通过流表目添加消息将该表目分发到转发平面。
(8)数据流随后的数据包查找该PSFB表目并做(3)和(4)操作即可。
(9)结束操作,处理下一个数据包。
本节的方法对基于Ipv6和移动互联的网络同样适用。
2组播转发:
(1)数据包首先进入网络设备后,转发平面首先根据<源地址、目的地址、源协议端口、目的协议端口、协议类型>计算出对应的Stream ID。
(2)转发平面根据(1)所得出的流ID按照精确查找(Exact Match)去查找流转发表(PSFB)。如果发现匹配则进行(3),否则进行(5)。
(3)如果发现匹配,首先根据策略类型得知需要进行组播转发。然后根据PSFB表项中的Multicast Port位进行位操作判断,并通过所置位所对应的邻接表(Adiacency Table)表项得出所有的出端口(Output Port)和对应的链路层消息(如MAC地址)。
(4)转发平面进行对数据包进行TTL减一和计算校验和等操作后,将该数据包从所有的出端口发出,并将Expired Flag位重新置位。
(5)如果没有表目匹配,则说明这是数据流的第一个包或者是PSFB表目已经老化,转发平面需要通过数据交互消息(PEM)则对数据流的第一个数据包送到控制平面。
(6)控制平面首先查找单播路由表(URT)来进行RPF(Reverse PathForwarding),来决定该包是否能够被转发,然后根据协议的不同,分别通过<*,G>、<S,G>或<RPT,S,G>来查找组播路由表(MRT),得出端口列表,并构造PSFB,表目的内容包括流ID、Multicast Port和策略类型(组播路由)。
(7)控制平面通过流表目添加(Add Table)消息将该表目分发到转发平面。
(8)数据流随后的数据包查找该PSFB表目并做(3)和(4)操作即可。
(9)结束操作,进行处理下一个数据包。
本节的方法对基于Ipv6和移动互联的网络同样适用。
3.PPPoE转发到IP接口
(1)数据包首先进入网络设备后,转发平面首先根据<源地址、目的地址、源协议端口、目的协议端口、协议类型>计算出对应的Stream ID。
(2)转发平面根据(1)所得出的流ID按照精确查找(Exact Match)去查找流转发表(PSFB)。如果发现匹配则进行(3),否则进行(5)。
(3)如果发现匹配,首先根据策略类型得知需要进行PPPoE处理,然后根据PSFB表项中的Session ID、源物理端口和源MAC地址对数据包的相应内容进行比较验证,如果验证失败,则跳到(9)。否则通过出端口索引所对应的邻接表(Adiacency Table)表项得出出端口(Output Port)和对应的链路层消息(如MAC地址)。
(4)转发平面进行对数据包进行去PPPoE包头、TTL减一和计算校验和等操作后,将该数据包从所有的出端口发出,并将Expired Flag位重新置位。
(5)如果没有表目匹配,则说明这是数据流的第一个包或者是PSFB表目已经老化,转发平面需要通过数据交互消息(PEM)则对数据流的第一个数据包送到控制平面。
(6)控制平面首先查找PPPoE的会话(Session)表项来决定该包是否能够被转发,如果能够则查找单播路由表(URT)并构造PSFB,表目的内容包括流ID、操作类型、Session ID、源MAC地址和源物理端口(用于认证和过滤)和策略类型(PPPoE转发)。
(7)控制平面通过流表目添加(Table Add)消息将该表目分发到转发平面。
(8)数据流随后的数据包查找该PSFB表目并做(3)和(4)操作即可。
(9)结束操作,进行对下一个数据包的处理。
本节的方法对基于Ipv6和移动互联的网络同样适用。
4.NAT+单播转发
(1)数据包首先进入网络设备后,转发平面首先根据<源地址、目的地址、源协议端口、目的协议端口、协议类型>计算出对应的Stream ID。
(2)转发平面根据(1)所得出的流ID按照精确查找(ExactMatch或散列算法去查找流转发表(PSFB)。如果发现匹配则进行(3),否则进行(5)。
(3)如果发现匹配,首先根据策略类型得知需要进行NAT处理和单播转发,然后通过PSFB的表项中的用PSFB表项中的Alias Port和Alias IPAddress替换数据包中的相关内容。
(4)转发平面进行对数据包TTL减一和计算校验和等操作后,将该数据包从所有的出端口发出,并将Expired Flag位重新置位。
(5)如果没有表目匹配,则说明这是数据流的第一个包或者是PSFB表目已经老化,转发平面需要通过数据交互消息(PEM)则对数据流的第一个数据包送到控制平面。
(6)控制平面首先查找NAT转换表,如果表目不存在,则为该数据包分配一个新的Alias Port并从地址池中重新分配一个Alias Adddress,如果能够,则查找单播路由表(URT)并构造PSFB,表目的内容包括流ID、AliasPort、Alias Address和策略类型(NAT和单播转发)。
(7)控制平面通过流表目添加(Add Table)消息将该表目分发到转发平面。
(8)数据流随后的数据包查找该PSFB表目并做(3)和(4)操作即可。
(9)结束操作,进行对下一个数据包的处理。
本节的方法对基于Ipv6和移动互联的网络同样适用。
5.IPv6转发
(1)数据包首先进入网络设备后,转发平面首先根据<源地址、目的地址、源协议端口、目的协议端口、协议类型>计算出对应的Stream ID。
(2)转发平面根据(1)所得出的流ID按照精确查找(Exact Match)去查找流转发表(PSFB)。如果发现匹配则进行(3),否则进行(5)。
(3)如果发现匹配,首先根据策略类型知道需要进行IPv6转发,然后根据Output Port Index表项所指向的邻接表(Adiacency Table)表项得出出端口(Output Port)和对应的链路层消息(如MAC地址)。
(4)转发平面进行对数据包进行TTL减一和计算校验和等操作后,将该数据包从出端口发出,并将Expired Flag位重新置位,并到(9)
(5)如果没有表目匹配,则说明这是数据流的第一个包或者是PSFB表目已经老化,转发平面需要通过数据交互消息(PEM)则对数据流的第一个数据包送到控制平面。
(6)控制平面查找IPv6路由表,通过最长匹配算法查到下一跳所对应的出端口和链路层信息,并构造PSFB表目,表目的内容包括流ID、出端口索引和策略类型(单播路由)。
(7)控制平面通过流表目添加消息将该表目分发到转发平面。
(8)数据流随后的数据包查找该PSFB表目并做(3)和(4)操作即可。
(9)结束操作,处理下一个数据包。
本节的方法对基于Ipv6的网络同样适用。
从以上流程可以看出,在单播、组播,IPv4和IPv6的转发过程中,策略流转发的过程基本相同,只需要在转发平面查找同一张PSFB表,不同之处仅在于(3)、(4)和(6)部分和业务相关的内容,因此,可以看出策略流转发可以在不额外引入节点间路由等信令协议、保证原Intemet网中所有互联互通协议(如IETF系列协议)不变和完全不改变路由器体系结构和硬件设计的前提下,支持各种复杂的应用。以下是策略流转发支持其它常见应用的实例:
1.802.1X
EAP包被送到控制平面并通过认证后,生成PSFB,分配到控制平面。表目内容包括:源端口、源MAC(用于过滤),出端口和链路层信息。数据流随后的数据包查找该PSFB表目并做相应的操作即可。
2.ACL(访问控制列表)
访问列表(ACL)是基于包过滤的防火墙。它是一个有序的语句集,通过匹配报文中信息与访问表参数,来允报文通过或拒绝报文通过某个接口。访问表的主要作用是基于已经建立的标准来允许或拒绝报文流,这样,报文过滤标准将决定所实现的访问表类型。
对于路由器接口,一个访问表必须在创建之后应用到某个接口上,它才能产生作用。因为通过接口的数据流是双向的,所以访问表要应用到接口的特定方向上,向外的方向或者向内的方向。此处,术语“向内的(inbound)”表示数据流流向路由器,而“向外的(outbound)”表示数据流从路由器流出。
因此,数据流的第一个包被送往控制平面进行过滤条目的逐条匹配,然后知道该数据流是应该转发还是丢弃,如果应该转发,再去查找相应的路由表,得出出端口和下一跳链路层信息。表目内容包括;转发标志位、出端口和下一跳链路层信息。数据流随后的数据包查找该PSFB表目并做相应的操作即可。
3.策略路由:
数据流的第一个包,被送往控制平面进行策略路由条目的逐条匹配,查找到相应的表目位后,生成相应的PSFB表目,并下载到转发平面。表目内容包括:出端口、下一跳链路层信息和转发标志位。数据流随后的数据包查找该PSFB表目并做相应的操作即可。
4.WEB认证:
认证数据包送控制平面处理,数据流的第一个包送控制平面处理,查找相应的路由条目,并分发到转发平面。表目内容包括:源物理端口、源IP地址、VLAN ID、转发标志位、出端口和下一跳链路层信息。
5.移动IP:
移动节点首先完成在归属代理(即路由器)的注册。然后,数据流的第一个包被送往控制平面,按照RFC2003或RFC2004的隧道封装格式进行封装,并生成转发表目分发到转发平面。表目内容包括:源IP地址、网关IP(Gateway IP),隧道ID、出端口和下一跳链路层消息。数据流随后的数据包查找该PSFB表目并做相应的操作即可。
6.计费:
针对每个数据流,表目创建时,由控制平面写入起始时间,表目老化删除时,记下结束时间。转发过程中,记录发送的数据包的个数和字节个数。表目过期时,将五元组、FlowID以及包和字节的统计计数,起始和结束的时间送到控制平面,并由控制平面送给计费服务器,服务器根据路由器所提供的计费源信息,包括<源IP,目的IP,源协议端口,目的协议端口,协议类型,包计数,字节技术,起始时间,结束时间>,由服务器的计费策略(基于时长、流量或服务质量)生成统一的帐单。
本节的方法对基于Ipv6和移动互联的网络同样适用。
本发明在设备上的布局和实现方法
图5示出了本发明的以策略流方式转发数据的数据转发设备的构成的示意方框图。如图5所示,该数据转发设备,包括至少一转发平面和一控制平面,该转发平面包括:流ID计算部分,用于根据该数据包的多元属性组计算出计算出标识该数据流的流ID;查找部分,用于按照精确匹配去查找一存储器中的策略流转发表(PSFB),看是否有与该数据包的流ID相匹配的PSFB表目;修改和转发部分,如果发现匹配,则按照所述PSFB表目对该数据包进行相关内容修改和转发操作,然后转发平面转向处理下一个数据包如不匹配,将该数据包送到控制平面;
所述控制平面中存有与数据转发相关的路由表和业务表目,并且包括:PSFB表生成部分,用于为所述未匹配的数据包查找相关的路由表和业务表目,得到下一跳所对应的转发信息和业务相关信息,并生成用于该数据流的PSFB表目,该PSFB表包括对所述数据包计算出的流ID、下一跳所对应的转发信息和业务相关信息与数据转发相关的路由表和业务表目,并将该PSFB表目分发到所述转发平面;
该设备还包括存储器,用于存储所述生成的PSFB表目,并供所述转发平面为同一数据流的随后的数据包查找使用。
所述控制平面还包括:策略处理部分,用于从与该数据包相关的业务表目中,得到对该数据包所在数据流应该进行的业务操作类型,即策略类型,并将该策略类型放入所述PSFB表目中,以供该整个数据流使用,并且所述转发信息包括该数据流的下一跳所对应的出端口索引和链路层信息。
所述转发平面的修改和转发部分从所述PSFB表中的该数据流的策略类型得知对该数据流的数据包应该进行的业务操作,并对所述数据包进行所述策略操作,然后根据所述下一跳所对应的出端口索引和链路层信息转发该数据包。
所述转发平面可以包括一个PSFB表更新部分,用于判断PSFB的老化情况和决定是否删除,其中,对于非TCP连接情况和非正常关闭的TCP连接情况,在PSFB表中设置一个超时标识,该PSFB表每被匹配的数据包使用一次即刷新该超时标识,并且所述控制平面还包括一定时器,每隔一定时间去检查该标识,如果该标识在一定时间内没有被刷新,说明该PSFB表已经老化,则删除该PSFB表;对于正常TCP连接的数据流,通过判断FIN包和RESET包来确定数据包的结束,并决定是否删除一PSFB表。该时间可以由网管设置。
所述转发平面的修改和转发部分在进行所述策略操作后,对该数据包进行TTL减一和计算校验和或修改源MAC地址等操作后,再将该数据包从出端口发出,并将该数据流的相应PSFB表中的超时标识重新置位。
该设备还可以包括一排队处理部分,用于在所述各个转发平面送往控制平面的数据流的第一个数据包的过程中进行排队处理,即控制单位时间内排队的数据包长度,使该队列的深度由该存储器剩余的表目存储空间来决定。
该设备还可以包括存储空间控制部分,用于随着所述存储器中表目空间的变小而缩短新建PSFB表目的老化时间,使得表目加快老化速度,使表目空间相对加大。
所述存储器可以包括一SRAM和一SDRAM,用于以两级方式存储所述PSFB表目,其中在SRAM上存储对应于每一个流ID的索引,而实际PSFB表目存储在SDRAM中,所述索引指向SDRAM中的表项。此外,策略流转发所使用存储器并不局限于SRAM和SDRAM,存储方式也不局限于以上提到的二级存储方式。
以下描述本发明的上述设备的应用实例,即在武汉烽火网络公司的HSR-2002(High-speed Switched Router 2002)上的具体应用。
武汉烽火网络公司研制的HSR-2002是定位于城域网汇聚层和城域网主干层的路由交换设备,它支持多种接口种类和具有灵活的业务生成能力。当HSR-2002定位于城域网汇聚层的网络设备时,它主要完成对城域网中接入层上联链路的汇接(Metro Aggregation),在用户侧能够接入Fast Ethernet、Gigabit Ethernet和低速ATM等信号,并提供智能业务生成(Service Creation)功能,为运营商提供各种增值功能,而在网络层通过GE或PoS和城域网主干层设备相连。此外,HSR-2002也可以通过Packet Over Sonet/SDH接口和SDH本地环连接,或者通过GE组成环形或星形网络,组成城域网的主干,并通过OC-48 POS和主干网设备相连。
从组网的需求来看,HSR-2002上需要实现RIP和0SPF等域内协议和BGP-4等域间协议,在链路层支持PPP、Ethernet、LAPS和HDLC等协议。从应用的角度来说,HSR-2002能够提供实现单播、组播和MPLS转发,并提供NAT、Firewall、VPN、Virtual Router和移动IP等应用。此外,考虑到目前国内接入层的组网方式,HSR-2002上该能够提供二层应用(VLAN)的支持。作为提供给运营商的增值功能,HSR-2002目前可以提供基于端口和PPPoE Session的带宽限制和QoS保证。从对用户的管理角度来说,HSR-2002目前可以提供基于PPPoE的认证方式,并能通过Radius来实现对用户流量的计费。此外,还支持VLAN+IP+MAC的三级绑定和Web认证。本节的方法对基于Ipv6和移动互联的网络同样适用。
HSR-2002的机架采用工业标准的19”机箱,盘位间距25.4mm,总共16个槽位,其中主控CPU和交换盘占用2个槽位,剩余14个槽位提供给线卡使用,线卡为9U。
图6示出本发明的应用的通用机架布局图。图6中,黑色箭头代表高速数据总线,绿色箭头代表高速控制总线。
如图6所示,交换卡通过高速串行的数据总线和各个线卡连接,该数据总线提供了路由器的高速数据通道;而主控处理卡和各个线路接口卡之间采用了高速的控制总线,它用来提供路由表、ACL和认证表目的更新,以及控制数据包和网管数据包的传输。其中,控制平面的软件运行在主控CPU和各个线卡的CPU上,而转发平面由分布在各个线卡的网络处理器(NetworkProcessor)上,由其中的微代码来实现。而ISMP协议则运行于线路接口卡上RISC处理器的协议软件和网络处理器上的微代码之间。
当采用策略流转发时,每个数据流的第一个数据包将被网络处理器送到线路接口卡的RISC处理器上,由它完成路由表的查找和其它业务操作(如移动IP)。然后,它将生成一条PSFB表目,并将它下载到SRAM和SDRAM中。由于采用了精确查找,而PSFB的表目的存储采用了两级存储的方式,首先在SRAM上存有对应每一个Stream ID的索引,而由这一索引指向SDRAM中的实际表项,而这一表项的索引采用了Hash的算法。目前情况下,每条流转发表目为128Bytes,在HSR-2002上,每个接口卡支持64K个Stream,因此PSFB所占用的SDRAM空间为128*64K=8M空间,本发明使用的空间是从SDRAM起始地址0x3ff0000开始的8MBytes空间。而SRAM由于只需要存放相关表目的索引,因此只需要64K*4=256KBytes空间,本发明使用的SRAM中的起始地址为0xc120000。而由于每个流都是单向的,因此每个流仅存在于各个线卡中,所以整个系统可以支持64K*14=896K个Stream。如果考虑到每个用户上网时平均有20个Stream,则HSR-2002共可以支持45K,即45,000个用户同时在线。
图7示出本发明的数据转发设备的线路接口卡布局图。如图7所示,在HSR-2002中,策略流转发的过程如下:
1)数据包进入HSR-2002,通过物理层芯片和成帧器进入到网络处理器中,网络处理器中的微代码首先根据<源地址、源协议端口、目的协议端口、协议类型>计算出对应的Stream ID。
(2)微代码根据(1)所得出的流ID按照精确查找(Exact Match)在SRAM中去查找流转发表(PSFB)。如果发现匹配则进行(3),否则进行(5)。
(3)如果发现匹配,则根据SRAM的索引找到SDRAM中的表项,首先根据策略类型知道需要何种业务操作,然后根据Output Port Index表项所指向的邻接表(Adiacency Table)表项得出出端口(Output Port)和对应的链路层消息(如MAC地址)(注:如果是组播转发,此处则是出端口列表)。
(4)微代码进行对数据包的策略操作,并进行TTL减一和计算校验和等操作后,将该数据包从出端口发出,并将Expired Flag位重新置位,并到(9)
(5)如果没有表目匹配,则说明这是数据流的第一个包或者是PSFB表目已经老化,微代码将对该数据包通过ISMP的数据交换消息送到线路接口卡上的RISC处理器进行处理。
(6)RISC处理器上的控制平面软件查找相关的路由表和业务表目(如PPPoE、NAT),得到下一跳所对应的出端口和链路层信息和业务相关信息,并构造PSFB表目,表目的内容包括流ID、出端口索引(在组播中为出端口列表)和策略类型等信息。
(7)该软件通过ISMP的表添加消息将该表目分发到控制平面,写入SDRAM和SRAM的相应空间。
(8)数据流随后的数据包查找该PSFB表目并做(3)和(4)操作即可。
(9)结束操作,处理下一个数据包。
采用了基于策略流转发的线速转发技术,HSR-2002可以最多支持45,000个用户的在线接入,并能提供线速的IPV4单播、组播转发能力和支持PPPoE、Web认证和NAT等应用。
此外,它能无缝的和其他厂家的网络设备完成互联互通。本节的方法对基于Ipv6和移动互联的网络同样适用。
从以上对本发明的详细描述可以看出,本发明的技术优势和创新点如下:
1.与MPLS技术不同,在不改变设备硬件结构和不引入其他网络间信令的前提下,只是通过改变设备内部的逻辑流程,提高了转发性能,并支持多种应用。
2.和传统的基于包IP转发不同,采用了基于流处理而不是基于每个数据包处理的思想,对一个数据流只需要做一次复杂处理即可,大大提高了转发性能。
3。和Cisco的Netflow技术不同,首次在转发表中采用统一而且唯一的策略业务流转发表目,不需要引入其它的转发表目,也不需要根据业务种类的不同去查找不同的表目,大大简化了转发平面(Simplified Forwarding Plane)的处理。
4.在转发平面的查找中采用了统一的精确查找的方式,而不是传统的最长匹配的方式,使得访问内存的次数大为减少,查找效率大大提高,解决了基于最长匹配的查找策略导致查找效率低下的问题。
5.采用多元组(如源IP地址、目的IP地址、源端口、目的端口和协议类型等)来标识一个IP业务流,在转发平面采用统一的策略流转发表PSFB,并提供丰富的可扩展的表项,可以根据业务操作类型来决定对数据包的处理,可以用来增长用户的各种需要应用,并为用户提供定制业务的接口,第一次使得用户定制业务成为可能。
6.相对于ACL或策略路由等需要对数据包进行逐条匹配的查找应用而言,策略流方法使路由器或三层交换设备的转发性能成指数提高。
7.不需要针对不同的应用去进行复杂的网络处理器编程,大大缩减了设备开发的时间和降低了设备开发成本。
8.本发明所构造的方法,使得采用专用大规模集成电路支持可扩展的网络业务成为可能。
综上所述,策略流转发技术采用了基于策略流而不是针对每个数据包处理的思路,在不额外引入节点间路由等信令协议、保证原Internet网中所有互联互通协议(如IETF系列协议)不变和完全不改变路由器体系结构和硬件设计的前提下,大大提高了转发平面的转发效率,使得线速的策略转发成为可能。此外,它采用了统一的策略流转发表(PSFB),这也使得网络设备在支持多种应用的同时能够向运营商提供业务定制的能力,能够满足目前用户和运营商对业务多样性的需求。最后,对设备开发商来说,策略流转发技术采用了简化的转发平面,这将大大减少了转发平面的开发工作,并使得采用ASIC来实现复杂的网络业务成为可能。本发明的方法对基于Ipv6的网络中的接入层、汇聚层和骨干层等二三层路由交换设备以及移动互联网络中的SGSN、GGSN、IGSN和PDSN设备同样适用。
以上用优选实施例,已经叙述和说明了本发明的原理。很明显,不偏离本发明的精神和范围,本领域技术人员能够在结构和细节上对发明进行修改和变型。所有这些变化和改变都应落在所附权利要求定义范围内。
Claims (28)
1、一种在网络设备中以策略流方式转发数据的方法,所述网络设备包括至少一转发平面和一控制平面,其特征在于,该方法包括以下步骤:
(a)在一转发平面接收至少一数据流的数据包;
(b)在转发平面根据该数据包的多元属性组计算出标识该数据流的流ID;
(c)转发平面根据步骤(b)所得出的流ID按照精确匹配去查找一策略流转发表(PSFB),如果发现匹配则进行步骤(d),否则进到步骤(e);
(d)如果发现匹配,则按照所述PSFB表目对该数据包进行相关内容修改和转发操作,然后进到步骤(h)处理下一个数据包;
(e)如果没有表目匹配,则说明这是数据流的第一个包或者是PSFB表目已经老化,转发平面将把该数据包送到控制平面;
(f)控制平面为该数据包查找相关的路由表和业务表目,得到下一跳所对应的转发信息和业务相关信息,并生成用于该数据流的PSFB表目,该PSFB表包括对所述数据包计算出的流ID、下一跳所对应的转发信息和业务相关信息;
(g)控制平面将该PSFB表目分发到所述转发平面;和
(h)对该数据流中随后的数据包,在所述转发平面使用该PSFB表目进行所述步骤(c)和(d)的转发操作,以将其转发到相应的接收方。
2、根据权利要求1所述的方法,其中在所述步骤(f)中控制平面从与该数据包相关的业务表目中,得到对该数据包所在数据流应该进行的业务操作类型,即策略类型,并将该策略类型放入所述PSFB表目中,以供该整个数据流使用,并且所述转发信息包括该数据流的下一跳所对应的出端口索引和链路层信息。
3、根据权利要求2所述的方法,其中在所述步骤(d)中,转发平面从所述PSFB表中的该数据流的策略类型得知对该数据流的数据包应该进行的业务操作,并对所述数据包进行所述策略操作,然后根据所述下一跳所对应的出端口和链路层信息转发该数据包。
4、根据权利要求3所述的方法,其中所述转发平面中的PSFB表中设置一个超时标识用于非TCP连接情况和非正常关闭的TCP连接情况,该PSFB表每被匹配的数据包使用一次即刷新该超时标识,所述控制平面每隔一定时间去检查该标识,如果该标识在一定时间内没有被刷新,说明该PSFB表已经老化,则删除该PSFB表。
5、根据权利要求4所述的方法,其中,在所述步骤(d)中在进行所述策略操作后,对该数据包进行TTL减一和计算校验和或修改源MAC地址等操作后,再将该数据包从出端口发出,并将该数据流的相应PSFB表中的超时标识重新置位。
6、根据权利要求5所述的方法,其中,所述的PSFB表目是存储在一存储器中,在所述各个转发平面送往控制平面的数据流的第一个数据包的过程中采用排队机制,即控制单位时间内排队的数据包长度,使该队列的深度由该存储器剩余的表目存储空间来决定。
7、根据权利要求6所述的方法,其中随着所述表目空间的变小而缩短新建PSFB表目的老化时间,使得表目加快老化速度,使表目空间相应加大。
8、如权利要求7所述的方法,其中对于正常TCP连接的数据流,通过判断FIN包和RESET包来确定数据包的结束,并决定是否删除一PSFB表。
9、如权利要求1所述的方法,其中所述步骤(b)中所述流ID的计算是采用散列算法,并且所述PSFB表目存有对应每一个Stream ID的索引,而由这一索引指向PSFB中的实际表项,而这一表项的索引采用散列算法。
10、如权利要求1所述的方法,其中所述控制平面和转发平面逻辑上可以为同一物理实体。
11.根据权利要求1-10任何之一所述的方法,其中所述数据包的多元属性组包括数据包的入物理端口、出物理端口、虚拟局域网标识(VLAN ID)、目的地址(包括IPv4、IPv6或MAC地址)、源地址(包括IPv4、IPv6或MAC地址)、协议类型、目的协议端口、源协议端口、PPPoE协议的会话ID(Session ID)、业务类型(TOS)、MPLS标记和隧道(Tunnel)ID中的任意m个的组合;并且所述策略流转发表中所包括以下内容的一个子集,并且所述PSFB表目中至少包括:为一数据流生成的所述流ID以及数据流的策略类型(Policy-Type)和出端口索引(Output Port Index,用于单播)或MulticastPort(用于组播)其中的一项。
Source IP:数据流的源IP地址,Ipv4时为4字节,Ipv6时为32字节。
Destination IP:数据流的目的IP地址,Ipv4时为4字节,Ipv6时为32字节。
Protocol Type:协议类型
Source Protocol Port:源协议端口,由协议类型来决定为何种协议的端口
Destination Protocol Port:目的协议端口,由协议类型来决定为何种协议的端口
Stream ID:由以上m元组所对应的数据流的唯一的流ID
Start of Time:起始时间,数据流的起始时间
End of Time:结束时间,数据流的结束时间
Alias Port:伪端口,网络地址转换后的协议端口
Alias Address:伪IP地址,网络地址转换后的IP地址
Session ID:PPPoE会话ID
Quality of Services:服务质量参数
Multicast Port:组播端口标识,通过位操作来指示组播端口
Source MAC:标识数据流源MAC Address
Destination MAC:标识数据流的目的MAC地址
Source Port:标识数据流所来自的源物理端口
Destination Port:标识数据流的目的物理端口
TunnelID:隧道ID
Gateway IP:网关IP地址
Transmit Packet:传送的数据包的个数
Transmit Byte:发送的字节个数
VLAN ID:VLAN ID
Forwarding Flag:转发标志位,决定是否转发该数据流
DSCP:用于区分业务。
Policy Type:策略类型,表明对数据流该进行的何种业务操作类型,可由网管灵活配置或用户进行业务定制
Expired Timer:超时定时器,判断该流转发表目是否超时
TCP Flag:TCP标志位,用来判断TCP流是否结束
MPLS Label:多协议标记交换的标记
12、如权利要求11所述的方法,其中,对于IPv4单播转发数据流,对于第一个数据包,在所述步骤(e)通过数据交互消息(PEM)将第一个数据包发送到控制平面;在所述步骤(f)控制平面查找URT(单播路由表),通过最长匹配算法查到下一跳所对应的出端口和链路层信息,并构造PSFB表目,表目的内容包括流ID、出端口索引和策略类型(单播路由),并且在步骤(g)控制平面通过流表目添加消息将该表目分发到转发平面;对于后续的数据包,在所述步骤(d)首先根据策略类型知道需要进行单播IPv4转发,然后根据Output Port Index表项所指向的邻接表(Adjacency Table)表项得出出端口(Output Port)和对应的链路层消息(如MAC地址),转发平面进行对数据包进行TTL减一和计算校验和等操作后,将该数据包从出端口发出,并将超时标识重新置位。
13、如权利要求11所述的方法,其中,对于IPv4组播转发数据流,对于第一个数据包,在所述步骤(e)通过数据交互消息(PEM)将第一个数据包发送到控制平面;在所述步骤(f)在控制平面首先查找单播路由表(URT)来进行RPF(Reverse Path Forwarding),来决定该包是否能够被转发,然后根据协议的不同,分别通过<*,G>、<S,G>或<RPT,S,G>来查找组播路由表(MRT),得出端口列表,并构造PSFB,表目的内容包括流ID、Multicast Port和策略类型(组播路由);并且在步骤(g)控制平面通过流表目添加消息将该表目分发到转发平面;对于后续的数据包,在所述步骤(d)首先根据策略类型得知需要进行组播转发,然后根据PSFB表项中的Multicast Port位进行位操作判断,并通过所置位所对应的邻接表(Adjacency Table)表项得出所有的出端口(Output Port)和对应的链路层消息(如MAC地址)转发平面进行对数据包进行TTL减一和计算校验和等操作后,将该数据包从出端口发出,并将超时标识重新置位。
14、如权利要求11所述的方法,其中,对于PPPoE数据流,对于第一个数据包,在所述步骤(e)通过数据交互消息(PEM)将第一个数据包发送到控制平面;在所述步骤(f)在控制平面首先查找PPPoE的会话(Session)表项来决定该包是否能够被转发,如果能够则查找单播路由表(URT)并构造PSFB,表目的内容包括流ID、操作类型、Session ID、源MAC地址和源物理端口(用于认证和过滤)和策略类型(PPPoE转发);并且在步骤(g)控制平面通过流表目添加消息将该表目分发到转发平面;对于后续的数据包,在所述步骤(d)首先根据策略类型得知需要进行PPPoE处理,然后根据PSFB表项中的Session ID、源物理端口和源MAC地址对数据包的相应内容进行比较验证,如果验证失败,则结束该数据包的操作,去处理下一个数据包;否则通过出端口索引所对应的邻接表(Adjacency Table)表项得出出端口(Output Port)和对应的链路层消息(如MAC地址);转发平面还进行对数据包进行去PPPoE包头、TTL减一和计算校验和等操作后,将该数据包从所有的出端口发出,并将Expired Flag位重新置位。
15、如权利要求11所述的方法,其中,对于NAT+单播转发数据流,对于第一个数据包,在所述步骤(e)通过数据交互消息(PEM)将第一个数据包发送到控制平面;在所述步骤(f)在控制平面首先查找NAT转换表,如果表目不存在,则为该数据包分配一个新的Alias Port并从地址池中重新分配一个Alias Adddress,如果能够,则查找单播路由表(URT)并构造PSFB,表目的内容包括流ID、Alias Port、Alias Address和策略类型(NAT和单播转发);并且在步骤(g)控制平面通过流表目添加消息将该表目分发到转发平面;对于后续的数据包,在所述步骤(d)首先根据策略类型得知需要进行NAT处理和单播转发,然后通过PSFB的表项中的用PSFB表项中的Alias Port和Alias IP Address替换数据包中的相关内容;转发平面进行对数据包TTL减一和计算校验和等操作后,将该数据包从所有的出端口发出,并将ExpiredFlag位重新置位。
16、如权利要求11所述的方法,其中,对于IPv6转发数据流,对于第一个数据包,在所述步骤(e)通过数据交互消息(PEM)将第一个数据包发送到控制平面;在所述步骤(f)在控制平面查找IPv6路由表,通过最长匹配算法查到下一跳所对应的出端口和链路层信息,并构造PSFB表目,表目的内容包括流ID、出端口索引和策略类型(单播路由);并且在步骤(g)控制平面通过流表目添加消息将该表目分发到转发平面;对于后续的数据包,在所述步骤(d)首先根据策略类型知道需要进行IPv6转发,然后根据Output PortIndex表项所指向的邻接表(Adjacency Table)表项得出出端口(Output Port)和对应的链路层消息(如MAC地址);转发平面进行对数据包进行TTL减一和计算校验和等操作后,将该数据包从出端口发出,并将Expired Flag位重新置位。
17、如权利要求11所述的方法,其中所述策略流转发表目(PSFB)支持IPv4、IPv6单播和组播转发、二层转发(包括基于VLAN)、MPLS转发(包括LSR和LER)和PPPoE、网络地址转换、802.1X、WEB认证、策略路由、访问控制列表、计费、虚拟专用网、GTP和移动IP等应用,它的具体内容由应用和策略类型来决定。
18、如权利要求17所述的方法,其中针对每个数据流,在表目创建时,由控制平面写入起始时间,表目老化删除时,记下结束时间;转发过程中,记录发送的数据包的个数和字节个数;表目过期时,将多元组、流ID以及包和字节的统计计数,起始和结束的时间送到控制平面,并由控制平面送给计费服务器,服务器根据路由器所提供的计费源信息,包括:源MAC地址、目的MAC地址、源IP地址,目的IP地址,源协议端口,目的协议端口,协议类型,包计数,字节计数,起始时间,结束时间,由服务器的计费策略(基于时长、流量、应用或服务质量)生成统一的帐单。
19、一种以策略流方式转发数据的数据转发设备,包括至少一转发平面,其每个接收至少一数据流的数据包;和一控制平面,其特征在于,
所述转发平面包括:
流ID计算部分,用于根据该数据包的多元属性组计算出计算出标识该数据流的流ID;
查找部分,用于按照精确匹配去查找一存储器中的策略流转发表(PSFB),看是否有与该数据包的流ID相匹配的PSFB表目;
修改和转发部分,如果发现匹配,则按照所述PSFB表目对该数据包进行相关内容修改和转发操作,然后转发平面转向处理下一个数据包如不匹配,将该数据包送到控制平面;
其中,所述控制平面中存有与数据转发相关的路由表和业务表目,并且包括:
PSFB表生成部分,用于为所述未匹配的数据包查找相关的路由表和业务表目,得到下一跳所对应的转发信息和业务相关信息,并生成用于该数据流的PSFB表目,该PSFB表包括对所述数据包计算出的流ID、下一跳所对应的转发信息和业务相关信息与数据转发相关的路由表和业务表目,并将该PSFB表目分发到所述转发平面;
存储器,用于存储所述生成的PSFB表目,并供所述转发平面为同一数据流的随后的数据包查找使用。
20、根据权利要求19所述的设备,其中,所述控制平面还包括:
策略处理部分,用于从与该数据包相关的业务表目中,得到对该数据包所在数据流应该进行的业务操作类型,即策略类型,并将该策略类型放入所述PSFB表目中,以供该整个数据流使用,并且所述转发信息包括该数据流的下一跳所对应的出端口索引和链路层信息。
21、根据权利要求20所述的设备,其中所述转发平面的修改和转发部分从所述PSFB表中的该数据流的策略类型得知对该数据流的数据包应该进行的业务操作,并对所述数据包进行所述策略操作,然后根据所述下一跳所对应的出端口索引和链路层信息转发该数据包。
22、根据权利要求21所述的设备,其中所述转发平面包括一个PSFB表更新部分,用于判断PSFB的老化情况和决定是否删除,其中,对于非TCP连接情况和非正常关闭的TCP连接情况,在PSFB表中设置一个超时标识,该PSFB表每被匹配的数据包使用一次即刷新该超时标识,并且所述控制平面还包括一定时器,每隔一定时间去检查该标识,如果该标识在一定时间内没有被刷新,说明该PSFB表已经老化,则删除该PSFB表;对于正常TCP连接的数据流,通过判断FIN包和RESET包来确定数据包的结束,并决定是否删除一PSFB表。
23、根据权利要求22所述的设备,其中所述转发平面的修改和转发部分在进行所述策略操作后,对该数据包进行TTL减一和计算校验和或修改源MAC地址等操作后,再将该数据包从出端口发出,并将该数据流的相应PSFB表中的超时标识重新置位。
24、根据权利要求19-23任何之一所述的设备,还包括一排队处理部分,用于在所述各个转发平面送往控制平面的数据流的第一个数据包的过程中进行排队处理,即控制单位时间内排队的数据包长度,使该队列的深度由该存储器剩余的表目存储空间来决定。
25、根据权利要求19-23任何之一所述的设备,还包括存储空间控制部分,用于随着所述存储器中表目空间的变小而缩短新建PSFB表目的老化时间,使得表目加快老化速度,使表目空间相应加大。
26、根据权利要求19-23任何之一所述的设备,其中,所述存储器可以包括一SRAM和一SDRAM,用于以两级方式存储所述PSFB表目,其中在SRAM上存储对应于每一个流ID的索引,而实际PSFB表目存储在SDRAM中,所述索引指向SDRAM中的表项。
27、根据权利要求19-23任何之一所述的设备,其中所述控制平面和转发平面逻辑上可以为同一物理实体。
28、根据权利要求19-23任何之一所述的设备,其中所述设备为路由器、网络交换机或移动互联网络中的GGSN、SGSN、IGSN和PDSN中之一。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB021248931A CN100359885C (zh) | 2002-06-24 | 2002-06-24 | 以策略流方式转发数据的方法和数据转发设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB021248931A CN100359885C (zh) | 2002-06-24 | 2002-06-24 | 以策略流方式转发数据的方法和数据转发设备 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN1466340A true CN1466340A (zh) | 2004-01-07 |
CN100359885C CN100359885C (zh) | 2008-01-02 |
Family
ID=34142756
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNB021248931A Expired - Fee Related CN100359885C (zh) | 2002-06-24 | 2002-06-24 | 以策略流方式转发数据的方法和数据转发设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN100359885C (zh) |
Cited By (74)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2006099782A1 (fr) * | 2005-03-21 | 2006-09-28 | Zte Corporation | Procédé de multidiffusion rapide et système idoine |
WO2007073690A1 (fr) * | 2005-12-27 | 2007-07-05 | Huawei Technologies Co., Ltd. | Interfonctionnement mondial pour systeme d'acces micro-onde et procede d'agencement de flux de services dans un systeme |
CN100334860C (zh) * | 2004-11-01 | 2007-08-29 | 杭州华为三康技术有限公司 | 提高设备转发性能的报文交互方法 |
CN100342740C (zh) * | 2004-05-06 | 2007-10-10 | 日本电气株式会社 | 数据传输系统和数据传输方法 |
CN100387019C (zh) * | 2005-04-04 | 2008-05-07 | 华为技术有限公司 | 跨混合网络的多协议标签交换虚拟专用网的实现方法 |
CN100438496C (zh) * | 2004-12-19 | 2008-11-26 | 华为技术有限公司 | 多协议标签交换虚拟专用网的网络传输方法 |
CN100442770C (zh) * | 2005-09-28 | 2008-12-10 | 华为技术有限公司 | 一种在bgp/mpls vpn实现组播的方法 |
WO2009021424A1 (en) * | 2007-08-13 | 2009-02-19 | Hangzhou H3C Technologies Co., Ltd. | A device and method for handling messages |
CN100464547C (zh) * | 2004-03-03 | 2009-02-25 | 联想(北京)有限公司 | 一种实现不同通信协议设备间信息传输的方法 |
CN100558047C (zh) * | 2007-01-26 | 2009-11-04 | 华为技术有限公司 | 一种路由表项的管理方法及系统 |
WO2010006520A1 (zh) * | 2008-07-15 | 2010-01-21 | 华为技术有限公司 | 数据流二层互通的方法和装置 |
CN101047650B (zh) * | 2007-04-19 | 2010-09-15 | 杭州华三通信技术有限公司 | 转发表关联方法及设备 |
CN101001363B (zh) * | 2006-06-29 | 2011-01-12 | 华为技术有限公司 | 一种数据单播的系统和方法 |
CN101296222B (zh) * | 2007-04-25 | 2011-02-02 | 北京天融信网络安全技术有限公司 | 一种提高防火墙芯片硬件加速性能的方法 |
CN101043440B (zh) * | 2006-03-25 | 2011-02-16 | 华为技术有限公司 | 一种WiMAX网络中支持多业务流操作的方法 |
CN101540724B (zh) * | 2009-04-28 | 2011-04-20 | 杭州华三通信技术有限公司 | 一种支持策略路由的转发方法和装置 |
CN102136986A (zh) * | 2010-01-22 | 2011-07-27 | 杭州华三通信技术有限公司 | 一种负载分担方法和交换设备 |
CN102164150A (zh) * | 2011-05-18 | 2011-08-24 | 北京星网锐捷网络技术有限公司 | 策略下发处理方法、设备、服务器和系统 |
CN102164078A (zh) * | 2011-03-25 | 2011-08-24 | 北京星网锐捷网络技术有限公司 | 策略路由方法、装置及系统 |
CN101176315B (zh) * | 2005-05-12 | 2011-09-21 | 松下电器产业株式会社 | 分组中继方法和归属代理 |
CN102273139A (zh) * | 2008-12-30 | 2011-12-07 | 惠普开发有限公司 | 存储网络流信息 |
CN102301663A (zh) * | 2011-07-06 | 2011-12-28 | 华为技术有限公司 | 一种报文处理方法及相关设备 |
CN101674193B (zh) * | 2009-08-21 | 2012-01-11 | 曙光信息产业(北京)有限公司 | 传输控制协议连接的管理方法和装置 |
CN1996991B (zh) * | 2006-01-06 | 2012-02-29 | 华为技术有限公司 | WiMAX网络中服务流策略的配置方法 |
CN102420759A (zh) * | 2011-11-30 | 2012-04-18 | 福建星网锐捷网络有限公司 | 标签交换路径建立方法、装置及系统、以及相应设备 |
CN102457430A (zh) * | 2010-10-20 | 2012-05-16 | 正文科技股份有限公司 | 网络封包处理方法及路由设备 |
CN101621416B (zh) * | 2009-08-05 | 2012-06-06 | 中兴通讯股份有限公司 | 保护类型的确定方法及装置 |
CN102497385A (zh) * | 2011-12-31 | 2012-06-13 | 曙光信息产业股份有限公司 | 一种网络流量审计方法及审计系统 |
CN102546405A (zh) * | 2011-12-27 | 2012-07-04 | 华为技术有限公司 | 协议栈的业务处理方法及装置 |
WO2012094919A1 (zh) * | 2011-01-14 | 2012-07-19 | 中兴通讯股份有限公司 | 一种策略控制方法及系统 |
CN102664816A (zh) * | 2012-05-30 | 2012-09-12 | 迈普通信技术股份有限公司 | 一种快速查找mpls转发表的装置及方法 |
CN102694727A (zh) * | 2012-05-21 | 2012-09-26 | 太仓市同维电子有限公司 | 实现网络数据包转发加速的方法及装置 |
CN102696205A (zh) * | 2010-01-06 | 2012-09-26 | 日本电气株式会社 | 通信控制系统和通信控制方法 |
CN102104528B (zh) * | 2009-12-21 | 2012-10-10 | 中国移动通信集团山西有限公司 | 一种应用于农村地区的网络系统及业务报文的传送方法 |
CN102801824A (zh) * | 2012-08-28 | 2012-11-28 | 山石网科通信技术(北京)有限公司 | Nat设备、napt设备和tcp应用引流的处理方法与处理系统 |
CN102821169A (zh) * | 2012-08-10 | 2012-12-12 | 华为技术有限公司 | 一种网络中mac地址表项创建的方法及网络设备 |
CN102882790A (zh) * | 2012-10-12 | 2013-01-16 | 北京锐安科技有限公司 | 一种IPv6实时数据流处理方法 |
CN101431511B (zh) * | 2007-11-09 | 2013-03-06 | 友讯科技股份有限公司 | 一种穿透防火墙在网络终端装置间建立联机信道的方法 |
CN102970224A (zh) * | 2012-12-07 | 2013-03-13 | 重庆金美通信有限责任公司 | 一种兼容atm体制并基于ip交换网络实现mpls报文转发方法 |
CN103036801A (zh) * | 2012-12-18 | 2013-04-10 | 网神信息技术(北京)股份有限公司 | 数据包的处理方法及装置 |
CN103095665A (zh) * | 2011-11-07 | 2013-05-08 | 中兴通讯股份有限公司 | 一种提升防火墙处理性能的方法和装置 |
CN101656670B (zh) * | 2008-08-14 | 2013-08-14 | 丛林网络公司 | 具有集成mpls-感知防火墙的路由装置 |
CN103428211A (zh) * | 2013-08-07 | 2013-12-04 | 华南理工大学 | 基于交换机的网络认证系统及其认证方法 |
CN103636252A (zh) * | 2012-06-12 | 2014-03-12 | 华为技术有限公司 | 数据包的处理方法和系统及设备 |
CN103748842A (zh) * | 2013-06-26 | 2014-04-23 | 华为技术有限公司 | 一种转发数据包的方法、装置和路由设备 |
WO2014067486A1 (zh) * | 2012-11-05 | 2014-05-08 | 华为技术有限公司 | 一种报文转发的方法及相应设备 |
WO2014101316A1 (zh) * | 2012-12-27 | 2014-07-03 | 中国科学院声学研究所 | 一种应用与网络融合驱动的多协议选路系统及方法 |
CN103973553A (zh) * | 2013-01-24 | 2014-08-06 | 华为技术有限公司 | 数据包的处理方法与网络设备 |
CN104009924A (zh) * | 2014-05-19 | 2014-08-27 | 北京东土科技股份有限公司 | 一种基于tcam和fpga的报文处理方法及装置 |
WO2014153758A1 (zh) * | 2013-03-28 | 2014-10-02 | 华为技术有限公司 | 一种报文传输的方法与交换设备和控制器 |
CN104660504A (zh) * | 2013-08-05 | 2015-05-27 | Agh科学技术大学 | 计算机网络中进行封包多路径路由选择的装置及其方法 |
WO2015074453A1 (zh) * | 2013-11-22 | 2015-05-28 | 华为技术有限公司 | 数据流转发路由的控制方法及装置 |
CN104734986A (zh) * | 2013-12-19 | 2015-06-24 | 华为技术有限公司 | 一种报文转发方法和装置 |
CN104754025A (zh) * | 2013-12-27 | 2015-07-01 | 英特尔公司 | 可编程分布式联网 |
WO2015172373A1 (zh) * | 2014-05-16 | 2015-11-19 | 华为技术有限公司 | 一种用于OpenFlow网络的数据处理方法和装置 |
CN105099992A (zh) * | 2014-04-29 | 2015-11-25 | 杭州迪普科技有限公司 | 一种报文修改装置及方法 |
CN105357126A (zh) * | 2015-11-12 | 2016-02-24 | 国电南瑞科技股份有限公司 | 应用于prp/hsr报文丢弃算法的查找表优化方法 |
CN101594345B (zh) * | 2008-05-26 | 2016-04-06 | 电信科学技术研究院 | 一种含参数消息的处理方法及系统、设备 |
CN105656801A (zh) * | 2015-12-31 | 2016-06-08 | 迈普通信技术股份有限公司 | 一种并发控制方法及装置 |
CN106330492A (zh) * | 2015-06-23 | 2017-01-11 | 华为技术有限公司 | 一种配置用户设备转发表的方法、装置及系统 |
CN107203635A (zh) * | 2017-06-07 | 2017-09-26 | 南开大学 | 一种基于最小略图的流模式下有向标签图的略图构建方法 |
CN107431707A (zh) * | 2015-03-27 | 2017-12-01 | 德国电信股份公司 | 针对欺诈报文保护通信网络的网络保护实体和方法 |
CN107682257A (zh) * | 2017-11-21 | 2018-02-09 | 凌云天博光电科技股份有限公司 | 数据传输方法和系统 |
CN107959603A (zh) * | 2017-10-27 | 2018-04-24 | 新华三技术有限公司 | 转发控制方法及装置 |
CN110098977A (zh) * | 2019-04-12 | 2019-08-06 | 中国科学院声学研究所 | 实时协议识别背景下的网络数据包按序存储方法及系统 |
CN110535771A (zh) * | 2018-05-24 | 2019-12-03 | 中兴通讯股份有限公司 | 一种数据转发方法、网络设备和计算机可读存储介质 |
CN110945843A (zh) * | 2017-07-19 | 2020-03-31 | 阿里巴巴集团控股有限公司 | 虚拟交换设备和方法 |
CN111614689A (zh) * | 2020-05-27 | 2020-09-01 | 北京天融信网络安全技术有限公司 | 一种用于状态防火墙的报文转发方法和装置 |
CN112333850A (zh) * | 2020-11-24 | 2021-02-05 | 展讯半导体(成都)有限公司 | 防止下行失步方法、通信装置和可读存储介质 |
CN112511362A (zh) * | 2019-09-16 | 2021-03-16 | 中国移动通信有限公司研究院 | 设备转发性能的测试方法、装置、设备、介质 |
CN112511495A (zh) * | 2020-11-05 | 2021-03-16 | 方一信息科技(上海)有限公司 | 面向分布式防火墙网络系统及接口卡数据流加速处理方法 |
CN113691452A (zh) * | 2020-05-18 | 2021-11-23 | 瞻博网络公司 | 转变多级混合层次化转发信息库格式 |
CN113783974A (zh) * | 2021-09-09 | 2021-12-10 | 烽火通信科技股份有限公司 | 一种动态下发map域规则的方法及装置 |
CN114079634A (zh) * | 2020-08-21 | 2022-02-22 | 深圳市中兴微电子技术有限公司 | 一种报文转发方法、装置及计算机可读存储介质 |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102158419B (zh) * | 2011-05-23 | 2016-05-04 | 深圳市共进电子股份有限公司 | 在家庭网关中实现数据包加速转发的方法 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6426943B1 (en) * | 1998-04-10 | 2002-07-30 | Top Layer Networks, Inc. | Application-level data communication switching system and process for automatic detection of and quality of service adjustment for bulk data transfers |
-
2002
- 2002-06-24 CN CNB021248931A patent/CN100359885C/zh not_active Expired - Fee Related
Cited By (118)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN100464547C (zh) * | 2004-03-03 | 2009-02-25 | 联想(北京)有限公司 | 一种实现不同通信协议设备间信息传输的方法 |
CN100342740C (zh) * | 2004-05-06 | 2007-10-10 | 日本电气株式会社 | 数据传输系统和数据传输方法 |
CN100334860C (zh) * | 2004-11-01 | 2007-08-29 | 杭州华为三康技术有限公司 | 提高设备转发性能的报文交互方法 |
CN100438496C (zh) * | 2004-12-19 | 2008-11-26 | 华为技术有限公司 | 多协议标签交换虚拟专用网的网络传输方法 |
US8392605B2 (en) | 2005-03-21 | 2013-03-05 | Zte Corporation | Method of fast-multicast and a system thereof |
CN100454893C (zh) * | 2005-03-21 | 2009-01-21 | 中兴通讯股份有限公司 | 一种快速组播的实现方法 |
WO2006099782A1 (fr) * | 2005-03-21 | 2006-09-28 | Zte Corporation | Procédé de multidiffusion rapide et système idoine |
CN100387019C (zh) * | 2005-04-04 | 2008-05-07 | 华为技术有限公司 | 跨混合网络的多协议标签交换虚拟专用网的实现方法 |
CN101176315B (zh) * | 2005-05-12 | 2011-09-21 | 松下电器产业株式会社 | 分组中继方法和归属代理 |
CN100442770C (zh) * | 2005-09-28 | 2008-12-10 | 华为技术有限公司 | 一种在bgp/mpls vpn实现组播的方法 |
WO2007073690A1 (fr) * | 2005-12-27 | 2007-07-05 | Huawei Technologies Co., Ltd. | Interfonctionnement mondial pour systeme d'acces micro-onde et procede d'agencement de flux de services dans un systeme |
CN1996991B (zh) * | 2006-01-06 | 2012-02-29 | 华为技术有限公司 | WiMAX网络中服务流策略的配置方法 |
CN101043440B (zh) * | 2006-03-25 | 2011-02-16 | 华为技术有限公司 | 一种WiMAX网络中支持多业务流操作的方法 |
CN101001363B (zh) * | 2006-06-29 | 2011-01-12 | 华为技术有限公司 | 一种数据单播的系统和方法 |
CN100558047C (zh) * | 2007-01-26 | 2009-11-04 | 华为技术有限公司 | 一种路由表项的管理方法及系统 |
CN101047650B (zh) * | 2007-04-19 | 2010-09-15 | 杭州华三通信技术有限公司 | 转发表关联方法及设备 |
CN101296222B (zh) * | 2007-04-25 | 2011-02-02 | 北京天融信网络安全技术有限公司 | 一种提高防火墙芯片硬件加速性能的方法 |
US8908689B2 (en) | 2007-08-13 | 2014-12-09 | Hangzhou H3C Technologies Co., Ltd. | Apparatus and method for processing packet |
WO2009021424A1 (en) * | 2007-08-13 | 2009-02-19 | Hangzhou H3C Technologies Co., Ltd. | A device and method for handling messages |
CN101431511B (zh) * | 2007-11-09 | 2013-03-06 | 友讯科技股份有限公司 | 一种穿透防火墙在网络终端装置间建立联机信道的方法 |
CN101594345B (zh) * | 2008-05-26 | 2016-04-06 | 电信科学技术研究院 | 一种含参数消息的处理方法及系统、设备 |
WO2010006520A1 (zh) * | 2008-07-15 | 2010-01-21 | 华为技术有限公司 | 数据流二层互通的方法和装置 |
CN101656670B (zh) * | 2008-08-14 | 2013-08-14 | 丛林网络公司 | 具有集成mpls-感知防火墙的路由装置 |
CN102273139A (zh) * | 2008-12-30 | 2011-12-07 | 惠普开发有限公司 | 存储网络流信息 |
CN102273139B (zh) * | 2008-12-30 | 2015-04-15 | 惠普开发有限公司 | 存储网络流信息 |
CN101540724B (zh) * | 2009-04-28 | 2011-04-20 | 杭州华三通信技术有限公司 | 一种支持策略路由的转发方法和装置 |
CN101621416B (zh) * | 2009-08-05 | 2012-06-06 | 中兴通讯股份有限公司 | 保护类型的确定方法及装置 |
CN101674193B (zh) * | 2009-08-21 | 2012-01-11 | 曙光信息产业(北京)有限公司 | 传输控制协议连接的管理方法和装置 |
CN102104528B (zh) * | 2009-12-21 | 2012-10-10 | 中国移动通信集团山西有限公司 | 一种应用于农村地区的网络系统及业务报文的传送方法 |
CN102696205B (zh) * | 2010-01-06 | 2015-03-04 | 日本电气株式会社 | 通信控制系统和通信控制方法 |
US9432283B2 (en) | 2010-01-06 | 2016-08-30 | Nec Corporation | Communication control system and communication control method |
CN102696205A (zh) * | 2010-01-06 | 2012-09-26 | 日本电气株式会社 | 通信控制系统和通信控制方法 |
CN102136986A (zh) * | 2010-01-22 | 2011-07-27 | 杭州华三通信技术有限公司 | 一种负载分担方法和交换设备 |
CN102136986B (zh) * | 2010-01-22 | 2013-11-06 | 杭州华三通信技术有限公司 | 一种负载分担方法和交换设备 |
CN102457430B (zh) * | 2010-10-20 | 2015-04-08 | 正文科技股份有限公司 | 网络封包处理方法及路由设备 |
CN102457430A (zh) * | 2010-10-20 | 2012-05-16 | 正文科技股份有限公司 | 网络封包处理方法及路由设备 |
WO2012094919A1 (zh) * | 2011-01-14 | 2012-07-19 | 中兴通讯股份有限公司 | 一种策略控制方法及系统 |
US9271220B2 (en) | 2011-01-14 | 2016-02-23 | Zte Corporation | Policy control method and system |
CN102164078B (zh) * | 2011-03-25 | 2014-07-02 | 北京星网锐捷网络技术有限公司 | 策略路由方法、装置及系统 |
CN102164078A (zh) * | 2011-03-25 | 2011-08-24 | 北京星网锐捷网络技术有限公司 | 策略路由方法、装置及系统 |
CN102164150B (zh) * | 2011-05-18 | 2013-08-14 | 北京星网锐捷网络技术有限公司 | 策略下发处理方法、设备、服务器和系统 |
CN102164150A (zh) * | 2011-05-18 | 2011-08-24 | 北京星网锐捷网络技术有限公司 | 策略下发处理方法、设备、服务器和系统 |
US9385886B2 (en) | 2011-07-06 | 2016-07-05 | Huawei Technologies Co., Ltd. | Method for processing a packet and related device |
WO2012106869A1 (zh) * | 2011-07-06 | 2012-08-16 | 华为技术有限公司 | 一种报文处理方法及相关设备 |
CN102301663A (zh) * | 2011-07-06 | 2011-12-28 | 华为技术有限公司 | 一种报文处理方法及相关设备 |
CN102301663B (zh) * | 2011-07-06 | 2013-11-06 | 华为技术有限公司 | 一种报文处理方法及相关设备 |
CN103095665A (zh) * | 2011-11-07 | 2013-05-08 | 中兴通讯股份有限公司 | 一种提升防火墙处理性能的方法和装置 |
CN102420759A (zh) * | 2011-11-30 | 2012-04-18 | 福建星网锐捷网络有限公司 | 标签交换路径建立方法、装置及系统、以及相应设备 |
CN102420759B (zh) * | 2011-11-30 | 2015-01-21 | 福建星网锐捷网络有限公司 | 标签交换路径建立方法、装置及系统、以及相应设备 |
CN102546405A (zh) * | 2011-12-27 | 2012-07-04 | 华为技术有限公司 | 协议栈的业务处理方法及装置 |
CN102546405B (zh) * | 2011-12-27 | 2015-05-13 | 华为技术有限公司 | 协议栈的业务处理方法及装置 |
CN102497385A (zh) * | 2011-12-31 | 2012-06-13 | 曙光信息产业股份有限公司 | 一种网络流量审计方法及审计系统 |
CN102694727A (zh) * | 2012-05-21 | 2012-09-26 | 太仓市同维电子有限公司 | 实现网络数据包转发加速的方法及装置 |
CN102664816B (zh) * | 2012-05-30 | 2015-08-19 | 迈普通信技术股份有限公司 | 一种快速查找mpls转发表的装置及方法 |
CN102664816A (zh) * | 2012-05-30 | 2012-09-12 | 迈普通信技术股份有限公司 | 一种快速查找mpls转发表的装置及方法 |
CN103636252B (zh) * | 2012-06-12 | 2018-07-03 | 华为技术有限公司 | 数据包的处理方法和系统及设备 |
CN103636252A (zh) * | 2012-06-12 | 2014-03-12 | 华为技术有限公司 | 数据包的处理方法和系统及设备 |
CN102821169B (zh) * | 2012-08-10 | 2015-12-09 | 华为技术有限公司 | 一种网络中mac地址表项创建的方法及网络设备 |
CN102821169A (zh) * | 2012-08-10 | 2012-12-12 | 华为技术有限公司 | 一种网络中mac地址表项创建的方法及网络设备 |
CN102801824A (zh) * | 2012-08-28 | 2012-11-28 | 山石网科通信技术(北京)有限公司 | Nat设备、napt设备和tcp应用引流的处理方法与处理系统 |
CN102801824B (zh) * | 2012-08-28 | 2015-07-01 | 山石网科通信技术有限公司 | Nat设备、napt设备和tcp应用引流的处理方法与处理系统 |
CN102882790A (zh) * | 2012-10-12 | 2013-01-16 | 北京锐安科技有限公司 | 一种IPv6实时数据流处理方法 |
WO2014067486A1 (zh) * | 2012-11-05 | 2014-05-08 | 华为技术有限公司 | 一种报文转发的方法及相应设备 |
CN102970224B (zh) * | 2012-12-07 | 2015-05-06 | 重庆金美通信有限责任公司 | 一种兼容atm体制并基于ip交换网络实现mpls报文转发方法 |
CN102970224A (zh) * | 2012-12-07 | 2013-03-13 | 重庆金美通信有限责任公司 | 一种兼容atm体制并基于ip交换网络实现mpls报文转发方法 |
CN103036801A (zh) * | 2012-12-18 | 2013-04-10 | 网神信息技术(北京)股份有限公司 | 数据包的处理方法及装置 |
CN103036801B (zh) * | 2012-12-18 | 2019-06-14 | 网神信息技术(北京)股份有限公司 | 数据包的处理方法及装置 |
US9692694B2 (en) | 2012-12-27 | 2017-06-27 | Institute Of Acoustics, Chinese Academy Of Sciences | Multi-protocol routing system and method driven by application and network in convergence |
WO2014101316A1 (zh) * | 2012-12-27 | 2014-07-03 | 中国科学院声学研究所 | 一种应用与网络融合驱动的多协议选路系统及方法 |
CN103973553A (zh) * | 2013-01-24 | 2014-08-06 | 华为技术有限公司 | 数据包的处理方法与网络设备 |
CN104247363B (zh) * | 2013-03-28 | 2017-03-29 | 华为技术有限公司 | 一种报文传输的方法与交换设备和控制器 |
WO2014153758A1 (zh) * | 2013-03-28 | 2014-10-02 | 华为技术有限公司 | 一种报文传输的方法与交换设备和控制器 |
CN103748842A (zh) * | 2013-06-26 | 2014-04-23 | 华为技术有限公司 | 一种转发数据包的方法、装置和路由设备 |
CN103748842B (zh) * | 2013-06-26 | 2017-04-12 | 华为技术有限公司 | 一种转发数据包的方法、装置和路由设备 |
CN104660504A (zh) * | 2013-08-05 | 2015-05-27 | Agh科学技术大学 | 计算机网络中进行封包多路径路由选择的装置及其方法 |
CN103428211B (zh) * | 2013-08-07 | 2016-12-28 | 华南理工大学 | 基于交换机的网络认证系统及其认证方法 |
CN103428211A (zh) * | 2013-08-07 | 2013-12-04 | 华南理工大学 | 基于交换机的网络认证系统及其认证方法 |
WO2015074453A1 (zh) * | 2013-11-22 | 2015-05-28 | 华为技术有限公司 | 数据流转发路由的控制方法及装置 |
CN104734986A (zh) * | 2013-12-19 | 2015-06-24 | 华为技术有限公司 | 一种报文转发方法和装置 |
CN104734986B (zh) * | 2013-12-19 | 2018-12-25 | 华为技术有限公司 | 一种报文转发方法和装置 |
CN104754025B (zh) * | 2013-12-27 | 2019-01-22 | 英特尔公司 | 可编程分布式联网 |
CN104754025A (zh) * | 2013-12-27 | 2015-07-01 | 英特尔公司 | 可编程分布式联网 |
CN105099992A (zh) * | 2014-04-29 | 2015-11-25 | 杭州迪普科技有限公司 | 一种报文修改装置及方法 |
CN105099992B (zh) * | 2014-04-29 | 2018-07-24 | 杭州迪普科技股份有限公司 | 一种报文修改装置及方法 |
CN105359472B (zh) * | 2014-05-16 | 2018-11-09 | 华为技术有限公司 | 一种用于OpenFlow网络的数据处理方法和装置 |
CN105359472A (zh) * | 2014-05-16 | 2016-02-24 | 华为技术有限公司 | 一种用于OpenFlow网络的数据处理方法和装置 |
US10033619B2 (en) | 2014-05-16 | 2018-07-24 | Huawei Technologies Co., Ltd. | Data processing method and apparatus for OpenFlow network |
WO2015172373A1 (zh) * | 2014-05-16 | 2015-11-19 | 华为技术有限公司 | 一种用于OpenFlow网络的数据处理方法和装置 |
CN104009924A (zh) * | 2014-05-19 | 2014-08-27 | 北京东土科技股份有限公司 | 一种基于tcam和fpga的报文处理方法及装置 |
CN104009924B (zh) * | 2014-05-19 | 2017-04-12 | 北京东土科技股份有限公司 | 一种基于tcam和fpga的报文处理方法及装置 |
CN107431707A (zh) * | 2015-03-27 | 2017-12-01 | 德国电信股份公司 | 针对欺诈报文保护通信网络的网络保护实体和方法 |
CN106330492A (zh) * | 2015-06-23 | 2017-01-11 | 华为技术有限公司 | 一种配置用户设备转发表的方法、装置及系统 |
US11005706B2 (en) | 2015-06-23 | 2021-05-11 | Huawei Technolgoies Co., Ltd. | Method for configuring forwarding table for user equipment, apparatus, and system |
CN106330492B (zh) * | 2015-06-23 | 2019-11-26 | 华为技术有限公司 | 一种配置用户设备转发表的方法、装置及系统 |
CN105357126A (zh) * | 2015-11-12 | 2016-02-24 | 国电南瑞科技股份有限公司 | 应用于prp/hsr报文丢弃算法的查找表优化方法 |
CN105656801B (zh) * | 2015-12-31 | 2018-10-30 | 迈普通信技术股份有限公司 | 一种并发控制方法及装置 |
CN105656801A (zh) * | 2015-12-31 | 2016-06-08 | 迈普通信技术股份有限公司 | 一种并发控制方法及装置 |
CN107203635B (zh) * | 2017-06-07 | 2020-08-11 | 南开大学 | 一种基于最小略图的流模式下有向标签图的略图构建方法 |
CN107203635A (zh) * | 2017-06-07 | 2017-09-26 | 南开大学 | 一种基于最小略图的流模式下有向标签图的略图构建方法 |
CN110945843B (zh) * | 2017-07-19 | 2022-04-12 | 阿里巴巴集团控股有限公司 | 虚拟交换设备和方法 |
CN110945843A (zh) * | 2017-07-19 | 2020-03-31 | 阿里巴巴集团控股有限公司 | 虚拟交换设备和方法 |
CN107959603A (zh) * | 2017-10-27 | 2018-04-24 | 新华三技术有限公司 | 转发控制方法及装置 |
CN107682257A (zh) * | 2017-11-21 | 2018-02-09 | 凌云天博光电科技股份有限公司 | 数据传输方法和系统 |
CN110535771A (zh) * | 2018-05-24 | 2019-12-03 | 中兴通讯股份有限公司 | 一种数据转发方法、网络设备和计算机可读存储介质 |
CN110098977A (zh) * | 2019-04-12 | 2019-08-06 | 中国科学院声学研究所 | 实时协议识别背景下的网络数据包按序存储方法及系统 |
CN112511362A (zh) * | 2019-09-16 | 2021-03-16 | 中国移动通信有限公司研究院 | 设备转发性能的测试方法、装置、设备、介质 |
CN112511362B (zh) * | 2019-09-16 | 2022-07-19 | 中国移动通信有限公司研究院 | 设备转发性能的测试方法、装置、设备、介质 |
CN113691452A (zh) * | 2020-05-18 | 2021-11-23 | 瞻博网络公司 | 转变多级混合层次化转发信息库格式 |
CN113691452B (zh) * | 2020-05-18 | 2022-11-29 | 瞻博网络公司 | 转变多级混合层次化转发信息库格式 |
CN111614689A (zh) * | 2020-05-27 | 2020-09-01 | 北京天融信网络安全技术有限公司 | 一种用于状态防火墙的报文转发方法和装置 |
CN111614689B (zh) * | 2020-05-27 | 2021-02-19 | 北京天融信网络安全技术有限公司 | 一种用于状态防火墙的报文转发方法和装置 |
CN114079634A (zh) * | 2020-08-21 | 2022-02-22 | 深圳市中兴微电子技术有限公司 | 一种报文转发方法、装置及计算机可读存储介质 |
CN114079634B (zh) * | 2020-08-21 | 2024-03-12 | 深圳市中兴微电子技术有限公司 | 一种报文转发方法、装置及计算机可读存储介质 |
CN112511495A (zh) * | 2020-11-05 | 2021-03-16 | 方一信息科技(上海)有限公司 | 面向分布式防火墙网络系统及接口卡数据流加速处理方法 |
CN112333850A (zh) * | 2020-11-24 | 2021-02-05 | 展讯半导体(成都)有限公司 | 防止下行失步方法、通信装置和可读存储介质 |
CN112333850B (zh) * | 2020-11-24 | 2022-08-16 | 展讯半导体(成都)有限公司 | 防止下行失步方法、通信装置和可读存储介质 |
CN113783974A (zh) * | 2021-09-09 | 2021-12-10 | 烽火通信科技股份有限公司 | 一种动态下发map域规则的方法及装置 |
CN113783974B (zh) * | 2021-09-09 | 2023-06-13 | 烽火通信科技股份有限公司 | 一种动态下发map域规则的方法及装置 |
Also Published As
Publication number | Publication date |
---|---|
CN100359885C (zh) | 2008-01-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN1466340A (zh) | 以策略流方式转发数据的方法和数据转发设备 | |
CN1052358C (zh) | 区域间多路传送报文的方法和系统 | |
CN1612562A (zh) | 用策略流实现不同因特网协议数据包转发的方法和设备 | |
CN1254056C (zh) | 多协议标签转换网络系统 | |
EP2795874B1 (en) | Controller for flexible and extensible flow processing in software-defined networks | |
Riedl | A hybrid genetic algorithm for routing optimization in IP networks utilizing bandwidth and delay metrics | |
CN1829195A (zh) | 分组转发装置 | |
CN1716911A (zh) | 交换环境用的组合流水线式包分类和地址搜索方法及设备 | |
CN1866922A (zh) | 一种以太网中的控制系统和数据报文传输方法 | |
CN1315019A (zh) | 向接入因特网的用户提供所需的服务策略 | |
CN1866919A (zh) | 基于虚拟局域网堆叠的业务交换方法 | |
CN1250290A (zh) | 分组中继设备 | |
CN1404591A (zh) | 执行高速互联网协议路由查找和管理路由选择/转发表的装置和方法 | |
CN1518278A (zh) | 网络通信中实现资源分配的系统及其方法 | |
CN1825831A (zh) | 数据包中继装置和通信频带控制方法 | |
CN1859242A (zh) | 支持多业务传输的宽带接入设备 | |
CN101068226A (zh) | IPv4/IPv6混合环境下多媒体交互网关实现方法 | |
CN1511279A (zh) | 数据网络中路由器之间每类资源的基于策略的同步 | |
CN101039262A (zh) | 一种半覆盖自组织的动态组播路由方法 | |
WO2013059683A1 (en) | Comprehensive multipath routing for congestion and quality-of-service in communication networks | |
CN1926828A (zh) | 分组通信网络和分组通信方法 | |
CN1744571A (zh) | 减少网络内媒体接入控制地址学习的方法 | |
CN1852212A (zh) | 一种提供虚拟专用网站点之间通信的方法 | |
Vuppala et al. | Layer-3 switching using virtual network ports | |
Saha et al. | QoS-aware adaptive flow-rule aggregation in software-defined IoT |
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 |
Effective date of registration: 20170329 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 Province, Wuhan City Road, No. 88 hospital Patentee before: Wuhan Fenghuo Network Co., Ltd. |
|
TR01 | Transfer of patent right | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20080102 Termination date: 20190624 |
|
CF01 | Termination of patent right due to non-payment of annual fee |