Internet Engineering Task Force (IETF) K. Kompella
Request for Comments: 6790 J. Drake
Updates: 3031, 3107, 3209, 5036 Juniper Networks
Category: Standards Track S. Amante
ISSN: 2070-1721 Level 3 Communications, Inc.
W. Henderickx
Alcatel-Lucent
L. Yong
Huawei USA
November 2012
Internet Engineering Task Force (IETF) K. Kompella
Request for Comments: 6790 J. Drake
Updates: 3031, 3107, 3209, 5036 Juniper Networks
Category: Standards Track S. Amante
ISSN: 2070-1721 Level 3 Communications, Inc.
W. Henderickx
Alcatel-Lucent
L. Yong
Huawei USA
November 2012
The Use of Entropy Labels in MPLS Forwarding
熵标签在MPLS转发中的应用
Abstract
摘要
Load balancing is a powerful tool for engineering traffic across a network. This memo suggests ways of improving load balancing across MPLS networks using the concept of "entropy labels". It defines the concept, describes why entropy labels are useful, enumerates properties of entropy labels that allow maximal benefit, and shows how they can be signaled and used for various applications. This document updates RFCs 3031, 3107, 3209, and 5036.
负载平衡是一个强大的工具，用于在网络上设计流量。这份备忘录提出了使用“熵标签”概念改善MPLS网络负载平衡的方法。它定义了这个概念，描述了熵标签为什么有用，列举了熵标签的属性，这些属性可以带来最大的好处，并展示了它们如何被标记和用于各种应用。本文档更新了RFCs 3031、3107、3209和5036。
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/rfc6790.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6790.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您在以下方面的权利和限制：
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.
请参阅本文件。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Conventions Used ...........................................4
1.2. Motivation .................................................6
2. Approaches ......................................................7
3. Entropy Labels and Their Structure ..............................8
4. Data Plane Processing of Entropy Labels .........................9
4.1. Egress LSR .................................................9
4.2. Ingress LSR ...............................................10
4.3. Transit LSR ...............................................11
4.4. Penultimate Hop LSR .......................................12
5. Signaling for Entropy Labels ...................................12
5.1. LDP Signaling .............................................12
5.1.1. Processing the ELC TLV .............................13
5.2. BGP Signaling .............................................13
5.3. RSVP-TE Signaling .........................................14
5.4. Multicast LSPs and Entropy Labels .........................15
6. Operations, Administration, and Maintenance (OAM) and
Entropy Labels .................................................15
7. MPLS-TP and Entropy Labels .....................................16
8. Entropy Labels in Various Scenarios ............................16
8.1. LDP Tunnel ................................................17
8.2. LDP over RSVP-TE ..........................................20
8.3. MPLS Applications .........................................20
9. Security Considerations ........................................20
10. IANA Considerations ...........................................21
10.1. Reserved Label for ELI ...................................21
10.2. LDP Entropy Label Capability TLV .........................21
10.3. BGP Entropy Label Capability Attribute ...................21
10.4. RSVP-TE Entropy Label Capability Flag ....................22
11. Acknowledgments ...............................................22
12. References ....................................................22
12.1. Normative References .....................................22
12.2. Informative References ...................................23
Appendix A. Applicability of LDP Entropy Label Capability TLV .....24
1. Introduction ....................................................3
1.1. Conventions Used ...........................................4
1.2. Motivation .................................................6
2. Approaches ......................................................7
3. Entropy Labels and Their Structure ..............................8
4. Data Plane Processing of Entropy Labels .........................9
4.1. Egress LSR .................................................9
4.2. Ingress LSR ...............................................10
4.3. Transit LSR ...............................................11
4.4. Penultimate Hop LSR .......................................12
5. Signaling for Entropy Labels ...................................12
5.1. LDP Signaling .............................................12
5.1.1. Processing the ELC TLV .............................13
5.2. BGP Signaling .............................................13
5.3. RSVP-TE Signaling .........................................14
5.4. Multicast LSPs and Entropy Labels .........................15
6. Operations, Administration, and Maintenance (OAM) and
Entropy Labels .................................................15
7. MPLS-TP and Entropy Labels .....................................16
8. Entropy Labels in Various Scenarios ............................16
8.1. LDP Tunnel ................................................17
8.2. LDP over RSVP-TE ..........................................20
8.3. MPLS Applications .........................................20
9. Security Considerations ........................................20
10. IANA Considerations ...........................................21
10.1. Reserved Label for ELI ...................................21
10.2. LDP Entropy Label Capability TLV .........................21
10.3. BGP Entropy Label Capability Attribute ...................21
10.4. RSVP-TE Entropy Label Capability Flag ....................22
11. Acknowledgments ...............................................22
12. References ....................................................22
12.1. Normative References .....................................22
12.2. Informative References ...................................23
Appendix A. Applicability of LDP Entropy Label Capability TLV .....24
Load balancing, or multi-pathing, is an attempt to balance traffic across a network by allowing the traffic to use multiple paths. Load balancing has several benefits: it eases capacity planning, it can help absorb traffic surges by spreading them across multiple paths, and it allows better resilience by offering alternate paths in the event of a link or node failure.
负载平衡，或多路径，是通过允许流量使用多条路径来平衡网络流量的一种尝试。负载平衡有几个好处：它简化了容量规划，可以通过将流量激增分散到多条路径来帮助吸收流量激增，还可以通过在链路或节点发生故障时提供备用路径来实现更好的恢复能力。
As providers scale their networks, they use several techniques to achieve greater bandwidth between nodes. Two widely used techniques are: Link Aggregation Group (LAG) and Equal Cost Multi-Path (ECMP). LAG is used to bond together several physical circuits between two adjacent nodes so they appear to higher-layer protocols as a single, higher-bandwidth "virtual" pipe. ECMP is used between two nodes separated by one or more hops, to allow load balancing over several shortest paths in the network. This is typically obtained by arranging IGP metrics such that there are several equal cost paths between source-destination pairs. Both of these techniques may, and often do, coexist in differing parts of a given provider's network, depending on various choices made by the provider.
随着提供商扩展其网络，他们使用多种技术来实现节点之间更大的带宽。两种广泛使用的技术是：链路聚合组（LAG）和等成本多路径（ECMP）。LAG用于将两个相邻节点之间的多个物理电路连接在一起，以便它们在高层协议中显示为单个、更高带宽的“虚拟”管道。ECMP用于由一个或多个跃点分隔的两个节点之间，以允许在网络中的多个最短路径上进行负载平衡。这通常是通过安排IGP度量来实现的，这样在源-目的地对之间就有几个相同的成本路径。这两种技术可能，而且通常在给定提供商网络的不同部分共存，这取决于提供商做出的各种选择。
A very important requirement when load balancing is that packets belonging to a given "flow" must be mapped to the same path, i.e., the same exact sequence of links across the network. This is to avoid jitter, latency, and reordering issues for the flow. What constitutes a flow varies considerably. A common example of a flow is a TCP session. Other examples are a Layer 2 Tunneling Protocol (L2TP) session corresponding to a given broadband user or traffic within an ATM virtual circuit.
负载平衡时的一个非常重要的要求是，属于给定“流”的数据包必须映射到相同的路径，即网络中相同的链路精确序列。这是为了避免流的抖动、延迟和重新排序问题。构成流量的内容差别很大。流的一个常见示例是TCP会话。其他示例是与给定宽带用户或ATM虚拟电路内的业务相对应的第2层隧道协议（L2TP）会话。
To meet this requirement, a node uses certain fields, termed "keys", within a packet's header as input to a load-balancing function (typically a hash function) that selects the path for all packets in a given flow. The keys chosen for the load-balancing function depend on the packet type; a typical set (for IP packets) is the IP source and destination addresses, the protocol type, and (for TCP and UDP traffic) the source and destination port numbers. An overly conservative choice of fields may lead to many flows mapping to the same hash value (and consequently poorer load balancing); an overly aggressive choice may map a flow to multiple values, potentially violating the above requirement.
为了满足这一要求，节点使用数据包报头中的某些字段（称为“键”）作为负载平衡函数（通常是哈希函数）的输入，该函数为给定流中的所有数据包选择路径。为负载平衡功能选择的密钥取决于数据包类型；典型的一组（对于IP数据包）是IP源和目标地址、协议类型以及（对于TCP和UDP通信）源和目标端口号。字段的过度保守选择可能会导致许多流映射到相同的哈希值（从而导致较差的负载平衡）；过度激进的选择可能会将流映射到多个值，从而可能违反上述要求。
For MPLS networks, most of the same principles (and benefits) apply. However, finding useful keys in a packet for the purpose of load balancing can be more of a challenge. In many cases, MPLS encapsulation may require fairly deep inspection of packets to find these keys at transit Label Switching Routers (LSRs).
对于MPLS网络，大多数相同的原则（和好处）都适用。然而，为了负载平衡的目的在数据包中找到有用的密钥可能更具挑战性。在许多情况下，MPLS封装可能需要对数据包进行相当深入的检查，以便在传输标签交换路由器（LSR）上找到这些密钥。
One way to eliminate the need for this deep inspection is to have the ingress LSR of an MPLS Label Switched Path extract the appropriate keys from a given packet, input them to its load-balancing function, and place the result in an additional label, termed the "entropy label", as part of the MPLS label stack it pushes onto that packet.
消除这种深度检查需要的一种方法是让MPLS标签交换路径的入口LSR从给定的数据包中提取适当的密钥，将它们输入到其负载平衡功能中，并将结果放入称为“熵标签”的附加标签中，作为其推送到该数据包上的MPLS标签堆栈的一部分。
The entire label stack of the MPLS packet can then be used by transit LSRs to perform load balancing, as the entropy label introduces the right level of "entropy" into the label stack.
然后，传输LSR可以使用MPLS数据包的整个标签堆栈来执行负载平衡，因为熵标签将适当级别的“熵”引入标签堆栈。
There are five key reasons why this is beneficial:
这是有益的，有五个关键原因：
1. At the ingress LSR, MPLS encapsulation hasn't yet occurred, so deep inspection is not necessary.
1. 在入口LSR，MPLS封装尚未发生，因此无需深入检查。
2. The ingress LSR has more context and information about incoming packets than transit LSRs.
2. 与传输LSR相比，入口LSR具有更多关于传入数据包的上下文和信息。
3. Ingress LSRs usually operate at lower bandwidths than transit LSRs, allowing them to do more work per packet.
3. 入口LSR通常以比传输LSR更低的带宽工作，允许它们在每个数据包上做更多的工作。
4. Transit LSRs do not need to perform deep packet inspection and can load balance effectively using only a packet's MPLS label stack.
4. 传输LSR不需要执行深度数据包检查，并且仅使用数据包的MPLS标签堆栈就可以有效地实现负载平衡。
5. Transit LSRs, not having the full context that an ingress LSR does, have the hard choice between potentially misinterpreting fields in a packet as valid keys for load balancing (causing packet-ordering problems) or adopting a conservative approach (giving rise to sub-optimal load balancing). Entropy labels relieve them of making this choice.
5. 传输LSR没有入口LSR那样的完整上下文，在将数据包中的字段误解为负载平衡的有效密钥（导致数据包排序问题）或采用保守方法（导致次优负载平衡）之间，很难做出选择。熵标签使他们不必做出这种选择。
This memo describes why entropy labels are needed and defines the properties of entropy labels, in particular, how they are generated and received and the expected behavior of transit LSRs. Finally, it describes in general how signaling works and what needs to be signaled as well as specifics for the signaling of entropy labels for LDP [RFC5036], BGP [RFC4271], and RSVP - Traffic Engineering (RSVP-TE) [RFC3209].
本备忘录描述了为什么需要熵标签，并定义了熵标签的属性，特别是如何生成和接收熵标签以及公交LSR的预期行为。最后，它概括地描述了信令的工作方式和需要信令的内容，以及LDP[RFC5036]、BGP[RFC4271]和RSVP-流量工程（RSVP-TE）[RFC3209]的熵标签信令的细节。
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]中所述进行解释。
The following acronyms/initialisms are used:
使用的首字母缩略词/首字母缩写如下：
BoS: Bottom of Stack
BoS：堆栈的底部
CE: Customer Edge
行政长官：顾客优势
ECMP: Equal Cost Multi-Path
ECMP：等成本多路径
EL: Entropy Label
熵标签
ELC: Entropy Label Capability
熵标记能力
ELI: Entropy Label Indicator
熵标签指示器
FEC: Forwarding Equivalence Class
转发等价类
LAG: Link Aggregation Group
滞后：链路聚合组
LER: Label Edge Router
标签边缘路由器
LSP: Label Switched Path
标签交换路径
LSR: Label Switching Router
标签交换路由器
PE: Provider Edge
PE：提供程序边缘
PW: Pseudowire
伪线
PHP: Penultimate Hop Popping
PHP：倒数第二跳弹出
TC: Traffic Class
TC：交通等级
TTL: Time to Live
TTL：生命的时刻
UHP: Ultimate Hop Popping
UHP：终极蹦极
VPLS: Virtual Private LAN (Local Area Network) Service
虚拟专用LAN（局域网）服务
VPN: Virtual Private Network
虚拟专用网
The term "ingress LSR" (or "egress LSR") is used interchangeably with "ingress LER" (or "egress LER"). The term "application" throughout the text refers to an MPLS application (such as a VPN or VPLS).
术语“入口LSR”（或“出口LSR”）可与“入口LER”（或“出口LER”）互换使用。全文中的术语“应用程序”指的是MPLS应用程序（例如VPN或VPLS）。
A label stack (say of three labels) is denoted by <L1, L2, L3>, where L1 is the "outermost" label and L3 the "innermost" (closest to the payload). Packet flows are depicted left to right, and signaling is shown right to left (unless otherwise indicated).
标签堆栈（比如三个标签）由<L1，L2，L3>表示，其中L1是“最外面的”标签，L3是“最里面的”（最接近有效负载）。分组流从左到右表示，信令从右到左表示（除非另有说明）。
The term "label" is used both for the entire 32-bit label stack entry and the 20-bit label field within a label stack entry. It should be clear from the context which is meant.
术语“标签”用于整个32位标签堆栈条目和标签堆栈条目内的20位标签字段。从上下文中应该清楚地知道这是什么意思。
MPLS is a very successful generic forwarding substrate that transports several dozen types of protocols, most notably: IP, PWs, VPLS, and IP VPNs. Within each type of protocol, there typically exist several variants, each with a different set of load-balancing keys, e.g., IPv4, IPv6, IPv6 in IPv4, etc. for IP and Ethernet; ATM, Frame-Relay, etc. for PWs. There are also several different types of Ethernet over PW encapsulation, ATM over PW encapsulation, etc. Finally, given the popularity of MPLS, it is likely that it will continue to be extended to transport new protocols.
MPLS是一种非常成功的通用转发基板，可传输几十种协议，最显著的是：IP、PWs、VPLS和IP VPN。在每种类型的协议中，通常存在多个变体，每个变体具有一组不同的负载平衡密钥，例如，用于IP和以太网的IPv4、IPv6、IPv4中的IPv6等；用于PWs的ATM、帧中继等。还有几种不同类型的以太网PW封装、ATM PW封装等。最后，鉴于MPLS的普及，它可能会继续扩展以传输新协议。
Currently, each transit LSR along the path of a given LSP has to try to infer the underlying protocol within an MPLS packet in order to extract appropriate keys for load balancing. Unfortunately, if the transit LSR is unable to infer the MPLS packet's protocol (as is often the case), it will typically use the topmost (or all) MPLS labels in the label stack as keys for the load-balancing function. The result may be an extremely inequitable distribution of traffic across equal cost paths exiting that LSR. This is because MPLS labels are generally fairly coarse-grained forwarding labels that typically describe a next hop, or provide some demultiplexing and/or forwarding function, and do not describe the packet's underlying protocol.
目前，沿着给定LSP路径的每个传输LSR必须尝试推断MPLS数据包内的底层协议，以便提取适当的密钥以实现负载平衡。不幸的是，如果传输LSR无法推断MPLS数据包的协议（通常情况下），它通常会使用标签堆栈中最上面（或所有）的MPLS标签作为负载平衡功能的密钥。结果可能是在退出该LSR的等成本路径上的流量分布极不公平。这是因为MPLS标签通常是相当粗粒度的转发标签，通常描述下一跳，或提供一些解复用和/或转发功能，而不描述数据包的底层协议。
On the other hand, an ingress LSR (e.g., a PE router) has detailed knowledge of a packet's contents, typically through a priori configuration of the encapsulations that are expected at a given PE-CE interface, (e.g., IPv4, IPv6, VPLS, etc.). They may also have more flexible forwarding hardware, depending on implementation details. PE routers need this information and these capabilities to:
另一方面，入口LSR（例如，PE路由器）通常通过在给定PE-CE接口（例如，IPv4、IPv6、VPLS等）处预期的封装的先验配置，具有关于分组内容的详细知识。它们还可能具有更灵活的转发硬件，具体取决于实现细节。PE路由器需要这些信息和功能来：
a. apply the required services for the CE;
a. 为行政长官提供所需的服务；
b. discern the packet's Class of Service (CoS) forwarding treatment;
b. 识别数据包的服务类别（CoS）转发处理；
c. apply filters to forward or block traffic to/from the CE;
c. 应用过滤器转发或阻止与CE之间的通信；
d. forward routing/control traffic to an onboard management processor; and,
d. 将路由/控制流量转发至车载管理处理器；和
e. load balance the traffic on its uplinks to transit LSRs (e.g., P routers).
e. 负载平衡传输LSR（例如，P路由器）上行链路上的流量。
By knowing the expected encapsulation types, an ingress LSR router can apply a more specific set of payload parsing routines to extract the keys appropriate for a given protocol. This allows for significantly improved accuracy in determining the appropriate load-balancing behavior for each protocol.
通过了解预期的封装类型，入口LSR路由器可以应用一组更具体的负载解析例程来提取适合给定协议的密钥。这样可以显著提高确定每个协议的适当负载平衡行为的准确性。
If the ingress LSR were to capture the flow information so gathered in a convenient form for downstream transit LSRs, transit LSRs could remain completely oblivious to the contents of each MPLS packet and use only the captured flow information to perform load balancing. In particular, there will be no reason to duplicate an ingress LSR's complex packet/payload parsing functionality in a transit LSR. This will result in less complex transit LSRs, enabling them to more easily scale to higher forwarding rates, larger port density, lower power consumption, etc. The idea in this memo is to capture this flow information as a label, the so-called "entropy label".
如果入口LSR要捕获以方便的形式为下游传输LSR收集的流信息，则传输LSR可以保持对每个MPLS分组的内容完全不在意，并且仅使用捕获的流信息来执行负载平衡。特别地，将没有理由在传输LSR中复制入口LSR的复杂分组/有效负载解析功能。这将减少运输LSR的复杂性，使其能够更轻松地扩展到更高的转发速率、更大的端口密度、更低的功耗等。本备忘录中的想法是将此流量信息捕获为一个标签，即所谓的“熵标签”。
Ingress LSRs can also adapt more readily to new protocols and extract the appropriate keys to use for load-balancing packets of those protocols. This means that deploying new protocols or services in edge devices requires fewer concomitant changes in the core, resulting in higher edge-service velocity and, at the same time, more stable core networks.
入口LSR还可以更容易地适应新协议，并提取适当的密钥用于这些协议的负载平衡数据包。这意味着在边缘设备中部署新的协议或服务需要更少的核心变化，从而提高边缘服务速度，同时提高核心网络的稳定性。
There are two main approaches to encoding load-balancing information in the label stack. The first allocates multiple labels for a particular Forwarding Equivalence Class (FEC). These labels are equivalent in terms of forwarding semantics, but having multiple labels allows flexibility in assigning labels to flows belonging to the same FEC. This approach has the advantage that the label stack has the same depth whether or not one uses label-based load balancing; consequently, there is no change to forwarding operations on transit and egress LSRs. However, it has a major drawback in that there is a significant increase in both signaling and forwarding state.
在标签堆栈中编码负载平衡信息有两种主要方法。第一种方法为特定的转发等价类（FEC）分配多个标签。这些标签在转发语义方面是等效的，但是具有多个标签允许灵活地将标签分配给属于同一FEC的流。这种方法的优点是，无论是否使用基于标签的负载平衡，标签堆栈都具有相同的深度；因此，中转和出口LSR上的转发操作没有变化。然而，它有一个主要缺点，即信令和转发状态都显著增加。
The other approach encodes the load-balancing information as an additional label in the label stack, thus increasing the depth of the label stack by one. With this approach, there is minimal change to signaling state for a FEC; also, there is no change in forwarding operations in transit LSRs and no increase of forwarding state in any LSR. The only purpose of the additional label is to increase the entropy in the label stack, so this is called an "entropy label". This memo focuses solely on this approach.
另一种方法将负载平衡信息编码为标签堆栈中的附加标签，从而将标签堆栈的深度增加一个。通过这种方法，FEC的信令状态变化最小；此外，在传输LSR中的转发操作没有变化，在任何LSR中的转发状态也没有增加。附加标签的唯一目的是增加标签堆栈中的熵，因此这称为“熵标签”。本备忘录仅关注此方法。
This latter approach uses upstream-generated entropy labels, which may conflict with downstream-allocated application labels. There are a few approaches to deal with this: 1) allocate a pair of labels for each FEC, one that must have an entropy label below it and one that must not; 2) use a label (the "Entropy Label Indicator") to indicate that the next label is an entropy label; and 3) allow entropy labels only where there is no possible confusion. The first doubles control and data plane state in the network; the last is too restrictive. The approach taken here is the second. In making both the above choices, the trade-off is to increase label stack depth rather than control and data plane state in the network.
后一种方法使用上游生成的熵标签，这可能与下游分配的应用程序标签冲突。有几种方法可以解决这个问题：1）为每个FEC分配一对标签，一个必须在其下方有一个熵标签，另一个不能；2） 使用标签（“熵标签指示器”）指示下一个标签是熵标签；3）仅允许在没有可能混淆的情况下使用熵标签。第一个将网络中的控制和数据平面状态加倍；最后一个限制太大了。这里采用的方法是第二种。在做出上述两种选择时，权衡的是增加标签堆栈深度，而不是网络中的控制和数据平面状态。
Finally, one may choose to associate ELs with MPLS tunnels (LSPs) or with MPLS applications (e.g., VPNs). (What this entails is described in later sections.) We take the former approach, for the following reasons:
最后，可以选择将ELs与MPLS隧道（LSP）或MPLS应用程序（例如VPN）相关联。（这需要什么在后面的章节中描述。）我们采用前一种方法，原因如下：
1. There are a small number of tunneling protocols for MPLS, but a large and growing number of applications. Defining ELs on a tunnel basis means simpler standards, lower development, interoperability, and testing efforts.
1. MPLS有少量的隧道协议，但有大量且不断增长的应用程序。在隧道基础上定义ELs意味着更简单的标准、更低的开发、互操作性和测试工作。
2. As a consequence, there will be much less churn in the network as new applications (services) are defined and deployed.
2. 因此，随着新应用程序（服务）的定义和部署，网络中的客户流失将大大减少。
3. Processing application labels in the data plane is more complex than processing tunnel labels. Thus, it is preferable to burden the latter rather than the former with EL processing.
3. 在数据平面中处理应用程序标签比处理隧道标签更复杂。因此，优选用EL处理来加重后者而不是前者的负担。
4. Associating ELs with tunnels makes it simpler to deal with hierarchy, be it LDP-over-RSVP-TE or Carrier's Carrier VPNs. Each layer in the hierarchy can choose independently whether or not they want ELs.
4. 将ELs与隧道相关联可以简化层次结构的处理，无论是RSVP TE上的LDP还是运营商的运营商VPN。层次结构中的每个层都可以独立选择是否需要ELs。
The cost of this approach is that ELIs will be mandatory; again, the trade-off is the size of the label stack. To summarize, the net increase in the label stack to use entropy labels is two: one reserved label for the ELI and the entropy label itself.
这种方法的成本是ELIs将是强制性的；同样，折衷是标签堆栈的大小。总而言之，使用熵标签的标签堆栈中的净增加量是两个：一个是为ELI保留的标签，另一个是熵标签本身。
An entropy label (as used here) is a label:
熵标签（此处使用）是一个标签：
1. that is not used for forwarding;
1. 不用于转发的；
2. that is not signaled; and
2. 没有发出信号；和
3. whose only purpose in the label stack is to provide "entropy" to improve load balancing.
3. 其在标签堆栈中的唯一用途是提供“熵”以改进负载平衡。
Entropy labels are generated by an ingress LSR, based entirely on load-balancing information. However, they MUST NOT have values in the reserved label space (0-15) [RFC3032].
熵标签由入口LSR生成，完全基于负载平衡信息。但是，它们不得在保留标签空间（0-15）[RFC3032]中具有值。
Since entropy labels are generated by an ingress LSR, an egress LSR MUST be able to distinguish unambiguously between entropy labels and application labels. To accomplish this, it is REQUIRED that the label immediately preceding an Entropy Label (EL) in the MPLS label stack be an Entropy Label Indicator (ELI), where preceding means closer to the top of the label stack (farther from bottom of stack indication). The ELI is a reserved label with value 7. How to set values of the TTL, TC, and "Bottom of Stack" (BoS) fields [RFC3032] for the ELI and for ELs is discussed in Section 4.2.
由于熵标签由入口LSR生成，因此出口LSR必须能够明确区分熵标签和应用程序标签。为了实现这一点，要求MPLS标签堆栈中紧靠熵标签（EL）之前的标签是熵标签指示符（ELI），其中前面的意思是更靠近标签堆栈的顶部（远离堆栈底部指示）。ELI是值为7的保留标签。第4.2节讨论了如何为ELI和ELs设置TTL、TC和“堆栈底部”（BoS）字段[RFC3032]的值。
Entropy labels are useful for pseudowires [RFC4447]. [RFC6391] explains how entropy labels can be used for pseudowires that are of the RFC 4447 style and is therefore complementary to this memo, which focuses on how entropy labels can be used for tunnels and thus for all other MPLS applications.
熵标签对于伪导线很有用[RFC4447]。[RFC6391]解释了熵标签如何用于RFC 4447样式的伪线，因此是对本备忘录的补充，本备忘录重点介绍了熵标签如何用于隧道以及所有其他MPLS应用。
Suppose egress LSR Y is capable of processing entropy labels for a tunnel. Y indicates this to all ingresses via signaling (see Section 5). Y MUST be prepared to deal both with packets with an imposed EL and those without; the ELI will distinguish these cases. If a particular ingress chooses not to impose an EL, Y's processing of the received label stack (which might be empty) is as if Y chose not to accept ELs.
假设出口LSR Y能够处理隧道的熵标签。Y通过信号向所有入口表明这一点（见第5节）。Y必须准备好处理有强制EL的数据包和没有强制EL的数据包；ELI将区分这些情况。如果特定入口选择不施加EL，Y对接收到的标签堆栈（可能为空）的处理就好像Y选择不接受EL一样。
If an ingress LSR X chooses to impose an EL, then Y will receive a tunnel termination packet with label stack <TL, ELI, EL> <remaining packet header>. Y recognizes TL as the label it distributed to its upstreams for the tunnel and pops it. (Note that TL may be the implicit null label, in which case it doesn't appear in the label stack.) Y then recognizes the ELI and pops two labels: the ELI and the EL. Y then processes the remaining packet header as normal; this may require further processing of tunnel termination, perhaps with further ELI+EL pairs. When processing the final tunnel termination, Y MAY enqueue the packet based on that tunnel TL's or ELI's TC value and MAY use the tunnel TL's or ELI's TTL to compute the TTL of the remaining packet header. The EL's TTL MUST be ignored.
如果入口LSR X选择施加EL，则Y将接收具有标签栈<TL，ELI，EL>的隧道终止分组<剩余分组报头>。Y将TL识别为其分发到隧道上游的标签，并将其弹出。（请注意，TL可能是隐式空标签，在这种情况下，它不会出现在标签堆栈中。）Y然后识别ELI并弹出两个标签：ELI和EL。然后，Y按照正常方式处理剩余的分组报头；这可能需要进一步处理隧道终端，可能需要进一步的ELI+EL对。当处理最终隧道终止时，Y可以基于该隧道TL或ELI的TC值使分组排队，并且可以使用隧道TL或ELI的TTL来计算剩余分组报头的TTL。必须忽略EL的TTL。
If any ELI processed by Y has the BoS bit set, Y MUST discard the packet and MAY log an error. The EL's BoS bit will indicate whether or not there are more labels in the stack.
如果Y处理的任何ELI设置了BoS位，Y必须丢弃该数据包并可能记录错误。EL的BoS位将指示堆栈中是否有更多标签。
If an egress LSR Y indicates via signaling that it can process ELs on a particular tunnel, an ingress LSR X can choose whether or not to insert ELs for packets going into that tunnel. Y MUST handle both cases.
如果出口LSR Y通过信令指示其可以在特定隧道上处理ELs，则入口LSR X可以选择是否为进入该隧道的分组插入ELs。我必须处理这两种情况。
The steps that X performs to insert ELs are as follows:
X插入ELs的步骤如下：
1. On an incoming packet, identify the application to which the packet belongs; based on this, pick appropriate fields as input to the load-balancing function; apply the load-balancing function to these input fields and let LB be the output.
1. 在传入数据包上，标识该数据包所属的应用程序；基于此，选择适当的字段作为负载平衡功能的输入；将负载平衡功能应用于这些输入字段，并将LB作为输出。
2. Determine the application label AL (if any). Push <AL> onto the packet.
2. 确定应用程序标签AL（如果有）。将<AL>推到数据包上。
3. Based on the application, the load-balancing output LB and other factors, determine the egress LSR Y, the tunnel to Y, the specific interface to the next hop, and thus the tunnel label TL. Use LB to generate the entropy label EL.
3. 基于应用程序、负载平衡输出LB和其他因素，确定出口LSR Y、隧道到Y、到下一跳的特定接口，从而确定隧道标签TL。使用LB生成熵标签EL。
4. If, for the chosen tunnel, Y has not indicated that it can process ELs, push <TL> onto the packet. If Y has indicated that it can process ELs for the tunnel, push <TL, ELI, EL> onto the packet. X SHOULD put the same TTL and TC fields for the ELI as it does for TL. X MAY choose different values for the TTL and TC fields if it is known that the ELI will not be exposed as the top label at any point along the LSP (as may happen in cases where PHP is used and the ELI and EL are not stripped at the penultimate hop (see Section 4.4). The BoS bit for the ELI MUST be zero (i.e., BoS is not set). The TTL for the EL MUST be zero to ensure that it is not used inadvertently for forwarding. The TC for the EL may be any value. The BoS bit for the EL depends on whether or not there are more labels in the label stack.
4. 如果对于所选隧道，Y未指示它可以处理ELs，则将<TL>推送到数据包上。如果Y指示它可以处理隧道的ELs，则将<TL，ELI，EL>推送到数据包上。X应为ELI设置与TL相同的TTL和TC字段。如果已知ELI不会在LSP的任何点作为顶部标签公开，则X可以为TTL和TC字段选择不同的值（在使用PHP且在倒数第二个跃点未剥离ELI和EL的情况下可能会发生这种情况（见第4.4节）。ELI的BoS位必须为零（即未设置BoS）。EL的TTL必须为零，以确保不会无意中用于转发。EL的TC可以是任何值。EL的BoS位取决于标签堆栈中是否有更多标签。
5. X then determines whether further tunnel hierarchy is needed; if so, X goes back to step 3, possibly with a new egress Y for the new tunnel. Otherwise, X is done and sends out the packet.
5. 然后确定是否需要进一步的隧道层次结构；如果是这样，X返回步骤3，可能为新隧道提供一个新出口Y。否则，X完成并发送数据包。
Notes:
笔记：
a. X computes load-balancing information and generates the EL based on the incoming application packet, even though the signaling of EL capability is associated with tunnels.
a. X计算负载平衡信息并基于传入的应用程序包生成EL，即使EL能力的信令与隧道相关。
b. X MAY insert several entropy labels in the stack (each, of course, preceded by an ELI), potentially one for each hierarchical tunnel, provided that the egress for that tunnel has indicated that it can process ELs for that tunnel.
b. X可以在堆栈中插入几个熵标签（当然，每个标签前面都有一个ELI），每个分层隧道可能有一个熵标签，前提是该隧道的出口指示它可以处理该隧道的ELs。
c. X MUST NOT include an entropy label for a given tunnel unless the egress LSR Y has indicated that it can process entropy labels for that tunnel.
c. X不得包括给定隧道的熵标签，除非出口LSR Y已指示其可以处理该隧道的熵标签。
d. The signaling and use of entropy labels in one direction (signaling from Y to X and data path from X to Y) is completely independent of the signaling and use of entropy labels in the reverse direction (signaling from X to Y and data path from Y to X).
d. 一个方向上熵标签的信令和使用（从Y到X的信令和从X到Y的数据路径）完全独立于反向上熵标签的信令和使用（从X到Y的信令和从Y到X的数据路径）。
Transit LSRs MAY operate with no change in forwarding behavior. The following are suggestions for optimizations that improve load balancing, reduce the amount of packet data processed, and/or enhance backward compatibility.
中转LSR可以在转发行为没有变化的情况下运行。以下是改进负载平衡、减少处理的数据包数据量和/或增强向后兼容性的优化建议。
If a transit LSR recognizes the ELI, it MAY choose to load balance solely on the following label (the EL); otherwise, it SHOULD use as much of the whole label stack as feasible as keys for the load-balancing function. In any case, reserved labels MUST NOT be used as keys for the load-balancing function.
如果公交LSR识别出ELI，则可选择仅在以下标签（EL）上进行负载平衡；否则，它应该尽可能多地使用整个标签堆栈作为负载平衡功能的键。在任何情况下，保留标签不得用作负载平衡功能的键。
Some transit LSRs look beyond the label stack for better load-balancing information. This is a simple, backward-compatible approach in networks where some ingress LSRs impose ELs and others don't. However, this is of limited incremental value if an EL is indeed present and requires more packet processing from the LSR. A transit LSR MAY choose to parse the label stack for the presence of the ELI and look beyond the label stack only if it does not find it, thus retaining the old behavior when needed, yet avoiding unnecessary work if not needed.
一些transit LSR在标签堆栈之外寻找更好的负载平衡信息。这是一种简单、向后兼容的方法，适用于某些入口LSR施加ELs而其他入口LSR不施加ELs的网络。然而，如果确实存在EL并且需要来自LSR的更多分组处理，则这是有限的增量值。transit LSR可以选择解析标签堆栈以确定是否存在ELI，并仅在未找到标签堆栈时查看标签堆栈之外的内容，从而在需要时保留旧行为，但在不需要时避免不必要的工作。
As stated in Sections 4.1 and 5, an egress LSR that signals both ELC and implicit null MUST pop the ELI and the next label (which should be the EL), if it encounters a packet with the ELI as the topmost label. Any other LSR (including PHP LSRs) MUST drop such packets, as per Section 3.18 of [RFC3031].
如第4.1节和第5节所述，发出ELC和隐式null信号的出口LSR必须弹出ELI和下一个标签（应为EL），如果它遇到一个以ELI作为最上面标签的数据包。根据[RFC3031]第3.18节，任何其他LSR（包括PHP LSR）必须丢弃此类数据包。
No change is needed at penultimate hop LSRs. However, a PHP LSR that recognizes the ELI MAY choose to pop the ELI and following label (which should be an entropy label) in addition to popping the tunnel label, provided that doing so doesn't diminish its ability to load balance on the next hop.
倒数第二跳LSR不需要更改。但是，识别ELI的PHP LSR除了弹出隧道标签外，还可以选择弹出ELI和后续标签（应该是熵标签），前提是这样做不会降低其在下一跳上的负载平衡能力。
An egress LSR Y can signal to ingress LSR(s) its ability to process entropy labels (henceforth called "Entropy Label Capability" or ELC) on a given tunnel. In particular, even if Y signals an implicit null label, indicating that PHP is to be performed, Y MUST be prepared to pop the ELI and EL.
出口LSR Y可以向入口LSR发送信号，表明其在给定隧道上处理熵标签（以下称为“熵标签能力”或ELC）的能力。特别是，即使Y表示要执行PHP的隐式空标签，Y也必须准备弹出ELI和EL。
Note that Entropy Label Capability may be asymmetric: if LSRs X and Y are at opposite ends of a tunnel, X may be able to process entropy labels, whereas Y may not. The signaling extensions below allow for this asymmetry.
请注意，熵标签功能可能是不对称的：如果LSRx和Y位于隧道的两端，则X可能能够处理熵标签，而Y可能不能。下面的信令扩展允许这种不对称。
For an illustration of signaling and forwarding with entropy labels, see Section 8.
有关使用熵标签的信令和转发的说明，请参见第8节。
A new LDP TLV [RFC5036] is defined to signal an egress's ability to process entropy labels. This is called the ELC TLV and may appear as an Optional Parameter of the Label Mapping Message TLV.
定义了一个新的LDP TLV[RFC5036]来表示出口处理熵标签的能力。这称为ELC TLV，可以作为标签映射消息TLV的可选参数显示。
The presence of the ELC TLV in a Label Mapping Message indicates to ingress LSRs that the egress LSR can process entropy labels for the associated LDP tunnel. The ELC TLV has Type 0x0206 and Length 0.
标签映射消息中ELC TLV的存在向入口LSR指示出口LSR可以处理相关LDP隧道的熵标签。ELC TLV的类型为0x0206，长度为0。
The structure of the ELC TLV is shown below.
ELC TLV的结构如下所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type 0x0206 | Length (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type 0x0206 | Length (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Entropy Label Capability TLV
图1：熵标签能力TLV
where:
哪里：
U: Unknown bit. This bit MUST be set to 1. If the ELC TLV is not understood by the receiver, then it MUST be ignored.
U:未知位。此位必须设置为1。如果接收器不理解ELC TLV，则必须忽略它。
F: Forward bit. This bit MUST be set be set to 1. Since the ELC TLV is going to be propagated hop-by-hop, it should be forwarded even by nodes that may not understand it.
F:向前位。此位必须设置为1。由于ELC TLV将逐跳传播，因此即使不理解它的节点也应该转发它。
Type: Type field (0x0206)
类型：类型字段（0x0206）
Length: Length field. This field specifies the total length in octets of the ELC TLV and is currently defined to be 0.
长度：长度字段。此字段指定ELC TLV的总长度（以八位字节为单位），当前定义为0。
An LSR that receives a Label Mapping with the ELC TLV but does not understand it MUST propagate it intact to its neighbors and MUST NOT send a notification to the sender (following the meaning of the U-and F-bits).
接收到ELC TLV标签映射但不理解该映射的LSR必须将其完整地传播到其邻居，并且不得向发送方发送通知（遵循U位和F位的含义）。
An LSR X may receive multiple Label Mappings for a given FEC F from its neighbors. In its turn, X may advertise a Label Mapping for F to its neighbors. If X understands the ELC TLV, and if any of the advertisements it received for FEC F does not include the ELC TLV, X MUST NOT include the ELC TLV in its own advertisements of F. If all the advertised Mappings for F include the ELC TLV, then X MUST advertise its Mapping for F with the ELC TLV. If any of X's neighbors resends its Mapping, sends a new Mapping or sends a Label Withdraw for a previously advertised Mapping for F, X MUST re-evaluate the status of ELC for FEC F, and, if there is a change, X MUST re-advertise its Mapping for F with the updated status of ELC.
LSR X可以从其邻居接收给定FEC F的多个标签映射。反过来，X可能会将F的标签映射播发到它的邻居。如果X了解ELC TLV，并且如果其收到的FEC F的任何广告不包括ELC TLV，则X不得在其自己的F广告中包括ELC TLV。如果F的所有广告映射包括ELC TLV，则X必须用ELC TLV广告其F映射。如果X的任何邻居重新发送其映射、发送新映射或为先前公布的F映射发送标签撤销，则X必须重新评估FEC F的ELC状态，如果有更改，X必须使用更新的ELC状态重新公布其F映射。
When BGP [RFC4271] is used for distributing Network Layer Reachability Information (NLRI) as described in, for example, [RFC3107], the BGP UPDATE message may include the ELC attribute as part of the Path Attributes. This is an optional, transitive BGP
当BGP[RFC4271]用于分发网络层可达性信息（NLRI）时，如在例如[RFC3107]中所述，BGP更新消息可以包括ELC属性作为路径属性的一部分。这是一个可选的、可传递的BGP
attribute of value 28. The inclusion of this attribute with an NLRI indicates that the advertising BGP router can process entropy labels as an egress LSR for all routes in that NLRI.
值为28的属性。将该属性与NLRI一起包含表示广告BGP路由器可以将熵标签处理为该NLRI中所有路由的出口LSR。
A BGP speaker S that originates an UPDATE should include the ELC attribute only if both of the following are true:
仅当以下两项均为真时，发起更新的BGP扬声器才应包括ELC属性：
A1: S sets the BGP NEXT_HOP attribute to itself AND
A1:S将BGP下一跳属性设置为自身，并
A2: S can process entropy labels.
A2:S可以处理熵标签。
Suppose a BGP speaker T receives an UPDATE U with the ELC attribute. T has two choices. T can simply re-advertise U with the ELC attribute if either of the following is true:
假设BGP扬声器T接收到具有ELC属性的更新U。T有两个选择。如果满足以下任一条件，T可以简单地使用ELC属性重新公布U：
B1: T does not change the NEXT_HOP attribute OR
B1:T不会更改下一跳属性或
B2: T simply swaps labels without popping the entire label stack and processing the payload below.
B2:T简单地交换标签，而不弹出整个标签堆栈并处理下面的有效负载。
An example of the use of B1 is Route Reflectors.
B1使用的一个例子是路线反射器。
However, if T changes the NEXT_HOP attribute for U and in the data plane pops the entire label stack to process the payload, T MAY include an ELC attribute for UPDATE U' if both of the following are true:
但是，如果T更改U的NEXT_HOP属性，并且在数据平面中弹出整个标签堆栈以处理有效负载，则T可以包括用于更新U'的ELC属性，如果以下两个都为真：
C1: T sets the NEXT_HOP attribute of U' to itself AND
C1:T将U'的下一跳属性设置为自身，并
C2: T can process entropy labels.
C2:T可以处理熵标签。
Otherwise, T MUST remove the ELC attribute.
否则，T必须删除ELC属性。
Entropy label support is signaled in RSVP-TE [RFC3209] using the Entropy Label Capability (ELC) flag in the Attribute Flags TLV of the LSP_ATTRIBUTES object [RFC5420]. The presence of the ELC flag in a Path message indicates that the ingress can process entropy labels in the upstream direction; this only makes sense for a bidirectional LSP and MUST be ignored otherwise. The presence of the ELC flag in a Resv message indicates that the egress can process entropy labels in the downstream direction.
熵标签支持在RSVP-TE[RFC3209]中使用LSP_ATTRIBUTES对象[RFC5420]的属性标志TLV中的熵标签能力（ELC）标志发出信号。路径消息中存在ELC标志指示入口可以在上游方向上处理熵标签；这仅适用于双向LSP，否则必须忽略。Resv消息中存在ELC标志表示出口可以在下游方向处理熵标签。
The bit number for the ELC flag is 9.
ELC标志的位号为9。
Multicast LSPs [RFC4875] [RFC6388] typically do not use ECMP for load balancing, as the combination of replication and multi-pathing can lead to duplicate traffic delivery. However, these LSPs can traverse bundled links [RFC4201] and LAGs. In both these cases, load balancing is useful, and hence entropy labels can be of value for multicast LSPs.
多播LSP[RFC4875][RFC6388]通常不使用ECMP进行负载平衡，因为复制和多路径的组合可能导致重复的流量传递。但是，这些LSP可以穿越捆绑链路[RFC4201]和LAG。在这两种情况下，负载平衡都很有用，因此熵标签对于多播LSP很有价值。
The methodology defined for entropy labels here will be used for multicast LSPs; however, the details of signaling and processing ELs for multicast LSPs will be specified in a future document.
这里为熵标签定义的方法将用于多播LSP；然而，多播LSP的信令和处理ELs的细节将在未来的文档中指定。
Generally, OAM comprises a set of functions operating in the data plane to allow a network operator to monitor its network infrastructure and to implement mechanisms in order to enhance the general behavior and the level of performance of its network, e.g., the efficient and automatic detection, localization, diagnosis, and handling of defects.
通常，OAM包括一组在数据平面上运行的功能，以允许网络运营商监控其网络基础设施并实施机制，以增强其网络的一般行为和性能水平，例如，高效和自动地检测、定位、诊断和处理缺陷。
Currently defined OAM mechanisms for MPLS include LSP ping/traceroute [RFC4379] and Bidirectional Forwarding Detection (BFD) for MPLS [RFC5884]. The latter provides connectivity verification between the endpoints of an LSP, and recommends establishing a separate BFD session for every path between the endpoints.
目前定义的MPLS OAM机制包括LSP ping/traceroute[RFC4379]和MPLS的双向转发检测（BFD）[RFC5884]。后者提供LSP端点之间的连接验证，并建议为端点之间的每条路径建立单独的BFD会话。
The LSP traceroute procedures of [RFC4379] allow an ingress LSR to obtain label ranges that can be used to send packets on every path to the egress LSR. It works by having the ingress LSR sequentially ask the transit LSRs along a particular path to a given egress LSR to return a label range such that the inclusion of a label in that range in a packet will cause the replying transit LSR to send that packet out the egress interface for that path. The ingress provides the label range returned by transit LSR N to transit LSR N + 1, which returns a label range that is less than or equal in span to the range provided to it. This process iterates until the penultimate transit LSR replies to the ingress LSR with a label range that is acceptable to it and to all LSRs along path preceding it for forwarding a packet along the path.
[RFC4379]的LSP跟踪路由程序允许入口LSR获得标签范围，该标签范围可用于在每条路径上向出口LSR发送数据包。它通过让入口LSR沿着特定路径顺序地请求传输LSR返回标签范围来工作，使得在分组中包含该范围内的标签将导致应答传输LSR将该分组发送出该路径的出口接口。入口提供transit LSR N返回到transit LSR N+1的标签范围，该标签范围返回的范围小于或等于提供给它的范围。此过程迭代，直到倒数第二个传输LSR使用其可接受的标签范围回复入口LSR，并回复其前面路径上的所有LSR，以便沿该路径转发数据包。
However, the LSP traceroute procedures do not specify where in the label stack the value from the label range is to be placed, whether deep packet inspection is allowed, and if so, which keys and key values are to be used.
但是，LSP跟踪路由程序未指定标签堆栈中标签范围的值的位置、是否允许深度数据包检查，以及如果允许，将使用哪些键和键值。
This memo updates LSP traceroute by specifying that the value from the label range is to be placed in the entropy label. Deep packet inspection is thus not necessary, although an LSR may use it, provided it does so consistently, i.e., if the label range to go to a given downstream LSR is computed with deep packet inspection, then the data path should use the same approach and the same keys.
此备忘录通过指定将标签范围中的值放置在熵标签中来更新LSP跟踪路由。因此，深度分组检查是不必要的，尽管LSR可以使用它，但前提是它一致地这样做，即，如果使用深度分组检查计算到给定下游LSR的标签范围，则数据路径应该使用相同的方法和相同的密钥。
In order to have a BFD session on a given path, a value from the label range for that path should be used as the EL value for BFD packets sent on that path.
为了在给定路径上具有BFD会话，该路径的标签范围中的值应用作在该路径上发送的BFD数据包的EL值。
Since the MPLS Transport Profile (MPLS-TP) does not use ECMP, entropy labels are not applicable to an MPLS-TP deployment.
由于MPLS传输配置文件（MPLS-TP）不使用ECMP，因此熵标签不适用于MPLS-TP部署。
This section describes the use of entropy labels in various scenarios. The material in this section is illustrative and offers guidance to implementations, but it does not form a normative part of this specification.
本节介绍熵标签在各种场景中的使用。本节中的内容是说明性的，为实现提供指导，但不构成本规范的规范性部分。
In the figures below, the following conventions are used to depict processing between X and Y. Note that control plane signaling goes right to left, whereas data plane processing goes left to right.
在下图中，以下约定用于描述X和Y之间的处理。请注意，控制平面信令从右向左，而数据平面处理从左向右。
Protocols
Y: <--- [L, E] Y signals L to X
X ------------- Y
Data Plane:
X-Y: <L, ELI, EL> Label Stack from X -> Y
Label Stack Operations:
X: +<L, ELI, EL> X pushes <L, ELI, EL>
Y: -<L, ELI, EL> Y pops <L, ELI, EL>
Protocols
Y: <--- [L, E] Y signals L to X
X ------------- Y
Data Plane:
X-Y: <L, ELI, EL> Label Stack from X -> Y
Label Stack Operations:
X: +<L, ELI, EL> X pushes <L, ELI, EL>
Y: -<L, ELI, EL> Y pops <L, ELI, EL>
This means that Y signals to X label L for an LDP tunnel. E can be one of:
这意味着Y向LDP隧道的X标签L发送信号。E可以是以下各项之一：
0: meaning egress is NOT entropy label capable or
0：表示出口不支持熵标签或
1: meaning egress is entropy label capable
1：表示出口具有熵标签功能
The line with LS: shows the label stack on the wire. Below that is the operation that each LSR does in the data plane, where + means push the following label stack, - means pop the following label stack, L~L' means swap L with L'.
带有LS:的线显示导线上的标签堆栈。下面是每个LSR在数据平面中执行的操作，其中+表示推动下面的标签堆栈，-表示弹出下面的标签堆栈，L~L'表示用L交换L。
The following figures illustrate several simple intra-AS LDP tunnels. The first diagram shows ultimate hop popping (UHP) with the ingress inserting an EL, the second UHP with no ELs, the third PHP with ELs, and finally, PHP with no ELs, but also with an application label AL (which could, for example, be a VPN label).
下图说明了几个简单的内部AS LDP隧道。第一个图显示了入口插入EL的终极跳跳跳（UHP），第二个UHP没有ELs，第三个PHP有ELs，最后一个PHP没有ELs，但也有一个应用程序标签AL（例如，可以是VPN标签）。
Note that, in all the cases below, the MPLS application does not matter; it may be that X pushes some more labels (perhaps for a VPN or VPLS) below the ones shown, and Y pops them.
请注意，在以下所有情况下，MPLS应用程序并不重要；可能是X在显示的标签下面再推一些标签（可能是VPN或VPL），Y会弹出它们。
A: <--- [TL4, 1]
B: <-- [TL3, 1]
W: <-- [TL2, 1]
Y: <-- [TL0, 1]
X --------------- A --------- B --- W ---------- Y
Data Plane:
X-A: <TL4, ELI, EL>
A-B: <TL3,ELI,EL>
B-W: <TL2,ELI,EL>
W-Y: <TL0,ELI,EL>
Label Stack Operations:
X: +<TL4, ELI, EL>
A: TL4~TL3
B: TL3~TL2
W: TL2~TL0
Y: -<TL0, ELI, EL>
A: <--- [TL4, 1]
B: <-- [TL3, 1]
W: <-- [TL2, 1]
Y: <-- [TL0, 1]
X --------------- A --------- B --- W ---------- Y
Data Plane:
X-A: <TL4, ELI, EL>
A-B: <TL3,ELI,EL>
B-W: <TL2,ELI,EL>
W-Y: <TL0,ELI,EL>
Label Stack Operations:
X: +<TL4, ELI, EL>
A: TL4~TL3
B: TL3~TL2
W: TL2~TL0
Y: -<TL0, ELI, EL>
Figure 2: LDP with UHP; Ingress Inserts ELs
图2：超高压LDP；入口插件
A: <--- [TL4, 1]
B: <-- [TL3, 1]
W: <-- [TL2, 1]
Y: <-- [TL0, 1]
X --------------- A --------- B --- W ---------- Y
Data Plane:
X-A: <TL4>
A-B: <TL3>
B-W: <TL2>
W-Y: <TL0>
Label Stack Operations:
X: +<TL4>
A: TL4~TL3
B: TL3~TL2
W: TL2~TL0
Y: -<TL0>
A: <--- [TL4, 1]
B: <-- [TL3, 1]
W: <-- [TL2, 1]
Y: <-- [TL0, 1]
X --------------- A --------- B --- W ---------- Y
Data Plane:
X-A: <TL4>
A-B: <TL3>
B-W: <TL2>
W-Y: <TL0>
Label Stack Operations:
X: +<TL4>
A: TL4~TL3
B: TL3~TL2
W: TL2~TL0
Y: -<TL0>
Figure 3: LDP with UHP; Ingress Does Not Insert ELs
图3：超高压LDP；入口不插入ELs
Note that in Figure 3, above, the Egress Y is signaling it is EL-capable, but the Ingress X has chosen not to insert ELs.
请注意，在上面的图3中，出口Y发出信号表示它具有EL能力，但入口X选择不插入EL。
A: <--- [TL4, 1]
B: <-- [TL3, 1]
W: <-- [TL2, 1]
Y: <-- [3, 1]
X --------------- A --------- B --- W ---------- Y
Data Plane:
X-A: <TL4, ELI, EL>
A-B: <TL3,ELI,EL>
B-W: <TL2,ELI,EL>
W-Y: <ELI,EL>
Label Stack Operations:
X: +<TL4, ELI, EL>
A: TL4~TL3
B: TL3~TL2
W: -TL2
Y: -<ELI, EL>
A: <--- [TL4, 1]
B: <-- [TL3, 1]
W: <-- [TL2, 1]
Y: <-- [3, 1]
X --------------- A --------- B --- W ---------- Y
Data Plane:
X-A: <TL4, ELI, EL>
A-B: <TL3,ELI,EL>
B-W: <TL2,ELI,EL>
W-Y: <ELI,EL>
Label Stack Operations:
X: +<TL4, ELI, EL>
A: TL4~TL3
B: TL3~TL2
W: -TL2
Y: -<ELI, EL>
Figure 4: LDP with PHP; Ingress Inserts ELs
图4：使用PHP的LDP；入口插件
A: <--- [TL4, 1]
B: <-- [TL3, 1]
W: <-- [TL2, 1]
Y: <-- [3, 1]
VPN: <------------------------------------------ [AL]
X --------------- A --------- B --- W ---------- Y
Data Plane:
X-A: <TL4, AL>
A-B: <TL3, AL>
B-W: <TL2, AL>
W-Y: <AL>
Label Stack Operations:
X: +<TL4, AL>
A: TL4~TL3
B: TL3~TL2
W: -TL2
Y: -<AL>
A: <--- [TL4, 1]
B: <-- [TL3, 1]
W: <-- [TL2, 1]
Y: <-- [3, 1]
VPN: <------------------------------------------ [AL]
X --------------- A --------- B --- W ---------- Y
Data Plane:
X-A: <TL4, AL>
A-B: <TL3, AL>
B-W: <TL2, AL>
W-Y: <AL>
Label Stack Operations:
X: +<TL4, AL>
A: TL4~TL3
B: TL3~TL2
W: -TL2
Y: -<AL>
Figure 5: LDP with PHP + VPN; Ingress Does Not Insert ELs
Figure 5: LDP with PHP + VPN; Ingress Does Not Insert ELs
Note that in Figure 5, above, the Egress Y is signaling it is EL-capable, but the Ingress X has chosen not to insert ELs.
请注意，在上面的图5中，出口Y发出信号表示它具有EL能力，但入口X选择不插入EL。
A: <--- [TL4, 1]
B: <-- [TL3, 1]
W: <-- [TL2, 1]
Y: <-- [3, 1]
VPN: <--------------------------------------------- [AL]
X --------------- A ------------ B --- W ---------- Y
Data Plane:
X-A: <TL4,ELI,EL,AL>
A-B: <TL3,ELI,EL,AL>
B-W: <TL2,ELI,EL,AL>
W-Y: <ELI,EL,AL>
Label Stack Operations:
X: +<TL4,ELI,EL,AL>
A: TL4~TL3
B: TL3~TL2
W: -TL2
Y: -<ELI,EL,AL>
A: <--- [TL4, 1]
B: <-- [TL3, 1]
W: <-- [TL2, 1]
Y: <-- [3, 1]
VPN: <--------------------------------------------- [AL]
X --------------- A ------------ B --- W ---------- Y
Data Plane:
X-A: <TL4,ELI,EL,AL>
A-B: <TL3,ELI,EL,AL>
B-W: <TL2,ELI,EL,AL>
W-Y: <ELI,EL,AL>
Label Stack Operations:
X: +<TL4,ELI,EL,AL>
A: TL4~TL3
B: TL3~TL2
W: -TL2
Y: -<ELI,EL,AL>
Figure 6: LDP with PHP + VPN; Ingress Inserts ELs
Figure 6: LDP with PHP + VPN; Ingress Inserts ELs
Figure 7 illustrates "LDP over RSVP-TE" tunnels. X and Y are the ingress and egress (respectively) of the LDP tunnel; A and W are the ingress and egress of the RSVP-TE tunnel. It is assumed that both the LDP and RSVP-TE tunnels have PHP.
图7说明了“RSVP-TE上的LDP”隧道。X和Y分别为LDP隧道的入口和出口；A和W是RSVP-TE隧道的入口和出口。假设LDP和RSVP-TE隧道都有PHP。
LDP: <--- [L4, 1] <------- [L3, 1] <--- [3, 1]
RSVP-TE: <-- [Rn, 0]
<-- [3, 0]
X --------------- A --------- B --- W ---------- Y
Data Plane:
X-A: <L4, ELI, EL>
A-B: <Rn,L3,ELI,EL>
B-W: <L3,ELI,EL>
W-Y: <ELI,EL>
Label Stack Operations:
X: +<L4, ELI, EL>
A: <L4~L3>+Rn
B: -Rn
W: -L3
Y: -<ELI, EL>
LDP: <--- [L4, 1] <------- [L3, 1] <--- [3, 1]
RSVP-TE: <-- [Rn, 0]
<-- [3, 0]
X --------------- A --------- B --- W ---------- Y
Data Plane:
X-A: <L4, ELI, EL>
A-B: <Rn,L3,ELI,EL>
B-W: <L3,ELI,EL>
W-Y: <ELI,EL>
Label Stack Operations:
X: +<L4, ELI, EL>
A: <L4~L3>+Rn
B: -Rn
W: -L3
Y: -<ELI, EL>
Figure 7: LDP with ELs over RSVP-TE Tunnels without ELs
图7：不带ELs的RSVP-TE隧道上带ELs的LDP
For each unicast tunnel starting at an ingress LSR X, X must remember whether the egress for that tunnel can process entropy labels. X does not have to keep state per application running over that tunnel. However, an ingress PE can choose on a per-application basis whether or not to insert ELs. For example, X may have an application for which it does not wish to use ECMP (e.g., circuit emulation) or for which it does not know which keys to use for load balancing (e.g., Appletalk over a pseudowire). In either of those cases, X may choose not to insert entropy labels but may choose to insert entropy labels for an IP VPN over the same tunnel.
对于从入口LSR X开始的每个单播隧道，X必须记住该隧道的出口是否可以处理熵标签。X不必为通过该通道运行的每个应用程序保持状态。但是，ingress PE可以根据每个应用选择是否插入ELs。例如，X可能具有其不希望使用ECMP（例如，电路仿真）的应用程序，或者其不知道用于负载平衡的密钥（例如，伪线上的Appletalk）。在这两种情况中，X可以选择不插入熵标签，但可以选择在同一隧道上为IP VPN插入熵标签。
This document describes advertisement of the capability to support receipt of entropy labels that an ingress LSR may insert in MPLS packets in order to allow transit LSRs to attain better load balancing across LAG and/or ECMP paths in the network.
本文档描述了支持接收熵标签的能力的广告，入口LSR可将熵标签插入MPLS分组中，以允许传输LSR在网络中的滞后和/或ECMP路径上实现更好的负载平衡。
This document does not introduce new security vulnerabilities to LDP, BGP or RSVP-TE. Please refer to the Security Considerations sections of these protocols ([RFC5036], [RFC4271], and [RFC3209]) for security mechanisms applicable to each.
本文件未向LDP、BGP或RSVP-TE引入新的安全漏洞。请参阅这些协议的安全注意事项部分（[RFC5036]、[RFC4271]和[RFC3209]），了解适用于每种协议的安全机制。
Given that there is no end-user control over the values used for entropy labels, there is little risk of entropy label forgery, which could cause uneven load balancing in the network. Note that if the EL value is calculated only based on packet headers, then a relatively efficient wiretapping interface could be added depending on the function used to generate the EL value. An implementation may protect against this by adding some other input to the generation of the EL values that would make it harder to build a table of EL values to tap given knowledge of the keys from the packet. For example, the ingress LSR could generate a random input to the EL generation process. In practice, many ECMP hashing algorithms contain a random factor in any case so as to avoid polarization issues.
由于最终用户无法控制熵标签的值，因此熵标签伪造的风险很小，这可能会导致网络中的负载平衡不均衡。请注意，如果仅基于包头计算EL值，则可以根据用于生成EL值的函数添加相对有效的窃听接口。实现可以通过向EL值的生成添加一些其他输入来防止这种情况的发生，这将使构建EL值表以从分组中获取密钥的给定知识变得更加困难。例如，入口LSR可以生成EL生成过程的随机输入。在实践中，许多ECMP哈希算法在任何情况下都包含一个随机因子，以避免极化问题。
If Entropy Label Capability is not signaled from an egress PE to an ingress PE, due to, for example, malicious configuration activity on the egress PE, then the PE will fall back to not using entropy labels for load balancing traffic over LAG or ECMP paths, which is, in general, no worse than the behavior observed in current production networks. That said, it is recommended that operators monitor changes to PE configurations and, more importantly, the fairness of load distribution over LAG or ECMP paths. If the fairness of load distribution over a set of paths changes that could indicate a misconfiguration, bug, or other non-optimal behavior on their PEs, and they should take corrective action.
如果由于例如出口PE上的恶意配置活动，熵标签能力没有从出口PE向入口PE发出信号，则PE将退回到不使用熵标签来通过延迟或ECMP路径进行负载平衡流量，这通常不会比当前生产网络中观察到的行为更糟。也就是说，建议运营商监控PE配置的变化，更重要的是，监控滞后或ECMP路径上负载分配的公平性。如果一组路径上负载分配的公平性发生变化，可能表明PEs上存在错误配置、错误或其他非最佳行为，则应采取纠正措施。
IANA has allocated a reserved label for the Entropy Label Indicator (ELI) from the "Multiprotocol Label Switching Architecture (MPLS) Label Values" registry.
IANA已从“多协议标签交换体系结构（MPLS）标签值”注册表中为熵标签指示器（ELI）分配了保留标签。
IANA has allocated the value of 0x0206 from the IETF Consensus range (0x0001-0x07FF) in the "TLV Type Name Space" registry as the "Entropy Label Capability TLV".
IANA已将“TLV类型名称空间”注册表中IETF共识范围（0x0001-0x07FF）中的0x0206值分配为“熵标签能力TLV”。
IANA has allocated the Path Attribute Type Code 28 from the "BGP Path Attributes" registry as the "BGP Entropy Label Capability Attribute".
IANA已将“BGP路径属性”注册表中的路径属性类型代码28分配为“BGP熵标签能力属性”。
IANA has allocated a new bit from the "Attribute Flags" sub-registry of the "Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" registry.
IANA已从“资源预留协议流量工程（RSVP-TE）参数”注册表的“属性标志”子注册表中分配了一个新位。
Bit | Name | Attribute | Attribute | RRO
No | | Flags Path | Flags Resv |
----+--------------------------+------------+------------+-----
9 Entropy Label Capability Yes Yes No
Bit | Name | Attribute | Attribute | RRO
No | | Flags Path | Flags Resv |
----+--------------------------+------------+------------+-----
9 Entropy Label Capability Yes Yes No
We wish to thank Ulrich Drafz for his contributions, as well as the entire "hash label" team for their valuable comments and discussion.
我们要感谢Ulrich Drafz的贡献，以及整个“哈希标签”团队的宝贵意见和讨论。
Sincere thanks to Nischal Sheth for his many suggestions and comments and for his careful reading of the document, especially with regard to data plane processing of entropy labels.
衷心感谢Nischal Sheth提出的许多建议和意见，以及他对本文件的仔细阅读，特别是在熵标签的数据平面处理方面。
Most of the work Kireeti Kompella did on this document was done while he was at Juniper Networks. He has since moved to Contrail Systems.
Kireeti Kompella在这个文档上所做的大部分工作都是在Juniper Networks期间完成的。此后，他转向了轨迹系统。
[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月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001.
[RFC3107]Rekhter，Y.和E.Rosen，“在BGP-4中携带标签信息”，RFC 3107，2001年5月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007.
[RFC5036]Andersson，L.，Minei，I.，和B.Thomas，“LDP规范”，RFC 5036，2007年10月。
[RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, February 2009.
[RFC5420]Farrel，A.，Papadimitriou，D.，Vasseur，JP.，和A.Ayyangarps，“使用资源预留协议流量工程（RSVP-TE）对MPLS LSP建立的属性进行编码”，RFC 5420，2009年2月。
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4201]Kompella，K.，Rekhter，Y.，和L.Berger，“MPLS流量工程（TE）中的链路捆绑”，RFC 42012005年10月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter，Y.，Li，T.，和S.Hares，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[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月。
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447]Martini，L.，Rosen，E.，El Aawar，N.，Smith，T.，和G.Heron，“使用标签分发协议（LDP）的伪线设置和维护”，RFC 4447，2006年4月。
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC4875]Aggarwal，R.，Papadimitriou，D.，和S.Yasukawa，“资源预留协议的扩展-点对多点TE标签交换路径（LSP）的流量工程（RSVP-TE）”，RFC 4875，2007年5月。
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC5884]Aggarwal，R.，Kompella，K.，Nadeau，T.，和G.Swallow，“MPLS标签交换路径（LSP）的双向转发检测（BFD）”，RFC 58842010年6月。
[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 2011.
[RFC6388]Wijnands，IJ.，Minei，I.，Kompella，K.，和B.Thomas，“点对多点和多点对多点标签交换路径的标签分发协议扩展”，RFC 6388，2011年11月。
[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月。
In the case of unlabeled IPv4 (Internet) traffic, the best practice is for an egress LSR to propagate eBGP learned routes within a Service Provider's Autonomous System after resetting the BGP next-hop attribute to one of its loopback IP addresses. That loopback IP address is injected into the Service Provider's IGP and, concurrently, a label assigned to it via LDP. Thus, when an ingress LSR is performing a forwarding lookup for a BGP destination, it recursively resolves the associated next hop to a loopback IP address and associated LDP label of the egress LSR.
在未标记IPv4（互联网）流量的情况下，最佳实践是出口LSR在将BGP下一跳属性重置为其一个环回IP地址后，在服务提供商的自治系统内传播eBGP学习的路由。该环回IP地址被注入到服务提供商的IGP中，同时通过LDP分配给它一个标签。因此，当入口LSR对BGP目的地执行转发查找时，它递归地将相关联的下一跳解析为出口LSR的环回IP地址和相关联的LDP标签。
Thus, in the context of unlabeled IPv4 traffic, the LDP Entropy Label Capability TLV will typically be applied only to the FEC for the loopback IP address of the egress LSR, and the egress LSR need not announce an Entropy Label Capability for the eBGP learned route.
因此，在未标记的IPv4业务的上下文中，LDP熵标签能力TLV通常仅应用于出口LSR的环回IP地址的FEC，并且出口LSR不需要宣布eBGP学习路由的熵标签能力。
Authors' Addresses
作者地址
Kireeti Kompella Contrail Systems 2350 Mission College Blvd. Santa Clara, CA 95054 US
Kireeti Kompella轨迹系统2350 Mission College Blvd。美国加利福尼亚州圣克拉拉95054
EMail: kireeti.kompella@gmail.com
EMail: kireeti.kompella@gmail.com
John Drake Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US
约翰·德雷克·朱尼珀网络公司美国加利福尼亚州桑尼维尔市马蒂尔达大道北1194号，邮编94089
EMail: jdrake@juniper.net
EMail: jdrake@juniper.net
Shane Amante Level 3 Communications, Inc. 1025 Eldorado Blvd Broomfield, CO 80021 US
美国科罗拉多州布鲁姆菲尔德埃尔多拉多大道1025号Shane Amante三级通信公司，邮编80021
EMail: shane@level3.net
EMail: shane@level3.net
Wim Henderickx Alcatel-Lucent Copernicuslaan 50 2018 Antwerp Belgium
Wim Henderickx Alcatel-Lucent Copernicuslaan 50 2018比利时安特卫普
EMail: wim.henderickx@alcatel-lucent.com
EMail: wim.henderickx@alcatel-lucent.com
Lucy Yong Huawei USA 5340 Legacy Dr. Plano, TX 75024 US
Lucy Yong Huawei USA 5340 Legacy Dr.Plano，德克萨斯州75024美国
EMail: lucy.yong@huawei.com
EMail: lucy.yong@huawei.com