CN105634977B - 发现路径最大传输单元的方法和装置 - Google Patents

发现路径最大传输单元的方法和装置 Download PDF

Info

Publication number
CN105634977B
CN105634977B CN201410597850.4A CN201410597850A CN105634977B CN 105634977 B CN105634977 B CN 105634977B CN 201410597850 A CN201410597850 A CN 201410597850A CN 105634977 B CN105634977 B CN 105634977B
Authority
CN
China
Prior art keywords
message
pmtu
length
value
fragment
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.)
Active
Application number
CN201410597850.4A
Other languages
English (en)
Other versions
CN105634977A (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.)
New H3C Technologies Co Ltd
Original Assignee
New H3C 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 New H3C Technologies Co Ltd filed Critical New H3C Technologies Co Ltd
Priority to CN201410597850.4A priority Critical patent/CN105634977B/zh
Priority to US15/522,867 priority patent/US10404611B2/en
Priority to PCT/CN2015/093085 priority patent/WO2016066101A1/en
Publication of CN105634977A publication Critical patent/CN105634977A/zh
Application granted granted Critical
Publication of CN105634977B publication Critical patent/CN105634977B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/407Bus networks with decentralised control
    • H04L12/413Bus networks with decentralised control with random access, e.g. carrier-sense multiple-access with collision detection [CSMA-CD]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/36Flow control; Congestion control by determining packet size, e.g. maximum transfer unit [MTU]
    • H04L47/365Dynamic adaptation of the packet size
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/407Bus networks with decentralised control
    • H04L12/413Bus networks with decentralised control with random access, e.g. carrier-sense multiple-access with collision detection [CSMA-CD]
    • H04L12/4135Bus networks with decentralised control with random access, e.g. carrier-sense multiple-access with collision detection [CSMA-CD] using bit-wise arbitration
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/26Route discovery packet
    • 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]
    • H04L69/166IP fragmentation; TCP segmentation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W48/00Access restriction; Network selection; Access point selection
    • H04W48/16Discovering, processing access restriction or access information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/02Data link layer protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04Network layer protocols, e.g. mobile IP [Internet Protocol]

Landscapes

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

Abstract

本申请提供一种发现PMTU的方法,应用在路径的目的节点上,包括以下步骤:接收来自所述路径的源节点的分片报文;由所述分片报文的最大长度和最小分片单位确定探测区间;根据预定策略在探测区间内取探测值,请求源节点回复长度为探测值的报文,根据回复报文是否被分片确定所述路径的PMTU。通过本申请的技术方案,减少了确定PMTU所需花费的时间和需要消耗的流量,降低了对网络性能的影响。

Description

发现路径最大传输单元的方法和装置
技术领域
本申请涉及网络通信技术领域,尤其涉及一种发现路径最大传输单元的方法和装置。
背景技术
网络设备的接口对通过报文的长度有一定的限制,允许通过的报文长度的最大值与接口的硬件配置、所采用的传输协议等因素有关。当报文的长度超过网络设备的接口上允许通过的最大值时,将被分割为几个片段,分别封装为长度不超过该最大值的几个报文传输到目的节点,再由目的节点进行重组;这一过程称为分片(fragmentation),分割后的报文称为分片报文。
网络设备在不分割报文的前提下允许通过的最大链路层载荷,被称为最大传输单元(MTU,maximum transmission unit)。能够从源主机无分割的传输到目的主机的最大链路层载荷,被称为路径最大传输单元(PMTU,Path maximum transmission unit)。PMTU数值上等于沿途经过的所有设备接口中最小的MTU。
一般而言,为了更高效的传输数据,报文的长度应该尽可能的大。但如果报文因超过PMTU导致分片发生,则会因每个分片报文都要封装新的报头而使得传输效率下降,并且可能引发重组错误。因此,以尽量少的流量消耗快速发现PMTU,对网络的性能有重要的意义。
发明内容
有鉴于此,本申请提供一种发现PMTU的方法,应用在路径的目的节点上,包括以下步骤:
接收来自所述路径的源节点的分片报文;
由所述分片报文的最大长度和最小分片单位确定探测区间;
根据预定策略在探测区间内取探测值,请求源节点回复长度为探测值的报文,根据回复报文是否被分片确定所述路径的PMTU。
本申请还提供了一种发现PMTU的装置,位于路径的目的节点上,包括:
分片报文接收单元,用于接收来自所述路径的源节点的分片报文;
探测区间确定单元,用于由所述分片报文的最大长度和最小分片单位确定探测区间;
PMTU探测单元,用于根据预定策略在探测区间内取探测值,请求源节点回复长度为探测值的报文,根据回复报文是否被分片确定所述路径的PMTU。
由以上技术方案可见,本申请的实施例中,目的节点根据来自源节点的分片报文的最大长度和最小分片单位得到探测区间,在该探测区间内通过少量报文交互即可得到准确的PMTU,大大减少了确定PMTU所需花费的时间和需要消耗的流量,在提高效率的同时降低了对网络性能的影响。
附图说明
图1是一个例子中目的节点所在设备的硬件架构示意图;
图2是一个例子中一种发现PMTU的方法的流程图;
图3是一个例子中网管服务器与被管理设备间发现PMTU的交互流程图;
图4是一个例子中用二分法取探测值得出PMTU的流程图;
图5是一个例子中一种发现PMTU的装置的逻辑结构图。
具体实施方式
报文的分片和重组由网络层进行。当网络层有要发送的数据时,会查询发送接口的MTU,如果数据报(datagram,完成三层封装后的网络层数据报)的长度超过MTU,则在网络层将该数据报分片,并且为每个片段重新生成三层首部。
以网络层的IP协议为例,在IP首部中包含了分片和重组所需的信息,其结构如表1所示:
Identification R DF MF Fragment Offset
表1
表1中,Identification(标识)字段为2字节,用来携带数据报的ID。源节点给每个IP数据报一个ID,用于唯一标识该IP数据报,目的节点利用此ID来判断接收的分片IP数据报是否属于同一个原始数据报。R、DF(Don't Fragment,不分片)和MF(More Fragment,更多分片)各为1个比特位,R保留未用;DF位为0表示可以对IP数据报分片,为1表示不允许对IP数据报分片;MF位为0表示本IP数据报未分片或是最后一个分片,为1表示本IP数据报是一个原始数据报的分片并且不是最后一个分片。Fragment Offset(分片偏移)字段为13比特,表示本IP数据报偏移原始数据报开始处的位置,偏移的字节数是该值乘以8;也就是说,网络层在对IP数据报分片时是以8字节为单位来进行的,8字节是IP协议的最小分片单位。为了减少分片的数量,网络层会在满足不超过MTU的条件下优先生成尽可能大的分片。
分片后的每个三层数据报作为链路层载荷,分别进行二层封装后成为报文(如二层以太帧),传输到目的节点。分片报文的重组在目的节点的网络层进行。仍以三层是IP数据报为例,目的节点根据IP首部中的上述字段,可以知道是否需要进行重组和如何进行重组,如:MF为0、Fragment Offset为0的IP数据报是未分片的数据报;MF为1的IP数据报可以按照Fragment Offset来排序;而MF为0、Fragment Offset不为0的IP数据报是最后一个分片。这样,分片后的数据报在目的节点上重新组合为完整的原始数据报。
IP首部中的DF位可以用来进行PMTU的发现。在RFC(Request For Comments,请求评议文件)1191中描述了一种确定PMTU的方法,路径的源节点发送一个设置了DF位(即数据报不可分割)的探测报文,如果该探测报文的长度超过传输路径上某个接口能够通过的最大报文,而该探测报文又不允许分片,则无法继续传递该探测报文的节点丢弃该探测报文,并向源节点回复“不可分割导致传递失败”的消息。如果收到“不可分割导致传递失败”的消息,源节点减少探测报文的长度后重新发送;否则增加探测报文的长度后重新发送。经过用多个大小不同的探测报文进行尝试后,源节点可以得出PMTU。
这种确定PMTU的方法往往需要等待很长的时间才能得出准确的PMTU,而反复迭代、不断尝试的过程会消耗网络的资源并影响网络的性能。另外,这种方法是在源节点上确定PMTU,而在一些应用场景中,更需要在目的节点上确定PMTU,如在网络管理领域,由于大量数据是沿着被管理设备到网管服务器的路径进行传输,在网管服务器上获知由被管理设备到网管服务器的PMTU更为重要。
在本申请的一个例子中,运行在目的节点上的PMTU发现控制逻辑能够用更短的时间、更小的资源消耗来确定从源节点到目的节点的路径的PMTU。其中,源节点和目的节点可以是网络中能够通信的任意两个物理的或逻辑的节点,可以是主机、网络设备、虚拟机、虚拟交换机等,本例中不做限定。
请参考图1,目的节点所在的设备10可以包括处理器111、存储器112以及网络接口113,这些硬件通过内部总线114相互连接。在这个例子中,处理器111在存储器112中运行PMTU发现控制逻辑,其运行流程如图2所示。
步骤210,接收来自路径的源节点的分片报文。
来自路径的源节点的分片报文可以是由源节点在发送前已经分片的报文,也可以是源节点发送时未分片,但因其长度超过源节点到目的节点的路径上某个节点允许通过的最大值,被该节点或与该节点相邻的节点分片而生成的分片报文。
在一个例子中,目的节点可以在需要进行PMTU发现的时候,请求源节点回复长度为指定值的报文,指定值应当大到足以使得回复报文被分片。不同的二层网络对报文长度的限制不同,但都有各自的上限值,一般而言,指定值超过该路径所在的二层网络的上限值,就可以使长度为指定值的回复报文被分片,保险起见也可以在高于上限值一定程度以上取值。例如,以太网报文(或称为帧,frame)协议规定的最大二层载荷的长度值为1500字节(即以太网报文的长度最大为1514字节),指定值可以取为1800字节。
这个例子中,源节点和目的节点支持指定回复报文长度的功能。目的节点可以利用与源节点间采用的通信协议中支持这一功能的命令来请求源节点回复某个长度的报文,也可以对已有的请求和响应报文进行扩展来实现这一功能,还可以自定义指定回复报文长度的请求响应过程,本例中对此不做限定。源节点收到目的节点的请求后,回复长度为指定值的报文,目的节点即可收到源节点回复的分片报文。
步骤220,由所述分片报文的最大长度和最小分片单位确定探测区间。
如前所述,在网络层对数据报进行分片时以最小分片单位为单位来进行,并且会在不超过MTU的范围内优先划分尽可能大的分段。换言之,目的节点收到的由同一原始数据报生成的分片报文中,最大长度分片报文的长度值与PMTU和最小分片单位相关。
本例中,报文的长度是指完整的二层帧的字节数,包括二层首部、二层载荷(即三层数据报),对有尾部封装的二层帧而言还包括二层的尾部。PMTU衡量的是二层载荷的长度(即三层数据报的长度),二层载荷的长度等于报文的长度减去二层封装的总长度,即减去二层首部和二层尾部的长度之和。以FraMaxLen表示目的节点收到的最大长度分片报文的长度值,以MinFragUnit表示最小分片单位的长度值,以PMTUFrameLen表示二层载荷长度为PMTU的报文长度值(即分片报文长度的最大可能值),则式1成立:
FraMaxLen≤PMTUFrameLen≤(FraMaxLen+MinFragUnit-1)………式1
如果PMTUFrameLen小于FraMaxLen,则最大长度的分片报文不能到达目的节点;如果PMTUFrameLen大于(FraMaxLen+MinFragUnit-1),则该分片报文再增加一个最小分片单位也同样可以到达目的节点,这样就不符合划分尽可能大的分段的分片原则;所以,式1成立。
二层载荷长度为PMTU的报文的长度在以FraMaxLen为下限,以(FraMaxLen+MinFragUnit-1)为上限的区间内;将该区间作为发现PMTU的探测区间,探测区间的长度由最小分片单位确定。
步骤230,根据预定策略在探测区间内取探测值,请求源节点回复长度为探测值的报文,根据回复报文是否被分片确定路径的PMTU。
目的节点根据预定策略至少一次在探测区间内取探测值,请求源节点回复长度为探测值的报文。如果报文中二层载荷的长度超过PMTU,则目的节点收到的回复报文是分片报文;否则目的节点收到的回复报文不会被分片。最长的未被分片的回复报文中二层载荷的长度即是PMTU。目的节点可以按照预定策略,通过在探测区间内逐次取不同探测值,来找到未被分片的回复报文的最大长度。
在一个例子中,目的节点可以在探测区间内依次顺序取值作为探测值,请求源节点回复长度为探测值的报文。如果目的节点从大到小依次取探测值,则收到第一个未被分片的回复报文即可停止探测,该报文的长度(或该探测值)就是未被分片的回复报文的最大长度;如果目的节点从小到大依次取探测值,则收到第一个被分片的回复报文即可停止探测,该报文的长度减1(或上一个探测值)就是未被分片的回复报文的最大长度。当然,也可以遍历探测区间内的所有可能取值,找到未被分片的回复报文的最大长度。
在另一个例子中,可以在探测区间采用二分法取值作为探测值,请求源节点回复长度为探测值的报文。如果回复报文未被分片则在较大值的半区内取下一个探测值,继续请求源节点回复长度为探测值的报文;否则在较小值的半区内取下一个探测值,继续请求源节点回复长度为探测值的报文。重复上述过程,直到找到未被分片的回复报文的最大长度。
最大长度未被分片的回复报文中的二层载荷长度等于PMTU,未被分片的回复报文的最大长度减去二层封装的总长度就是PMTU。这样,根据未被分片的回复报文所具有的最大长度,可以计算得出路径的PMTU。
本例中,根据来自源节点的分片报文的最大长度,目的节点得到取值范围为最小分片单位的探测区间,在该探测区间内通过少量报文交互即可得到准确的PMTU,极大的减少了所需花费的时间,提高了确定PMTU的效率;另外,也极大的降低了确定PMTU需要的流量消耗,基本不会对网络的性能造成影响。本例中还实现了在目的节点上发现PMTU,或者说,实现了对反向路径PMTU的发现。
在一些应用场景中,源节点到目的节点的物理传输路径可能发生变化,例如在有故障发生时,各种基于冗余链路的动态协议都可能导致传输路径的变化,PMTU也往往随之改变。在确定PMTU之后,当满足设定条件时,目的节点可以请求源节点回复长度对应于PMTU的报文、和长度对应于(PMTU+1)的报文。如果PMTU不变,则长度对应于PMTU的回复报文不会被分片,而长度对应于(PMTU+1)的回复报文会被分片。如果长度对应于PMTU的回复报文被分片、或者长度对应于(PMTU+1)的回复报文未被分片,则重新发现PMTU。设定条件可以根据具体的应用场景确定,例如,在发生可能导致路径变化的故障时、以某个预定周期等。
在本申请的另一个例子中,路径的目的节点为网管服务器,源节点为被管理设备,网管服务器通过Ping(Packet Internet Groper,互连网包探索器)命令来请求被管理网络设备回复某个长度的报文。
Ping命令是利用ICMP(Internet Control Message Protocol,互联网控制报文协议)报文来测试网络连接的程序,ICMP报文的封装结构如表2所示。其中,以太网首部为14字节,IP首部为20字节,ICMP首部为8字节。Ping命令可以通过l选项设置所发送的ICMP报文中ICMP数据的大小。
以太网首部 IP首部 ICMP首部 ICMP数据
表2
运行Ping命令的节点发送一个ICMP回声请求报文给对端节点,对端节点在收到该请求报文后,会回复ICMP回声应答报文,并以请求报文中的ICMP数据作为应答报文中的ICMP数据。发送ping命令的节点收到ICMP回声应答报文后,会报告回声应答报文是否分片以及每个分片报文的长度。
可见,通过设置对应于指定值或探测值的ICMP数据的大小,网管服务器利用ping命令即可请求被管理的设备回复长度为指定值或探测值的报文。具体而言,ICMP数据的大小等于指定值或探测值减去42字节(14字节以太网首部+20字节IP首部+8字节ICMP首部)。而对于ICMP回声应答报文而言,其二层载荷的长度等于应答报文的长度减去14字节(以太网首部)。
需要说明的是,在以太网中传输的二层帧的后面,还有4字节的校验和字段,用来进行二层帧的CRC(Cyclic Redundancy Check,循环冗余校验)校验,防止其在传输过程中发生异常变化。这4字节的校验和不作为二层帧的组成部分,也不计算在报文长度中。
本例中,网管服务器与被管理设备间的交互流程如图3所示。
网管服务器向被管理设备发送Ping命令,设置ICMP回声请求报文中ICMP载荷的大小等于(指定值-42)。对ICMP报文而言,指定值应当大于1514,ICMP载荷的大小应当大于1472。例如,指定值为2042时,向被管理设备发送如下命令:
Ping-l 2000 60.0.1.60;
其中,60.0.1.60为被管理设备的IP地址。
被管理设备的回复ICMP载荷的大小等于(指定值-42)的回声应答报文,该回复报文在网络层按照IP协议的最小分片单位8字节被分片,分片报文分别传输到网管服务器。
网管服务器找到最大长度的分片报文,设其长度为Length,将[Length,Length+7]作为探测区间。
网管服务器在[Length,Length+7]区间内根据预定策略取一个至多个探测值,向被管理设备发送对应的一个至多个Ping命令,设置ICMP回声请求报文中ICMP载荷的大小分别等于(探测值-42)。
被管理设备回复网管设备一个至多个ICMP回声应答报文,网管服务器根据这些ICMP回声应答报文是否被分片来确定PMTU。
例如,网管服务器向被管理设备发送以下8个ping命令:
Ping-l(Length-42)60.0.1.60;
Ping-l(Length-41)60.0.1.60;
Ping-l(Length-40)60.0.1.60;
Ping-l(Length-39)60.0.1.60;
Ping-l(Length-38)60.0.1.60;
Ping-l(Length-37)60.0.1.60;
Ping-l(Length-36)60.0.1.60;
Ping-l(Length-35)60.0.1.60;
则网管服务器收到的ICMP回声应答报文是否分片的情况及对应的PMTU如表3所示,其中,0表示回声应答报文未分片,1表示回声应答报文被分片。
PMTU Length-42 Length-41 Length-40 Length-39 Length-38 Length-37 Length-36 Length-35
Length-14 0 1 1 1 1 1 1 1
Length-13 0 0 1 1 1 1 1 1
Length-12 0 0 0 1 1 1 1 1
Length-11 0 0 0 0 1 1 1 1
Length-10 0 0 0 0 0 1 1 1
Length-9 0 0 0 0 0 0 1 1
Length-8 0 0 0 0 0 0 0 1
Length-7 0 0 0 0 0 0 0 0
表3
表3中,PMTU等于未被分片的回复报文的最大长度减去二层以太网首部的14字节;或者说等于最大长度未被分片的回复报文的ICMP数据大小加上ICMP首部和IP首部的28字节。网管服务器最多发送8个Ping命令即可得到PMTU。
再如,网管服务器可以在[Length,Length+7]区间内用二分法取探测值来计算得出PMTU。其流程请参见图4。
步骤401,网管服务器取(Length+4)为探测值,向被管理设备发送Ping命令:Ping-l(Length-38)60.0.1.60;
步骤402,网管服务器判断(Length+4)长度的回声应答报文是否分片,如果是,执行步骤403,否则转步骤409;
步骤403,网管服务器在[Length,Length+4]区间取(Length+2)为探测值,向被管理设备发送Ping命令:Ping-l(Length-40)60.0.1.60;
步骤404,网管服务器判断(Length+2)长度的回声应答报文是否分片,如果是,执行步骤405,否则转步骤407;
步骤405,网管服务器在[Length,Length+2]区间取(Length+1)为探测值,向被管理设备发送Ping命令:Ping-l(Length-41)60.0.1.60;
步骤406,网管服务器判断(Length+1)长度的回声应答报文是否分片,如果是,则PMTU等于(Length-14);否则PMTU等于(Length-13);流程结束;
步骤407,网管服务器在[Length+2,Length+4]区间取(Length+3)为探测值,向被管理设备发送Ping命令:Ping-l(Length-39)60.0.1.60;
步骤408,网管服务器判断(Length+3)长度的回声应答报文是否分片,如果是,则PMTU等于(Length-12);否则PMTU等于(Length-11);流程结束;
步骤409,网管服务器在[Length+4,Length+7]区间取(Length+6)为探测值,向被管理设备发送Ping命令:Ping-l(Length-36)60.0.1.60;
步骤410,网管服务器判断(Length+6)长度的回声应答报文是否分片,如果是,执行步骤411,否则转步骤413;
步骤411,网管服务器在[Length+4,Length+6]区间取(Length+5)为探测值,向被管理设备发送Ping命令:Ping-l(Length-37)60.0.1.60;
步骤412,网管服务器判断(Length+5)长度的回声应答报文是否分片,如果是,则PMTU等于(Length-10);否则PMTU等于(Length-9);流程结束;
步骤413,网管服务器在[Length+6,Length+7]区间取(Length+7)为探测值,向被管理设备发送Ping命令:Ping-l(Length-35)60.0.1.60;
步骤414,网管服务器判断(Length+7)长度的回声应答报文是否分片,如果是,则PMTU等于(Length-8);否则PMTU等于(Length-7);流程结束。
基于图4的流程,网管服务器最多发送3个Ping命令即可得到PMTU。
在网络管理中,网管服务器需要及时感知被管理设备的运行状态是否正常。在很多应用场景中,网管服务器采用主动向被管理设备发送周期性轮询探测报文(如Ping命令)的方式,根据是否收到被管理设备的回复报文,来判断被管理设备的状态。可以将轮询报文用来作为要求被管理设备回复某个长度报文的请求报文,从而能够利用常规的网络管理报文传输来进行PMTU的发现,进一步降低了PMTU发现对网络资源的占用和对网络性能的影响。另外,由于网络管理中大量数据沿着被管理设备到网管服务器的路径进行传输,在网管服务器上得到路径的PMTU能够更好的优化网管数据的传输。
与上述流程实现对应,本申请还提供了发现PMTU的装置,应用在路径的目的节点上,该装置可以通过软件实现,也可以通过硬件或者软硬件结合的方式实现。以软件实现为例,作为一个逻辑意义上的装置,可以通过图1中的处理器111在存储器112中运行PMTU发现控制逻辑而形成。
图5所示为本申请一个例子中的一种发现PMTU的装置,位于路径的目的节点上,从功能上划分,包括分片报文接收单元、探测区间确定单元和PMTU探测单元,其中:
分片报文接收单元,用于接收来自所述路径的源节点的分片报文;
探测区间确定单元,用于由所述分片报文的最大长度和最小分片单位确定探测区间;
PMTU探测单元,用于根据预定的策略在探测区间内取探测值,请求源节点回复长度为探测值的报文,根据回复报文是否被分片确定所述路径的PMTU。
所述装置还可以包括分片报文请求单元,用于请求源节点回复长度为指定值的报文;所述指定值能够使回复报文被分片;此时,所述来自路径的源节点的分片报文包括:源节点回复的分片报文。
所述探测区间的下限为:所述分片报文的最大长度;所述探测区间的上限为:所述分片报文的最大长度加最小分片单位减1。
在一个例子中,所述PMTU探测单元包括顺序探测模块和PMTU计算模块,其中:顺序探测模块用于在探测区间依次顺序取值作为探测值,请求源节点回复长度为探测值的报文;PMTU计算模块用于根据未被分片的回复报文所具有的最大长度,计算所述路径的PMTU。
在另一个例子中,所述PMTU探测单元包括二分探测模块和PMTU计算模块,其中:二分探测模块,用于在探测区间采用二分法取值作为探测值,请求源节点回复长度为探测值的报文;如果回复报文未被分片则在较大值的半区内取下一个探测值继续,否则在较小值的半区内取下一个探测值继续,直到找到未被分片的回复报文所具有的最大长度;PMTU计算模块,用于根据未被分片的回复报文所具有的最大长度,计算所述路径的PMTU。
所述装置还可以包括PMTU变化检测单元和重新发现单元,其中:PMTU变化检测单元用于在确定所述路径的PMTU之后,当满足设定条件时,请求源节点回复长度对应于PMTU和长度对应于(PMTU+1)的报文;重新发现单元用于在长度对应于PMTU的回复报文被分片、或者长度对应于(PMTU+1)的回复报文未被分片时,则重新发现所述路径的PMTU。
一个例子中,所述PMTU探测单元包括ping命令发送模块,用于向所述路径的源节点发送互连网包探索器ping命令;所述ping命令的互联网控制报文协议ICMP数据的大小对应于探测值;所述最小分片单位为IP协议的最小分片单位。
以上所述仅为本申请的较佳实施例而已,并不用以限制本申请,凡在本申请的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本申请保护的范围之内。

Claims (12)

1.一种发现路径最大传输单元PMTU的方法,其特征在于,所述方法应用在路径的目的节点上,包括以下步骤:
接收来自所述路径的源节点的分片报文;
由所述分片报文的最大长度和最小分片单位确定探测区间;所述探测区间的下限为:所述分片报文的最大长度;所述探测区间的上限为:所述分片报文的最大长度加最小分片单位减1;
根据预定策略在探测区间内取探测值,请求源节点回复长度为探测值的报文,根据回复报文是否被分片确定所述路径的PMTU。
2.根据权利要求1所述的方法,其特征在于,所述方法还包括:请求源节点回复长度为指定值的报文;所述指定值能够使回复报文被分片;
所述来自路径的源节点的分片报文包括:源节点回复的分片报文。
3.根据权利要求1所述的方法,其特征在于,所述根据预定策略在探测区间内取探测值,请求源节点回复长度为探测值的报文,根据回复报文是否被分片确定所述路径的PMTU,包括:
在探测区间依次顺序取值作为探测值,请求源节点回复长度为探测值的报文;
根据未被分片的回复报文所具有的最大长度,计算所述路径的PMTU。
4.根据权利要求1所述的方法,其特征在于,所述根据预定策略在探测区间内取探测值,请求源节点回复长度为探测值的报文,根据回复报文是否被分片确定所述路径的报文长度最大值,包括:
在探测区间采用二分法取值作为探测值,请求源节点回复长度为探测值的报文;如果回复报文未被分片则在较大值的半区内取下一个探测值继续,否则在较小值的半区内取下一个探测值继续,直到找到未被分片的回复报文所具有的最大长度;
根据未被分片的回复报文所具有的最大长度,计算所述路径的PMTU。
5.根据权利要求1所述的方法,其特征在于,所述方法还包括:
在确定所述路径的PMTU之后,当满足设定条件时,请求源节点回复长度对应于PMTU和长度对应于(PMTU+1)的报文;
如果长度对应于PMTU的回复报文被分片、或者长度对应于(PMTU+1)的回复报文未被分片,则重新发现所述路径的PMTU。
6.根据权利要求1所述的方法,其特征在于,所述请求路径的源节点回复长度为探测值的报文,包括:向所述路径的源节点发送互连网包探索器ping命令;所述ping命令的互联网控制报文协议ICMP数据的大小对应于探测值;
所述最小分片单位为IP协议的最小分片单位。
7.一种发现路径最大传输单元PMTU的装置,其特征在于,所述装置位于路径的目的节点上,包括:
分片报文接收单元,用于接收来自所述路径的源节点的分片报文;
探测区间确定单元,用于由所述分片报文的最大长度和最小分片单位确定探测区间;所述探测区间的下限为:所述分片报文的最大长度;所述探测区间的上限为:所述分片报文的最大长度加最小分片单位减1;
PMTU探测单元,用于根据预定策略在探测区间内取探测值,请求源节点回复长度为探测值的报文,根据回复报文是否被分片确定所述路径的PMTU。
8.根据权利要求7所述的装置,其特征在于,所述装置还包括:分片报文请求单元,用于请求源节点回复长度为指定值的报文;所述指定值能够使回复报文被分片;
所述来自路径的源节点的分片报文包括:源节点回复的分片报文。
9.根据权利要求7所述的装置,其特征在于,所述PMTU探测单元包括:
顺序探测模块,用于在探测区间依次顺序取值作为探测值,请求源节点回复长度为探测值的报文;
PMTU计算模块,用于根据未被分片的回复报文所具有的最大长度,计算所述路径的PMTU。
10.根据权利要求7所述的装置,其特征在于,所述PMTU探测单元包括:
二分探测模块,用于在探测区间采用二分法取值作为探测值,请求源节点回复长度为探测值的报文;如果回复报文未被分片则在较大值的半区内取下一个探测值继续,否则在较小值的半区内取下一个探测值继续,直到找到未被分片的回复报文所具有的最大长度;
PMTU计算模块,用于根据未被分片的回复报文所具有的最大长度,计算所述路径的PMTU。
11.根据权利要求7所述的装置,其特征在于,所述装置还包括:
PMTU变化检测单元,用于在确定所述路径的PMTU之后,当满足设定条件时,请求源节点回复长度对应于PMTU和长度对应于(PMTU+1)的报文;
重新发现单元,用于在长度对应于PMTU的回复报文被分片、或者长度对应于(PMTU+1)的回复报文未被分片时,则重新发现所述路径的PMTU。
12.根据权利要求7所述的装置,其特征在于,所述PMTU探测单元包括:ping命令发送模块,用于向所述路径的源节点发送互连网包探索器ping命令;所述ping命令的互联网控制报文协议ICMP数据的大小对应于探测值;
所述最小分片单位为IP协议的最小分片单位。
CN201410597850.4A 2014-10-29 2014-10-29 发现路径最大传输单元的方法和装置 Active CN105634977B (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN201410597850.4A CN105634977B (zh) 2014-10-29 2014-10-29 发现路径最大传输单元的方法和装置
US15/522,867 US10404611B2 (en) 2014-10-29 2015-10-28 Discovering path maximum transmission unit
PCT/CN2015/093085 WO2016066101A1 (en) 2014-10-29 2015-10-28 Discovering path maximum transmission unit

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201410597850.4A CN105634977B (zh) 2014-10-29 2014-10-29 发现路径最大传输单元的方法和装置

Publications (2)

Publication Number Publication Date
CN105634977A CN105634977A (zh) 2016-06-01
CN105634977B true CN105634977B (zh) 2019-06-04

Family

ID=55856619

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201410597850.4A Active CN105634977B (zh) 2014-10-29 2014-10-29 发现路径最大传输单元的方法和装置

Country Status (3)

Country Link
US (1) US10404611B2 (zh)
CN (1) CN105634977B (zh)
WO (1) WO2016066101A1 (zh)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113411260B (zh) 2015-08-31 2023-04-18 华为技术有限公司 一种IPv6网络中数据报文的发送方法及装置
US10594618B1 (en) 2017-06-06 2020-03-17 Juniper Networks, Inc Apparatus, system, and method for fragmenting packets into segments that comply with the maximum transmission unit of egress interfaces
US10992590B2 (en) * 2018-04-09 2021-04-27 Nicira, Inc. Path maximum transmission unit (PMTU) discovery in software-defined networking (SDN) environments
CN111953620B (zh) * 2020-08-21 2023-01-10 锐捷网络股份有限公司 一种分片报文的重组方法及装置
CN113055305B (zh) * 2021-02-28 2022-09-02 北京华三通信技术有限公司 报文处理方法及装置
CN113726574A (zh) * 2021-08-31 2021-11-30 杭州迪普信息技术有限公司 一种生成snmp响应报文的方法及装置
CN113890858B (zh) * 2021-09-29 2023-10-20 杭州迪普科技股份有限公司 Pmtu的探测方法及装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1716944A (zh) * 2004-06-28 2006-01-04 杭州华为三康技术有限公司 网络路径最大传输长度发现方法
CN102546359A (zh) * 2010-12-10 2012-07-04 中兴通讯股份有限公司 实现路径最大传输单元探测的方法及路由器

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7512120B2 (en) * 2002-07-09 2009-03-31 Ntt Docomo, Inc. Node, correspondent node, mobility anchor point, and home agent in packet communication system, packet communication system, and path MTU discovery method
KR100513282B1 (ko) * 2003-05-02 2005-09-09 삼성전자주식회사 에드 혹 네트워크에서의 패스 엠티유를 이용하여 데이터를 송신하는 데이터 송신 노드 및 송신 방법
US7680047B2 (en) * 2005-11-22 2010-03-16 Cisco Technology, Inc. Maximum transmission unit tuning mechanism for a real-time transport protocol stream
WO2009139914A1 (en) 2008-05-15 2009-11-19 Nortel Networks Limited Method and system for transmission of fragmented packets on a packet-based communication network
US8121135B2 (en) * 2009-06-23 2012-02-21 Juniper Networks, Inc. Discovering path maximum transmission unit size

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1716944A (zh) * 2004-06-28 2006-01-04 杭州华为三康技术有限公司 网络路径最大传输长度发现方法
CN102546359A (zh) * 2010-12-10 2012-07-04 中兴通讯股份有限公司 实现路径最大传输单元探测的方法及路由器

Also Published As

Publication number Publication date
US20170331755A1 (en) 2017-11-16
CN105634977A (zh) 2016-06-01
US10404611B2 (en) 2019-09-03
WO2016066101A1 (en) 2016-05-06

Similar Documents

Publication Publication Date Title
CN105634977B (zh) 发现路径最大传输单元的方法和装置
US11171969B2 (en) Systems and methods for real-time configurable load determination
US7440415B2 (en) Virtual network addresses
CN110069441A (zh) 一种用于流计算的fpga网络及流计算系统与方法
CN101360046B (zh) 一种带宽资源的节约方法
DE102020112346A1 (de) Techniken zum betrieb einer tdm-mac
EP3703316B1 (en) Frame aggregation in a wireless network
EP3338396A1 (en) Device and method for establishing connection in load-balancing system
KR102148757B1 (ko) 통신 시스템에서 데이터를 송수신하는 방법 및 장치
CN103001846B (zh) 用于数据网的嵌入式端到端延迟信息
Pedretti et al. Using the Cray Gemini Performance Counters.
CN104363181A (zh) 流量传输控制方法及装置
CN113472670B (zh) 用于计算机网络的方法、网络装置及存储介质
CN105847352A (zh) 基于分布式缓存系统的扩容方法、装置及分布式缓存系统
DE102022129250A1 (de) Übertragungsrate basierend auf detektierter verfügbarer Bandbreite
CN107770239A (zh) 用于通过网络通信的方法和设备
US10176068B2 (en) Methods, systems, and computer readable media for token based message capture
CN109586987A (zh) 一种对云存储系统中设备的测试方法及装置
Al-Rubaie et al. Simulating fog computing in OMNeT++
CN106161339B (zh) 获取ip访问关系的方法及装置
Yasin et al. Gossip routing protocol for forest fire detection using wireless sensor networks
CN113094437B (zh) 一种基于Rsync的区块链状态数据同步方法及系统
CN100579075C (zh) 一种快速响应icmp回送请求报文的方法
CN108334424B (zh) 基于lpwan技术的网络通讯管理平台过滤冗余数据的方法
Ren et al. Smart NCAP supporting low-rate DDoS detection for IEEE 21451-1-5 internet of things

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
CB02 Change of applicant information
CB02 Change of applicant information

Address after: 310052 Binjiang District Changhe Road, Zhejiang, China, No. 466, No.

Applicant after: Xinhua three Technology Co., Ltd.

Address before: 310052 Binjiang District Changhe Road, Zhejiang, China, No. 466, No.

Applicant before: Huasan Communication Technology Co., Ltd.

GR01 Patent grant
GR01 Patent grant