[要約] RFC 3037は、Label Distribution Protocol（LDP）の適用範囲と目的について説明しています。LDPは、MPLSネットワークでラベルの配布と交換を行うためのプロトコルです。このRFCは、LDPの使用方法とその利点についてのガイドラインを提供しています。
Network Working Group B. Thomas
Request for Comments: 3037 Cisco Systems, Inc.
Category: Informational E. Gray
Zaffire, Inc.
January 2001
LDP Applicability
LDPの適用可能性
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.
Copyright（c）The Internet Society（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）は、ラベルと呼ばれるパケットによって運ばれる短い固定長値を使用してパケットネクソップを決定するパケットを転送する方法です。MPLSの基本的な概念は、2つのラベルスイッチングルーター（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.
ラベル分布プロトコルは、1つのラベルスイッチングルーター（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.
このドキュメントでは、宛先ベースのルーティングプロトコルによって決定されるように、通常ルーティングパスに沿ったMPLS転送のラベル分布をサポートするように設計されたラベル配布の新しいプロトコルであるラベル分布プロトコル（LDP）の適用性について説明します。これは、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は、IPルーティングプレーンおよびソフトウェアをプログラムしてATMスイッチまたはフレームリレースイッチクロスコネクトテーブルをプログラムし、オーバーレイまたは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.
さらに、LDPには、最適な努力を超えた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は、LDPへの拡張セットであるCR-LDP [CRLDP-AS]、またはRSVPの拡張セットであるRSVP-TE [RSVP-TE-AS]によってセットアップされる場合があります。現在、これらのプロトコルのどれが技術的に優れているかについてのコンセンサスはありません。したがって、ネットワーク管理者は、ニーズと特定の状況に基づいて、2つを選択する必要があります。
The "requirement level" [RFC2026] for LDP is:
LDPの「要件レベル」[RFC2026]は次のとおりです。
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]を分配する各ラベルに関連付けます。LDPを使用してFEC-Labelの結合情報を交換する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.
LDPは、セッション通信に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ピアを発見できるメカニズムが含まれています。発見メカニズムにより、オペレーターは各LSRをLDPピアで明示的に構成する必要があります。
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つの異なる方法をサポートしています。下流の未承諾ディストリビューションを使用したLSRは、MPLSによってFECのパケットを転送する準備ができている場合、FEC-Label Bindingsがピアに宣伝します。ダウンストリームオンデマンド配布を使用したLSRは、FECのラベルのピアからの特定の要求に応じて、FEC-labelバインディングをピアに提供します。
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.
LDPは、学習ラベルを保持するための戦略におけるLSRSの柔軟性を可能にします。リベラルラベル保持ストアを使用した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-Labelバインディングを宣伝する時期の戦略の柔軟性を可能にします。独立したコントロールモードを使用したLSRは、FEC-labelバインディングがフィットを見るたびにピアに宣伝しますが、順序付けられたコントロールを使用すると、以前にFEC Nexthopから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.
LDPには、ベンダープライベートおよび実験機能の開発をサポートする拡張メカニズムが含まれています。このメカニズムは、新しいタイプのメッセージと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-Labelバインディングの定期的な更新は必要ありません。
- 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.
- ラベルリソースが不足していない状況では、リベラルなラベル保持を備えた下流の未承諾の方法を使用すると、FEC Nexthopの変化がLDPピアから別のピアへの変化により、以前に分散したラベルを更新するために配布アクションが必要になります。
- Limitations on the number of TCP connections an LSR supports limit the number of LDP peers the LSR can support.
- LSRをサポートするTCP接続の数の制限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は、TCP MD5署名オプションのオプションの使用を定義して、LDPセッション接続ストリームにスプーフィングされたTCPセグメントを導入することから保護します。LDP TCP MD5署名オプションの使用は、[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. Ash、M。Girish、E。Gray、B。Jamoussi、G。Wright、「CR-LDPのアプリケーションステートメント」、1999年9月、Work in Progress。
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1771] Rekhter、Y。およびT. Li、「A Border Gateway Protocol 4（BGP-4）」、RFC 1771、1995年3月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、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] Rosen、E。およびY. Rekhter、「BGP/MPLS VPNS」、RFC 2547、1999年3月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036] Andersson、L.、Doolan、P.、Feldman、N.、Fredette、A。and B. Thomas、「LDP仕様」、RFC 3036、2001年1月。
[RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、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.、Hannan、A。、およびX. Xiao、「LSP-TunnelsのRSVPへの拡張の適用可能性状態」、2000年4月の進行中。
Eric Gray Zaffire, Inc 2630 Orchard Parkway, San Jose, CA 95134-2020
エリック・グレイ・ザフィア、INC 2630オーチャード・パークウェイ、サンノゼ、カリフォルニア95134-2020
Phone: 408-894-7362 EMail: ewgray@mindspring.com
電話：408-894-7362メール：ewgray@mindspring.com
Bob Thomas Cisco Systems, Inc. 250 Apollo Dr. Chelmsford, MA 01824
Bob Thomas Cisco Systems、Inc。250 Apollo Dr. Chelmsford、MA 01824
Phone: 978-244-8078 EMail: rhthomas@cisco.com
電話：978-244-8078メール：rhthomas@cisco.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。