CN1499794A - 通信设备中在第三层处理数据包的方法 - Google Patents

通信设备中在第三层处理数据包的方法 Download PDF

Info

Publication number
CN1499794A
CN1499794A CNA200310103010XA CN200310103010A CN1499794A CN 1499794 A CN1499794 A CN 1499794A CN A200310103010X A CNA200310103010X A CN A200310103010XA CN 200310103010 A CN200310103010 A CN 200310103010A CN 1499794 A CN1499794 A CN 1499794A
Authority
CN
China
Prior art keywords
mpls
bag
packet
header
frame
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
Application number
CNA200310103010XA
Other languages
English (en)
Other versions
CN1312887C (zh
Inventor
I
I·布西
P·V·格兰迪
M·丰塔纳
G·赞格兰多
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alcatel CIT SA
Alcatel Lucent SAS
Alcatel Lucent NV
Original Assignee
Alcatel NV
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Alcatel NV filed Critical Alcatel NV
Publication of CN1499794A publication Critical patent/CN1499794A/zh
Application granted granted Critical
Publication of CN1312887C publication Critical patent/CN1312887C/zh
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/16Multipoint routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08Protocols for interworking; Protocol conversion

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

在通信设备中处理MPLS数据包的方法包括按照下列顺序的下列步骤:在输入方向:计算接收到的帧和八位字节,验证数据包,确定接口ID,计算接收到的数据包和八位字节,剥离外部报头,查找输入数据包的目标地址,下一层决定和转发,TTL管理,如果下一中继不是该设备,PHB判断;在输出方向:从接收到的输出客户数据包中提取TTL,将接收到的输出客户数据包作为被剥离的MPLS包,与接收到的FEC、PHB和TTL一起转发,生成End of stack比特,传递被剥离的MPLS包,以及FEC、PHB、TTL和End of Stack,查找输出客户端数据包的目标地址(FEC由设备生成),TTL管理,生成MPLS报头,计算发送的数据包和八位字节的数目,转发MPLS包、PHB和下一中继。

Description

通信设备中在第三层处理数据包的方法
技术领域
本发明涉及在通信设备中,在第三层级别上处理数据包,特别是IP和MPLS包的方法。
背景技术
众所周知,互连网世界中的标准化行动很特别,它是由一个网络设计者、运营商、供应商和研究者组成的大型开放性国际团体——互连网工程任务组(IETF),来完成的。
IETF的标准化行动通常包括数据包处理的单个操作,从未有人试图对通信设备的整个功能模型进行标准化。
有无数的可能性可以合并并且实现各种不同的操作。如何以及何时来执行这些不同的操作在很大程度上影响设备的整体功能和有效性。
发明概述
本发明提出了已经在通信设备中处理IP包和/或MPLS包的过程中显示了特殊效果的两个特别选择。
本发明也涉及特别适合于实现这些数据包处理方法的通信设备、计算机程序产品和计算机可读介质。
附图说明
结合附图,从下属描述中,本发明将会更加清楚。附图中:
图1是根据本发明的整个通信设备,具体来说是路由器,的功能模型;
图2是图1的MPLS框的分解功能模型。
具体实施方式
此处使用的描述方法是ITU-T(国际电信联盟,电信标准化部门)推荐G.806中所定义的一种方法。
详细的描述涉及到能够处理IP包和MPLS包的路由器,但是本发明具有更为广阔的应用:除了处理IP和/或MPLS数据包的路由器,还可用于处理IP和/或MPLS数据包的主机;此外,本发明与设备的物理接口数目无关。
众所周知,在通信设备的功能模型中,传输源可以分为:
-连接功能
-终止功能
-适配功能
-适配-终止功能
根据上述推荐,连接功能由椭圆框图形来代表,终止功能由三角框代表,适配功能由梯形代表,适配-终止功能由顶部有梯形的三角形的复合框来代表。
图1显示了根据本发明的路由器的功能模型,对接收和发送方向都进行了表示。图1的结构采用了ISO/OSI逻辑。
名为“第四层及以上”的框包括了所有的第四层协议、信令功能和IEMF(IP元素管理功能)以及上层应用。名为“第一和第二层”的框包括了硬件接口和第二层驱动器。
解释图1时,记住IP世界的分层和ISO/OSI分层并不完全一致。因此,众所周知,第四层包括一些可以从逻辑上视为第三层的功能。这些功能在第四层而不是第三层是因为,对于消息传输来说,它们是依赖于IP协议的。同样,可以发现,一些功能在第二层而不是第三层。一个典型的例子是ARP(地址裁决协议)。从消息传输的观点来看,这项功能应当放在第三层,但是,由于它提供了获得MAC(媒体接入控制)地址所需要的地址翻译特征,它被放在了第二层。
路由器从网络中接收的数据包,如果被转发,则被从物理层直到IP_C框的功能框处理,或者,如果它被终止,则到达更高层。这个处理过程被称为输入方向上的处理。
由更高层生成或者转发的数据包,被从IP_C框向下到物理层的功能框处理,并在物理层传送到网络中。这处理过程被称为输出方向上的处理。
协调功能(在图1中由于图形上的原因,由两个独立的框COORD来代表)起到粘和剂的作用,通过它来实现与较低层和较高层之间的直接通信。
每次由于任何原因而丢弃数据包的时候,丢弃数据包的框也向ICMP(网际控制消息协议)发送所有需要汇集并向被丢弃的数据包的产生者发送一个ICMP消息的相关消息。任何ICMP消息都是根据标准IETF过程生成的。
输入和输出方向上的功能是不一样的,下面将进行详细描述。
在附图中,连续线代表通信流,而虚线,通常将终止框或者适配框连接到协调功能框,被用于代表控制流。
输入数据包首先在第二层被处理,识别该输入包是纯IP包还是MPLS封装包。MPLS封装包在MPLS框中进行处理,在那里它可以被转发或终止。当仍旧被封装,或者当不再被封装(倒数第二个弹出(pop)的情况)的情况下,被转发的包被直接送回到第二层。不管怎样,采用最后被弹出的标签选择输出接口。被中断的数据包被送到IPL_T框,进行进一步处理。
IPL_T终止功能执行传送IP包必须用到的所有功能,并选择下一个步骤。可能的步骤包括:
-该数据包必须被转发,因为它不是送到该路由器的;在这种情况下,该包被送到IP_C框以进行查找;
-该数据包被封装在IP隧道内;在这种情况下,该包被送到IPIP_T框,以进一步进行处理;
-该数据包既没有封装在IP隧道内,也没有被转发;在这种情况下,该包被直接送到IP_T终止框。
隧道内的数据包被IPIP_T框处理,它对所有被终止的第三层报头进行检查,并剥离这些报头。之后,该包被送到另一个IPL_T框。
重要的是要理解,隧道处理线中存在的两个IPL_T终止框执行同样的操作,但是是对于不同的第三层报头。仅接着第二层的IPL_T终止框处理外部报头,而仅接着IP_C框的IPL_T终止框,在IPIP_T框的剥离操作之后,处理剩余报头的外部。
IP_T终止框执行必须对被终止的数据包进行的所有检查,并且,如果没有遇到问题,将该包发送到第四层。
路由器生成的所有非多点传送数据包必须首先通过IP_T框,加上第三层报头,之后IP_C框执行查找,并决定输出接口以及必须在发送数据包之前执行的操作。
路由器生成的多点传送数据包与特殊的输出接口相关联;实际上,这些数据包是控制包(例如,OSPF包),并非真正的多点传送包。上层应当将此特殊输出接口通知IP_T框,IP_T框将第三层报头加上,并将此数据包与输出接口信号一起送往IP_C框。这样,连接功能不进行任何查找,而是将数据包转发到要求的接口。
有三种可能的输出方法:
-数据包直接发出,
-数据包必须先封装在IP隧道中,然后发出,
-数据包必须先封装在MPLS中,然后发出。
中转数据包是路由器处理并转发的所有数据包。
处理与已经描述过的相同,而不考虑IP_T框到上层的部分。
MPLS框的功能模型在图2中进行了详细描述。
在图的上部,是MPLS框的一个入口,承载IP包、通过IP_C框提取的PHB(Per-Hop Behavior,逐中继行为)和通过IP_C框计算的FEC(ForwardingEquivalent Class,转发等价类)。数据被MPLS_T框处理,其在朝着一个MPLS_C框的输出方向上,主要建立一个MPLS包。该MPLS包,与PHB和FEC一起,被送到MPLS_C框,以进行进一步处理。
在框的下面,有一个用于来自于线路的MPLS包的进入点。这些数据包被MPLSI_T终止框进行验证,并被MPLSI/MPLS_A框剥去外部MPLS报头。包含在外部报头中的标签(不包括PHB、TTL以及End_of_Stack标志)与被剥离的数据包和接口识别标志一起,被送到MPLS_C框。
MPLS_C框执行不同的功能,这依赖于数据包的源。在数据包来自于MPLSI_T框的情况下,会执行一次FEC查找,以发现输出接口和待增加的标签。之后,数据包和标签、下一中继(next hop)以及PHB,被送到MPLS/MPLS_A框进行封装和排队。在数据包来自于MPLS/MPLS_A框的情况下,会对提取的标签进行查找,以判断是否必须终止该MPLS包(或者之后发送到MPLS_T框),或者为其选择路由(之后发送到MPLS/MPLS_A框)。
在输入方向,MPLS_T终止框根据下一跳和end-of-stack比特,来判断是否把数据包发往MPLS框的外部,送到IP/MPLS适配框(在“层1和2”框之内),以进行排队(“No More Pops”),或者送回MPLSI_T框(“More Pops”),以执行新的弹出操作。这最后一种情况的目的在于在同一终止(即,多隧道终止)中,考虑多次弹出的可能性,以及在LSP(标签交换通路)中倒数第二个节点执行应当由最后一个节点来进行的弹出(倒数第二次弹出功能)的可能性。
MPLS_C框负责查找所有接收到的MPLS标签消息和路由器发出的所有接收的IP包消息。
MPLS_C框负责支持下列角色:
-MPLS核心路由器,处理MPLS标签输入数据包;
-MPLS边路由器,处理没有标签的输入IP包,并转发输出的MPLS包;
-MPLS TLS边路由器,处理输入的没有标签的以太帧,并转发输出的MPLS包。
FEC参数作为检查过程的一个参数提供,其中FEC包括:
1.<输入接口ID,输入MPLS标签>用于接收的MPLS包,
2.<IP FEC(作为NHLFE的指针)>用于生成的IP包,
3.<流ID>用于任何其它协议(例如TLS)。
在数据包没有标签的情况下,它把由IP_C框决定的FEC映射给一个或多个NHLFE(Next Hop Label Forwar ding Entry,下一中继标签转发入口)。在这种情况下,这个过程称为FTN(FEC-to-NHLFE)。
在标签数据包的情况下,它把输入标签映射到一个或多个NHLFE。这种情况下,这个过程称为ILM(Incoming Label Map,输入标签映射)。
NHLFE、FTN和ILM表定义如下。
NHLFE用于转发有标签的数据包。
注意,给定LSR(标签交换路由器)时,数据包的“下一中继”可能是该LSR本身。在这种情况下,LSR需要弹出顶层标签,然后向其自身“转发”生成的数据包。之后它会基于堆栈的标签被弹出之后的剩余,再一次进行转发决定。这可能仍然是一个标签数据包,或者也可能是裸露IP包。这暗示,在一些情况下,LSR可能需要在IP报头上操作,以转发数据包。如果数据包的“下一中继”是当前的LSR,那么标签堆栈操作必须是“弹出堆栈”。
ILM将每个输入标签映射到一个NHLFE集合。当转发数据包作为有标签的数据包到达时,使用它。
为了将输入标签映射到一个NHLFE集合,除了输入标签之外,该框可以使用其它消息,例如接口识别消息(由MPLS_T框提取)。在处理多标签地址空间的时候,需要此最后的消息。在某些情况下,通过不同的接口将不同的标签和同一个FEC联系起来可能会更好。
如果ILM将单个标签映射到了一个包含多个元素的NHLFE集合,那么在数据包被转发之前,必须从集合中选定一个确定的元素。
ILM将标签映射到包含多于一个的NHLFE集合这个事实可能是有用的,例如,希望在多均等成本路径中进行平衡负载。
FTN将每个FEC映射到一个NHLFE集合。它用于转发到达时没有标签、但是需要在转发之前加上标签的数据包。
如果FTN将单个标签映射到一个包含多于一个元素的NHLFE集合上,那么在数据包被转发之前,必须从集合中选定一个确定的元素。FTN将标签映射到包含多于一个的NHLFE的集合这个事实可能是有用的,例如,希望在多均等成本路径中进行平衡负载。
在进行检查之后,MPLS_C框判断下面的路径,这有两种可能:
-数据包必须在加入一个或多个标签之后转发;在这种情况下,数据包与接口ID、标签消息、End_of_stack标志、下一中继、TTL和PHB一起,被送到MPLSI/MPLS_A框。
-数据包必须在本地终止,或者因为必须执行一些多次弹出,或者因为该数据包的目标地址是该路由器本身;MPLS_C框不能分辨这最后两种情况,而把数据包发往MPLS_T框进行进一步处理。
注意,没有对于TTL进行处理,其值仅从输入拷贝到输出,因此下一个框可进行进一步的处理。
MPLSI_T框的目的是处理与MPLS包的终止相关联的操作。
在图2中,框由两个分离的框来代表,以完成可能的发送和接收处理:在从线路上接收到MPLS包之后的处理、与多转发点相关联的处理,以及与发送相关联的处理。
在接受方向,它执行下列操作:
1.计算接收到的帧和八位字节的数目,
2.根据标签范围验证输入MPLS包,
3.确定接口标识,
在输出方向上,它执行下列操作:
1.进行MPLS分片,
2.传递交换MPLS包、PHB和下一中继;在本框中没有使用PHB和下一中继的操作;这些信息片只是被转发到其它框中进行排队。
MPLSI_T框由一个MPLS接口代表,根据对于支持MPLS的基础物理接口(PPP,以太网)的激活/撤销,它从代理中被生成/删除。
在生成时间,下列有关于接口的参数具有预定的或者固定的值:
-接口速率为0
-接口高速率为0
-接口物理地址不使用
-接口连接器设为假
-计数器复位到0
-双工类型固定为全双工
-混杂模式设为假
-接口别名为空。操作者可以轻易对其进行改变。
-接口名称和描述包括一个长度为零的字符串。
仅当基础接口(PPP或者以太网)被激活时,MPLSI_T才可以被激活。
仅当没有MPLS片断(在输入或者输出方向)在其上被激活的时候,MPLSI_T才可以被撤销。
操作状态代表MPLS在本接口上实际的或者操作的状态。
任何时候,网络管理系统都可以重新得到MPLSI_T的当前操作状态。
操作状态的改变必须同时通过状态改变通知,来通知管理员。
操作状态最后改变的时间必须被存储起来。
管理员能够读取操作状态最后改变的时间。
每个接收的数据包都要被检查,以确保具有在配置的MPLS输入范围之内的标签。接收到的具有范围之外的、或者没有分配的MPLS标签的数据包则被丢弃。
对于接收到的具有保留的标签(在0和16之间)的数据包的处理被用于进一步研究。
下列监测参数从MPLSI_T框进行更新(在PM域):
-接口失败标签查找:它代表在本接口已经接收到、但因为没有匹配的交叉连接入口而被丢弃的有标签的数据包的数目。
每接口MPLS标签空间规定要求NMS为每个MPLS接口说明下列参数:
-接口标签最小输入
-接口标签最大输入
没有要求每接口输出MPLS标签空间(接口标签最小输出,接口标签最大输出)的规定,任何在输出接口上,做为从下行MPLS标签分布处理而提供的MPLS标签都被设备接受。
MPLSI_T框提取下列监测参数:
-使用的接口输入标签:它代表在输入方向上,该接口当时在该点使用的标签的数目;
-使用的接口输出标签:与接口输入标签相同,但用于输出接口。
每个接口的下列参数可被配置:
-总接口带宽
-可获得的接口带宽。
超过任何MPLS接口的MTU的MPLS包被丢弃。
下列监测参数由MPLSI_T框进行更新:
-接口输出片断:代表在本接口上传输之前需要进行分片的输出MPLS包的数目。
MPLSI/MPLS_A框的目的在于,处理有关于MPLS包的接收和转发的操作。
在图2中,对接收和转发处理都进行了表示。
在输入方向,它进行下列操作:
1.计算接收到的数据包和八位字节数,
2.剥离外部MPLS报头,提取被剥离的信息。
在输出方向,它进行下列操作:
1.TTL管理(递减和检查),
2.生成新的MPLS报头(MPLS标签加入);根据PHB设定EXP比特,
3.计算发送的数据包和八位字节数。
MPLSI/MPLS_A框通过明示的NMS请求而被生成/删除。
MPLSI/MPLS_A功能框的生成和删除在单向上进行。
MPLSI/MPLS_A的激活/撤销在单向上通过明示的NMS请求而进行。
仅当基础MPLSI_T框已经被激活时,MPLSI/MPLS_A才能够被激活。仅当相应的MPLS交叉连接已经被撤销时,MPLSI/MPLS_A才可以被撤销。
路由器不能检查一个数据包的TTL,除非需要转发该包;更具体来说,任何发往该设备、并且TTL=0的MPLS包必须认为是合法数据包。
在输出方向上,如果转发包的TTL大于1,则将其减1,否则数据包被丢弃。
MPLSI/MPLS_A框为每个方向提供一组初始值,用于监控目的。他们是:
在输入方向上:
-输入片断八位字节:它代表本片断接收的所有八位字节的数目,
-输入片断数据包:它代表本片断数据包总数,
-输入片断错误:它代表本片断接收到的错误数据包的数目,
-输入片断丢弃:它代表在本输入片断上接收到的有标签的数据包的数目,尽管没有探测到任何防止它们被传输的错误,这些数据包仍然被丢弃;丢弃这样一个有标签的数据包的一个可能原因是释放缓存空间。
-输入片断HC八位字节:代表接受的八位字节的总数目;这是输入片断八位字节的64比特版本。
-不连续时间:代表大多数在上述一个或多个计数器发生不连续的最近情况下,SysUpTime的值。
在输出方向上(与上述计数器具有同样的意义,但是应用于输出方向):
-输出片断八位字节
-输出片断数据包
-输出片断错误
-输出片断丢弃
-输出片断HC八位字节
-不连续时间
MPLS_T框的目的是处理有关于终止MPLS包的操作,并根据在弹出操作之前提取的End_of_Stack标识和MPLS标签来决定进一步的处理步骤。在输入方向上,它执行下列操作:
1.将输入的MPLS包送到不同的适配框,以进行进一步的处理。
如果End_of_stack标识等于0,MPLS包被送到MPLS/MPLSI_A适配功能。
如果End_of_stack标识等于1,MPLS包被送到更多的特定适配功能(MPLS/IP_A,MPLS/TLS_A)适配功能。可能的标准是:接口ID和与IP或者TLS服务有关的输入MPLS标签。
在输出方向上,它执行下列操作:
1.传送接收到的被剥离的MPLS包、FEC、TTL和PHB。它生成End_of_stack比特(设定为1)。
在输入方向上,MPLS/MPLSI_A适配框执行下列操作:
1.TTL管理:当下一中继不是该LSR自身的时候,对TTL值的递减和检查;该TTL值随后被复制进内部MPLS报头。
2.如果下一中继不是LSR本身,它执行PHB判断(具有剩余MPLS标签的PHP)。
3.决定进一步的步骤。
如果下一中继是LSR本身,它将MPLS包转发到MPLSI_T,以进行后续的检查(具有剩余的MPLS标签的POP操作)。
否则,它将具有计算出的PHB的MPLS包送到相应于下一中继的第二层(具有剩余的MPLS标签的PHP)。
在输入方向上,MPLS/IP_A适配框执行下列操作:
1.TTL管理:当下一中继不是该LSR自身的时候,进行对TTL值的递减和检查;该TTL值随后被复制进内部IP报头。
2.如果下一中继不是LSR本身,它执行PHB判断(没有剩余的MPLS标签的PHP)。
3.决定进一步的步骤。
如果下一中继是LSR本身,它将IP包传递到IPL_T,以进行IP转发(没有剩余的MPLS标签的POP操作)。
否则,它将具有计算出的PHB的IP包送到相应于下一中继的第二层(没有剩余的MPLS标签的PHP)。
在输出方向上,MPLS/IP_A适配框执行下列操作:
1.它从IP包中提取TTL。
2.它将接收到的IP包作为剥离的MPLS包,与接收到的FEC、PHB和提取出的TTL一起,传送到MPLS_T框。
在下面的段落中,可以看到对第三层功能的详细展示,该功能与要结合图1所考虑的IP协议相关联。
在输入方向上,IPL_T框具有下列功能:
1.IP包验证
2.选择字段管理
3.滤波
4.下一层决定和转发。
在输出方向上,IPL_T框具有下列功能:
1.重新定向(redirect)管理
2.TTL管理
3.源地址管理
4.选择字段管理
5.数据包分片
必须记住,在所有改变IP包报头的处理过程中,都必须进行报头的校验和计算。
在对IP报头进行任何处理之前,必须要进行一些检查(“输入IP包验证”)。如果有任何的检查没有顺利通过,该包与失败的原因一起,被送到使用协调功能的ICMP处理。下面,按照执行顺序报告检查情况:
1.连接层报告的数据包长度必须足够大,以容纳最小的合法IP,
2.IP报头校验和必须正确,
3.IP版本号必须为4,
4.IP报头长度字段范围必须足够大,以容纳长度最小的合法IP报头;即,它必须大于或等于5(20字节报头),
5.IP总长度必须大于或等于IP报头长度,
6.连接层报告的数据包长度大于或等于IP总长度,
7.如果IP目标地址不属于路由器,必须不存在严格的源路由选项,
8.如果IP源地址不合法,数据包被默默地丢弃;如果一个IP源地址位于网络0中、属于多点传送或者广播地址,或者,是一个回送地址,则它被认为非法,
9.其它选项特定检查,
10.如果IP目标地址不合法,数据包被丢弃;如果一个IP目标地址位于网络0中、属于E类别,或者,是一个回送地址,则它被认为非法;仅在由于宽松源路由或者严格源路由而执行了目标地址切换之后,才能进行此检查。
在TOS和Flags字段,为未来应用而保留了两比特空间。这些比特不得卷入任何检查。
当接收到多点传送包,必须进行下列检查:
1.接口应当属于被目标地址识别的多点传送组;路由器的所有接口总是属于“所有IP主机”永久组。动态分组成员由IGMP(互连网络组管理协议)框来进行管理,并通过协调功能通知IPL_T框;所有接收到的被送到一个多点传送组的(该接口不属于该多点传送组)的多点传送包被默默抛弃(包括路由器的任何其它接口属于的情况)。
2.路由器不应当成为接收到的多点传送数据包的源;如果接收到的数据包的源地址是路由器的地址之一,该数据包被默默丢弃;如果一个应用要求接收该数据包,则它会已经被IP_T框循环回来。
IP版本4预见了在报头中插入不同的选项的可能性。
插入报头的选项的顺序是自由的。
有两种可能的选项格式:
-单字节选项,仅包括选项类型
-多字节选项,按照顺序包括:选项类型、选项长度和数据。
该选项类型可以被视为具有下列意义的一个比特字段:
-最高有效位规定了当支持片断功能时,是否必须在片断中复制该选项(其类型大于127的选项必须在片断中复制)。
-低有效位的5比特,规定了选项号码,
-剩余的2比特包括选项类别,对于时间戳选项其值为2,对于所有其它选项其值为0。
IP层必须翻译所有它可以理解的选项,并保留所有其它选项不变(“选项字段管理”)。下面,对于IPL_T终止框中所有的选项以及有关路由器处理和支持的信息,给出了简要的说明。
当选项的结尾与报头的结尾不一致时,End_of_Option_List选项被用于所有选项的结尾。
No_Operation选项用于将一个选项的开头与一个32比特的边界校准。
Security(安全)选项用于发送安全消息、分隔消息和处理限制消息。
Loose_Source_rout选项为IP包的源提供了一种手段,以提供明确的路由信息,该信息被路由器用来将该数据包转发到目标地址并记录经由路线。
宽松源路由选项用于需要强制数据包仅仅通过路径中的一些特定节点的时候。
在该选项中的四个字段是:
-类型:(选项类型)宽松源路由选项的值为131,
-长度:考虑到类型、长度、指针和路由数据字段的选项的长度,
-指针:是下一个被处理的地址的位移,开始于选项的开始,最小值为4,如果指针大于长度,那么就到达了选项的末尾,进一步的路由将只使用目标IP,
-路由数据:有待处理的一系列地址。
每当路由器收到目标是该路由器自身的IP包,它必须检查宽松源路由选项是否存在。
如果该选项存在,并且不为空(指针小于长度),在输入方向上必须进行下列操作:
-检查它是否是IP报头中唯一的源路由选项(不论严格或宽松);如果由两个或更多的源路由选项存在,该数据包被丢弃,并被送到ICMP框以生成错误报告,
-在数据字段中取下一个IP地址,将其放入该数据包的目标IP地址字段中。
如果该选项存在且不为空(指针小于长度),并且指向的值等于目标地址,那么在输出方向上必须进行下列操作:
-将输出接口的IP地址放在指针指向的位置,
-将指针增加4。
这个过程保证了返回路由被以反向记录到该选项中,这样最终接收者可以使用这些数据来在反向方向上建立宽松源路由。
由于目标地址被替换的事实,涉及到目标地址合法性的检查必须在地址替换之后进行。
Strict_Source_Route选项为IP包的源提供了一种提供明确的路由信息的手段,该明确的路由信息用于路由器将数据包转发到目标地址以及记录沿循的路线。
严格源路由选项用于需要强制数据包通过特定路线的时候。必须在该选项中提供路径中的所有节点。
选项的格式与宽松源路由选项相同,前面已经描述过。
分配给该选项类型的值是137。
每次路由器接收一个其目标地址是路由器自身的IP包,它必须检查严格源路由选项是否存在。
如果该选项存在并不为空(指针小于长度),在输入方向上必须进行下列操作:
-检查它是否是IP报头中唯一的源路由选项(不论严格或宽松);如果有两个或更多的源路由选项存在,该数据包被丢弃,并被送到ICMP框以生成错误报告,
-在数据字段中取下一个IP地址,将其放入该数据包的目标IP地址字段中。
如果该选项存在且不为空(指针小于长度),并且指向的值等于目标地址,那么在输出方向上必须进行下列操作:
-将输出接口的IP地址放在指针指向的位置,
-将指针增加4。
这个过程保证了返回路由被以反向记录到该选项中,这样最终接收者可以使用这些数据来在反向方向上建立宽松源路由。
由于目标地址被替换的事实,涉及到目标地址合法性的检查必须在地址替换之后进行。
Record_Route选项为IP包的源提供了一种记录来自源地址发往目标地址的数据包沿循的路由的手段。
该选项的格式与宽松源路由选项相同,上面已经描述过。
分配给该类型选项的值为7。
每次路由器接收到目标地址不为该路由器本身的IP包,它必须检查record route记录路由选项是否存在。
如果该选项存在,并且还有一些自由空间(指针小于长度),在接收方向上路由器必须执行下列检查:
-在一个数据包中,该选项至多出现一次,
-在该选项中由足够的空间来容纳IP地址。
如果没有通过检查,该数据包被丢弃。
如果该选项存在,并且还有自由空间(指针小于长度),在输入方向上必须进行下列操作:
-将输出接口的IP地址放在指针指向的位置,
-将指针增加4。
如果该选项存在,但是没有可用空间了(指针大于长度),则不需要进行任何操作。
Stream_ID选项用于通过不支持流概念的网络转发SATNET流。
该选项过时了。
时间戳选项用于强制IP网络中一些或者所有的节点在被路由的数据包中插入时间戳。
Route_Alert(路由告警)选项用于与路由器通信,该路由器需要进一步检查并非直接送给它的数据包。
该选项的一个可能应用是,平滑地引入新路由能力,而无需重新建立基本的路由协议功能。
在该选项中的三个字段是:
-类型:(选项类型)路由告警选项的值是148。
-长度:考虑了类型、长度、指针和路由器数据字段的该选项的长度;此值固定为4。
-值:如果路由器必须检查数据包,则设为0。所有其它值被留作将来使用。
在输出方向上,“重新定向管理”功能将检验要被发送的数据包是否满足下列条件:
-它被曾经接收它的同一个接口发出,
-源地址属于下一中继的子网,
-没有源路由选项。
如果所有上述条件都为真,数据包就被发送。它的一份拷贝与下一中继的地址一起也会被送到ICMP框,用于生成重新选择路由ICMP消息。
路由器不能检查数据包的TTL,除非在转发它的时候(“TTL管理”);更具体来说,任何地址是该路由器且TTL等于0的IP包必须被视为合法。
在输出方向上,如果转发包的TTL大于1,则将其减1,否则数据包被丢弃。
每次IP报头被IPL_T框改变,必须重新计算校验和(“校验和计算”)。
路由器支持增量校验和计算,即,新校验和计算由IP报头中目前已有的开始,仅考虑进行过的变化。
这保证了被路由器废弃的数据包在下一中继能够被丢弃。
在结束对输入数据包的处理之后,IPL_T框通过协议字段和目标地址字段,来决定哪层是接收该数据包并进行进一步处理的下一层;该下一层可以被视为ISO/OSI模型第三层的子层。
如果目标地址是多点传送地址,该数据包必须被终止,则它被转发到IP_T框。接口也会通过“Mcast If”信号。
如果协议字段是IP v4,并且目标地址是路由器接口IP地址之一或者路由器id,那么IP in IP隧道被终止;数据包被转发到IPIP_T终止框。
如果目标地址不是路由器接口IP地址之一,那么必须为数据包重新选择路由;数据包被转发到IP_C连接功能框。
如果目标地址是路由器接口IP地址之一或者路由器id,并且协议不是IP v4,那么数据包必须被终止;数据包被转发到IP_T终止框。
当被路由的数据包体积大于MTU(最大传输单元)时,该数据包必须被分片(“数据包分片”)。
每个片断(包括IP报头)的体积必须小于或等于MTU。
进行分片时,所有的报头字段必须被复制到所有片断中,除了校验和以及选项,必须重新计算校验和,而选项的行为可以通过察看选项类型字段来了解。通过这种方法,同一数据包的所有片断在互连网身份识别字段具有同样的值。
所有片断的更多片断标识比特设为1,除了最后一个。
片断的偏移字段识别片断相对于原始的未分片的数据包的起始位置(以8字节为单元)。第一个片断的偏移等于0。
由于最小偏移是8字节,以及报头最大可达60字节这样的事实,没有小于68字节的数据包会被分片。
在TOS和Flags字段,保留了两个比特以备将来使用。这两个比特必须被拷贝到所有的片段中。
路由器的任何接口都必须关联一个IP地址,当接口处于休眠状态时,该IP地址由管理员提供。
提供的IP地址必须合法,否则路由器会拒绝该提供。
IP地址由两个部分构成:
-一个32比特IP地址,识别网络中的元素,
-一个32比特的子网掩码,明确哪些比特代表了子网,哪些比特代表子网内的元素;代表子网的比特是最高有效位,必须是连续的。
如果点对点接口没有关联的IP地址,而路由器ID已经作为路由协议配置的一部分而进行了配置,则路由器ID必须被用于接口地址。
当一个IP接口被删除,所有与之关联的IP地址都必须被删除。
IPIP_T终止框的任务是在IP over IP隧道的建立和运行阶段给以所有必要的支持。
源终端的第一项任务是观察本地表中保留的消息,确定哪个隧道必须被生成到输入IP包上。下面的步骤是生成并为每个必须生成的隧道正确填充第三层报头。
如果IP包不需要插入任何隧道,那么源是绝对透明的,并且输入数据包不经过任何处理就可以通过。
在输出方向上,隧道终止框必须执行下列过程:
1.确定哪条隧道必须被生成(如果有的话),
2.根据隧道地址验证输入数据包的IP地址,
3.进行从客户端接收者到隧道端点地址,以及反过来的地址翻译,
4.插入外部报头,
5.处理外部报头字段,强制分片标识取“Do Not Fragment”值,
6.处理外部报头选项字段,
7.计算外部报头校验和,
8.进行路径MTU发现,
9.在传输过程出错的情况下,向在隧道中被传输的消息的生成者发送ICMP消息。
Traceroute(跟踪路由)功能也可以实现。
当标签和CoS消息存在时,只被通过,以允许后面的框进行MPLS封装。
Sink终止框的第一个任务是,确定哪个隧道必须被终止。这项操作可以通过察看协议字段和每个加入堆栈的第三层报头的目标地址来完成。紧接着的步骤是剥离所有的外部报头,并管理内部报头的TTL。如果没有任何隧道必须被终止,那么sink是完全透明的,输入数据包不经过任何处理地被传送。
在输入方向上,隧道终止框必须进行下列操作:
1.判断哪个报头必须被剥离(如果有的话),
2.剥离隧道报头,
3.处理所有被剥离的报头的TTL,除了已经被IPL_T框处理过的第一个报头,
4.处理所有被剥离的报头的CRC,除了已经被IPL_T框处理过的第一个报头。
IP_C框的主要任务是执行检查,以决定每个输入和输出IP包的目标地址。
从逻辑的观点来看,该框执行两种查找。
第一种是查找转发表,以了解IP包是否必须被路由或终止。在第一种情况下,IP_C框确定下一中继和发送该数据包的接口。
如果数据包具有多点传送地址,它被转发到按照上层协议要求的接口,上层协议生成该数据包,通过“Mcast If”信号。
第二种查找与一个事实有关,即有可能引起一个MPLS数据包,它可以用于FEC计算。
在这种情况下,IP_C框必须执行下列操作:
-确定输出IP数据包的FEC,
-确定CoS。
这项查找导致将输入数据包根据FEC进行分类。为执行这项分类,必须考虑输入接口Id。
FEC是以同样方式(例如,通过同样的路经,进行同样的转发处理)转发的一组IP包。
特别是,如果满足一个或多个下列标准,输入IP包属于一个FEC,这些标准可以在每个输入接口上单独激活。这些标准是:
-源地址,
-目标地址,
-源端口,
-目标端口,
-协议。
可以检查一个输入数据包与一组以上标准的匹配情况来决定其FEC。
例如,首先检查输入数据包是否匹配特定源地址和目标地址(FEC1),之后检查特定的目标地址(FEC2)。
一旦数据包被分类,它被送到MPLS_T框,以进行进一步操作。
在输入方向上,IP_T框实现下列功能:
1.IP包报头验证,
2.数据包重组
3.选项字段管理
4.下一层决定和转发
在输出方向上,IP_T框实现下列功能:
1.IP负载的多路传输,
2.选项字段管理,
3.生成IP报头。
在对IP报头进行任何处理之前,必须执行一些检查(“输入IP包验证”)。如果有任何的检查没有顺利通过,该包与失败的原因一起,被送到ICMP做进一步处理。下面,按照执行顺序报告检查情况:
1.IP源地址不同于0.0.0.0;没有通过此项检查的数据包被默默丢弃。
2.IP报头的协议字段规定了支持的协议。
下表中,给出了支持的协议:
    协议            十进制值
    ICMP            01
    IGMP            02
    IP(IP in IP)    04
    TCP             06
    UDP             17
    RSVP            46
    OSPF            89
输入的分片数据包必须重新组合(“数据包重组”)。属于该数据包的一部分的片断必须被保持在一个队列中,直到接收到所有的片断,或者重组时间期满。如果在接收到所有的片断之前重组时间期满,那么已经接收到的片断都必须被丢弃。
重组时间的取值随着产品而不同,并且在任何时候都可管理员读取。
第四版IP协议预见了一些选项。
IP层必须翻译所有它理解的选项(“选项字段管理”)。下面,对于IP_T终止框中所有的选项以及有关路由器处理和支持的消息,给出了简要的说明。
当选项的结尾与报头的结尾不一致时,即当采用了垫整(padding)时,End_of_Option_List选项被用于所有选项的结尾,。
No_Operation选项用于将一个选项的开头与一个32比特的边界校准。
Security(安全)选项用于发送安全消息、分隔消息和处理限制消息。
Loose_Source_rout选项为IP包的源提供了一种手段,以提供明确的、被路由器用来将该数据包转发到目标地址并记录经由路线的路由信息。
宽松源路由选项用于需要强制数据包通过路径中某些的特定节点的时候。
如果源路由数据包在IP_T终止框中被终止,记录的线路必须被送到上层。
当生成宽松源路由数据包的时候,该选项必须已经形成。这意味着,该IP包的目标地址必须是第一个路由器的IP地址,而该选项包含其它路由器的IP地址。在这个选项的清单里,不能出现多点传送地址。
Strict_Source_Route(严格源路由)选项提供了一种用于IP包的源提供明确的路由信息的手段,该明确的路由信息用于路由器将数据包转发到目标地址以及记录沿循的路线。
严格源路由选项用于需要强制数据包通过特定路线的时候。必须在该选项中提供路径中的所有节点。
该选项的格式与宽松源路由选项相同,前面已经描述过。
如果源路由数据包在IP_T终止框中被终止,记录的线由必须被送到上层。
当创建严格源路由数据包的时候,该选项必须已经形成。这意味着,该IP包的目标地址必须是第一个路由器的IP地址,而该选项包含其它路由器的IP地址。在这个选项的清单里,不能出现多点传送地址。
Record_Route(记录路由)选项为IP包的源提供了一种记录来自源地址发往目标地址的数据包沿循的路由的手段。
该选项的格式与宽松源路由选项相同,上面已经描述过。
当创建该选项的时候,路由器有责任分配足够的空间,以登记完整的路径。
选项数据部分的大小(地址储存于其中)必须是IP地址的大小的倍数。
如果记录路由的数据包在IP_T终止框中被终止,记录的路由必须被送到上层。
Stream_ID选项用于通过不支持流概念的网络转发SATNET流。
该选项过时了。
如果它存在于被终止的IP包中,它必须被忽略。
该选项不会由IP_T终止框生成。
时间戳选项用于强制IP网络中一些或者所有的节点在被路由的数据包中插入时间戳。
Route_Alert选项用于与路由器通信,该路由器需要进一步检查并非直接送给它的数据包。
该选项的一个可能应用是,平滑地引入新路由能力,而无需重新建立基本的路由协议功能。
在IP终止框中,本选项必须被忽略。
IP_T终止框必须剥离报头,并通过协议来进行选择(“next layerforwarding”下一层转发),将负载转发到相应的上层客户端(例如,TCP、UDP、IGMP,...)。
在IP报头的协议字段中,明确了上层客户协议。如果协议未知或者未被激活,则该数据包被丢弃,并且与失败原因一起,通过协调功能被送到ICMP客户端。
与负载一起,IP_T终止框必须向上层转发:
-数据包的目标地址,
-严格源路由信息(如果存在的话),
-宽松源路由信息(如果存在的话),
-记录路由信息(如果存在的话),
-时间戳信息(如果存在的话),
-TTL(如果已知的话),
-已经接收过数据包的接口(如果是多点传送数据包),
IP_T终止框必须多路传输来自于不同的上层协议的负载(多路传输IP负载)。
与负载一起,上层协议必须向IP_T终止框转发:
-协议类型,
-数据包的源和目标地址;源地址必须是单点转发IP地址,不同于0.0.0.0,并且已经分配给了任一个路由器接口或者是路由器ID,
-严格源路由信息(如果存在的话),
-宽松源路由信息(如果存在的话),
-记录路由信息(如果存在的话),
-时间戳消息(如果存在的话),
-TTL,
-ToS,
-数据包的识别标识,
-数据包应当被发往的接口,无论它是否能够环回(如果是多点传送数据包)。
当生成IP报头时,必须进行以下操作:
-将报头的IP版本号字段的值设为4,
-利用从上层协议接收到的数据,设置服务类型字段,
-使用从上层协议接收到的数据来设定TTL的值;如果上层协议不提供TTL值,则使用默认值;对于单点转发数据包来说,该默认值可以由管理员规定;在第一次启动之后,默认的TTL值为255;对于多点传送数据包的默认值通常为1。
-使用从上层协议接收到的数据,设定协议字段、源和目标地址,
-将身份识别字段设成对于源地址/目标地址对来说唯一的值;该值是上层接收的;该值对于能够进行分片的节点来说是有用处的,
-将标志字段设置为0,除了“Don’t Fragment”标志外,该标志利用从上层协议收到的值进行设定,
-将片断偏移设为0,
-创建选项字段,
-生成垫整,
-计算报头长度并将其写入适当的字段,
-加上负载,
-计算总长度并将其写入适当的字段,
-根据总体算法计算校验和。
如果是多点传送数据包,生成它的上层可以要求,通过Mcast Loopback信号,来禁止数据报的本地发送,即使该路由器是该数据包要送达的组的成员。
IP多点传送数据包与该数据包应当被送达的接口(即Mcast信号)被送到IP_C框以进行网络发送,并且,如果上层不禁止本地发送,也通过此项功能送到上层进行本地发送。任何由路由器生成、并被网络接收的多点传送IP数据包都会在下一层转发过程中被丢弃。
转发多点传送数据包的接口可以被上层应用省略。在这种情况下,IP_T框应当发送给IP_C框一个默认接口,该默认接口由TMN(电信管理网络)提供。
在这个特定的实施例中,应用总是将每个多点传送数据包通知输出接口,因此不要求前面所述的性能。
ICMP(网际控制消息协议)用于允许路由器与它自身处理的数据包的源通信,例如,因为在处理该数据包的过程中出现了一些错误。它一直存在并且处于激活状态。
有三种ICMP消息:
-错误报告ICPM消息,
-请求ICPM消息,
-应答ICPM消息。
当处理错误的IP包时,错误报告ICMP消息可以由任何主机或者中间路由器生成。
如果参考图1,可以更好地领会下面的段落。
所有的错误数据包都被探测到错误状况的原子功能通过协调功能报告到ICMP框(图中未示出)。如果情况是这样,那么ICMP框随后生成适当的错误报告ICMP消息。所有生成的ICMP错误消息将会携带错误数据包的IP报头和尽量多的负载八位字节(即,不引起携带ICMP消息的IP包的大小超过576字节)。
为了避免不确定的消息,在下列情况下不生成错误报告ICMP消息:
-该错误数据包携带了ICMP消息,
-错误数据包的目标地址是广播或者多点传送地址,
-错误数据包是一个片断,但不是第一片。
为了限制ICMP错误消息的生成速度,路由器可以避免生成一些ICMP错误消息,即使检测到相应的错误状况。这个用来选择不生成哪些消息的机制是产品特有的。
仅在响应路由器生成的IP包的时候,错误报告ICMP消息才可以被ICMP框接收。随后,通过协调功能,这些消息被传送到生成该错误数据包的更高层协议(例如TCP或者UDP)。
任何更高层协议(例如TCP或者UDP)都可以要求ICMP框通过协调功能发送一些ICMP消息。请求ICMP消息随后被生成。
应答ICMP消息由ICMP框响应接收到的请求ICMP消息而生成。
只有在回答该ICMP框发出的请求ICMP消息的时候,应答ICMP消息才可以被该ICMP框接收。随后这些消息被转发到发出请求的更高层协议。
所有给该路由器的ICMP消息通过IP_T框被ICMP框接收。如果满足下列条件之一,接收到的ICMP消息被认为是非法的并被丢弃,而不进行处理。
-校验和不正确,
-长度不合法。
所有由ICMP框生成的ICMP消息被作为路由器生成的普通的IP包转发,通过IP_T框。这些消息不会在ICMP层中丢弃,而仅可能在较低的层中被丢弃。ICMP框也会将附加消息通知IP_T框。
-错误报告消息的源地址是探测到错误情况的接口的IP地址。应答消息的源地址是相应的请求的目标地址。请求消息的源地址由上层通知ICMP框,或者使用路由器ID。
-错误报告消息的目标地址是相应的错误IP包的源地址。应答消息的目标地址是相应的请求的源地址。请求消息的目标地址由上层通知ICMP框。
-不通知TTL,但是它会被IP_T框设定为默认值。路由器广告消息是例外:TTL设为1。
-错误报告和请求ICMP消息的ToS字段应当被设为网间控制消息编码(即,值“11000000”)。应答ICMP消息的ToS字段应当被设为与相应的请求中ToS字段同样的值。
-如果引起发送ICMP消息的数据包包括源路由选项(无论严格或者宽松源路由),那么同样类型的选项,带有通过把上行到当前点的路由进行翻转而获得的下一中继清单,应当被通知给IP_T框。当ICMP消息因为源路由选项自身发生错误而生成时,前面的请求则不会获得满足。
目标地址无法达到的消息是type=3的错误报告消息。
没有使用的字节在传输过程中设为0,并在接受的时候被忽略。
超时消息是type=11的错误报告消息。
没有使用的字节在传输过程中设为0,并在接受的时候被忽略。
参数出错的消息是type=12的错误报告消息。
没有使用的字节在传输过程中设为0,并在接受的时候被忽略。
Source Quench消息是type=4的错误报告消息。
只有code=0被定义。
重新定向消息是type=5的错误报告消息。
回声消息是请求和应答消息,分别是type=8和type=10。
只有code=0被定义。
时间戳消息是请求和应答消息,分别是type=13和type=14。
只有code=0被定义。
信息消息是请求和应答消息,分别是type=15和type=16。
只有code=0被定义。
Address mask(地址掩码)消息是请求和应答消息,分别是type=17和type=18。
只有code=0被定义。
路由请求和广告消息是请求和应答消息,分别是type=10和type=9。
只有code=0被定义。
在以上内容中,根据本发明的两个特别的实施例,基本上描述了通信设备中两种处理数据包(IP包和/或MPLS包)的方法。
根据另一个方面,本发明也涉及包括特别适合于实现这样的或者类似的方法的通信设备。
根据再一个方面,当所述的程序运行于计算机上时,本发明也涉及包含适合于执行这样的或者类似的方法的所有步骤的计算机程序编码的计算机程序产品。
根据最后一个方面,本发明还涉及其中记录有程序的计算机可读介质,当所述的程序运行在计算机上的时候,所述的计算机可读介质包括适合于执行这样或者类似的方法的所有步骤的计算机程序代码装置。

Claims (13)

1.一种在通信设备上处理IP包的方法,包括按照下列顺序的下列步骤:
在输入方向上:
(IPL_T)
-IP包验证,
-选择字段管理,
-滤波,
-第一个下一层决定和转发;
在输出方向上:
(IPL_T)
-重新定向管理
-TTL管理
-源地址管理
-选择字段管理
-数据包分片
2.如权利要求1所述的方法,其中,在IP包由该设备发出或者目标是该设备的情况下,还包括按照下列顺序的下列步骤:
在输入方向上,在第一个下一层决定和转发步骤之后:
(IP_T)
-IP包报头验证,
-数据包重组
-选项字段管理
-第二个下一层决定和转发;
在输出方向上,在重新定向管理步骤之前:
(IP_T)
-多路传输IP负载,
-选项字段管理,
-生成IP报头。
3.如权利要求2所述的方法,其中,在IP包将要被该设备发出的情况下,:
在输入方向上,在第一个下一层决定和转发步骤之后:
(IP_C)
-执行查找步骤,以决定输入IP包的目标地址,
在输出方向上,在重新定向管理步骤之前,并在生成IP报头步骤之后:
(IP_C)
-执行查找步骤,以决定输出IP包的目标地址。
4.如权利要求3所述的方法,其中,在IP in IP隧道的情况下,进一步包括按照下列顺序的下列步骤:
在输入方向上,在第一个下一层决定和转发步骤之后,并且查找步骤之前:
(IPIP_T)
-判断哪个报头必须被剥离,
-剥离隧道报头,
-处理被剥离的报头的TTL,除了已经在前面的步骤中处理过的第一个报头。
-处理所有被剥离的报头的CRC,除了已经在前面的步骤中处理过的第一个报头。
(IPL_T)
-IP包验证,
-选择字段管理,
-滤波,
-第三个下一层决定和转发;
在输出方向上,在查找步骤之后,并在重新定向管理步骤之前:
(IPL_T)
-重新定向管理
-TTL管理
-源地址管理
-选择字段管理
-数据包分片
(IPIP_T)
-判断必须建立哪个隧道,
-根据隧道地址,验证输入数据包的IP地址,
-进行从客户端接收者到隧道端点地址,以及反过来的地址翻译,
-插入外部报头,
-处理外部报头字段,强制分片标识取“Do Not Fragment”值,
-处理外部报头选项字段,
-计算外部报头校验和,
-进行路径MTU恢复,
-在传输过程出错的情况下,向在隧道中被路由的消息的发送者发送ICMP消息。
5.如权利要求3或4所述的方法,还包括:
在输入方向上,在第一个IP包验证步骤之前:
-MPLS包输入处理
在输出方向上,在查找步骤之后:
-MPLS包输出处理
6.一种在通信设备中处理MPLS包的方法,包括按照下列顺序的下列步骤:
在输入方向上,
(MPLSI_T)
-计算接收到的帧和八位字节的数目,
-根据标签范围,验证输入MPLS包,
-确定接口标识,
(MPLSI/MPLS_A)
-计算接收到的数据包和八位字节的数目,
-剥离外部MPLS报头,提取剥离的信息,
(MPLS_C)
-查找输入MPLS包的目标地址,
(MPLS_T)
-至少基于End_of_Stack标识,进行下一层决定,
-下一层转发,
(MPLS/IP_A,MPLS/MPLSI_A)
-TTL管理,
-如果下一中继不是设备本身,PHB判断,
在输出方向上:
(MPLS/IP_A)
-从接收到的输出客户数据包中提取TTL,
-将接收到的输出客户数据包作为被剥离的MPLS包,与接收到的FEC、PHB和TTL一起转发,
(MPLS_T)
-生成End_of_stack比特
-传递被剥离的MPLS包,以及FEC、PHB、TTL和End_of_Stack,
(MPLS_C)
-查找输出客户端数据包的目标地址,FEC由设备生成,
(MPLSI/MPLS_A)
-TTL管理,
-生成MPLS报头,
-计算发送的数据包和八位字节的数目,
(MPLSI_T)
-传递MPLS包、PHB和下一中继。
7.如权利要求6所述的方法,其中,在多MPLS封装的情况下,
在输入方向上,处理步骤在被剥离的MPLS包上重复;
在输出方向上,在一次MPLS报头生成步骤中,所有需要的MPLS标签被加入。
8.如权利要求6或7所述的方法,其中,在倒数第二个中继的情况下,在输入方向上,客户数据包被转发到低层,被剥离并发送出。
9.如权利要求6至8的任一条所述的方法,其中,客户数据包是一个IP包。
10.如权利要求6至8的任一条所述的方法,其中,客户数据包是以太网帧。
11.一种通信设备,特征在于,它包括适合于实现根据权利要求1至10中的任一条的方法的装置。
12.一种计算机程序产品,当所述的程序运行于计算机上时,包含适合于执行如权利要求1至10中的任一条所述的方法的所有步骤的计算机程序代码装置。
13.一种计算机可读介质,当所述的程序运行在计算机上的时候,包括适合于执行如权利要求1至10的任一条所述的方法的所有步骤的计算机程序代码装置。
CNB200310103010XA 2002-10-31 2003-10-28 通信设备中在第三层处理数据包的方法 Expired - Fee Related CN1312887C (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP02292719A EP1416682B1 (en) 2002-10-31 2002-10-31 Methods of processing data packets at layer three level in a telecommunication equipment
EP02292719.8 2002-10-31

Publications (2)

Publication Number Publication Date
CN1499794A true CN1499794A (zh) 2004-05-26
CN1312887C CN1312887C (zh) 2007-04-25

Family

ID=32088077

Family Applications (1)

Application Number Title Priority Date Filing Date
CNB200310103010XA Expired - Fee Related CN1312887C (zh) 2002-10-31 2003-10-28 通信设备中在第三层处理数据包的方法

Country Status (5)

Country Link
US (1) US7480292B2 (zh)
EP (1) EP1416682B1 (zh)
CN (1) CN1312887C (zh)
AT (1) ATE438242T1 (zh)
DE (1) DE60233145D1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107660342A (zh) * 2015-05-01 2018-02-02 亚马逊技术有限公司 通过自适应比特率清单处理的内容传递网络视频内容无效
US20230318969A1 (en) * 2022-03-31 2023-10-05 Lenovo (United States) Inc. Optimizing network load in multicast communications

Families Citing this family (60)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100534617B1 (ko) * 2004-01-29 2005-12-07 삼성전자주식회사 다중 룩업 부하 감소기능이 구비된 엠피엘에스 에지라우터 및 그 제어방법
US7616663B1 (en) 2004-03-04 2009-11-10 Verizon Corporate Services Group, Inc. Method and apparatus for information dissemination
US7821929B2 (en) * 2004-04-05 2010-10-26 Verizon Business Global Llc System and method for controlling communication flow rates
US8289973B2 (en) * 2004-04-05 2012-10-16 Verizon Business Global Llc System and method for indicating classification of a communications flow
US7869450B2 (en) * 2004-04-05 2011-01-11 Verizon Business Global Llc Method and apparatus for processing labeled flows in a communication access network
US20050220059A1 (en) * 2004-04-05 2005-10-06 Delregno Dick System and method for providing a multiple-protocol crossconnect
US8218569B2 (en) 2004-04-05 2012-07-10 Verizon Business Global Llc Apparatus and method for terminating service emulation instances
US8948207B2 (en) * 2004-04-05 2015-02-03 Verizon Patent And Licensing Inc. System and method for transporting time-division multiplexed communications through a packet-switched access network
US8340102B2 (en) 2004-04-05 2012-12-25 Verizon Business Global Llc Apparatus and method for providing a network termination point
US8249082B2 (en) * 2004-04-05 2012-08-21 Verizon Business Global Llc System method for a communications access network
US7908291B2 (en) * 2005-01-07 2011-03-15 Oracle International Corporation Technique for creating self described data shared across multiple services
EP1864434A1 (en) * 2005-03-08 2007-12-12 Matsushita Electric Industrial Co., Ltd. Network managing method and network managing apparatus
US7944853B2 (en) * 2006-01-06 2011-05-17 Belair Networks Inc. Virtual root bridge
US7961635B2 (en) * 2006-05-24 2011-06-14 At&T Intellectual Property I, Lp Network latency analysis packet and method
CN100583827C (zh) * 2007-05-17 2010-01-20 华为技术有限公司 一种多协议标签交换网络流量切换的方法及设备
US7920560B2 (en) * 2007-06-12 2011-04-05 Hewlett-Packard Development Company, L.P. Method for detecting topology of computer systems
US8645524B2 (en) * 2007-09-10 2014-02-04 Microsoft Corporation Techniques to allocate virtual network addresses
US7792031B2 (en) * 2008-07-03 2010-09-07 Telefonaktiebolaget Lm Ericsson (Publ) Optimal fragmentation of multicast packets
US8850065B2 (en) * 2012-01-04 2014-09-30 Alcatel Lucent Diameter route learning
CN102447639B (zh) * 2012-01-17 2016-03-09 华为技术有限公司 一种策略路由方法及装置
US8619579B1 (en) 2013-03-15 2013-12-31 Extrahop Networks, Inc. De-duplicating of packets in flows at layer 3
US8867343B2 (en) 2013-03-15 2014-10-21 Extrahop Networks, Inc. Trigger based recording of flows with play back
US8626912B1 (en) 2013-03-15 2014-01-07 Extrahop Networks, Inc. Automated passive discovery of applications
US9929966B2 (en) * 2014-03-21 2018-03-27 Fujitsu Limited Preservation of a TTL parameter in a network element
KR101801587B1 (ko) * 2014-10-20 2017-11-27 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
US9338147B1 (en) 2015-04-24 2016-05-10 Extrahop Networks, Inc. Secure communication secret sharing
US10291957B2 (en) * 2015-05-22 2019-05-14 Telefonaktiebolaget Lm Ericsson (Publ) Quicker IPTV channel with static group on IGMP loopback interface
CN105429882A (zh) * 2015-10-21 2016-03-23 盛科网络(苏州)有限公司 基于传统交换芯片查找方式的报文编辑实现方法及装置
US10204211B2 (en) 2016-02-03 2019-02-12 Extrahop Networks, Inc. Healthcare operations with passive network monitoring
US9729416B1 (en) 2016-07-11 2017-08-08 Extrahop Networks, Inc. Anomaly detection using device relationship graphs
US9660879B1 (en) 2016-07-25 2017-05-23 Extrahop Networks, Inc. Flow deduplication across a cluster of network monitoring devices
US10476673B2 (en) 2017-03-22 2019-11-12 Extrahop Networks, Inc. Managing session secrets for continuous packet capture systems
US10263863B2 (en) 2017-08-11 2019-04-16 Extrahop Networks, Inc. Real-time configuration discovery and management
US10063434B1 (en) 2017-08-29 2018-08-28 Extrahop Networks, Inc. Classifying applications or activities based on network behavior
US9967292B1 (en) 2017-10-25 2018-05-08 Extrahop Networks, Inc. Inline secret sharing
US10757230B2 (en) 2017-12-11 2020-08-25 Mellanox Technologies Tlv Ltd. Efficient parsing of extended packet headers
US10701190B2 (en) * 2018-01-10 2020-06-30 Mellanox Technologies Tlv Ltd. Efficient parsing of optional header fields
US10264003B1 (en) 2018-02-07 2019-04-16 Extrahop Networks, Inc. Adaptive network monitoring with tuneable elastic granularity
US10389574B1 (en) 2018-02-07 2019-08-20 Extrahop Networks, Inc. Ranking alerts based on network monitoring
US10038611B1 (en) 2018-02-08 2018-07-31 Extrahop Networks, Inc. Personalization of alerts based on network monitoring
US10270794B1 (en) 2018-02-09 2019-04-23 Extrahop Networks, Inc. Detection of denial of service attacks
US10116679B1 (en) 2018-05-18 2018-10-30 Extrahop Networks, Inc. Privilege inference and monitoring based on network behavior
US10411978B1 (en) 2018-08-09 2019-09-10 Extrahop Networks, Inc. Correlating causes and effects associated with network activity
US10594718B1 (en) 2018-08-21 2020-03-17 Extrahop Networks, Inc. Managing incident response operations based on monitored network activity
US10965702B2 (en) * 2019-05-28 2021-03-30 Extrahop Networks, Inc. Detecting injection attacks using passive network monitoring
US11165814B2 (en) 2019-07-29 2021-11-02 Extrahop Networks, Inc. Modifying triage information based on network monitoring
US11388072B2 (en) 2019-08-05 2022-07-12 Extrahop Networks, Inc. Correlating network traffic that crosses opaque endpoints
US10742530B1 (en) 2019-08-05 2020-08-11 Extrahop Networks, Inc. Correlating network traffic that crosses opaque endpoints
US10742677B1 (en) 2019-09-04 2020-08-11 Extrahop Networks, Inc. Automatic determination of user roles and asset types based on network monitoring
US11258885B2 (en) 2019-12-10 2022-02-22 Mellanox Technologies, Ltd. Flexible parser in a networking device
US11165823B2 (en) 2019-12-17 2021-11-02 Extrahop Networks, Inc. Automated preemptive polymorphic deception
US11323372B2 (en) 2020-04-21 2022-05-03 Mellanox Technologies Ltd. Flexible steering
CN111683073A (zh) * 2020-05-29 2020-09-18 烽火通信科技股份有限公司 一种基于mac的三层应用的通信方法及系统
US11463466B2 (en) 2020-09-23 2022-10-04 Extrahop Networks, Inc. Monitoring encrypted network traffic
EP4218212A1 (en) 2020-09-23 2023-08-02 ExtraHop Networks, Inc. Monitoring encrypted network traffic
US11425230B2 (en) 2021-01-28 2022-08-23 Mellanox Technologies, Ltd. Efficient parsing tuned to prevalent packet types
US11349861B1 (en) 2021-06-18 2022-05-31 Extrahop Networks, Inc. Identifying network entities based on beaconing activity
US11296967B1 (en) 2021-09-23 2022-04-05 Extrahop Networks, Inc. Combining passive network analysis and active probing
US11711453B2 (en) 2021-10-24 2023-07-25 Mellanox Technologies, Ltd. Template-based packet parsing
US11843606B2 (en) 2022-03-30 2023-12-12 Extrahop Networks, Inc. Detecting abnormal data access based on data similarity

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5566170A (en) * 1994-12-29 1996-10-15 Storage Technology Corporation Method and apparatus for accelerated packet forwarding
US6339595B1 (en) * 1997-12-23 2002-01-15 Cisco Technology, Inc. Peer-model support for virtual private networks with potentially overlapping addresses
US20020085567A1 (en) * 2000-12-28 2002-07-04 Maple Optical Systems, Inc. Metro switch and method for transporting data configured according to multiple different formats
WO2002065700A2 (en) * 2001-02-14 2002-08-22 Clearspeed Technology Limited An interconnection system
US7200146B2 (en) * 2001-08-17 2007-04-03 Intel Corporation System and method of IP packet forwarding across directly connected forwarding elements
US6950398B2 (en) * 2001-08-22 2005-09-27 Nokia, Inc. IP/MPLS-based transport scheme in 3G radio access networks
US7310356B2 (en) * 2002-06-24 2007-12-18 Paradyne Corporation Automatic discovery of network core type

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107660342A (zh) * 2015-05-01 2018-02-02 亚马逊技术有限公司 通过自适应比特率清单处理的内容传递网络视频内容无效
US20230318969A1 (en) * 2022-03-31 2023-10-05 Lenovo (United States) Inc. Optimizing network load in multicast communications

Also Published As

Publication number Publication date
EP1416682B1 (en) 2009-07-29
EP1416682A1 (en) 2004-05-06
US20040088430A1 (en) 2004-05-06
ATE438242T1 (de) 2009-08-15
US7480292B2 (en) 2009-01-20
CN1312887C (zh) 2007-04-25
DE60233145D1 (de) 2009-09-10

Similar Documents

Publication Publication Date Title
CN1499794A (zh) 通信设备中在第三层处理数据包的方法
CN1592259A (zh) 网络用交换装置、路径管理服务器、网络接口装置及其控制方法
CN1131624C (zh) 短信元复用atm传送系统及传送方法
CN1405986A (zh) 第2层虚拟专用网络中继系统
CN1679279A (zh) 网络系统、生成树构成方法、生成树构成节点和生成树构成程序
CN1682500A (zh) 网络中的帧传送方法以及节点、帧传送程序
CN1160915C (zh) 用于在互联网路由提供商之间互连的专用网络接入点路由器
CN1172506C (zh) 通过互联网传送多媒体数据的管理方法及实施该方法所用的芯片卡
CN1756189A (zh) 基于snmp的ip网络拓扑发现方法
CN1206837C (zh) 按规定的策略在多服务器实施ip数据报发送的方法和系统
CN101032137A (zh) 网络系统、节点及节点控制程序、网络控制方法
CN1531282A (zh) 分组中继装置
CN1685672A (zh) 通信控制方法及系统,数据包转发及监测方法和系统
CN1496632A (zh) 用在扩展局域网中的以优先级为基础的负载平衡方法和设备
CN1968251A (zh) 数据通信装置
CN1300149A (zh) 帧构造方法、帧构造装置和数据传输系统
CN1774890A (zh) 用于网络中速率控制服务的系统和方法
CN1703016A (zh) 虚拟网络拓扑结构生成
CN1729660A (zh) 分组发送接收装置
CN1708017A (zh) 协议仿真器
CN1650572A (zh) 群组判定设备
CN1308437A (zh) 用于媒体数据传输的方法和装置
CN1568589A (zh) 处理光网络下行数据包的方法和系统
CN1618223A (zh) 弹性多业务环
CN1738219A (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
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20070425

Termination date: 20191028

CF01 Termination of patent right due to non-payment of annual fee