RFC5283 日本語訳
5283 LDP Extension for Inter-Area Label Switched Paths (LSPs). B.Decraene, JL. Le Roux, I. Minei. July 2008. (Format: TXT=26534 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group B. Decraene
Request for Comments: 5283 JL. Le Roux
Category: Standards Track France Telecom
I. Minei
Juniper Networks, Inc.
July 2008
Decraeneがコメントのために要求するワーキンググループB.をネットワークでつないでください: 5283JL。 ル・ルーCategory: 規格はInc.2008年7月にフランス電子通信I.Minei杜松ネットワークを追跡します。
LDP Extension for Inter-Area Label Switched Paths (LSPs)
相互領域のラベルの切り換えられた経路のための自由民主党の拡大(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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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).
与えられたAutonomous System(AS)の複数のIGP領域にかかるLabel Switched Paths(LSPs)の設立を容易にするために、このドキュメントはLabel Distributionプロトコル(自由民主党)のために新しい任意のLongest-マッチLabel Mapping Procedureについて説明します。
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.
Forwarding Equivalence Class(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
1. 序論…2 2. このドキュメントで中古のコンベンション…2 3. 用語…2 4. 問題声明…3 5. 最も長い間、ラベルマッピングメッセージ手順を合わせてください…4 6. アプリケーションの例…6 6.1. 相互領域LSPs…6 6.2. スタティックルートの使用…7 7. 展開のための警告…8 7.1. 展開問題…8 7.2. ルート設定集合時間問題…8 8. セキュリティ問題…9 9. 参照…9 9.1. 標準の参照…9 9.2. 有益な参照…9 10. 承認…11
Decraene, et al. Standards Track [Page 1] RFC 5283 LDP Extension for Inter-Area LSPs July 2008
Decraene、他 規格は2008年7月に相互領域LSPsのためにRFC5283自由民主党拡張子を追跡します[1ページ]。
1. Introduction
1. 序論
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]などの州のInteriorゲートウェイプロトコル(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"):
しかしながら、[自由民主党]は、FEC ElementのIPアドレスが*まさにそうするべきであることを勧めます。*IP経路情報基地(RIB)の中でエントリーに合ってください。 [自由民主党]に従ってセクション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.
Prefix SHOULDのためのLSRがラベルを使用しない川下からの経路指定テーブルがそんなにまさにエントリーを含んでいない場合進められるLabel Mappingメッセージを受け取るLSR[ラベルSwitching Router]はFEC Elementに合っています。
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の特定(例えば、IPv4のための/32)のループバックアドレスがすべての領域の向こう側に再配付されない場合、異なった領域/レベルのLabel Edge Routers(LERs)の間のMPLS LSPsはセットアップされません。
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では、私たちはABRsでIP接頭語集合を維持している間、隣接の相互領域LSPsのセットアップを支持するために[自由民主党]で定義されたLabel Mapping Procedureを広げます。 これは最も長くマッチベースのLabel Mappingを考慮するのから成ります。
2. Conventions Used in This Document
2. 本書では使用されるコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
3. Terminology
3. 用語
IGP Area: OSPF Area or IS-IS level
IGP領域: または、OSPF Area、-、平ら
ABR: OSPF Area Border Router or IS-IS L1/L2 router
ABR: または、OSPF Area Border Router、-、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: 少なくとも1つのIGPエリアの境界を横断するLSP。
Decraene, et al. Standards Track [Page 2] RFC 5283 LDP Extension for Inter-Area LSPs July 2008
Decraene、他 規格は2008年7月に相互領域LSPsのためにRFC5283自由民主党拡張子を追跡します[2ページ]。
4. Problem Statement
4. 問題声明
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(Multiprotocol Label Switching)ネットワークは、Layer3Virtualの成功で兵士のNetworksを広げて[L3-VPN]、Layer2VPNsの新しい展開[VPLS-BGP][VPLS-自由民主党)です。 Provider Edge(PE)ルータの添加に応じて、サービスプロバイダーのMPLS背骨はかなりともに密度で新しい顧客に接するようになっています、そして、伝統的であるとしての足跡で、Layer2集合ネットワークをIP/MPLSネットワークに取り替えるかもしれません。 結果として、多くのプロバイダーが、IGP領域を導入する必要があります。 相互領域LSPs(すなわち、少なくとも2つのIGP領域を横断するLSPs)は異なったIGP領域に位置するPEsの間の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領域でPEsの間の必要なMPLS LSPsをセットアップするために、サービスプロバイダーには、現在、3つの解決策があります: 1) IGPルート漏出、2がある)自由民主党 MPLS階層構造、および3)相互領域RSVP-TE(リソース予約プロトコル交通Engineering[RSVP-TE])がある自由民主党の上のBGP[MPLS-BGP]。
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ループバックアドレスをエリアの境界の向こう側に再配付するのから成ります。 その結果、自由民主党は、RIBでFECに関して完全な一致を見つけて、LSPをセットアップします。 結果として、多くのアドレスがABRsによって再配付されなければならないので、マルチ領域ドメインがもたらすかもしれない潜在的利益はかなり減少していて、ドメイン(それが属す領域/レベルが何であっても)のあらゆるLSRによって維持されたIGP Link州Database(LSDB)、RIB、およびForwarding Information基地(FIB)の中のIPエントリーの数を最小にすることができません。
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階層構造を使用することによって、これらの相互領域LSPsをセットアップするかもしれません。 次のホップが通常そうするBGPはABRsであって、BGPにLSPsが入れ子にされるイントラ領域LSPsがPEsとABRsの間と、そして、ABRsの間に自由民主党で設定する作成です。
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.
すべてのABRsの上のBGPを必要とするときそれらのプロバイダールータでBGPを走らせたがっていないサービスプロバイダーには、この解決策は適切ではありません。 さらに、MPLS階層構造で、局所的にABRの故障(IP/自由民主党Fast Reroute)に対してLSPを保護して、したがって、ABRの故障でサブ50msに回復を確実にしません。 声か必要不可欠なアプリケーションに必要である厳しいサービス・レベル・アグリーメント(SLA)において、結果として起こる集合時間は許容できないかもしれません。 最終的に、この解決策は自由民主党とIGPルート漏出から最初の相互領域LSPsをすぐにセットアップし始めたサービスプロバイダーに、重要な移動の努力を必要とします。
Decraene, et al. Standards Track [Page 3] RFC 5283 LDP Extension for Inter-Area LSPs July 2008
Decraene、他 規格は2008年7月に相互領域LSPsのためにRFC5283自由民主党拡張子を追跡します[3ページ]。
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]を使用することによって、これらの相互領域LSPsをセットアップするかもしれません。 RSVP- TEがイントラ領域LSPsをセットアップするのに既に使用されるとき、これは関連解決策です、そして、相互領域交通工学機能が必要です。 自由民主党がイントラ領域LSPsをセットアップするのに既に使用されて、相互領域交通工学機能は必要でないときに、代わりに、これが必要な解決策ではありません。
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ループバックアドレスを漏れさせるのを避けている間に隣接の相互領域LSPsをセットアップする自由民主党ベースの解決策の必要があります、その結果、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.
その文脈では、このドキュメントは、ABRsでIP接頭語集合を維持している間、隣接の相互領域LSPsのセットアップを支持するために新しい自由民主党Label Mapping Procedureを定義します。 この手順は、[自由民主党]で定義されたものと同様ですが、FEC要素を捜すとき、RIBでIPの最も長いマッチを実行します。
5. Longest-Match Label Mapping Message Procedure
5. 最も長いマッチラベルマッピングメッセージ手順
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.
このドキュメントは[自由民主党]のために新しいLabel Mapping Procedureを定義します。 それはIPv4とIPv6接頭語FEC要素(IANAサイトでの「アドレスファミリーナンバ」登録に従ってアドレス家族1と2)に適切です。 それ、SHOULD、構成、およびそれでこの手順を活性化するか、または非活性化するのにおいて可能なSHOULD、デフォルトで非活性化されてください。 1接頭語あたり1個のベースでそれを動かすのは可能であるかもしれません。
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.
この新しいLongest-マッチLabel Mapping Procedure、Prefix Address FEC Element FEC1 SHOULDのために隣人LSRからLabel Mappingメッセージを受け取るLSRと共に経路指定テーブルがFEC Element FEC1に合っているエントリーを含んでいて、広告LSRが次のホップであるならMPLS推進に範囲FEC1にラベルを使用してください。 そうだとすれば、それ、SHOULDは容認されたFEC Element FEC1とラベルの自由民主党の同輩に広告を出します。
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 Element」で、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.
このLongest-マッチLabel Mapping Procedureと共に、自由民主党によって設立された各LSPがIGPによって定義された最短パスにまだ厳密に続いていることに注意してください。
Decraene, et al. Standards Track [Page 4] RFC 5283 LDP Extension for Inter-Area LSPs July 2008
Decraene、他 規格は2008年7月に相互領域LSPsのためにRFC5283自由民主党拡張子を追跡します[4ページ]。
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.
このLongest-マッチLabel Mapping Procedureによって選択されたFECsは規則正しい方法で分配されます。 LERの故障の場合には、FECへの可到達性の取り外しは、ラベル分配モード手順が注文された自由民主党を使用することで起こります。 [自由民主党]でセクションA.1.5で定義されるように、FECはLabel Withdrawメッセージの伝播で規則正しい方法で取り外されるでしょう。 これの使用、(不-、)、このドキュメントの範囲の外にこのMPLS LSP(例えば、[MP-BGP])を使用する応用層のそばの可到達性情報があります。
As per [LDP], LDP already has some interactions with the RIB. In particular, it needs to be aware of the following events:
[自由民主党]に従って、自由民主党には、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:
このLongest-マッチLabel Mapping Message Procedureに、複数のFECsは単一のRIB接頭語変化によって関係があらせるかもしれません。 LSR MUSTはこのRIB接頭語の部分集合であるすべてのFECsをチェックします。 それで、RIB出来事に続いて起こるいくつかの自由民主党の反応を変えます:
- 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に現れると、LSR MUSTは、いくつかの既存のFECsがないかどうかこの接頭語が、より良いマッチであるかどうかチェックします。 そして、例えば、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のためのしたがって、Next Hop Label Forwarding Entry(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 MUSTは最も良いマッチとしてこのRIB接頭語を使用しているすべてのFEC要素をチェックします。 各FECのために、別のRIB接頭語が最も良いマッチとして見つけられるなら、自由民主党はそれを使用しなければなりません。 これは次として中古のLSRが飛び越す変化とこのFECのためのしたがって、NHLFEをもたらすかもしれません。 さもなければ、LSR MUSTはFEC結合を取り除いて、Label Withdrawメッセージを送ります。
- 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 MUSTは、この接頭語を使用することですべての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.
今後の活動はこのLongest-マッチLabel Mapping Message Procedureを動かすか、または非活性化するためにMPLS LDP MIBモジュール[自由民主党-MIB]と新しい管理物を定義するかもしれません、ことによると1接頭語あたり1個のベースで。
Decraene, et al. Standards Track [Page 5] RFC 5283 LDP Extension for Inter-Area LSPs July 2008
Decraene、他 規格は2008年7月に相互領域LSPsのためにRFC5283自由民主党拡張子を追跡します[5ページ]。
6. Application Examples
6. アプリケーションの例
6.1. Inter-Area LSPs
6.1. 相互領域LSPs
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
+----------+ +-------------+
| |
+--------------------------+
+--------------------------+ 領域「A」| | 領域「C」| | レベル1| | レベル1/領域| 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ドメインは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.
これが等しく適用する注意、-、そして、OSPF。 または、ABRがここでOSPF ABRを参照する、-、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--自由民主党におけるすべての特定のIP FEC要素(/32)
Decraene, et al. Standards Track [Page 6] RFC 5283 LDP Extension for Inter-Area LSPs July 2008
Decraene、他 規格は2008年7月に相互領域LSPsのためにRFC5283自由民主党拡張子を追跡します[6ページ]。
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
境界ルータABR2は領域「A」に広告を出します: - IGPの集められたIP接頭語192.0.2.0/24--自由民主党におけるすべての個々のIP FEC要素(/32)
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.
この状況に、1LSPがABRsでIP接頭語集合を維持している間、イングレスPE4と領域Cのあらゆる出口PEの間に設立されます。
6.2. Use of Static Routes
6.2. スタティックルートの使用
Consider the following example where a LER is dual-connected to two LSRs:
LERが二元的に2LSRsに接続されている以下の例を考えてください:
+--------LSR1----
| |
LER |
| |
+--------LSR2----
+--------LSR1---- | | LER| | | +--------LSR2----
Figure 2: LER dual-connected to two LSRs.
図2: 二元的に2LSRsに接続されたLER。
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と2LSRsの間の静的なIPルートを使用するのが有効です。 必要なら、すぐに接続性の損失を検出するのに、Bidirectional Forwarding Detectionプロトコル[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.
[自由民主党]で定義された自由民主党仕様はイングレスLERで出口LERと外向的なインタフェースあたり1つのIPルートの構成と維持を必要とするでしょう。
The Longest-Match Label Mapping Procedure described in this document only requires one IP route per outgoing interface.
Label Mapping Procedureが説明したLongest-マッチは本書では外向的なインタフェースあたり1つのIPルートしか必要としません。
Decraene, et al. Standards Track [Page 7] RFC 5283 LDP Extension for Inter-Area LSPs July 2008
Decraene、他 規格は2008年7月に相互領域LSPsのためにRFC5283自由民主党拡張子を追跡します[7ページ]。
7. Caveats for Deployment
7. 展開のための警告
7.1. Deployment Considerations
7.1. 展開問題
LSRs compliant with this document are backward compatible with LSRs that comply with [LDP].
このドキュメントで言いなりになっているLSRsは[自由民主党]に従うLSRsと互換性があった状態で後方です。
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.
終わりから終わりへのFECsがRIBで集められるMPLS LSPsのうまくいっている設立において、IP集合が使用されているすべての領域のすべてのLSRsでこの仕様を履行しなければなりません。 経路の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.
- そして、または、領域でそれを配備できる、-、経路ドメイン、基礎、必ず、AS全体の展開を必要とするというわけではありません。 例えば、すべての特定のIP接頭語がIGP背骨領域で漏らされて、スタッブ領域だけがIP集合を使用するなら、背骨領域のLSRsはこのドキュメントで言いなりになる必要はありません。
- 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.
- それぞれのルーティング領域の中では、LSRsはいつでも、どんな注文、およびサービスの崩壊なしでも独自にアップグレードできます。 展開の間、それらのLSPsが既に使用される場合にだけ、ABRsがこの領域のすべてのLSRsが首尾よくアップグレードするまで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]で議論するように準最適のルーティングをもたらすかもしれないのを意識しているべきです。
7.2. Routing Convergence Time Considerations
7.2. ルート設定集合時間問題
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
IPとMPLS交通回復時間は2つの要素に基づいています: 制御飛行機のShortest Path First(SPF)計算と推進飛行機のForwarding情報基地の(FIB)/ラベルFIB(LFIB)アップデート時間。 SPF計算はOをスケーリングします。(NがNodesの数であるN*ログ(N))。 FIB/LFIBアップデートはPが変更された接頭語の数であるO(P)をスケーリングします。 したがって、現在、ほとんどのルータ実現で、FIB/LFIBアップデートは、優位なコンポーネント[IGP-CONV]と、優先権で記述されるべきであるボトルネックです。 本書では記録された解決策は制御飛行機のリンク州のデータベースサイズと推進飛行機のFIBエントリーの数を減少させます。 そういうものとして、それはスケーリングを解決します。
Decraene, et al. Standards Track [Page 8] RFC 5283 LDP Extension for Inter-Area LSPs July 2008
Decraene、他 規格は2008年7月に相互領域LSPsのためにRFC5283自由民主党拡張子を追跡します[8ページ]。
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.
MPLSルータとIGPを共有する純粋なIPルータ。 しかしながら、それはLFIBエントリーの数をMPLSルータのスケーリングを解決できないくらいには減少させません。 これに関しては、追加メカニズムが必要です(例えば、自由民主党で何らかの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:
LERの故障(すなわち、リンク、プロバイダールータ、およびABRs)以外のすべての失敗によって[自由民主党]と比べて、失敗通知と集合は変わりがありません。 LERの故障において、IGPがABRsの上のIPルートに集めて、もう特定の接頭語の広告を出さないなら、出口LERノードの失敗の場合にプロトコル(例えば、[MP-BGP])かアプリケーション(例えば、[L3-VPN])の制御飛行機と、より明確にルーティング集合働きを変えるかもしれません。 出口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).
- ラベル配給統制モードが[自由民主党]で定義されるように注文された自由民主党を当てにしてください--出口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.
- 制御飛行機の目的のためにIGPに推進飛行機でIP FIBエントリーを作成しない方法でLERの可到達性の広告を出してください。
8. Security Considerations
8. セキュリティ問題
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.
[自由民主党]のSecurity Considerations部に関する限り、本書では説明されたLongest-マッチLabel Mapping手順は少しの変化も導入しません。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[LDP] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, October 2007.
[自由民主党] アンデション、L.、エド、Minei、I.、エド、B.トーマス、エド、「自由民主党仕様」、RFC5036、10月2007日
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
9.2. Informative References
9.2. 有益な参照
[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仮想私設網(VPNs)」、RFC4364 2006年2月。
Decraene, et al. Standards Track [Page 9] RFC 5283 LDP Extension for Inter-Area LSPs July 2008
Decraene、他 規格は2008年7月に相互領域LSPsのためにRFC5283自由民主党拡張子を追跡します[9ページ]。
[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インチのためのMultiprotocol拡張子、RFC4760、2007年1月。」
[MPLS-BGP] Rekhter, Y. and E. Rosen, "Carrying Label Information
in BGP-4", RFC 3107, May 2001.
「BGP-4インチ、RFC3107、2001年5月にラベル情報を運ぶ」[MPLS-BGP]Rekhter、Y.、およびE.ローゼン。
[IS-IS] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[-、]、Callon、R.、「使用、TCP/IPと二元的な環境におけるルーティングのためのOSI IS存在、」、RFC1195、12月1990日
[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を使用して、合図すること」でのRFC4761(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-自由民主党]ラセール、M.(エド)、およびV.Kompella(エド)、「ラベル分配を使用する仮想の個人的なLANサービス(VPLS)が(自由民主党)シグナリングについて議定書の中で述べます」、RFC4762、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.スミット、「2レベルとのドメイン全体の接頭語分配、-、」、RFC2966、10月2000日
[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)拡大」、RFC5151、2月2008日
[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.
[自由民主党-MIB] Cucchiara、J.、シェストランド、H.、およびJ.Luciani、「Multiprotocolラベル切り換え(MPLS)のための管理オブジェクトの定義、ラベル分配は(自由民主党)について議定書の中で述べます」、RFC3815、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] 「大きいIPネットワークでサブ2番目のIGP集合を達成する」フランソアとP.とFilsfils、C.とエヴァンス、J.。 ACM SIGCOMMコンピュータコミュニケーションは2005年7月に再検討されます。
[OSPFv2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
1998.
[OSPFv2]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
Decraene, et al. Standards Track [Page 10] RFC 5283 LDP Extension for Inter-Area LSPs July 2008
Decraene、他 規格は2008年7月に相互領域LSPsのためにRFC5283自由民主党拡張子を追跡します[10ページ]。
10. Acknowledgments
10. 承認
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.
作者はこの問題、彼らのレビュー、およびコメントについての役に立つ議論についてヤコフRekhter、ステファーノPrevidi、Vach Kompella、ボブ・トーマス、クラレンスFilsfils、Kireeti Kompella、ルカMartini、シーナMirtorabi、デーヴMcDysan、ブノワFondeviole、ジルBourdon、およびクリスチャンのJacquenetに感謝したがっています。
Authors' Addresses
作者のアドレス
Bruno Decraene France Telecom 38 rue du General Leclerc 92794 Issy Moulineaux cedex 9 France
ブルーノDecraeneフランステレコム38悔悟duルクレール92794Issy Moulineaux cedex9司令官フランス
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、大通りピアー-Marzin22307Lannion Cedexフランス
EMail: jeanlouis.leroux@orange-ftgroup.com
メール: jeanlouis.leroux@orange-ftgroup.com
Ina Minei Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089
伊奈Minei杜松は1194N.マチルダAveをネットワークでつなぎます。 サニーベル、カリフォルニア 94089
EMail: ina@juniper.net
メール: ina@juniper.net
Decraene, et al. Standards Track [Page 11] RFC 5283 LDP Extension for Inter-Area LSPs July 2008
Decraene、他 規格は2008年7月に相互領域LSPsのためにRFC5283自由民主党拡張子を追跡します[11ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Decraene, et al. Standards Track [Page 12]
Decraene、他 標準化過程[12ページ]
一覧
スポンサーリンク
