[要約] RFC 3137は、OSPF Stub Router Advertisementの仕様を定義しており、スタブルーターがOSPFネットワークに参加するための方法を提供しています。目的は、スタブルーターがネットワークのトポロジ情報を受け取らずに、他のルーターとの通信を確立することです。
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
OSPFスタブルーター広告
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.
Copyright（c）The Internet Society（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以外のタイプのリンク）は、概要および概要ASExternal LSAで使用される24ビット値0xffffffではなく、16ビット値0xffff）に設定されます。
o costs of stub links (type 3) are set to the interface output cost.
o スタブリンクのコスト（タイプ3）は、インターフェイスの出力コストに設定されます。
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]で指定されているように、エリア内Dijkstra計算を実行するルーターでネットワークが構築されている場合、[RFC158383838383で指定されているように実行するルーターを実行するルーターである場合、ネットワークが領域内Dijkstra計算を実行するルーターで構成されている場合、ある程度の矛盾がわかります。]およびより高い（リンクを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.
この文書の著者は、説明されているアイデアの独創性について主張していません。他の人たちの中で、このトピックに関する最初の議論の1つであることをヘンクスミットに認めたいと思います。
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] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[RFC1247] Moy, J., "OSPF Version 2", RFC 1247, July 1991.
[RFC1247] Moy、J。、「OSPFバージョン2」、RFC 1247、1991年7月。
[RFC1583] Moy, J., "OSPF Version 2", RFC 1583, March 1994.
[RFC1583] Moy、J。、「OSPFバージョン2」、RFC 1583、1994年3月。
Alvaro Retana 7025 Kit Creek Rd. Research Triangle Park, NC 27709 USA
Alvaro Retana 7025 Kit Creek Rd。研究トライアングルパーク、NC 27709 USA
EMail: aretana@cisco.com
Liem Nguyen 7025 Kit Creek Rd. Research Triangle Park, NC 27709 USA
Liem Nguyen 7025 Kit Creek Rd。研究トライアングルパーク、NC 27709 USA
EMail: lhnguyen@cisco.com
Russ White Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709
Russ White Cisco Systems、Inc。7025 Kit Creek Rd。研究トライアングルパーク、ノースカロライナ州27709
EMail: riw@cisco.com
Alex Zinin Nexsi Systems 1959 Concourse Drive San Jose,CA 95131
Alex Zinin Nexsi Systems 1959 Concourse Drive San Jose、CA 95131
EMail: azinin@nexsi.com
Danny McPherson Amber Networks 48664 Milmont Drive Fremont, CA 94538
ダニーマクファーソンアンバーネットワーク48664ミルモントドライブフリーモント、カリフォルニア94538
EMail: danny@ambernetworks.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。