Network Working Group A. Retana
Request for Comments: 3137 L. Nguyen
Category: Informational R. White
Cisco Systems
A. Zinin
Nexsi Systems
D. McPherson
Amber Networks
June 2001
OSPF Stub Router Advertisement
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 (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
This memo describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise unavailability to forward transit traffic or to lower the preference level for the paths through such a router. In some cases, it is desirable not to route transit traffic via a specific OSPF router. However, OSPF does not specify a standard way to accomplish this.
このメモは、通過トラフィックを転送したり、ルータを介してパスの優先度を下げるために使用不能を通知するOSPF（オープンショーテストパスファースト）の実装によって使用されることができる下位互換性技術が記載されています。いくつかのケースでは、そうではない、特定のOSPFルータを経由する経路トランジットトラフィックをすることが望ましいです。しかし、OSPFは、これを実現するための標準的な方法を指定しません。
In some situations, it may be advantageous to inform routers in a network not to use a specific router as a transit point, but still route to it. Possible situations include the following.
いくつかの状況では、中継点として特定のルータを使用し、まだそれにルートしないネットワーク内のルータに通知することが有利であり得ます。可能な状況には以下のものが挙げられます。
o The router is in a critical condition (for example, has very high CPU load or does not have enough memory to store all LSAs or build the routing table).
ルータO（例えば、非常に高いCPU負荷を持っているか、すべてのLSAを保存したり、ルーティングテーブルを構築するための十分なメモリがありません）重要な条件です。
o Graceful introduction and removal of the router to/from the network.
O優雅導入し、ネットワークから/へのルータの除去。
o Other (administrative or traffic engineering) reasons.
Oその他（管理上またはトラフィックエンジニアリング）の理由。
Note that the proposed solution does not remove the router from the topology view of the network (as could be done by just flushing that router's router-LSA), but prevents other routers from using it for transit routing, while still routing packets to router's own IP addresses, i.e., the router is announced as stub.
それでもルータ自身にパケットをルーティングしながら、提案されたソリューションは、ネットワークのトポロジビュー（ちょうどそのルータのルータ - LSAをフラッシュすることによって行うことができるよう）からルータを削除しますが、トランジットルーティングのためにそれを使用してから他のルータを防止していないことに注意してくださいIPアドレスは、すなわち、ルータはスタブとして発表されます。
It must be emphasized that the proposed solution provides real benefits in networks designed with at least some level of redundancy so that traffic can be routed around the stub router. Otherwise, traffic destined for the networks reachable through such a stub router will be still routed through it.
トラフィックがスタブルータを迂回することができるように提案された解決策は、冗長性の少なくともいくつかのレベルで設計されたネットワークでの真のメリットを提供することを強調しなければなりません。そうでなければ、このようスタブルータを介して到達可能なネットワーク宛てのトラフィックはまだそれを経由してルーティングされます。
The solution described in this document solves two challenges associated with the outlined problem. In the description below, router X is the router announcing itself as a stub.
この文書で説明するソリューションを概説問題に関連した2つの課題を解決します。以下の説明では、ルータXは、スタブとして自分自身を発表ルータです。
1) Making other routers prefer routes around router X while performing the Dijkstra calculation.
1）他のルータの作成ダイクストラ計算を行いながら、ルータXの周りにルートを好みます。
2) Allowing other routers to reach IP prefixes directly connected to router X.
2）他のルータが直接ルータXに接続されているIPプレフィクスに到達することを可能にします
Note that it would be easy to address issue 1) alone by just flushing router X's router-LSA from the domain. However, it does not solve problem 2), since other routers will not be able to use links to router X in Dijkstra (no back link), and because router X will not have links to its neighbors.
それだけで、ドメインからルータXのルータLSAをフラッシュすることによってのみ）問題1に対処するのは簡単だろうことに注意してください。しかし、他のルータは、ダイクストラにおけるX（ノーバックリンクをルータにリンクを使用することはできませんので、それは）、）問題2を解決しないと、ルータXは、隣国へのリンクを持っていないので。
To address both problems, router X announces its router-LSA to the neighbors as follows.
次のように両方の問題に対処するために、ルータXは、隣人にそのルータLSAを発表しました。
o costs of all non-stub links (links of the types other than 3) are set to LSInfinity (16-bit value 0xFFFF, rather than 24-bit value 0xFFFFFF used in summary and AS-external LSAs).
Oすべての非スタブリンク（3以外のタイプのリンク）のコストは（0xFFFFFFのサマリーとAS-外部LSAで使用される16ビット値0xFFFFではなく、24ビット値）LSInfinityに設定されています。
o costs of stub links (type 3) are set to the interface output cost.
スタブリンク（タイプ3）のOコストは、インターフェイス出力コストに設定されています。
This addresses issues 1) and 2).
これは、問題に対処1）及び2）。
Some inconsistency may be seen when the network is constructed of the routers that perform intra-area Dijkstra calculation as specified in [RFC1247] (discarding link records in router-LSAs that have LSInfinity cost value) and routers that perform it as specified in [RFC1583] and higher (do not treat links with LSInfinity cost as unreachable). Note that this inconsistency will not lead to routing loops, because if there are some alternate paths in the network, both types of routers will agree on using them rather than the path through the stub router. If the path through the stub router is the only one, the routers of the first type will not use the stub router for transit (which is the desired behavior), while the routers of the second type will still use this path.
[RFC1247]（LSInfinityコスト値を有するルータのLSAのリンクレコードを破棄）と[RFC1583で指定されるようにそれを実行するルータで指定されたネットワークは、エリア内ダイクストラ計算を実行するルータで構成されている場合、いくつかの矛盾が見られるかもしれません]と高い（到達不能としてLSInfinityコストとのリンクを扱うことはありません）。ネットワーク内のいくつかの代替パスがある場合、ルータの両方のタイプは、スタブルータを通る経路ではなく、それらを使用することに同意するので、この矛盾は、ルーティングループをもたらさないことに注意してください。スタブルータを通るパスが一つだけである場合に、第2のタイプのルータがまだこのパスを使用する一方、第一のタイプのルータは、（所望の動作である）トランジットのスタブルータを使用しないであろう。
The authors of this document do not make any claims on the originality of the ideas described. Among other people, we would like to acknowledge Henk Smit for being part of one of the initial discussions around this topic.
本書の著者は述べたアイデアの独創性に申し立てを行うことはありません。他の人の中で、私たちは、このトピックの周りの初期の議論の一つの一部であるためヘンクスミットを承認したいと思います。
The technique described in this document does not introduce any new security issues into OSPF protocol.
この文書に記載された技術は、OSPFプロトコルに新たなセキュリティ問題を紹介しません。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[RFC1247] Moy, J., "OSPF Version 2", RFC 1247, July 1991.
[RFC1247]モイ、J.、 "OSPFバージョン2"、RFC 1247、1991年7月。
[RFC1583] Moy, J., "OSPF Version 2", RFC 1583, March 1994.
[RFC1583]モイ、J.、 "OSPFバージョン2"、RFC 1583、1994年3月。
Alvaro Retana 7025 Kit Creek Rd. Research Triangle Park, NC 27709 USA
アルバロRetana 7025キットクリークRdを。リサーチトライアングルパーク、NC 27709 USA
EMail: aretana@cisco.com
メールアドレス：aretana@cisco.com
Liem Nguyen 7025 Kit Creek Rd. Research Triangle Park, NC 27709 USA
Liem Nguyenの7025キットクリークRdを。リサーチトライアングルパーク、NC 27709 USA
EMail: lhnguyen@cisco.com
メールアドレス：lhnguyen@cisco.com
Russ White Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709
ラスホワイトシスコシステムズ株式会社7025キットクリークRdを。リサーチトライアングルパーク、NC 27709
EMail: riw@cisco.com
メールアドレス：riw@cisco.com
Alex Zinin Nexsi Systems 1959 Concourse Drive San Jose,CA 95131
アレックスジニンNexsiシステムズ1959コンコースドライブサンノゼ、CA 95131
EMail: azinin@nexsi.com
メールアドレス：azinin@nexsi.com
Danny McPherson Amber Networks 48664 Milmont Drive Fremont, CA 94538
ダニー・マクファーソンアンバーネットワーク48664 Milmontドライブフリーモント、CA 94538
EMail: danny@ambernetworks.com
メールアドレス：danny@ambernetworks.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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機能のための基金は現在、インターネット協会によって提供されます。