Network Working Group B. Decraene
Request for Comments: 5283 JL. Le Roux
Category: Standards Track France Telecom
I. Minei
Juniper Networks, Inc.
July 2008
LDP Extension for Inter-Area Label Switched Paths (LSPs)
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
To facilitate the establishment of Label Switched Paths (LSPs) that would span multiple IGP areas in a given Autonomous System (AS), this document describes a new optional Longest-Match Label Mapping Procedure for the Label Distribution Protocol (LDP).
ラベルの確立が与えられた自律システム（AS）内に複数のIGP領域にまたがるうスイッチパス（LSP）容易にするために、この文書は、ラベル配布プロトコル（LDP）のための新しいオプションの最長一致ラベルマッピング手順を説明します。
This procedure allows the use of a label if the Forwarding Equivalence Class (FEC) Element matches an entry in the Routing Information Base (RIB). Matching is defined by an IP longest-match search and does not mandate an exact match.
転送等価クラス（FEC）要素は、ルーティング情報ベース（RIB）内のエントリに一致する場合、この手順は、ラベルを使用することができます。マッチングは、IP最長一致検索によって定義され、完全一致を強制しません。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. Terminology .....................................................2
4. Problem Statement ...............................................3
5. Longest-Match Label Mapping Message Procedure ...................4
6. Application Examples ............................................6
6.1. Inter-Area LSPs ............................................6
6.2. Use of Static Routes .......................................7
7. Caveats for Deployment ..........................................8
7.1. Deployment Considerations ..................................8
7.2. Routing Convergence Time Considerations ....................8
8. Security Considerations .........................................9
9. References ......................................................9
9.1. Normative References .......................................9
9.2. Informative References .....................................9
10. Acknowledgments ...............................................11
Link state Interior Gateway Protocols (IGPs) such as OSPF [OSPFv2] and IS-IS [IS-IS] allow the partition of an autonomous system into areas or levels so as to increase routing scalability within a routing domain.
OSPFなどのリンク状態インテリアゲートウェイプロトコル（のIGP）のOSPFv2]およびIS-ISルーティングドメイン内ルーティングのスケーラビリティを増加させるように領域またはレベルへの自律システムのパーティションを可能にする[-ISは、IS]。
However, [LDP] recommends that the IP address of the FEC Element should *exactly* match an entry in the IP Routing Information Base (RIB). According to [LDP], section 3.5.7.1 ("Label Mapping Messages Procedures"):
ただし、[LDP]はFEC要素のIPアドレスが*正確に* IPルーティング情報ベース（RIB）内のエントリと一致する必要がありますことをお勧めします。 [LDP]によれば、セクション3.5.7.1（「ラベルマッピングメッセージ手順」）。
An LSR [Label Switching Router] receiving a Label Mapping message from a downstream LSR for a Prefix SHOULD NOT use the label for forwarding unless its routing table contains an entry that exactly matches the FEC Element.
そのルーティングテーブルが正確にFEC要素と一致するエントリが含まれていない限り、接頭辞のための川下のLSRからラベルマッピングメッセージを受信したLSR [ラベルスイッチングルータ]は転送のためにラベルを使用しないでください。
Therefore, MPLS LSPs between Label Edge Routers (LERs) in different areas/levels are not set up unless the specific (e.g., /32 for IPv4) loopback addresses of all the LERs are redistributed across all areas.
したがって、異なる領域のラベルエッジルータ（のLER）との間のMPLS LSPは/レベル（例えば、IPv4の/ 32）全てのLERのループバックアドレスはすべての領域を横切って再配布されない限り、特定の設定されていません。
The problem statement is discussed in section 4. Then, in section 5 we extend the Label Mapping Procedure defined in [LDP] so as to support the setup of contiguous inter-area LSPs while maintaining IP prefix aggregation on the ABRs. This consists of allowing for longest-match-based Label Mapping.
問題文は、5章で我々はのABR上のIPプレフィックス集約を維持しながら、連続した領域間のLSPの設定をサポートするように[LDP]で定義されたラベルマッピング手順を拡張し、その後、セクション4で説明されています。これは、最長一致に基づくラベルマッピングを可能に構成されています。
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]に記載されているように解釈されます。
IGP Area: OSPF Area or IS-IS level
IGPエリア：OSPFエリアまたはIS-ISレベル
ABR: OSPF Area Border Router or IS-IS L1/L2 router
ABR：OSPFエリア境界ルータまたはIS-IS L1 / L2ルータ
LSP: Label Switched Path
LSP：ラベルスイッチパス
Intra-area LSP: LSP that does not traverse any IGP area boundary.
エリア内のLSP：LSP任意のIGPエリア境界を横断していません。
Inter-area LSP: LSP that traverses at least one IGP area boundary.
エリア間のLSP：LSP少なくとも一つのIGPエリア境界を横断。
Provider-based MPLS (Multiprotocol Label Switching) networks are expanding with the success of Layer 3 Virtual Private Networks [L3-VPN] and the new deployments of Layer 2 VPNs ([VPLS-BGP], [VPLS-LDP]). Service providers' MPLS backbones are significantly growing both in terms of density with the addition of Provider Edge (PE) routers to connect new customers and in terms of footprint as traditional Layer 2 aggregation networks may be replaced by IP/MPLS networks. As a consequence many providers need to introduce IGP areas. Inter-area LSPs (that is, LSPs that traverse at least two IGP areas) are required to ensure MPLS connectivity between PEs located in distinct IGP areas.
ネットワークレイヤの成功と3つの仮想プライベートネットワーク[L3-VPN]およびレイヤの新しい展開2つのVPN（[VPLS-BGP]、[VPLS-LDP]）を拡大しているプロバイダベースのMPLS（マルチプロトコルラベルスイッチング）。サービスプロバイダののMPLSバックボーンを大幅に従来のレイヤ2アグリゲーションネットワークは、IP / MPLSネットワークに置き換えることができるよう、新たな顧客を接続し、フットプリントの観点からするプロバイダーエッジ（PE）ルータを追加して、両方の密度の面で成長しています。結果として、多くのプロバイダは、IGP領域を導入する必要があります。エリア間のLSP（すなわち、少なくとも二つのIGP領域を横断するLSPは）別個のIGP領域に位置するPE間のMPLS接続を確保するために必要とされます。
To set up the required MPLS LSPs between PEs in different IGP areas, service providers currently have three solutions: 1) LDP with IGP route leaking, 2) BGP [MPLS-BGP] over LDP with MPLS hierarchy, and 3) inter-area RSVP-TE (Resource Reservation Protocol-Traffic Engineering [RSVP-TE]).
1）LDP IGPルート漏出、MPLS階層とLDP上2）BGP [MPLS-BGP]、および3）エリア間のRSVPを有する：別のIGP領域内のPE間に必要なMPLSのLSPを設定するために、サービスプロバイダは、現在、三つの溶液を有します-TE（リソース予約プロトコル - トラフィックエンジニアリング[RSVP-TE]）。
IGP route leaking consists of redistributing all specific PE loopback addresses across area boundaries. As a result, LDP finds in the RIB an exact match for its FEC and sets up the LSP. As a consequence, the potential benefits that a multi-area domain may yield are significantly diminished since a lot of addresses have to be redistributed by ABRs, and the number of IP entries in the IGP Link State Database (LSDB), RIB, and Forwarding Information Base (FIB) maintained by every LSR of the domain (whatever the area/level it belongs to) cannot be minimized.
IGPルートリークは、地域の境界を越えて、すべての特定のPEループバックアドレスを再分配で構成されています。結果として、LDPはRIBにそのFECの正確な一致を見つけ、LSPを設定します。アドレスの多くはのABRによって再配布する必要があるため結果として、マルチエリアドメインが生じることの潜在的な利益が大幅に減少しており、IGPリンクステートデータベース（LSDB）、RIB、および転送中にIPエントリの数（面積/レベルは、それが属する何でも）ドメインのすべてのLSRによって維持される情報ベース（FIB）を最小限に抑えることができません。
Service providers may also set up these inter-area LSPs by using MPLS hierarchy with BGP [MPLS-BGP] as a label distribution protocol between areas. The BGP next hop would typically be the ABRs, and the BGP-created LSPs would be nested within intra-area LSPs set up by LDP between PEs and ABRs and between ABRs.
サービスプロバイダは、領域間のラベル配布プロトコルとしてBGP [MPLS-BGP]とMPLS階層を使用して、これらのエリア間のLSPを設定してもよいです。 BGPネクストホップは、典型的には、のABRであろう、及びBGP-作成LSPは、PEとのABR間とのABR間LDPによって設定エリア内のLSP内にネストされるであろう。
This solution is not adequate for service providers which don't want to run BGP on their provider routers as it requires BGP on all ABRs. In addition, MPLS hierarchy does not allow locally protecting the LSP against ABR failures (IP/LDP Fast Reroute), and hence ensuring sub-50ms recovery upon ABR failure. The resulting convergence time may not be acceptable for stringent Service Level Agreements (SLAs) required for voice or mission-critical applications. Finally, this solution requires a significant migration effort for service providers that started with LDP and IGP route leaking to quickly set up the first inter-area LSPs.
このソリューションは、それはすべてのABR上でBGPを必要とするため、そのプロバイダのルータでBGPを実行したくないサービスプロバイダーには十分ではありません。また、MPLS階層はABR障害に対するLSP（IP / LDP高速リルート）を保護し、ひいてはABRの故障時にサブ50msの回復を確実にローカルに許可しません。結果の収束時間は、音声やミッションクリティカルなアプリケーションに必要な厳しいサービスレベル契約（SLA）のために許容できない場合があります。最後に、このソリューションはすぐに最初のエリア間のLSPを設定するにはLDPとIGPルートリークで開始サービスプロバイダーにとって重要な移行作業が必要です。
Service providers may also set up these inter-area LSPs by using inter-area RSVP-TE [RSVP-TE]. This is a relevant solution when RSVP-TE is already used for setting up intra-area LSPs, and inter-area traffic engineering features are required. In return, this is not a desired solution when LDP is already used for setting up intra-area LSPs, and inter-area traffic engineering features are not required.
サービスプロバイダはまた、エリア間RSVP-TE [RSVP-TE]を使用して、これらのエリア間のLSPを設定することがあります。これは、RSVP-TEは、既にエリア内のLSPを設定するために使用され、エリア間トラフィックエンジニアリング機能が必要とされ、関連するソリューションです。自民党は既にエリア内のLSPを設定するために使用され、エリア間トラフィックエンジニアリング機能が必要とされていないときのリターンでは、これは、望ましい解決策ではありません。
To avoid the above drawbacks, there is a need for an LDP-based solution that allows setting up contiguous inter-area LSPs while avoiding leaking of specific PE loopback addresses across area boundaries, thereby keeping all the benefits of IGP hierarchy.
上記の欠点を回避するために、地域の境界を越えて、特定のPEループバックアドレスの漏洩を防止することにより、IGP階層のすべての利点を維持しながら、連続したエリア間のLSPを設定することができますLDPベースのソリューションの必要性があります。
In that context, this document defines a new LDP Label Mapping Procedure so as to support the setup of contiguous inter-area LSPs while maintaining IP prefix aggregation on the ABRs. This procedure is similar to the one defined in [LDP] but performs an IP longest match when searching the FEC element in the RIB.
ABR上のIPプレフィックス集約を維持しながら、連続した領域間のLSPの設定をサポートするようにその意味で、この文書は、新しいLDPラベルマッピング手順を定義します。この手順は、[LDP]で定義されたものと同様であるが、RIBにFEC要素を検索する際にIP最長一致を行います。
This document defines a new Label Mapping Procedure for [LDP]. It is applicable to IPv4 and IPv6 prefix FEC elements (address families 1 and 2 as per the "Address Family Numbers" registry on the IANA site). It SHOULD be possible to activate/deactivate this procedure by configuration, and it SHOULD be deactivated by default. It MAY be possible to activate it on a per-prefix basis.
この文書では、[LDP]に新しいラベルマッピング手順を定義します。これは、IPv4およびIPv6プレフィックスFEC要素（IANAサイト上の「アドレスファミリ番号」レジストリあたりとしてアドレスファミリー1および2）に適用されます。 /アクティブ構成のことで、この手順を無効にすることは可能であるべきであり、それはデフォルトで無効にする必要があります。プレフィクス単位毎に、それを有効にすることも可能です。
With this new Longest-Match Label Mapping Procedure, an LSR receiving a Label Mapping message from a neighbor LSR for a Prefix Address FEC Element FEC1 SHOULD use the label for MPLS forwarding if its routing table contains an entry that matches the FEC Element FEC1 and the advertising LSR is a next hop to reach FEC1. If so, it SHOULD advertise the received FEC Element FEC1 and a label to its LDP peers.
そのルーティングテーブルはFEC要素FEC1と一致するエントリが含まれている場合、この新しい最長一致ラベルマッピング手順で、LSRはMPLS転送用ラベルを使用すべきであるプレフィックスアドレスFEC要素FEC1のための隣接LSRからラベルマッピングメッセージを受信広告LSRはFEC1に到達するためのネクストホップです。もしそうなら、それは受信FEC要素FEC1とそのLDPピアにラベルを宣伝すべきです。
By "matching FEC Element", one should understand an IP longest match. That is, either the LDP FEC element exactly matches an entry in the IP RIB or the FEC element is a subset of an IP RIB entry. There is no match for other cases (i.e., if the FEC element is a superset of a RIB entry, it is not considered a match).
「FEC要素にマッチする」とは、一つはIP最長一致を理解する必要があります。つまり、どちらかのLDP FEC要素は正確にIP RIBまたはFEC要素のエントリは、IP RIBエントリーのサブセットで一致しました。 （FEC要素はRIBエントリのスーパーセットである場合、すなわち、それは一致と見なされていない）他の場合には一致がありません。
Note that LDP re-advertises to its peers the specific FEC element FEC1, and not the aggregated prefix found in the IP RIB during the longest-match search.
自民党はそのピアに最長一致検索の際にIP RIBで見つかった特定のFEC要素FEC1はなく、集約されたプレフィックスを再アドバタイズことに注意してください。
Note that with this Longest-Match Label Mapping Procedure, each LSP established by LDP still strictly follows the shortest path(s) defined by the IGP.
この最長一致ラベルマッピング手順を用いて、LDPによって確立された各LSPがまだ厳密IGPによって定義された最短経路（複数可）を、以下のことに注意してください。
FECs selected by this Longest-Match Label Mapping Procedure are distributed in an ordered way. In case of LER failure, the removal of reachability to the FEC occurs using LDP ordered label distribution mode procedures. As defined in [LDP] in section A.1.5, the FEC will be removed in an ordered way through the propagation of Label Withdraw messages. The use of this (un)reachability information by application layers using this MPLS LSP (e.g., [MP-BGP]) is outside the scope of this document.
この最長一致ラベルマッピング手順によって選択されたのFECは、注文した方法で配布されています。 LERの障害が発生した場合に、FECへの到達可能性の除去は、LDPを使用して発生したラベル配布モード手順を指示しました。セクションA.1.5の[LDP]で定義されるように、FECは、メッセージを撤回ラベルの伝搬を介して順序付けられた方法で除去されます。これを使用して、アプリケーション層によってこの（UN）到達可能性情報を使用することは、LSP（例えば、[MP-BGP]）は、この文書の範囲外であるMPLS。
As per [LDP], LDP already has some interactions with the RIB. In particular, it needs to be aware of the following events:
[LDP]あたりとして、自民党はすでにRIBといくつかの相互作用を持っています。特に、次のイベントに注意する必要があります。
- prefix up when a new IP prefix appears in the RIB,
- プレフィックスアップを新しいIPプレフィックスがRIBに表示され、
- prefix down when an existing IP prefix disappears,
- 接頭辞がダウンして、既存のIPプレフィックスが消え、
- next-hop change when an existing IP prefix has a new next hop following a routing change.
- 既存のIPプレフィックスがルーティング変更後の新しい次のホップを持っているネクストホップの変更。
With this Longest-Match Label Mapping Message Procedure, multiple FECs may be concerned by a single RIB prefix change. The LSR MUST check all the FECs that are a subset of this RIB prefix. So, some LDP reactions following a RIB event are changed:
この最長一致ラベルマッピングメッセージの手順で、複数のFECは、単一のRIB接頭語の変更を懸念することができます。 LSRはこのRIB接頭語のサブセットであるすべてのFECをチェックしなければなりません。だから、RIBイベント、次のいくつかのLDP反応が変更されます。
- When a new prefix appears in the RIB, the LSR MUST check if this prefix is a better match for some existing FECs. For example, the FEC elements 192.0.2.1/32 and 192.0.2.2/32 used the IP RIB entry 192.0.2.0/24, and a new more specific IP RIB entry 192.0.2.0/26 appears. This may result in changing the LSR used as next hop and hence the Next Hop Label Forwarding Entry (NHLFE) for this FEC.
- 新しい接頭語がRIBに表示されたら、このプレフィックスは、いくつかの既存のFECsのためのより良い一致がある場合、LSRはチェックしなければなりません。例えば、FEC要素192.0.2.1/32と192.0.2.2/32は、IP RIBエントリ192.0.2.0/24、そして新しい、より具体的なIP RIBエントリ192.0.2.0/26が表示されますを使用していました。これは、LSRは、このFECのための次のホップとして使用され、従ってネクストホップラベル転送エントリ（NHLFE）変化をもたらすことができます。
- When a prefix disappears in the RIB, the LSR MUST check all FEC elements that are using this RIB prefix as best match. For each FEC, if another RIB prefix is found as best match, LDP MUST use it. This may result in changing the LSR used as next hop and hence the NHLFE for this FEC. Otherwise, the LSR MUST remove the FEC binding and send a Label Withdraw message.
- 接頭語がRIBに消えると、LSRはベストマッチとしてこのRIB接頭辞を使用しているすべてのFECの要素をチェックしなければなりません。各FECのために、別のRIB接頭語がベストマッチとして発見された場合、自民党はそれを使用しなければなりません。これは、LSRは、次のホップ、従って、このFECのためのNHLFEとして用い変化をもたらすことができます。そうでなければ、LSRはバインディングFECを削除し、メッセージを撤回ラベルを送らなければなりません。
- When the next hop of a RIB prefix changes, the LSR MUST change the NHLFE of all the FEC elements using this prefix.
- ときRIB接頭語の変更の次のホップは、LSRは、このプレフィックスを使用して、すべてのFEC要素のNHLFEを変更する必要があります。
Future work may define new management objects to the MPLS LDP MIB modules [LDP-MIB] to activate/deactivate this Longest-Match Label Mapping Message Procedure, possibly on a per-prefix basis.
今後の課題は、おそらくプレフィクス単位毎に、この最長一致ラベルマッピングメッセージ手順を有効化/無効化するMPLS LDP MIBモジュール[LDP-MIB]に新しい管理オブジェクトを定義することもできます。
Consider the following example of an autonomous system with one backbone area and two edge areas:
1つのバックボーンエリア二縁領域を有する自律システムの次の例を考えてみます。
Area "B"
エリア「B」
Level 2 / Backbone area
レベル2 /バックボーンエリア
+--------------------------+
Area "A" | | Area "C"
| |
Level 1 | | Level 1 / area
| P1 |
+----------+ +-------------+
| | P2 | PE1 | 192.0.2.1/32
| | | |
|PE4 ABR2 ABR1 PE2 | 192.0.2.2/32
| | P3 | |
| | | PE3 | 192.0.2.3/32
+----------+ +-------------+
| |
+--------------------------+
Figure 1: An IGP domain with two areas
attached to the Backbone Area.
Note that this applies equally to IS-IS and OSPF. An ABR refers here either to an OSPF ABR or to an IS-IS L1/L2 node.
これは、IS-IS、およびOSPFにも同様に適用されることに注意してください。 ABRは、OSPF ABRまたはIS-IS L1 / L2ノードにここでのいずれかを指します。
All routers are MPLS enabled, and MPLS connectivity (i.e., an LSP) is required between all PE routers.
すべてのルータがMPLSイネーブルされ、及びMPLS接続（すなわち、LSP）は、すべてのPEルータとの間で必要とされます。
In the "egress" area "C", the records available are:
「出口」の領域「C」で、使用可能なレコードは、次のとおりです。
IGP RIB LDP FEC elements: 192.0.2.1/32 192.0.2.1/32 192.0.2.2/32 192.0.2.2/32 192.0.2.3/32 192.0.2.3/32
IGP RIB LDP FEC要素：192.0.2.1/32 192.0.2.1/32 192.0.2.2/32 192.0.2.2/32 192.0.2.3/32 192.0.2.3/32
The area border router ABR1 advertises in the backbone area: - the aggregated IP prefix 192.0.2.0/26 in the IGP - all the specific IP FEC elements (/32) in LDP
エリア境界ルータABR1は、バックボーンエリアにアドバタイズ： - IGPにおける凝集IPプレフィックス192.0.2.0/26 - LDP内のすべての特定のIP FEC要素（/ 32）
In the "backbone" area "B", the records available are:
「バックボーン」エリア「B」では、利用できるレコードは、次のとおりです。
IGP RIB LDP FEC elements: 192.0.2.0/26 192.0.2.1/32 192.0.2.2/32 192.0.2.3/32
IGP RIB LDP FEC要素：192.0.2.0/26 192.0.2.1/32 192.0.2.2/32 192.0.2.3/32
The area border router ABR2 advertises in the area "A": - an aggregated IP prefix 192.0.2.0/24 in the IGP - all the individual IP FEC elements (/32) in LDP
IGPに集約IPプレフィックス192.0.2.0/24 - - LDP内のすべての個々のIP FEC要素（/ 32）：エリア境界ルータABR2は、領域「A」にアドバタイズ
In the "ingress" area "A", the records available are:
「侵入」エリア「A」では、利用できるレコードは、次のとおりです。
IGP RIB LDP FEC elements: 192.0.2.0/24 192.0.2.1/32 192.0.2.2/32 192.0.2.3/32
IGP RIB LDP FEC要素：192.0.2.0/24 192.0.2.1/32 192.0.2.2/32 192.0.2.3/32
In this situation, one LSP is established between the ingress PE4 and every egress PE of area C while maintaining IP prefix aggregation on the ABRs.
この状況では、一つのLSPは、入口PE4とのABR上のIPプレフィックス集約を維持しながら、領域Cのすべての出口PEとの間に確立されます。
Consider the following example where a LER is dual-connected to two LSRs:
LERは、デュアル接続された二つのLSRにある次の例を考えてみましょう。
+--------LSR1----
| |
LER |
| |
+--------LSR2----
Figure 2: LER dual-connected to two LSRs.
図2：LERデュアル接続された二つのLSRに。
In some situations, especially on the edge of the network, it is valid to use static IP routes between the LER and the two LSRs. If necessary, the Bidirectional Forwarding Detection protocol [BFD] can be used to quickly detect loss of connectivity.
いくつかの状況では、特にネットワークのエッジでは、LER二つのLSR間の静的IPルートを使用することが有効です。必要に応じて、双方向フォワーディング検出プロトコル[BFD]は迅速接続の喪失を検出するために使用され得ます。
The LDP specification defined in [LDP] would require on the ingress LER the configuration and the maintenance of one IP route per egress LER and per outgoing interface.
[LDP]で定義されたLDP仕様は構成LER入口と出口LER当たりおよび発信インターフェイスごとに1つのIP経路の維持に必要であろう。
The Longest-Match Label Mapping Procedure described in this document only requires one IP route per outgoing interface.
このドキュメントで説明最長一致ラベルマッピング手順は、発信インターフェイスごとに1つのIPルートが必要です。
LSRs compliant with this document are backward compatible with LSRs that comply with [LDP].
この文書に準拠のLSRは、[LDP]に準拠のLSRとの下位互換性があります。
For the successful establishment of end-to-end MPLS LSPs whose FECs are aggregated in the RIB, this specification must be implemented on all LSRs in all areas where IP aggregation is used. If an LSR on the path does not support this procedure, then the LSP initiated on the egress LSR stops at this non-compliant LSR. There are no other adverse effects.
FEC RIBに集約され、エンドツーエンドのMPLS LSPの成功確立のために、この仕様は、IP集約が使用されているすべての領域内の全てのLSR上に実装されなければなりません。パス上のLSRは、この手順をサポートしていない場合、LSPがLSRは、この非対応のLSRで停止出口で開始しました。他の悪影響はありません。
This extension can be deployed incrementally:
この拡張はインクリメンタルに展開することができます。
- It can be deployed on a per-area or per-routing-domain basis and does not necessarily require an AS-wide deployment. For example, if all specific IP prefixes are leaked in the IGP backbone area and only stub areas use IP aggregation, LSRs in the backbone area don't need to be compliant with this document.
- それは、地域ごとまたはルーティングドメインベースで展開することができ、必ずしもASワイド展開を必要としません。すべての特定のIPプレフィクスがIGPバックボーンエリアにリークされており、唯一のスタブエリアは、IP集約を使用した場合、バックボーンエリア内のLSRは、この文書に準拠している必要はありません。
- Within each routing area, LSRs can be upgraded independently, at any time, in any order, and without service disruption. During deployment, if those LSPs are already used, one should only make sure that ABRs keep advertising the specific IP prefixes in the IGP until all LSRs of this area are successfully upgraded. Then, the ABRs can advertise the aggregated prefix only and stop advertising the specific ones.
- 各ルーティング領域内で、のLSRは、いつでも、任意の順序で、サービスを中断することなく、独立してアップグレードすることができます。これらのLSPが既に使用されている場合、展開時には、1のみ、この地域のすべてのLSRが正常にアップグレードされるまでのABRはIGPで特定のIPプレフィックスをアドバタイズし続けることを確認する必要があります。その後、のABRだけで集計プレフィックスを通知し、特定のものを宣伝停止することができます。
A service provider currently leaking specific LER loopback addresses in the IGP and considering performing IP aggregation on ABR should be aware that this may result in suboptimal routing as discussed in [RFC2966].
現在IGPの特定のLERループバックアドレスが漏洩し、ABR上のIPアグリゲーションを行う考慮サービスプロバイダは、[RFC2966]で説明したように、これは準最適ルーティングをもたらすことができることに注意すべきです。
IP and MPLS traffic restoration time is based on two factors: the Shortest Path First (SPF) calculation in the control plane and Forwarding Information Base (FIB) / Label FIB (LFIB) update time in the forwarding plane. The SPF calculation scales O(N*Log(N)) where N is the number of Nodes. The FIB/LFIB update scales O(P) where P is the number of modified prefixes. Currently, with most routers implementations, the FIB/LFIB update is the dominant component [IGP-CONV], and therefore the bottleneck that should be addressed in priority. The solution documented in this document reduces the link state database size in the control plane and the number of FIB entries in the forwarding plane. As such, it solves the scaling of pure IP routers sharing the IGP with MPLS routers. However, it does not decrease the number of LFIB entries so is not sufficient to solve the scaling of MPLS routers. For this, an additional mechanism is required (e.g., introducing some MPLS hierarchy in LDP). This is out of scope for this document.
IPおよびMPLSトラフィック復旧時間は、2つの要因に基づいています。コントロールプレーンと転送情報ベース（FIB）/ラベルFIB（LFIB）でShortest Path First（SPF）の計算フォワーディングプレーンで時刻を更新。 SPFの計算は、nはノードの数であり、O（N *ログ（N））をスケーリングします。 FIB / LFIBアップデートはPが修正プレフィックスの数であり、O（P）をスケーリングします。現在、ほとんどのルータ実装と、FIB / LFIBアップデートは、支配的な成分[IGP-CONV]、及び優先的に取り組むべき従ってボトルネックです。この文書に記載された溶液は、制御プレーンにおけるリンク状態データベースのサイズと転送プレーン内のFIBエントリの数を減少させます。このように、それはMPLSルータとIGPを共有し、純粋なIPルータのスケーリングを解決します。しかし、それはそうMPLSルータのスケーリングを解決するのに十分ではないLFIBエントリの数を減少させません。このため、追加のメカニズム（例えば、LDPにおけるいくつかのMPLS階層を導入する）が必要です。これはこの文書の範囲外です。
Compared to [LDP], for all failures except LER failure (i.e., links, provider routers, and ABRs), the failure notification and the convergence is unchanged. For LER failure, given that the IGP aggregates IP routes on ABRs and no longer advertises specific prefixes, the control plane and more specifically the routing convergence behavior of protocols (e.g., [MP-BGP]) or applications (e.g., [L3-VPN]) may be changed in case of failure of the egress LER node. For protocols and applications which need to track egress LER availability, several solutions can be used, for example:
[LDP]に比べて、LER障害（すなわち、リンク、プロバイダ・ルータ、およびのABR）を除くすべての障害のために、障害通知と収束は不変です。 LERの故障のために、IGPは、特定のプレフィックス、制御プレーン及びプロトコル（例えば、[MP-BGP]）またはアプリケーション（例えば、[L3-VPNのより具体的ルーティング収束挙動をのABR上のIPルートを集約し、もはやアドバタイズすることを考えると】）出口LERノードの障害が発生した場合に変更することができます。出口LERの可用性を追跡する必要があるプロトコルおよびアプリケーションのために、いくつかのソリューションは、たとえば、使用することができます。
- Rely on the LDP ordered label distribution control mode -- as defined in [LDP] -- to know the availability of the LSP toward the egress LER. The egress to ingress propagation time of that unreachability information is expected to be comparable to the IGP (but this may be implementation dependent).
- LDPに任せラベル配布制御モードを命じ - [LDP]で定義されるよう - 出口LERに向かってLSPの利用可能性を知っています。その不到達情報の伝搬時間を進入する出口は、IGPと同等であること（これは実装依存であってもよい）が期待されます。
- Advertise LER reachability in the IGP for the purpose of the control plane in a way that does not create IP FIB entries in the forwarding plane.
- フォワーディングプレーンでIP FIBエントリを作成しない方法で、コントロールプレーンの目的のためにIGPにLERの到達可能性をアドバタイズします。
The Longest-Match Label Mapping procedure described in this
document does not introduce any change as far as the Security
Considerations section of [LDP] is concerned.
[LDP] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[LDP]アンデション、L.、エド。、Minei、I.、エド。、およびB.トーマス、エド。、 "LDP仕様"、RFC 5036、2007年10月。
[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月。
[L3-VPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[L3-VPN]ローゼン、E.およびY. Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）"、RFC 4364、2006年2月。
[MP-BGP] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[MP-BGP]ベイツ、T.、チャンドラ、R.、カッツ、D.、およびY. Rekhter、 "BGP-4のためのマルチプロトコル拡張機能"、RFC 4760、2007年1月。
[MPLS-BGP] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001.
[MPLS-BGP] Rekhter、Y.、およびE.ローゼン、 "BGP-4でのキャリングラベル情報"、RFC 3107、2001年5月。
[IS-IS] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[IS-IS] Callon、R.は、RFC 1195、1990年12月 "OSIの使用は、TCP / IPやデュアル環境でのルーティングのためIS-IS"。
[VPLS-BGP] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007.
[VPLS-BGP] Kompella、K.、エド。、およびY. Rekhter、エド。、 "仮想プライベートLANサービス（VPLS）自動検出およびシグナリングのためにBGPを使用する"、RFC 4761、2007年1月。
[VPLS-LDP] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007.
[VPLS-LDP] Lasserre、M.、エド。、およびV. Kompella、エド。、 "仮想プライベートLANサービス（VPLS）ラベル配布プロトコル（LDP）シグナリングの使用"、RFC 4762、2007年1月を。
[RFC2966] Li, T., Przygienda, T., and H. Smit, "Domain-wide Prefix Distribution with Two-Level IS-IS", RFC 2966, October 2000.
[RFC2966]李、T.、Przygienda、T.、およびH.スミット、RFC 2966、2000年10月の "2レベルでドメイン全体のプレフィックス配布は-IS IS"。
[RSVP-TE] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 5151, February 2008.
[RSVP-TE]ファレル、A.編、Ayyangar、A.、およびJP。 Vasseur、 "ドメイン間MPLSおよびGMPLSトラフィックエンジニアリング - リソース予約プロトコル - トラフィックエンジニアリング拡張機能（RSVP-TE）"、RFC 5151、2008年2月。
[LDP-MIB] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)", RFC 3815, June 2004.
[LDP-MIB] Cucchiara、J.、Sjostrand、H.、およびJ.ルチアーニは、 "マルチプロトコルラベルのための管理オブジェクトの定義は、スイッチング（MPLS）、ラベル配布プロトコル（LDP）"、RFC 3815、2004年6月。
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", Work in Progress, March 2008.
[BFD]カッツ、D.とD.ウォード、 "双方向フォワーディング検出"、進歩、2008年3月に作業。
[IGP-CONV] Francois, P., Filsfils, C., and Evans, J., "Achieving sub-second IGP convergence in large IP networks". ACM SIGCOMM Computer Communications Review, July 2005.
[IGP-CONV]フランソワ、P.、Filsfils、C.、エバンス、J.、 "大規模なIPネットワークにおいてサブ秒IGP収束を達成します"。 ACM SIGCOMMコンピュータコミュニケーションレビュー、2005年7月。
[OSPFv2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
【のOSPFv2]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
The authors would like to thank Yakov Rekhter, Stefano Previdi, Vach Kompella, Bob Thomas, Clarence Filsfils, Kireeti Kompella, Luca Martini, Sina Mirtorabi, Dave McDysan, Benoit Fondeviole, Gilles Bourdon, and Christian Jacquenet for the useful discussions on this subject, their reviews, and comments.
著者は、このテーマに関する有益な議論のためのヤコフ・レックター、ステファノPrevidi、VACH Kompella、ボブ・トーマス、クラレンスFilsfils、Kireeti Kompella、ルカ・マルティーニ、シーナMirtorabi、デイブMcDysan、ブノワFondeviole、ジル・ブルドン、およびキリスト教のJacquenetに感謝したいと思います彼らのレビュー、およびコメント。
Authors' Addresses
著者のアドレス
Bruno Decraene France Telecom 38 rue du General Leclerc 92794 Issy Moulineaux cedex 9 France
ブルーノDecraeneフランステレコム38 RUEデュ一般ルクレール92794イシムリノーCEDEX 9、フランス
EMail: bruno.decraene@orange-ftgroup.com
メールアドレス：bruno.decraene@orange-ftgroup.com
Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France
ジャン=ルイ・ルーフランステレコム2、大通りピエールMarzin 22307ラニオンセデックスフランス
EMail: jeanlouis.leroux@orange-ftgroup.com
メールアドレス：jeanlouis.leroux@orange-ftgroup.com
Ina Minei Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089
伊那Mineiジュニパーネットワークスの1194 N.マチルダアベニュー。サニーベール、CA 94089
EMail: ina@juniper.net
メールアドレス：ina@juniper.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。