【IPV6技术】IPV6 相关概念浅谈-应用中的问题

bjjqsj

1 应用中的问题　　下面主要讨论与应用Path MTU发现机制相关的问题，主要包括：
　　由哪个层来应用PMTU发现?
　　如何缓存PMTU信息?
　　如何删除无用的PMTU信息?
　　传输层和更高层必须做什么?
　　1.1 分层
　　在IP架构里面，发送什么样尺寸的报文是由IP层以上的协议决定的，可以称它们为报文化协议(packetization protocol)。报文化协议通常是传输层协议，但也有可能是更高层的协议(比如建立在UDP上的协议)。在报文化层(packetization layer)应用Path MTU发现机制可以简化许多层间的问题，但同时也带来一些弊端：每一个报文化协议不得不重复应用PMTU发现机制，不同的报文化层之间很难共享PMTU信息，由一些报文化层保留的面向对象的状态基不容易扩展以长时间保留PMTU信息。
　　因此建议在IP层保留PMTU信息，ICMP层处理接收到的Packet Too Big消息。报文化层次必须响应PMTU的变化，改变他们发送的尺寸。为了支持这种分层，报文化层需要一种方法来学习到MMS_S(maximum send transport-message size)。MMS_S的值等于Path MTU减去IPV6头部与附加头部分的和。
　　有时候也许报文化层不能改变消息的大小，那么这就可能造成报文大小超过了Path MTU。为了适应这种特殊情况，就需要将报文的载荷payload进行分片(参考RFC1883)。然而，报文化层尽量避免使用分片。
　　1.2 存储PMTU信息
　　理想的情况下，PMTU应该和特定的路径相关的，然而，通常没有足够的信息去完整且精确地区分这些路径。进而，节点就需要使用某个本地特性来区分路径。在组播目的地址的情况下，报文的拷贝会在许多路径上穿越，到达不同的节点。选择组播路径的本地特性需要代表所有一系列组播路径。
　　最简单化的情况下，应用者可能保留一个PMTU的值，用于发送所有的报文。这个PMTU为所有学习的PMTU中最小的一个。使用这样的解决方法可能造成许多路径上的报文大小都比实际可以应用的MTU要小。
　　有些应用者可能会使用目的地址作为本地特性来识别路径(也就是一个目的地址代表一条路径)，由某个目的地址决定的PMTU是到达该目的地址的所有路径集中最小的PMTU。我们希望这个路径集是一个小范围的(路径集太大仍然会造成发送的报文过小，浪费网络带宽)，在大多数情况下最好是由单一的路径组成。这种方法可以在每个目的地址基础上形成优化的报文尺寸，也很好地与邻居发现协议(参考RFC2461)中的主机概念模型相结合：每个PMTU的值对应于目的地缓存中的一个条目。
　　如果使用flows(参考RFC1883)的话，那么应用者可能使用flow id作为路径的本地特性。去往相同的目的地址而带有不同flow id的报文会走不同的路径，相应的有不同的PMTU。这种方法可以在每个flow id基础上形成优化的报文尺寸，可以提供比基于目的地址更加精细的尺寸颗粒。
　　对于源路由报文而言，源路由信息可以进一步限制路径的本地特性。这里有一种比较特殊的情况，当一个报文包含type 0的路由头，其中所有的Strict/Loose Bit Map都是1时，该报文包含了一个完整的路径细节，那么应用者可以使用源路由信息作为本地特性来区分路径。
　　需要指出的是，有些路径可以通过不同的安全级别进一步区分，但是这部分的细节应该在安全级别相关协议中定义。
　　一开始的时候，某路径PMTU值应该假设为第一跳链路的MTU。当收到一个Packet Too Big消息的时候，节点确定该消息应该应用于哪条路径。例如，如果基于目的地址来确定路径的话，那么原始报文中的目的地址将用于确定消息生效的路径。需要注意的是，如果原始报文中包含路由头，那么路由头应该用于确定原始报文的目的地址。如果Segment Left等于0的话，那么目的地址就在IPV6头的目的地址字段内;如果Segment Left大于0，目的地址就是路由头中的最后一个地址。
　　节点使用Packet Too Big消息中的MTU字段作为试探性MTU(tentative MTU)，将它和目前的PMTU做比较，如果试探性MTU比目前的小，就用试探性MTU替代目前的PMTU。
　　当PMTU减小时，必须通知报文化层。如果PMTU减小了，任何报文化层的实例(例如TCP连接)只要它们还使用该路径，就必须被通知到。需要注意的是，即使Packet Too Big消息包含的原始源报文头中指出报文为UDP报文，也应该通知使用该路径的TCP层。
　　引起Packet Too Big消息的报文发送进程也应该被通知到：它的报文被丢弃了。甚至如果PMTU并没有因为Packet Too Big消息而发生变化，也需要通知发报文进程。因此它需要重传丢弃的数据。此处需要注意的是，应用者可以避免使用这样的异步通知方式，它只需要将通知推迟到下一次发送超过PMTU大小的报文的时候。这样的话，当试图发送一个超过PMTU的报文，发送函数就会失败并且返回一个适当的错误指示。这种方法适合于无连接报文化层(例如使用UDP的应用)，在某些应用中它很难从ICMP层得到通知。这种情况下，正常的超时重传机制将被用于恢复被丢弃的报文。
　　1.3 清除无效的PMTU信息
　　Internet的拓扑结构是动态的，路由也是随着时间变化的，然而路径的本地代表特性(例如目的地址)是不会发生变化的，实际使用的路径却发生了变化。因此，节点缓存的PMTU信息也就变得无效了。
　　当网络发生变化时，如果当前旧的PMTU相对于网络变化后的新PMTU太大时，一旦发送一个足够大(介于旧的PMTU和新的PMTU之间)的报文，那么就会立刻发现PMTU的变化(变小了)。然而，并没有一种机制，用于发现旧的PMTU相对于当前网络状态偏小的机制。因此，应用者应该采用老化缓存的PMTU值，来达到定期清除旧PMTU的目的。当某个PMTU值持续了一段时间(10分钟量级)没有被减小过，就将PMTU的估计值设置为第一跳的MTU值，而且这种变化应该通知到报文化层。这样会引起新一轮的Path MTU发现过程。需要注意的是，应用者应该提供更改超时间隔的方式(包括设置为无限大，当节点认为不可能发现比本地MTU更小的PMTU时，超时间隔就可以设置为无限大)。
　　上层不允许因为PMTU增加而重传数据，因为这类增加PMTU并不意味着丢弃了报文。
　　应用PMTU老化机制的一种方法就是联系PMTU值对应的时间戳字段(timestamp field)。这个字段初始化为保留值，表示PMTU等于第一跳链路MTU。无论什么时候由于Packet Too Big报文引起PMTU减少，timestamp都会被设置为当时的时间。
　　应用者给所有的缓存PMTU值启动定时器驱动的过程，一旦某个时间戳不是保留值而且通过时间戳计算出的保留时间比超时时间间隔要大的话，就需要：
　　将PMTU的值设置为第一跳链路MTU;
　　将时间戳设置为保留值;
　　通知那些使用该路径的报文化层。
　　1.4 TCP层
　　TCP层必须跟随其连接所使用的路径的PMTU变化，它不应该发送过大的报文段(segments)，造成报文(packets)超过PMTU。简单的情况下，可以在每次创建报文段的时候向IP层询问PMTU值，但这样的效率很低。对于许多TCP应用者而言，它们采用慢启动拥塞防止算法(slow start congestion-avoidance algorithm，参考Van Jacobson. Congestion Avoidance and Control. Proc SIGCOMM’88 Symposium on Communications Architectures and Protocols, pages 314-329. Stanford, CA, August, 1988)，还需要计算和缓存许多从PMTU而来的值。这样的话，当PMTU改变时，使用异步通知的方式要更简单一些。
　　TCP应用者必须存储MSS值(从对端获得)，无论PMTU是多少，都不准发送任何超过MSS的报文段。
　　在TCP MSS选项中的值是独立于PMTU的，这个MSS选项值被TCP连接的对端使用(参考RFC 1883)。
　　当接收到Packet Too Big消息时，那就暗示着报文被发送ICMP消息的节点丢弃了。此时，只需要像其它丢弃的报文一样处理这个丢弃的报文就已经足够了：等到重传定时器超时后重新发送报文段。如果PMTU发现过程需要许多步骤来完成全路径检测的话，那么就会将连接延迟几个往返的时间段(指接收到Packet Too Big，然后更改PMTU发送，如此反复多次)。
　　另外，当接收到PMTU变化的通知时，也可以立刻进行重传。但是这种机制仅仅允许在Packet Too Big消息指定的连接上使用。用于重传的报文大小不应该超过新的PMTU。值得注意的是，报文化层不允许响应每个Packet Too Big消息而重传报文段，因为许多超大报文段会引起大量的Packet Too Big消息，如果大家都响应的话就需要重传许多相同的数据。如果新的估计PMTU仍然错误的话，那么过程又重复，多余的报文会以指数形式上涨。这就意味着TCP层必须能够识别出Packet Too Big消息所指示的确实降低的某个PMTU，而该PMTU已经用于在特定连接上发送数据，除此之外，TCP层应该忽略任何其它通知。
　　许多TCP应用结合了拥塞避免和慢启动算法来提高性能，由Packet Too Big消息造成的重传不应该改变拥塞窗口，这与TCP重传定时器超时造成的重传不同。而且，它应该触发慢启动机制(也就是说在双方再次达成共识之前，仅仅有一个报文段需要重传)。
　　众所周知，如果发送者的最大窗口尺寸(这里不是拥塞窗口尺寸，拥塞窗口尺寸总是报文段的整数倍)不是报文段尺寸的整数倍，就会降低TCP性能。在许多系统中(例如那些来源于4.2BSD的系统)，报文段尺寸经常设置为1024octets，最大窗口尺寸通常是1024octets的整数倍，这就缺省的保证了整数倍的关系。如果使用PMTU发现机制的话，报文段尺寸可能就不是最大窗口尺寸的因子了(也就是最大窗口尺寸不是报文段尺寸的整数倍)，这就意味着，TCP层需要根据PMTU变化而改变传输窗口尺寸。最大窗口尺寸应该设置为报文段尺寸的最大倍数，前提是小于等于发送者的缓冲空间大小。
　　1.5 管理接口
　　建议应用者提供一些途径，完成下面的功能：
　　 指定某条路径不执行PMTU发现;
　　改变某路径的PMTU值;
　　改变PMTU信息超时定时器的值。