CN1300985C - 在二层虚拟专用网络中处理超长报文的方法 - Google Patents

在二层虚拟专用网络中处理超长报文的方法 Download PDF

Info

Publication number
CN1300985C
CN1300985C CNB031091385A CN03109138A CN1300985C CN 1300985 C CN1300985 C CN 1300985C CN B031091385 A CNB031091385 A CN B031091385A CN 03109138 A CN03109138 A CN 03109138A CN 1300985 C CN1300985 C CN 1300985C
Authority
CN
China
Prior art keywords
message
length
tunnel
equipment
feedback information
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.)
Expired - Fee Related
Application number
CNB031091385A
Other languages
English (en)
Other versions
CN1536832A (zh
Inventor
欧阳光
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.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CNB031091385A priority Critical patent/CN1300985C/zh
Publication of CN1536832A publication Critical patent/CN1536832A/zh
Application granted granted Critical
Publication of CN1300985C publication Critical patent/CN1300985C/zh
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Landscapes

  • Communication Control (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明公开了一种解决二层虚拟专用网络中的链路最大传输单元字节数的方法,包括在PE设备上增加一个ICMP协议,ICMP协议能够为网络发布错误报告,当用户发出的报文长度超过1522字节时,ICMP协议能够自动产生一个目的不可达的错误报告并将能够发送报文的最大字节数反馈给用户主机,使用户能够根据反馈的信息重新发送长度适合的报文。使用本方法能够限制用户计算机发出报文的大小,从源头上防止出现超过1522字节的报文,可以有效地保证报文不会被丢弃。

Description

在二层虚拟专用网络中处理超长报文的方法
发明领域
本发明一般涉及网络传输技术,特别涉及一种解决二层虚拟专用网络中链路最大传输单元字节数限制问题的方法。
背景技术
在L2VPN(二层虚拟专用网络)中,当用户报文通过隧道时,它必须被封装在新的链路层帧头以及隧道承载协议层里,例如,基于MPLS(多协议标签交换)协议的隧道必须加装两层MPLS标签头。如果用户侧的链路和隧道侧的链路都建立在以太网上,这样以太网用户报文在加装隧道协议头后,最大帧长就会远远超过以太网协议的最大帧长1522字节,但是由于二层协议不可能对报文进行分片处理,所以在没有任何措施的情况下,这种超长报文一般都被服务商边缘设备(本文中是指隧道边缘设备,以下简称为PE设备)或服务商设备(本文中是指隧道中间设备,以下简称为P设备)丢弃。下面将结合附图对这个问题进行详细说明。
图1是L2VPN典型组网示意图。如图1所示,本地的vlan(虚拟局域网)8通过L2VPN隧道与远端的vlan 12相连,这样从vlan 8中发往vlan 12的报文都需要经过PE1加装隧道承载协议头,然后才能发送到隧道中去。因为在此过程中,PE1一般不会感知用户的二层报文里面到底是封装的什么协议,所以L2VPN是不可能进行分片处理的。L2VPN协议规定:如果用户报文长度加上隧道封装头的长度超过隧道的MTU(链路最大传输单元的字节数)值,PE设备不可以分片处理,而是简单地将其丢弃。
但是这种处理存在着很大的缺陷,为了更加清楚地说明问题,我们假设隧道是建立在MPLS协议之上的。图2是基于MPLS协议的L2VPN隧道封装报文示意图。如图2所示,原始用户报文加装隧道协议头部后一般情况下会增长22或者26(有Vlan tag的情况下)个字节,这样,进入MPLS隧道的报文长度最大可到1522+26=1548字节,它已经大大超过了以太网允许的MTU值1522,由于L2VPN协议不允许进行分片处理,所以按照以往的以太网协议规定,这些超长报文必须被扔掉。
上述缺陷是所有L2VPN协议都面临的一个重大问题。针对这个问题,现有技术中已经提出了一些解决方案。其中一种解决方案是:不管以太网协议的限定,强行将隧道上所有的设备出口的MTU值改为1548字节以上,目前大部分以太网接口芯片都支持发送和接收超过1522字节的以太网报文,所以很多设备都支持这种设置,CISCO为这种报文还专门取了一个名字,叫Biggiant报文。但是,这种解决方案的问题在于:必须让沿途所有的P设备和PE设备都支持接收和发送这类超长的以太网报文,否则,无论那个中间节点不支持这些协议,都会无条件将帧扔掉或者错误地进行分片处理。在复杂网络情况下,由于隧道中间的P节点可能会很多,并且可能属于不同的设备商提供。因此,不能完全保证L2VPN隧道所涉及到的P设备都支持这种设置。还有一种解决方案,即,利用jumbo帧(超大帧)封装协议对以太网本文进行封装。该协议是一种非正式标准的协议,它能够支持在以太网上传输最长到9022字节的报文,它本来是专门为G比特以太网开发的协议,但L2VPN可以借用这一协议来解决自己的MTU问题。但是,这种解决方案也存在着与上述第一种解决方案相类似的问题,即,必须让沿途所有的P设备和PE设备都支持jumbo帧封装协议,否则,无论那个中间节点不支持这些协议,都会无条件将帧扔掉或者错误地进行分片处理。在复杂网络情况下,隧道中间的P节点可能会很多,并且可能属于不同的设备商提供。因此,不能完全保证L2VPN隧道所涉及到的P设备、PE设备和链路都支持这种协议。
另外,作为对本发明的一个参考,在相关的现有技术中有一种处理超长报文的方法,该方法采用ICMP(网间控制报文协议)对超长报文进行控制。图3示出了这种超长报文处理方法的示意图。如图3所示,当计算机的操作***通过路由器在网络上传送文件时,发送的报文都会使用禁止分片功能,即,报文的IP头部中的DF(禁止分片标志位)标志被置位,由于DF标志位是公知的IP协议中的一个重要标志位,故此不再说明。如果路由器接收到此类报文,并且又发现该报文长度比接口MTU大,由于该报文已经明确指定不准分片,所以IP协议规定,该报文必须被丢弃,并且路由器将回应给源主机一个type=3,code=4类型的ICMP报文,并在该报文中携带接口的MTU值,这样主机收到该报文后,就会主动调节自己的MTU值为ICMP报文中所携带的值,以后该主机发出的所有报文都会小于这个值。但是,现有技术中的这种方法只给出了在三层网络传输中的应用,而并未给出在诸如L2VPN的二层网络传输技术中的应用。
发明内容
为了解决现有技术中存在的上述缺陷,本发明的目的是提供一种能够从根源上防止二层虚拟专用网络中的报文长度超长的方法。
为了实现上述目的,本发明提供了一种在二层虚拟专用网络中处理超长报文的方法,该方法包括以下步骤:1)在PE设备上捆绑一个报文控制协议;2)当从发送端发送至所述PE设备的报文是一个被禁止分片的报文并且其长度超过一预定长度时,所述PE设备利用所述报文控制协议自动产生一个反馈信息并将其返回给发送端,该反馈信息中至少包括下一报文的允许长度;3)发送端根据所述反馈信息中的下一个报文的允许长度调整报文长度并重新发送报文。
通过利用本发明所述的方法在PE设备上捆绑一个报文控制协议,并利用这种协议对报文的长度进行控制,就可以限制住用户计算机所发出的报文的长度,从而在源头上防止出现超过1522字节的报文。这样,无论P设备是否支持上述两种协议,都可以保证报文不会被丢弃。
附图说明
图1是L2VPN典型组网示意图;
图2是基于MPLS协议的L2VPN隧道封装报文示意图;
图3是现有技术中DF置位的超长报文的处理示意图;
图4是根据本发明实施例所述的二层虚拟专用网络中处理超长报文的方法示意图;
图5是本发明实施例中的ICMP报文的结构示意图。
具体实施方式
下面将参考图4和图5对本发明的实施例进行详细说明。
为了减少路由器耗时的分片操作并提高网络效率,目前的主流操作***在网络通讯时,基本上都会将报文的DF置位,并且随时准备按情况调整自己的MTU值。本发明的意图就是利用这一特点,在PE设备上添加一个ICMP(网间控制报文协议)并通过利用该协议回应ICMP报文来主动调节主机的MTU值,从而达到解决L2VPN MTU值的问题。下面将对本发明的具体实施方式进行详细说明。
首先,需要在PE设备上捆绑一个ICMP协议。ICMP协议是一个现有的三层协议,并非是L2VPN协议中所有的,其最基本的一个功能是为网络发布错误报告,例如自动反馈给用户一个目的不可达的ICMP报文(Type=3,code=4)。目前,几乎所有的路由器或者三层交换机都支持这个协议。至于捆绑ICMP协议的具体过程,由于它在本领域中是公知的,故此不再赘述。
然后,如图4所示,在PC机发出的原始报文通过PE设备进入隧道时,根据L2VPN协议,PE设备必须为其加装隧道协议头部。在加装完隧道协议头部之后,PE设备将对加装头部后的报文的长度与隧道的MTU值(也就是以太网的最大长度1522字节)进行比较,并且判断报文的DF是否置位。如果该报文是一个DF置位的IP报文,并且在加装隧道协议头部之后其长度超过了隧道的MTU值(即,1522字节),则PE设备将丢弃该报文并向PC机回应一个ICMP报文,并且在该ICMP报文中携带出接口的MTU值以反馈给PC机。例如,在隧道是建立在MPLS协议之上的情况下,ICMP报文中所携带的隧道的MTU值可以为1500-26=1474。注意,在上述例子中,因为ICMP协议规定必须回应三层净荷的最大长度,所以需要先除去二层帧头(18字节)+二层帧CRC校验和(4字节)再除去隧道协议头部的长度(26字节),这样才能正确指明隧道的MTU值。另外,由于目前主流网络通信中的报文的DF都是置位的,所以上述判断DF置位的步骤也可省略。
图5示出了一个ICMP报文的结构。如图5所示,在ICMP报文帧的ICMP帧头中指出了下一次发送时报文的MTU值(本例中为1474)。当接收到上述带有MTU值的ICMP报文之后,用户PC机只需按照ICMP报文中所反馈的数值(1474)自动降低自己相应网络接口的MTU值即可。由于目前任何支持TCP/IP协议的主机都肯定支持ICMP协议,并且该协议的操作流程也是公知的,故不再对其进行说明。这样,以后所有的用户报文即使加装隧道协议头部后都不会超过正常的以太网MTU值。
本发明利用ICMP协议的错误报告反馈功能,使用户主机主动降低自己的MTU值,在不用更新设备的基础上到达解决L2VPN中MTU值不匹配又不能分片的缺陷,可以有效地保证报文不会被丢弃。这对L2VPN协议是一个非常有意义的补充。
应该注意的是,虽然以上对本发明的说明是参考其具体实施例来进行的,但它并不意味着是对本发明的限制。本领域的普通技术人员应该明白,可以在本发明思想的基础上对其做出各种修改和变换。总之,不背离本发明精神的各种改型均在本发明所附的权利要求的保护范围之内。

Claims (7)

1.一种在二层虚拟专用网络中处理超长报文的方法,包括以下步骤:
1)在隧道边缘设备PE上添加一个报文控制协议;
2)当从发送端发送至所述PE设备的报文是一个被禁止分片的报文并且其长度超过一预定长度时,所述PE设备利用所述报文控制协议自动产生一个反馈信息并将其返回给发送端,该反馈信息中至少包括下一报文的允许长度;
3)发送端根据所述反馈信息中的下一个报文的允许长度调整报文长度并重新发送报文。
2.根据权利要求1所述的方法,其特征在于,所述报文控制协议为网间控制报文协议ICMP。
3.根据权利要求1所述的方法,其特征在于,所述预定长度为以太网的最大帧长。
4.根据权利要求1所述的方法,其特征在于,所述步骤2)中还包括判断所述报文长度是否超过所述预定长度的步骤。
5.根据权利要求1所述的方法,其特征在于,所述步骤2)中还包括判断所述报文的IP头部中的禁止分片标志位DF是否被置位的步骤。
6.根据权利要求1所述的方法,其特征在于,所述步骤2)中的下一报文的允许长度是合法的以太网报文长度,最大值小于所述的预定长度。
7.根据权利要求1至6中任意一项所述的方法,其特征在于,所述步骤3)中进一步包括发送端将报文长度调整为包含在所述反馈信息中的所述报文的允许长度的步骤。
CNB031091385A 2003-04-04 2003-04-04 在二层虚拟专用网络中处理超长报文的方法 Expired - Fee Related CN1300985C (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CNB031091385A CN1300985C (zh) 2003-04-04 2003-04-04 在二层虚拟专用网络中处理超长报文的方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CNB031091385A CN1300985C (zh) 2003-04-04 2003-04-04 在二层虚拟专用网络中处理超长报文的方法

Publications (2)

Publication Number Publication Date
CN1536832A CN1536832A (zh) 2004-10-13
CN1300985C true CN1300985C (zh) 2007-02-14

Family

ID=34319203

Family Applications (1)

Application Number Title Priority Date Filing Date
CNB031091385A Expired - Fee Related CN1300985C (zh) 2003-04-04 2003-04-04 在二层虚拟专用网络中处理超长报文的方法

Country Status (1)

Country Link
CN (1) CN1300985C (zh)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1956353B (zh) * 2005-10-28 2011-07-20 华为技术有限公司 基于隧道进行流管理的方法和无线接入中转***
CN100454900C (zh) * 2006-01-24 2009-01-21 华为技术有限公司 快速响应ip分片报文的方法和***
CN101242341B (zh) * 2007-02-07 2015-07-29 华为技术有限公司 一种报文调度方法及装置
CN101459592B (zh) * 2007-12-12 2011-05-11 华为技术有限公司 供应商边缘设备之间传送报文的方法、***及设备
CN101552728B (zh) * 2009-05-12 2012-05-23 北京师范大学 一种面向IPv6的路径MTU发现方法及***
CN101827031A (zh) * 2010-04-22 2010-09-08 中兴通讯股份有限公司 一种用户数据包协议udp隧道中传输报文的方法及装置
JP5672836B2 (ja) * 2010-08-09 2015-02-18 日本電気株式会社 通信装置、通信方法、および通信プログラム
CN102263699B (zh) * 2011-08-15 2014-12-24 杭州华三通信技术有限公司 一种应用于mpls tp的负载均衡实现方法及其装置
CN102594505A (zh) * 2012-02-08 2012-07-18 华为技术有限公司 数据传输方法及装置
CN104320359A (zh) * 2014-11-24 2015-01-28 上海斐讯数据通信技术有限公司 一种堆叠式交换机的数据包传输方法及***
CN106330706A (zh) * 2015-07-01 2017-01-11 中兴通讯股份有限公司 一种获取设备接口mru值的方法和装置
CN109525534A (zh) * 2017-09-18 2019-03-26 北京握奇智能科技有限公司 一种在安全网络中保证报文不被分片的方法和***

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002044890A2 (de) * 2000-11-28 2002-06-06 Infineon Technologies Ag Anordnung zur befehlsübertragung
JP2003060730A (ja) * 2001-08-14 2003-02-28 Nippon Telegr & Teleph Corp <Ntt> Hdlc信号送受信方法及びhdlc信号装置、ならびにそのプログラムと記録媒体

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002044890A2 (de) * 2000-11-28 2002-06-06 Infineon Technologies Ag Anordnung zur befehlsübertragung
JP2003060730A (ja) * 2001-08-14 2003-02-28 Nippon Telegr & Teleph Corp <Ntt> Hdlc信号送受信方法及びhdlc信号装置、ならびにそのプログラムと記録媒体

Also Published As

Publication number Publication date
CN1536832A (zh) 2004-10-13

Similar Documents

Publication Publication Date Title
US7852789B2 (en) Methods, systems, and/or devices for providing network access
EP1766876B1 (en) Technique for transferring data over a packet switched network
CN100382517C (zh) 网络服务质量测试方法及***
CN1300985C (zh) 在二层虚拟专用网络中处理超长报文的方法
CN101247353B (zh) 流老化方法及网络设备
Xiao et al. Requirements for pseudo-wire emulation edge-to-edge (PWE3)
EP3588859B1 (en) Network device configuration versioning
CN1514585A (zh) 用于检测连接故障的方法,***和网络实体
CN100433714C (zh) 一种ip分片报文传输处理方法
CN100464519C (zh) 捆绑链路状态的管理方法
CN104113513B (zh) 一种主机发现方法、装置及***
CN109743758A (zh) 多链路通信方法、通信装置及通信***
EP2627037A1 (en) Network configuration method, ring network system, and node
CN101827012B (zh) 分组传送网及其承载纯三层ip包业务的方法
CN101252526B (zh) 流量控制方法以及vpws网络***
CN101166138A (zh) 二层虚拟专网业务传送的装置
CN101262424B (zh) 转发mpls报文的方法、设备及mpls通信***
Cisco Cisco uBR7200 Series - Cisco IOS Release 12.2 XF
Cisco Cisco uBR7100 Series - Cisco IOS Release 12.2 BC
WO2014117474A1 (zh) 路由方法、***及相关设备
CN103109504A (zh) 提供使用偏移的带内控制信道的伪线
CN100428740C (zh) 包交换网络中配属电路连接状态通告方法及服务设备
CN100589460C (zh) 一种网关设备及在网关设备实现广域网共享连接的方法
CN101166148A (zh) 二层虚拟专网业务传送的方法
EP4391475A1 (en) Bit index explicit replication (bier) with anycast

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: 20070214

Termination date: 20150404

EXPY Termination of patent right or utility model