Internet Engineering Task Force (IETF) B. Carpenter
Request for Comments: 6438 Univ. of Auckland
Category: Standards Track S. Amante
ISSN: 2070-1721 Level 3
November 2011
Internet Engineering Task Force (IETF) B. Carpenter
Request for Comments: 6438 Univ. of Auckland
Category: Standards Track S. Amante
ISSN: 2070-1721 Level 3
November 2011
Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels
在隧道中使用IPv6流标签进行等成本多路径路由和链路聚合
Abstract
摘要
The IPv6 flow label has certain restrictions on its use. This document describes how those restrictions apply when using the flow label for load balancing by equal cost multipath routing and for link aggregation, particularly for IP-in-IPv6 tunneled traffic.
IPv6流标签对其使用有一定的限制。本文档描述了当使用流标签通过等成本多路径路由进行负载平衡和链路聚合时，这些限制是如何应用的，特别是对于IPv6隧道中的IP流量。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6438.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6438.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Choice of IP Header Fields for Hash Input . . . . . . . . . 3
1.2. Flow Label Rules . . . . . . . . . . . . . . . . . . . . . 4
2. Normative Notation . . . . . . . . . . . . . . . . . . . . . . 5
3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Choice of IP Header Fields for Hash Input . . . . . . . . . 3
1.2. Flow Label Rules . . . . . . . . . . . . . . . . . . . . . 4
2. Normative Notation . . . . . . . . . . . . . . . . . . . . . . 5
3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . . 8
When several network paths between the same two nodes are known by the routing system to be equally good (in terms of capacity and latency), it may be desirable to share traffic among them. Two such techniques are known as equal cost multipath (ECMP) routing and link aggregation (LAG) [IEEE802.1AX]. There are, of course, numerous possible approaches to this, but certain goals need to be met:
当路由系统知道相同两个节点之间的多条网络路径同样良好（在容量和延迟方面）时，可能需要在它们之间共享流量。这两种技术被称为等成本多路径（ECMP）路由和链路聚合（LAG）[IEEE802.1AX]。当然，有许多可能的方法来实现这一点，但需要实现某些目标：
o Maintain roughly equal share of traffic on each path. (In some cases, the multiple paths might not all have the same capacity, and the goal might be appropriately weighted traffic shares rather than equal shares. This would affect the load-sharing algorithm but would not otherwise change the argument.)
o 在每条路径上保持大致相等的流量份额。（在某些情况下，多条路径可能不具有相同的容量，目标可能是适当加权的流量共享，而不是相等的共享。这将影响负载共享算法，但不会改变参数。）
o Minimize or avoid out-of-order delivery for individual traffic flows.
o 尽量减少或避免单个交通流的无序交付。
o Minimize idle time on any path when queue is non-empty.
o 当队列非空时，最小化任何路径上的空闲时间。
There is some conflict between these goals: for example, strictly avoiding idle time could cause a small packet sent on an idle path to overtake a bigger packet from the same flow, causing out-of-order delivery.
这些目标之间存在一些冲突：例如，严格避免空闲时间可能会导致在空闲路径上发送的小数据包超过同一流中的大数据包，从而导致无序交付。
One lightweight approach to ECMP or LAG is this: if there are N equally good paths to choose from, then form a modulo(N) hash [RFC2991] from a defined set of fields in each packet header that are certain to have the same values throughout the duration of a flow, and use the resulting output hash value to select a particular path. If the hash function is chosen so that the output values have a uniform statistical distribution, this method will share traffic roughly equally between the N paths. If the header fields included in the hash input are consistent, all packets from a given flow will generate the same hash output value, so out-of-order delivery will
ECMP或LAG的一种轻量级方法是：如果有N个同样好的路径可供选择，则从每个数据包头中定义的字段集合中形成一个模（N）散列[RFC2991]，这些字段肯定在流的整个持续时间内具有相同的值，并使用结果输出散列值来选择特定路径。如果选择哈希函数，使输出值具有统一的统计分布，则此方法将在N条路径之间大致平均地共享流量。如果散列输入中包含的头字段是一致的，那么来自给定流的所有数据包都将生成相同的散列输出值，因此无序传递将被忽略
not occur. Assuming a large number of unique flows are involved, it is also probable that the method will avoid idle time, since the queue for each link will remain non-empty.
不会发生。假设涉及大量唯一流，该方法也可能避免空闲时间，因为每个链路的队列将保持非空。
In the remainder of this document, we will use the term "flow" to represent a sequence of packets that may be identified by either the source and destination IP addresses alone {2-tuple} or the source IP address, destination IP address, protocol number, source port number, and destination port number {5-tuple}. It should be noted that the latter is more specifically referred to as a "microflow" in [RFC2474], but this term is not used in connection with the flow label in [RFC3697].
在本文档的其余部分中，我们将使用术语“流”来表示数据包序列，这些数据包可以仅由源和目标IP地址{2-tuple}或源IP地址、目标IP地址、协议号、源端口号和目标端口号{5-tuple}标识。应注意，后者在[RFC2474]中更具体地称为“微流”，但该术语未与[RFC3697]中的流量标签结合使用。
The question, then, is which header fields are used to identify a flow and serve as input keys to a modulo(N) hash algorithm. A common choice when routing general traffic is simply to use a hash of the source and destination IP addresses, i.e., the 2-tuple. This is necessary and sufficient to avoid out-of-order delivery and, with a wide variety of sources and destinations as one finds in the core of the network, often statistically sufficient to distribute the load evenly. In practice, many implementations use the 5-tuple {dest addr, source addr, protocol, dest port, source port} as input keys to the hash function, to maximize the probability of evenly sharing traffic over the equal cost paths. However, including transport-layer information as input keys to a hash may be a problem for IP fragments [RFC2991] or for encrypted traffic. Including the protocol and port numbers, totaling 40 bits, in the hash input makes the hash slightly more expensive to compute but does improve the hash distribution, due to the variable nature of ephemeral ports. Ephemeral port numbers are quite well distributed [Lee10] and will typically contribute 16 variable bits. However, in the case of IPv6, transport-layer information is inconvenient to extract, due to the variable placement of and variable length of next-headers; all implementations must be capable of skipping over next-headers, even if they are rarely present in actual traffic. In fact, [RFC2460] implies that next-headers, except hop-by-hop options, are not normally inspected by intermediate nodes in the network. This situation may be challenging for some hardware implementations, raising the potential that network equipment vendors might sacrifice the length of the fields extracted from an IPv6 header.
那么，问题是哪些头字段用于标识流并用作模（N）散列算法的输入键。在路由一般流量时，一个常见的选择是简单地使用源和目标IP地址的散列，即2元组。这对于避免无序交付是必要且充分的，并且，对于网络核心中的各种来源和目的地，通常在统计上足以均匀分配负载。实际上，许多实现使用5元组{dest addr，source addr，protocol，dest port，source port}作为散列函数的输入键，以最大限度地提高在等成本路径上均匀共享流量的概率。然而，对于IP片段[RFC2991]或加密的通信量来说，将传输层信息作为散列的输入密钥可能是一个问题。在散列输入中包括协议和端口号（总计40位），使得散列的计算成本稍高，但由于临时端口的可变性质，确实改善了散列分布。临时端口号分布非常均匀[Lee10]，通常会贡献16个可变位。然而，在IPv6的情况下，由于下一个报头的位置和长度可变，传输层信息不便于提取；所有实现都必须能够跳过下一个报头，即使它们很少出现在实际流量中。事实上，[RFC2460]意味着下一个报头（逐跳选项除外）通常不会被网络中的中间节点检查。这种情况对于某些硬件实现来说可能具有挑战性，这增加了网络设备供应商可能牺牲从IPv6报头提取的字段长度的可能性。
It is worth noting that the possible presence of a Generic Routing Encapsulation (GRE) header [RFC2784] and the possible presence of a GRE key within that header creates a similar challenge to the possible presence of IPv6 extension headers; anything that complicates header analysis is undesirable.
值得注意的是，可能存在的通用路由封装（GRE）报头[RFC2784]以及该报头内可能存在的GRE密钥对可能存在的IPv6扩展报头产生了类似的挑战；任何使标头分析复杂化的操作都是不可取的。
The situation is different in IP-in-IP tunneled scenarios. Identifying a flow inside the tunnel is more complicated, particularly because nearly all hardware can only identify flows based on information contained in the outermost IP header. Assume that traffic from many sources to many destinations is aggregated in a single IP-in-IP tunnel from tunnel endpoint (TEP) A to TEP B (see figure). Then all the packets forming the tunnel have outer source address A and outer destination address B. In all probability, they also have the same port and protocol numbers. If there are multiple paths between routers R1 and R2, and ECMP or LAG is applied to choose a particular path, the 2-tuple or 5-tuple (and its hash) will be constant, and no load sharing will be achieved, i.e., polarization will occur. If there is a high proportion of traffic from one or a small number of tunnels, traffic will not be distributed as intended across the paths between R1 and R2, due to partial polarization. (Related issues arise with MPLS [MPLS-LABEL].)
在IP隧道方案中，IP的情况有所不同。识别隧道内的流更为复杂，特别是因为几乎所有硬件都只能基于最外层IP报头中包含的信息来识别流。假设从多个源到多个目的地的流量聚合在从隧道端点（TEP）a到TEP B的单个IP-in-IP隧道中（见图）。然后，构成隧道的所有数据包都具有外部源地址A和外部目标地址B。在所有可能性中，它们也具有相同的端口号和协议号。如果路由器R1和R2之间存在多条路径，并且应用ECMP或LAG来选择特定路径，则2元组或5元组（及其散列）将保持不变，并且不会实现负载共享，即，将发生极化。如果来自一条或少量隧道的交通量比例较高，则由于部分极化，交通量不会按预期分布在R1和R2之间的路径上。（MPLS[MPLS-LABEL]会产生相关问题。）
_____ _____ _____ _____
| TEP |_________| R1 |-------------| R2 |_________| TEP |
|__A__| |_____|-------------|_____| |__B__|
tunnel ECMP or LAG tunnel
here
_____ _____ _____ _____
| TEP |_________| R1 |-------------| R2 |_________| TEP |
|__A__| |_____|-------------|_____| |__B__|
tunnel ECMP or LAG tunnel
here
As noted above, for IPv6, the 5-tuple is quite inconvenient to extract due to the next-header placement. The question therefore arises whether the 20-bit flow label in IPv6 packets would be suitable for use as input to an ECMP or LAG hash algorithm, especially in the case of tunnels where the inner packet header is inaccessible. If the flow label could be used in place of the port numbers and protocol number in the 5-tuple, the implementation would be simplified.
如上所述，对于IPv6，由于下一个报头的位置，5元组的提取非常不方便。因此，问题在于IPv6数据包中的20位流标签是否适合用作ECMP或滞后哈希算法的输入，特别是在无法访问内部数据包报头的隧道的情况下。如果可以使用流标签来代替5元组中的端口号和协议号，那么实现将会简化。
The flow label was left Experimental by [RFC2460] but was better defined by [RFC3697]. We quote three rules from that RFC:
[RFC2460]对流量标签进行了实验，但[RFC3697]对流量标签进行了更好的定义。我们引用了RFC中的三条规则：
1. "The Flow Label value set by the source MUST be delivered unchanged to the destination node(s)."
1. “源设置的流标签值必须原封不动地传递到目标节点。”
2. "IPv6 nodes MUST NOT assume any mathematical or other properties of the Flow Label values assigned by source nodes."
2. “IPv6节点不得采用源节点分配的流标签值的任何数学或其他属性。”
3. "Router performance SHOULD NOT be dependent on the distribution of the Flow Label values. Especially, the Flow Label bits alone make poor material for a hash key."
3. 路由器的性能不应依赖于流标签值的分布。尤其是，流标签位本身对散列键的影响很差
These rules, especially the last one, have caused designers to hesitate about using the flow label in support of ECMP or LAG. The fact is that today most nodes set a zero value in the flow label, and the first rule definitely forbids the routing system from changing the flow label once a packet has left the source node. Considering normal IPv6 traffic, the fact that the flow label is typically zero means that it would add no value to an ECMP or LAG hash, but neither would it do any harm to the distribution of the hash values.
这些规则，尤其是最后一条规则，导致设计师在使用流标签支持ECMP或LAG时犹豫不决。事实上，今天大多数节点在流标签中设置了零值，第一条规则明确禁止路由系统在数据包离开源节点后更改流标签。考虑到正常的IPv6流量，流标签通常为零这一事实意味着它不会向ECMP或延迟哈希添加任何值，但也不会对哈希值的分布造成任何损害。
However, in the case of an IP-in-IPv6 tunnel, the TEP is itself the source node of the outer packets. Therefore, a TEP may freely set a flow label in the outer IPv6 header of the packets it sends into the tunnel.
然而，对于IPv6隧道中的IP，TEP本身就是外部数据包的源节点。因此，TEP可以在其发送到隧道中的数据包的外部IPv6报头中自由设置流标签。
The second two rules quoted above need to be seen in the context of [RFC3697], which assumes that routers using the flow label in some way will be involved in some sort of method of establishing flow state: "To enable flow-specific treatment, flow state needs to be established on all or a subset of the IPv6 nodes on the path from the source to the destination(s)." The RFC should perhaps have made clear that a router that has participated in flow state establishment can rely on properties of the resulting flow label values without further signaling. If a router knows these properties, rule 2 is irrelevant, and it can choose to deviate from rule 3.
需要在[RFC3697]的上下文中查看上面引用的第二个两条规则，其中假设以某种方式使用流标签的路由器将参与某种建立流状态的方法：“要启用特定于流的处理，需要在从源到目标的路径上的所有或部分IPv6节点上建立流状态。“RFC也许应该清楚地表明，参与流状态建立的路由器可以依赖结果流标签值的属性，而无需进一步信令。如果路由器知道这些属性，那么规则2是不相关的，它可以选择偏离规则3。
In the tunneling situation sketched above, routers R1 and R2 can rely on the flow labels set by TEP A and TEP B being assigned by a known method. This allows an ECMP or LAG method to be based on the flow label consistently with [RFC3697], regardless of whether the non-tunnel traffic carries non-zero flow label values.
在上面描述的隧道情况下，路由器R1和R2可以依赖由TEP A和TEP B设置的流标签，并通过已知的方法进行分配。这允许ECMP或LAG方法基于与[RFC3697]一致的流量标签，而不管非隧道交通是否携带非零流量标签值。
The IETF has recently revised RFC 3697 [RFC6437]. That revision is fully compatible with the present document and obviates the concerns resulting from the above three rules. Therefore, the present specification applies both to RFC 3697 and to RFC 6437.
IETF最近修订了RFC 3697[RFC6437]。这一修订完全符合本文件，消除了上述三条规则引起的关切。因此，本规范适用于RFC 3697和RFC 6437。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
We assume that the routers supporting ECMP or LAG (R1 and R2 in the above figure) are unaware that they are handling tunneled traffic. If it is desired to include the IPv6 flow label in an ECMP or LAG hash in the tunneled scenario shown above, the following guidelines apply:
我们假设支持ECMP或LAG（上图中的R1和R2）的路由器不知道它们正在处理隧道流量。如果希望在如上所示的隧道场景中的ECMP或延迟哈希中包含IPv6流标签，则适用以下准则：
o Inner packets MUST be encapsulated in an outer IPv6 packet whose source and destination addresses are those of the tunnel endpoints (TEPs).
o 内部数据包必须封装在外部IPv6数据包中，该数据包的源地址和目标地址都是隧道端点（TEP）的地址。
o The flow label in the outer packet SHOULD be set by the sending TEP to a 20-bit value in accordance with [RFC6437]. The same flow label value MUST be used for all packets in a single user flow, as determined by the IP header fields of the inner packet.
o 发送TEP应根据[RFC6437]将外部数据包中的流标签设置为20位值。同一个流标签值必须用于单个用户流中的所有数据包，由内部数据包的IP头字段确定。
o To achieve this, the sending TEP MUST classify all packets into flows once it has determined that they should enter a given tunnel and then write the relevant flow label into the outer IPv6 header. A user flow could be identified by the sending TEP most simply by its {destination, source} address 2-tuple or by its 5-tuple {dest addr, source addr, protocol, dest port, source port}. At present, there would be little point in using the {dest addr, source addr, flow label} 3-tuple of the inner packet, but doing so would be a future-proof option. The choice of n-tuple is an implementation choice in the sending TEP.
o 要实现这一点，发送TEP必须在确定所有数据包应进入给定隧道后将其分类为流，然后将相关流标签写入外部IPv6报头。用户流可以通过发送TEP识别，最简单的方法是通过其{destination，source}地址2元组或其5元组{dest addr，source addr，protocol，dest port，source port}。目前，使用内部数据包的{dest addr，source addr，flow label}3元组没有什么意义，但这样做将是一个未来的选择。n元组的选择是发送TEP中的实现选择。
* As specified in [RFC6437], the flow label values should be chosen from a uniform distribution. Such values will be suitable as input to a load-balancing hash function and will be hard for a malicious third party to predict.
* 如[RFC6437]所述，流量标签值应从均匀分布中选择。这些值适合作为负载平衡哈希函数的输入，恶意第三方很难预测。
* The sending TEP MAY perform stateless flow label assignment by using a suitable 20-bit hash of the inner IP header's 2-tuple or 5-tuple as the flow label value.
* 发送TEP可以通过使用内部IP报头的2元组或5元组的合适的20位散列作为流标签值来执行无状态流标签分配。
* If the inner packet is an IPv6 packet, its flow label value could also be included in this hash.
* 如果内部数据包是IPv6数据包，则其流标签值也可以包含在此哈希中。
* This stateless method creates a small probability of two different user flows hashing to the same flow label. Since [RFC6437] allows a source (the TEP in this case) to define any set of packets that it wishes as a single flow, occasionally labeling two user flows as a single flow through the tunnel is acceptable.
* 此无状态方法创建两个不同用户流散列到同一流标签的小概率。由于[RFC6437]允许源（在本例中为TEP）定义它希望作为单个流的任何数据包集，因此偶尔将两个用户流标记为通过隧道的单个流是可以接受的。
o At intermediate routers that perform load distribution, the hash algorithm used to determine the outgoing component-link in an ECMP and/or LAG toward the next hop MUST minimally include the 3-tuple {dest addr, source addr, flow label} and MAY also include the remaining components of the 5-tuple. This applies whether the traffic is tunneled traffic only or a mixture of normal traffic and tunneled traffic.
o 在执行负载分配的中间路由器上，用于确定ECMP中的传出组件链路和/或延迟到下一跳的哈希算法必须至少包括3元组{dest addr，source addr，flow label}，并且还可以包括5元组的其余组件。无论通信量是仅隧道通信量还是正常通信量和隧道通信量的混合，这都适用。
* Intermediate IPv6 router(s) will presumably encounter a mixture of tunneled traffic and normal IPv6 traffic. Because of this, the design should also include {protocol, dest port, source port} as input keys to the ECMP and/or LAG hash algorithms, to provide additional entropy for flows whose flow label is set to zero, including non-tunneled traffic flows.
* 中间IPv6路由器可能会遇到隧道流量和正常IPv6流量的混合。因此，设计还应包括{protocol，dest port，source port}作为ECMP和/或滞后散列算法的输入键，为流标签设置为零的流（包括非隧道流量流）提供额外的熵。
o Individual nodes in a network are free to implement different algorithms that conform to this specification without impacting the interoperability or function of the network.
o 网络中的各个节点可以自由实施符合本规范的不同算法，而不会影响网络的互操作性或功能。
o Operations, Administration, and Maintenance (OAM) techniques will need to be adapted to manage ECMP and LAG based on the flow label. The issues will be similar to those that arise for MPLS [RFC4379] and pseudowires [RFC6391].
o 操作、管理和维护（OAM）技术需要根据流量标签进行调整，以管理ECMP和LAG。这些问题与MPLS[RFC4379]和伪线[RFC6391]出现的问题类似。
The flow label is not protected in any way and can be forged by an on-path attacker. However, it is expected that tunnel endpoints and the ECMP or LAG paths will be part of a managed infrastructure that is well protected against on-path attacks (e.g., by using IPsec between the two tunnel endpoints). Off-path attackers are unlikely to guess a valid flow label if an apparently pseudo-random and unpredictable value is used. In either case, the worst an attacker could do against ECMP or LAG is attempt to selectively overload a particular path. For further discussion, see [RFC6437].
流标签不受任何保护，可由路径上的攻击者伪造。但是，预计隧道端点和ECMP或LAG路径将是受管基础设施的一部分，该基础设施可以很好地抵御路径攻击（例如，通过在两个隧道端点之间使用IPsec）。如果使用了明显的伪随机和不可预测的值，则非路径攻击者不太可能猜到有效的流标签。在这两种情况下，攻击者针对ECMP或LAG所能做的最糟糕的事情就是有选择地重载特定路径。有关进一步讨论，请参阅[RFC6437]。
This document was suggested by corridor discussions at IETF 76. Joel Halpern made crucial comments on an early version. We are grateful to Qinwen Hu for general discussion about the flow label. Valuable comments and contributions were made by Miguel Garcia, Brian Haberman, Sheng Jiang, Thomas Narten, Jarno Rajahalme, Brian Weis, and others.
本文件由IETF 76上的走廊讨论提出。Joel Halpern对早期版本发表了重要评论。我们感谢胡勤文对流量标签的一般性讨论。米格尔·加西亚、布赖恩·哈伯曼、盛江、托马斯·纳滕、贾诺·拉贾哈尔梅、布赖恩·韦斯和其他人发表了宝贵的评论和贡献。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004.
[RFC3697]Rajahalme，J.，Conta，A.，Carpenter，B.，和S.Deering，“IPv6流标签规范”，RFC 36972004年3月。
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, November 2011.
[RFC6437]Amante，S.，Carpenter，B.，Jiang，S.，和J.Rajahalme，“IPv6流标签规范”，RFC 6437，2011年11月。
[IEEE802.1AX] Institute of Electrical and Electronics Engineers, "Link Aggregation", IEEE Standard 802.1AX-2008, 2008.
[IEEE802.1AX]电气和电子工程师协会，“链路聚合”，IEEE标准802.1AX-2008，2008年。
[Lee10] Lee, D., Carpenter, B., and N. Brownlee, "Observations of UDP to TCP Ratio and Port Numbers", Fifth International Conference on Internet Monitoring and Protection ICIMP 2010, May 2010.
[Lee10]Lee，D.，Carpenter，B.，和N.Brownlee，“UDP与TCP比率和端口号的观察”，第五届互联网监测和保护国际会议ICIMP 2010，2010年5月。
[MPLS-LABEL] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", Work in Progress, May 2011.
[MPLS-LABEL]Kompella，K.，Drake，J.，Amante，S.，Henderickx，W.，和L.Yong，“MPLS转发中熵标签的使用”，正在进行的工作，2011年5月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Traina，“通用路由封装（GRE）”，RFC 27842000年3月。
[RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, November 2000.
[RFC2991]Thaler，D.和C.Hopps，“单播和多播下一跳选择中的多路径问题”，RFC 29912000年11月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379]Kompella，K.和G.Swallow，“检测多协议标签交换（MPLS）数据平面故障”，RFC 4379，2006年2月。
[RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, J., and S. Amante, "Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network", RFC 6391, November 2011.
[RFC6391]Bryant，S.，Filsfils，C.，Drafz，U.，Kompella，V.，Regan，J.，和S.Amante，“MPLS分组交换网络上伪线的流感知传输”，RFC 63912011年11月。
Authors' Addresses
作者地址
Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand
Brian Carpenter奥克兰大学计算机系，奥克兰92019，新西兰1142
EMail: brian.e.carpenter@gmail.com
EMail: brian.e.carpenter@gmail.com
Shane Amante Level 3 Communications, LLC 1025 Eldorado Blvd Broomfield, CO 80021 USA
美国科罗拉多州布鲁姆菲尔德埃尔多拉多大道1025号Shane Amante三级通信有限责任公司，邮编80021
EMail: shane@level3.net
EMail: shane@level3.net