[要約] RFC 5443は、LDP（Label Distribution Protocol）とIGP（Interior Gateway Protocol）の同期に関する標準化された手順を提供します。その目的は、LDPとIGPの情報を同期させることで、ネットワークの効率性と信頼性を向上させることです。
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
LDP IGP同期
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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.
特定のネットワークでは、マルチプロトコルラベルスイッチング（MPLS）仮想プライベートネットワーク（VPN）アプリケーションに使用されるネットワークなど、ラベル分布プロトコル（LDP）によってエッジツーエッジラベルスイッチ付きパス（LSP）セットアップに依存しています。。このようなアプリケーションでは、MPLS LSPが適切に動作していない場合、インターネットプロトコル（IP）転送に依存することはできません。ラベル付きトラフィックのブラックホールは、LDPがないリンクでインテリアゲートウェイプロトコル（IGP）が動作している状況で発生する可能性があります。リンクはIP転送に使用される可能性がありますが、MPLS転送、たとえばMPLS VPNアプリケーションやBorder Gateway Protocol（BGP）のルートフリーコアなどに役立ちません。このドキュメントでは、プロトコルの変更を導入することなく、この状態によるトラフィックの損失を回避するメカニズムについて説明しています。
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を確立します。一般的なネットワーク設計では、LDPは、開いた最短パスファースト（OSPF）[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ルーターからもう1つのルーターへの最短パスに沿ったすべてのリンクが運用上の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の隣接がありますが、LDPはまだ隣接またはセッションを確立していないか、すべてのラベルバインディングをまだ分配していません。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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がリンクで動作しているが、LDPが操作しない場合、潜在的なネットワークの問題が存在します。したがって、このドキュメントで説明されているソリューションは、LDPが完全に動作していない限り、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.
これは、[RFC3137]で指定されたメカニズムとある程度の類似性を持ち、OSPFルーターがトランジットルーターとして使用してはならないことを宣伝することができます。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.
詳細：LDPが特定のリンクで「完全に動作する」（以下を参照）（以下を参照）場合、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 Hello隣接が存在する場合、リンクで完全に動作すると見なされます。適切な関連LDPセッション（Hello隣接のLDP識別子と一致する）がリンクの反対側のピアに確立され、すべてのラベルバインディングがありますセッションで交換されました。現時点では、後者の状態は一般にルーターによって検証できず、何らかの推定を使用する必要がある場合があります。簡単な実装戦略は、設定可能なホールドダウンタイマーを使用して、LDPが完全に動作することを宣言する前にLDPセッションの確立を可能にすることです。デフォルトのタイマーは、ラベル情報ベース（LIB）のテーブルサイズと機器機能の大きなバリエーションの懸念のため、このドキュメントでは定義されていません。さらに、[LIBの終了]で指定されているLDP End-of-LIBで進行中の現在の作業があります。これにより、LDPスピーカーはセッション設立後の最初の広告の完了を知らせることができます。LDP-of-libの終了が実装されている場合、構成可能なホールドダウンタイマーは不要になります。近隣LDPセッションは、LIBの終了通知メッセージが受信されると、完全に動作すると見なされます。
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 Communications Magazine Paper [LDP-Fail-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転送は、リンクが発生した後、またはリンクに真の問題がある場合にのみ短時間発生することに注意してください。後者の場合、実装はネットワーク管理アラートを発行してエラー条件を報告し、オペレーターがそれに対処できるようにする必要があります。
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 VPNSおよびBGPフリーのコアネットワーク設計です。ここでは、LDP転送状態が利用可能な場合にトラフィックをコアからのみ転送できます。
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ピアとの放送リンクでは、コストアウト手順は、リンク全体にのみ適用でき、個々のピアには適用できません。したがって、LDPサービスが1つのピアに利用できない場合、リンク上のすべてのピアからトラフィックが迂回されるかどうかは、ポリシー決定を下す必要があります。
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.
一部のネットワークでは、LDPは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関連のトラフィックブラックホリングの可能性のある原因の1つである可能性があります。このドキュメントでは、LDPセッションの故障を防ぐ方法については対処していません。ここで説明するメカニズムは、LDPがIGPの間に動作しないリンクの使用を防ぎます。このようなリンクでIGPコストを最大に割り当てることは、新しいセキュリティの脅威を導入してはなりません。操作はルーターの内部であり、LDPとIGPが通信および反応できるようにします。ただし、多くのLDPリンクを利用できないようにすることは、利用可能なネットワーク容量が限られているためにトラフィックの減少を引き起こす可能性のあるセキュリティの脅威です。これは、運用エラーまたは実装エラーによってトリガーされる場合があります。これらのエラーは一般的なセキュリティの問題と見なされ、実装者は現在の最高のセキュリティプラクティス[MPLS-GMPLS-SEC]に従う必要があります。
[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月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、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] Andersson、L.、ed。、Minei、I.、ed。、およびB. Thomas、ed。、「LDP仕様」、RFC 5036、2007年10月。
[End-of-LIB] Asati, R., LDP End-of-LIB, Work in Progress, January 2009.
[LIBの終わり] Asati、R.、LDP End-of-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 Standard 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-Fail-Rec] Fang、L.、Atlas、A.、Chiussi、F.、Kompella、K。、およびG. Swallow、「LDP障害検出と回復」、IEEE Communications Magazine、Vol.42、No。10、2004年10月。
[MPLS-GMPLS-Sec] Fang. L., Ed., "Security Framework for MPLS and GMPLS Networks", Work in Progress, November 2008.
[MPLS-GMPLS-SEC] Fang。L.、ed。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、2008年11月、Work in Progress。
[RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. McPherson, "OSPF Stub Router Advertisement", RFC 3137, June 2001.
[RFC3137] Retana、A.、Nguyen、L.、White、R.、Zinin、A。、およびD. McPherson、「OSPF Stub Router Advertisement」、RFC 3137、2001年6月。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008.
[RFC5305] Li、T。およびH. Smit、「IS-IS Traffic Engineering for Traffic Engineering」、RFC 5305、2008年10月。
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.
著者は、彼の詳細な議論とコメント、彼の有益なレビューと入力についてデイブ・ウォード、ロス・カロン、アマンダ・ババー、フランシス・デュポン、ドナルド・イーストレイク、ラス・ヒューズリー、パシ・エロネン、ダン・ロマスカヌ、Bin Mo、Lan Zheng、Bob Thomas、およびDave Ojemannのレビューとコメントについて。
Authors' Addresses
著者のアドレス
Markus Jork GENBAND 3 Federal St. Billerica, MA 01821 USA
Markus Jork Genband 3 Federal St.Billerica、MA 01821 USA
EMail: Markus.Jork@genband.com
Alia Atlas British Telecom
Alia Atlas British Telecom
EMail: alia.atlas@bt.com
Luyuan Fang Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA
Luyuan Fang Cisco Systems、Inc。300 Beaver Brook Road Boxborough、MA 01719 USA
EMail: lufang@cisco.com
Phone: 1 (978) 936-1633