[要約] RFC 5283は、LDP拡張機能を使用して、異なるエリア間のラベルスイッチパス（LSP）を確立するための手法を提供します。その目的は、MPLSネットワーク内でのエリア間トラフィックの効率的な転送を可能にすることです。
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)
エリア間ラベルの切り替えパスのLDP拡張（LSP）
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）のエントリと一致する場合、ラベルを使用できます。マッチングは、最も長いマッチ検索で定義され、正確な一致を義務付けていません。
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 [OSPFV2]やIS [IS]などのリンク状態内部ゲートウェイプロトコル（IGPS）は、自律システムをエリアまたはレベルに分割すると、ルーティングドメイン内のルーティングスケーラビリティを向上させることができます。
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.
LSR [ラベルスイッチングルーター]は、下流のLSRからプレフィックスのラベルマッピングメッセージを受信すると、ルーティングテーブルにFEC要素と正確に一致するエントリが含まれていない限り、転送にラベルを使用しないでください。
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.
したがって、さまざまな領域 /レベルのラベルエッジルーター（LERS）間のMPLS LSPは、すべての領域で特定の（IPv4の場合 /32）ループバックアドレスがすべての領域で再分配されない限り、セットアップされません。
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.
問題のステートメントについては、セクション4で説明します。次に、セクション5で、ABRのIPプレフィックス集約を維持しながら、連続的なエリア間LSPのセットアップをサポートするために、[LDP]で定義されたラベルマッピング手順を拡張します。これは、一致した一致ベースのラベルマッピングを可能にすることで構成されています。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
A-AREA INTRA LSP：IGP領域の境界を横断しないLSP。
Inter-area LSP: LSP that traverses at least one IGP area boundary.
エリア間LSP：少なくとも1つのIGP面積境界を通過するLSP。
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.
プロバイダーベースのMPLS（マルチプロトコルラベルスイッチング）ネットワークは、レイヤー3仮想プライベートネットワーク[L3-VPN]の成功と、レイヤー2 VPN（[VPLS-BGP]、[VPLS-LDP]）の新しい展開で拡大しています。サービスプロバイダーのMPLSバックボーンは、新しい顧客を接続するプロバイダーエッジ（PE）ルーターの追加と、従来のレイヤー2集約ネットワークがIP/MPLSネットワークに置き換える可能性があるため、フットプリントの観点から密度の両方で大幅に成長しています。その結果、多くのプロバイダーがIGPエリアを導入する必要があります。エリア間LSP（つまり、少なくとも2つの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]).
さまざまなIGP領域のPE間で必要なMPLS LSPを設定するには、サービスプロバイダーには現在3つのソリューションがあります。1）IGPルートの漏れを伴うLDP、2）MPLS階層を備えたLDP上のBGP [MPLS-BGP]、および3）A-AREA RSVP-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次のホップは通常ABRSであり、BGPが作成したLSPは、PESと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階層では、LSPをABR障害から局所的に保護することはできません（IP/LDP Fast Reroute）。結果の収束時間は、音声またはミッションクリティカルなアプリケーションに必要な厳しいサービスレベル契約（SLA）には受け入れられない場合があります。最後に、このソリューションには、LDPおよびIGPルートが漏れてから最初のエリア間LSPを迅速に設定するサービスプロバイダーに大きな移行努力が必要です。
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のセットアップに使用されている場合、関連するソリューションであり、エリア間の交通工学機能が必要です。その見返りに、これはLDPがすでにエリア内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.
上記の欠点を回避するために、LDPベースのソリューションが必要です。これにより、エリア境界を越えて特定のPEループバックアドレスの漏れを避けながら、隣接するエリア間LSPを設定し、IGP階層のすべての利点を維持します。
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 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をアドレスします）。この手順を構成によってアクティブ化/非アクティブ化することが可能であるはずであり、デフォルトでは非アクティブ化する必要があります。Prefixごとにアクティブ化することが可能かもしれません。
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からラベルマッピングメッセージを受信するLSRがMPLS転送にラベルを使用する必要があります。広告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要素を一致させる」ことにより、最も長い一致を理解する必要があります。つまり、LDP FEC要素がIPリブのエントリと正確に一致するか、FEC要素はIPリブエントリのサブセットです。他のケースには一致しません（つまり、FEC要素がrib 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.
LDPは、最長試合検索中にIPリブにある集計プレフィックスではなく、特定の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は、ラベル引き出しメッセージの伝播を通じて順序付けられた方法で削除されます。このMPLS LSP（[MP-BGP]など）を使用したアプリケーションレイヤーによるこの（UN）Reachability情報の使用は、このドキュメントの範囲外です。
As per [LDP], LDP already has some interactions with the RIB. In particular, it needs to be aware of the following events:
[LDP]によると、LDPにはすでにリブとの相互作用があります。特に、次のイベントに注意する必要があります。
- prefix up when a new IP prefix appears in the RIB,
- リブに新しいIPプレフィックスが表示されたときにプレフィックスが上がります。
- 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が単一のリブプレフィックスの変更を懸念する場合があります。LSRは、このリブプレフィックスのサブセットであるすべての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.
- リブに新しいプレフィックスが表示された場合、LSRは、このプレフィックスが既存のFECに適しているかどうかを確認する必要があります。たとえば、FEC要素192.0.2.1/32および192.0.2.2/32がIPリブエントリ192.0.2.0/24を使用し、新しい具体的なIPリブエントリ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.
- リブでプレフィックスが消えると、LSRはこのリブプレフィックスを使用しているすべてのFEC要素を最高の一致として確認する必要があります。各FECについて、別のリブプレフィックスが最高の一致として見つかった場合、LDPはそれを使用する必要があります。これにより、次のホップとして使用される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.
- リブプレフィックスの次のホップが変更されると、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]に新しい管理オブジェクトを定義して、おそらくPrefixごとにこの最長のラベルマッピングメッセージ手順をアクティブ化/非アクティブ化する場合があります。
Consider the following example of an autonomous system with one backbone area and two edge areas:
1つのバックボーン領域と2つのエッジエリアを持つ自律システムの次の例を考えてみましょう。
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.
図1：バックボーン領域に2つの領域が取り付けられたIGPドメイン。
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
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は、バックボーンエリアに宣伝されています。
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
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
エリアボーダールーター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
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.
この状況では、ABRのIPプレフィックス集約を維持しながら、イングレスPE4とエリアCのすべての出力PEの間に1つのLSPが確立されます。
Consider the following example where a LER is dual-connected to two LSRs:
LERが2つのLSRにデュアル接続されている次の例を考えてみましょう。
+--------LSR1----
| |
LER |
| |
+--------LSR2----
Figure 2: LER dual-connected to two LSRs.
図2：2つの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と2つの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].
このドキュメントに準拠したLSRSは、[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で停止します。他の悪影響はありません。
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.
- エリアごとまたはルーティングごとのドメインごとに展開でき、必ずしも展開を必要とするわけではありません。たとえば、すべての特定の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が既に使用されている場合、この領域のすべてのLSRが正常にアップグレードされるまで、ABRがIGPの特定のIPプレフィックスを宣伝し続けることのみを確認する必要があります。次に、ABRSは集約されたプレフィックスのみを宣伝し、特定のプレフィックスを宣伝するのを停止できます。
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トラフィック回復時間は、コントロールプレーンでの最短パス（SPF）計算と転送情報ベース（FIB） /ラベルFIB（LFIB）の転送面での更新時間の2つの要因に基づいています。SPF計算スケールo（n*log（n））ここで、nはノードの数です。FIB/LFIB更新スケールo（p）ここで、pは修正されたプレフィックスの数です。現在、ほとんどのルーターの実装により、FIB/LFIBアップデートはドミナントコンポーネント[IGP-CONV]であり、したがって優先順位で対処する必要があるボトルネックです。このドキュメントで文書化されたソリューションは、コントロールプレーンのリンク状態データベースサイズと転送面でのFIBエントリの数を削減します。そのため、IGPをMPLSルーターと共有する純粋なIPルーターのスケーリングを解決します。ただし、LFIBエントリの数を減らすことはないため、MPLSルーターのスケーリングを解くには十分ではありません。このためには、追加のメカニズムが必要です（たとえば、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障害（つまり、リンク、プロバイダールーター、ABRS）を除くすべての障害について、障害通知と収束は変更されません。IGPがABRのIPルートを集約し、特定のプレフィックス、コントロールプレーン、より具体的にはプロトコルのルーティング収束動作（[MP-BGP]など）またはアプリケーション（例：[L3-VPN）を宣伝しなくなることを考えると、障害の場合、]）出力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順序付けされたラベル分布制御モードに依存して、Egress 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のリーチ性を宣伝します。
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]のセキュリティに関する考慮事項セクションに関する限り、変更を導入しません。
[LDP] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[LDP] Andersson、L.、ed。、Minei、I.、ed。、およびB. Thomas、ed。、「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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Rosen、E。およびY. Rekhter、「BGP/MPLS IP仮想ネットワーク（VPNS）」、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] Bates、T.、Chandra、R.、Katz、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. Rosen、「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。、「TCP/IPおよびデュアル環境でのルーティングのためのOSI IS-I-ISの使用」、RFC 1195、1990年12月。
[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.、ed。、およびY. Rekhter、ed。、「自動配置とシグナル伝達のためにBGPを使用した仮想プライベートLANサービス（VPLS）」、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.、ed。、およびV. Kompella、ed。、「ラベル分布プロトコル（LDP）シグナル伝達を使用した仮想プライベートLANサービス（VPLS）」、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] Li、T.、Przygienda、T。、およびH. Smit、「2レベルのIS-ISを備えたドメイン全体の接頭分布」、RFC 2966、2000年10月。
[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] Farrel、A.、ed。、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. Luciani、「マルチプロトコルラベルスイッチング（MPLS）の管理オブジェクトの定義、ラベル分布プロトコル（LDP）」、RFC 3815、2004年6月。
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", Work in Progress, March 2008.
[BFD] Katz、D。およびD. Ward、「双方向転送検出」、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] Francois、P.、Filsfils、C。、およびEvans、J。、「大規模なIPネットワークでサブ秒IGP収束を達成する」。ACM Sigcomm Computer Communications Review、2005年7月。
[OSPFv2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPFV2] Moy、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.
著者は、Yakov Rekhter、Stefano Previdi、Vach Kompella、Bob Thomas、Clarence Filsfils、Kireeti Kompella、Luca Martini、Sina Mirtorabi、Dave McDysan、Benoit Fondeviole、Gilles Bourdon、およびChristian Jacquenetに感謝します。彼らのレビューとコメント。
Authors' Addresses
著者のアドレス
Bruno Decraene France Telecom 38 rue du General Leclerc 92794 Issy Moulineaux cedex 9 France
Bruno Decraene France Telecom 38 Rue General Leclerc 92794 Issy Moulineaux Cedex 9 France
EMail: bruno.decraene@orange-ftgroup.com
Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France
Jean-Louis Le Roux France Telecom 2、Avenue Pierre-Marzin 22307 Lannion Cedex France
EMail: jeanlouis.leroux@orange-ftgroup.com
Ina Minei Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089
Ina Misei Juniper Networks 1194 N. Mathilda Ave. Sunnyvale、CA 94089
EMail: ina@juniper.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。