Network Working Group A. Zinin
Request for Comments: 3509 Alcatel
Category: Informational A. Lindem
Redback Networks
D. Yeung
Procket Networks
April 2003
Alternative Implementations of OSPF Area Border Routers
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
Open Shortest Path First (OSPF) is a link-state intra-domain routing protocol used for routing in IP networks. Though the definition of the Area Border Router (ABR) in the OSPF specification does not require a router with multiple attached areas to have a backbone connection, it is actually necessary to provide successful routing to the inter-area and external destinations. If this requirement is not met, all traffic destined for the areas not connected to such an ABR or out of the OSPF domain, is dropped. This document describes alternative ABR behaviors implemented in Cisco and IBM routers.
オープンショーテストパスファースト（OSPF）IPネットワークにおけるルーティングのために使用されるリンクステートドメイン内ルーティングプロトコルです。 OSPF仕様のエリア境界ルータ（ABR）の定義は、バックボーン接続を持つように、複数の接続されたエリアでルータを必要としませんが、エリア間および外部の宛先に成功したルーティングを提供するために、実際には必要です。この要件が満たされていない場合は、そのようなABRまたはOSPFドメインの外に接続されていない領域宛てのすべてのトラフィックは、廃棄されます。このドキュメントでは、CiscoとIBMルータに実装され、代替ABRの動作を説明します。
1 Overview
1。概要
An OSPF routing domain can be split into several subdomains, called areas, which limit the scope of LSA flooding. According to [Ref1] a router having attachments to multiple areas is called an "area border router" (ABR). The primary function of an ABR is to provide its attached areas with Type-3 and Type-4 LSAs, which are used for describing routes and AS boundary routers (ASBRs) in other areas, as well as to perform actual inter-area routing.
OSPFルーティングドメインは、LSAフラッディングの範囲を制限するいくつかのサブドメインと呼ばれる領域に分割することができます。 [Ref1の]によれば、複数の領域に添付ファイルを有するルータは、「エリア境界ルータ」（ABR）と呼ばれています。 ABRの主な機能は、タイプ3との取り付け領域を提供し、タイプ4の他の領域内のルートを記述するために使用されたLSA、およびAS境界ルータ（のASBR）を、ならびに実際のエリア間ルーティングを実行することです。
In OSPF domains the area topology is restricted so that there must be a backbone area (area 0) and all other areas must have either physical or virtual connections to the backbone. The reason for this star-like topology is that OSPF inter-area routing uses the distance-vector approach and a strict area hierarchy permits avoidance of the "counting to infinity" problem. OSPF prevents inter-area routing loops by implementing a split-horizon mechanism, allowing ABRs to inject into the backbone only Summary-LSAs derived from the intra-area routes, and limiting ABRs' SPF calculation to consider only Summary-LSAs in the backbone area's link-state database.
OSPFではそこバックボーンエリア（エリア0）でなければならず、他のすべてのエリアがバックボーンに物理的または仮想接続のどちらかを持っている必要がありますように、地域のトポロジが制限されているドメイン。この星状トポロジーの理由は、OSPFエリア間のルーティングは、距離ベクトル・アプローチを使用して、厳密な領域階層が「カウント無限に」問題の回避を可能にすることです。 OSPFは、スプリットホライズンメカニズムを実装するのABRがバックボーンにイントラ領域ルートに由来するのみ要約-LSAを注入することができ、およびバックボーンエリアの中で唯一の概要-LSAを考慮するのABR SPF計算を制限することにより、エリア間ルーティングのループを防ぎますリンクステートデータベース。
The last restriction leads to a problem when an ABR has no backbone connection (in OSPF, an ABR does not need to be attached to the backbone). Consider a sample OSPF domain depicted in the Figure 1.
最後の制限はABRが全くバックボーン接続を持っていないという問題があった（OSPFに、ABRは、バックボーンに接続する必要はありません）。図1に示すサンプルOSPFドメインを考えます。
. .
. Area 0 .
+--+ +--+
..|R1|.. ..|R2|..
. +--+ .. +--+ .
. .. .
. +--+ .
. Area1 |R3| Area2 .
. +--+ +--+ .
. .. |R4| .
. . . +--+ .
....... .......
Figure 1. ABR dropping transit traffic
図1. ABRはトランジットトラフィックをドロップ
In this example R1, R2, and R3 are ABRs. R1 and R2 have backbone connections, while R3 doesn't.
この例では、R1、R2、及びR3はのABRです。 R3はそうではないR1とR2は、バックボーン接続を持っています。
Following the section 12.4.1 of [Ref1], R3 will identify itself as an
ABR by setting the bit B in its router-LSA. Being an ABR, R3 can
only consider summary-LSAs from the backbone when building the
routing table (according to section 16.2 of [Ref1]), so it will not
have any inter-area routes in its routing table, but only intra-area
routes from both Area 1 and Area 2. Consequently, according to
section 12.4.3 of [Ref1], R3 will originate into Areas 1 and 2 only
summary-LSAs covering destinations in the directly attached areas,
i.e., in Area 2---the summary-LSAs for Area 1, and in Area 1---the
summary-LSAs for Area 2.
At the same time, router R2, as an ABR connected to the backbone, will inject into Area 2 summary-LSAs describing the destinations in Area 0 (the backbone), Area 1 and other areas reachable through the backbone.
これと同時に、ルータR2は、バックボーンに接続されたABRのように、エリアにエリア0（バックボーン）、領域1とバックボーンを介して到達可能な他の分野での宛先を記述する2要約LSAを注入します。
This results in a situation where internal router R4 calculates its
routes to destinations in the backbone and areas other than Area 1
via R2. The topology of Area 2 itself can be such that the best path
from R4 to R2 is via R3, so all traffic destined for the backbone and
backbone-attached areas goes through R3. Router R3 in turn, having
only intra-area routes for areas 1 and 2, will drop all traffic not
destined for the areas directly attached to it. The same problem can
occur when a backbone-connected ABR loses all of its adjacencies in
the backbone---even if there are other normally functioning ABRs in
the attached areas, all traffic going to the backbone (destined for
it or for other areas) will be dropped.
In a standard OSPF implementation this situation can be remedied by use of Virtual Links (see section 15 of [Ref1] for more details). In this case, router R3 will have a virtual backbone connection, will form an adjacency over it, will receive all LSAs directly from a backbone-attached router (R1 or R2, or both in our example) and will install intra- or inter-area routes.
標準のOSPFの実装では、このような状況は、仮想リンク（詳細は[Ref1の]のセクション15を参照）を使用することによって改善することができます。この場合には、ルータR3は、その上に隣接関係を形成するバックボーン接続ルータ（R1又はR2、又はこの例では双方）から直接、すべてのLSAを受信すると細胞内又は細胞相互インストールされ、仮想バックボーン接続を有するであろうエリアルート。
While being an unavoidable technique for repairing a partitioned backbone area, the use of virtual links in the described situation adds extra configuration headaches and system traffic overhead.
分割されたバックボーンエリアを修復するための避けられない技術であるが、説明した状況にある仮想リンクを使用すると、追加の構成頭痛やシステムトラフィックのオーバーヘッドが追加されます。
Another situation where standard ABR behavior does not provide acceptable results is when it is necessary to provide redundant connectivity to an ASBR via several different OSPF areas. This would allow a provider to aggregate all their customers connecting through a single access point into one area while still offering a redundant connection through another access point in a different area, as shown in Figure 2.
いくつかの異なるOSPFエリアを経由してASBRへの冗長接続を提供する必要がある場合に、標準のABRの動作が許容できる結果を提供していない別の状況があります。これは、プロバイダは、図2に示すように、まだ、別の領域に別のアクセスポイントを介して冗長接続を提供しながら、一つの領域に単一のアクセスポイントを介して接続するすべての顧客を集約することを可能にします。
. .
. Area 0 .
+--+ +--+
..|R1|.. ..|R2|..
. +--+ .. +--+ .
. .. .
. .. .
. Area1 .. Area2 .
. .. .
. .. .
. +--+ .
.......|R3|.......
ASBR+--+
/..\
--+- -+--
CN1 CNx
Customer Networks (CN1--CNx) Advertised as AS External or NSSA External Routes
顧客ネットワーク（CN1 - CNX）などの外部またはNSSA外部ルートとしてアドバタイズ
Figure 2. Dual Homed Customer Router
図2.デュアルホームカスタマー・ルータ
This technique is already used in a number of networks including one of a major provider.
この技術は、すでに主要なプロバイダのいずれかを含むネットワークの数に使用されています。
The next section describes alternative ABR behaviors, implemented in Cisco and IBM routers. The changes are in the ABR definition and inter-area route calculation. Any other parts of standard OSPF are not changed.
次の項では、CiscoとIBMルータに実装され、代替ABRの動作を、説明しています。変更は、ABRの定義とエリア間経路計算です。標準OSPFの任意の他の部分は変更されません。
These solutions are targeted to the situation when an ABR has no
backbone connection. They imply that a router connected to multiple
areas without a backbone connection is not an ABR and should function
as a router internal to every attached area. This solution emulates
a situation where separate OSPF processes are run for each area and
supply routes to the routing table. It remedies the situation
described in the examples above by not dropping transit traffic.
Note that a router following it does not function as a real border
router---it doesn't originate summary-LSAs. Nevertheless such a
behavior may be desirable in certain situations.
Note that the proposed solutions do not obviate the need of virtual link configuration in case an area has no physical backbone connection at all. The methods described here improve the behavior of a router connecting two or more backbone-attached areas.
エリアは全く物理的なバックボーン接続を持っていない場合には提案されたソリューションは、仮想リンクの設定の必要性を除去しないことに注意してください。ここで説明する方法は二つ以上のバックボーン接続されたエリアを接続するルータの動作を改善します。
2 Changes to ABR Behavior
ABRの動作に2つの変更点
The following definitions will be used in this document to describe the new ABR behaviors:
以下の定義は、新たなABRの振る舞いを記述するために、このドキュメントで使用されます。
Configured area: An area is considered configured if the router has at least one interface in any state assigned to that area.
構成エリア：ルータはその領域に割り当てられている状態で、少なくとも1つのインタフェースを有する場合に領域が設定考えられます。
Actively Attached area: An area is considered actively attached if the router has at least one interface in that area in the state other than Down.
積極的に地域を添付：ルータがダウン以外の状態では、その領域内の少なくとも1つのインタフェースを持っている場合の領域を積極的に取り付けたと考えられています。
Active Backbone Connection: A router is considered to have an active backbone connection if the backbone area is actively attached and there is at least one fully adjacent neighbor in it.
アクティブなバックボーン接続は：バックボーンエリアを積極的に取り付けられており、その中に少なくとも1つの完全に隣接するネイバーが存在している場合、ルータは、アクティブなバックボーン接続を持っていると考えられています。
Area Border Router (ABR):
エリア境界ルータ（ABR）：
Cisco Systems Interpretation: A router is considered to be an ABR if it has more than one area Actively Attached and one of them is the backbone area.
シスコシステムズ解釈：それは複数のエリア積極的に付属しており、そのうちの一つは、バックボーンエリアであればルータがABRであると考えられています。
IBM Interpretation: A router is considered to be an ABR if it has more than one Actively Attached area and the backbone area Configured.
IBMの解釈：ルータは、それが複数の積極添付エリアとバックボーンエリア設定されている場合ABRであると考えられています。
The following changes are made to the base OSPF, described in [Ref1]:
以下の変更は、[Ref1の]に記載のベースOSPF、に対して行われます。
1. The algorithm for Type 1 LSA (router-LSA) origination is changed to prevent a multi-area connected router from identifying itself as an ABR by the bit B (as described in section 12.4.1 of [Ref1]) until it considers itself as an ABR according to the definitions given in section 2.1.
1. 1 LSAのためのアルゴリズムは、（ルータLSA）発信は、それが考慮されるまで（[Ref1の]のセクション12.4.1に記載されているように）ビットBによってABRとして自身を特定のルータを接続するマルチエリアを防ぐために変更されますセクション2.1で与えられた定義に従ってABRとして自体。
2. The algorithm for the routing table calculation is changed to allow the router to consider the summary-LSAs from all attached areas if it is not an ABR, but has more than one attached area, or it does not have an Active Backbone Connection. Definitions of the terms used in this paragraph are given in section 2.1.
2.ルーティングテーブルの計算のためのアルゴリズムは、それがABRではなく、複数の接続面積を有しているか、それがアクティブなバックボーン接続を持っていない場合、すべての接続されたエリアから要約LSAを検討するためにルータを許可するように変更されます。この段落で使用される用語の定義は、セクション2.1に記載されています。
So, the paragraph 1 of section 16.2 of [Ref1] should be
interpreted as follows:
"The inter-area routes are calculated by examining summary-LSAs. If the router is an ABR and has an Active Backbone Connection, only backbone summary-LSAs are examined. Otherwise (either the router is not an ABR or it has no Active Backbone Connection), the router should consider summary-LSAs from all Actively Attached areas..."
「エリア間のルートが要約LSAを調べることによって計算されます。ルータがABRであり、唯一のバックボーン要約LSAが検討されているアクティブなバックボーン接続を持っています。そうでない場合（どちらかのルータがABRではないか、それがアクティブなバックボーンを持っていない場合接続）、ルータはすべて積極的に接続されたエリアから要約LSAを検討すべきです...」
3. For Cisco ABR approach, the algorithm for the summary-LSAs origination is changed to prevent loops of summary-LSAs in situations where the router considers itself an ABR but doesn't have an Active Backbone Connection (and, consequently, examines summaries from all attached areas). The algorithm is changed to allow an ABR to announce only intra-area routes in such a situation.
シスコABRのアプローチについて、要約LSAの発信のためのアルゴリズムは、ルータが自身ABRと考える状況で要約LSAのループを防ぐために3に変更されていても、Activeバックボーン接続を持っている（と、その結果として、より要約を調べていません接続されたすべての領域）。アルゴリズムはこのような状況でのみイントラ領域ルートを発表するABRを可能にするように変更されます。
So, the paragraph 2 of subsection 12.4.3 of [Ref1] should be
interpreted as follows:
"Summary-LSAs are originated by area border routers. The precise summary routes to advertise into an area are determined by examining the routing table structure (see Section 11) in accordance with the algorithm described below. Note that while only intra-area routes are advertised into the backbone, if the router has an Active Backbone Connection, both intra-area and inter-area routes are advertised into the other areas; otherwise, the router only advertises intra-area routes into non-backbone areas."
「概要-LSAはエリア境界ルータによって発信される。正確なサマリールートエリアにアドバタイズするように、以下に説明するアルゴリズムに従った（セクション11を参照）、ルーティングテーブルの構造を調べることによって決定される。のみエリア内のルートがあるがなおルータがアクティブなバックボーン接続を持ち、両方のエリア内とエリア間ルートが他のエリアにアドバタイズされている場合は、バックボーンにアドバタイズ、そうでない場合、ルータは唯一の非バックボーンエリアにエリア内のルートをアドバタイズ「。
For this policy to be applied we change steps 6 and 7 in the summary origination algorithm to be as follows:
我々は要約発信アルゴリズムの手順6と7を変更するには、このポリシーが適用されるようにするには、次のように：
Step 6:
ステップ6：
"Else, if the destination of this route is an AS boundary router, a summary-LSA should be originated if and only if the routing table entry describes the preferred path to the AS boundary router (see Step 3 of Section 16.4). If so, a Type 4 summary-LSA is originated for the destination, with Link State ID equal to the AS boundary router's Router ID and metric equal to the routing table entry's cost. If the ABR performing this algorithm does not have an Active Backbone Connection, it can originate Type 4 summary-LSA only if the type of the route to the ASBR is intra-area. Note: Type 4 summary-LSAs should not be generated if Area A has been configured as a stub area."
このルートの目的地がAS境界ルータである場合は、ルーティングテーブルエントリがAS境界ルータへの優先パスを記述している場合のみと（セクション16.4のステップ3を参照）が「そうでなければ、要約-LSAを発信しなければならない。そうであれば、タイプ4要約LSAはAS境界ルータのルータIDに等しいとルーティングテーブルのエントリのコストに等しいメトリックリンクステートIDと目的地のために発信される。このアルゴリズムを実行するABRは、アクティブなバックボーン接続を持っていない場合は、 ASBRへのルートのタイプがイントラ領域である場合にのみ、タイプ4要約LSAを発信することができます：領域Aは、スタブ領域として構成されている場合、タイプ4要約LSAは生成されるべきではありません「。
Step 7:
ステップ7：
"Else, the Destination type is network. If this is an inter-area route and the ABR performing this algorithm has an Active Backbone Connection, generate a Type 3 summary-LSA for the destination, with Link State ID equal to the network's address (if necessary, the Link State ID can also have one or more of the network's host bits set; see Appendix E for details) and metric equal to the routing table cost."
「そうでなければ、宛先タイプがネットワークである。これは、エリア間のルートで、ABRは、このアルゴリズムを実行すると、アクティブなバックボーン接続を持っている場合は、宛先のタイプ3要約LSAを生成し、ネットワークのアドレスと同じリンクステートID（と必要に応じて、リンクステートIDも設定されたネットワークのホストビットの1つ以上を有することができます。詳細については、付録Eを参照）、ルーティングテーブル・コストに等しいメトリック「。
The changes in the ABR behavior described in this section allow a multi-area connected router to successfully route traffic destined for the backbone and other areas. Note that if the router does not have a backbone area Configured it does not actively attract inter-area traffic, because it does not consider itself an ABR and does not originate summary-LSAs. It still can forward traffic from one attached area to another along intra-area routes in case other routers in corresponding areas have the best inter-area paths over it, as described in section 1.2.
このセクションで説明ABR行動の変化は、マルチエリアがバックボーンと他のエリアに宛て成功裏でトラフィックをルーティングするルータを接続することができます。ルータがバックボーンエリアが設定されていない場合、それは自分自身ABR考慮していないと要約LSAを発信しないので、それは積極的に、エリア間のトラフィックを誘致しないことに注意してください。セクション1.2で説明したように対応する領域に他のルータは、その上に最高のエリア間経路を有する場合には、それはまだエリア内のルートに沿って別の取り付け領域からのトラフィックを転送することができます。
By processing all summaries when the backbone is not active, we prevent the ABR, which has just lost its last backbone adjacency, from dropping any packets going through the ABR in question to another ABR and destined towards the backbone or other areas not connected to the ABR directly.
バックボーンがアクティブでないとき、すべての要約を処理することにより、私達はちょうどに接続されていない別のABRに質問にABRを通過するすべてのパケットをドロップするから、その最後のバックボーン隣接関係を失い、背骨やその他の地域の方に宛てたABRを防ぎます直接ABR。
3 Virtual Link Treatment
3仮想リンクの治療
The Cisco ABR approach described in this document requires an ABR to have at least one active interface in the backbone area. This requirement may cause problems with virtual links in those rare situations where the backbone area is purely virtual, as shown in Figure 3, and the state of the VL is determined as in [Ref1].
この文書で説明するシスコABRのアプローチは、バックボーンエリア内の少なくとも1つのアクティブなインターフェイスを持つようにABRが必要です。この要件は、図3に示され、及びVLの状態は[Ref1の]のように決定されるバックボーンエリアは、純粋に仮想的であるそれらのまれな状況では、仮想リンクの問題を引き起こす可能性があります。
....... ........... ......
. . . .
+--+ VL +--+
|R1|***********|R2|
+--+ +--+
Area 1 . . Area 2 . . Area 3
....... ........... ......
Figure 3. Purely Virtual Backbone
図3.純粋仮想バックボーン
If R1 and R2 treat virtual links as in [Ref1], their virtual links will never go up, because their router-LSAs do not contain the B-bit, which is, in turn, because the routers do not have active interfaces (virtual links) in the backbone and do not consider themselves ABRs.
R1とR2は[Ref1の]のように仮想リンクを扱う場合は、そのルータのLSAはターンでは、Bビットを、含まれていないため、ルータがアクティブなインターフェイスを持っていないので、その仮想リンクは、仮想（、、上がることはありませんリンク）バックボーン、それ自体のABR考慮していません。
Note that this problem does not appear if one of the routers has a real interface in the backbone, as it usually is in real networks.
それは通常、実際のネットワークにあるようルータの1つは、主鎖中に本当のインターフェースを持っている場合、この問題が表示されないことに注意してください。
Though the situation described is deemed to be rather rare, implementations supporting Cisco ABR behavior may consider changing VL-specific code so that a virtual link is reported up (an InterfaceUp event is generated) when a router with corresponding router-ID is seen via Dijkstra, no matter whether its router-LSA indicates that it is an ABR or not. This means that checking of configured virtual links should be done not in step 4 of the algorithm in 16.1 of [Ref1] when a router routing entry is added, but every time a vertex is added to the SPT in step 3 of the same algorithm.
記載状況がかなり稀であると思われるが、対応するルータIDを持つルータは、ダイクストラを介して見たときの仮想リンクが（InterfaceUpイベントが発生する）まで報告されているように、シスコABRの動作をサポートする実装は、VL固有のコードを変更することを検討してもよいです、そのルータLSAは、それがABRであるかないことを示しているかどうかに関係なく。これは、構成された仮想リンクのチェックは16.1でアルゴリズムのステップ4ではない行うべきであることを意味する[Ref1の】ルータのルーティングエントリが追加される場合が、頂点は同じアルゴリズムのステップ3でSPTに追加されるたびに。
4 Compatibility
4互換性
The changes of the OSPF ABR operations do not influence any aspects of the router-to-router cooperation and do not create routing loops, and hence are fully compatible with standard OSPF. Proof of compatibility is outside the scope of this document.
OSPF ABR動作の変化は、ルータ間の協力の任意の態様に影響を与えないと、ルーティングループを作成しない、したがって標準OSPFと完全に互換性があります。互換性の証明は、この文書の範囲外です。
5 Deployment Considerations
5つの配備の考慮事項
This section discusses the deployments details of the ABR behaviors described in this document. Note that this approach is fully compatible with standard ABR behavior, so ABRs acting as described in [Ref1] and in this document can coexist in an OSPF domain and will function without problems.
このセクションでは、この文書で説明したABR行動の展開の詳細について説明します。 [Ref1の]で説明し、本書でOSPFドメイン内に共存することができ、問題なく機能するようのABRが作用するので、このアプローチは、標準的なABRの動作と完全に互換性があることに留意されたいです。
Deployment of ABRs using the alternative methods improves the behavior of a router connected to multiple areas without a backbone attachment, but can lead to unexpected routing asymmetry, as described below.
別の方法を使用してのABRの展開は、バックボーンアタッチメントなしで複数のエリアに接続されたルータの動作を改善するが、以下に説明するように、予期しないルーティングの非対称性をもたらすことができます。
Consider an OSPF domain depicted in Figure 4.
図4に示さOSPFドメインを考えます。
. Backbone .
. .
. --------------------- .
. |1 1| .
..+--+.............+--+..
..|R1|..... ....|R4|..
. +--+ . . +--+ .
. 1| . . /4 .
. | 8 +--+ 4 / .
. | +-|R3|---+ .
. 1| / +--+\4 .
. +--+ / . . \ 4 +--+ .
. |R2|/8 . . +--|R5| .
. +--+ . . +--+ .
. | . . | .
. --------- . . -------- .
. net N . . net M .
. . . .
. Area 1 . . Area 2 .
........... ..........
Figure 4. Inter-area routing asymmetry
図4.インター領域ルーティング非対称
Assume that R3 uses the approach described in this document. In this case R2 will have inter-area routes to network M via ABR R1 only. R5 in turn will have its inter-area route to network N via R4, but as far as R4 is only reachable via R3, all traffic destined to network N will pass through R3. R3 will have an intra-area route to network N via R2 and will, of course, route it directly to it (because intra-area routes are always preferred over inter-area ones). Traffic going back from network N to network M will pass through R2 and will be routed to R1, as R2 will not have any inter-area routes via R3. So, traffic from N to M will always go through the backbone while traffic from M to N will cross the areas directly via R3 and, in this example, will not use a more optimal path through the backbone.
R3は、この文書で説明したアプローチを使用していることを前提としています。この場合、R2は、ABR R1を介してMをネットワークにエリア間経路を有することになります。次にR5は、R4を介してNをネットワークへのエリア間経路を有するであろう、しかし限りR4はR3を介してのみ到達可能であるように、Nをネットワークに宛てたすべてのトラフィックはR3を通過することになります。 （エリア内のルートが常にエリア間のものよりも優先されるため）R3は、R2を介してNをネットワークにエリア内のルートを持っているとは、もちろん、それに直接ルートになります。 R2がR3を介して任意のエリア間のルートを持っていないので、トラフィックが、MがR2を通過し、R1にルーティングされるネットワーク、ネットワークNから遡っ。 MからNへのトラフィックはR3経由で直接領域を横断すると、この例では、バックボーンを通じて、より最適なパスを使用することはありませんしながら、だから、NからMへのトラフィックは常にバックボーンを通過します。
Note that this problem is not caused by the fact that R3 uses the alternative approach. The reason for attracting the attention to it is that R3 is not really functioning as an ABR in case this new behavior is used, i.e., it does not inject summary-LSAs into the attached areas, but inter-area traffic can still go through it.
この問題は、R3は、別のアプローチを使用するという事実によって引き起こされていないことに注意してください。それに注目する理由はつまり、それが接続されたエリアに要約LSAを注入しない、R3は本当に場合にはABRとして機能していないこの新しい動作が使用されていることですが、エリア間のトラフィックはまだそれを通過することができます。
6 Security Considerations
6セキュリティについての考慮事項
The alternative ABR behaviors specified in this document do not raise any security issues that are not already covered in [Ref1].
この文書で指定された代替ABRの行動はすでに[Ref1の]でカバーされていない任意のセキュリティ上の問題を提起しません。
7 Acknowledgements
7つの謝辞
Authors would like to thank Alvaro Retana, Russ White, and Liem Nguyen for their review of the document.
著者は、ドキュメントの彼らのレビューのためにアルバロRetana、ラスホワイト、及びLiem Nguyenさんに感謝したいと思います。
8 Disclaimer
8免責事項
This document describes OSPF ABR implementations of respective vendors "as is", only for informational purposes, and without any warranties, guarantees or support. These implementations are subject to possible future changes. For the purposes of easier deployment, information about software versions where described behavior was integrated is provided below.
この文書は情報提供のみを目的として、いかなる保証、保証やサポートなしに、「そのまま」のそれぞれのベンダーのOSPF ABRの実装について説明します。これらの実装は、将来変更することがあります。簡単に導入の目的のために、説明した動作が統合されたソフトウェアのバージョンに関する情報は以下の通りです。
Initial Cisco ABR implementation (slightly different from the one described in this memo, requiring non-backbone areas to be configured, and not necessarily actively attached in the ABR definition) was introduced in Cisco IOS (tm) version 11.1(6). Cisco ABR behavior described in this document was integrated in Cisco IOS (tm) in version 12.1(3)T.
初期シスコABR（このメモで説明したものとは若干異なる、構成する非バックボーン領域を必要とし、必ずしも積極ABR定義に結合している）の実装は、Cisco IOS（登録商標）バージョン11.1（6）に導入されました。この文書で説明するシスコABRの挙動は、バージョン12.1（3）TのCisco IOS（TM）に統合されました。
The ABR behavior described as IBM ABR approach was implemented by IBM in IBM Nways Multiprotocol Routing Services (MRS) 3.3.
IBM ABRアプローチとして記載ABRの動作はIBM Nwaysマルチルーティング・サービスでIBM（MRS）3.3によって実施されました。
Note that the authors do not intend to keep this document in sync with actual implementations.
著者らは、実際の実装と同期して、この文書を維持するつもりはないことに注意してください。
10 References
10本の参考文献
[Ref1] Moy, J., "OSPF version 2", STD 54, RFC 2328, April 1998.
[Ref1の】モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
11 Authors' Addresses
11本の著者のアドレス
Alex Zinin Alcatel
アルカテルアレックス・Z
EMail: zinin@psg.com
メールアドレス：zinin@psg.com
Derek M. Yeung Procket Networks 1100 Cadillac Ct Milpitas, CA 95035
デレク・M.ヨンProcket Networksの1100キャデラック・CTSミルピタス、CA 95035
Phone: 408-635-7911 EMail: myeung@procket.com
電話：408-635-7911 Eメール：myeung@procket.com
Acee Lindem Redback Networks 102 Carric Bend Court Cary, NC 27519 USA
ACEE Lindemレッドバック・ネットワーク102 Carricベンド裁判所カリー、NC 27519 USA
Phone: 919-387-6971 EMail: acee@redback.com
電話：919-387-6971 Eメール：acee@redback.com
12 Full Copyright Statement
12完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。