Network Working Group B. Thomas
Request for Comments: 3037 Cisco Systems, Inc.
Category: Informational E. Gray
Zaffire, Inc.
January 2001
LDP Applicability
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
Multiprotocol Label Switching (MPLS) is a method for forwarding packets that uses short, fixed-length values carried by packets, called labels, to determine packet nexthops. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document describes the applicability of a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths.
マルチプロトコルラベルスイッチング（MPLS）は、パケットnexthopsを決定するために、パケットによって運ばれる短い固定長の値と呼ばれるラベルを、使用するパケットを転送するための方法です。 MPLSの基本的な考え方は、二つのラベルスイッチングルータ（LSRには）の間およびそれらを介してトラフィックを転送するために使用されるラベルの意味に同意しなければならないということです。この共通の理解は、1 LSRは自身が行ったラベルバインディングの別通知することにより、ラベル配布プロトコルと呼ばれる一連の手順を、使用することによって達成されます。この文書は、のLSRが正常にルーティングパスに沿ってMPLS転送をサポートするためのラベルを配布れる（ラベル配布プロトコルのための）LDPと呼ばれるこのような手順のセットの適用を記載します。
A label distribution protocol is a set of procedures by which one Label Switching Router (LSR) informs another of the meaning of labels used to forward traffic between and through them.
ラベル配布プロトコルは、ルータ（LSR）をスイッチングつのラベルの間およびそれらを介してトラフィックを転送するために使用されるラベルの意味の別を通知することにより、手順のセットです。
The MPLS architecture allows for the possibility of more than a single method for distributing labels, and a number of different label distribution protocols are being standardized. Existing protocols have been extended so that label distribution can be piggybacked on them, and new protocols have been defined for the explicit purpose of distributing labels.
MPLSアーキテクチャは、ラベルを配布するための単一の方法以上の可能性を可能にし、異なるラベル配布プロトコルの数は、標準化されています。ラベル配布がそれらの上にピギーバックすることができ、新しいプロトコルラベルを配布する明示的な目的のために定義されているように、既存のプロトコルが拡張されています。
This document describes the applicability of the Label Distribution Protocol (LDP), a new protocol for label distribution designed to support label distribution for MPLS forwarding along normally routed paths as determined by destination-based routing protocols. This is sometimes called MPLS hop-by-hop forwarding.
この文書は、ラベル配布プロトコル（LDP）、宛先ベースのルーティングプロトコルによって決定されるように、通常、ルーティングパスに沿ってMPLS転送用ラベル配布をサポートするように設計されたラベル配布のための新しいプロトコルの適用が記載されています。これは、時々、MPLSホップバイホップ転送と呼ばれています。
LDP, together with an IP routing plane and software to program ATM switch or Frame Relay switch cross-connect tables, can implement IP in a network of ATM and/or Frame Relay switches without requiring an overlay or the use of ATM-specific or Frame Relay-specific addressing or routing.
LDP、一緒にATMのネットワークでIPを実装及び/又はオーバーレイまたはATM特異的またはフレームの使用を必要とすることなく、リレースイッチフレームができ、ATMスイッチをプログラムまたはリレークロスコネクトテーブルを切り替えフレームに平面とソフトウェアをIPルーティングとリレー固有のアドレス指定またはルーティング。
LDP is also useful in situations that require efficient hop-by-hop routed tunnels, such as MPLS-based VPN architectures [RFC2574] and tunneling between BGP border routers.
LDPはまた、MPLSベースのVPNアーキテクチャ[RFC2574]とBGP境界ルータ間のトンネルのような効率的なホップバイホップルーティングされたトンネルを、必要とする状況で有用です。
In addition, LDP includes a mechanism that makes it possible to extend it to support MPLS features that go beyond best effort hop-by-hop forwarding.
また、自民党は超えてベストエフォートホップバイホップ転送を行ってMPLS機能をサポートするためにそれを拡張することを可能にする機構を備えています。
As a stand-alone protocol for distributing labels LDP does not rely on the presence of specific routing protocols at every hop along an LSP path in order to establish an LSP. Hence LDP is useful in situations in which an LSP must traverse nodes which may not all support a common piggybacked approach to distributing labels.
LDPはLSPを確立するためにLSPパスに沿ってすべてのホップで特定ルーティングプロトコルの存在に依存しないラベルを配布するためのスタンドアロンプロトコルとして。したがってLDPはLSPがすべてのラベルを配布する一般的なピギーバックアプローチをサポートしていない場合がノードを通過しなければならない状況において有用です。
Traffic Engineering [TE] is expected to be an important MPLS application. MPLS support for Traffic Engineering uses explicitly routed LSPs, which need not follow normally-routed (hop-by-hop) paths.
トラフィックエンジニアリング[TE]は、重要なMPLSアプリケーションであることが予想されます。トラフィックエンジニアリングのためのMPLSのサポートは、（ホップバイホップ）通常のルーティング経路を辿る必要はありません明示的にルーティングされたLSPを、使用しています。
Explicitly routed LSPs may be setup by CR-LDP [CRLDP-AS], a set of extensions to LDP, or by RSVP-TE [RSVP-TE-AS], a set of extensions to RSVP. There is currently no consensus on which of these protocols is technically superior. Therefore, network administrators should make a choice between the two based upon their needs and particular situation.
明示的にルーティングされたLSPはCRLDP [CRLDP-AS]、LDPの拡張セット、またはRSVP-TE [RSVP-TE-AS]、RSVPの拡張セットで設定することがあります。技術的に優れているこれらのプロトコルのどれに何のコンセンサスは現在ありません。そのため、ネットワーク管理者は、自分のニーズや特定の状況に基づいて、2つの間の選択をする必要があります。
The "requirement level" [RFC2026] for LDP is:
「要求レベル」[RFC2026] LDPのためのものです：
Implementation of LDP is recommended for devices that perform MPLS forwarding along normally routed paths as determined by destination-based routing protocols.
LDPの実装は、宛先ベースのルーティングプロトコルによって決定されるように、通常、ルーティングパスに沿ってMPLS転送を行うデバイスに推奨されます。
LDP associates a Forwarding Equivalence Class (FEC) [RFC3031] with each label it distributes. Two LSRs which use LDP to exchange FEC-label binding information are known as "LDP Peers", and we speak of there being an "LDP Session" between them.
LDPは、配布各ラベルに転送等価クラス（FEC）[RFC3031]を関連付けます。 FEC-ラベルバインディング情報を交換するためにLDPを使用する2つのLSRは、「LDPピア」として知られている、と私たちはそれらの間の「LDPセッション」であることが話すされています。
LDP uses TCP for session communication. Use of TCP ensures that session messages are reliably delivered, and that distributed labels and state information associated with LSPs need not be refreshed periodically.
自民党はセッションの通信にTCPを使用しています。 TCPを使用すると、セッションメッセージが確実に配信されることを保証し、LSPを関連付けられている分散型ラベルや状態情報を定期的に更新する必要はありません。
LDP includes a mechanism by which an LSR can discover potential LDP peers. The discovery mechanism makes it unnecessary for operators to explicitly configure each LSR with its LDP peers.
LDPは、LSRが潜在LDPピアを発見することができるメカニズムを含みます。検出メカニズムは、それが不要な事業者が明示的にそのLDPピアと各LSRを設定できるようになります。
When an LSR discovers another LSR it follows the LDP session setup procedure to establish an LDP session. By means of this procedure the LSRs establish a session TCP connection and use it to negotiate parameters for the session, such as the label distribution method to be used (see below). After the LSRs agree on the parameters, the session is operational and the LSRs use the TCP connection for label distribution.
LSRは別のLSRを検出すると、LDPセッションを確立するために、LDPセッションのセットアップ手順に従います。この手順によってのLSRは、セッションTCP接続を確立し（下記参照）は、使用されるラベル配布方法としてセッションのパラメータをネゴシエートするために使用します。 LSRは、パラメータに同意した後、セッションが動作しているとのLSRは、ラベル配布のためのTCP接続を使用します。
LDP supports two different methods for label distribution. An LSR using Downstream Unsolicited distribution advertises FEC-label bindings to its peers when it is ready to forward packets in the FEC by means of MPLS. An LSR using Downstream on Demand distribution provides FEC-label bindings to a peer in response to specific requests from the peer for a label for the FEC.
LDPは、ラベル配布のための2つの異なる方法をサポートしています。 MPLSによってFECでパケットを転送する準備ができたときにダウンストリーム迷惑分布を使用してLSRは、そのピアにFEC-ラベルバインディングをアドバタイズします。オンデマンド配信に川下使用してLSRはFECのためのラベルのピアからの特定の要求に応じて、ピアにFEC-ラベルバインディングを提供します。
LDP allows LSRs flexibility in strategies for retaining learned labels. An LSR using liberal label retention stores all labels learned from peers regardless of whether it currently needs them for forwarding, whereas one using conservative label retention stores only labels for which it has immediate use and releases unneeded labels to the peer that advertised them.
自民党は学んだのラベルを保持するための戦略でのLSRの柔軟性を可能にします。それはそれらをアドバタイズしたピアへの即時使用し、リリース不要なラベルを持っているだけのラベルを保守ラベル保持ストアを使用して1に対し、すべてのラベルにかかわらず、それが現在の転送のためにそれらを必要とするかどうかのピアから学習したリベラルラベル保持ストアを使用してLSR。
In addition, LDP allows flexibility in strategies for when to advertise FEC-label bindings. An LSR using independent control mode advertises FEC-label bindings to peers whenever it sees fit, whereas one using ordered control advertises bindings only when it has previously received a label for the FEC from the FEC nexthop or it is an MPLS egress for the FEC.
また、LDPは、FEC-ラベルバインディングをアドバタイズするときのための戦略の柔軟性を可能にします。 1が注文したコントロールを使用すると、それはFECネクストホップからFECのためのラベルを受け、以前にした唯一のバインディングをアドバタイズするか、それがFECのためのMPLSの出口であるのに対し、独立した制御モードを使用してLSRは、それが適当と考えるたびピアにFEC-ラベルバインディングをアドバタイズします。
Downstream on Demand distribution with conservative label retention and ordered control is appropriate in situations where labels are a relatively scarce resource that must be conserved, and Downstream
保守的なラベル保持してオンデマンド配信のダウンストリームと制御を命じたが、ラベルが保存されている必要があり、比較的希少な資源である状況で適切、かつ下流であります
Unsolicited distribution with liberal label retention and independent control is appropriate where labels are plentiful and need not be carefully conserved. However, the protocol permits other combinations of distribution method, label retention mode and control mode, including hybrid variants of them.
ラベルは豊富であり、慎重に保存されていない必要がある場所リベラルラベル保持及び独立制御と迷惑分布が適切です。しかし、プロトコルはそれらのハイブリッド変異体を含む配信方法、ラベル保持モードと制御モードの他の組み合わせを可能にします。
LDP defines a mechanism for loop detection to protect against forwarding loops in LSPs that traverse non-TTL MPLS clouds; see [RFC3031] for discussion of situations which may benefit from this mechanism. The loop detection mechanism is optional in the sense that it may be disabled by LSR configuration. However, an LDP-compliant LSR must implement it.
LDPは、非TTL MPLSクラウドを横断するLSPに転送ループから保護するために、ループ検出のための機構を定義します。この機構から利益を得ることができる状況での議論のために[RFC3031]を参照。ループ検出メカニズムは、LSRの設定によって無効にすることができるという意味で任意です。しかし、LDPに準拠したLSRは、それを実装する必要があります。
LDP includes an extension mechanism which supports the development of vendor-private and experimental features. This mechanism defines procedures for introducing new types of messages and TLVs, methods an LSR can use for detecting such messages and TLVs, and procedures an LSR must follow when it receives a message or TLV it does not implement. While it is not possible to make every future enhancement backwards compatible, these procedures facilitate the introduction of new capabilities in MPLS networks that include older implementations that do not recognize them.
自民党は、ベンダーのプライベートや実験的な機能の開発をサポートしている拡張メカニズムを含んでいます。この機構は、メッセージのTLVと新しいタイプの、LSRは、そのようなメッセージを検出し、TLVのために使用することができ、そしてそれが実装されていないメッセージまたはTLVを受信したときの手順LSRが従わなければならないメソッドを導入するための手順を定義します。それは、すべての将来の拡張は下位互換性にすることはできませんが、これらの手順は、それらを認識しない古い実装が含まれるMPLSネットワークの新機能の導入を促進します。
The following factors may influence the scalability of LDP implementations:
次の要因は、LDP実装のスケーラビリティに影響を与える可能性があります。
- LDP label distribution is incremental, requiring no periodic refresh of FEC-label bindings.
- LDPラベル配布はFECラベルバインディングのない定期的なリフレッシュを必要としない、インクリメンタルです。
- In situations were label resources may be scarce (ATM and Frame Relay links) the use of the Downstream on Demand distribution method with conservative label retention ensures that only those labels required to support normally-routed paths are allocated and distributed.
- 状況ではラベルリソースは（ATMおよびフレーム・リレー・リンク）不足であってもよい保守的ラベル保持とオンデマンド配信方法で下流の使用は、通常、ルーティングパスをサポートするのに必要なだけのラベルが割り当てと分配されることを確実にしました。
- In situations where label resources are not scarce, the use of the Downstream Unsolicited method with liberal label retention ensures that changes in FEC nexthop from one LDP peer to another require no distribution action to update previously distributed labels.
- ラベルリソースが不足でない状況では、リベラルラベル保持下流迷惑方法の使用は、別のLDPピアからFECネクストホップの変化が以前に分散ラベルを更新する配布アクションを必要としないことを保証します。
- Limitations on the number of TCP connections an LSR supports limit the number of LDP peers the LSR can support.
- TCP接続の数LSRの制限が限界にLSRがサポートできるLDPピアの数をサポートしています。
- Use of the optional path vector based loop detection mechanism imposes additional memory and processing requirements on an LSR, as well as additional LDP traffic. Both impact scalability.
- 任意のパスベクトルベースのループ検出機構の使用は、LSRに追加のメモリおよび処理要件、ならびに追加LDPトラフィックを課します。どちらもインパクトのスケーラビリティ。
LDP defines the optional use of the TCP MD5 Signature Option to protect against the introduction of spoofed TCP segments into LDP session connection streams. LDP use of the TCP MD5 Signature Option is similar to BGP [RFC1771] use of the option specified in [RFC2385].
LDPは、LDPセッション接続ストリームにスプーフィングされたTCPセグメントの導入から保護するためにTCP MD5署名オプションの任意の使用を規定します。 TCP MD5署名オプションのLDPの使用は[RFC2385]で指定されたオプションのBGP [RFC1771]の使用に類似しています。
[CRLDP-AS] J. Ash, M. Girish, E. Gray, B. Jamoussi, G. Wright, "Applicability Statement for CR-LDP", Work in Progress, September 1999.
[CRLDP-AS] J.アッシュ、M. Girish、E.グレー、B. Jamoussi、G.ライト、 "CRLDPための適用に関する声明"、進歩、1999年9月ワーク。
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1771] Rekhter、Y.、およびT.李、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 1771、1995年3月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Heffernanの、A.、 "TCP MD5署名オプションを使用してBGPセッションの保護"、RFC 2385、1998年8月。
[RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999.
[RFC2547]ローゼン、E.およびY. Rekhter、 "BGP / MPLS VPNの"、RFC 2547、1999年3月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036]アンデション、L.、Doolan、P.、フェルドマン、N.、Fredette、A.およびB.トーマス、 "LDP仕様"、RFC 3036、2001年1月。
[RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.とR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[RSVP-TE-AS] Awduche, D., Hannan, A. and X. Xiao, "Applicability State for Extensions to RSVP for LSP-Tunnels", Work in Progress, April 2000.
[RSVP-TE-AS] Awduche、D.、阪南、A.およびX.シャオ、 "適用性国家LSP-トンネルのためのRSVPへの拡張のために"、進歩、2000年4月の作業。
Eric Gray Zaffire, Inc 2630 Orchard Parkway, San Jose, CA 95134-2020
エリックグレーZaffire、株式会社2630オーチャードパークウェイ、カリフォルニア州サンノゼ95134から2020
Phone: 408-894-7362 EMail: ewgray@mindspring.com
電話：408-894-7362 Eメール：ewgray@mindspring.com
Bob Thomas Cisco Systems, Inc. 250 Apollo Dr. Chelmsford, MA 01824
ボブトーマスシスコシステムズ社250アポロ博士チェルムズフォード、MA 01824
Phone: 978-244-8078 EMail: rhthomas@cisco.com
電話：978-244-8078 Eメール：rhthomas@cisco.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。