分片程序的一个例子:
可以在下一个网络中被传输的最大数据报大小被称为最大传输单元(MTU)
如果总长度小于或者等于最大传输单元,则在处理数据报的时候直接将数据报呈给下一个节点。否则将数据
报分隔成两个分片,第一个分片设置成最大的分片大小,第二个分片则是数据报的剩余部分。第一个分片在数
据报处理中被呈送给下一个节点,而第二个分片如果仍然比MTU大则被呈送给分片程序。
符号(Notation):
FO - 分片偏移(Fragment Offset)
IHL - Internet头部长度(Internet Header Length)
DF - 禁止分片标志(Don't Fragment flag)
MF - More分片标志(More Fragments flag)
TL - 总长度(Total Length)
OFO - 老分片偏移(Old Fragment Offset)
OIHL - 老Internet头部长度(Old Internet Header Length)
OMF - 老More分片标志(Old More Fragments flag)
OTL - 老总长度(Old Total Length)
NFB - 分片块数量(Number of Fragment Blocks)
MTU - 最大传输单元(Maximum Transmission Unit)
程序(Procedure):
如果TL<=MTU,则将该数据报上呈给下一个数据报处理环节
否则如果DF=1,则丢弃数据报
否则
处理第一个分片:
(1)拷贝原来的internet头部
(2)OTHL=OHL;OTL=TL;OFO=FO;OMF=MF
(3)NFB=(MTU-IHL*4)/8
(4)附着上第一个NFB*8的数据块
(5)修正头部
MF=1;TL=(IHL*4)+(NFB*8);
重新计算校验和
(6)将该分片提交给数据报处理流程的下一个节点
接着处理第二个分片:
(7)选择性地拷贝internet头部(有些选项不拷贝,参见选项定义)
(8)填充剩下的数据
(9) 修正头部:
IHL=(((OIHL*4)-(未拷贝的选项长度))+3)/4;
TL=OTL-NFB*8-(OIHL-IHL)*4);
FO=OFO+NFB;MF=OMF;
重新计算校验和
(10) 提交该数据分片给数据报处理流程中的下一个节点.完成
在上述程序中,每个分片(除最后一个)被设置成最大允许大小。另外一个可选的方案是产生小于最大允许大小
的分片。比如,分片程序可以重复地将大数据报分成两半直到最后的分片小于最大传输大小。
一个重组程序例子
对每个数据报来说,buffer标识是通过源地址,目的地址,协议和分片标识头部结合计算得到的。
如果这是一个完整的数据报(也就是分片偏移和more标志头部都是0),则任何同这个buffer标识关联的
重组资源被释放,数据报被前推给下一个节点。
如果这个buffer标识现在没有其它分片,则重组资源被分配。重组资源包括一个数据缓冲,一个头部
缓冲,一个分片块位表,一个总数据长度头部,和一个定时器。分片的数据根据分片偏移和长度被放在数据缓
冲中,且在分片块位表中根据接收到的分片块设定位。
如果是第一个分片(分片偏移为0),头部被放在头部缓冲中。如果是最后一个分片(more标志位
是0),总的数据长度被计算。如果分片完成了数据报(通过检查设置在分片块表中的位来测试),则数据报
被送到数据报的下一个处理步骤中。否则,定时器设置成当前定时器值和分片生存时间(TTL)两者的大值,
然后重组程序放弃控制。
如果定时器时间到了,该缓冲标识的所有的重组资源将被释放。定时器的初始化设置是比重组等待时
间小的界限。这是因为如果到达分片的生存时间如果大于当前定时器值,等待时间将被增加,但是如果到达
分片的生存时间小于当前定时器值,则不会被减少。该定时器可以达到的最大值是生存时间的最大值(大约
4.25分钟左右)。当前推荐的初始化定时器设置是15秒。可以根据协议积聚的经验修改该值。注意该参数值的
选择是同可用的缓冲容量以及传输媒介的数据传输率相关的。也就是说,数据传输率乘以定时器值等于缓冲
大小(e.g.,10kb/s*15s=150kb).
符号(Notation):
FO - 分片偏移(Fragment Offset)
IHL - Internet头部长度(Internet Header Length)
MF - More分片标志(More Fragments flag)
TTL - 生存时间(Time To Live)
NFB - 分片块数目(Number of Fragment Blocks)
TL - 总长度(Total Length)
TDL - 总数据长度(Total Data Length)
BUFID - Buffer标识(Buffer Identifier)
RCVBT - 分片接收位表(Fragment Received Bit Table)
TLB - 定时器下限(Timer Lower Bound)
程序(Procedure):
(1) BUFID <- source|destination|protocol|identification;
(2) IF FO = 0 AND MF = 0
(3) THEN IF buffer with BUFID is allocated
(4) THEN flush all reassembly for this BUFID;
(5) Submit datagram to next step; DONE.
(6) ELSE IF no buffer with BUFID is allocated
(7) THEN allocate reassembly resources
with BUFID;
TIMER <- TLB; TDL <- 0;
(8) put data from fragment into data buffer with
BUFID from octet FO*8 to
octet (TL-(IHL*4))+FO*8;
(9) set RCVBT bits from FO
to FO+((TL-(IHL*4)+7)/8);
(10) IF MF = 0 THEN TDL <- TL-(IHL*4)+(FO*8)
(11) IF FO = 0 THEN put header in header buffer
(12) IF TDL # 0
(13) AND all RCVBT bits from 0
to (TDL+7)/8 are set
(14) THEN TL <- TDL+(IHL*4)
(15) Submit datagram to next step;
(16) free all reassembly resources
for this BUFID; DONE.
(17) TIMER <- MAX(TIMER,TTL);
(18) give up until next fragment or timer expires;
(19) timer expires: flush all reassembly with this BUFID; DONE.
在这个例子中,两个或多于两个的分片包含了同样的数据。
不管是同一个或者是局部的交迭,本程序使用在数据缓冲中最近到达的拷贝以及最近投递的数据报。
标识(Identification)
数据报标识的选择是基于提供一种唯一标识特殊数据报的分片的方式的需要。重组分片的协议模块在当分片具有相投的源地址,目的地址,协议和标识的时候,断定他们属于同一个数据报。因此,发送者必须选择一个在数据报(或者数据报的任一分片在internet生存期间对该源地址,目的地址对和协议来说是唯一的标识。
发送协议模块需要维护一个标识表,对于同它进行通信的目的地址在最后一个的最大包生命周期内维护一个条目。
但是,既然标识允许65536个不同的值,有些主机可用简单地使用独立于目的地址的唯一标识。
由高层协议来选择标识是合理的。比如,TCP协议模块可能重传一个相同的TCP分片,如果重传携带了同第一次传送时一样的标识,正确接收的可能性会加强,因为他们中的任何一个数据报都可用用来构造一个正确的TCP分片。
服务类型(Type of Service)
服务类型(TOS)用于internet服务质量选择。服务类型通过一套参数(优先级,延迟,吞吐和可靠性)来指定。这套参数被映射成数据报传输中的特定网络的真实服务参数。
优先级(Precedence). 数据报重要性的独立衡量。
延迟(Delay). 立即投递对该指示的数据报是重要的。
吞吐(Throughput). 高数据率对具有该指示的数据报是重要的。
可靠性(Reliability). 高层确保投递可靠的努力对有该指示的数据报是重要的
比如,ARPANET有个优先级位,可以选择标准(“standard”)信息(type 0)和未受控制(“uncontrolled”)的信息(type 3)。单一包或者多包也可以视为一个服务参数。未受控制的信息倾向于以较低的可靠性投递,但是可以获得比较低的延迟。假设一个internet数据报要在ARPANET上传送,设置internet服务类型为:
优先级(Precedence): 5
延迟(Delay): 0
吞吐(Throughput): 1
可靠性(Reliability): 1
在这个例子中,这些参数向ARPANET上可用参数的映射就是设置ARPANET优先级位(priority bit)为打开,因为Internet优先级(precedence)处于它的优先级区域的上半部。选择标准(standard)消息,因为有吞吐和可靠性要求指示,二没有延迟指示。更详细的信息在”Service Mappings”[8]的服务映射中给出。
生存时间(Time to Live)
生存时间由发送者设置成允许数据报在internet系统上允许存活的最大时间。如果数据报在internet系统上长于生存时间,则数据报必须被销毁。
在internet头部被处理的每个点,该头部必须减小,以反应花在处理数据报上的时间。即使无法获得实际花费时间的本地信息,该头部也必须减1。时间以秒单位衡量(比如,值1标识1秒)。因此,最大生存时间是255秒或者4.25分钟。由于处理数据报的每个模块至少对TTL减1,即使他在小于1秒内处理完数据报,因此TTL只能被当作数据报可以存在的时间上限。
有些高层可靠性连接协议是基于老的数据报副本在一定时间间隔之后不会再到达的假设。TTL给了这些协议假设满足的保证。
选项(Options)
选项对每个数据报是可选的,但是对实现是要求的。也就是说,选项的出现与否是发送者的选择,但是每个internet模块必须能够解析每个选项。在选项头部可以有多个选项。
选项可以不结束于32位边界。Internet头部必须以0字节填充。这些字节的开始将被解析成选项结束标志,其它的结识乘internet头部填充。
每个internet模块必须能够作用于每个选项。如果分类的、限制的、分隔的通信流要传送,安全选项是需要的。
校验和(Checksum)
如果internet头部改变,internet头部校验和要重新计算。比如,生存时间的减少,internet选项的增加或者变化,或者由于分片。在internet级别的这个校验和用来防止internet头部的传输错误。
有些应用程序允许一部分数据位错误,但是不允许重传延迟。如果internet协议强迫数据的正确性,则这些程序不能支持。
错误(Errors)
internet协议错误可以通过ICMP信息报告。
3.3. 接口(Interfaces)
IP的用户接口的功能性描述最好是功能性的,因为每个操作系统有不同的库(facility)。因此,我们要警告读者,不同的IP实现可能有不同的用户接口。
但是,所有的IPs实现必须提供一套最小的服务以确保所有的ip实现能够职称同样的协议层次结构。这一章指定了所有的ip实现要求的功能接口。
Internet协议接口一边是局域网络,另一边是较高层的协议或者一个应用程序。下面,高层协议或者应用程序将称为用户,因为它正在使用internet模块。 因为internet协议是一个数据报协议,在数据报传输中,维护了最小内存或者状态,每个调用internet协议模块的用户提供IPs所需的全部信息以执行所需服务。
一个上层接口的例子
下面两个例子调用满足了internet模块通信的用户要求(”=>”标识返回):
SEND (src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt => result)
where:
src = source address(源地址)
dst = destination address(目的地址)
prot = protocol(协议)
TOS = type of service(服务类型)
TTL = time to live(生存实际那)
BufPTR = buffer pointer(缓冲指针)
len = length of buffer(缓冲长度)
Id = Identifier(标识)
DF = Don't Fragment(禁止分片)
opt = option data(选项数据)
result = response(响应)
OK = datagram sent ok(数据报发送OK)
Error = error in arguments or local network error(参数或者局域网络错误)
注意优先级包括在TOS里面,安全(security)/间隔(compartment)在选项(option)中传递
RECV (BufPTR, prot, => result, src, dst, TOS, len, opt)
where:
BufPTR = buffer pointer(缓冲指针)
prot = protocol(协议)
result = response(响应)
OK = datagram received ok(数据报接收OK)
Error = error in arguments(参数错误)
len = length of buffer(缓冲长度)
src = source address(源地址)
dst = destination address(目的地址)
TOS = type of service(服务类型)
opt = option data(选项数据)
当用户发送一个数据报的时候,它提供所有的参数,执行SEND调用。Internet模块在收到该调用以后,检查参数,并准备和发送消息。如果参数没有问题,且数据报被局域网接受,调用成功返回。如果参数不合法,或者数据报不被局域网络接受,调用返回失败。失败返回的时候,必须生成问题原因的合理报告,但是这种报告的细节由各自的实现决定。
当一个数据报从局域网络到达internet协议模块的时候,队列中可能有从用户指定地址来的一个RECV调用,或者没有,在第一种情况中,在队列中的的调用通过传递从数据报到用户的信息而被满足。在第二种情况下,指定地址的用户被通知有悬而未决的数据报。如果指定的用户地址不存在,一个ICMP错误信息返回给发送者,数据被丢弃。
用户的通知可能通过一个伪中断或者其它相同的机制,一个适合于实现的特殊操作系统环境的机制。
用户的接收调用可以被一个悬而未决的数据报立即满足,或者调用被悬置,直到数据报到达。
在发送主机有多个地址(多个物理连接或者逻辑地址)的情况下,源地址包含在发送调用中。Internet模块必须检查确保源地址是该主机的合法地址之一。
协议可以允许或者要求一个到internet的调用来指示某一类型数据报的兴趣或者保留排他性的使用。
这一节从功能的角度出发阐述了用户/IP(USER/IP)接口。使用的名词同在高层语言的函数调用中的大多数程序一样,但这种用法并被意味着排除trap类型服务调用(比如,SVCs,UUOs,EMTs)或者其它任何形式的进程间通信。
附录A:例子
Example 1:
下面是internet数据报携带的最小数据的例子:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 |Type of Service| Total Length = 21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 111 |Flg=0| Fragment Offset = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time = 123 | Protocol = 1 | header checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+
Example Internet Datagram
Figure 5.
注:每个小间隔表示一个位。
这是internet协议版本4的一个数据报。Internet头部包含5个32位字,数据报的总长度是21个八位字节。这个数据报是一个完整的数据报(不是分片)
例子2:
在这个例子中,我们首先看到一个中等大小的internet数据报(452数据字节),然后是两个internet分片,可能是当该数据报在最大允许传输代谢哦啊是280字节的网络上传输时该数据报的分片。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 |Type of Service| Total Length = 472 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 111 |Flg=0| Fragment Offset = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time = 123 | Protocol = 6 | header checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
\ \
\ \
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example Internet Datagram
Figure 6.
Now the first fragment that results from splitting the datagram after
256 data octets.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 |Type of Service| Total Length = 276 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 111 |Flg=1| Fragment Offset = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time = 119 | Protocol = 6 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
\ \
\ \
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example Internet Fragment
Figure 7.
[Page 36]
September 1981
Internet Protocol
And the second fragment.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 |Type of Service| Total Length = 216 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 111 |Flg=0| Fragment Offset = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time = 119 | Protocol = 6 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
\ \
\ \
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example Internet Fragment
Figure 8.
[Page 37]
September 1981
Internet Protocol
Example 3:
Here, we show an example of a datagram containing options:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 8 |Type of Service| Total Length = 576 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 111 |Flg=0| Fragment Offset = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time = 123 | Protocol = 6 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt. Code = x | Opt. Len.= 3 | option value | Opt. Code = x |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt. Len. = 4 | option value | Opt. Code = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt. Code = y | Opt. Len. = 3 | option value | Opt. Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
\ \
\ \
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example Internet Datagram
Figure 9.