CN1716943A - 获取隧道网关环境中路径最大传输长度的方法及系统 - Google Patents
获取隧道网关环境中路径最大传输长度的方法及系统 Download PDFInfo
- Publication number
- CN1716943A CN1716943A CN 200410059486 CN200410059486A CN1716943A CN 1716943 A CN1716943 A CN 1716943A CN 200410059486 CN200410059486 CN 200410059486 CN 200410059486 A CN200410059486 A CN 200410059486A CN 1716943 A CN1716943 A CN 1716943A
- Authority
- CN
- China
- Prior art keywords
- tunnel
- maximum transmitted
- length
- gateway
- links
- 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
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种获取隧道网关环境中路径最大传输长度的方法及系统,所述系统的隧道网关包括:隧道链路MTU获取装置和隧道链路MTU配置装置,由隧道网关建立隧道链路MTU;当探测报文经过隧道网关时,隧道网关根据建立的隧道链路MTU及探测报文的长度,向发送方返回ICMP控制报文;发送方根据返回的ICMP控制报文调整探测报文的长度,直到发送方认为报文已不会再被分片为止,此时的报文长度即为路径MTU。利用本发明,可以使隧道网关对不可分片的IP报文简单、有效地返回ICMP消息。同时,对于可分片的IP报文,可以根据需要选择采用隧道MTU或者链路MTU对报文进行分片处理,有利于提高网络传输效率。
Description
技术领域
本发明涉及网络通信技术领域,具体涉及一种获取路径最大传输长度的方法及系统。
背景技术
随着网络技术的发展,TCP/IP(传输控制协议/网际协议)协议保证了各种异构网络实现互联,这样,IP报文的传输就可能经过多种混合型链路,如以太网、FDDI(光纤分布式数据接口)、ATM(异步传输模式)等。两台主机通过互联网进行通信时,一个较长的IP报文在传输时,常常由于超过了底层链路MTU(最大传输长度)的限制而需要进行分片。MTU是指一个特定的网络所允许的物理帧的最大数据量,链路层具有MTU,它限制了数据帧的最大传输长度,不同的网络类型都有一个上限值,比如,以太网的MTU是1500。当路由器收到一个大于其要转发的网络的MTU的数据报时,路由器必须将这个数据报分成可通过该网络的数据报片,使每一片的长度都小于或等于MTU。每一片仍采用数据报的格式,且保留原数据报的标识符,但只包含原数据报的部分数据,在需要时,数据报片可以再次分片。假设要传送一个UDP数据包,以太网的MTU是1500字节,一般IP首部为20字节,UDP首部为8字节,数据的净荷部分是1500-20-8=1472字节,如果数据部分大于1472字节,就会出现分片。IP首部包含了分片与重组所需的信息。当数据报被分片后,每个片的总长度值要改为该片的长度值。
在一个TCP/IP互联网上,一旦数据报分片后,每片都作为独立的数据报传送,一直等到到达目的主机后,才由IP层重组为原报文。目的主机通过数据报首部的标识符来查证各片是否为同一个数据报的分片,且根据片偏移及标志来控制分片和重组。
分片重组技术的使用,虽然给使用者带来了方便,但是也存在一些问题:如果一个报文中的一个分片没有正常到达目的主机,则整个报文的传输失败,需要重新传输整个报文。所以,为了提高报文传输效率,希望传输的报文在传输过程中不进行分片,这就需要发送方一开始就知道整个路径上最小的链路MTU,即路径MTU(PMTU)。为此,RFC1191给出了一种探测PMTU的方法,该方法的过程描述如下:
(1)发送方构造一个充分大的IP探测报文(长度大于出口的MTU),对IP头中的DF位置位,标识该报文不可分片,然后发送。
(2)沿途的路由器如果要对报文分片,在检查到DF位置位后,就会丢弃报文,并向源主机返回一个目的不可达类型的ICMP(互联网控制管理协议)差错控制报文。
(3)发送方收到ICMP差错控制报文后,减小探测报文的长度,然后再发送出去。
(4)如此反复探测,直到发送方认为报文已不会再被分片为止,此时的报文长度即为PMTU。
通常利用ICMP的echo/reply(回应请求/应答)报文来实现这一方案。
该方法在有隧道网关的环境中很有可能会出现问题。
隧道是一个数据包封装在另一个数据包的净荷中进行传送时所经过的路径。采用隧道技术可以将一个协议的报文封装在另一个协议中,并利用第二个协议的设备穿过一些网络节点,到达目的地后,封装被剥离,原报文被重新注入到该网络中。隧道技术能克服网络的局域性,将两个互相隔开的站点链接起来。现在互联网中有许多的隧道网关,如IPv4/IPv6网关、Ipsec(IP security)网关等等。报文在经过这些网关时,会将整个IP报文作为数据内容,外加新的IP头,然后再进行转发。
隧道转发的原理如图1所示:其中,新IP头的源地址是发送方的隧道网关,目的地址是接收方的隧道网关。报文发送到接收方隧道网关时,由该网关去掉新的IP头,恢复原来的IP报文再继续转发。
在互联网传输的过程中,如果中途路由器要对超长报文分片,但由于探测报文标志为不可分片,则中途路由器会丢弃报文,并返回目的不可达类型的ICMP差错控制报文,该报文中会携带原IP报文的首部及其后续8个字节的内容,处理过程如图2所示:中途路由器能处理的只是隧道报文,不可能看到原来的IP头,所以IP头1的目的地址是发送方的隧道网关,源地址是中途路由器。而ICMP携带的原报文信息只是隧道报文的IP头及其后续的8个字节。在这种情况下,发送方隧道网关收到ICMP差错控制报文后,应该转发给源主机,这样才能通知主机报文超长。但是,隧道网关仅通过该报文内容是难以确定原IP报文的源IP地址的,故一般情况下难以将ICMP报文返回给源主机。
针对上述问题,RFC2401提出了一种解决方案,该方案具体描述如下:
(1)IPsec网关收到中途路由器返回的ICMP目的不可达报文(对不能分片的报文需要分片)时,如果能根据ICMP报文中携带的信息(新IP头+后续的8个字节)确定原报文的源地址,就将根据该信息重新构建ICMP差错控制报文,将其传送给所有可能的源主机。
这一点在IPsec网关中是有可能实现的,因为经IPsec网关封装的隧道报文结构可能如图3所示:
其中,AH(认证头)中记录了头部认证协议的相关信息,提供无连接的完整性验证、数据源认证、选择性抗重播服务。AH报头字段包括:
下一个报头:识别下一个使用IP协议号的报头,例如,Next Header值等于″6″,表示紧接其后的是TCP报头。
长度:AH报头长度。
SPI(安全参数索引):这是一个为数据报识别安全关联的32位伪随机值。SPI值0被保留来表明″没有安全关联存在″。
序列号:从1开始的32位单增序列号,不允许重复,唯一地标识了每一个发送数据包,为安全关联提供反重播保护。接收端校验序列号为该字段值的数据包是否已经被接收过,若是,则拒收该数据包。
AD(认证数据):包含完整性检查和。接收端接收数据包后,首先执行hash计算,再与发送端所计算的该字段值比较,若两者相等,表示数据完整,若在传输过程中数据遭修改,两个计算结果不一致,则丢弃该数据包。
SPI是IPSec协议中的一个重要参数,它与目的地址和安全协议相结合,用来标识一个安全关联,以此确定发送方所选择的算法、密钥及密钥的长度等。SPI根据目的地址来分配,与一特定的发送方相关联,具有相同目的地址的不同发送方报文,其SPI值也不同。因此,可用SPI来代替TCP/UDP(传输控制协议/用户数据报文协议)端口。
由于IPsec网关为每一条IPsec隧道都创建了一个安全联盟(SA),其中记录了隧道的封装参数以及所传输数据流的特征,所以按照RFC2401要求建立起来的SA数据库,是可以通过三元组<目的IP,安全协议类型,SPI>来反向查出原报文所对应的数据流,从而有可能查出原报文的源IP地址或源IP地址范围。
(2)如果IPsec网关不能从ICMP差错控制报文所携带的内容数据中获取原报文的源IP地址,则可以先将ICMP报文所携带的中途路由器的出口MTU保存在与该报文对应的SA中,待监测到该SA上后续传送的要求不分片的报文时,比较报文长度与已存的MTU,如果报文超长,则直接向源主机发送ICMP目的不可达报文(对不能分片的报文需要分片)。这时可以利用后续报文的源IP知道报文的来源。
这种方案虽然可行,但实现起来很复杂;而且,ICMP目的不可达报文的成功返回依赖于Ipsec网关特殊的实现机制,该方案对于其他类型的隧道网关无法实现,通用性差。
发明内容
本发明的目的是提供一种获取隧道网关环境中路径最大传输长度的方法及系统,以克服上述现有技术方案实现复杂、通用性差的缺点,使隧道网关对不可分片的IP报文简单、有效地返回ICMP消息。
本发明的目的是通过以下技术方案实现的:
一种获取隧道网关环境中路径最大传输长度的方法,包括以下步骤:
a、由所述隧道网关建立隧道链路最大传输长度;
b、构造不可分片的路径最大传输长度探测报文;
c、向目的节点发送所述探测报文;
d、当所述探测报文经过所述隧道网关时,所述隧道网关根据所述建立的隧道链路最大传输长度及所述探测报文的长度,向发送方返回互联网控制管理协议报文;
e、当所述发送方收到目的不可达类型的互联网控制管理协议报文时,按预定方式调整所述探测报文的长度,重复上述步骤c至d,直到发送方接收到所述目的节点返回的回应报类型的互联网控制管理协议报文;
f、当所述发送方接收到所述目的节点返回的回应类型的互联网控制管理协议报文时,将所述探测报文的当前长度作为路径最大传输长度。
所述步骤a包括:
a1、在所述隧道网关上建立至少一条隧道;
a2、将所述隧道作为直连数据链路,获取该直连数据链路的最大传输长度;
a3、将所述获取的直连数据链路的最大传输长度作为所述隧道对应的隧道链路最大传输长度;
a4、将所述隧道链路最大传输长度配置在所述隧道网关出口上。
所述步骤a2包括:
采用标准协议获取所述直连数据链路的最大传输长度;或者
采用私有协议获取所述直连数据链路的最大传输长度。
所述步骤a4还包括:
当所述隧道网关上建有多条隧道时,为每条隧道建立一个逻辑接口;
将每条隧道对应的隧道链路最大传输长度配置在所述隧道的逻辑接口上。
所述步骤d具体为:
d11、将所述探测报文发送到对应隧道的逻辑接口上;
d12、由所述逻辑接口根据配置的隧道链路最大传输长度进行分片处理;
d13、当所述探测报文长度大于所述隧道链路最大传输长度时,由所述隧道网关向所述发送方返回目的不可达类型的互联网控制管理协议差错控制报文;
d14、当所述探测报文长度小于所述隧道链路最大传输长度时,向所述隧道网关下一节点传送所述探测报文。
所述步骤a4还包括:
当所述隧道网关上建有多条隧道时,在所述隧道网关出口上建立隧道链路最大传输长度索引表;
将所述获取的每条隧道对应的隧道链路最大传输长度写入所述索引表。
所述步骤d具体为:
d21、根据所述探测报文获取传送所述探测报文所需隧道;
d22、检索所述索引表获取所需隧道对应的隧道链路最大传输长度;
d23、当所述探测报文长度大于所述隧道链路最大传输长度时,向所述发送方返回目的不可达类型的互联网控制管理协议差错控制报文;
d24、当所述探测报文长度小于所述隧道链路最大传输长度时,向下一节点传送所述探测报文。
所述方法还包括:
g、所述隧道网关按预定方式重新探测所述隧道链路最大传输长度;
h、当探测到的隧道链路最大传输长度与已配置的隧道链路最大传输长度不同时,更新所述配置。
所述预定方式包括:
定时探测所述隧道链路最大传输长度;或者
当所述隧道网关收到隧道途中节点返回的目的不可达类型的互联网控制管理协议差错控制报文时,重新探测所述隧道链路最大传输长度。
所述方法还包括:
设定所述隧道链路最大传输长度阈值;
当所述建立的隧道链路最大传输长度小于所述阈值时,在所述隧道网关上根据网关出口链路最大传输长度对可分作片报文进行分片操作。
一种获取隧道网关环境中路径最大传输长度的系统,包括:多个节点,多个隧道网关,隧道网关之间互连的隧道链路,节点之间互连及节点与隧道网关相连的节点链路;
所述节点包括:源节点、中途节点、目的节点;
所述隧道网关包括:发送方隧道网关、接收方隧道网关;
所述发送方隧道网关包括:
链路接口,用于与相邻节点进行通信;
隧道链路MTU获取装置,用于获取所述隧道链路MTU;
隧道链路MTU配置装置,用于配置所述发现的隧道链路MTU。
所述源节点包括:
路径MTU探测报文设置装置,用于设定探测路径MTU所需的报文;
探测报文长度调整装置,用于调整所述路径MTU探测报文的长度;
路径MTU发现装置,用于根据路径MTU探测报文发现路径MTU。
所述链路接口包括:
节点链路接口,耦合于所述逻辑接口,用于与通过所述节点链路连接的相邻节点进行通信;
隧道链路接口,耦合于所述逻辑接口,用于与通过所述隧道链路连接的相邻节点进行通信。
所述隧道链路MTU配置装置包括:
至少一个逻辑接口,分别耦合于所述节点链路接口和所述隧道链路接口,对应于所述隧道链路,用于配置对应隧道链路的最大传输长度。
由以上本发明提供的技术方案可以看出,本发明通过将隧道看作一条直连的数据链路,引入隧道MTU的概念,使报文在进入隧道时,按照隧道MTU进行分片,这样,使得长度大于隧道MTU的不可分片的探测报文到达隧道网关时即被丢弃,直接由隧道网关向源节点主机返回目的不可达类型的ICMP差错控制报文,避免了现有技术中探测报文在隧道中传输时,由于报文超长而被丢弃时不能将ICMP控制报文返回源节点主机,或者实现复杂的情况,简化了在复杂网络环境中对PMTU的测算;同时,对于可分片的IP报文,可以根据需要选择采用隧道MTU或者链路MTU对报文进行分片处理,有利于提高网络传输效率。
附图说明
图1是隧道网关原理示意图;
图2是现有技术中在隧道网关环境中探测MTU时返回ICMP差错控制报文的示意图;
图3是经IPsec网关封装的隧道报文结构;
图4是本发明中引入的隧道链路MTU示意图;
图5是本发明方法的流程图;
图6是IP报文格式;
图7是ICMP报文格式;
图8是本发明方法中探测报文格式;
图9是本发明方法中建立隧道链路MTU的第一实施例的流程图;
图10是本发明方法中建立隧道链路MTU的第二实施例的流程图;
图11是本发明方法中建立的隧道逻辑接口示意图;
图12是本发明系统的第一实施例组网图;
图13是本发明系统的第二实施例组网图;
图14是本发明系统的第三实施例组网图。
具体实施方式
本发明的核心在于引入隧道MTU(最大传输路径)的概念,即在隧道所经过的网络传输路径上最小的链路MTU,也就是将隧道作为一个具有通常各种媒介链路属性的直连数据链路,参见图4。在建立隧道时,由隧道网关根据RFC1191推荐的方法或采用其他私有协议来获取每条隧道对应的隧道链路MTU,并将其配置在隧道网关的出口上。
当不可分片的路径MTU探测报文进入隧道时,如果报文长度大于对应隧道链路MTU,则由隧道网关直接将该探测报文丢弃,并直接向源节点主机发送目的不可达ICMP(互联网控制管理协议)报文。源节点主机根据收到的目的不可达ICMP报文调节路径MTU探测报文的长度,直到收到目的节点返回的回应类型的ICMP报文时,将所述探测报文的当前长度作为路径最大传输长度。
当可分片的IP(网际协议)报文进入隧道时,按照实际需要选择采用隧道MTU还是采用出口链路MTU对报文进行分片。按照对应的隧道MTU的长度对报文进行分片时,会使隧道另一端收到最少的报文分片;但当隧道MTU的值小于某一预定值时,为了不影响某些链路的传输效率,可以直接使用链路MTU对报文进行分片。
由于互联网中的路由有可能发生变化,所以隧道路径也可能随之发生变化,因此,还需要由隧道网关对获取的每条隧道对应的隧道链路MTU进行维护,当探测到隧道链路MTU发生变化时及时更新当前保存的隧道链路MTU。
为了使本技术领域的人员更好地理解本发明方案,下面结合附图和实施方式对本发明作进一步的详细说明。
参照图5,图5示出了本发明方法的详细流程,包括以下步骤:
步骤501:由隧道网关建立隧道链路最大传输长度,可以采用RFC1191中推荐的方法,也可以采用其他私有协议方法来实现。
步骤502:构造不可分片的路径最大传输长度探测报文。
探测报文的长度要足够大,至少要大于出口的MTU,采用图6所示的标准的IP报文格式。在IP头中,标志域包括3个比特,其中,第一个比特R保留未用;第二个比特DF(Don’t fragment)表示目标主机不能分片;第三个比特MF(Morefragment):“1”表示本分片后还有分片,“0”表示本分片后没有分片了,除了最后一片外,其他每个组成数据报的片都要把该比特置“1”。将标志域中的DF位置位,标识该报文不可分片。
数据报文作为物理帧的数据封装在特定的物理帧内,通过帧的传输来实现数据报文的传输。数据帧头部的目的地址是数据报送往目的地的下一跳的物理地址。
数据报在源节点进行封装,将物理帧传给下一跳,接收者从物理帧中的数据区提取数据报文,丢掉帧的头部,然后采用下一个物理网络的帧格式进行封装,又传给下一跳,直至目的地。
利用图7所示的标准ICMP协议控制处理差错和控制信息,将ICMP封装在IP数据包中。ICMP报文通过类型域来表示报文的类型,比如:
类型8:ICMP echo(ICMP回应请求);
类型0:ICMP reply(ICMP回应应答);
类型3:目的不可达ICMP报文。
将ICMP echo报文封装在探测报文中。封装ICMP echo报文后,探测报文的格式如图7所示。
步骤503:向目的节点发送探测报文。
步骤504:当探测报文经过隧道网关时,隧道网关判断探测报文的长度是否大于隧道链路MTU。
如果探测报文的长度大于隧道链路MTU,因为探测报文是不可分片的,因此,进到步骤505:向发送方返回目的不可达类型的ICMP报文。
然后,进到步骤506:发送方收到目的不可达类型的ICMP报文后,按预定方式调整探测报文的长度。
比如,可以按照以下两种方式调整探测报文的长度:
(1)枚举法:预先列出所有可能的路径MTU,由高到低依次选择这些可能的路径MTU作为探测报文的长度进行探测;
(2)反馈法:根据返回的目的不可达类型ICMP差错控制报文中记录的路由器出口的MTU值,将该值作为探测报文的长度。
然后,返回步骤503:继续向目的节点发送探测报文。
如果探测报文的长度小于隧道链路MTU,则进到步骤507:向目的节点传送探测报文。
然后,进到步骤508:目的节点收到探测报文后,向发送方返回回应类型的ICMP报文。
步骤509:发送方收到回应类型的ICMP报文后,则将探测报文的当前长度作为探测到的PMTU。
图9示出了上述建立隧道链路MTU的第一实施例的流程:
首先,在步骤901:在隧道网关上建立多条隧道。
然后,进到步骤902:分别将建立的隧道作为直连数据链路,获取每条直连数据链路的最大传输长度。可以采用RFC1191中推荐的方法,也可以采用其他私有协议方法获取所述直连数据链路的最大传输长度。
步骤903:将获取的直连数据链路的最大传输长度作为该隧道对应的隧道链路MTU;
步骤904:在隧道网关出口上建立隧道链路MTU索引表。该索引表包括:隧道入口地址,隧道出口地址,隧道链路MTU。
步骤905:将每条隧道对应的隧道链路MTU写入索引表。
按上述方式将每条隧道对应的隧道链路MTU配置到隧道网关上的索引表后,隧道网关对收到的探测报文的处理过程如下:
首先,根据探测报文获取传送该探测报文所需的隧道,可以根据该探测报文的目的地址及隧道网关中配置的路由表获知所需的隧道;
然后,检索索引表获取所需隧道对应的隧道链路MTU;
当探测报文长度大于隧道链路MTU时,向发送方返回目的不可达类型的ICMP报文;
当探测报文长度小于隧道链路MTU时,向目的节点传送探测报文。
由于一个隧道网关上可能同时建立多个目的端不同的隧道,但是在本端隧道网关的出口却是相同的,为了便于报文的转发处理,可以采用图10所示的上述建立隧道链路MTU的第二实施例的流程:
首先,在步骤101:在隧道网关上建立多条隧道。
然后,进到步骤102:分别获取每条隧道对应的隧道链路MTU。同样,可以采用RFC1191中推荐的方法,也可以采用其他私有协议方法获取隧道链路MTU。
步骤103:为每条隧道建立一个逻辑接口。
步骤104:将每条隧道对应的隧道链路MTU配置在该隧道的逻辑接口上。
用图表示为图11所示,在该隧道网关上建立3条隧道:隧道1、隧道2、隧道3,对应这3条隧道有3个逻辑接口:逻辑接口1、逻辑接口2、逻辑接口3,配置的隧道链路MTU分别为MTU1、MTU2、MTU3。
按上述方式将每条隧道对应的隧道链路MTU配置到建立的逻辑接口上后,隧道网关对收到的探测报文的处理过程如下:
首先,隧道网关的入口接收探测报文;
然后,将收到的探测报文发送到对应隧道的逻辑接口2上;
然后,获取该逻辑接口上配置的隧道链路MTU;
再由该逻辑接口将探测报文及获取的隧道链路MTU转发给隧道网关出口;
当探测报文长度大于隧道链路MTU时,向发送方返回目的不可达类型的ICMP报文;
当探测报文长度小于隧道链路MTU时,向目的节点传送探测报文。
由于互联网中的路由有可能发生变化,所以隧道链路也可能随之发生变化,不同隧道链路MTU有可能是不同的。所以隧道网关还需要对配置的隧道链路MTU进行维护,如有变化,及时更新。在本发明方法中,隧道网关按预定方式重新探测隧道链路MTU,比如,定时探测隧道链路MTU,或者当隧道网关收到隧道途中节点返回的目的不可达类型的ICMP报文(对不能分片的报文需要分片时返回的差错控制报文)时,重新探测隧道链路MTU;当探测到的隧道链路MTU与已配置的隧道链路MTU不同时,更新原来的配置。
由上面的描述可见,隧道链路MTU的使用给处理不可分片的隧道报文带来了方便,当不可分片的隧道报文到达逻辑链路接口时,如果报文的长度大于隧道链路MTU,则隧道网关就可以直接将其丢弃,并向源主机发送正确的目的不可达ICMP报文,不必等到进入隧道后,不可分片的报文长度大于中途路由器之间的链路MTU时,再向源主机发送目的不可达ICMP报文时增加的处理难度,甚至不能向源主机返回有效的控制报文的问题。
既然建立了隧道链路MTU,如果报文在隧道的入口处就按照隧道链路MTU进行分片,显然会使隧道另一端收到最少的报文分片,这样,有利于提高传输效率。因此,对可以分片的IP报文,实现者可以自行决定是采用隧道链路MTU还是出口链路的MTU对报文进行分片处理。但当隧道链路MTU太小时,有可能会降低某些链路的传输效率。
为此,本发明还可采取以下措施:
设定隧道链路最大传输长度阈值;
当建立的隧道链路最大传输长度小于所述阈值时,在隧道网关上根据网关出口链路MTU对可分作片报文进行分片操作;
当建立的隧道链路最大传输长度大于所述阈值时,在隧道网关上根据隧道链路MTU对可分作片报文进行分片操作。
图12是本发明系统的第一实施例组网图:
包括:源节点121、发送方隧道网关122、接收方隧道网关123、目的节点124,以及源节点121与发送方隧道网关122之间的节点链路、接收方隧道网关123与目的节点124之间的节点链路、发送方隧道网关122与接收方隧道网关123之间的隧道链路。
在发送方网关122中包括:用于获取隧道链路MTU的隧道链路MTU获取装置125,以及用于配置获取的隧道链路MTU的隧道链路MTU配置装置126。
当发送方隧道网关和接收方隧道网关建立隧道链路时,由隧道链路MTU获取装置125获取该隧道链路的MTU值,然后由隧道链路MTU配置装置126将该值配置到发送方隧道网关的出口上。
当源节点通过节点链路发送不可分片的路径MTU探测报文(IP报文)到发送方隧道网关后,由该隧道网关检测报文长度,如果报文长度大于已配置的隧道链路MTU,则由该隧道网关直接向源节点返回目的不可达类型的ICMP报文,通知源节点该报文的长度过长;如果报文长度小于已配置的隧道链路MTU,则由发送方遂道网关将该报文封装为隧道报文:将原探测报文作为数据内容,加上新的IP头,新IP头中的源地址为发送方的隧道网关,目的地址是接收方的隧道网关,通过隧道链路将该报文转发给接收方隧道网关。接收方隧道网关收到隧道报文后,去掉新的IP头,恢复原IP报文,然后经节点链路转发给目的节点。目的节点收到该报文后,按原路径向源节点发送回应响应类型的ICMP报文。
图13是本发明系统的第二实施例组网图:
其中,源节点121包括:
路径MTU探测报文设置装置127,用于设定探测路径MTU所需的报文;
探测报文长度调整装置128,用于调整所述路径MTU探测报文的长度;
路径MTU发现装置129,用于根据路径MTU探测报文发现路径MTU。
当源节点需要探测路径MTU时,首先由路径MTU探测报文设置装置127构造探测报文,设置报文头域中的DF位为1,标识该报文不可分片,设置报文的长度大于源节点主机出口的MTU值,并将ICMP差错控制报文封装到该报文中,以便接收方返回控制信息;然后,源节点向目的节点发送构造的探测报文,当经过隧道时,在隧道入口由发送方隧道网关判断该报文的长度是否超过隧道链路MTU,如果超过了隧道链路MTU,则直接丢弃该报文,并向源节点发送目的不可达类型的ICMP控制报文,源节点收到ICMP报文后,由路径MTU发现装置129根据返回的ICMP报文信息,控制探测报文长度调整装置128调整探测报文的长度;然后,按上述方式重新发送探测报文,直到收到目的节点发送的ICMP reply报文后,则将当前的探测报文的长度作为路径MTU。
图14是本发明系统的第三实施例组网图:
其中,在发送方遂道网关上同时建有两条隧道:隧道1和隧道2,对应于隧道1建有逻辑接口223,对应于隧道2建有逻辑接口224,隧道1的链路MTU配置在逻辑接口223上,隧道2的链路MTU配置在逻辑接口224上。
逻辑接口223和逻辑接口224分别耦合于节点链路接口221和隧道链路接口222。节点链路接口221用于与通过节点链路连接的相邻节点进行通信;隧道链路接口222用于与通过隧道链路连接的相邻节点进行通信。
当源节点通过节点链路发送不可分片的路径MTU探测报文(IP报文)到发送方隧道网关后,首先由该隧道网关的节点链路接口221将报文转发到对应的逻辑接口223上,由该逻辑接口将报文及配置的隧道链路MTU转发到隧道链路接口222上,由隧道链路接口222根据报文长度及链道MTU的值对该报文进行处理。
如果探测报文通过隧道时不需要分片,而通过隧道出口时,在隧道出口到下一个节点之间的链路MTU小于该探测报文,这时需要对报文进行分片,如果该报文为不可分片的报文,则需要向源节点返回目的不可达ICMP报文,因为在隧道出口该报文已经去掉了进入隧道时增加的新IP头,恢复为原来的IP报文,该IP报文头中的源地址是源节点(发送方)的地址,因此,能将目的不可达ICMP报文正确发送到源节点。
虽然通过实施例描绘了本发明,本领域普通技术人员知道,本发明有许多变形和变化而不脱离本发明的精神,希望所附的权利要求包括这些变形和变化而不脱离本发明的精神。
Claims (14)
1、一种获取隧道网关环境中路径最大传输长度的方法,其特征在于,包括以下步骤:
a、由所述隧道网关建立隧道链路最大传输长度;
b、构造不可分片的路径最大传输长度探测报文;
c、向目的节点发送所述探测报文;
d、当所述探测报文经过所述隧道网关时,所述隧道网关根据所述建立的隧道链路最大传输长度及所述探测报文的长度,向发送方返回互联网控制管理协议报文;
e、当所述发送方收到目的不可达类型的互联网控制管理协议报文时,按预定方式调整所述探测报文的长度,重复上述步骤c至d,直到发送方接收到所述目的节点返回的回应报类型的互联网控制管理协议报文;
f、当所述发送方接收到所述目的节点返回的回应类型的互联网控制管理协议报文时,将所述探测报文的当前长度作为路径最大传输长度。
2、根据权利要求1所述的获取隧道网关环境中路径最大传输长度的方法,其特征在于,所述步骤a包括:
a1、在所述隧道网关上建立至少一条隧道;
a2、将所述隧道作为直连数据链路,获取该直连数据链路的最大传输长度;
a3、将所述获取的直连数据链路的最大传输长度作为所述隧道对应的隧道链路最大传输长度;
a4、将所述隧道链路最大传输长度配置在所述隧道网关出口上。
3、根据权利要求2所述的获取隧道网关环境中路径最大传输长度的方法,其特征在于,所述步骤a2包括:
采用标准协议获取所述直连数据链路的最大传输长度;或者
采用私有协议获取所述直连数据链路的最大传输长度。
4、根据权利要求2所述的获取隧道网关环境中路径最大传输长度的方法,其特征在于,所述步骤a4还包括:
当所述隧道网关上建有多条隧道时,为每条隧道建立一个逻辑接口;
将每条隧道对应的隧道链路最大传输长度配置在所述隧道的逻辑接口上。
5、根据权利要求4所述的获取隧道网关环境中路径最大传输长度的方法,其特征在于,所述步骤d具体为:
d11、将所述探测报文发送到对应隧道的逻辑接口上;
d12、由所述逻辑接口根据配置的隧道链路最大传输长度进行分片处理;
d13、当所述探测报文长度大于所述隧道链路最大传输长度时,由所述隧道网关向所述发送方返回目的不可达类型的互联网控制管理协议差错控制报文;
d14、当所述探测报文长度小于所述隧道链路最大传输长度时,向所述隧道网关下一节点传送所述探测报文。
6、根据权利要求2所述的获取隧道网关环境中路径最大传输长度的方法,其特征在于,所述步骤a4还包括:
当所述隧道网关上建有多条隧道时,在所述隧道网关出口上建立隧道链路最大传输长度索引表;
将所述获取的每条隧道对应的隧道链路最大传输长度写入所述索引表。
7、根据权利要求6所述的获取隧道网关环境中路径最大传输长度的方法,其特征在于,所述步骤d具体为:
d21、根据所述探测报文获取传送所述探测报文所需隧道;
d22、检索所述索引表获取所需隧道对应的隧道链路最大传输长度;
d23、当所述探测报文长度大于所述隧道链路最大传输长度时,向所述发送方返回目的不可达类型的互联网控制管理协议差错控制报文;
d24、当所述探测报文长度小于所述隧道链路最大传输长度时,向下一节点传送所述探测报文。
8、根据权利要求1所述的获取隧道网关环境中路径最大传输长度的方法,其特征在于,所述方法还包括:
g、所述隧道网关按预定方式重新探测所述隧道链路最大传输长度;
h、当探测到的隧道链路最大传输长度与已配置的隧道链路最大传输长度不同时,更新所述配置。
9、根据权利要求8所述的获取隧道网关环境中路径最大传输长度的方法,其特征在于,所述预定方式包括:
定时探测所述隧道链路最大传输长度;或者
当所述隧道网关收到隧道途中节点返回的目的不可达类型的互联网控制管理协议差错控制报文时,重新探测所述隧道链路最大传输长度。
10、根据权利要求1所述的获取隧道网关环境中路径最大传输长度的方法,其特征在于,所述方法还包括:
设定所述隧道链路最大传输长度阈值;
当所述建立的隧道链路最大传输长度小于所述阈值时,在所述隧道网关上根据网关出口链路最大传输长度对可分作片报文进行分片操作。
11、一种获取隧道网关环境中路径最大传输长度的系统,包括:多个节点,多个隧道网关,隧道网关之间互连的隧道链路,节点之间互连及节点与隧道网关相连的节点链路;
所述节点包括:源节点、中途节点、目的节点;
所述隧道网关包括:发送方隧道网关、接收方隧道网关;
其特征在于,所述发送方隧道网关包括:
链路接口,用于与相邻节点进行通信;
隧道链路MTU获取装置,用于获取所述隧道链路MTU;
隧道链路MTU配置装置,用于配置所述发现的隧道链路MTU。
12、根据权利要求11所述的获取隧道网关环境中路径最大传输长度的系统,其特征在于,所述源节点包括:
路径MTU探测报文设置装置,用于设定探测路径MTU所需的报文;
探测报文长度调整装置,用于调整所述路径MTU探测报文的长度;
路径MTU发现装置,用于根据路径MTU探测报文发现路径MTU。
13、根据权利要求11所述的获取隧道网关环境中路径最大传输长度的系统,其特征在于,所述链路接口包括:
节点链路接口,耦合于所述逻辑接口,用于与通过所述节点链路连接的相邻节点进行通信;
隧道链路接口,耦合于所述逻辑接口,用于与通过所述隧道链路连接的相邻节点进行通信。
14、根据权利要求13所述的获取隧道网关环境中路径最大传输长度的系统,其特征在于,所述隧道链路MTU配置装置包括:
至少一个逻辑接口,分别耦合于所述节点链路接口和所述隧道链路接口,对应于所述隧道链路,用于配置对应隧道链路的最大传输长度。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2004100594862A CN100486241C (zh) | 2004-06-28 | 2004-06-28 | 获取隧道网关环境中路径最大传输长度的方法及系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2004100594862A CN100486241C (zh) | 2004-06-28 | 2004-06-28 | 获取隧道网关环境中路径最大传输长度的方法及系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN1716943A true CN1716943A (zh) | 2006-01-04 |
CN100486241C CN100486241C (zh) | 2009-05-06 |
Family
ID=35822363
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNB2004100594862A Active CN100486241C (zh) | 2004-06-28 | 2004-06-28 | 获取隧道网关环境中路径最大传输长度的方法及系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN100486241C (zh) |
Cited By (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2009026824A1 (fr) * | 2007-08-22 | 2009-03-05 | Huawei Technologies Co., Ltd. | Procédé, dispositif et système pour transférer des messages multiplex |
WO2009082896A1 (fr) * | 2007-12-28 | 2009-07-09 | Huawei Technologies Co., Ltd. | Procédé et convertisseur pour la transmission de messages de données |
CN101827031A (zh) * | 2010-04-22 | 2010-09-08 | 中兴通讯股份有限公司 | 一种用户数据包协议udp隧道中传输报文的方法及装置 |
CN102088410A (zh) * | 2011-01-25 | 2011-06-08 | 中国人民解放军国防科学技术大学 | 一种报文分片方法及系统 |
CN101640645B (zh) * | 2009-09-09 | 2012-01-11 | 中兴通讯股份有限公司 | 报文传输方法和系统 |
CN102457404A (zh) * | 2010-10-15 | 2012-05-16 | 中兴通讯股份有限公司 | 检测通信路径mtu的方法、装置和系统 |
CN101695048B (zh) * | 2009-10-29 | 2012-05-30 | 福建星网锐捷网络有限公司 | 隧道最大传输单元的发现处理方法与装置、路由器 |
CN102868613A (zh) * | 2012-08-14 | 2013-01-09 | 中兴通讯股份有限公司 | 一种通用路由封装隧道报文发送方法和装置 |
CN104601409A (zh) * | 2015-01-30 | 2015-05-06 | 杭州华三通信技术有限公司 | 一种mtu探测方法及装置 |
CN104618275A (zh) * | 2015-01-21 | 2015-05-13 | 大唐移动通信设备有限公司 | 一种分片处理的方法和设备 |
CN102821051B (zh) * | 2012-08-21 | 2015-11-18 | 神州数码网络(北京)有限公司 | 通用路由封装隧道中路径最大传输单元更改方法 |
WO2016192402A1 (zh) * | 2015-06-03 | 2016-12-08 | 中兴通讯股份有限公司 | 一种调整IPv6隧道最大传输单元的方法和装置 |
WO2017190467A1 (zh) * | 2016-05-03 | 2017-11-09 | 中兴通讯股份有限公司 | 终端最大传输单元的调整方法、装置和终端设备 |
CN108600861A (zh) * | 2018-03-26 | 2018-09-28 | 南京地铁建设有限责任公司 | 基于城市轨道乘客信息系统的音视频数据包包长调整方法 |
CN109525534A (zh) * | 2017-09-18 | 2019-03-26 | 北京握奇智能科技有限公司 | 一种在安全网络中保证报文不被分片的方法和系统 |
CN109873763A (zh) * | 2017-12-05 | 2019-06-11 | 北京华为数字技术有限公司 | 一种通信方法及设备 |
CN110177052A (zh) * | 2019-04-30 | 2019-08-27 | 佛山易识科技有限公司 | 一种隧道报文的分片处理方法及装置 |
CN111884877A (zh) * | 2020-07-23 | 2020-11-03 | 厦门爱陆通通信科技有限公司 | 一种增强ipsec链路稳定性的有效网关检测机制的方法 |
CN111988309A (zh) * | 2020-08-18 | 2020-11-24 | 深圳市联软科技股份有限公司 | 一种icmp隐蔽隧道检测方法及系统 |
CN112787905A (zh) * | 2020-12-25 | 2021-05-11 | 北京中科网威信息技术有限公司 | Mtu确定方法及系统、电子设备及存储介质 |
CN113411260A (zh) * | 2015-08-31 | 2021-09-17 | 华为技术有限公司 | 一种IPv6网络中数据报文的发送方法及装置 |
CN114244782A (zh) * | 2021-08-27 | 2022-03-25 | 新华三信息安全技术有限公司 | 路径最大传输单元Path MTU值调整方法及装置 |
CN116015943A (zh) * | 2022-12-30 | 2023-04-25 | 电子科技大学 | 一种基于多级隧道混淆的隐私保护方法 |
-
2004
- 2004-06-28 CN CNB2004100594862A patent/CN100486241C/zh active Active
Cited By (32)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101374101B (zh) * | 2007-08-22 | 2011-05-04 | 华为技术有限公司 | 一种传输复用报文的方法、设备及系统 |
WO2009026824A1 (fr) * | 2007-08-22 | 2009-03-05 | Huawei Technologies Co., Ltd. | Procédé, dispositif et système pour transférer des messages multiplex |
WO2009082896A1 (fr) * | 2007-12-28 | 2009-07-09 | Huawei Technologies Co., Ltd. | Procédé et convertisseur pour la transmission de messages de données |
CN101640645B (zh) * | 2009-09-09 | 2012-01-11 | 中兴通讯股份有限公司 | 报文传输方法和系统 |
CN101695048B (zh) * | 2009-10-29 | 2012-05-30 | 福建星网锐捷网络有限公司 | 隧道最大传输单元的发现处理方法与装置、路由器 |
CN101827031A (zh) * | 2010-04-22 | 2010-09-08 | 中兴通讯股份有限公司 | 一种用户数据包协议udp隧道中传输报文的方法及装置 |
CN102457404B (zh) * | 2010-10-15 | 2016-03-30 | 中兴通讯股份有限公司 | 检测通信路径mtu的方法、装置和系统 |
CN102457404A (zh) * | 2010-10-15 | 2012-05-16 | 中兴通讯股份有限公司 | 检测通信路径mtu的方法、装置和系统 |
CN102088410A (zh) * | 2011-01-25 | 2011-06-08 | 中国人民解放军国防科学技术大学 | 一种报文分片方法及系统 |
CN102868613A (zh) * | 2012-08-14 | 2013-01-09 | 中兴通讯股份有限公司 | 一种通用路由封装隧道报文发送方法和装置 |
WO2014026571A1 (zh) * | 2012-08-14 | 2014-02-20 | 中兴通讯股份有限公司 | 一种通用路由封装隧道报文发送方法和装置 |
CN102821051B (zh) * | 2012-08-21 | 2015-11-18 | 神州数码网络(北京)有限公司 | 通用路由封装隧道中路径最大传输单元更改方法 |
CN104618275A (zh) * | 2015-01-21 | 2015-05-13 | 大唐移动通信设备有限公司 | 一种分片处理的方法和设备 |
CN104601409A (zh) * | 2015-01-30 | 2015-05-06 | 杭州华三通信技术有限公司 | 一种mtu探测方法及装置 |
CN104601409B (zh) * | 2015-01-30 | 2018-01-09 | 新华三技术有限公司 | 一种mtu探测方法及装置 |
WO2016192402A1 (zh) * | 2015-06-03 | 2016-12-08 | 中兴通讯股份有限公司 | 一种调整IPv6隧道最大传输单元的方法和装置 |
US11477106B2 (en) | 2015-08-31 | 2022-10-18 | Huawei Technologies Co., Ltd. | Data packet sending method and apparatus in IPV6 network |
CN113411260A (zh) * | 2015-08-31 | 2021-09-17 | 华为技术有限公司 | 一种IPv6网络中数据报文的发送方法及装置 |
CN107342885A (zh) * | 2016-05-03 | 2017-11-10 | 中兴通讯股份有限公司 | 终端最大传输单元的调整方法、装置和终端设备 |
WO2017190467A1 (zh) * | 2016-05-03 | 2017-11-09 | 中兴通讯股份有限公司 | 终端最大传输单元的调整方法、装置和终端设备 |
CN109525534A (zh) * | 2017-09-18 | 2019-03-26 | 北京握奇智能科技有限公司 | 一种在安全网络中保证报文不被分片的方法和系统 |
CN109873763A (zh) * | 2017-12-05 | 2019-06-11 | 北京华为数字技术有限公司 | 一种通信方法及设备 |
CN109873763B (zh) * | 2017-12-05 | 2021-12-03 | 北京华为数字技术有限公司 | 一种通信方法及设备 |
CN108600861A (zh) * | 2018-03-26 | 2018-09-28 | 南京地铁建设有限责任公司 | 基于城市轨道乘客信息系统的音视频数据包包长调整方法 |
CN110177052A (zh) * | 2019-04-30 | 2019-08-27 | 佛山易识科技有限公司 | 一种隧道报文的分片处理方法及装置 |
CN111884877A (zh) * | 2020-07-23 | 2020-11-03 | 厦门爱陆通通信科技有限公司 | 一种增强ipsec链路稳定性的有效网关检测机制的方法 |
CN111988309B (zh) * | 2020-08-18 | 2022-07-05 | 深圳市联软科技股份有限公司 | 一种icmp隐蔽隧道检测方法及系统 |
CN111988309A (zh) * | 2020-08-18 | 2020-11-24 | 深圳市联软科技股份有限公司 | 一种icmp隐蔽隧道检测方法及系统 |
CN112787905A (zh) * | 2020-12-25 | 2021-05-11 | 北京中科网威信息技术有限公司 | Mtu确定方法及系统、电子设备及存储介质 |
CN114244782A (zh) * | 2021-08-27 | 2022-03-25 | 新华三信息安全技术有限公司 | 路径最大传输单元Path MTU值调整方法及装置 |
CN116015943A (zh) * | 2022-12-30 | 2023-04-25 | 电子科技大学 | 一种基于多级隧道混淆的隐私保护方法 |
CN116015943B (zh) * | 2022-12-30 | 2024-03-12 | 电子科技大学 | 一种基于多级隧道混淆的隐私保护方法 |
Also Published As
Publication number | Publication date |
---|---|
CN100486241C (zh) | 2009-05-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN1716943A (zh) | 获取隧道网关环境中路径最大传输长度的方法及系统 | |
CN1279731C (zh) | 一种通信流模板分组过滤的装置和方法 | |
CN1210971C (zh) | 无线通信系统中的分组数据业务 | |
CN1893707A (zh) | 通信终端及通信方法 | |
CN1254998C (zh) | 无线通信方法及用于其中的移动体终端 | |
CN1188991C (zh) | 用于可靠的和低时延的分组传输的通信设备和方法 | |
CN1140090C (zh) | 分组网络中的接口及其操作方法 | |
CN1225099C (zh) | 一种利用与网络连接的装置进行源已知桥接的方法 | |
CN1362814A (zh) | 通用组帧程序帧的传送设备与方法 | |
CN1839594A (zh) | 准确控制特设网络中的传输信息 | |
CN1750512A (zh) | 单播反向路径转发方法 | |
CN1656750A (zh) | 协议、信息处理系统和方法、信息处理设备和方法、记录介质和程序 | |
CN1636374A (zh) | 带有标题压缩的无线通信设备 | |
CN101061672A (zh) | 通信系统、无线局域网基站控制装置和无线局域网基站装置 | |
CN101030977A (zh) | 用于防御非法通信的装置及其网络系统 | |
CN1914862A (zh) | 集群系统、集群成员、故障恢复方法及程序 | |
CN1503526A (zh) | 地址转换装置和地址转换规则的管理方法 | |
CN101047711A (zh) | Ip报文传输、协商带宽节省能力和节省网络带宽的方法 | |
CN1761233A (zh) | IPv6接入网中的网络服务选择和认证,及无状态自动配置 | |
CN1375966A (zh) | 用实时包传输状态和传输路径阻塞状态的通信质量控制 | |
CN1855935A (zh) | 信息处理装置和方法、程序、以及记录介质 | |
CN1918558A (zh) | 一种多个站在共享介质上进行通信的网络中的操作方法 | |
CN1941753A (zh) | 下一代网络中的ip互通网关及其实现ip域互通的方法 | |
CN1754364A (zh) | 发射/接收系统、发射设备和方法及接收设备和方法 | |
CN101047633A (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 | ||
CP03 | Change of name, title or address | ||
CP03 | Change of name, title or address |
Address after: 310052 Binjiang District Changhe Road, Zhejiang, China, No. 466, No. Patentee after: Xinhua three Technology Co., Ltd. Address before: 310053 Hangzhou hi tech Industrial Development Zone, Zhejiang province science and Technology Industrial Park, No. 310 and No. six road, HUAWEI, Hangzhou production base Patentee before: Huasan Communication Technology Co., Ltd. |