Network Working Group M. Jork
Request for Comments: 5443 GENBAND
Category: Informational A. Atlas
British Telecom
L. Fang
Cisco Systems, Inc.
March 2009
LDP IGP Synchronization
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Abstract
抽象
In certain networks, there is dependency on the edge-to-edge Label Switched Paths (LSPs) setup by the Label Distribution Protocol (LDP), e.g., networks that are used for Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) applications. For such applications, it is not possible to rely on Internet Protocol (IP) forwarding if the MPLS LSP is not operating appropriately. Blackholing of labeled traffic can occur in situations where the Interior Gateway Protocol (IGP) is operational on a link on which LDP is not. While the link could still be used for IP forwarding, it is not useful for MPLS forwarding, for example, MPLS VPN applications or Border Gateway Protocol (BGP) route-free cores. This document describes a mechanism to avoid traffic loss due to this condition without introducing any protocol changes.
特定のネットワークでは、エッジ・ツー・エッジラベルへの依存がラベル配布プロトコル（LDP）、例えば、マルチプロトコルラベルに使用されているネットワークスイッチング（MPLS）バーチャルプライベートネットワーク（VPN）アプリケーションによってパス（LSPの）セットアップスイッチがあります。このようなアプリケーションの場合は、MPLS LSPが適切に動作していない場合は、インターネットプロトコル（IP）の転送に依存することはできません。ラベルされたトラフィックのブラックホールは、内部ゲートウェイプロトコル（IGP）は自民党がされていないリンクで動作している状況で発生する可能性があります。リンクがまだIPフォワーディングを使用することができるが、それは例えば、MPLS VPNアプリケーションやボーダーゲートウェイプロトコル（BGP）ルートのないコア、MPLSフォワーディングのために有用ではありません。このドキュメントは、任意のプロトコルの変更を導入することなく、この条件によるトラフィック損失を回避するためのメカニズムを説明しています。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Proposed Solution ...............................................3
3. Applicability ...................................................4
4. Interaction with TE Tunnels .....................................5
5. Security Considerations .........................................5
6. References ......................................................6
6.1. Normative References .......................................6
6.2. Informative References .....................................6
7. Acknowledgments .................................................6
LDP [RFC5036] establishes MPLS LSPs along the shortest path to a destination as determined by IP forwarding. In a common network design, LDP is used to provide Label Switched Paths throughout the complete network domain covered by an IGP such as Open Shortest Path First (OSPF) [RFC2328] or Intermediate System to Intermediate System (IS-IS) [ISO.10589.1992]; i.e., all links in the domain have IGP as well as LDP adjacencies.
LDP [RFC5036]はIPフォワーディングによって決定されるように目的地までの最短経路に沿ってMPLSのLSPを確立します。一般的なネットワーク設計では、自民党は、OSPF（Open Shortest Path First）のようIGPなどによってカバーされ、完全なネットワーク・ドメイン[RFC2328]または中間システム中間システム（IS-IS）[ISO.10589.1992への全体のパスをラベルスイッチを提供するために使用されます];つまり、ドメイン内のすべてのリンクはIGPだけでなく、LDP隣接関係を持っています。
A variety of services a network provider may want to deploy over an LDP-enabled network depend on the availability of edge-to-edge label switched paths. In a layer 2 (L2) or layer 3 (L3) VPN scenario, for example, a given Provider-Edge (PE) router relies on the availability of a complete MPLS forwarding path to the other PE routers for the VPNs it serves. This means that all the links along the IP shortest path from one PE router to the other need to have operational LDP sessions, and the necessary label binding must have been exchanged over those sessions. If only one link along the IP shortest path is not covered by an LDP session, a blackhole exists and services depending on MPLS forwarding will fail. This might be a transient or a persistent error condition. Some of the reasons for this could be:
ネットワークプロバイダは、LDP対応のネットワーク上で展開することがあり、様々なサービスは、パスを切り替え、エッジ・ツー・エッジのラベルの可用性に依存します。レイヤ2（L2）またはレイヤ3（L3）VPNシナリオでは、例えば、所与のプロバイダエッジ（PE）ルータは、それが機能するVPNの他のPEルータへの完全なMPLS転送パスの可用性に依存しています。これは、1つのPEルータから他の必要性へのIP最短経路に沿ってすべてのリンクが動作LDPセッションを持っていることを意味し、必要なラベルがこれらのセッション上で交換されている必要がありますバインディング。 IP最短経路に沿って1つのリンクのみがLDPセッションでカバーされていない場合は、ブラックホールが存在し、MPLSフォワーディングに応じたサービスが失敗します。これは、一時的または永続的なエラー状態であるかもしれません。その理由の一部は次のようになります。
- A configuration error.
- 構成エラー。
- An implementation bug.
- 実装のバグ。
- The link has just come up and has an IGP adjacency but LDP has either not yet established an adjacency or session, or has not yet distributed all the label bindings.
- リンクはちょうど出てくるとIGP隣接関係を持っていますが、自民党はまだ隣接またはセッションを確立していないか、まだすべてのラベルバインディングを配布していませんしました。
The LDP protocol has currently no way to correct the issue. LDP is not a routing protocol; it cannot re-direct traffic to an alternate IGP path.
LDPプロトコルは、現在この問題を修正する方法はありません。 LDPは、ルーティングプロトコルではありません。それは別のIGPパスにトラフィックをリダイレクトすることはできません。
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"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The problem described above exists because LDP is tied to IP-forwarding decisions but no coupling between the IGP and LDP operational state on a given link exists. If IGP is operational on a link but LDP is not, a potential network problem exists. So the solution described by this document is to discourage a link from being used for IP forwarding as long as LDP is not fully operational.
LDPは、IP転送の判断に接続されているが、所与のリンク上のIGPおよびLDP動作状態の間には結合が存在しないため、上述の問題が存在します。 IGPは、リンク上で動作しているが、自民党がない場合には、潜在的なネットワークの問題が存在します。したがって、この文書で説明するソリューションは限り自民党が完全に動作していないとして、IP転送のために使用されているからリンクを阻止することです。
This has some similarity to the mechanism specified in [RFC3137], which allows an OSPF router to advertise that it should not be used as a transit router. One difference is that [RFC3137] raises the link costs on all (stub) router links, while the mechanism described here applies on a per-link basis.
これは、OSPFルータは、それがトランジットルータとして使用すべきではないことを宣伝することを可能にする[RFC3137]で指定されたメカニズムにはいくつかの類似性を有します。 1つの違いは、ここで説明したメカニズムは、リンクごとに適用されている間、[RFC3137]は、すべての（スタブ）ルータリンクのリンクコストを上げることです。
In detail: when LDP is not "fully operational" (see below) on a given link, the IGP will advertise the link with maximum cost to avoid any transit traffic over it. In the case of OSPF, this cost is LSInfinity (16-bit value 0xFFFF), as proposed in [RFC3137]. In the case of ISIS, the maximum metric value is 2^24-2 (0xFFFFFE). Indeed, if a link is configured with 2^24-1 (the maximum link metric per [RFC5305]), then this link is not advertised in the topology. It is important to keep the link in the topology to allow IP traffic to use the link as a last resort in case of massive failure.
具体的には：自民党は「完全に動作」でない場合（下記参照）指定されたリンク上で、IGPは、それ以上の任意の通過トラフィックを避けるために、最大コストとのリンクをアドバタイズします。 OSPFの場合、このコストは[RFC3137]で提案されているように、LSInfinity（16ビット値が0xFFFF）です。 ISISの場合には、最大メトリック値は2 ^ 24-2（0xFFFFFE）です。リンクが2 ^ 24-1（[RFC5305]あたりの最大リンクメトリック）で構成されている場合、実際に、このリンクは、トポロジでアドバタイズされていません。 IPトラフィックは、大規模な障害が発生した場合の最後の手段としてリンクを使用できるようにするために、トポロジ内のリンクを維持することが重要です。
LDP is considered fully operational on a link when an LDP hello adjacency exists on it, a suitable associated LDP session (matching the LDP Identifier of the hello adjacency) is established to the peer at the other end of the link, and all label bindings have been exchanged over the session. At the present time, the latter condition cannot generally be verified by a router and some estimation may have to be used. A simple implementation strategy is to use a configurable hold-down timer to allow LDP session establishment before declaring LDP fully operational. The default timer is not defined in this document due to concerns of the large variations of the Label Information Base (LIB) table size and equipment capabilities. In addition, there is a current work in progress on LDP End-of-LIB as specified in [End-of-LIB], which enables the LDP speaker to signal the completion of its initial advertisement following session establishment. When LDP End-of-LIB is implemented, the configurable hold-down timer is no longer needed. The neighbor LDP session is considered fully operational when the End-of-LIB notification message is received.
LDPは、LDPハロー隣接がその上に存在する場合、（ハロー隣接のLDP識別子に一致する）適切な関連LDPセッションがリンクの他端にピアに確立され、そしてすべてのラベルバインディングを持っているリンク上で完全に動作可能であると考えられますセッション上で交換されて。現時点では、後者の条件は、一般的にルータによって確認することができず、いくつかの推定を使用しなければならないかもしれません。単純な実装戦略は自民党が完全に動作宣言する前に、LDPセッションの確立を許可するように設定可能なホールドダウンタイマーを使用することです。デフォルトのタイマーが原因ラベル情報ベース（LIB）テーブルサイズと設備能力の大きな変動の懸念に、この文書で定義されていません。その最初の広告次のセッション確立の完了を通知するLDPスピーカーを可能にする、[エンドの-LIB]で指定されるように加えて、LDPエンドの-LIBに進行中の現在の仕事があります。 LDPエンドの-LIBが実装されている場合は、設定可能なホールドダウンタイマーは必要ありません。エンド・オブ・LIB通知メッセージを受信したときに、隣接LDPセッションは完全に動作と考えられています。
This is typically sufficient to deal with the link when it is being brought up. LDP protocol extensions to indicate the complete transmission of all currently available label bindings after a session has come up are conceivable, but not addressed in this document.
これは、それが育っているときに、リンクに対処するために、典型的には十分です。セッションが来た後に現在使用可能なすべてのラベルバインディングの完全な伝送を示すために、LDPプロトコル拡張が考えられるが、この文書で扱われていません。
The mechanism described in this document does not entail any protocol changes and is a local implementation issue.
この文書で説明するメカニズムは、任意のプロトコルの変更を伴うし、ローカルの導入問題であることはありません。
The problem space and solution specified in this document have also been discussed in an IEEE Communications Magazine paper [LDP-Fail-Rec].
この文書で指定された問題空間とソリューションは、IEEEコミュニケーションマガジン紙[LDP-失敗-REC]で議論されています。
In general, the proposed procedure is applicable in networks where the availability of LDP-signaled MPLS LSPs and avoidance of blackholes for MPLS traffic are more important than always choosing an optimal path for IP-forwarded traffic. Note however that non-optimal IP forwarding only occurs for a short time after a link comes up or when there is a genuine problem on a link. In the latter case, an implementation should issue network management alerts to report the error condition and enable the operator to address it.
一般的には、提案されている手順は、LDP-合図のMPLS LSPをとMPLSトラフィックのブラックホールの回避の可用性は常にIP転送トラフィックのための最適な経路を選択するよりも重要であるネットワークに適用可能です。リンクが起動した後、またはリンク上の本物の問題がある場合に非最適IP転送が短時間だけ発生することに注意してください。後者の場合、実装は、エラー状態を報告し、それに対処するための作業を可能にするために、ネットワーク管理アラートを発行する必要があります。
Example network scenarios that benefit from the mechanism described here are MPLS VPNs and BGP-free core network designs where traffic can only be forwarded through the core when LDP forwarding state is available throughout.
ここで説明されたメカニズムから恩恵を受ける例示的なネットワークシナリオは、MPLS VPNとLDP転送状態は、全体を通して利用可能である場合、トラフィックのみコアを介して転送することができるBGP-フリーコアネットワーク設計です。
The usefulness of this mechanism also depends on the availability of alternate paths with sufficient bandwidth in the network should one link be assigned to the maximum cost due to the unavailability of LDP service over it.
この機構の有用性はまた、その上LDPサービスの利用不能にネットワークに十分な帯域幅を1つのリンクが最大コストに割り当てられるべきであると代替パスの可用性に依存します。
On broadcast links with more than one IGP/LDP peer, the cost-out procedure can only be applied to the link as a whole and not to an individual peer. So a policy decision has to be made whether the unavailability of LDP service to one peer should result in the traffic being diverted away from all the peers on the link.
複数のIGP / LDPピアとブロードキャストリンクでは、コストアウト手順は、全体としてではなく、個々のピアへのリンクにも適用することができます。だから、政策決定は、1つのピアにLDPサービスが利用できないが、リンク上のすべてのピアから離れ流用されたトラフィックをもたらすべきであるかどうかを判断する必要があります。
In some networks, LDP is used in conjunction with RSVP-TE, which sets up traffic-engineered tunnels. The path computation for the TE tunnels is based on the TE link cost that is flooded by the IGP in addition to the regular IP link cost. The mechanism described in this document should only be applied to the IP link cost to prevent unnecessary TE tunnel reroutes.
一部のネットワークでは、自民党は、トラフィックエンジニアリングトンネルを設定RSVP-TE、と組み合わせて使用されます。 TEトンネルのパス計算は、通常のIPリンクコストに加えて、IGPによって浸水されたTEリンクコストに基づいています。本書で説明されたメカニズムは、不要TEトンネル再ルーティングを防止するために、IPリンクコストに適用されるべきです。
In order to establish LDP LSPs across a TE tunnel, a targeted LDP session between the tunnel endpoints needs to exist. This presents a problem very similar to the case of a regular LDP session over a link (the case discussed so far): when the TE tunnel is used for IP forwarding, the targeted LDP session needs to be operational to avoid LDP connectivity problems. Again, raising the IP cost of the tunnel while there is no operational LDP session will solve the problem. When there is no IGP adjacency over the tunnel and the tunnel is not advertised as a link into the IGP, this becomes a local issue of the tunnel headend router.
TEトンネルを横切ってLDP LSPを確立するために、トンネルのエンドポイントとの間のターゲットLDPセッションが存在する必要があります。これは、リンク（これまで説明してきた場合）の上に、通常のLDPセッションの場合と非常によく似た問題を提示：TEトンネルがIP転送に使用されている場合、対象とLDPセッションは、LDP接続の問題を回避するために運用する必要があります。ここでも、運用LDPセッションが存在しない間トンネルのIPコストを上げると、問題を解決します。そこにトンネル上何のIGP隣接関係がなく、トンネルをIGPへのリンクとして宣伝されていない場合は、これはトンネルヘッドエンドルータのローカル問題となります。
A Denial-of-Service (DoS) attack that brings down LDP service on a link or prevents it from becoming operational on a link could be one possible cause of LDP-related traffic blackholing. This document does not address how to prevent LDP session failure. The mechanism described here prevents the use of the link where LDP is not operational while IGP is. Assigning the IGP cost to maximum on such a link should not introduce new security threats. The operation is internal to the router to allow LDP and IGP to communicate and react. Making many LDP links unavailable, however, is a security threat that can cause dropped traffic due to limited available network capacity. This may be triggered by operational error or implementation error. These errors are considered general security issues and implementors should follow the current best security practice [MPLS-GMPLS-Sec].
リンク上でLDPサービスをダウンさせたり、リンク上で動作可能になることから、それを防止サービス拒否（DoS）攻撃は、LDP関連のトラフィックのブラックホールの一つの可能な原因である可能性があります。この文書では、LDPセッションの失敗を防ぐためにどのように対処していません。ここで説明するメカニズムはIGPがある一方、自民党が動作していないリンクの使用を防止します。そのようなリンク上で最大のIGPコストを割り当てると、新しいセキュリティ脅威を導入してはなりません。動作はLDPとIGPが通信と反応することを可能にするルータの内部にあります。多くの自民党のリンクが利用できないように、しかし、限ら利用できるネットワーク容量へのトラフィックを落とし引き起こす可能性がセキュリティ上の脅威です。これは、操作ミスや実装エラーによってトリガすることができます。これらのエラーは、現在のセキュリティのベストプラクティス[MPLS-GMPLS-SEC]を従うべき一般的なセキュリティ上の問題や実装を検討しています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036]アンデション、L.、エド。、Minei、I.、エド。、およびB.トーマス、エド。、 "LDP仕様"、RFC 5036、2007年10月。
[End-of-LIB] Asati, R., LDP End-of-LIB, Work in Progress, January 2009.
[エンドの-LIB] Asati、R.、LDPエンドの-LIB、進歩、2009年1月の作業。
[ISO.10589.1992] International Organization for Standardization, "Intermediate system to intermediate system intra-domain-routing routine information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)", ISO Standard 10589, 1992.
【ISO.10589.1992】国際標準化機構「に中間システム中間システムイントラドメインルーティングコネクションレス型ネットワークサービス（ISO 8473）を提供するためのプロトコルと一緒に使用するためのルーチンの情報交換プロトコル」、ISO規格10589を1992。
[LDP-Fail-Rec] Fang, L., Atlas, A., Chiussi, F., Kompella, K., and G. Swallow, "LDP Failure Detection and Recovery", IEEE Communications Magazine, Vol.42, No.10, October 2004.
[LDP-フェールREC]牙、L.、アトラス、A.、Chiussi、F.、Kompella、K.、およびG.ツバメ、 "LDP障害検出および回復"、IEEE通信誌、Vol.42、号10、2004年10月。
[MPLS-GMPLS-Sec] Fang. L., Ed., "Security Framework for MPLS and GMPLS Networks", Work in Progress, November 2008.
[MPLS-GMPLS-SEC]牙。 L.、エド。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、進歩、2008年11月の作業。
[RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. McPherson, "OSPF Stub Router Advertisement", RFC 3137, June 2001.
[RFC3137] Retana、A.、グエン、L.、ホワイト、R.、ジニン、A.、およびD.マクファーソン、 "OSPFスタブルータアドバタイズメント"、RFC 3137、2001年6月。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008.
[RFC5305]李、T.とH.スミットは、RFC 5305、2008年10月 "トラフィックエンジニアリングのための拡張機能-IS IS"。
The authors would like to thank Bruno Decraene for his in-depth discussion and comments, Dave Ward for his helpful review and input, and Loa Andersson, Ross Callon, Amanda Baber, Francis Dupont, Donald Eastlake, Russ Housley, Pasi Eronen, Dan Romascanu, Bin Mo, Lan Zheng, Bob Thomas, and Dave Ojemann for their reviews and comments.
著者は、彼の深い議論やコメントのブルーノDecraene、彼の役に立つレビューと入力のためのデイブ・ワード、及びロア・アンダーソン、ロスCallon、アマンダBaber、フランシスデュポン、ドナルドイーストレイク、ラスHousley、パシEronen、ダンRomascanuに感謝したいと思います、彼らのレビューとコメントのためのビンのMo、蘭鄭、ボブ・トーマス、とDave Ojemann。
Authors' Addresses
著者のアドレス
Markus Jork GENBAND 3 Federal St. Billerica, MA 01821 USA
マルクスJorkのジェンバンド3の連邦セントビレリカ、MA 01821 USA
EMail: Markus.Jork@genband.com
メールアドレス：Markus.Jork@genband.com
Alia Atlas British Telecom
アリアアトラスブリティッシュテレコム
EMail: alia.atlas@bt.com
メールアドレス：alia.atlas@bt.com
Luyuan Fang Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA
Luyuan牙シスコシステムズ社300ビーバーブルック・ロードボックスボロー、MA 01719 USA
EMail: lufang@cisco.com Phone: 1 (978) 936-1633
メールアドレス：lufang@cisco.com電話：1（978）936-1633