[要約] RFC 6790は、MPLS転送におけるエントロピー・ラベルの使用に関する規格であり、エントロピー・ラベルの目的は、トラフィックの均等な分散と負荷分散を実現することです。
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ネットワーク間のロードバランシングを改善する方法を提案します。概念を定義し、エントロピーラベルが有用である理由を説明し、最大の利益を可能にするエントロピーラベルのプロパティを列挙し、さまざまなアプリケーションでどのように通知および使用できるかを示します。このドキュメントは、RFC 3031、3107、3209、および5036を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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.
プロバイダーはネットワークを拡張する際に、いくつかの手法を使用してノード間の帯域幅を拡大します。広く使用されている2つの手法は、リンク集約グループ（LAG）と等コストマルチパス（ECMP）です。 LAGは、隣接する2つのノード間で複数の物理回路を結合するために使用されるため、上位層のプロトコルでは、単一の高帯域幅の「仮想」パイプのように見えます。 ECMPは、1つ以上のホップで分離された2つのノード間で使用され、ネットワーク内のいくつかの最短パスでのロードバランシングを可能にします。これは通常、送信元と宛先のペア間にいくつかの等コストパスが存在するように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.
この詳細な検査の必要性を排除する1つの方法は、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.
エントロピーラベルが適切なレベルの「エントロピー」をラベルスタックに導入するため、MPLSパケットのラベルスタック全体を中継LSRで使用してロードバランシングを実行できます。
There are five key reasons why this is beneficial:
これが有益である主な理由は5つあります。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The following acronyms/initialisms are used:
次の頭字語/頭文字が使用されています。
BoS: Bottom of Stack
BoS：スタックの一番下
CE: Customer Edge
CE：カスタマーエッジ
ECMP: Equal Cost Multi-Path
ECMP：等コストマルチパス
EL: Entropy Label
EL：エントロピーラベル
ELC: Entropy Label Capability
ELC：エントロピーラベル機能
ELI: Entropy Label Indicator
ELI：エントロピーラベルインジケーター
FEC: Forwarding Equivalence Class
FEC：転送同等クラス
LAG: Link Aggregation Group
LAG：リンク集約グループ
LER: Label Edge Router
LER：ラベルエッジルーター
LSP: Label Switched Path
LSP：ラベルスイッチドパス
LSR: Label Switching Router
LSR：ラベルスイッチングルーター
PE: Provider Edge
PE：プロバイダーエッジ
PW: Pseudowire
説明：シュードビル
PHP: Penultimate Hop Popping
PHP：最後から2番目のホップの飛び出し
TC: Traffic Class
TC：トラフィッククラス
TTL: Time to Live
TTL：Time to Live
UHP: Ultimate Hop Popping
UHP：Ultimate Hop Popping
VPLS: Virtual Private LAN (Local Area Network) Service
VPLS：Virtual Private LAN（Local Area Network）Service
VPN: Virtual Private Network
VPN：仮想プライベートネットワーク
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).
ラベルスタック（たとえば3つのラベル）は、<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、PW、VPLS、IP VPNを転送する非常に成功した汎用転送素材です。各タイプのプロトコル内には、通常、いくつかのバリアントが存在し、それぞれに異なるセットのロードバランシングキーがあります。たとえば、IPおよびイーサネットの場合はIPv4、IPv6、IPv4のIPv6などです。 PW用のATM、フレームリレーなど。 Ethernet over PWカプセル化、ATM over 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. CEに必要なサービスを適用します。
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.
ラベルスタックで負荷分散情報をエンコードするには、主に2つの方法があります。 1つ目は、特定のForwarding Equivalence Class（FEC）に複数のラベルを割り当てます。これらのラベルは転送セマンティクスの点では同等ですが、複数のラベルを使用すると、同じFECに属するフローにラベルを柔軟に割り当てることができます。このアプローチには、ラベルベースのロードバランシングを使用するかどうかに関係なく、ラベルスタックの深さが同じであるという利点があります。その結果、通過LSRと出力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.
もう1つの方法では、負荷分散情報をラベルスタックの追加ラベルとしてエンコードし、ラベルスタックの深さを1つ増やします。このアプローチでは、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に1組のラベルを割り当てます。1つはその下にエントロピーラベルが必要で、もう1つはそうではありません。 2）ラベル（「エントロピーラベルインジケーター」）を使用して、次のラベルがエントロピーラベルであることを示します。 3）混乱の可能性がない場合にのみ、エントロピーラベルを許可します。 1つ目は、ネットワークのコントロールプレーンとデータプレーンの状態を2倍にします。最後は制限が多すぎます。ここで採用したアプローチは2番目です。上記の両方の選択を行う際のトレードオフは、ネットワークの制御とデータプレーンの状態ではなく、ラベルスタックの深さを増やすことです。
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:
最後に、ELを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のトンネリングプロトコルは少数ですが、アプリケーションの数は増え続けています。トンネルベースでELを定義することは、標準の簡素化、開発の低下、相互運用性、およびテストの労力を意味します。
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. データプレーンでのアプリケーションラベルの処理は、トンネルラベルの処理よりも複雑です。したがって、前者よりも後者にＥＬ処理を負担させる方が好ましい。
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. ELをトンネルに関連付けると、LDP-over-RSVP-TEでも、キャリアのキャリアVPNでも、階層の処理が簡単になります。階層内の各レイヤーは、ELが必要かどうかを個別に選択できます。
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.
このアプローチのコストは、ELIが必須になることです。ここでも、トレードオフはラベルスタックのサイズです。要約すると、エントロピーラベルを使用するためのラベルスタックの正味の増加は2つです。ELI用に予約されたラベルとエントロピーラベル自体です。
An entropy label (as used here) is a label:
エントロピーラベル（ここで使用）はラベルです。
1. that is not used for forwarding;
1. 転送には使用されません。
2. that is not signaled; and 3. whose only purpose in the label stack is to provide "entropy" to improve load balancing.
2.通知されない; 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]に値があってはなりません（MUST NOT）。
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の予約済みラベルです。ELIおよびELのTTL、TC、および「Bottom of Stack」（BoS）フィールド[RFC3032]の値を設定する方法については、セクション4.2で説明します。
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は暗黙のnullラベルである可能性があることに注意してください。その場合、ラベルスタックには表示されません。）YはELIを認識し、ELIとELの2つのラベルをポップします。次に、Yは残りのパケットヘッダーを通常どおりに処理します。これには、おそらくさらにELI + ELペアを使用して、トンネル終端の追加処理が必要になる場合があります。 Yは、最後のトンネル終了を処理するときに、そのトンネルTLまたはELIのTC値に基づいてパケットをエンキューし、残りのパケットヘッダーのTTLを計算するためにトンネルTLまたはELIの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はパケットを破棄し、エラーをログに記録する必要があります（MUST）。 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がシグナリングを介して特定のトンネルでELを処理できることを示す場合、入力LSR Xはそのトンネルに入るパケットにELを挿入するかどうかを選択できます。 Yは両方のケースを処理する必要があります。
The steps that X performs to insert ELs are as follows:
ELを挿入するためにXが実行する手順は次のとおりです。
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がELを処理できることを示していない場合は、<TL>をパケットにプッシュします。 YがトンネルのELを処理できることを示している場合は、<TL、ELI、EL>をパケットにプッシュします。 Xは、TLの場合と同じELIのTTLおよびTCフィールドを配置する必要があります（SHOULD）。 Xは、ELIがLSPに沿ったどの時点でもトップラベルとして公開されないことがわかっている場合、TTLおよびTCフィールドに異なる値を選択できます（PHPが使用され、ELIとELが削除されていない場合に発生する可能性があります）。最後から2番目のホップ（セクション4.4を参照）。ELIのBoSビットはゼロでなければなりません（つまり、BoSが設定されていません）。誤って転送に使用されないようにするには、ELのTTLをゼロにする必要があります。 ELの値は任意で、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は、さらにトンネル階層が必要かどうかを判断します。そうである場合、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. EL機能のシグナリングがトンネルに関連付けられている場合でも、Xは負荷分散情報を計算し、着信アプリケーションパケットに基づいて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が前に付けられます）。そのトンネルの出力で、そのトンネルのELを処理できることが示されている場合に限ります。
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がそのトンネルのエントロピーラベルを処理できることを示していない限り、特定のトンネルのエントロピーラベルを含めてはなりません（MUST NOT）。
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. 1つの方向のエントロピーラベルのシグナリングおよび使用（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）のみでロードバランスを選択できます（MAY）。それ以外の場合は、ロードバランス機能のキーとして、可能な限りラベルスタック全体を使用する必要があります。いずれの場合も、予約済みラベルは、負荷分散機能のキーとして使用してはなりません。
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.
一部のトランジットLSRは、ラベルスタックを超えて、より良いロードバランシング情報を求めます。これは、ネットワークにおける単純な下位互換性のあるアプローチであり、一部の入力LSRがELを課し、他は課しません。ただし、ELが実際に存在し、LSRからのより多くのパケット処理が必要な場合、これは増分値に制限があります。トランジット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と最上位ラベルとしてパケットを検出した場合、ELCと暗黙のnullの両方を通知する出力LSRは、ELIと次のラベル（ELである必要があります）をポップする必要があります。 [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.
最後から2番目のホップの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は、指定されたトンネルでエントロピーラベル（以降、「エントロピーラベル機能」またはELCと呼ばれる）を処理する能力を入力LSRに通知できます。特に、YがPHPが実行されることを示す暗黙のnullラベルを通知した場合でも、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が関連するLDPトンネルのエントロピーラベルを処理できることを入力LSRに示します。 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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に設定する必要があります。ELCTLVがレシーバーによって理解されない場合は、無視する必要があります。
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に設定する必要があります。ELCTLVはホップバイホップで伝播されるため、理解できないノードによっても転送されるはずです。
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は、ELC TLVを自身のFの広告に含めてはなりません。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 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.
たとえば[RFC3107]で説明されているように、BGP [RFC4271]を使用してネットワーク層到達可能性情報（NLRI）を配布する場合、BGP UPDATEメッセージにパス属性の一部としてELC属性が含まれることがあります。これは、値28のオプションの推移的なBGP属性です。この属性を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:
UPDATEを発信するBGPスピーカーSには、次の両方が当てはまる場合にのみ、ELC属性を含める必要があります。
A1: S sets the BGP NEXT_HOP attribute to itself AND
A1：SはBGP NEXT_HOP属性をそれ自体に設定しますAND
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属性を持つUPDATE Uを受信するとします。 Tには2つの選択肢があります。 Tは、次のいずれかに該当する場合、ELC属性を使用してUを再アドバタイズすることができます。
B1: T does not change the NEXT_HOP attribute OR
B1：TはNEXT_HOP属性を変更しないOR
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はUPDATE U 'のELC属性を含めることができます。
C1: T sets the NEXT_HOP attribute of U' to itself AND
C1：TはU 'のNEXT_HOP属性をそれ自体に設定し、かつ
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.
LSP_ATTRIBUTESオブジェクト[RFC5420]の属性フラグTLVのエントロピーラベル機能（ELC）フラグを使用して、RSVP-TE [RFC3209]でエントロピーラベルのサポートが通知されます。 Pathメッセージに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のELのシグナリングと処理の詳細は、将来のドキュメントで指定されます。
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 traceroute手順により、入力LSRは、すべてのパスで出力LSRにパケットを送信するために使用できるラベル範囲を取得できます。これは、入力LSRが特定の出力LSRへの特定のパスに沿ってトランジットLSRに順番に要求してラベル範囲を返すようにすることで機能し、パケットにその範囲のラベルが含まれると、応答するトランジットLSRがそのパケットを送信するそのパスの出力インターフェイス。入力は、トランジットLSR NからトランジットLSR N + 1に返されるラベル範囲を提供します。これにより、指定された範囲とスパンが同じかそれより短いラベル範囲が返されます。パスに沿ってパケットを転送するために、最後から2番目のトランジット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 tracerouteの手順では、ラベルスタックのどこにラベル範囲の値を配置するか、詳細なパケット検査を許可するかどうか、許可する場合はどのキーとキー値を使用するかを指定していません。
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 tracerouteを更新します。したがって、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>
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を挿入するイングレス、ELを使用しない2番目のUHP、ELを使用する3番目のPHP、最後にELを使用しないPHPであるが、アプリケーションラベル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またはVPLSの場合）を表示されているラベルの下にプッシュし、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>
Figure 2: LDP with UHP; Ingress Inserts ELs
図2：UHPを使用したLDP; Ingress Inserts ELs
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：UHPを使用したLDP; IngressがELを挿入しない
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>
Figure 4: LDP with PHP; Ingress Inserts ELs
図4：PHPを使用したLDP; Ingress Inserts ELs
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
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>
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は、「LDP over RSVP-TE」トンネルを示しています。 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>
Figure 7: LDP with ELs over RSVP-TE Tunnels without ELs
図7：ELのないRSVP-TEトンネル上のELのある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は、そのトンネルで実行されているアプリケーションごとに状態を保持する必要はありません。ただし、入力PEは、アプリケーションごとにELを挿入するかどうかを選択できます。たとえば、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がネットワーク内のLAGパスやECMPパス全体でより良いロードバランシングを実現できるように、入力LSRがMPLSパケットに挿入するエントロピーラベルの受信をサポートする機能のアドバタイズについて説明します。
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は、LAGまたはECMPパス上のトラフィックの負荷分散にエントロピーラベルを使用しないようにフォールバックします。 、これは一般的に、現在の本番ネットワークで観察された動作よりも悪いことではありません。とはいえ、オペレーターはPE構成の変更を監視し、さらに重要なことに、LAGまたはECMPパス上の負荷分散の公平性を監視することをお勧めします。パスのセットでの負荷分散の公平性が変化し、PEの設定ミス、バグ、またはその他の非最適な動作を示している可能性がある場合は、修正措置を講じる必要があります。
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は、「Resource Reservation Protocol-Traffic Engineering（RSVP-TE）Parameters」レジストリの「Attribute Flags」サブレジストリから新しいビットを割り当てました。
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.
キリーティコンペラがこのドキュメントで行った作業のほとんどは、ジュニパーネットワークスにいたときに行われました。その後、彼はContrail Systemsに異動しました。
[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]ローゼン、E。、ヴィスワナサン、A。、およびR.キャロン、「マルチプロトコルラベルスイッチングアーキテクチャ」、RFC 3031、2001年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]ローゼン、E。、タッパン、D。、フェドルコフ、G。、レクター、Y。、ファリナッチ、D。、リー、T。、およびA.コンタ、「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、「Carrying Label Information in 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：Extensions for RSVP for LSP Tunnels」、RFC 3209、12月2001年。
[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 4201、2005年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、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年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、「Detecting Multi-Protocol Label Switched（MPLS）Data Plane Failures」、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、「Extensions to Resource Reservation Protocol-Traffic Engineering（RSVP-TE）for Point-to-Multipoint TE Label Switched Paths（LSPs）」、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 5884、2010年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]ブライアント、S。、フィルスフィルス、C。、ドラフズ、U。、コンペラ、V。、リーガン、J。、およびS.アマンテ、「MPLSパケット交換ネットワーク上の疑似配線のフロー対応トランスポート」、RFC 6391 、2011年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（インターネット）トラフィックの場合、BGPネクストホップ属性をループバックIPアドレスの1つにリセットした後、出力LSRがサービスプロバイダーの自律システム内でeBGP学習ルートを伝播することがベストプラクティスです。そのループバックIPアドレスは、サービスプロバイダーのIGPに注入され、同時にLDPを介してそれに割り当てられたラベルも挿入されます。したがって、入力LSRがBGP宛先の転送ルックアップを実行している場合、関連するネクストホップをループバックIPアドレスおよび出力LSRの関連する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
キリーティコンペラコントレイルシステムズ2350ミッションカレッジブルバード。サンタクララ、CA 95054 US
EMail: kireeti.kompella@gmail.com
John Drake Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US
John Drake Juniper Networks 1194 N. Mathilda Ave. Sunnyvale、CA 94089 US
EMail: jdrake@juniper.net
Shane Amante Level 3 Communications, Inc. 1025 Eldorado Blvd Broomfield, CO 80021 US
Shane Amante Level 3 Communications、Inc. 1025 Eldorado Blvd Broomfield、CO 80021 US
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
Lucy Yong Huawei USA 5340 Legacy Dr. Plano, TX 75024 US
Lucy Yong Huawei USA 5340 Legacy Dr. Plano、TX 75024 US
EMail: lucy.yong@huawei.com