Network Working Group E. Rosen
Request for Comments: 4577 P. Psenak
Updates: 4364 P. Pillay-Esnault
Category: Standards Track Cisco Systems, Inc.
June 2006
OSPF as the Provider/Customer Edge Protocol for
BGP/MPLS IP Virtual Private Networks (VPNs)
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）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
Many Service Providers offer Virtual Private Network (VPN) services to their customers, using a technique in which customer edge routers (CE routers) are routing peers of provider edge routers (PE routers). The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. This is known as a "BGP/MPLS IP VPN". The base specification for BGP/MPLS IP VPNs presumes that the routing protocol on the interface between a PE router and a CE router is BGP. This document extends that specification by allowing the routing protocol on the PE/CE interface to be the Open Shortest Path First (OSPF) protocol.
多くのサービスプロバイダは、顧客のエッジルータ（CEルータ）技術を使用して、顧客に仮想プライベートネットワーク（VPN）サービスを提供プロバイダーエッジルータ（PEルータ）のピアをルーティングしています。ボーダーゲートウェイプロトコル（BGP）は、プロバイダのIPバックボーンネットワークを介して顧客のルートを配布するために使用され、マルチプロトコルラベルスイッチング（MPLS）は、プロバイダのバックボーン間でトンネル顧客パケットに使用されています。これは、 "BGP / MPLS IP VPN" として知られています。 BGP / MPLS IP VPNの基本仕様は、PEルータとCEルータ間のインターフェイス上でルーティングプロトコルがBGPであることを前提。この文書では、PE / CEインターフェイス上のルーティングプロトコルは、オープンショーテストパスファースト（OSPF）プロトコルとすることができるようにすることで、その仕様を拡張します。
This document updates RFC 4364.
この文書は、RFC 4364に更新します。
Table of Contents
目次
1. Introduction ....................................................2
2. Specification of Requirements ...................................3
3. Requirements ....................................................4
4. BGP/OSPF Interaction Procedures for PE Routers ..................6
4.1. Overview ...................................................6
4.1.1. VRFs and OSPF Instances .............................6
4.1.2. VRFs and Routes .....................................6
4.1.3. Inter-Area, Intra-Area, and External Routes .........7
4.1.4. PEs and OSPF Area 0 .................................8
4.1.5. Prevention of Loops .................................9
4.2. Details ....................................................9
4.2.1. Independent OSPF Instances in PEs ...................9
4.2.2. Router ID ..........................................10
4.2.3. OSPF Areas .........................................10
4.2.4. OSPF Domain Identifiers ............................10
4.2.5. Loop Prevention ....................................12
4.2.5.1. The DN Bit ................................12
4.2.5.2. Use of OSPF Route Tags ....................12
4.2.5.3. Other Possible Loops ......................13
4.2.6. Handling LSAs from the CE ..........................14
4.2.7. Sham Links .........................................16
4.2.7.1. Intra-Area Routes .........................16
4.2.7.2. Creating Sham Links .......................17
4.2.7.3. OSPF Protocol on Sham Links ...............18
4.2.7.4. Routing and Forwarding on Sham Links ......19
4.2.8. VPN-IPv4 Routes Received via BGP ...................19
4.2.8.1. External Routes ...........................20
4.2.8.2. Summary Routes ............................22
4.2.8.3. NSSA Routes ...............................22
5. IANA Considerations ............................................22
6. Security Considerations ........................................23
7. Acknowledgements ...............................................23
8. Normative References ...........................................23
9. Informative References .........................................24
[VPN] describes a method by which a Service Provider (SP) can use its IP backbone to provide a VPN (Virtual Private Network) service to customers. In that method, a customer's edge devices (CE devices) are connected to the provider's edge routers (PE routers). If the CE device is a router, then the PE router may become a routing peer of the CE router (in some routing protocol) and may, as a result, learn the routes that lead to the CE's site and that need to be distributed to other PE routers that attach to the same VPN.
[VPN]サービスプロバイダ（SP）が顧客にVPN（仮想プライベートネットワーク）サービスを提供するために、そのIPバックボーンを使用することができる方法を説明します。その方法では、顧客のエッジ機器（CE機器）は、プロバイダのエッジルータ（PEルータ）に接続されています。 CE装置がルータである場合には、PEルータは、（いくつかのルーティングプロトコルにおける）CEルータのルーティングピアになることがあり、結果として、CEのサイトにつながるルートを学習とに分配すべき必要があるかもしれません同じVPNに接続他のPEルータ。
The PE routers that attach to a common VPN use BGP (Border Gateway Protocol) to distribute the VPN's routes to each other. A CE router can then learn the routes to other sites in the VPN by peering with its attached PE router in a routing protocol. CE routers at different sites do not, however, peer with each other.
一般的なVPNに接続PEルータは、相互にVPNの経路を配布するBGP（ボーダーゲートウェイプロトコル）を使用します。 CEルータは、ルーティングプロトコルにおけるその取り付けPEルータとのピアリングにより、VPN内の他のサイトへのルートを学習することができます。異なるサイトのCEルータは、しかし、お互いにじっとしていません。
It can be expected that many VPNs will use OSPF (Open Shortest Path First) as their IGP (Interior Gateway Protocol), i.e., the routing protocol used by a network for the distribution of internal routes within that network. This does not necessarily mean that the PE routers need to use OSPF to peer with the CE routers. Each site in a VPN can use OSPF as its intra-site routing protocol, while using, for example, BGP [BGP] or RIP (Routing Information Protocol) [RIP] to distribute routes to a PE router. However, it is certainly convenient, when OSPF is being used intra-site, to use it on the PE-CE link as well, and [VPN] explicitly allows this.
多くのVPNはそのIGP（インテリアゲートウェイプロトコル）、すなわち、そのネットワーク内の内部経路の配信のためにネットワークによって使用されるルーティングプロトコルとしてOSPF（オープンショーテストパスファースト）を使用することが期待できます。これは必ずしもPEルータは、CEルータとピアにOSPFを使用する必要があることを意味するものではありません。使用しながら、VPN内の各サイトは、BGP [BGP]またはRIP（ルーティング情報プロトコル）[RIP]はPEルータへのルートを配布するために、例えば、そのサイト内のルーティングプロトコルとしてOSPFを使用することができます。 OSPFは、同様にPE-CEリンク上でそれを使用するために、サイト内で使用されている場合しかし、それは、確かに便利で、[VPN]明示的にこれができます。
Like anything else, the use of OSPF on the PE-CE link has advantages and disadvantages. The disadvantage to using OSPF on the PE-CE link is that it gets the SP's PE router involved, however peripherally, in a VPN site's IGP. The advantages though are:
何か他のものと同様に、PE-CEリンク上のOSPFの使用は長所と短所があります。 PE-CEリンク上でOSPFを使用することの欠点は、VPNサイトのIGPで、しかし末梢、関与SPのPEルータを取得するということです。しかし利点は以下のとおりです。
- The administrators of the CE router need not have any expertise in any routing protocol other than OSPF.
- CEルータの管理者は、OSPF以外のルーティングプロトコルのいずれかの専門知識を持つ必要はありません。
- The CE routers do not need to have support for any routing protocols other than OSPF.
- CEルータはOSPF以外のルーティングプロトコルのサポートを持っている必要はありません。
- If a customer is transitioning his network from a traditional OSPF backbone to the VPN service described in [VPN], the use of OSPF on the PE-CE link eases the transitional issues.
- 顧客は[VPN]で説明VPNサービスに、伝統的なOSPFバックボーンから自分のネットワークに移行している場合は、PE-CEリンク上のOSPFの使用は過渡的な問題を容易にします。
It seems likely that some SPs and their customers will resolve these trade-offs in favor of the use of OSPF on the PE-CE link. Thus, we need to specify the procedures that must be implemented by a PE router in order to make this possible. (No special procedures are needed in the CE router though; CE routers just run whatever OSPF implementations they may have.)
これは、いくつかのSPとその顧客は、PE-CEリンク上のOSPFの使用を支持してこれらのトレードオフを解決する可能性が高いようです。したがって、我々は、これを可能にするために、PEルータで実装されなければならない手順を指定する必要があります。 （特別な手順はいえCEルータで必要とされていない、CEルータはちょうど彼らが持っているかもしれどんなOSPFの実装を実行します。）
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]に記載されているように解釈されます。
Consider a set of VPN sites that are thought of as being in the same "OSPF domain". Two sites are considered to be in the same OSPF domain if it is intended that routes from one site to the other be considered intra-network routes. A set of OSPF sites in the same domain will almost certainly be a set of sites that together constitute an "intranet", each of which runs OSPF as its intra-site routing protocol.
同じ「OSPFドメイン」にあると考えられているVPNサイトのセットを考えてみましょう。二つのサイトは、他にあるサイトからのルートは、ネットワーク内の経路とみなされることが意図されている場合は、同じOSPFドメインにあると考えられています。同じドメイン内のOSPFサイトのセットは、ほぼ確実に一緒にそのサイト内のルーティングプロトコルとしてOSPFを実行してそれぞれが「イントラネット」を構成する部位のセットとなります。
Per [VPN], the VPN routes are distributed among the PE routers by BGP. If the PE uses OSPF to distribute routes to the CE router, the standard procedures governing BGP/OSPF interactions [OSPFv2] would cause routes from one site to be delivered to another in type 5 LSAs (Link State Advertisements), as "AS-external" routes. This is undesirable; it would be much better to deliver such routes in type 3 LSAs (as inter-area routes), so that they can be distinguished from any "real" AS-external routes that may be circulating in the VPN (that is, so that they can be distinguished by OSPF from routes that really do not come from within the VPN). Hence, it is necessary for the PE routers to implement a modified version of the BGP/OSPF interaction procedures.
[VPN]あたり、VPNルートは、BGPによってPEルータ間で分散されています。 PEは、CEルータに経路を配布するOSPFを使用している場合、BGP / OSPF相互作用を支配する標準的な手順[OSPFv2は一つのサイトからのルートは、「AS-外部ようなタイプ別に5のLSA（リンクステートアドバタイズメント）を、配信される原因となります「ルート。これは望ましくありません。彼らは（つまり、VPN内を循環することができる任意の「本物の」AS-外部経路と区別できるように、（エリア間のルートのような）タイプ3 LSAを、このような経路を提供するためにはるかに良いとなるように、それら本当にVPN内から来ていない路線）からOSPFで区別することができます。 PEルータは、BGP / OSPF相互作用手順の修正バージョンを実装するため、それが必要です。
In fact, we would like to have a very general set of procedures that allows a customer to replace a legacy private OSPF backbone easily with the VPN service. We would like this procedure to meet the following set of requirements:
実際には、我々は、顧客がVPNサービスで簡単にレガシープライベートOSPFバックボーンを交換することを可能にする手順の非常に一般的なセットを持っていると思います。私たちは、要件の次のセットを満たすために、この手順をしたいと思います。
- The procedures should not make assumptions about the OSPF topology. In particular, it should not be assumed that customer sites are OSPF stub sites or NSSA (Not So Stubby Area) sites. Nor should it be assumed that a customer site contains only one OSPF area, or that it has no area 0 routers.
- 手順は、OSPFトポロジに関する仮定を行うべきではありません。特に、顧客サイトは、OSPFスタブサイトまたはNSSA（ないスタビーエリア）サイトであると仮定するべきではありません。また、顧客のサイトが一つだけのOSPFエリアが含まれているか、それはエリア0ルータを持っていないことを想定しなければなりません。
- If VPN sites A and B are in the same OSPF domain, then routes from one should be presented to the other as OSPF intra-network routes. In general, this can be done by presenting such routes as inter-area routes in type 3 LSAs.
- VPNサイトAとBが同じOSPFドメインにある場合、1からルートはOSPFイントラネットワークルートなどの他に提示されるべきです。一般に、これはタイプ3のLSAにエリア間のルートのような経路を提示することによって行うことができます。
Note that this allows two VPN sites to be connected via an "OSPF backdoor link". That is, one can have an OSPF link between the two sites that is used only when the VPN backbone is unavailable. (This would not be possible with the ordinary BGP/OSPF interaction procedures. The ordinary procedures would present routes via the VPN backbone as AS-external routes, and these could never be preferred to intra-network routes.) This may be very useful during a period of transition from a legacy OSPF backbone to a VPN backbone.
これは、2つのVPNサイトは、「OSPFバックドアリンク」を介して接続することを可能にすることに注意してください。つまり、1は、VPNバックボーンが利用できない場合にのみ使用される2つのサイト間のOSPFのリンクを持つことができます。 （これは、通常のBGP / OSPF相互作用手順で可能ではないであろう。通常の手順は、AS-外部ルートとしてVPNバックボーンを介してルートを提示するであろう、そしてこれらは、イントラネットワークルートに好まれることはありませんでした。）これは、中に非常に有用であり得ますVPNバックボーンに、従来のOSPFバックボーンからの移行期。
- It should be possible to make use of an "OSPF backdoor link" between two sites, even if the two sites are in the same OSPF area and neither of the routers attached to the inter-site backdoor link is an area 0 router. This can also be very useful during a transition period, and it eliminates any need to reconfigure the sites' routers to be ABRs (Area Border Routers).
- 2つのサイトが同じOSPFエリア内にあり、サイト間のバックドアリンクに接続されたルータのどちらもエリア0ルータの場合でも、2つのサイト間の「OSPFバックドアリンク」を利用することが可能でなければなりません。これはまた、移行期間中に非常に役立つことができ、そしてそれはのABR（エリア境界ルータ）であることをサイトのルータを再設定する必要がなくなります。
Assuming that it is desired to have the route via the VPN backbone be preferred to the backdoor route, the VPN backbone itself must be presented to the CE routers at each site as a link between the two PE routers to which the CE routers are respectively attached.
バックドア経路に好まれるVPNバックボーンを経由する経路を有することが望まれると仮定すると、VPNバックボーン自体は、CEルータがそれぞれ取り付けられた2つのPEルータ間のリンクとして各サイトにCEルータに提示されなければなりません。
- CE routers, connected to PE routers of the VPN service, may themselves function as OSPF backbone (area 0) routers. An OSPF backbone may even consist of several "segments" that are interconnected themselves only via the VPN service. In such a scenario, full intercommunication between sites connected to different segments of the OSPF backbone should still be possible.
- OSPFバックボーン（エリア0）ルータなどのVPNサービスのルータをPEに接続されたCEルータ、よい自体機能。 OSPFバックボーンだけでもVPNサービスを介して自分自身を相互に接続されているいくつかの「セグメント」から構成されてもよいです。そのようなシナリオでは、OSPFバックボーンの異なるセグメントに接続された部位との間の完全な相互通信がまだ可能であるべきです。
- The transition from the legacy private OSPF backbone to the VPN service must be simple and straightforward. The transition is likely to be phased, such that customer sites are migrated one by one from the legacy private OSPF backbone to the VPN service. During the transition, any given site might be connected to the VPN service, to the legacy OSPF backbone, or to both. Complete connectivity among all such sites must be maintained.
- VPNサービスへのレガシープライベートOSPFバックボーンからの移行は単純明快でなければなりません。移行は、顧客サイトは、VPNサービスにレガシープライベートOSPFバックボーンから一つずつ移行されるように、段階的にされる可能性が高いです。移行時には、任意のサイトには、レガシーOSPFバックボーンに、または両方に、VPNサービスに接続される可能性があります。このようなすべてのサイト間の完全な接続性を維持しなければなりません。
Since the VPN service is to replace the legacy backbone, it must be possible, by suitable adjustment of the OSPF metrics, to make OSPF prefer routes that traverse the SP's VPN backbone to alternative routes that do not.
VPNサービスは、従来のバックボーンを交換することですので、それはOSPFにはない代替ルートにSPのVPNバックボーンを通過するルートを好む作るために、OSPFメトリックを適切に調整することで、可能でなければなりません。
- The OSPF metric assigned to a given route should be carried transparently over the VPN backbone.
- 指定されたルートに割り当てられたOSPFメトリックは、VPNバックボーン上に透過的に行われるべきです。
Routes from sites that are not in the same OSPF domain will appear as AS-external routes.
同じOSPFドメインにないサイトからのルートはAS外部ルートとして表示されます。
We presuppose familiarity with the contents of [OSPFv2], including the OSPF LSA types, and will refer without further exegesis to type 1, 2, 3, etc. LSAs. Familiarity with [VPN] is also presupposed.
我々は、OSPF LSAタイプを含む〔のOSPFv2]の内容に精通して前提とし、1、2、3、等LSAを入力し、さらに釈義なしに言及します。 [VPN]に精通しても前提とされます。
A PE router that attaches to more than one OSPF domain MUST run an independent instance of OSPF for each domain. If the PE is running OSPF as its IGP (Interior Gateway Protocol), the instance of OSPF running as the IGP must be separate and independent from any other instance of OSPF that the PE is running. (Whether these instances are realized as separate processes or merely as separate contexts of a common process is an implementation matter.) Each interface that attaches to a VPN site belongs to no more than one OSPF instance.
複数のOSPFドメインに付着PEルータは、各ドメインのためのOSPFの独立したインスタンスを実行する必要があります。 PEがそのIGP（インテリアゲートウェイプロトコル）としてOSPFを実行している場合、IGPとして実行OSPFのインスタンスは、PEが実行されていることをOSPFの任意の他のインスタンスから別個で独立しなければなりません。 （これらの例は、共通のプロセスの別のコンテキストとして単に別々のプロセスまたはとして実現されるかどうかは、インプリメンテーションの問題である。）VPNサイトに付着各インターフェイスが1個以下のOSPFインスタンスに属します。
[VPN] defines the notion of a Per-Site Routing and Forwarding Table, or VRF. Each VRF is associated with a set of interfaces. If a VRF is associated with a particular interface, and that interface belongs to a particular OSPF instance, then that OSPF instance is said to be associated with the VRF. If two interfaces belong to the same OSPF instance, then both interfaces must be associated with the same VRF.
[VPN]の概念を定義するごとサイトルーティングおよび転送テーブル、またはVRF。各VRFは、インターフェースのセットに関連付けられています。 VRFは、特定のインターフェイスに関連付けられ、そのインターフェースは、特定のOSPFインスタンスに属している場合は、そのOSPFインスタンスは、VRFに関連付けされていると言われます。二つのインターフェースが同じOSPFインスタンスに属している場合、両方のインターフェイスが同じVRFに関連付けられなければなりません。
If an interface attaches a PE to a CE, and that interface is associated with a VRF, we will speak of the CE as being associated with the VRF.
インターフェイスは、CEへのPEを添付し、そのインターフェイスをVRFに関連付けられている場合、我々は、VRFに関連するものとしてCEの話をします。
OSPF is used to distribute routes from a CE to a PE. The standard OSPF decision process is used to install the best OSPF-distributed routes in the VRF.
OSPFは、PEにCEからルートを配布するために使用されます。標準のOSPF決定プロセスは、VRFで最高のOSPF-配布されたルートをインストールするために使用されます。
Per [VPN], BGP is used to distribute VPN-IPv4 routes among PE routers. An OSPF route installed in a VRF may be "exported" by being redistributed into BGP as a VPN-IPv4 route. It may then be distributed by BGP to other PEs. At the other PEs, a VPN-IPv4 route may be "imported" by a VRF and may then be redistributed into one or more of the OSPF instances associated with that VRF.
[VPN]あたり、BGPは、PEルータ間でVPN-IPv4ルートを配布するために使用されます。 VRFに設置OSPF経路は、VPN-IPv4ルートとしてBGPに再配布されることによって「エクスポート」することができます。その後、他のPEへのBGPで配布することができます。他のPEでは、VPN-IPv4ルートはVRFによって「インポート」されてもよいし、そのVRFに関連付けられたOSPFインスタンスの一つ以上に再配布することができます。
Import from and export to particular VRFs is controlled by the use of the Route Target Extended Communities attribute (or, more simply, Route Target or RT), as specified in [VPN].
[VPN]で指定されるようにからインポートおよび特定のVRFにエクスポートがルートターゲットの使用によって制御され、コミュニティ属性（または、より単純に、ルートターゲット又はRT）を拡張しました。
A VPN-IPv4 route is "eligible for import" into a particular VRF if its Route Target is identical to one of the VRF's import Route Targets. The standard BGP decision process is used to select, from among the routes eligible for import, the set of VPN-IPv4 routes to be "installed" in the VRF.
そのルートターゲットは、VRFのインポートルートターゲットのものと同一である場合にはVPN-IPv4ルートは、特定のVRFに「インポートの対象」です。標準BGP決定プロセスは、インポート対象のルートの中から、VRFに「インストール」するVPN-IPv4ルートのセットを選択するために使用されます。
If a VRF contains both an OSPF-distributed route and a VPN-IPv4 route for the same IPv4 prefix, then the OSPF-distributed route is preferred. In general, this means that forwarding is done according to the OSPF route. The one exception to this rule has to do with the "sham link". If the next hop interface for an installed (OSPF-distributed) route is the sham link, forwarding is done according to a corresponding BGP route. This is detailed in Section 4.2.7.4.
VRFは、OSPF-分散経路と同じIPv4のプレフィックスのためのVPN-IPv4ルートの両方が含まれている場合、OSPF-分散経路が好ましいです。一般に、これは、転送がOSPF経路に従って行われることを意味します。この規則の唯一の例外は、「偽リンク」に関係しています。インストール（OSPF-分散）ルートのネクストホップインターフェイスは偽のリンクである場合、転送は、対応するBGPルートに従って行われます。これは、セクション4.2.7.4で詳述されます。
To meet the requirements of Section 3, a PE that installs a particular route into a particular VRF needs to know whether that route was originally an OSPF route and, if so, whether the OSPF instance from which it was redistributed into BGP is in the same domain as the OSPF instances into which the route may be redistributed. Therefore, a domain identifier is encoded as a BGP Extended Communities attribute [EXTCOMM] and distributed by BGP along with the VPN-IPv4 route. The route's OSPF metric and OSPF route type are also carried as BGP attributes of the route.
もしそうであれば第3の要件を満たすために、特定のVRFへの特定のルートをインストールPEは、BGPに再配布されたOSPFインスタンスが同じであるかどうか、そのルートが最初OSPF経路であったかどうかを知る必要があるとルートが再配布され得るにOSPFインスタンスとしてドメイン。したがって、ドメイン識別子は、BGP拡張コミュニティは、[EXTCOMM]属性として符号化され、VPN-IPv4ルートと共にBGPによって分配されます。 BGPルートの属性としてルートのOSPFメトリックとOSPFのルートタイプも搭載されています。
If a PE installs a particular VPN-IPv4 route (learned via BGP) in a VRF, and if this is the preferred BGP route for the corresponding IPv4 prefix, the corresponding IPv4 route is then "eligible for redistribution" into each OSPF instance that is associated with the VRF. As a result, it may be advertised to each CE in an LSA.
PEはVRFに（BGPを介して学習された）特定のVPN-IPv4ルートをインストールし、これは、対応するIPv4のプレフィックスのための好ましいBGPルートである場合、対応するIPv4ルートは、各OSPFインスタンスにし、「再分配の対象」である場合VRFに関連付けられています。その結果、LSAの各CEに通知することができます。
Whether a route that is eligible for redistribution into OSPF is actually redistributed into a particular OSPF instance may depend upon the configuration. For instance, the PE may be configured to distribute only the default route into a given OSPF instance. In this case, the routes that are eligible for redistribution would not actually be redistributed.
OSPFへの再配布の対象となる経路が実際に特定のOSPFインスタンスに再配布されたか否かの設定に依存し得ます。例えば、PEは、与えられたOSPFインスタンスにのみデフォルトルートを分配するように構成されてもよいです。この場合、再配分の対象となる路線は、実際に再配布することはないだろう。
In the following, we discuss the procedures for redistributing a BGP-distributed VPN-IPv4 route into OSPF; these are the procedures to be followed whenever such a route is eligible to be redistributed into OSPF and the configuration does not prevent such redistribution.
以下では、OSPFにBGP-分散VPN-IPv4ルートを再配布するための手順を議論します。これらは、そのようなルートがOSPFに再配布の対象であり、構成は、このような再分配を妨げないときはいつでも従うべき手順です。
If the route is from an OSPF domain different from that of the OSPF instance into which it is being redistributed, or if the route is not from an OSPF domain at all, then the route is considered an external route.
ルートは、それが再配布されているにOSPFインスタンスとは異なるOSPFドメインからのものである場合、経路が全くOSPFドメインからではない場合、または、その経路は、外部経路であると考えられます。
If the route is from the same OSPF domain as the OSPF instance into which it is being redistributed, and if it was originally advertised to a PE as an OSPF external route or an OSPF NSSA route, it will be treated as an external route. Following the normal OSPF procedures, external routes may be advertised to the CE in type 5 LSAs, or in type 7 LSAs, or not at all, depending on the type of area to which the PE/CE link belongs.
ルートは、それが再分配され、それは元々OSPF外部ルートまたはOSPF NSSAルートとしてPEにアドバタイズされた場合、それは外部経路として処理されるにOSPFインスタンスと同じOSPFドメインからのものである場合。通常のOSPFの手順に従って、外部経路は、PE / CEリンクが所属するエリアの種類に応じて、全く7のLSA、またはしないタイプ5のLSAにCEに通知、またはタイプでもよいです。
If the route is from the same OSPF domain as the OSPF instance into which it is being redistributed, and if it was originally advertised to a PE as an inter-area or intra-area route, the route will generally be advertised to the CE as an inter-area route (in a type 3 LSA).
ルートは、それが再配布されているにOSPFインスタンスと同じOSPFドメインからであり、それは元々間領域またはエリア内のルートとしてPEにアドバタイズされた場合、ルートは、一般的にCEなどにアドバタイズされる場合（タイプ3 LSAで）エリア間のルート。
As a special case, suppose that PE1 attaches to CE1, and that PE2 attaches to CE2, where:
特別な場合として、PE1がCE1に接続すると仮定し、PE2はCE2、に取り付けること：
- the OSPF instance containing the PE1-CE1 link and the OSPF instance containing the PE2-CE2 link are in the same OSPF domain, and
- PE1-CE1リンクおよびPE2-CE2リンクを含むOSPFインスタンスを含むOSPFインスタンスは、同じOSPFドメインであり、そして
- the PE1-CE1 and PE2-CE2 links are in the same OSPF area A (as determined by the configured OSPF area number),
- PE1-CE1及びPE2-CE2リンクが同じOSPFエリアA（構成OSPFエリアの数によって決定される）であり、
then, PE1 may flood to CE1 a type 1 LSA advertising a link to PE2, and PE2 may flood to CE2 a type 1 LSA advertising a link to PE1. The link advertised in these LSAs is known as a "sham link", and it is advertised as a link in area A. This makes it look to routers within area A as if the path from CE1 to PE1 across the service provider's network to PE2 to CE2 is an intra-area path. Sham links are an OPTIONAL feature of this specification and are used only when it is necessary to have the service provider's network treated as an intra-area link. See Section 4.2.7 for further details about the sham link.
その後、PE1がCE1にPE2へのリンクを広告するタイプ1 LSAをあふれさせることができ、PE2はCE2にPE1へのリンクを広告するタイプ1 LSAをあふれさせることがあります。これらのLSAで広告リンクが「偽リンク」として知られており、それはPE2へのサービスプロバイダのネットワークを介してCE1からPE1へのパスかのように面積A内のルータに見えるの領域Aにリンクとして宣伝されていますCE2にエリア内のパスです。シャムリンクは、この仕様のオプション機能であり、サービスプロバイダのネットワークは、エリア内のリンクとして扱わ持っていることが必要である場合にのみ使用されます。偽リンクについて詳しくは、セクション4.2.7を参照してください。
The precise details by which a PE determines the type of LSA used to advertise a particular route to a CE are specified in Section 4.2.8. Note that if the VRF is associated with multiple OSPF instances, the type of LSA used to advertise the route might be different in different instances.
PEは、CEへの特定のルートをアドバタイズするために使用されるLSAのタイプを決定することにより、正確な詳細はセクション4.2.8で指定されています。 VRFは、複数のOSPFインスタンスに関連付けられている場合、LSAのタイプはルートが異なるインスタンスで異なる場合があります宣伝するために使用されていることに注意してください。
Note that if a VRF is associated with several OSPF instances, a given route may be redistributed into some or all of those OSPF instances, depending on the characteristics of each instance. If redistributed into two or more OSPF instances, it may be advertised within each instance using a different type of LSA, again depending on the characteristics of each instance.
VRFは、いくつかのOSPFインスタンスに関連付けられている場合、指定されたルートは、各インスタンスの特性に応じて、それらのOSPFインスタンスの一部またはすべてに再配布されてもよいことに留意されたいです。二つ以上のOSPFインスタンスに再配布する場合は、再度、各インスタンスの特性に応じて、LSAの異なる種類を使用して、各インスタンス内でアドバタイズされてもよいです。
Within a given OSPF domain, a PE may attach to multiple CEs. Each PE/CE link is assigned (by configuration) to an OSPF area. Any link can be assigned to any area, including area 0.
所与OSPFドメイン内で、PEは、複数のCEに取り付けることができます。各PE / CEリンクは、OSPFエリアに（構成によって）割り当てられます。任意のリンクは、エリア0を含め、任意の領域に割り当てることができます。
If a PE attaches to a CE via a link that is in a non-zero area, then the PE serves as an ABR for that area.
PEは、非ゼロの領域内にあるリンクを介してCEに付着する場合、PEはそのエリアのABRとして機能します。
PEs can thus be considered OSPF "area 0 routers", i.e., they can be considered part of the "OSPF backbone". Thus, they are allowed to distribute inter-area routes to the CE via Type 3 LSAs.
PEはこのようにOSPF「エリア0ルータ」、即ち、それらは「OSPFバックボーン」の一部と考えることができると考えることができます。したがって、それらは、タイプ3のLSAを介してCEへのエリア間のルートを配布を許可されています。
If the OSPF domain has any area 0 routers other than the PE routers, then at least one of those MUST be a CE router and MUST have an area 0 link to at least one PE router. This adjacency MAY be via an OSPF virtual link. (The ability to use an OSPF virtual link in this way is an OPTIONAL feature.) This is necessary to ensure that inter-area routes and AS-external routes can be leaked between the PE routers and the non-PE OSPF backbone.
OSPFドメインはPEルータ以外のエリア0ルータがある場合、それらの少なくとも一つは、CEルータでなければなりませんと、少なくとも1つのPEルータのエリア0のリンクを持たなければなりません。この隣接関係は、OSPF仮想リンクを介してもよいです。 （このようにOSPF仮想リンクを使用する能力は、オプション機能である。）これは、エリア間ルートことを確実にするために必要であり、AS-外部ルートがPEルータと非PE OSPFバックボーンとの間に漏洩することができます。
Two sites that are not in the same OSPF area will see the VPN backbone as being an integral part of the OSPF backbone. However, if there are area 0 routers that are NOT PE routers, then the VPN backbone actually functions as a sort of higher-level backbone, providing a third level of hierarchy above area 0. This allows a legacy OSPF backbone to become disconnected during a transition period, as long as the various segments all attach to the VPN backbone.
同じOSPFエリアにされていない2つのサイトでは、OSPFバックボーンの不可欠な一部であるとしてVPNバックボーンが表示されます。 PEルータされていないエリア0ルータが存在する場合は、次にVPNバックボーンは、実際にはこれはレガシーOSPFバックボーンは、中に切断なることを可能にするエリア0上の階層の第3レベルを提供し、より高いレベルのバックボーンの一種として機能します移行期間、様々なセグメントすべてがVPNバックボーンに接続する限り。
If a route sent from a PE router to a CE router could then be received by another PE router from one of its own CE routers, it would be possible for routing loops to occur. To prevent this, a PE sets the DN bit [OSPF-DN] in any LSA that it sends to a CE, and a PE ignores any LSA received from a CE that already has the DN bit sent. Older implementations may use an OSPF Route Tag instead of the DN bit, in some cases. See Sections 4.2.5.1 and 4.2.5.2.
CEルータにPEルータから送信された経路がそれ自身のCEルータの1つから別のPEルータによって受信することができれば、それが発生するループをルーティングすることも可能です。これを防止するために、PEは、CEに送信し、PEは、LSAが既にDNが送信ビットたCEから受信した任意のものを無視する任意のLSAの[OSPF-DN] DNビットをセットします。古い実装は、いくつかのケースでは、OSPFルートタグの代わりにDNビットを使用することができます。セクション4.2.5.1と4.2.5.2を参照してください。
The PE MUST support one OSPF instance for each OSPF domain to which it attaches. These OSPF instances function independently and do not leak routes to each other. Each instance of OSPF MUST be associated with a single VRF. If n CEs associated with that VRF are running OSPF on their respective PE/CE links, then those n CEs are OSPF adjacencies of the PE in the corresponding instance of OSPF.
PEは、それが付着した各OSPFドメインのための一つのOSPFインスタンスをサポートしなければなりません。これらOSPFインスタンスは、独立して機能し、お互いへのルートを漏れません。 OSPFの各インスタンスは、単一のVRFに関連付けられなければなりません。そのVRFに関連付けられたN個のCEは、それぞれのPE / CEリンク上でOSPFを実行している場合、それらのn個のCEはOSPFの対応するインスタンスにおけるPEのOSPFの隣接関係です。
Generally, though not necessarily, if the PE attaches to several CEs in the same OSPF domain, it will associate the interfaces to those PEs with a single VRF.
PEは、同じOSPFドメイン内のいくつかのCEに接続されている場合、一般的に、必ずしも必要ではないけれども、それは単一のVRFとのそれらのPEへのインターフェイスを関連付けます。
If a PE and a CE are communicating via OSPF, the PE will have an OSPF Router ID that is valid (i.e., unique) within the OSPF domain. More precisely, each OSPF instance has a Router ID. Different OSPF instances may have different Router IDs.
PEとCEは、OSPFを介して通信している場合、PEは、OSPFドメイン内の有効な（すなわち、一意）であるOSPFルータIDを有することになります。より正確には、各OSPFインスタンスは、ルータIDを有しています。異なるOSPFインスタンスが異なるルータIDを持つことができます。
A PE-CE link may be in any area, including area 0; this is a matter of the OSPF configuration.
PE-CEリンクは、エリア0を含む任意の領域であってもよいです。これは、OSPFの設定の問題です。
If a PE has a link that belongs to a non-zero area, the PE functions as an Area Border Router (ABR) for that area.
PEは、非ゼロ領域に属するリンクを有する場合、その領域のエリア境界ルータ（ABR）としてPE機能します。
PEs do not pass along the link state topology from one site to another (except in the case where a sham link is used; see Section 4.2.7).
PEは（偽のリンクを使用している場合を除き、セクション4.2.7を参照）別のサイトからのリンク状態トポロジーに沿って通過しません。
Per [OSPFv2, Section 3.1], "the OSPF backbone always contains all area border routers". The PE routers are therefore considered area 0 routers. Section 3.1 of [OSPFv2] also requires that area 0 be contiguous. It follows that if the OSPF domain has any area 0 routers other than the PE routers, at least one of those MUST be a CE router, and it MUST have an area 0 link (possibly a virtual link) to at least one PE router.
[OSPFv2の、セクション3.1]パー、「OSPFバックボーンは、常にすべてのエリア境界ルータが含まれています」。 PEルータは、したがって、エリア0ルータと考えられます。 [OSPFv2の]のセクション3.1はまた、エリア0が連続していることが必要です。 OSPFドメインはPEルータ以外のエリア0ルータを有する場合、それらの少なくとも一つは、CEルータでなければなりません、そして、それは、少なくとも1つのPEルータにエリア0リンク（おそらく仮想リンク）が必要ということになります。
Each OSPF instance MUST be associated with one or more Domain Identifiers. This MUST be configurable, and the default value (if none is configured) SHOULD be NULL.
各OSPFインスタンスは、1つ以上のドメイン識別子に関連付けられなければなりません。これは構成可能でなければなりません、そして（何も設定されていない場合）、デフォルト値はNULLであるべきです。
If an OSPF instance has multiple Domain Identifiers, one of these is considered its "primary" Domain Identifier; this MUST be determinable by configuration. If an OSPF instance has exactly one Domain Identifier, this is of course its primary Domain Identifier. If an OSPF instance has more than one Domain Identifier, the NULL Domain Identifier MUST NOT be one of them.
OSPFインスタンスは、複数のドメイン識別子を有する場合、これらの一つは、その「一次」ドメイン識別子であると考えられます。これは、設定によって決定でなければなりません。 OSPFインスタンスは正確に一つのドメイン識別子を持っている場合、これは当然のことながら、その主ドメイン識別子です。 OSPFインスタンスが複数のドメイン識別子を持っている場合は、NULLドメイン識別子は、そのうちの一つにすることはできません。
If a route is installed in a VRF by a particular OSPF instance, the primary Domain Identifier of that OSPF instance is considered the route's Domain Identifier.
経路が特定のOSPFインスタンスによってVRFにインストールされている場合は、そのOSPFインスタンスのプライマリドメイン識別子は、ルートのドメイン識別子と考えられています。
Consider a route, R, that is installed in a VRF by OSPF instance I1, then redistributed into BGP as a VPN-IPv4 route, and then installed by BGP in another VRF. If R needs to be redistributed into OSPF instance I2, associated with the latter VRF, the way in which R is advertised in I2 will depend upon whether R's Domain Identifier is one of I2's Domain Identifiers. If R's Domain Identifier is not one of I2's Domain Identifiers, then, if R is redistributed into I2, R will be advertised as an AS-external route, no matter what its OSPF route type is. If, on the other hand, R's Domain Identifier is one of I2's Domain Identifiers, how R is advertised will depend upon R's OSPF route type.
別のVRFにBGPによってインストール次にVPN-IPv4ルートとしてBGPに再配布し、その後、それはOSPFインスタンスI1によってVRFにインストールされ、R、ルートを考えます。 Rは、OSPFインスタンスI2に再配布する必要がある場合は、後者のVRFに関連付けられた、RがI2でアドバタイズされた方法は、Rのドメイン識別子は、I2のドメイン識別子の一つであるかどうかに依存するであろう。 Rのドメイン識別子は、I2のドメイン識別子のいずれでもない場合は、R I2に再配布された場合、その後、Rは関係なく、そのOSPFのルートタイプが何であるか、AS外部ルートとしてアドバタイズされません。場合は、他の一方で、Rのドメイン識別子は、Rは、RのOSPFのルートタイプに依存するアドバタイズされるか、I2のドメイン識別子の一つです。
If two OSPF instances are in the same OSPF domain, then either:
2つのOSPFインスタンスが同じOSPFドメインにある場合、次のいずれか
2. Each OSPF instance has the primary Domain Identifier of the other as one of its own Domain Identifiers.
2.各OSPFインスタンスは、自身のドメイン識別子の一つとして、他の一次ドメイン識別子を有しています。
If two OSPF instances are in different OSPF domains, then either:
2つのOSPFインスタンスが異なるOSPFドメインにある場合は、次のいずれか
4. Neither OSPF instance has the Primary Domain Identifier of the other as one of its own Domain Identifiers.
4. OSPFインスタンスいずれも、それ自身のドメイン識別子の一つとして、他のプライマリドメイン識別子を有します。
(Note that if two OSPF instances each have the NULL Domain Identifier, we cannot tell from the Domain Identifier whether they are in the same OSPF Domain. If they are in different domains, and if routes from one are distributed into the other, the routes will appear as intra-network routes, which may not be what is intended.)
（それらは異なるドメインにある場合二つOSPFインスタンスそれぞれがNULLドメイン識別子を持っている場合、我々は、彼らが同じOSPFドメイン内にあるかどうかをドメイン識別子と言うことができないことに注意してください、1からルートは、ルートの他に分配されている場合意図されるものではないかもしれないれ、イントラネットワークルートとして表示されます。）
A Domain Identifier is an eight-byte quantity that is a valid BGP Extended Communities attribute, as specified in Section 4.2.4. If a particular OSPF instance has a non-NULL Domain Identifier, when routes from that OSPF instance are distributed by BGP as VPN-IPv4 routes, the routes MUST carry the Domain Identifier Extended Communities attribute that corresponds to the OSPF instance's Primary Domain Identifier. If the OSPF instance's Domain Identifier is NULL, the Domain Identifier Extended Communities attribute MAY be omitted when routes from that OSPF instance are distributed by BGP; alternatively, a value of the Domain Identifier Extended Communities attribute that represents NULL (see Section 4.2.4) MAY be carried with the route.
ドメイン識別子は、セクション4.2.4に指定されている有効なBGP拡張コミュニティは、属性である8バイトの量です。特定のOSPFインスタンスが非NULLドメイン識別子を有する場合、そのOSPFインスタンスからルートがVPN-IPv4ルートとしてBGPによって分配されている場合、ルートは、ドメイン識別子は、OSPFインスタンスのプライマリドメイン識別子に対応するコミュニティ属性を拡張運ばなければなりません。 OSPFインスタンスのドメイン識別子がNULLである場合は、そのOSPFインスタンスからのルートをBGPで配布されている場合、ドメイン識別子拡張コミュニティを省略することができる属性。代替的に、ドメイン識別子の値がNULLを表すコミュニティ属性（セクション4.2.4を参照）の経路で実施することができる拡張しました。
If the OSPF instances of an OSPF domain are given one or more non-NULL Domain Identifiers, this procedure allows us to determine whether a particular OSPF-originated VPN-IPv4 route belongs to the same domain as a given OSPF instance. We can then determine whether the route should be redistributed to that OSPF instance as an inter-area route or as an OSPF AS-external route. Details can be found in Sections 4.2.4 and 4.2.8.1.
OSPFドメインのOSPFインスタンスは、1つ以上の非NULLドメイン識別子を与えられている場合、この手順は、私たちは、特定のOSPF-発信VPN-IPv4ルートは、所定のOSPFインスタンスと同じドメインに属しているかどうかを決定することを可能にします。我々は、次に、ルートは、エリア間のルートとして、またはOSPF AS外部ルートとしてそのOSPFインスタンスに再配布する必要があるかどうかを決定することができます。詳細は、セクション4.2.4と4.2.8.1で見つけることができます。
When a type 3 LSA is sent from a PE router to a CE router, the DN bit [OSPF-DN] in the LSA Options field MUST be set. This is used to ensure that if any CE router sends this type 3 LSA to a PE router, the PE router will not redistribute it further.
タイプ3 LSAは、CEルータにPEルータから送信された場合、LSAオプションフィールドにDNビット[OSPF-DN]は設定しなければなりません。これは、任意のCEルータがPEルータにこのタイプ3 LSAを送信した場合、PEルータがさらに再配布しないことを保証するために使用されます。
When a PE router needs to distribute to a CE router a route that comes from a site outside the latter's OSPF domain, the PE router presents itself as an ASBR (Autonomous System Border Router), and distributes the route in a type 5 LSA. The DN bit [OSPF-DN] MUST be set in these LSAs to ensure that they will be ignored by any other PE routers that receive them.
PEルータはCEルータに後者のOSPFドメインの外部サイトから来るルートを配布する必要がある場合、PEルータはASBR（自律システム境界ルータ）としての地位を提示し、タイプ5 LSAにルートを分配します。 DNビット[OSPF-DN]は、彼らがそれらを受信する他のPEルータによって無視されることを保証するために、これらのLSAに設定されなければなりません。
There are deployed implementations that do not set the DN bit, but instead use OSPF route tagging to ensure that a type 5 LSA generated by a PE router will be ignored by any other PE router that may receive it. A special OSPF route tag, which we will call the VPN Route Tag (see Section 4.2.5.2), is used for this purpose. To ensure backward compatibility, all implementations adhering to this specification MUST by default support the VPN Route Tag procedures specified in Sections 4.2.5.2, 4.2.8.1, and 4.2.8.2. When it is no longer necessary to use the VPN Route Tag in a particular deployment, its use (both sending and receiving) may be disabled by configuration.
DNビットを設定し、その代わりにPEルータによって生成されたタイプ5 LSAはそれを受け取ることができる任意の他のPEルータによって無視されることを確実にするためにタグ付けOSPFルートを使用しない展開の実装が存在します。私たちは、VPNルートタグを呼び出します特別なOSPFルートタグは、（セクション4.2.5.2を参照）、この目的のために使用されています。下位互換性を確保するために、デフォルトでこの仕様MUSTに付着したすべての実装は、セクション4.2.5.2、4.2.8.1、および4.2.8.2に指定されたVPNルートタグの手続きをサポートしています。それは特定の展開、その使用は、（両方の送信側と受信側）にVPNルートタグを使用する必要がなくなりました場合には設定で無効にすることができます。
If a particular VRF in a PE is associated with an instance of OSPF, then by default it MUST be configured with a special OSPF route tag value, which we call the VPN Route Tag. By default, this route tag MUST be included in the Type 5 LSAs that the PE originates (as the result of receiving a BGP-distributed VPN-IPv4 route, see Section 4.2.8) and sends to any of the attached CEs.
PE中の特定のVRFをOSPFのインスタンスに関連付けられている場合、デフォルトでは、我々はVPNルートタグを呼び出す特別なOSPFルートタグ値を設定する必要があります。デフォルトでは、このルートタグは、PEの発信元は、（BGP-分散VPN-IPv4ルートを受信した結果として、セクション4.2.8を参照）、取り付けられたCEのいずれかに送信するタイプ5のLSAに含まれなければなりません。
The configuration and inclusion of the VPN Route Tag is required for backward compatibility with deployed implementations that do not set the DN bit in type 5 LSAs. The inclusion of the VPN Route Tag may be disabled by configuration if it has been determined that it is no longer needed for backward compatibility.
構成およびVPNルートタグの包含は、タイプ5のLSAにDNビットを設定しない展開の実装との下位互換性のために必要とされます。それはもはや下位互換性のために必要であると判断されていない場合、VPNルートタグを含めることは、設定で無効にすることができます。
The value of the VPN Route Tag is arbitrary but must be distinct from any OSPF Route Tag being used within the OSPF domain. Its value MUST therefore be configurable. If the Autonomous System number of the VPN backbone is two bytes long, the default value SHOULD be an automatically computed tag based on that Autonomous System number:
VPNルートタグの値は任意であるが、OSPFドメイン内で使用されている任意のOSPFルートタグは区別しなければなりません。その値は、したがって、構成可能でなければなりません。 VPNバックボーンの自律システム番号は2バイト長である場合、デフォルト値は、その自律システム番号に基づいて自動的に計算されたタグする必要があります。
Tag = <Automatic = 1, Complete = 1, PathLength = 01>
タグ= <完全自動= 1、= 1、光路長= 01>
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1|0|1| ArbitraryTag | AutonomousSystem |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 _AS number of the VPN Backbone_
1 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 VPN Backbone_の_As番号
If the Autonomous System number is four bytes long, then a Route Tag value MUST be configured, and it MUST be distinct from any Route Tag used within the VPN itself.
自律システム番号は4バイト長である場合には、ルートタグ値を設定する必要があり、それはVPN自体内で使用される任意のルートタグ異なるものでなければなりません。
If a PE router needs to use OSPF to distribute to a CE router a route that comes from a site outside the CE router's OSPF domain, the PE router SHOULD present itself to the CE router as an Autonomous System Border Router (ASBR) and SHOULD report such routes as AS-external routes. That is, these PE routers originate Type 5 LSAs reporting the extra-domain routes as AS-external routes. Each such Type 5 LSA MUST contain an OSPF route tag whose value is that of the VPN Route Tag. This tag identifies the route as having come from a PE router. The VPN Route Tag MUST be used to ensure that a Type 5 LSA originated by a PE router is not redistributed through the OSPF area to another PE router.
PEルータは、CEルータにCEルータのOSPFドメイン外のサイトから来ているルートを配布するためにOSPFを使用する必要がある場合は、PEルータは、自律システム境界ルータ（ASBR）としてCEルータに自分自身を提示しなければならないし、報告しなければなりませんAS-外部ルートなどのルート。つまり、これらのPEルータがAS外部ルートとして追加のドメインのルートを報告するタイプ5 LSAを発信、です。このような各タイプ5 LSAは、その値がVPNルートタグのものであるOSPFルートタグを含まなければなりません。このタグは、PEルータから来るものとして経路を識別する。 VPNルートタグは、PEルータによって発信タイプ5 LSAは、別のPEルータにOSPFエリアを介して再配布されないことを確実にするために使用されなければなりません。
The procedures specified in this document ensure that if routing information derived from a BGP-distributed VPN-IPv4 route is distributed into OSPF, it cannot be redistributed back into BGP as a VPN-IPv4 route, as long as the DN bit and/or VPN route tag is maintained within the OSPF domain. This does not eliminate all possible sources of loops. For example, if a BGP VPN-IPv4 route is distributed into OSPF, then distributed into RIP (where all the information needed to prevent looping is lost), and then distributed back into OSPF, then it is possible that it could be distributed back into BGP as a VPN-IPv4 route, thereby causing a loop.
この文書で指定された手順は、BGP-分散VPN-IPv4ルートから誘導経路情報をOSPFに分配されている場合、それは限りDNビット及び/又はVPNなど、VPN-IPv4ルートとしてバックBGPに再配布することができないことを保証しますルートタグは、OSPFドメイン内に維持されます。これは、ループのすべての可能なソースがなくなるわけではありません。 BGP VPN-IPv4ルートをOSPFに分配されている場合、例えば、次にバックOSPFに分配次いで（ループを防止するために必要なすべての情報が失われている）RIPに分配し、そして、それがバックに分配することが可能ですBGPは、VPN-IPv4ルートとして、それによってループを引き起こします。
Therefore, extreme care must be taken if there is any mutual redistribution of routes between the OSPF domain and any third routing domain (i.e., not the VPN backbone). If the third routing domain is a BGP domain (e.g., the public Internet), the ordinary BGP loop prevention measures will prevent the route from reentering the OSPF domain.
OSPFドメインと任意の第三のルーティングドメイン（すなわち、ないVPNバックボーン）との間の経路の任意の相互再分配がある場合したがって、細心の注意を払わなければなりません。第三のルーティングドメインが、BGPドメイン（例えば、公衆インターネット）であれば、通常のBGPループ防止対策は、OSPFドメインを再入力からルートを防止します。
This section specifies the way in which a PE router handles the OSPF LSAs it receives from a CE router.
このセクションでは、PEルータが、それはCEルータから受信したOSPF LSAを処理する方法を指定します。
When a PE router receives, from a CE router, any LSA with the DN bit [OSPF-DN] set, the information from that LSA MUST NOT be used by the route calculation. If a Type 5 LSA is received from the CE, and if it has an OSPF route tag value equal to the VPN Route Tag (see Section 4.2.5.2), then the information from that LSA MUST NOT be used by the route calculation.
PEルータは、CEルータから、DNビット[OSPF-DN]が設定された任意のLSAを受信すると、そのLSAからの情報はルート計算で使用してはいけません。タイプ5 LSAは、CEから受信し、それがVPNルートタグに等しいOSPFルートタグ値を有する場合（セクション4.2.5.2を参照）である場合、そのLSAからの情報はルート計算で使用してはいけません。
Otherwise, the PE must examine the corresponding VRF. For every address prefix that was installed in the VRF by one of its associated OSPF instances, the PE must create a VPN-IPv4 route in BGP. Each such route will have some of the following Extended Communities attributes:
それ以外の場合は、PEは、対応するVRFを調べる必要があります。それに関連付けられたOSPFインスタンスのいずれかによってVRFにインストールされたすべてのアドレスプレフィックスのために、PEは、BGPにおけるVPN-IPv4ルートを作成する必要があります。 ：ような各ルートは、次の拡張コミュニティのいくつかの属性があります
- The OSPF Domain Identifier Extended Communities attribute. If the OSPF instance that installed the route has a non-NULL primary Domain Identifier, this MUST be present; if that OSPF instance has only a NULL Domain Identifier, it MAY be omitted. This attribute is encoded with a two-byte type field, and its type is 0005, 0105, or 0205. For backward compatibility, the type 8005 MAY be used as well and is treated as if it were 0005. If the OSPF instance has a NULL Domain Identifier, and the OSPF Domain Identifier Extended Communities attribute is present, then the attribute's value field must be all zeroes, and its type field may be any of 0005, 0105, 0205, or 8005.
- OSPFドメイン識別子拡張コミュニティ属性。ルートをインストールOSPFインスタンスが非NULLプライマリドメイン識別子を有する場合、これが存在しなければなりません。そのOSPFインスタンスのみNULLドメイン識別子を持っている場合、それは省略されるかもしれません。この属性は、2バイトのタイプフィールドで符号化され、そのタイプは、タイプ8005は、同様に使用することができる0005、0105、または下位互換性のために0205であり、それは0005.であるかのようにOSPFインスタンスを持っている場合処理されています拡張コミュニティ属性をNULLドメイン識別子、およびOSPFドメイン識別子は、属性の値フィールドがすべてゼロでなければならない、存在し、そのタイプフィールドは0005、0105、0205、または8005のいずれであってもよいです。
- OSPF Route Type Extended Communities Attribute. This attribute MUST be present. It is encoded with a two-byte type field, and its type is 0306. To ensure backward compatibility, the type 8000 SHOULD be accepted as well and treated as if it were type 0306. The remaining six bytes of the Attribute are encoded as follows:
- OSPFルートタイプ拡張コミュニティ属性。この属性が存在しなければなりません。これは、2バイトのタイプフィールドで符号化され、その種類は次のように、タイプ8000は、同様に受け入れられ、それは属性の残りの6つのバイトが符号化されたタイプ0306.であるかのように扱われるべき下位互換性を確保するために0306.であります：
+-------+-------+-------+-------+-------+-------+
| Area Number | Route |Options|
| | Type | |
+-------+-------+-------+-------+-------+-------+
* Area Number: 4 bytes, encoding a 32-bit area number. For AS-external routes, the value is 0. A non-zero value identifies the route as being internal to the OSPF domain, and as being within the identified area. Area numbers are relative to a particular OSPF domain.
*エリア番号：4バイト、32ビットのエリア番号を符号化します。 AS-外部ルートの場合、値はゼロ以外の値は、OSPFドメインの内部にあるように経路を特定し、特定された領域内にあるように0です。エリア番号は、特定のOSPFドメインに関連しています。
* OSPF Route Type: 1 byte, encoded as follows:
* OSPFルートのタイプ：1バイト、次のようにエンコードされました：
** 1 or 2 for intra-area routes (depending on whether the route came from a type 1 or a type 2 LSA).
**エリア内のルート（ルートはタイプ1又はタイプ2 LSAから来たかどうかに応じて）のために1又は2です。
** 3 for inter-area routes.
**エリア間ルートの3。
** 5 for external routes (area number must be 0).
**外部経路（領域番号は、0でなければならない）5。
** 7 for NSSA routes.
** 7 NSSA経路のために。
Note that the procedures of Section 4.2.8 do not make any distinction between routes types 1, 2, and 3. If BGP installs a route of one of these types in the VRF, and if that route is selected for redistribution into OSPF, it will be advertised by OSPF in either a type 3 or a type 5 LSA, depending on the domain identifier.
それは、BGPはVRF内のこれらのタイプのいずれかの経路をインストールする場合、セクション4.2.8の手順はルートタイプ1、2、および3の間の任意の区別をしないように注意し、そのルートがOSPFに再配布するために選択された場合ドメイン識別子に応じて、タイプ3又はタイプ5 LSAのいずれかでOSPFによってアドバタイズされるであろう。
* Options: 1 byte. Currently, this is only used if the route type is 5 or 7. Setting the least significant bit in the field indicates that the route carries a type 2 metric.
*オプション：1バイト。ルート・タイプが5または7である場合、現在、これが唯一のフィールドの最下位ビットの設定に使用される経路は2メトリックタイプを運ぶことを示しています。
- OSPF Router ID Extended Communities Attribute. This OPTIONAL attribute specifies the OSPF Router ID of the system that is identified in the BGP Next Hop attribute. More precisely, it specifies the OSPF Router Id of the PE in the OSPF instance that installed the route into the VRF from which this route was exported. This attribute is encoded with a two-byte type field, and its type is 0107, with the Router ID itself carried in the first 4 bytes of the value field. The type 8001 SHOULD be accepted as well, to ensure backward compatibility, and should be treated as if it were 0107.
- OSPFルータID拡張コミュニティ属性。このオプション属性は、BGPネクストホップ属性で識別されているシステムのOSPFルータIDを指定します。より正確には、このルートがエクスポートされたVRFにルートをインストールOSPFインスタンス内のPEのOSPFルータIDを指定します。この属性は、2バイトタイプフィールドで符号化され、そのタイプは、値フィールドの最初の4バイトで運ばルータID自体で、0107です。タイプ8001は、下位互換性を確保するために、同様に受け入れられるべきであり、それは0107であったかのように扱われるべきです。
- MED (Multi_EXIT_DISC attribute). By default, this SHOULD be set to the value of the OSPF distance associated with the route, plus 1.
- MED（MULTI_EXIT_DISC属性）。デフォルトでは、このルートに関連付けられたOSPF距離の値、プラス1に設定されるべきです。
The intention of all this is the following. OSPF Routes from one site are converted to BGP, distributed across the VPN backbone, and possibly converted back to OSPF routes before being distributed into another site. With these attributes, BGP carries enough information about the route to enable the route to be converted back into OSPF "transparently", just as if BGP had not been involved.
このすべての意図は以下の通りです。一つのサイトからOSPFルートは、VPNバックボーンに分散し、BGPに変換し、そしておそらく他のサイトに分配される前に、バックOSPFルートに変換されます。これらの属性を使用すると、BGPはBGPが関与していなかったかのように、「透過的」バックOSPFに変換するルートを可能にするために、ルートに関する十分な情報を運びます。
Routes that a PE receives in type 4 LSAs MUST NOT be redistributed to BGP.
PEは、タイプ4 LSAを受信したルートがBGPに再配布してはいけません。
The attributes specified above are in addition to any other attributes that routes must carry in accordance with [VPN].
上記指定された属性は、ルートが[VPN]に従って実行しなければならない他の属性に加えています。
The Site of Origin attribute, which is usually required by [VPN], is OPTIONAL for routes that a PE learns from a CE via OSPF.
通常、[VPN]によって必要とされるorigin属性のサイトは、PEがOSPFを介してCEから学習したルートのオプションです。
Use of the Site of Origin attribute would, in the case of a multiply homed site (i.e., a site attached to several PE routers), prevent an intra-site route from being reinjected into a site from the VPN backbone. Such a reinjection would not harm the routing, because the route via the VPN backbone would be advertised in a type 3 LSA, and hence would appear to be an inter-area route; the real intra-area route would be preferred. But unnecessary overhead would be introduced. On the other hand, if the Site of Origin attribute is not used, a partitioned site will find itself automatically repaired, since traffic from one partition to the other will automatically travel via the VPN backbone. Therefore, the use of a Site of Origin attribute is optional, so that a trade-off can be made between the cost of the increased overhead and the value of automatic partition repair.
origin属性のサイトの使用は、多重ホームサイトの場合には（すなわち、いくつかのPEルータに取り付け部位）は、VPNバックボーンからサイトに再注入されるのサイト内経路を妨げます。 VPNバックボーンを経由する経路がタイプ3 LSAでアドバタイズされるであろう、そしてそれ故にエリア間のルートであるように思われるため、このような再注入は、ルーティングに害を与えないであろう。本当のエリア内ルートが好ましいであろう。しかし、不要なオーバーヘッドが導入されます。起源属性のサイトが使用されていない場合は、1つのパーティションから他方へのトラフィックが自動的にVPNバックボーンを経由して移動するので、一方、分割されたサイトは、自動的に修復自身を見つけるでしょう。トレードオフが増加オーバーヘッドのコストおよび自動パーティション修復の値とすることができるように、したがって、origin属性のサイトの使用は、任意です。
This section describes the protocol and procedures necessary for the support of "Sham Links," as defined herein. Support for sham links is an OPTIONAL feature of this specification.
本明細書で定義されるこのセクションでは、「シャムリンク」をサポートするために必要なプロトコルおよび手順を記載しています。偽リンクのサポートは、この仕様のオプション機能です。
Suppose that there are two sites in the same OSPF area. Each site is attached to a different PE router, and there is also an intra-area OSPF link connecting the two sites.
同じOSPFエリア内の2つのサイトがあると仮定します。各サイトは、異なるPEルータに接続され、2つのサイトを接続するイントラ領域OSPFリンクもあります。
It is possible to treat these two sites as a single VPN site that just happens to be multihomed to the backbone. This is in fact the simplest thing to do and is perfectly adequate, provided that the preferred route between the two sites is via the intra-area OSPF link (a "backdoor link"), rather than via the VPN backbone. There will be routes between sites that go through the PE routers, but these routes will appear to be inter-area routes, and OSPF will consider them less preferable than the intra-area routes through the backdoor link.
ちょうどバックボーンにマルチホームすることを起こる、単一のVPNサイトとしてこれら二つの部位を治療することが可能です。これは、実際に行うための最も簡単なもので、完全に適切である、2つのサイト間の好ましい経路は、エリア内のOSPFリンク（「バックドアリンク」）ではなく、VPNバックボーン経由経由であることを条件とします。そこPEルータを経由するサイト間のルートになりますが、これらの空路はエリア間ルートのように見えるだろう、とOSPFは、バックドアリンクを介して、エリア内ルートよりも彼らはあまり好ましくない検討します。
If it is desired to have OSPF prefer the routes through the backbone over the routes through the backdoor link, then the routes through the backbone must be appear to be intra-area routes. To make a route through the backbone appear to be an intra-area route, it is necessary to make it appear as if there is an intra-area link connecting the two PE routers. This is what we refer to as a "sham link". (If the two sites attach to the same PE router, this is of course not necessary.)
それはOSPFバックドアリンクを介して経路を介してバックボーン経由のルートを好むことが望まれている場合は、バックボーン経由ルートは、エリア内ルートのように見えるしなければなりません。バックボーンを通るルートがエリア内のルートであるように見えるようにするには、2台のPEルータを接続するエリア内のリンクがあるかのように見えるようにする必要があります。これは、私たちが「偽リンク」と呼ぶものです。 （2つのサイトが同じPEルータに接続している場合、これはもちろん必要ありません。）
A sham link can be thought of as a relation between two VRFs. If two VRFs are to be connected by a sham link, each VRF must be associated with a "Sham Link Endpoint Address", a 32-bit IPv4 address that is treated as an address of the PE router containing that VRF. The Sham Link Endpoint Address is an address in the VPN's address space, not the SP's address space. The Sham Link Endpoint Address associated with a VRF MUST be configurable. If the VRF is associated with only a single OSPF instance, and if the PE's router id in that OSPF instance is an IP address, then the Sham Link Endpoint Address MAY default to that Router ID. If a VRF is associated with several OSPF instances, each sham link belongs to a single OSPF instance.
偽リンクは、2つのVRFの間の関係と考えることができます。 2つのVRFが偽リンクによって接続される場合、各VRFは「偽リンクエンドポイントアドレス」、そのVRFを含有するPEルータのアドレスとして扱われる32ビットのIPv4アドレスに関連付けられなければなりません。シャムリンクエンドポイントアドレスは、VPNのアドレス空間ではなく、SPのアドレス空間内のアドレスです。 VRFに関連付けられた模造リンクエンドポイントアドレスは、構成可能でなければなりません。 VRFは、単一のOSPFインスタンスに関連付けられている場合は、そのOSPFインスタンス内のPEのルータIDがIPアドレスであれば、そして、その後、シャムリンクエンドポイントアドレスは、ルータIDをデフォルトにするかもしれません。 VRFは、いくつかのOSPFインスタンスに関連付けられている場合、それぞれのにせのリンクは、単一のOSPFインスタンスに属します。
For a given OSPF instance, a VRF needs only a single Sham Link Endpoint Address, no matter how many sham links it has. The Sham Link Endpoint Address MUST be distributed by BGP as a VPN-IPv4 address whose IPv4 address prefix part is 32 bits long. The Sham Link Endpoint Address MUST NOT be advertised by OSPF; if there is no BGP route to the Sham Link Endpoint Address, that address is to appear unreachable, so that the sham link appears to be down.
与えられたOSPFインスタンスの場合は、VRFは関係なく、それが持っているどのように多くの偽のリンク、一つだけシャムリンクエンドポイント・アドレスを必要としません。シャムリンクエンドポイントアドレスは、そのIPv4アドレス接頭部は32ビット長であり、VPN-IPv4アドレスとしてBGPによって分配されなければなりません。シャムリンクエンドポイントアドレスは、OSPFによってアドバタイズしてはなりません。シャムリンクエンドポイントアドレスへのBGPルートが存在しない場合は偽のリンクがダウンしていると思われるように、そのアドレスは、到達不能表示されるようになります。
Sham links are manually configured.
シャムのリンクが手動で構成されています。
For a sham link to exist between two VRFs, each VRF has to be configured to create a sham link to the other, where the "other" is identified by its sham link endpoint address. No more than one sham link with the same pair of sham link endpoint addresses will ever be created. This specification does not include procedures for single-ended manual configuration of the sham link.
偽のリンクが2つのVRFの間に存在するため、各VRFは、「その他」は、その偽のリンク・エンドポイント・アドレスによって識別される場合、他に偽のリンクを作成するように構成されなければなりません。偽リンクのエンドポイント・アドレスの同じ組とは、複数の偽のリンクは、これまで作成されません。この仕様は、偽のリンクのシングルエンド手動設定するための手順が含まれていません。
Note that sham links may be created for any area, including area 0.
なお、偽のリンクは、エリア0を含め、任意の領域のために作成することができます。
A sham link connecting two VRFs is considered up if and only if a route to the 32-bit remote endpoint address of the sham link has been installed in VRF.
2つのVRFを接続偽リンクがあれば最大とみなされ、偽のリンクの32ビットリモートエンドポイントアドレスへのルートは、VRFにインストールされている場合にのみ。
The sham link endpoint address MUST NOT be used as the endpoint address of an OSPF Virtual Link.
偽リンクエンドポイントアドレスは、OSPF仮想リンクのエンドポイントアドレスとして使用してはいけません。
An OSPF protocol packet sent on a Sham Link from one PE to another must have as its IP source address the Sham Link Endpoint Address of the sender, and as its IP destination address the Sham Link Endpoint Address of the receiver. The packet will travel from one PE router to the other over the VPN backbone, which means that it can be expected to traverse multiple hops. As such, its TTL (Time to Live) field must be set appropriately.
別のPEから模造リンク上で送信されるOSPFプロトコルパケットは、そのIPソースアドレスとして送信者の偽のリンクのエンドポイントアドレスを有し、受信機のそのIP宛先アドレスとして偽リンクエンドポイントアドレスしなければなりません。パケットは、複数のホップを通過することが期待できることを意味し、VPNバックボーンを介して他の1つのPEルータから移動します。そのため、そのTTL（生存時間）フィールドを適切に設定する必要があります。
An OSPF protocol packet is regarded as having been received on a particular sham link if and only if the following three conditions hold:
そして次の3つの条件が成立する場合にのみ場合にOSPFプロトコルパケットは、特定の偽リンク上で受信されたとみなされます。
- The packet arrives as an MPLS packet, and its MPLS label stack causes it to be "delivered" to the local sham link endpoint address.
- パケットがMPLSパケットとして到着し、そのMPLSラベルスタックは、それがローカルの偽リンクエンドポイントアドレスに「配信」されます。
- The packet's IP destination address is the local sham link endpoint address.
- パケットの宛先IPアドレスは、ローカル偽リンクエンドポイントのアドレスです。
- The packet's IP source address is the remote sham link endpoint address.
- パケットのIP送信元アドレスは、リモート偽リンクエンドポイントのアドレスです。
Sham links SHOULD be treated by OSPF as OSPF Demand Circuits. This means that LSAs will be flooded over them, but periodic refresh traffic is avoided. Note that, as long as the backdoor link is up, flooding the LSAs over the sham link serves no purpose. However, if the backdoor link goes down, OSPF does not have mechanisms enabling the routers in one site to rapidly flush the LSAs from the other site. Therefore, it is still necessary to maintain synchronization among the LSA databases at the two sites, hence the flooding over the sham link.
シャムリンクは、OSPFデマンド回線としてOSPFによって扱われるべきです。これは、LSAのは、彼らの上にフラッディングされますが、定期的なリフレッシュトラフィックが回避されることを意味します。限り、バックドアリンクがアップしているように、偽のリンク上のLSAをフラッディングすることは目的を達成しません、ということに注意してください。バックドアリンクがダウンした場合は、OSPFは急速に他のサイトからのLSAをフラッシュする1つのサイト内のルータを有効にするメカニズムを持っていません。したがって、偽のリンク上で氾濫、したがって、まだ2つのサイトのLSAデータベース間の同期を維持するために必要です。
The sham link is an unnumbered point-to-point intra-area link and is advertised as a type 1 link in a type 1 LSA.
偽リンクは無数のポイントツーポイントエリア内のリンクであり、タイプ1 LSAタイプ1リンクとして広告されます。
The OSPF metric associated with a sham link MUST be configurable (and there MUST be a configurable default). Whether traffic between the sites flows via a backdoor link or via the VPN backbone (i.e., via the sham link) depends on the settings of the OSPF link metrics. The metrics can be set so that the backdoor link is not used unless connectivity via the VPN backbone fails, for example.
偽リンクに関連付けられたOSPFメトリックは、構成可能でなければなりません（と設定可能なデフォルトがでなければなりません）。サイト間のトラフィックはバックドアリンクを介して、またはVPNバックボーン（すなわち、偽リンクを介して）を介して流れかどうかは、OSPFリンクメトリックの設定に依存します。 VPNバックボーンを経由して接続が失敗しない限り、バックドアリンクは、たとえば、使用されないように、メトリックを設定することができます。
The default Hello Interval for sham links is 10 seconds, and the default Router Dead Interval for sham links is 40 seconds.
偽リンクのデフォルトのHello間隔は10秒で、偽のリンクのデフォルトルータのデッドインターバルは40秒です。
If a PE determines that the next hop interface for a particular route is a sham link, then the PE SHOULD NOT redistribute that route into BGP as a VPN-IPv4 route.
PEは、特定のルートのネクストホップインターフェイスは、偽のリンクであると判断した場合、その後、PEはVPN-IPv4ルートとしてBGPにそのルートを再配布するべきではありません。
Any other route advertised in an LSA that is transmitted over a sham link MUST also be redistributed (by the PE flooding the LSA over the sham link) into BGP. This means that if the preferred (OSPF) route for a given address prefix has the sham link as its next hop interface, then there will also be a "corresponding BGP route", for that same address prefix, installed in the VRF. Per Section 4.1.2, the OSPF route is preferred. However, when forwarding a packet, if the preferred route for that packet has the sham link as its next hop interface, then the packet MUST be forwarded according to the corresponding BGP route. That is, it will be forwarded as if the corresponding BGP route had been the preferred route. The "corresponding BGP route" is always a VPN-IPv4 route; the procedure for forwarding a packet over a VPN-IPv4 route is described in [VPN].
偽のリンクを介して送信されるLSAでアドバタイズ他の経路もBGPに（偽リンクを介してLSAをフラッディングPEによって）再配布されなければなりません。これは、所与のアドレス・プレフィクスのための好ましい（OSPF）ルートがネクストホップインタフェースとして偽のリンクを有する場合、その後もVRFにインストールされている同一のアドレスプレフィックスの「対応するBGPルート」、が存在するであろうことを意味します。 4.1.2項ごとに、OSPFの経路が好ましいです。パケットを転送する際に、そのパケットのための好ましい経路は、その次のホップインタフェースとして偽のリンクを持っている場合しかし、パケットは、対応するBGPルートに応じて転送されなければなりません。すなわち、対応するBGPルートが好ましい経路であったかのように転送される、です。 「対応するBGPルート」常にVPN-IPv4ルートです。 VPN-IPv4ルートを介してパケットを転送するための手順は、[VPN]に記載されています。
This same rule applies to any packet whose IP destination address is the remote endpoint address of a sham link. Such packets MUST be forwarded according to the corresponding BGP route.
この同じルールは、そのIPアドレス、宛先偽リンクのリモートエンドポイントのアドレスである任意のパケットに適用されます。そのようなパケットは、対応するBGPルートに応じて転送されなければなりません。
This section describes how the PE router handles VPN-IPv4 routes received via BGP.
このセクションでは、PEルータがBGPを介して受信されたVPN-IPv4ルートをどのように処理するかを記述しています。
If a received BGP VPN-IPv4 route is not installed in the VRF, nothing is reported to the CE. A received route will not be installed into the VRF if the BGP decision process regards some other route as preferable. When installed in the VRF, the route appears to be an IPv4 route.
受信BGP VPN-IPv4ルートがVRFにインストールされていない場合は、何もCEに報告されません。 BGP決定プロセスが好ましいようにいくつかの他の経路に関してあれば受信した経路は、VRFにインストールされません。 VRFにインストールすると、ルートは、IPv4ルートのように見えます。
A BGP route installed in the VRF is not necessarily used for forwarding. If an OSPF route for the same IPv4 address prefix has been installed in the VRF, the OSPF route will be used for forwarding, except in the case where the OSPF route's next-hop interface is a sham link.
VRFに設置BGPルートは必ずしも転送に使用されていません。同一のIPv4アドレスプレフィックスのOSPFルートがVRFにインストールされている場合、OSPF経路がOSPFルートのネクストホップインターフェイスは、偽のリンクである場合を除いて、転送に使用されるであろう。
If a BGP route installed in the VRF is used for forwarding, then the BGP route is redistributed into OSPF and possibly reported to the CEs in an OSPF LSA. The sort of LSA, if any, to be generated depends on various characteristics of the BGP route, as detailed in subsequent sections of this document.
VRFに設置BGPルートが転送に使用される場合、BGPルートをOSPFに再配布され、おそらくOSPF LSAにCEに報告しました。生成されるLSAの種類、存在する場合は、この文書の以降のセクションで詳述するように、BGPルートの様々な特性に依存します。
The procedure for forwarding a packet over a VPN-IPv4 route is described in [VPN].
VPN-IPv4ルートを介してパケットを転送するための手順は、[VPN]に記載されています。
In the following, we specify what is reported, in OSPF LSAs, by the PE to the CE, assuming that the PE is not configured to do any further summarization or filtering of the routing information before reporting it to the CE.
以下では、PEがCEにそれを報告する前に、ルーティング情報の任意のさらなる集約やフィルタリングを行うように構成されていないと仮定して、CEへのPEにより、OSPFのLSAには、報告されているものを指定します。
When sending an LSA to the CE, it may be necessary to set the DN bit. See Section 4.2.5.1 for the rules regarding the DN bit.
CEにLSAを送信する場合、DNビットを設定する必要があるかもしれません。 DNビットに関する規則については、セクション4.2.5.1を参照してください。
When sending an LSA to the CE, it may be necessary to set the OSPF Route Tag. See Section 4.2.5.2 for the rules about setting the OSPF Route Tag.
CEへのLSAを送信するとき、OSPFルートタグを設定する必要があるかもしれません。 OSPFルートタグの設定についての規則については、セクション4.2.5.2を参照してください。
When type 5 LSAs are sent, the Forwarding Address is set to 0.
タイプ5のLSAが送信されると、転送先アドレスは0に設定されています。
With respect to a particular OSPF instance associated with a VRF, a VPN-IPv4 route that is installed in the VRF and then selected as the preferred route is treated as an External Route if one of the following conditions holds:
次のいずれかの条件が成立する場合にVRFに関連付けられた特定のOSPFインスタンスに対して、VRF内に設置し、次いで、好ましい経路として選択されたVPN-IPv4ルートは、外部ルートとして扱われます。
- The route type field of the OSPF Route Type Extended Community has an OSPF route type of "external".
- OSPFルートタイプ拡張コミュニティのルートタイプフィールドは、「外部」のOSPFルートのタイプがあります。
- The route is from a different domain from the domain of the OSPF instance.
- ルートはOSPFインスタンスのドメインとは異なるドメインからのものです。
The rules for determining whether a route is from a domain different from that of a particular OSPF instance are the following. The OSPF Domain Identifier Extended Communities attribute carried by the route is compared with the OSPF Domain Identifier Extended Communities attribute(s) with which the OSPF instance has been configured (if any). In general, when two such attributes are compared, all eight bytes must be compared. Thus, two OSPF Domain Identifier Extended Communities attributes are regarded as equal if and only if one of the following three conditions holds:
ルートが特定のOSPFインスタンスとは異なるドメインからのものであるかどうかを決定するためのルールは以下の通りです。経路によって運ばれる属性OSPFドメイン識別子拡張コミュニティは、OSPFドメイン識別子は、OSPFインスタンスは（もしあれば）が設定されているとコミュニティ属性（複数可）拡張と比較されます。二つのそのような属性を比較する場合、一般的に、全8つのバイトを比較しなければなりません。以下の3つの条件のいずれかが成立する場合にのみ場合したがって、2つのOSPFドメイン識別子拡張コミュニティ属性が等しいとみなされます。
2. They are identical in their lower-order six bytes (value field), but one attribute has two high-order bytes (type field) of 0005 and the other has two high-order bytes (type field) of 8005. (This condition is for backward compatibility.)
2.この（これらは、それらの下位6バイト（値フィールド）に同一であるが、一つの属性は、0005の上位2バイト（タイプフィールド）を有し、他方が8005の上位2バイト（タイプフィールド）を有します条件は、下位互換性のためです。）
3. The lower-order six bytes (value field) of both attributes consist entirely of zeroes. In this case, the two attributes are considered identical irrespective of their type fields, and they are regarded as representing the NULL Domain Identifier.
3.両方の属性の下位6バイト（値フィールド）がゼロの完全に構成されています。この場合、2つの属性に関係なく、それらのタイプのフィールドの同一とみなされ、それらはNULLドメイン識別子を表すとみなされます。
If a VPN-IPv4 route has an OSPF Domain Identifier Extended Communities attribute, we say that that route is in the identified domain. If the value field of the Extended Communities attribute consists of all zeroes, then the identified domain is the NULL domain, and the route is said to belong to the NULL domain. If the route does not have an OSPF Domain Identified Extended Communities attribute, then the route belongs to the NULL domain.
VPN-IPv4ルートがOSPFドメイン識別子拡張コミュニティ属性を持っている場合、我々はそのルートが特定のドメインにあることを言います。拡張コミュニティ属性の値フィールドがすべてゼロで構成されている場合は、その後、識別されたドメインは、NULLドメインであり、ルートはNULLドメインに属していると言われています。ルートがOSPFドメイン同定された拡張コミュニティ属性を持っていない場合は、ルートはNULLドメインに属しています。
Every OSPF instance is associated with one or more Domain Identifiers, though possibly only with the NULL domain identifier. If an OSPF instance is associated with a particular Domain Identifier, we will say that it belongs to the identified domain.
すべてのOSPFインスタンスは、おそらく唯一のNULLのドメイン識別子を持つものの、一つ以上のドメイン識別子に関連付けられています。 OSPFインスタンスは、特定のドメイン識別子に関連付けられている場合、我々はそれが識別されたドメインに属していることを言うだろう。
If a VPN-IPv4 route is to be redistributed to a particular instance, it must be determined whether that route and that OSPF instance belong to the same domain. A route and an OSPF instance belong to the same domain if and only if one of the following conditions holds:
VPN-IPv4ルートが特定のインスタンスに再配布する場合、そのルートかどうか、およびOSPFインスタンスが同じドメインに属していると判定されなければなりません。そして次のいずれかの条件が成立する場合だけルートとOSPFインスタンスが同じドメインに属しています：
2. The domain to which the route belongs is the domain to which the OSPF instance belongs. (That is, the route's Domain Identifier is equal to the OSPF instance's domain identifier, as determined by the definitions given earlier in this section.)
2.ルートが属するドメインは、OSPFインスタンスが属するドメインです。 （すなわち、前述のセクションで与えられた定義によって決定されるようなルートのドメイン識別子は、OSPFインスタンスのドメイン識別子と同じです。）
If the route and the VRF do not belong to the same domain, the route is treated as an external route.
ルートおよびVRFが同じドメインに属していない場合は、ルートが外部ルートとして扱われます。
If an external route is redistributed into an OSPF instance, the route may or may not be advertised to a particular CE, depending on the configuration and on the type of area to which the PE/CE link belongs. If the route is advertised, and the PE/CE link belongs to a NSSA area, it is advertised in a type 7 LSA. Otherwise, if the route is advertised, it is advertised in a type 5 LSA. The LSA will be originated by the PE.
外部ルートは、OSPFインスタンスに再配布されている場合、ルートは、又は構成及びPE / CEリンクが所属するエリアの種類に応じて、特定のCEに通知してもしなくてもよいです。ルートをアドバタイズし、PE / CEリンクがNSSAエリアに属している場合、それは、タイプ7 LSAでアドバタイズされます。ルートがアドバタイズされる場合はそうでなければ、それはタイプ5 LSAでアドバタイズされます。 LSAはPEによって発信されるであろう。
The DN bit (Section 4.2.5.1) MUST be set in the LSA. The VPN Route Tag (see Section 4.2.5.2) MUST be placed in the LSA, unless the use of the VPN Route Tag has been turned off by configuration.
DNビット（セクション4.2.5.1）は、LSAに設定しなければなりません。 VPNルートタグの使用は、構成によってオフにされていない限り、VPNルートタグは、（セクション4.2.5.2を参照）、LSAに配置する必要があります。
By default, a type 2 metric value is included in the LSA, unless the options field of the OSPF Route Type Extended Communities attribute of the VPN-IPv4 route specifies that the metric should be type 1.
VPN-IPv4ルートのOSPFルートタイプ拡張コミュニティ属性のオプションフィールドは、メトリックがタイプ1であることを指定しない限り、デフォルトでは、タイプ2メトリック値は、LSAに含まれています。
By default, the value of the metric is taken from the MED attribute of the VPN-IPv4 route. If the MED is not present, a default metric value is used. (The default type 1 metric and the default type 2 metric MAY be different.)
デフォルトでは、メトリックの値は、VPN-IPv4ルートのMED属性から取得されます。 MEDが存在しない場合、デフォルトのメトリック値が使用されます。 （デフォルトのタイプ1メトリックとデフォルトタイプ2メトリックは異なっていてもよいです。）
Note that this way of handling external routes makes every PE appear to be an ASBR attached to all the external routes. In a multihomed site, this can result in a number of type 5 LSAs containing the same information.
外部ルートを処理するこの方法は、すべてのPEは、すべての外部ルートに添付ASBRように見えることに注意してください。マルチホームサイトでは、これは、同じ情報を含むタイプ5 LSAの数をもたらすことができます。
If a route and the VRF into which it is imported belong to the same domain, then the route should be treated as if it had been received in an OSPF type 3 LSA. This means that the PE will report the route in a type 3 LSA to the CE. (Note that this case is possible even if the VPN-IPv4 route carries an area number identical to that of the CE router. This means that if an area is "partitioned" such that the two pieces are connected only via the VPN backbone, it appears to be two areas, with inter-area routes between them.)
それがインポートされた内経路およびVRFが同じドメインに属している場合、それはOSPFタイプ3 LSAで受信されたかのように、次に経路は、治療されるべきです。これは、PEは、CEにタイプ3 LSAで経路を報告することを意味します。 （この場合は、VPN-IPv4ルートが、これはもし領域は二枚のみVPNバックボーンを介して接続されているように、「分配」されることを意味する。それをCEルータと同一のエリア番号を搬送する場合であっても可能であることに注意してくださいそれらの間のエリア間ルートで、二つの領域であるように思われます。）
NSSA routes are treated the same as external routes, as described in Section 4.2.8.1.
セクション4.2.8.1に記載されるようにNSSAルートは、外部ルートと同じように扱われます。
Section 11 of [EXTCOMM] calls upon IANA to create a registry for BGP Extended Communities Type Field and Extended Type Field values. Section 4.2.6 of this document assigns new values for the BGP Extended Communities Extended Type Field. These values all fall within the range of values that [EXTCOMM] states "are to be assigned by IANA, using the 'First Come, First Served' policy defined in RFC 2434".
BGPのレジストリを作成するために、IANAに呼びかけ[EXTCOMM]のセクション11は、コミュニティタイプフィールドと拡張型フィールドの値を拡張しました。このドキュメントのセクション4.2.6には、タイプフィールド拡張BGP拡張コミュニティのための新しい値を割り当てます。これらの値は[EXTCOMM]状態は、「RFC 2434で定義された 『第一に、是非、まず配信』ポリシーを使用して、IANAによって割り当てられることになっている」値の範囲内にあるすべての秋。
The BGP Extended Communities Extended Type Field values assigned in Section 4.2.6 of this document are as follows:
次のようにこのドキュメントのセクション4.2.6に割り当てられたタイプフィールドの値を拡張BGP拡張コミュニティは、次のとおりです。
- OSPF Domain Identifier: Extended Types 0005, 0105, and 0205.
- OSPFドメイン識別子：拡張タイプ0005、0105、および0205。
- OSPF Route Type: Extended Type 0306
- OSPFルートの種類：拡張型0306
- OSPF Router ID: Extended Type 0107
- OSPFルータID：拡張タイプ0107
Security considerations that are relevant in general to BGP/MPLS IP VPNS are discussed in [VPN] and [VPN-AS]. We discuss here only those security considerations that are specific to the use of OSPF as the PE/CE protocol.
BGP / MPLS IP VPNに一般に関連するセキュリティ上の考慮事項は、[VPN]と[VPN-AS]で議論されています。ここではPE / CEプロトコルとしてOSPFの使用に固有のもののみ、セキュリティ上の考慮事項について説明します。
A single PE may be running OSPF as the IGP of the SP backbone network, as well as running OSPF as the IGP of one or more VPNs. This requires the use of multiple, independent OSPF instances, so that routes are not inadvertently leaked between the backbone and any VPN. The OSPF instances for different VPNs must also be independent OSPF instances, to prevent inadvertent leaking of routes between VPNs.
単一のPEは、SPバックボーンネットワークのIGPとしてOSPFを実行し、ならびに1つのまたは複数のVPNのIGPとしてOSPFを実行してもよいです。ルートは不注意バックボーンおよび任意のVPN間で漏洩しないようにこれは、複数の独立したOSPFインスタンスを使用する必要があります。異なるVPNのためのOSPFインスタンスはまた、VPN間の経路の不用意な漏れを防止するために、独立したOSPFインスタンスでなければなりません。
OSPF provides a number of procedures that allow the OSPF control messages between a PE and a CE to be authenticated. OSPF "cryptographic authentication" SHOULD be used between a PE and a CE. It MUST be implemented on each PE.
OSPFは、PEとCEの間のOSPF制御メッセージが認証されることを可能にする手順の数を提供します。 OSPFは、「暗号化認証」PEとCEの間で使用されるべきです。これは、各PE上に実装されなければなりません。
In the absence of such authentication, it is possible that the CE might not really belong to the VPN to which the PE assigns it. It may also be possible for an attacker to insert spoofed messages on the PE/CE link, in either direction. Spoofed messages sent to the CE could compromise the routing at the CE's site. Spoofed messages sent to the PE could result in improper VPN routing, or in a denial-of-service attack on the VPN.
そのような認証がない場合には、CEが本当にPEがそれを割り当て先のVPNに属さない可能性があります。攻撃者がいずれかの方向に、PE / CEリンク上で偽装されたメッセージを挿入することも可能です。 CEに送信された偽装されたメッセージは、CEのサイトでルーティングを危険にさらす可能性が。 PEに送信された偽装されたメッセージは、不適切なVPNルーティングで、またはVPN上のサービス拒否攻撃につながる可能性があります。
Major contributions to this work have been made by Derek Yeung and Yakov Rekhter.
この作品への主要な貢献は、デレク・ヨンとヤコフ・レックターによって行われています。
Thanks to Ross Callon, Ajay Singhal, Russ Housley, and Alex Zinin for their review and comments.
彼らのレビューとコメントのためのロスCallon、アジャイシングハル、ラスHousley、およびアレックスジニンに感謝します。
[EXTCOMM] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.
[EXTCOMM]サングリ、S.、タッパン、D.、およびY. Rekhterは、2006年2月、RFC 4360 "BGPはコミュニティ属性を拡張しました"。
[OSPFv2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
【のOSPFv2]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[OSPF-DN] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4576, June 2006.
[OSPF-DN]ローゼン、E.、Psenak、P.、およびP. Pillay-Esnault、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）でループを防止するためにリンクステートアドバタイズメント（LSA）オプションビットを使用する"、RFC 4576、2006年6月。
[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月。
[VPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[VPN]ローゼン、E.およびY. Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）"、RFC 4364、2006年2月。
[BGP] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[BGP] Rekhter、Y.、李、T.、およびS.野兎、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 4271、2006年1月。
[RIP] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[RIP]マルキン、G.、 "RIPバージョン2"、STD 56、RFC 2453、1998年11月。
[VPN-AS] Rosen, E., "Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4365, February 2006.
[VPN-AS]ローゼン、E.、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）のための適用性に関する声明"、RFC 4365、2006年2月。
Authors' Addresses
著者のアドレス
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
エリックC.ローゼンシスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA 01719
EMail: erosen@cisco.com
メールアドレス：erosen@cisco.com
Peter Psenak Cisco Systems BA Business Center, 9th Floor Plynarenska 1 Bratislava 82109 Slovakia
ピーターPsenakシスコシステムズBAビジネスセンター、9階のPlynarenska 1ブラチスラバ82109スロバキア
EMail: ppsenak@cisco.com
メールアドレス：ppsenak@cisco.com
Padma Pillay-Esnault Cisco Systems 3750 Cisco Way San Jose, CA 95134
パドマPillay-Esnaultシスコシステムズ3750のCiscoウェイサンノゼ、CA 95134
EMail: ppe@cisco.com
メールアドレス：ppe@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
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 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が表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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に情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。