观看加密视频，请点击

<<IPv6原理和配置（思科IOS版）>>

或发邮件 tony_che@163.com

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

■视频名称:

    <<[IPv6]3-4 IPv6 Traffic Class and Flow Label>>

■所属专辑:

    <<IPv6 Fundamental and Configuration>>

■视频时长:

    20分34秒

■内容简介:

    流标识

    IPv6源结点希望IPv6路由器对一组数据包序列进行特殊处理，那么IPv6源结点可以使用流标识字段来标识这组数据包。这些数据包可能是非默认定义的服务质量的数据包（默认定义的服务质量，是通过Traffic Class表示的），或者是某种实时服务（不值得占用Traffic Class字段，或难以分类的服务）。截止RFC2460发布，IPv6的流标识字段仍处在实验阶段，随着网络对流标识字段功能的需求的变化，流标识的规范也可能随之改变。IPv6主机或路由器如果不支持流标识字段，那么需要用“0”填充该字段，或透明传输该字段（不修改字段），同时不处理该字段的任何数据。

    RFC1809

    Flow Label的优势

    flow label最初是28bit，逐渐修改至rfc2460的20bit。flow label通过伪随机算法生成，介于1至fffff之间。如果一组数据流具有相同的源地址、目的地址、hop-by-hop和routing，那么这组数据流可能共享flow label。即，IPv6结点可以仅通过flow label，不检查其它属性值，即可知道如何处理和转发这组数据流。

    Flow Label的难题

    截止rfc2460发布为止，flow label的功能仍在讨论和实验中，甚至可能随着市场需求的变化而更新。目前flow label功能的部署存在很多问题，其中以下三个问题非常重要：

    (1)什么样的数据包会共享一个flow label？?有人建议每个TCP session使用一个独立的flow label，以争取更好的服务质量。反对者认为这会导致flow label数据库的急剧膨胀。而且，哪应用程序的数据流对应flow label，对应用程序是透明的，因此需要全局管理机构参与其中，类似IANA。

    (2)IPv6结点收到一个flow label不为零的数据包，但是无法识别该flow label，这时IPv6结点应如何处理数据包？?该情况是正常现象，诱因很多。直接丢包并发送ICMP消息是一种方案；忽略flow label也是一种方案。更复杂的解放方案，是研发协议或部署应用来辅助flow label功能。至今为止，该问题没有解决。

    (3)当某个flow label过期，那么如果刷新全网状态？?主流方案有两个，一是源结点显式发送flow label的有效和失效消息；另一是采用计时器机制。这两种方式都需要修改协议并测试，实现难度较大。

    以上三个问题，是rfc1809于1995年总结的，至今均未有合适的解决方案。个人认为原因有二：一是flow label功能是从底层修改现有的网络架构，实现难度大；二是市场需求不旺盛，人们常提及IPv6的地址空间、移动应用和线性高速处理能力，而很少考虑flow label功能。

■Abstract:

    Flow Label

    The 20-bit Flow Label field in the IPv6 header may be used by a source to label sequences of packets for which it requests special handling by the IPv6 routers, such as non-default quality of service or "real-time" service. This aspect of IPv6 is, at the time of writing, still experimental and subject to change as the requirements for flow support in the Internet become clearer. Hosts or routers that do not support the functions of the Flow Label field are required to set the field to zero when originating a packet, pass the field on unchanged when forwarding a packet, and ignore the field when receiving a packet.

    RFC1809

    Brief Description of the Flow Label

    The current draft of the IPv6 specification states that every IPv6 header contains a 24-bit Flow Label. (Originally the specification called for a 28-bit Flow ID field, which included the flow label and a 4-bit priority field. The priority field is now distinct, for reasons discussed at the end of this memo).

    The Flow Label is a pseudo-random number between 1 and FFFFFF (hex) that is unique when combined with the source address. The zero Flow Label is reserved to say that no Flow Label is being used. The
specification requires that a source must not reuse a Flow Label value until all state information for the previous use of the Flow Label has been flushed from all routers in the internet.

    The specification further requires that all datagrams with the same (non-zero) Flow Label must have the same Destination Address, Hop-by-Hop Options header, Routing Header and Source Address contents. The notion is that by simply looking up the Flow Label in a table, the router can decide how to route and forward the datagram without examining the rest of the header.

    Flow Label Issues

    The IPv6 specification originally left open a number of questions, of which these three were among the most important:
    (1)Which datagrams should carry (non-zero) Flow Labels?
    (2)What should a router do if a datagram with a (non-zero) Flow Label arrives and the router has no state for that Flow Label?
    (3)How does an internet flush old Flow Labels?

    This memo summarizes the End-to-End Group's attempts to answer these questions.

    Which Datagrams Should Carry (Non-Zero) Flow Labels?

    Interestingly, this is the problem on which the least progress has been made.

    There were some points of basic agreement. Small exchanges of data should have a zero Flow Label, because it is not worth creating a flow for a few datagrams. Real-time flows must obviously always have a Flow Label, since flows are a primary reason Flow Labels were created. The issue is what to do with peers sending large amounts of best effort traffic (e.g., TCP connections). Some people want all long-term TCP connections to use Flow Labels, others do not.

    The argument in favor of using Flow Labels on individual TCP connections is that even if the source does not request special service, a network provider's routers may be able to recognize a large amount of traffic and use the Flow Label field to establish a special route that gives the TCP connection better service (e.g., lower delay or bigger bandwidth). Another argument is to assist in efficient demux at the receiver (i.e., IP and TCP demuxing could be done once).

    An argument against using Flow Labels in individual TCP connections is that it changes how we handling route caches in routers. Currently one can cache a route for a destination host, regardless of how many different sources are sending to that destination host. I.e., if five sources each have two TCP connections sending data to a server, one cache entry containing the route to the server handles all ten TCPs' traffic. Putting Flow Labels in each datagram changes the cache into a Flow Label cache, in which there is a cache entry for every TCP connection. So there's a potential for cache explosion. There are ways to alleviate this problem, such as managing the Flow Label cache as an LRU cache, in which infrequently used Flow Labels get discarded (and then recovered later). It is not clear, however, whether this will cause cache thrashing.

    Observe that there is no easy compromise between these positions. One cannot, for instance, let the application decide whether to use a Flow Label. Those who want different Flow Labels for every TCP connection assume that they may optimize a route without the application's knowledge. And forcing all applications to use Flow Labels will force routing vendors to deal with the cache explosion issue, even if we later discover that we don't want to optimize individual TCP connections.

    What Does a Router Do With Flow Labels for Which It Has No State?

    If a datagram with a non-zero Flow Label arrives at a router and the router discovers it has no state information for that Flow Label, what is the correct thing for the router to do?

    The IPv6 specification allows routers to ignore Flow Labels and also allows for the possibility that IPv6 datagrams may carry flow setup information in their options. Unknown Flow Labels may also occur if a router crashes and loses its state. During a recovery period, the router will receive datagrams with Flow Labels it does not know, but this is arguably not an error, but rather a part of the recovery period. Finally, if the controversial suggestion that each TCP connection be assigned a separate Flow Label is adopted, it may be necessary to manage Flow Labels using an LRU cache (to avoid Flow Label cache overflow in routers), in which case an active but infrequently used flow's state may have been intentionally discarded.

    In any case, it is clear that treating this situation as an error and, say dropping the datagram and sending an ICMP message, is inappropriate. Indeed, it seems likely that in most cases, simply forwarding the datagram as one would a datagram with a zero Flow Label would give better service to the flow than dropping the datagram.

    Of course, there will be situations in which routing the datagram as if its Flow Label were zero will cause the wrong result. An example is a router which has two paths to the datagram's destination, one via a high-bandwidth satellite link and the other via a low-bandwidth terrestrial link. A high bandwidth flow obviously should be routed via the high-bandwidth link, but if the router loses the flow state, the router may route the traffic via the low-bandwidth link, with the potential for the flow's traffic to swamp the low-bandwidth link. It seems likely, however, these situations will be exceptions rather than the rule. So it seems reasonable to handle these situations using options that indicate that if the flow state is absent, the datagram needs special handling. (The options may be Hop-by-Hop or only handled at some routers, depending on the flow's needs).

    It would clearly be desirable to have some method for signalling to end systems that the flow state has been lost and needs to be refreshed. One possibility is to add a state-lost bit to the Flow Label field, however there is sensitivity to eating into the precious 24-bits of the field. Other possibilities include adding options to the datagram to indicate its Flow Label was unknown or sending an ICMP message back to the flow source.

    In summary, the view is that the default rule should be that if a router receives a datagram with an unknown Flow Label, it treats the datagram as if the Flow Label is zero. As part of forwarding, the router will examine any hop-by-hop options and learn if the the datagram requires special handling. The options could include simply the information that the datagram is to be dropped if the Flow Label is unknown or could contain the flow state the router should have. There is clearly room here for experimentation with option design.

    Flushing Old Flow Labels

    The flow mechanism assumes that state associated with a given Flow Label is somehow deposited in routers, so they know how to handle datagrams that carry the Flow Label. A serious problem is how to flush Flow Labels that are no longer being used (stale Flow Labels) from the routers.

    Stale Flow Labels can happen a number of ways, even if we assume that the source always sends a message deleting a Flow Label when the source finishes using a Flow. An internet may have partioned since the flow was created. Or the deletion message may be lost before reaching all routers. Furthermore, the source may crash before it can send out a Flow Label deletion message. The point here is that we cannot expect the source (or, for the same reasons, a third party) always to clear out stale Flow Labels. Rather, routers will have to find some mechanism to flush Flow Labels themselves.

    The obvious mechanism is to use a timer. Routers should discard Flow Labels whose state has not been refreshed within some period of time. At the same time, a source that crashes must observe a quiet time, during which it creates no flows, until it knows that all Flow Labels from its previous life must have expired. (Sources can avoid quiet time restrictions by keeping information about active Flow Labels in stable storage that survives crashes). This is precisely how TCP initial sequence numbers are managed and it seems the same mechanism should work well for Flow Labels.

    Exactly how the Flow Label and its state should be refreshed needs some study. There are two obvious options. The source could periodically send out a special refresh message (such as an RSVP Path message) to explicitly refresh the Flow Label and its state. Or, the router could treat every datagram that carries the Flow Label as an implicit refresh or sources could send explicit refresh options. The choice is between periodically handling a special update message and doing an extra computation on each datagram (namely noting in the Flow Label's entry that the Flow Label has been refreshed).