RFC3101 日本語訳
3101 The OSPF Not-So-Stubby Area (NSSA) Option. P. Murphy. January 2003. (Format: TXT=76243 bytes) (Obsoletes RFC1587) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Murphy Request for Comments: 3101 US Geological Survey Obsoletes: 1587 January 2003 Category: Standards Track
コメントを求めるワーキンググループP.マーフィー要求をネットワークでつないでください: 3101年の米国の地質調査は以下を時代遅れにします。 1587 2003年1月のカテゴリ: 標準化過程
The OSPF Not-So-Stubby Area (NSSA) Option
OSPFしたがって、短く太くない領域(NSSA)オプション
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
This memo documents an optional type of Open Shortest Path First (OSPF) area that is somewhat humorously referred to as a "not-so- stubby" area (or NSSA). NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion.
このメモがいくらかユーモラスにaと呼ばれる任意のタイプのオープンShortest Path First(OSPF)領域を記録する、「-、したがって、短く太い、」 領域(または、NSSA)。 NSSAsには、既存のOSPFスタッブ領域設定オプションと同様ですが、AS外部経路を輸入する追加する機能が限られたファッションであります。
The OSPF NSSA Option was originally defined in RFC 1587. The functional differences between this memo and RFC 1587 are explained in Appendix F. All differences, while expanding capability, are backward-compatible in nature. Implementations of this memo and of RFC 1587 will interoperate.
OSPF NSSA Optionは元々、RFC1587で定義されました。 このメモとRFC1587の機能的な違いはAppendix F.で説明されます。All差は能力を広げている間、現実に互換性があります後方の。 このメモとRFC1587の実現は共同利用するでしょう。
Murphy Standards Track [Page 1] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
マーフィーStandardsはOSPFしたがって、短く太くない領域(NSSA)オプション2003年1月にRFC3101を追跡します[1ページ]。
Table Of Contents
目次
1.0 Overview ................................................. 2
1.1 Motivation - Transit Networks ......................... 2
1.2 Motivation - Corporate Networks ....................... 4
1.3 Proposed Solution ..................................... 5
2.0 NSSA Intra-Area Implementation Details ................... 7
2.1 The N-bit ............................................. 7
2.2 Type-7 Address Ranges ................................. 7
2.3 Type-7 LSAs ........................................... 8
2.4 Originating Type-7 LSAs ............................... 9
2.5 Calculating Type-7 AS External Routes ................. 10
2.6 Incremental Updates ................................... 14
2.7 Optionally Importing Summary Routes ................... 14
3.0 Intra-AS Implementation Details .......................... 15
3.1 Type-7 Translator Election ............................ 15
3.2 Translating Type-7 LSAs into Type-5 LSAs .............. 16
3.3 Flushing Translated Type-7 LSAs ....................... 19
4.0 Security Considerations .................................. 20
5.0 Acknowledgements ......................................... 21
6.0 Contributors ............................................. 22
7.0 References ............................................... 22
Appendix A: The Options Field ................................ 23
Appendix B: Router-LSAs ...................................... 24
Appendix C: Type-7 LSA Packet Format ......................... 26
Appendix D: Configuration Parameters ......................... 27
Appendix E: The P-bit Policy Paradox ......................... 28
Appendix F: Differences from RFC 1587 ........................ 30
Author's Addresses ........................................... 32
Full Copyright Statement ..................................... 33
1.0概観… 2 1.1 動機--トランジットネットワーク… 2 1.2 動機--法人のネットワーク… 4 1.3はソリューションを提案しました… 5 2.0 NSSAイントラ領域実現の詳細… 7 2.1 N-ビット… 7 2.2 タイプ-7アドレスは及びます… 7 2.3 タイプ-7LSAs… 8 2.4 由来しているタイプ-7LSAs… 9 2.5 外部としての計算のタイプ-7ルート… 10 2.6 増加のアップデート… 14 2.7 任意に、概要ルートを輸入します… 14、3.0、イントラ、-、実現の詳細… 15 3.1 タイプ-7翻訳者選挙… 15 3.2 タイプ-7LSAsをタイプ-5LSAsに翻訳します… 16 3.3 洗い流すのはタイプ-7LSAsを翻訳しました… 19 4.0 セキュリティ問題… 20 5.0の承認… 21 6.0人の貢献者… 22 7.0の参照箇所… 22 付録A: オプション分野… 23 付録B: ルータ-LSAs… 24 付録C: タイプ-7LSAパケット・フォーマット… 26 付録D: 構成パラメタ… 27 付録E: P-ビット方針パラドックス… 28 付録F: RFC1587からの違い… 30作者のアドレス… 32 完全な著作権宣言文… 33
1.0 Overview
1.0 概観
1.1 Motivation - Transit Networks
1.1 動機--輸送網
Wide-area transit networks often have connections to moderately complex "leaf" sites. A leaf site may have multiple IP network numbers assigned to it. Typically, one of the leaf site's networks is directly connected to a router provided and administered by the transit network while the others are distributed throughout and administered by the site. From the transit network's perspective, all of the network numbers associated with the site make up a single "stub" entity. For example, BBN Planet has one site composed of a class-B network, 130.57.0.0, and a class-C network, 192.31.114.0. From BBN Planet's perspective, this configuration looks something like the diagram on the next page, where the "cloud" consists of the subnets of 130.57 and network 192.31.114, all of which are learned by RIP on router BR18.
広い領域輸送網には、適度に複雑な「葉」サイトには接続がしばしばあります。 葉のサイトで、複数のIPネットワーク・ナンバーをそれに割り当てるかもしれません。 通常、葉のサイトのネットワークの1つは直接トランジットネットワークによって提供されて、他のものがサイトによって分配されて管理されていましたが、管理されたルータに関連づけられます。 トランジットネットワークの見解から、サイトに関連しているネットワーク・ナンバーのすべてがただ一つの「スタッブ」実体を作ります。 BBN Planetには、例えば、130.57の.0のクラスBネットワーク、.0、およびaクラスCネットワークで構成されたあるサイト、192.31があります。.114 .0。 BBN Planetの見解から、この構成が「雲」が130.57とネットワークのサブネットから成る次のページのダイヤグラムのように見える、192.31、.114、それのすべてがルータBR18の上のRIPによって学習される。
Murphy Standards Track [Page 2] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
マーフィーStandardsはOSPFしたがって、短く太くない領域(NSSA)オプション2003年1月にRFC3101を追跡します[2ページ]。
192.31.114
|
(cloud)
-------------- 130.57.4
|
|
------ 131.119.13 ------
|BR18|------------|BR10|
------ ------
|
V
to BBN Planet "core" OSPF system
192.31.114 | (雲) -------------- 130.57.4 | | ------ 131.119.13 ------ |BR18|------------|BR10| ------ ------ | BBN Planet「コア」OSPFシステムへのV
Topologically, this cloud looks very much like an OSPF stub area. The advantages of running the cloud as an OSPF stub area are:
位相的に、この雲はOSPFスタッブ領域にたいへん似ています。 OSPFスタッブ領域として雲を走らせる利点は以下の通りです。
1. External routes learned from OSPF's Type-5 AS-external-LSAs are
not advertised beyond the router labeled "BR10". This is
advantageous because the link between BR10 and BR18 may be a
low-speed link or the router BR18 may have limited resources.
1. OSPFのType-5 ASの外部のLSAsから学習された外部経路は"BR10""とラベルされたルータを超えて広告を出しません。 BR10とBR18とのリンクが低速リンクであったかもしれないかルータBR18がリソースを制限したかもしれないので、これは有利です。
2. The transit network is abstracted to the "leaf" router BR18 by
advertising only a default route across the link between BR10
and BR18.
2. トランジットネットワークは、BR10とBR18とのリンクの向こう側にデフォルトルートだけの広告を出すことによって、「葉」ルータBR18に抜き取られています。
3. The cloud becomes a single, manageable "leaf" with respect to
the transit network.
3. 雲はトランジットネットワークに関して単一の、そして、処理しやすい「葉」になります。
4. The cloud can become, logically, a part of the transit
network's OSPF routing system.
4. トランジットネットワークのOSPFの一部がシステムを発送する場合、雲は論理的になることができます。
However, the original definition of the OSPF protocol (See [OSPF]) imposes topological limitations that restrict simple cloud topologies from becoming OSPF stub areas. In particular, it is illegal for a stub area to import routes external to OSPF; thus it is not possible for routers BR18 and BR10 to both be members of the stub area and to import into OSPF as Type-5 AS-external-LSAs routes learned from RIP or other IP routing protocols. In order to run OSPF out to BR18, BR18 must be a member of a non-stub area or the OSPF backbone before it can import routes other than its directly connected network(s). Since it is not acceptable for BR18 to maintain all of BBN Planet's Type-5 AS external routes, BBN Planet is forced by OSPF's topological limitations to only run OSPF out to BR10 and to run RIP between BR18 and BR10.
しかしながら、OSPFプロトコル([OSPF]を見る)のオリジナルの定義はOSPFスタッブ領域になるので簡単な雲のtopologiesを制限する位相的な制限を課します。 スタッブ領域がOSPFへの外部のルートを輸入するのは、特に、不法です。 したがって、それはともにスタッブ領域のメンバーであるルータのBR18とBR10とRIPから学習されたType-5 ASの外部のLSAsルートとしてのOSPFへの輸入か他のIPルーティング・プロトコルに可能ではありません。 BR18への外へOSPFを走らせるために、直接接続されたネットワーク以外のルートを輸入できる前にBR18は非スタッブ領域かOSPF背骨の器官でなければなりません。 BR18がBBN PlanetのType-5 AS外部経路のすべてを維持するのが、許容できないので、BBN PlanetはBR10への外へOSPFを走らせるだけであり、BR18とBR10の間でRIPを走らせるのがOSPFの位相的な制限で強制されます。
Murphy Standards Track [Page 3] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
マーフィーStandardsはOSPFしたがって、短く太くない領域(NSSA)オプション2003年1月にRFC3101を追跡します[3ページ]。
1.2 Motivation - Corporate Networks
1.2 動機--企業ネットワーク
In a corporate network that supports a large corporate infrastructure it is not uncommon for its OSPF domain to have a complex non-zero area infrastructure that injects large routing tables into its Area 0 backbone. Organizations within the corporate infrastructure may routinely multi-home their non-zero OSPF areas to strategically located Area 0 backbone routers, either to provide backbone redundancy or to increase backbone connectivity or both. Because of these large routing tables, OSPF aggregation via summarization is routinely used and recommended. Stub areas are also recommended to keep the size of the routing tables of non-backbone routers small. Organizations within the corporation are administratively autonomous and compete for corporate backbone resources. They also want isolation from each other in order to protect their own network resources within the organization.
大きい法人のインフラストラクチャを支持する企業ネットワークでは、OSPFドメインにはArea0背骨に大きい経路指定テーブルを注ぐ複雑な非ゼロ領域インフラストラクチャがあるのは、珍しくはありません。 法人のインフラストラクチャの中の組織はきまりきってそうするかもしれません。戦略上見つけられたArea0背骨ルータ、背骨冗長を提供するか、または背骨の接続性を増加させるどちらかまたは両方へのそれらの非ゼロのマルチの家のOSPF地域。 これらの大きい経路指定テーブルのために、総括を通したOSPF集合は、きまりきって使用されて、推薦されます。 また、スタッブ領域が非背骨ルータの経路指定テーブルのサイズを小さく保つことが勧められます。 会社の中の組織は、行政上自治であり、法人の背骨リソースを競争します。 また、彼らは、組織の中にそれら自身のネットワーク資源を保護するために互いから孤立が欲しいです。
Consider the typical example configuration shown below where routers A1, B1 and A2, B2 are connected to Area 1 and Area 2 respectively, and where routers A0 and B0 are Area 0 border routers that connect to both Area 1 and Area 2. Assume the 192.168.192/20 and 192.168.208/22 clouds are subnetted with a protocol different from the corporate OSPF instance. These other protocols could be RIP, IGRP, or second and third OSPF instances separate from the corporate OSPF backbone instance.
ルータのA1とB1とA2、B2がどこでそれぞれArea1とArea2に接続されるか、そして、ルータのA0とB0がどこのArea1とArea2の両方に接続するArea0境界ルータであるかの下に示された典型的な例の構成を考えてください。 20と.192/192.168.208/22回の雲が法人のOSPF例と異なったプロトコルで「副-網で覆」われると192.168に仮定してください。 これらの他のプロトコルは、リップ、IGRP、または法人のOSPF背骨例から別々の2番目と3番目のOSPF例であるかもしれません。
Area 1 and Area 2 would like to be stub areas to minimize the size of their link state databases. It is also desirable to originate two aggregated external advertisements for the subnets of 192.168.192/20 and 192.168.208/22 in such a way that the preferred path to 192.168.192/20 is through A0 and the preferred path to 192.168.208/22 is through B0.
領域1とArea2は、それらのリンク州のデータベースのサイズを最小にするためにスタッブ領域になりたがっています。 また、2を溯源するのが192.168 20と.192/192.168.208/22のサブネットのためにそのような方法で外部の広告に集められたのも、望ましい、それ、都合のよい経路、192.168に、.192/20はB0を通してA0と192.168への都合のよい経路を通して、.208/22があるということです。
+---A0------Area 0 cloud------B0---+
| | | |
| | | |
| |T1 56kbs| |
56kbs| | | |T1
| | | |
| | Area 1 cloud | |
| A1-----192.168.192/20-----B1 |
| |
+---A2 B2---+
| |
| Area 2 cloud |
+-----192.168.208/22------+
+---A0------領域0雲------B0---+ | | | | | | | | | |T1 56kbs| | 56kbs| | | |T1| | | | | | 領域1雲| | | A1-----192.168.192/20-----B1| | | +---A2 B2---+ | | | 領域2雲| +-----192.168.208/22------+
Murphy Standards Track [Page 4] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
マーフィーStandardsはOSPFしたがって、短く太くない領域(NSSA)オプション2003年1月にRFC3101を追跡します[4ページ]。
The current standard OSPF stub area has no mechanism to support the redistribution of routes for the subnets of 192.168.192/20 and 192.168.208/22 within a stub area or the ability to aggregate a range of external routes in any OSPF area. Any solution to this dilemma must also honor Area 1's path of choice to 192.168.192/20 through A0 with redundancy through B0 while at the same time honoring Area 2's path of choice to 192.168.208/20 through B0 with redundancy through A0.
現在の標準のOSPFスタッブ領域はどんなOSPF領域にもいずれのスタッブ領域の中の192.168 20と.192/192.168.208/22のサブネットのためにルートの再分配を支持するメカニズムもさまざまな外部経路に集める能力も持っていません。 また、このジレンマのどんな解決策も、Area2の選択の経路を192.168と光栄に思いながら、B0を通して冗長があるA0を通した.192/20が同時にゆったり過ごす192.168とArea1の選択の経路を光栄に思わなければなりません。A0を通して冗長があるB0を通した.208/20。
1.3 Proposed Solution
1.3 提案されたソリューション
This document describes a new optional type of OSPF area, somewhat humorously referred to as a "not-so-stubby" area (or NSSA), which has the capability of importing external routes in a limited fashion.
このドキュメントは限られたファッションで外部経路を輸入する能力を持っているいくらかユーモラスに「したがって、短く太くない」領域(または、NSSA)と呼ばれた新しい任意のタイプのOSPF領域について説明します。
The OSPF specification defines two general classes of area configuration. The first allows Type-5 LSAs to be flooded throughout the area. In this configuration, Type-5 LSAs may be originated by routers internal to the area or flooded into the area by area border routers. These areas, referred to herein as Type-5 capable areas (or just plain areas in the OSPF specification), are distinguished by the fact that they can carry transit traffic. The backbone is always a Type-5 capable area. The second type of area configuration, called stub, does not allow Type-5 LSAs to be propagated into/throughout the area and instead depends on default routing to external destinations.
OSPF仕様は2つの一般的なクラスの領域構成を定義します。 1番目は、領域中にType-5 LSAsが水につかっているのを許容します。 この構成では、Type-5 LSAsは境界ルータによってその領域への内部のルータによって溯源されるか、または領域へあふれさせられるかもしれません。 トランジット交通を運ぶことができるという事実によってここにType-5のできる領域(または、まさしくOSPF仕様による平らな領域)と呼ばれたこれらの領域は区別されます。 いつも背骨はType-5のできる領域です。 スタッブと呼ばれる2番目のタイプの領域構成は、Type-5 LSAsが領域中で/に伝播されるのを許容しないで、代わりに外部の目的地へのデフォルトルーティングに依存します。
NSSAs are defined in much the same manner as existing stub areas. To support NSSAs, a new option bit (the "N" bit) and a new type of LSA (Type-7) are defined. The "N" bit ensures that routers belonging to an NSSA agree on its configuration. Similar to the stub area's use of the "E" bit, both NSSA neighbors must agree on the setting of the "N" bit or the OSPF neighbor adjacency will not form.
NSSAsは既存のスタッブ領域への似たり寄ったりの方法で定義されます。 NSSAsを支持するために、新しいオプションビット(「N」ビット)とLSAの新しいタイプ(タイプ-7)は定義されます。 「N」ビットは、NSSAに属すルータが構成に同意するのを確実にします。 「E」ビットのスタッブ領域の使用と同様です、両方のNSSA隣人が「N」ビットの設定に同意しなければならない、さもなければ、OSPF隣人隣接番組は形成されないでしょう。
Type-7 LSAs provide for carrying external route information within an NSSA. Type-7 LSAs have virtually the same syntax as Type-5 LSAs with the obvious exception of the link-state type. (See section 2.3 for more details.) Both LSAs are considered a type of OSPF AS- external-LSA. There are two major semantic differences between Type-5 LSAs and Type-7 LSAs.
タイプ-7LSAsがNSSAの中で外部経路情報を運ぶのに提供します。 タイプ-7LSAsには、実際にはリンク州のタイプの明白な例外があるType-5 LSAsと同じ構文があります。 (その他の詳細に関してセクション2.3を見てください。) 両方のLSAsは一種のOSPF ASの外部のLSAであると考えられます。 Type-5 LSAsとType-7 LSAsの間には、2つの主要な意味違いがあります。
o Type-7 LSAs may be originated by and advertised throughout an
NSSA; as with stub areas, Type-5 LSAs are not flooded into
NSSAs and do not originate there.
o タイプ-7LSAsがNSSA中に溯源されて広告を出すかもしれません。 スタッブ領域のように、Type-5 LSAsはNSSAsへあふれないで、またそこで由来しません。
o Type-7 LSAs are advertised only within a single NSSA; they are
not flooded into the backbone area or any other area by border
routers, though the information that they contain may be
propagated into the backbone area. (See Section 3.2.)
o 独身のNSSAだけの中にタイプ-7LSAsの広告を出します。 それらは背骨領域か境界ルータによるいかなる他の領域へもあふれません、それらが含む情報が背骨領域に伝播されるかもしれませんが。 (セクション3.2を見てください。)
Murphy Standards Track [Page 5] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
マーフィーStandardsはOSPFしたがって、短く太くない領域(NSSA)オプション2003年1月にRFC3101を追跡します[5ページ]。
In order to allow limited exchange of external information across an NSSA border, NSSA border routers will translate selected Type-7 LSAs received from the NSSA into Type-5 LSAs. These Type-5 LSAs will be flooded to all Type-5 capable areas. NSSA border routers may be configured with address ranges so that multiple Type-7 LSAs may be aggregated into a single Type-5 LSA. The NSSA border routers that perform translation are configurable. In the absence of a configured translator one is elected.
NSSA境界の向こう側に外部の情報の限られた交換を許容するために、NSSA境界ルータはNSSAから受け取られた選択されたType-7 LSAsをType-5 LSAsに翻訳するでしょう。 これらのType-5 LSAsはすべてのType-5のできる領域へあふれるでしょう。 NSSA境界ルータは、複数のType-7 LSAsを独身のType-5 LSAに集めることができるようにアドレスの範囲によって構成されるかもしれません。 翻訳を実行するNSSA境界ルータは構成可能です。 構成された翻訳者が不在のとき、1つは選出されます。
In addition, an NSSA border router should originate a default LSA (IP network is 0.0.0.0/0) into the NSSA. Default routes are necessary because NSSAs do not receive full routing information and must have a default route in order to route to AS-external destinations. Like stub areas, NSSAs may be connected to the Area 0 backbone at more than one NSSA border router, but may not be used as a transit area. Note that a Type-7 default LSA originated by an NSSA border router is never translated into a Type-5 LSA, however, a Type-7 default LSA originated by an NSSA internal AS boundary router (one that is not an NSSA border router) may be translated into a Type-5 LSA.
IPネットワークはそうです。さらに、NSSA境界ルータがデフォルトLSAを溯源するべきである、(0.0 .0 .0/0) NSSAに。 NSSAsが完全なルーティング情報を受け取らないで、デフォルトルートを持たなければならないのでデフォルトルートが必要である、AS外部の目的地に発送します。 スタッブ領域のように、NSSAsは1つ以上のNSSA境界ルータにおけるArea0背骨に接続されますが、トランジット領域として使用されないかもしれません。 しかしながら、NSSA境界ルータによって溯源されたType-7デフォルトLSAがType-5 LSAに決して翻訳されないで、NSSAの内部のAS境界ルータ(NSSA境界ルータでないもの)によって溯源されたType-7デフォルトLSAがType-5 LSAに翻訳されるかもしれないことに注意してください。
Like stub areas, NSSA border routers optionally import summary routes into their NSSAs as Type-3 summary-LSAs. If the import is disabled, particular care should be taken to ensure that summary routing is not obscured by an NSSA's Type-7 AS-external-LSAs. This may happen when the AS's other IGPs, like RIP and ISIS, leak routing information into the NSSA. In these cases all summary routes should be imported into the NSSA. The recommended default behavior is to import summary routes into NSSAs. Since Type-5 AS-external-LSAs are not flooded into NSSAs, NSSA border routers should not originate Type-4 summary- LSAs into their NSSAs. Also an NSSA's border routers never originate Type-4 summary-LSAs for the NSSA's AS boundary routers, since Type-7 AS-external-LSAs are never flooded beyond the NSSA's border.
スタッブ領域のように、NSSA境界ルータはType-3概要-LSAsとして任意に概要ルートをそれらのNSSAsに輸入します。 輸入は障害があるなら、特定の注意が、概要ルーティングがNSSAのType-7 ASの外部のLSAsによってあいまいにされないのを保証するために払われるべきです。 ASの他のIGPsがRIPとイシスのようにルーティング情報をNSSAに漏らすと、これは起こるかもしれません。 これらの場合では、すべての概要ルートをNSSAに輸入するべきです。 お勧めのデフォルトの振舞いは概要ルートをNSSAsに輸入することです。 Type-5 ASの外部のLSAsがNSSAsへあふれないので、NSSA境界ルータはType-4概要LSAsを彼らのNSSAsに溯源するべきではありません。 また、NSSAの境界ルータはNSSAのAS境界ルータのためにType-4概要-LSAsを決して溯源しません、Type-7 ASの外部のLSAsがNSSAの境界を超えて決して水につかっていないので。
When summary routes are not imported into an NSSA, the default LSA originated into it by its border routers must be a Type-3 summary- LSA. This default summary-LSA insures intra-AS connectivity to the rest of the OSPF domain, as its default summary route is preferred over the default route of a Type-7 default LSA. Without a default summary route the OSPF domain's inter-area traffic, which is normally forwarded by summary routes, might exit the AS via the default route of a Type-7 default LSA originated by an NSSA internal router. The Type-7 default LSAs originated by NSSA internal routers and the no- summary option are mutually exclusive features. When summary routes are imported into the NSSA, the default LSA originated by a NSSA border router into the NSSA should be a Type-7 LSA.
概要ルートがいつでないかがType-3概要がLSAであったに違いないなら境界ルータによってそれに溯源されたLSAをNSSA、デフォルトに輸入しました。 このデフォルト概要-LSAはイントラ-ASの接続性をOSPFドメインの残りに保障します、デフォルト概要ルートがType-7デフォルトLSAのデフォルトルートより好まれるように。 デフォルト概要ルートがなければ、OSPFドメインの相互領域交通(通常、概要ルートで進められる)はNSSAの内部のルータによって溯源されたType-7デフォルトLSAのデフォルトルートでASを出るかもしれません。 NSSAの内部のルータによって溯源されたType-7デフォルトLSAsといいえ概要オプションは互いに唯一の特徴です。 概要ルートをNSSAに輸入するとき、NSSA境界ルータによってNSSAに溯源されたデフォルトLSAはType-7 LSAであるべきです。
In our transit topology example the subnets of 130.57 and network 192.31.114 will still be learned by RIP on router BR18, but now both
私たちのトランジットトポロジーの例では、それでも、130.57とネットワーク192.31.114のサブネットはRIPの両方だけによって学習されるでしょう。
Murphy Standards Track [Page 6] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
マーフィーStandardsはOSPFしたがって、短く太くない領域(NSSA)オプション2003年1月にRFC3101を追跡します[6ページ]。
BR10 and BR18 can be in an NSSA and all of BBN Planet's external routes are hidden from BR18; BR10 becomes an NSSA border router and BR18 becomes an AS boundary router internal to the NSSA. BR18 will import the subnets of 130.57 and network 192.31.114 as Type-7 LSAs into the NSSA. BR10 then translates these routes into Type-5 LSAs and floods them into BBN Planet's backbone.
BR10とBR18がNSSAにあることができます、そして、BR18BBN Planetの外部経路のすべてを隠されます。 BR10はNSSA境界ルータになります、そして、BR18はNSSAへの内部のAS境界ルータになります。 BR18はType-7 LSAsとして130.57とネットワーク192.31.114のサブネットをNSSAに輸入するでしょう。 BR10は次に、これらのルートをType-5 LSAsに翻訳して、BBN Planetの背骨へ彼らをあふれさせます。
In our corporate topology example if Area 1 and Area 2 are NSSAs the external paths to the subnets of the address ranges 192.168.192/20 and 192.168.208/22 can be redistributed as Type-7 LSAs throughout Area 1 and Area 2 respectively, and then aggregated during the translation process into separate Type-5 LSAs that are flooded into Area 0. A0 may be configured as Area 1's translator even though B0 is the translator of Area 2.
私たちの法人のトポロジーの例では、Area1とArea2がNSSAsであるならType-7 LSAsとしてArea1とArea2中でそれぞれアドレスの範囲192.168 20と.192/192.168.208/22のサブネットへの外部の経路を再配付できます、そして、Area0はその時、翻訳の過程の間、押し寄せられる別々のType-5 LSAsに集めました。 B0はArea2の翻訳者ですが、A0はArea1の翻訳者として構成されるかもしれません。
2.0 NSSA Intra-Area Implementation Details
2.0 NSSAイントラ領域実現の詳細
2.1 The N-bit
2.1 N-ビット
The N-bit ensures that all members of an NSSA agree on the area's configuration. Together, the N-bit and E-bit reflect an interface's (and consequently the interface's associated area) external LSA flooding capability. As explained in [OSPF] Section 10.5, if Type-5 LSAs are not flooded into/throughout the area, the E-bit must be clear in the option field of the received Hello packets. Interfaces associated with an NSSA will not send or receive Type-5 LSAs on that interface but may send and receive Type-7 LSAs. Therefore, if the N-bit is set in the options field, the E-bit must be clear.
N-ビットは、NSSAのすべてのメンバーが領域の構成に同意するのを確実にします。 N-ビットとE-ビットはインタフェース(そして、その結果インタフェースの関連領域)の外部のLSA氾濫能力を一緒に、反映します。 [OSPF]セクション10.5で説明されるように、Type-5 LSAsが領域中に/へあふれないなら、E-ビットは容認されたHelloパケットのオプション・フィールドで明確であるに違いありません。 NSSAに関連しているインタフェースは、Type-7 LSAsを発信しないか、そのインタフェースでType-5 LSAsを受けますが、送って、または受けるかもしれません。 したがって、N-ビットがオプション分野に設定されるなら、E-ビットは明確であるに違いありません。
To support the NSSA option an additional check must be made in the function that handles the receiving of the Hello packet to verify that both the N-bit and the E-bit found in the Hello packet's option field match the area type and ExternalRoutingCapability of the area of the receiving interface. A mismatch in the options causes processing of the received Hello packet to stop and the packet to be dropped.
NSSAオプションをサポートするために、Helloパケットのオプション・フィールドで見つけられたN-ビットとE-ビットの両方が受信インタフェースの領域の領域のタイプとExternalRoutingCapabilityに合っていることを確かめるためにHelloパケットの受信を扱う機能で追加チェックをしなければなりません。 オプションにおけるミスマッチは止める容認されたHelloパケットとパケットの処理を落とされます。
2.2 Type-7 Address Ranges
2.2 タイプ-7アドレスは及びます。
NSSA border routers may be configured with Type-7 address ranges. Each Type-7 address range is defined as an [address,mask] pair. Many separate Type-7 networks may fall into a single Type-7 address range, just as a subnetted network is composed of many separate subnets. NSSA border routers may aggregate Type-7 routes by advertising a single Type-5 LSA for each Type-7 address range. The Type-5 LSA resulting from a Type-7 address range match will be distributed to all Type-5 capable areas. Section 3.2 details how Type-5 LSAs are generated from Type-7 address ranges.
NSSA境界ルータはType-7アドレスの範囲によって構成されるかもしれません。 それぞれのType-7アドレスの範囲は[アドレス、マスク]組と定義されます。 多くの別々のType-7ネットワークがただ一つのType-7アドレスの範囲に落ちるかもしれません、ちょうどサブネット化したネットワークが多くの別々のサブネットで構成されるように。 NSSA境界ルータは、それぞれのType-7アドレスの範囲に独身のType-5 LSAの広告を出すことによって、Type-7ルートに集められるかもしれません。 Type-7アドレス範囲マッチから生じるType-5 LSAはすべてのType-5のできる領域に分配されるでしょう。 セクション3.2はType-5 LSAsがType-7アドレスの範囲からどう発生するかを詳しく述べます。
Murphy Standards Track [Page 7] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
マーフィーStandardsはOSPFしたがって、短く太くない領域(NSSA)オプション2003年1月にRFC3101を追跡します[7ページ]。
A Type-7 address range includes the following configurable items.
Type-7アドレスの範囲は以下の構成可能な項目を含んでいます。
o An [address,mask] pair.
o [アドレス、マスク]組。
o A status indication of either Advertise or DoNotAdvertise.
o どちらかの状態しるし、広告、または、DoNotAdvertise。
o An external route tag.
o 外部経路タグ。
2.3 Type-7 LSAs
2.3 タイプ-7LSAs
External routes are imported into NSSAs as Type-7 LSAs by NSSA AS boundary routers. An NSSA AS boundary router (ASBR) is a router that has an interface associated with the NSSA and is exchanging routing information with routers belonging to another AS. Like OSPF ASBRs, an NSSA router indicates it is an NSSA ASBR by setting the E-bit in its router-LSA. As with Type-5 LSAs a separate Type-7 LSA is originated for each destination network. To support NSSAs the link- state database must therefore be expanded to contain Type-7 LSAs.
NSSA AS境界ルータはType-7 LSAsとして外部経路をNSSAsに輸入します。 NSSA AS境界ルータ(ASBR)はNSSAに関連しているインタフェースを持って、別のASに属すルータとルーティング情報を交換しているルータです。 OSPF ASBRsのように、NSSAルータは、それがルータ-LSAにE-ビットをはめ込むことによってNSSA ASBRであることを示します。 Type-5 LSAsのように、別々のType-7 LSAは各送信先ネットワークのために溯源されます。 したがって、Type-7 LSAsを含むようにサポートNSSAsへのリンク州のデータベースを広げなければなりません。
Type-7 LSAs are identical to Type-5 LSAs except for the following (see [OSPF] Section 12.4.4, "AS external links").
タイプ-7LSAsが以下を除いたType-5 LSAsと同じです([OSPF]セクション12.4.4、「ASの外部のリンク」を見てください)。
1. The Type field in the LSA header is 7.
1. LSAヘッダーのType分野は7です。
2. Type-7 LSAs are only flooded within the originating NSSA. The
flooding of Type-7 LSAs follows the same rules as the flooding
of Type-1 and Type-2 LSAs.
2. タイプ-7LSAsが由来しているNSSAの中で水につかっているだけです。 Type-7 LSAsの氾濫はType-1とType-2 LSAsの氾濫と同じ規則に続いて起こります。
3. Type-7 LSAs are only listed within the OSPF area data
structures of their respective NSSAs, making them area
specific. Type-5 LSAs, which are flooded to all Type-5 capable
areas, have global scope and are listed in the OSPF protocol
data structure.
3. 彼らを領域特有にして、タイプ-7LSAsしかそれらのそれぞれのNSSAsのOSPF領域データ構造の中に記載されていません。 タイプ-5LSAs(すべてのType-5のできる領域へあふれる)がグローバルな範囲を持って、OSPFプロトコルデータ構造で記載されています。
4. NSSA border routers select which Type-7 LSAs are translated
into Type-5 LSAs and flooded into the OSPF domain's transit
topology.
4. NSSA境界ルータはどのType-7 LSAsがType-5 LSAsに翻訳されて、OSPFドメインのトランジットトポロジーへあふれるかを選択します。
5. Type-7 LSAs have a propagate (P) bit that, when set, tells an
NSSA border router to translate a Type-7 LSA into a Type-5 LSA.
5. タイプ-7LSAsがaに設定されるとType-7 LSAをType-5 LSAに翻訳するようにNSSA境界ルータに言う(P)ビットを伝播させます。
6. Those Type-7 LSAs that are to be translated into Type-5 LSAs
must have their forwarding address set.
6. Type-5 LSAsに翻訳されることになっているそれらのType-7 LSAsは彼らのフォーワーディング・アドレスを設定させなければなりません。
Murphy Standards Track [Page 8] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
マーフィーStandardsはOSPFしたがって、短く太くない領域(NSSA)オプション2003年1月にRFC3101を追跡します[8ページ]。
Type-5 LSAs that are translations of Type-7 LSAs copy the Type-7 LSAs' non-zero forwarding addresses. Only those Type-5 LSAs that are aggregations of Type-7 LSAs may have 0.0.0.0 as a forwarding address. (See Section 3.2 for details.) Non-zero forwarding addresses produce efficient inter-area routing to an NSSA's AS external destinations when it has multiple border routers. Also the non-zero forwarding addresses of Type-7 LSAs ease the process of their translation into Type-5 LSAs, as NSSA border routers are not required to compute them.
Type-7 LSAsに関する翻訳であるタイプ-5LSAsがType-7 LSAsの非ゼロフォーワーディング・アドレスをコピーします。 Type-7 LSAsの集合であるそれらの唯一のType-5 LSAsは0.0に推進としての.0が記述する.0を持っているかもしれません。 (詳細に関してセクション3.2を見てください。) それに複数の境界ルータがあるとき、非ゼロフォーワーディング・アドレスはNSSAのASの外部の目的地に効率的な相互領域ルーティングを作成します。 また、Type-7 LSAsの非ゼロフォーワーディング・アドレスはType-5 LSAsへの彼らの翻訳の過程を緩和します、NSSA境界ルータがそれらを計算するのに必要でないときに。
Normally the next hop address of an installed AS external route learned by an NSSA ASBR from an adjacent AS points at one of the adjacent AS's gateway routers. If this address belongs to a network connected to the NSSA ASBR via one of its NSSAs' active interfaces, then the NSSA ASBR copies this next hop address into the forwarding address field of the route's Type-7 LSA that is originated into this NSSA, as is currently done with Type-5 LSAs. (See [OSPF] Section 12.4.4.1.) For an NSSA with no such network the forwarding address field may only be filled with an address from one of the its active interfaces or 0.0.0.0. If the P-bit is set, the forwarding address must be non-zero; otherwise it may be 0.0.0.0. If an NSSA requires the P-bit be set and a non-zero forwarding address is unavailable, then the route's Type-7 LSA is not originated into this NSSA.
通常、インストールされたAS外部経路の次のホップアドレスは、NSSA ASBRで隣接しているASから、ASのゲートウェイルータが隣接の1つを指していることを学びました。 このアドレスがNSSAsのアクティブなインタフェースの1つを通してNSSA ASBRに接続されたネットワークに属すなら、NSSA ASBRはそのままなこのNSSAに現在Type-5 LSAsと共にしていた状態で溯源されるルートのType-7 LSAの推進アドレス・フィールドにこの次のホップアドレスをコピーします。 (.1に[OSPF]セクション12.4.4を見ます) そのようなネットワークのないNSSAに関して、推進アドレス・フィールドが1からのアドレスで満たされるだけであるかもしれない、アクティブなインタフェースか0.0、.0 .0。 P-ビットが設定されるなら、フォーワーディング・アドレスは非ゼロであるに違いありません。 さもなければ、それはそうです。0.0 .0 .0。 非ゼロフォーワーディング・アドレスが入手できません、NSSAがP-ビットを必要とするなら、設定されてください。そうすれば、次に、ルートのType-7 LSAはこのNSSAに溯源されません。
When a router is forced to pick a forwarding address for a Type-7 LSA, preference should be given first to the router's internal addresses (provided internal addressing is supported). If internal addresses are not available, preference should be given to the router's active OSPF stub network addresses. These choices avoid the possible extra hop that may happen when a transit network's address is used. When the interface whose IP address is the LSA's forwarding address transitions to a Down state (see [OSPF] Section 9.3), the router must select a new forwarding address for the LSA and then re- originate it. If one is not available the LSA should be flushed.
ルータがやむを得ずType-7 LSAのためのフォーワーディング・アドレスを選ぶとき、最初に、ルータの内部のアドレスに優先を与えるべきです(内部のアドレシングが支持されるなら)。 内部のアドレスが利用可能でないなら、ルータのアクティブなOSPFスタッブネットワーク・アドレスに優先を与えるべきです。 これらの選択はトランジットネットワークのアドレスが使用されているとき起こるかもしれない可能な余分なホップを避けます。 IPアドレスがLSAのフォーワーディング・アドレスであるインタフェースがDown状態に移行すると([OSPF]セクション9.3を見てください)、ルータは、LSAのための新しいフォーワーディング・アドレスを選択して、それを再溯源しなければなりません。 1つが利用可能でないなら、LSAは洗い流されるべきです。
The metrics and path types of Type-5 LSAs are directly comparable with the metrics and path types of Type-7 LSAs.
Type-5 LSAsの測定基準と経路タイプは直接Type-7 LSAsの測定基準と経路タイプに匹敵しています。
2.4 Originating Type-7 LSAs
2.4 由来しているタイプ-7LSAs
NSSA AS boundary routers may only originate Type-7 LSAs into NSSAs. An NSSA internal AS boundary router must set the P-bit in the LSA header's option field of any Type-7 LSA whose network it wants advertised into the OSPF domain's full transit topology. The LSAs of these networks must have a valid non-zero forwarding address. If the P-bit is clear the LSA is not translated into a Type-5 LSA by NSSA border routers.
NSSA AS境界ルータはNSSAsにType-7 LSAsを溯源するだけであるかもしれません。 NSSAの内部のAS境界ルータはLSAヘッダーのそれが欲しいネットワークがOSPFドメインの完全なトランジットトポロジーに広告を出したどんなType-7 LSAのオプション・フィールドにもP-ビットをはめ込まなければなりません。 これらのネットワークのLSAsには、有効な非ゼロフォーワーディング・アドレスがなければなりません。 P-ビットが明確であるなら、LSAはNSSA境界ルータによってType-5 LSAに翻訳されません。
Murphy Standards Track [Page 9] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
マーフィーStandardsはOSPFしたがって、短く太くない領域(NSSA)オプション2003年1月にRFC3101を追跡します[9ページ]。
When an NSSA border router originates both a Type-5 LSA and a Type-7 LSA for the same network, then the P-bit must be clear in the Type-7 LSA so that it isn't translated into a Type-5 LSA by another NSSA border router. If the border router only originates a Type-7 LSA, it may set the P-bit so that the network may be aggregated/propagated during Type-7 translation. If an NSSA's border router originates a Type-5 LSA with a forwarding address from the NSSA, it should also originate a Type-7 LSA into the NSSA. If two NSSA routers, both reachable from one another over the NSSA, originate functionally equivalent Type-7 LSAs (i.e., same destination, cost and non-zero forwarding address), then the router having the least preferred LSA should flush its LSA. (See [OSPF] Section 12.4.4.1.) Preference between two Type-7 LSAs is determined by the following tie breaker rules:
NSSA境界ルータが同じネットワークのためにType-5 LSAとType-7 LSAの両方を溯源すると、P-ビットがType-7 LSAで明確であるに違いないので、それは別のNSSA境界ルータによってType-5 LSAに翻訳されません。 境界ルータがType-7 LSAを溯源するだけであるなら、それは、Type-7翻訳の間、ネットワークを集めるか、または伝播できるようにP-ビットを設定するかもしれません。 また、NSSAの境界ルータがNSSAからのフォーワーディング・アドレスでType-5 LSAを溯源するなら、それはNSSAにType-7 LSAを溯源するべきです。 2つのNSSAの上でお互いからともに届いているNSSAルータが機能上同等なType-7 LSAs(すなわち、同じ目的地、費用、および非ゼロフォーワーディング・アドレス)を溯源するなら、持っている中でLSA最も都合のよくないルータはLSAを洗い流すべきです。 (.1に[OSPF]セクション12.4.4を見ます) 2Type-7 LSAsの間の好みは以下のタイブレーク規則で決定します:
1. An LSA with the P-bit set is preferred over one with the P-bit
clear.
1. P-ビットセットがあるLSAはP-ビットが明確の1つより好まれます。
2. If the P-bit settings are the same, the LSA with the higher
router ID is preferred.
2. P-ビット設定が同じであるなら、より高いルータIDがあるLSAは好まれます。
A Type-7 default LSA for the network 0.0.0.0/0 may be originated into the NSSA by any NSSA router. The Type-7 default LSA originated by an NSSA border router must have the P-bit clear. An NSSA ASBR that is not an NSSA border router may originate a Type-7 default LSA with the P-bit set. A Type-7 default LSA may be installed by NSSA border routers if and only if its P-bit is set. (See Appendix E.)
A Type-7 default LSA for the network 0.0.0.0/0 may be originated into the NSSA by any NSSA router. The Type-7 default LSA originated by an NSSA border router must have the P-bit clear. An NSSA ASBR that is not an NSSA border router may originate a Type-7 default LSA with the P-bit set. A Type-7 default LSA may be installed by NSSA border routers if and only if its P-bit is set. (See Appendix E.)
NSSA border routers must originate an LSA for the default destination into all their directly attached NSSAs in order to support intra-AS routing and inter-AS routing. This default destination is advertised in either a Type-3 LSA or a Type-7 LSA, as described in Section 2.7. The default LSA's metric should be configurable. For Type-7 default LSAs, the metric type (1 or 2) should also be configurable.
NSSA border routers must originate an LSA for the default destination into all their directly attached NSSAs in order to support intra-AS routing and inter-AS routing. This default destination is advertised in either a Type-3 LSA or a Type-7 LSA, as described in Section 2.7. The default LSA's metric should be configurable. For Type-7 default LSAs, the metric type (1 or 2) should also be configurable.
2.5 Calculating Type-7 AS External Routes
2.5 Calculating Type-7 AS External Routes
This calculation must be run when Type-7 LSAs are processed during the AS external route calculation. This calculation may process Type-5 LSAs, but it is written that way only for comparison sake.
This calculation must be run when Type-7 LSAs are processed during the AS external route calculation. This calculation may process Type-5 LSAs, but it is written that way only for comparison sake.
Non-default Type-7 LSAs with the P-bit clear may be installed in the OSPF routing table of NSSA border routers. Since these LSAs are not propagated throughout the OSPF domain, traffic that originates external to an NSSA and that passes through one of the NSSA's border routers may be unexpectedly diverted into the NSSA. (See Appendix E.)
Non-default Type-7 LSAs with the P-bit clear may be installed in the OSPF routing table of NSSA border routers. Since these LSAs are not propagated throughout the OSPF domain, traffic that originates external to an NSSA and that passes through one of the NSSA's border routers may be unexpectedly diverted into the NSSA. (See Appendix E.)
Murphy Standards Track [Page 10] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
Murphy Standards Track [Page 10] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
An NSSA border router should examine both Type-5 LSAs and Type-7 LSAs if either Type-5 or Type-7 routes need to be updated or recalculated. This is done as part of the AS external route calculation. An NSSA internal router should examine Type-7 LSAs when Type-7 routes need to be recalculated.
An NSSA border router should examine both Type-5 LSAs and Type-7 LSAs if either Type-5 or Type-7 routes need to be updated or recalculated. This is done as part of the AS external route calculation. An NSSA internal router should examine Type-7 LSAs when Type-7 routes need to be recalculated.
What follows is only a modest modification of [OSPF] Section 16.4. Original paragraphs are tagged with [OSPF]. Paragraphs with minor changes are tagged with ~[OSPF]. Paragraphs specific to NSSA are tagged with [NSSA].
What follows is only a modest modification of [OSPF] Section 16.4. Original paragraphs are tagged with [OSPF]. Paragraphs with minor changes are tagged with ~[OSPF]. Paragraphs specific to NSSA are tagged with [NSSA].
AS external routes are calculated by examining AS-external-LSAs, be they Type-5 or Type-7. Each of the AS-external-LSAs is considered in turn. Most AS-external-LSAs describe routes to specific IP destinations. An AS-external-LSA can also describe a default route for the Autonomous System (Destination ID = DefaultDestination, network/subnet mask = 0x00000000). For each AS-external-LSA: ~[OSPF]
AS external routes are calculated by examining AS-external-LSAs, be they Type-5 or Type-7. Each of the AS-external-LSAs is considered in turn. Most AS-external-LSAs describe routes to specific IP destinations. An AS-external-LSA can also describe a default route for the Autonomous System (Destination ID = DefaultDestination, network/subnet mask = 0x00000000). For each AS-external-LSA: ~[OSPF]
(1) If the metric specified by the LSA is LSInfinity, or if the
age of the LSA equals MaxAge, then examine the next LSA.
[OSPF]
(1) If the metric specified by the LSA is LSInfinity, or if the age of the LSA equals MaxAge, then examine the next LSA. [OSPF]
(2) If the LSA was originated by the calculating router itself,
examine the next LSA.
[OSPF]
(2) If the LSA was originated by the calculating router itself, examine the next LSA. [OSPF]
(3) Call the destination described by the LSA N. N's address is
obtained by masking the LSA's Link State ID with the
network/subnet mask contained in the body of the LSA. Look up
the routing table entries that match the LSA's type for the AS
boundary router (ASBR) that originated the LSA. For a Type-5
LSA, routing table entries may only be selected from each
attached Type-5 capable area. Since the flooding scope of a
Type-7 LSA is restricted to the originating NSSA, the routing
table entry of its ASBR must be found in the originating NSSA.
If no entries exist for the ASBR (i.e. the ASBR is unreachable
over the transit topology for a Type-5 LSA, or, for a Type-7
LSA, it is unreachable over the LSA's originating NSSA), do
nothing with this LSA and consider the next in the list.
[NSSA]
(3) Call the destination described by the LSA N. N's address is obtained by masking the LSA's Link State ID with the network/subnet mask contained in the body of the LSA. Look up the routing table entries that match the LSA's type for the AS boundary router (ASBR) that originated the LSA. For a Type-5 LSA, routing table entries may only be selected from each attached Type-5 capable area. Since the flooding scope of a Type-7 LSA is restricted to the originating NSSA, the routing table entry of its ASBR must be found in the originating NSSA. If no entries exist for the ASBR (i.e. the ASBR is unreachable over the transit topology for a Type-5 LSA, or, for a Type-7 LSA, it is unreachable over the LSA's originating NSSA), do nothing with this LSA and consider the next in the list. [NSSA]
Else if the destination is a Type-7 default route (destination
ID = DefaultDestination) and one of the following is true,
then do nothing with this LSA and consider the next in the
list:
Else if the destination is a Type-7 default route (destination ID = DefaultDestination) and one of the following is true, then do nothing with this LSA and consider the next in the list:
Murphy Standards Track [Page 11] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
Murphy Standards Track [Page 11] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
o The calculating router is a border router and the LSA has
its P-bit clear. Appendix E describes a technique
whereby an NSSA border router installs a Type-7 default
LSA without propagating it.
o The calculating router is a border router and the LSA has its P-bit clear. Appendix E describes a technique whereby an NSSA border router installs a Type-7 default LSA without propagating it.
o The calculating router is a border router and is
suppressing the import of summary routes as Type-3
summary-LSAs.
[NSSA]
o The calculating router is a border router and is suppressing the import of summary routes as Type-3 summary-LSAs. [NSSA]
Else, this LSA describes an AS external path to destination N.
Examine the forwarding address specified in the AS-external-
LSA. This indicates the IP address to which packets for the
destination should be forwarded.
[OSPF]
Else, this LSA describes an AS external path to destination N. Examine the forwarding address specified in the AS-external- LSA. This indicates the IP address to which packets for the destination should be forwarded. [OSPF]
If the forwarding address is set to 0.0.0.0 then packets
should be sent to the ASBR itself. If the LSA is Type-5, from
among the multiple non-NSSA routing table entries for the ASBR
(both NSSA and non-NSSA ASBR entries might exists on an NSSA
border router), select the preferred entry as follows:
~[OSPF]
If the forwarding address is set to 0.0.0.0 then packets should be sent to the ASBR itself. If the LSA is Type-5, from among the multiple non-NSSA routing table entries for the ASBR (both NSSA and non-NSSA ASBR entries might exists on an NSSA border router), select the preferred entry as follows: ~[OSPF]
If RFC1583Compatibility is set to "disabled", prune the set
of routing table entries for the ASBR as described in OSPF
Section 16.4.1. In any case, among the remaining routing
table entries, select the routing table entry with the least
cost; when there are multiple least cost routing table
entries the entry whose associated area has the largest OSPF
Area ID (when considered as an unsigned 32-bit integer) is
chosen.
[OSPF]
If RFC1583Compatibility is set to "disabled", prune the set of routing table entries for the ASBR as described in OSPF Section 16.4.1. In any case, among the remaining routing table entries, select the routing table entry with the least cost; when there are multiple least cost routing table entries the entry whose associated area has the largest OSPF Area ID (when considered as an unsigned 32-bit integer) is chosen. [OSPF]
Since a Type-7 LSA only has area-wide flooding scope, when its
forwarding address is set to 0.0.0.0, its ASBR's routing table
entry must be chosen from the originating NSSA. Here no
pruning is necessary since this entry always contains non-
backbone intra-area paths.
[NSSA]
Since a Type-7 LSA only has area-wide flooding scope, when its forwarding address is set to 0.0.0.0, its ASBR's routing table entry must be chosen from the originating NSSA. Here no pruning is necessary since this entry always contains non- backbone intra-area paths. [NSSA]
If the forwarding address is non-zero look up the forwarding
address in the routing table. For a Type-5 LSA the matching
routing table entry must specify an intra-area or inter-area
path through a Type-5 capable area. For a Type-7 LSA the
matching routing table entry must specify an intra-area path
through the LSA's originating NSSA. If no such path exists
If the forwarding address is non-zero look up the forwarding address in the routing table. For a Type-5 LSA the matching routing table entry must specify an intra-area or inter-area path through a Type-5 capable area. For a Type-7 LSA the matching routing table entry must specify an intra-area path through the LSA's originating NSSA. If no such path exists
Murphy Standards Track [Page 12] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
Murphy Standards Track [Page 12] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
then do nothing with this LSA and consider the next in the
list.
[NSSA]
then do nothing with this LSA and consider the next in the list. [NSSA]
(4) Let X be the cost specified by the preferred routing table
entry for the ASBR/forwarding address, and Y the cost
specified in the LSA. X is in terms of the link state metric,
and Y is a type 1 or 2 external metric.
[OSPF]
(4) Let X be the cost specified by the preferred routing table entry for the ASBR/forwarding address, and Y the cost specified in the LSA. X is in terms of the link state metric, and Y is a type 1 or 2 external metric. [OSPF]
(5) Now, look up the routing table entry for the destination N.
If no entry exists for N, install the AS external path to N,
with the next hop equal to the list of next hops to the
ASBR/forwarding address, and advertising router equal to the
ASBR. If the external metric type is 1, then the path-type is
set to Type-1 external and the cost is equal to X + Y. If the
external metric type is 2, the path-type is set to Type-2
external, the link-state component of the route's cost is X,
and the type 2 cost is Y.
[OSPF]
(5) Now, look up the routing table entry for the destination N. If no entry exists for N, install the AS external path to N, with the next hop equal to the list of next hops to the ASBR/forwarding address, and advertising router equal to the ASBR. If the external metric type is 1, then the path-type is set to Type-1 external and the cost is equal to X + Y. If the external metric type is 2, the path-type is set to Type-2 external, the link-state component of the route's cost is X, and the type 2 cost is Y. [OSPF]
(6) Otherwise compare the AS external path described by the LSA
with the existing paths in N's routing table entry. If the
new path is preferred, it replaces the present paths in N's
routing table entry. If the new path is of equal preference,
it is added to the present paths in N's routing table entry.
[OSPF]
(6) Otherwise compare the AS external path described by the LSA with the existing paths in N's routing table entry. If the new path is preferred, it replaces the present paths in N's routing table entry. If the new path is of equal preference, it is added to the present paths in N's routing table entry. [OSPF]
Preference is defined as follows:
Preference is defined as follows:
(a) Intra-area and inter-area paths are always preferred over
AS external paths.
[OSPF]
(a) Intra-area and inter-area paths are always preferred over AS external paths. [OSPF]
(b) Type 1 external paths are always preferred over type 2
external paths. When all paths are type 2 external paths,
the paths with the smallest advertised type 2 metric are
always preferred.
[OSPF]
(b) Type 1 external paths are always preferred over type 2 external paths. When all paths are type 2 external paths, the paths with the smallest advertised type 2 metric are always preferred. [OSPF]
(c) If the new AS external path is still indistinguishable
from the current paths in N's routing table entry, and
RFC1583Compatibility is set to "disabled", select the
preferred paths based on the intra-AS paths to the
ASBR/forwarding addresses, as specified in Section 16.4.1.
Here intra-NSSA paths are equivalent to the intra-area
paths of non-backbone regular OSPF areas.
[NSSA]
(c) If the new AS external path is still indistinguishable from the current paths in N's routing table entry, and RFC1583Compatibility is set to "disabled", select the preferred paths based on the intra-AS paths to the ASBR/forwarding addresses, as specified in Section 16.4.1. Here intra-NSSA paths are equivalent to the intra-area paths of non-backbone regular OSPF areas. [NSSA]
Murphy Standards Track [Page 13] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
Murphy Standards Track [Page 13] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
(d) If the new AS external path is still indistinguishable
from the current paths in N's routing table entry, select
the preferred path based on a least cost comparison. Type
1 external paths are compared by looking at the sum of the
distance to the ASBR/forwarding addresses and the
advertised type 1 metric (X+Y). Type 2 external paths
advertising equal type 2 metrics are compared by looking
at the distance to the ASBR/forwarding addresses.
~[OSPF]
(d) If the new AS external path is still indistinguishable from the current paths in N's routing table entry, select the preferred path based on a least cost comparison. Type 1 external paths are compared by looking at the sum of the distance to the ASBR/forwarding addresses and the advertised type 1 metric (X+Y). Type 2 external paths advertising equal type 2 metrics are compared by looking at the distance to the ASBR/forwarding addresses. ~[OSPF]
(e) If the current LSA is functionally the same as an
installed LSA (i.e., same destination, cost and non-zero
forwarding address) then apply the following priorities in
deciding which LSA is preferred:
(e) If the current LSA is functionally the same as an installed LSA (i.e., same destination, cost and non-zero forwarding address) then apply the following priorities in deciding which LSA is preferred:
1. A Type-7 LSA with the P-bit set.
1. A Type-7 LSA with the P-bit set.
2. A Type-5 LSA.
2. A Type-5 LSA.
3. The LSA with the higher router ID.
3. The LSA with the higher router ID.
[NSSA]
[NSSA]
2.6 Incremental Updates
2.6 Incremental Updates
Incremental updates for Type-7 LSAs should be treated the same as incremental updates for Type-5 LSAs (see [OSPF] Section 16.6). When a new instance of a Type-7 LSA is received it is not necessary to recalculate the entire routing table. Call the destination described by the Type-7 LSA N. N's address is obtained by masking the LSA's Link State ID with the network/subnet mask contained in the body of the LSA. If there is already an intra-area or inter-area route to the destination, no recalculation is necessary (internal routes take precedence).
Incremental updates for Type-7 LSAs should be treated the same as incremental updates for Type-5 LSAs (see [OSPF] Section 16.6). When a new instance of a Type-7 LSA is received it is not necessary to recalculate the entire routing table. Call the destination described by the Type-7 LSA N. N's address is obtained by masking the LSA's Link State ID with the network/subnet mask contained in the body of the LSA. If there is already an intra-area or inter-area route to the destination, no recalculation is necessary (internal routes take precedence).
Otherwise, the procedure in the preceding section will have to be performed but only for the external routes (Type-5 and Type-7) whose destination is N. Before this procedure is performed, the present routing table entry for N should be invalidated.
Otherwise, the procedure in the preceding section will have to be performed but only for the external routes (Type-5 and Type-7) whose destination is N. Before this procedure is performed, the present routing table entry for N should be invalidated.
2.7 Optionally Importing Summary Routes
2.7 Optionally Importing Summary Routes
In order for OSPF's summary routing to not be obscured by an NSSA's Type-7 AS-external-LSAs, all NSSA border router implementations must support the optional import of summary routes into NSSAs as Type-3 summary-LSAs. The default behavior is to import summary routes. A new area configuration parameter, ImportSummaries, is defined in Appendix D. When ImportSummaries is set to enabled, summary routes
In order for OSPF's summary routing to not be obscured by an NSSA's Type-7 AS-external-LSAs, all NSSA border router implementations must support the optional import of summary routes into NSSAs as Type-3 summary-LSAs. The default behavior is to import summary routes. A new area configuration parameter, ImportSummaries, is defined in Appendix D. When ImportSummaries is set to enabled, summary routes
Murphy Standards Track [Page 14] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
Murphy Standards Track [Page 14] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
are imported. When it is set to disabled, summary routes are not imported. The default setting is enabled.
are imported. When it is set to disabled, summary routes are not imported. The default setting is enabled.
When OSPF's summary routes are not imported, the default LSA originated by an NSSA border router into the NSSA should be a Type-3 summary-LSA. This protects the NSSA from routing intra-AS traffic out the AS via the default route of a Type-7 default LSA originating from one of the NSSA's internal routers. When summary routes are imported into the NSSA, the default LSA originated by an NSSA border router must not be a Type-3 summary-LSA; otherwise its default route would be chosen over the potentially more preferred default routes of Type-7 default LSAs.
When OSPF's summary routes are not imported, the default LSA originated by an NSSA border router into the NSSA should be a Type-3 summary-LSA. This protects the NSSA from routing intra-AS traffic out the AS via the default route of a Type-7 default LSA originating from one of the NSSA's internal routers. When summary routes are imported into the NSSA, the default LSA originated by an NSSA border router must not be a Type-3 summary-LSA; otherwise its default route would be chosen over the potentially more preferred default routes of Type-7 default LSAs.
3.0 Intra-AS Implementation Details
3.0 Intra-AS Implementation Details
3.1 Type-7 Translator Election
3.1 Type-7 Translator Election
It is not recommended that multiple NSSA border routers perform Type-7 to Type-5 translation unless it is required to route packets efficiently through Area 0 to an NSSA partitioned by Type-7 address ranges. It is normally sufficient to have only one NSSA border router perform the translation. Excessive numbers of Type-7 translators unnecessarily increase the size of the OSPF link state data base.
It is not recommended that multiple NSSA border routers perform Type-7 to Type-5 translation unless it is required to route packets efficiently through Area 0 to an NSSA partitioned by Type-7 address ranges. It is normally sufficient to have only one NSSA border router perform the translation. Excessive numbers of Type-7 translators unnecessarily increase the size of the OSPF link state data base.
A new area configuration parameter, NSSATranslatorRole, is defined in Appendix D. It specifies whether or not an NSSA router will unconditionally translate Type-7 LSAs to Type-5 LSAs when acting as an NSSA border router. Configuring the identity of the translator can be used to bias the routing to aggregated destinations. When NSSATranslatorRole is set to Always, Type-7 LSAs are always translated regardless of the translator state of other NSSA border routers. When NSSATranslatorRole is set to Candidate an NSSA border router will participate in the translator election process described below.
A new area configuration parameter, NSSATranslatorRole, is defined in Appendix D. It specifies whether or not an NSSA router will unconditionally translate Type-7 LSAs to Type-5 LSAs when acting as an NSSA border router. Configuring the identity of the translator can be used to bias the routing to aggregated destinations. When NSSATranslatorRole is set to Always, Type-7 LSAs are always translated regardless of the translator state of other NSSA border routers. When NSSATranslatorRole is set to Candidate an NSSA border router will participate in the translator election process described below.
A new area parameter, NSSATranslatorState, is maintained in an NSSA's OSPF area data structure. By default all NSSA routers initialize NSSATranslatorState to disabled. When an NSSA border router's NSSATranslatorState changes from disabled to either enabled or elected, it begins translating the NSSA's Type-7 LSAs into Type-5 LSAs. When its NSSATranslatorState changes from either enabled or elected to disabled, it ceases translating the NSSA's Type-7 LSAs into Type-5 LSAs. (See paragraphs below.)
A new area parameter, NSSATranslatorState, is maintained in an NSSA's OSPF area data structure. By default all NSSA routers initialize NSSATranslatorState to disabled. When an NSSA border router's NSSATranslatorState changes from disabled to either enabled or elected, it begins translating the NSSA's Type-7 LSAs into Type-5 LSAs. When its NSSATranslatorState changes from either enabled or elected to disabled, it ceases translating the NSSA's Type-7 LSAs into Type-5 LSAs. (See paragraphs below.)
A new bit, Nt, is defined for the router-LSAs of NSSAs. (See Appendix B.) By default routers clear bit Nt when originating router-LSAs. However, when an NSSA border router has its
A new bit, Nt, is defined for the router-LSAs of NSSAs. (See Appendix B.) By default routers clear bit Nt when originating router-LSAs. However, when an NSSA border router has its
Murphy Standards Track [Page 15] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
Murphy Standards Track [Page 15] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
NSSATranslatorState enabled, it sets bit Nt in the router-LSA it originates into the NSSA. An NSSA router whose NSSATranslatorRole is set to Always should re-originate a router-LSA into the NSSA whenever its NSSATranslatorState changes.
NSSATranslatorState enabled, it sets bit Nt in the router-LSA it originates into the NSSA. An NSSA router whose NSSATranslatorRole is set to Always should re-originate a router-LSA into the NSSA whenever its NSSATranslatorState changes.
When an NSSA router with the NSSA's NSSATranslatorRole set to Always attains border router status, it should change NSSATranslatorState from disabled to enabled. When it loses border router status, it should change NSSATranslatorState from enabled to disabled.
When an NSSA router with the NSSA's NSSATranslatorRole set to Always attains border router status, it should change NSSATranslatorState from disabled to enabled. When it loses border router status, it should change NSSATranslatorState from enabled to disabled.
All NSSA border routers must set the E-bit in the Type-1 router-LSAs of their directly attached non-stub areas, even when they are not translating. This allows other NSSA border routers to see their ASBR status across the AS's transit topology. Failure to do so may cause the election algorithm to elect unnecessary translators. Every NSSA border router is a potential translator.
All NSSA border routers must set the E-bit in the Type-1 router-LSAs of their directly attached non-stub areas, even when they are not translating. This allows other NSSA border routers to see their ASBR status across the AS's transit topology. Failure to do so may cause the election algorithm to elect unnecessary translators. Every NSSA border router is a potential translator.
An NSSA border router whose NSSA's NSSATranslatorRole is set to Candidate must maintain a list of the NSSA's border routers that are reachable both over the NSSA and as ASBRs over the AS's transit topology. Any change in this list, or to the Nt bit settings of members of this list, causes the NSSA border router to reevaluate its NSSATranslatorState. If there exists another border router in this list whose router-LSA has bit Nt set or who has a higher router ID, then its NSSATranslatorState is disabled. Otherwise its NSSATranslatorState is elected.
An NSSA border router whose NSSA's NSSATranslatorRole is set to Candidate must maintain a list of the NSSA's border routers that are reachable both over the NSSA and as ASBRs over the AS's transit topology. Any change in this list, or to the Nt bit settings of members of this list, causes the NSSA border router to reevaluate its NSSATranslatorState. If there exists another border router in this list whose router-LSA has bit Nt set or who has a higher router ID, then its NSSATranslatorState is disabled. Otherwise its NSSATranslatorState is elected.
An elected translator will continue to perform translation duties until supplanted by a reachable NSSA border router whose Nt bit is set or whose router ID is greater. Such an event may happen when an NSSA router with NSSATranslatorRole set to Always regains border router status, or when a partitioned NSSA becomes whole. If an elected translator determines its services are no longer required, it continues to perform its translation duties for the additional time interval defined by a new area configuration parameter, TranslatorStabilityInterval. This minimizes excessive flushing of translated Type-7 LSAs and provides for a more stable translator transition. The default value for the TranslatorStabilityInterval parameter has been defined as 40 seconds. (See Appendix D.)
An elected translator will continue to perform translation duties until supplanted by a reachable NSSA border router whose Nt bit is set or whose router ID is greater. Such an event may happen when an NSSA router with NSSATranslatorRole set to Always regains border router status, or when a partitioned NSSA becomes whole. If an elected translator determines its services are no longer required, it continues to perform its translation duties for the additional time interval defined by a new area configuration parameter, TranslatorStabilityInterval. This minimizes excessive flushing of translated Type-7 LSAs and provides for a more stable translator transition. The default value for the TranslatorStabilityInterval parameter has been defined as 40 seconds. (See Appendix D.)
3.2 Translating Type-7 LSAs into Type-5 LSAs
3.2 Translating Type-7 LSAs into Type-5 LSAs
This step is performed as part of the NSSA's Dijkstra calculation after Type-5 and Type-7 routes have been calculated. If the calculating router is currently not an NSSA border router translator, then this translation algorithm should be skipped. Only installed
This step is performed as part of the NSSA's Dijkstra calculation after Type-5 and Type-7 routes have been calculated. If the calculating router is currently not an NSSA border router translator, then this translation algorithm should be skipped. Only installed
Murphy Standards Track [Page 16] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
Murphy Standards Track [Page 16] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
Type-7 LSAs and those non-default Type-7 LSAs originated by the router itself should be examined. Locally sourced Type-7 LSAs should be processed first.
Type-7 LSAs and those non-default Type-7 LSAs originated by the router itself should be examined. Locally sourced Type-7 LSAs should be processed first.
Note that it is possible for a Type-5 LSA generated by translation to supplant a Type-5 LSA originating from a local OSPF external source. Future reoriginations of the locally sourced Type-5 LSA should be suppressed until the Type-5 LSA generated by translation is flushed.
Note that it is possible for a Type-5 LSA generated by translation to supplant a Type-5 LSA originating from a local OSPF external source. Future reoriginations of the locally sourced Type-5 LSA should be suppressed until the Type-5 LSA generated by translation is flushed.
A Type-7 LSA and a Type-7 address range best match one another if there does not exist a more specific Type-7 address range that contains the LSA's network. For each eligible Type-7 LSA perform the following:
A Type-7 LSA and a Type-7 address range best match one another if there does not exist a more specific Type-7 address range that contains the LSA's network. For each eligible Type-7 LSA perform the following:
(1) If the Type-7 LSA has the P-bit clear, or its forwarding
address is set to 0.0.0.0, or the most specific Type-7 address
range that subsumes the LSA's network has DoNotAdvertise
status, then do nothing with this Type-7 LSA and consider the
next one in the list. Otherwise term the LSA as translatable
and proceed with step (2).
(1) If the Type-7 LSA has the P-bit clear, or its forwarding address is set to 0.0.0.0, or the most specific Type-7 address range that subsumes the LSA's network has DoNotAdvertise status, then do nothing with this Type-7 LSA and consider the next one in the list. Otherwise term the LSA as translatable and proceed with step (2).
(2) If the Type-7 LSA is not contained in any explicitly
configured Type-7 address range and the calculating router has
the highest router ID amongst NSSA translators that have
originated a functionally equivalent Type-5 LSA (i.e. same
destination, cost and non-zero forwarding address) and that
are reachable over area 0 and the NSSA, then a Type-5 LSA
should be generated if there is currently no Type-5 LSA
originating from this router corresponding to the Type-7 LSA's
network, or there is an existing Type-5 LSA and either it
corresponds to a local OSPF external source whose path type
and metric is less preferred (see Section 2.5 step (6), parts
(b) and (d)), or it doesn't and the Type-5 LSA's path type or
cost(s) have changed (See Section 2.5 step (5)) or the
forwarding address no longer maps to a translatable Type-7
LSA.
(2) If the Type-7 LSA is not contained in any explicitly configured Type-7 address range and the calculating router has the highest router ID amongst NSSA translators that have originated a functionally equivalent Type-5 LSA (i.e. same destination, cost and non-zero forwarding address) and that are reachable over area 0 and the NSSA, then a Type-5 LSA should be generated if there is currently no Type-5 LSA originating from this router corresponding to the Type-7 LSA's network, or there is an existing Type-5 LSA and either it corresponds to a local OSPF external source whose path type and metric is less preferred (see Section 2.5 step (6), parts (b) and (d)), or it doesn't and the Type-5 LSA's path type or cost(s) have changed (See Section 2.5 step (5)) or the forwarding address no longer maps to a translatable Type-7 LSA.
The newly originated Type-5 LSA will describe the same network
and have the same network mask, path type, metric, forwarding
address and external route tag as the Type-7 LSA. The
advertising router field will be the router ID of this NSSA
border router. The link-state ID is equal to the LSA's
network address (in the case of multiple originations of
Type-5 LSAs with the same network address but different mask,
the link-state ID can also have one or more of the network's
"host" bits set).
The newly originated Type-5 LSA will describe the same network and have the same network mask, path type, metric, forwarding address and external route tag as the Type-7 LSA. The advertising router field will be the router ID of this NSSA border router. The link-state ID is equal to the LSA's network address (in the case of multiple originations of Type-5 LSAs with the same network address but different mask, the link-state ID can also have one or more of the network's "host" bits set).
Murphy Standards Track [Page 17] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
Murphy Standards Track [Page 17] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
(3) Else the Type-7 LSA must be aggregated by the most specific
Type-7 address range that subsumes it. If this Type-7 address
range has the same [address,mask] pair as the LSA's network
and no other translatable Type-7 LSA with a different network
best matches this range, then flag the LSA as not contained in
any explicitly configured Type-7 address range and process the
LSA as described in step (2). Otherwise compute the path type
and metric for this Type-7 address range as described below.
(3) Else the Type-7 LSA must be aggregated by the most specific Type-7 address range that subsumes it. If this Type-7 address range has the same [address,mask] pair as the LSA's network and no other translatable Type-7 LSA with a different network best matches this range, then flag the LSA as not contained in any explicitly configured Type-7 address range and process the LSA as described in step (2). Otherwise compute the path type and metric for this Type-7 address range as described below.
The path type and metric of the Type-7 address range is
determined from the path types and metrics of those
translatable Type-7 LSAs that best match the range plus any
locally sourced Type-5 LSAs whose network has the same
[address,mask] pair. If any of these LSAs have a path type of
2, the range's path type is 2, otherwise it is 1. If the
range's path type is 1 its metric is the highest cost amongst
these LSAs; if the range's path type is 2 its metric is the
highest Type-2 cost + 1 amongst these LSAs. (See Section 2.5
step (5).) 1 is added to the Type-2 cost to ensure that the
translated Type-5 LSA does not appear closer on the NSSA
border than a translatable Type-7 LSA whose network has the
same [address,mask] pair and Type-2 cost.
The path type and metric of the Type-7 address range is determined from the path types and metrics of those translatable Type-7 LSAs that best match the range plus any locally sourced Type-5 LSAs whose network has the same [address,mask] pair. If any of these LSAs have a path type of 2, the range's path type is 2, otherwise it is 1. If the range's path type is 1 its metric is the highest cost amongst these LSAs; if the range's path type is 2 its metric is the highest Type-2 cost + 1 amongst these LSAs. (See Section 2.5 step (5).) 1 is added to the Type-2 cost to ensure that the translated Type-5 LSA does not appear closer on the NSSA border than a translatable Type-7 LSA whose network has the same [address,mask] pair and Type-2 cost.
A Type-5 LSA is generated from the Type-7 address range when
there is currently no Type-5 LSA originated by this router
whose network has the same [address,mask] pair as the range or
there is but either its path type or metric has changed or its
forwarding address is non-zero.
A Type-5 LSA is generated from the Type-7 address range when there is currently no Type-5 LSA originated by this router whose network has the same [address,mask] pair as the range or there is but either its path type or metric has changed or its forwarding address is non-zero.
The newly generated Type-5 LSA will have a link-state ID equal
to the Type-7 address range's address (in the case of multiple
originations of Type-5 LSAs with the same network address but
different mask, the link-state ID can also have one or more of
the range's "host" bits set). The advertising router field
will be the router ID of this area border router. The network
mask and the external route tag are set to the range's
configured values. The forwarding address is set to 0.0.0.0.
The path type and metric are set to the range's path type and
metric as defined and computed above.
The newly generated Type-5 LSA will have a link-state ID equal to the Type-7 address range's address (in the case of multiple originations of Type-5 LSAs with the same network address but different mask, the link-state ID can also have one or more of the range's "host" bits set). The advertising router field will be the router ID of this area border router. The network mask and the external route tag are set to the range's configured values. The forwarding address is set to 0.0.0.0. The path type and metric are set to the range's path type and metric as defined and computed above.
The pending processing of other translation eligible Type-7
LSAs that best match this Type-7 address range is suppressed.
Thus at most a single Type-5 LSA is originated for each Type-7
address range.
The pending processing of other translation eligible Type-7 LSAs that best match this Type-7 address range is suppressed. Thus at most a single Type-5 LSA is originated for each Type-7 address range.
Murphy Standards Track [Page 18] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
Murphy Standards Track [Page 18] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
For example, given a Type-7 address range of [10.0.0.0, 255.0.0.0] that subsumes the following Type-7 routes:
For example, given a Type-7 address range of [10.0.0.0, 255.0.0.0] that subsumes the following Type-7 routes:
10.1.0.0/24 path type 1, cost 10
10.2.0.0/24 path type 1, cost 11
10.3.0.0/24 path type 2, type 2 cost 5
10.1.0.0/24 path type 1, cost 10 10.2.0.0/24 path type 1, cost 11 10.3.0.0/24 path type 2, type 2 cost 5
a Type-5 LSA would be generated with a path type of 2 and a metric 6.
a Type-5 LSA would be generated with a path type of 2 and a metric 6.
Given a Type-7 address range of [10.0.0.0, 255.0.0.0] that subsumes the following Type-7 routes:
Given a Type-7 address range of [10.0.0.0, 255.0.0.0] that subsumes the following Type-7 routes:
10.1.0.0/24 path type 1, cost 10
10.2.0.0/24 path type 1, cost 11
10.3.0.0/24 path type 1, cost 5
10.1.0.0/24 path type 1, cost 10 10.2.0.0/24 path type 1, cost 11 10.3.0.0/24 path type 1, cost 5
a Type-5 LSA will be generated with a path type of 1 and a metric 11.
a Type-5 LSA will be generated with a path type of 1 and a metric 11.
These Type-7 address range metric and path type rules will avoid routing loops in the event that path types 1 and 2 are both used within the area.
These Type-7 address range metric and path type rules will avoid routing loops in the event that path types 1 and 2 are both used within the area.
As with all newly originated Type-5 LSAs, a Type-5 LSA that is the result of a Type-7 LSA translation or aggregation is flooded to all attached Type-5 capable areas.
As with all newly originated Type-5 LSAs, a Type-5 LSA that is the result of a Type-7 LSA translation or aggregation is flooded to all attached Type-5 capable areas.
Like Type-3 address ranges, a Type-7 address range performs the dual function of setting propagation policy via its Advertise/DoNotAdvertise parameter and aggregation via its network address and mask pair. Unlike the origination of Type-3 summary-LSAs, the translation of a Type-7 LSA into a Type-5 LSA may result in more efficient routing when the forwarding address is set, as is done during step (2) of the translation procedure.
Like Type-3 address ranges, a Type-7 address range performs the dual function of setting propagation policy via its Advertise/DoNotAdvertise parameter and aggregation via its network address and mask pair. Unlike the origination of Type-3 summary-LSAs, the translation of a Type-7 LSA into a Type-5 LSA may result in more efficient routing when the forwarding address is set, as is done during step (2) of the translation procedure.
Another important feature of this translation process is that it allows a Type-7 address range to apply different properties (aggregation, forwarding address, and Advertise/DoNotAdvertise status) for the Type-7 routes it subsumes, versus those Type-7 routes subsumed by other more specific Type-7 address ranges contained in the Type-7 address range.
Another important feature of this translation process is that it allows a Type-7 address range to apply different properties (aggregation, forwarding address, and Advertise/DoNotAdvertise status) for the Type-7 routes it subsumes, versus those Type-7 routes subsumed by other more specific Type-7 address ranges contained in the Type-7 address range.
3.3 Flushing Translated Type-7 LSAs
3.3 Flushing Translated Type-7 LSAs
If an NSSA border router has either translated or aggregated an installed Type-7 LSA into a Type-5 LSA that should no longer be translated or aggregated, then the Type-5 LSA should either be flushed or reoriginated as a translation or aggregation of other Type-7 LSAs.
NSSA境界ルータが翻訳するか、またはもう翻訳されるべきではありませんし、また集められるべきでないType-5 LSAへのインストールされたType-7 LSAに集めてあるなら、Type-5 LSAは他のType-7 LSAsの翻訳か集合として洗い流されるべきであるか、または再由来されるべきです。
Murphy Standards Track [Page 19] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
マーフィーStandardsはOSPFしたがって、短く太くない領域(NSSA)オプション2003年1月にRFC3101を追跡します[19ページ]。
If an NSSA border router is translating Type-7 LSA's into Type-5 LSA's with NSSATranslatorState set to elected and the NSSA border router has determined that its translator election status has been deposed by another NSSA border router (see Section 3.1), then, as soon as the TranslatorStabilityInterval has expired without the router reelecting itself as a translator, Type-5 LSAs that are generated by aggregating Type-7 LSAs into their best matched Type-7 address ranges (see Section 3.2, Step (3)) are flushed. Conversely Type-5 LSAs generated by translating Type-7 LSAs are not immediately flushed, but are allowed to remain in the OSPF routing domain as if the originator is still an elected translator. This minimizes the flushing and flooding impact on the transit topology of an NSSA that changes its translators frequently.
NSSA境界ルータが翻訳されているなら、NSSATranslatorStateがあるType-5 LSAのものへのType-7 LSAは選出されるのにセットしました、そして、NSSA境界ルータは翻訳者選挙状態を別のNSSA境界ルータによって口供されたことを決定しました(セクション3.1を見てください)、そして; TranslatorStabilityIntervalが翻訳者としてルータ改選自体なしで期限が切れるとすぐに、Type-7 LSAsに集めることによって彼らの最も良い取り組んでいるType-7に発生するType-5 LSAsは範囲を記述します。(セクション3.2(洗い流されたStep(3)))を見てください。 逆に、Type-7 LSAsを翻訳することによって発生するType-5 LSAsはすぐに洗い流されませんが、まるで創始者が選出された翻訳者であるかのようにOSPF経路ドメインに残ることができます。 これは頻繁に翻訳者を変えるNSSAのトランジットトポロジーへの洗い流すのと氾濫影響を最小にします。
4.0 Security Considerations
4.0 セキュリティ問題
There are two types of issues that need be addressed when looking at protecting routing protocols from misconfigurations and malicious attacks. The first is authentication and certification of routing protocol information. The second is denial of service attacks resulting from repetitive origination of the same router advertisement or origination of a large number of distinct advertisements resulting in database overflow. Note that both of these concerns exist independently of a router's support for the NSSA option.
misconfigurationsと悪意ある攻撃からルーティング・プロトコルを保護するのを検討するとき記述されなければならない2つのタイプの問題があります。 1番目は、ルーティングプロトコル情報の認証と証明です。 2番目は同じルータ通知の反復性の創作かデータベースオーバーフローをもたらす多くの異なった広告の創作から生じるサービス不能攻撃です。 これらの関心の両方がルータのNSSAオプションのサポートの如何にかかわらず存在することに注意してください。
The OSPF protocol addresses authentication concerns by authenticating OSPF protocol exchanges. OSPF supports multiple types of authentication; the type of authentication in use can be configured on a per network segment basis. One of OSPF's authentication types, namely the Cryptographic authentication option, is believed to be secure against passive attacks and provides significant protection against active attacks. When using the Cryptographic authentication option, each router appends a "message digest" to its transmitted OSPF packets. Receivers then use the shared secret key and the received digest to verify that each received OSPF packet is authentic.
OSPFプロトコルは、OSPFプロトコル交換を認証することによって、認証関心を記述します。 OSPFは複数のタイプの認証を支持します。 ネットワークセグメント基礎あたりのaで使用中の認証のタイプを構成できます。 OSPFの認証タイプのひとり(すなわち、Cryptographic認証オプション)は、受け身の攻撃に対して安全であると信じられていて、活発な攻撃に対する重要な保護を前提とします。 Cryptographic認証オプションを使用するとき、各ルータは「メッセージダイジェスト」を伝えられたOSPFパケットに追加します。 そして、受信機は、それぞれの容認されたOSPFパケットが正統であることを確かめるのに共有された秘密鍵と受け取られていているダイジェストを使用します。
The quality of the security provided by the Cryptographic authentication option depends completely on the strength of the message digest algorithm (MD5 is currently the only message digest algorithm specified), the strength of the key being used, and the correct implementation of the security mechanism in all communicating OSPF implementations. It also requires that all parties maintain the secrecy of the shared secret key. None of the standard OSPF authentication types provide confidentiality, nor do they protect against traffic analysis. For more information on the standard OSPF security mechanisms, see Sections 8.1, 8.2, and Appendix D of [OSPF].
Cryptographic認証オプションで提供されたセキュリティの品質は完全メッセージダイジェストアルゴリズム(現在、MD5は指定された唯一のメッセージダイジェストアルゴリズムである)の強さ、使用されるキーの強さ、およびすべてでのOSPF実現を伝えるセキュリティー対策の正しい実現に依存します。 また、それは、すべてのパーティーが共有された秘密鍵の秘密主義を維持するのを必要とします。 標準のOSPF認証タイプのだれも秘密性を提供しません、そして、彼らはトラヒック分析から守りません。 標準のOSPFセキュリティー対策の詳しい情報に関しては、セクション8.1、8.2、および[OSPF]のAppendix Dを見てください。
Murphy Standards Track [Page 20] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
マーフィーStandardsはOSPFしたがって、短く太くない領域(NSSA)オプション2003年1月にRFC3101を追跡します[20ページ]。
[DIGI] describes the extensions to OSPF required to add digital signature authentication to Link State data and to provide a certification mechanism for router data. [DIGI] also describes the added LSA processing and key management as well as a method for migration from or co-existence with standard OSPF V2.
[DIGI]はLink州データにデジタル署名認証を追加して、証明メカニズムをルータデータに提供しなければならなかったOSPFに拡大について説明します。 また、[DIGI]は標準のOSPF V2がある移動か共存のための方法と同様に加えられたLSA処理とかぎ管理を説明します。
OSPF addresses repetitive origination of advertisements by mandating a limit on how frequent new instances of any particular LSA can be originated and accepted during the flooding procedure. The frequency at which new LSA instances may be originated is set to once every MinLSInterval seconds, whose value is 5 seconds. (See [OSPF] Section 12.4.) The frequency at which new LSA instances are accepted during flooding is once every MinLSArrival seconds, whose value is set to 1 second. (See [OSPF] Section 13, Appendix B, and G.1.)
OSPFは、氾濫手順の間どうどんな特定のLSAの頻繁な新しい例も溯源して、受け入れることができるかに関して限界を強制することによって、広告の反復性の創作を記述します。 新しいLSA例が溯源されるかもしれない頻度はかつてのあらゆるMinLSIntervalに秒を決めることです。(秒の値は5秒です)。 ([OSPF]セクション12.4を見てください。) かつて新しいLSA例が氾濫の間に受け入れられる頻度は秒、値が1秒に設定されるあらゆるMinLSArrivalです。 (セクション13、付録B、およびG.1を見てください[OSPF]。)
Proper operation of the OSPF protocol requires that all OSPF routers maintain an identical copy of the OSPF link state database. However, when the size of the link state database becomes very large, some routers may be unable to keep the entire database due to resource shortages; this is termed "database overflow". When database overflow is anticipated, the routers with limited resources can be accommodated by configuring OSPF stub areas and NSSAs. [OVERFLOW] details a way of gracefully handling unanticipated database overflows.
OSPFプロトコルの適切な操作は、すべてのOSPFルータがOSPFリンク州のデータベースの同一の複製物を維持するのを必要とします。 しかしながら、リンク州のデータベースのサイズが非常に大きくなるとき、リソース不足のため、いくつかのルータは全体のデータベースを保つことができないかもしれません。 これは「データベースオーバーフロー」と呼ばれます。 データベースオーバーフローが予期されるとき、OSPFスタッブ領域とNSSAsを構成することによって、限りある資源があるルータを設備することができます。 [OVERFLOW]は優雅に思いがけないデータベースオーバーフローを扱う方法を詳しく述べます。
5.0 Acknowledgements
5.0 承認
This document was produced by the OSPF Working Group, chaired by John Moy.
このドキュメントはジョンMoyによってまとめられたOSPF作業部会によって製作されました。
In addition, the comments of the following individuals are also acknowledged:
また、さらに、以下の個人のコメントは承諾されます:
Antoni Przygienda Redback Networks, Inc
Alex Zinin cisco
Antoni Przygienda Redback Networks、Incアレックスジニンコクチマス
It is also noted that comments from
また、注意されて、それがコメントするということです。
Phani Jajjarvarpu cisco
Dino Farinacci cisco
Jeff Honig Cornell University
Doug Williams IBM
Phani Jajjarvarpuコクチマスディーノファリナッチコクチマスジェフホニッグコーネル大学ダグウィリアムズIBM
were acknowledged in the predecessor of this document, RFC 1587.
このドキュメント、RFC1587の前任者では、承認されました。
Murphy Standards Track [Page 21] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
マーフィーStandardsはOSPFしたがって、短く太くない領域(NSSA)オプション2003年1月にRFC3101を追跡します[21ページ]。
6.0 Contributors
6.0 貢献者
This document, RFC 3101, adds new sections, features, edits, and revisions to its predecessor, RFC 1587, "The OSPF NSSA Option", authored by Rob Coltun, Movaz Networks, and Vince Fuller. Content from RFC 1587 is used throughout RFC 3101. In addition to adding new features, this document makes the NSSA specification consistent with the OSPFv2 specification, RFC 2328, authored by John Moy, Sycamore Networks, Inc. Section 2.5, Calculating Type-7 AS External Routes, and Section 2.6, Incremental Updates, rely heavily on text in RFC 2328's Section 16.4 and Section 16.6 respectively. Section 4.0, Security Considerations, is an edit of similar content in Rob Coltun's RFC 2370, "The OSPF Opaque LSA option", Section 6.0.
このドキュメント(RFC3101)は前任者、RFC1587、ロブColtunによって書かれた「OSPF NSSAオプション」Movaz Networks、およびビンス・フラーに新しいセクション、特徴、編集、および改正を加えます。 RFC1587からの内容はRFC3101中で使用されます。 新機能を加えることに加えて、このドキュメントでNSSA仕様はOSPFv2仕様と一致するようになって、ジョンMoy、Sycamore Networks Inc.セクション2.5、Calculating Type-7 AS External Routes、およびセクション2.6によって書かれたRFC2328(Incremental Updates)は大いにそれぞれRFC2328のセクション16.4とセクション16.6のテキストを当てにします。 セクション4.0(Security Considerations)はロブColtunのRFC2370での同様の内容の編集、「OSPF Opaque LSAオプション」(セクション6.0)です。
Acee Lindem, Redback Networks, Inc, is also recognized for the first full known implementation of this specification. Acee's implementation resulted in substantive content change.
また、Acee Lindem(Redback Networks、Inc)はこの仕様の最初の完全な知られている実現として認識されます。 Aceeの実現は実質的な満足している変化をもたらしました。
7.0 References
7.0の参照箇所
[DIGI] Murphy, S., Badger, M. and B. Wellington, "OSPF with
Digital Signatures", RFC 2154, June 1997.
[DIGI]マーフィーとS.とムジナとM.とB.ウェリントン、「デジタル署名があるOSPF」、RFC2154、1997年6月。
[MUEX] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March
1994.
[MUEX] Moy、J.、「OSPFへのマルチキャスト拡大」、RFC1584、1994年3月。
[OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[OSPF]Moy、J.、「OSPF、バージョン2インチ、RFC2328、1998インチ年4月。
[OPAQUE] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July
1998.
[不透明]のColtun、1998年7月のR.、「OSPFの不明瞭なLSAオプション」RFC2370。
[OVERFLOW] Moy, J., "OSPF Database Overflow", RFC 1765, March 1995.
[オーバーフロー]Moy、J.、「OSPFデータベースオーバーフロー」、RFC1765、1995年3月。
Murphy Standards Track [Page 22] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
マーフィーStandardsはOSPFしたがって、短く太くない領域(NSSA)オプション2003年1月にRFC3101を追跡します[22ページ]。
Appendix A: The Options Field
付録A: オプション分野
The OSPF options field is present in OSPF Hello packets, Database Description packets and all link state advertisements. See [OSPF] Appendix A.2 and [OPAQUE] Appendix A.1 for a description of the options field. Six bits are assigned but only two (the E-bit and the N/P bit) are described completely in this section.
OSPFオプション分野はOSPF Helloパケット、Database記述パケット、およびすべてのリンク州の広告に存在しています。 オプション分野の記述に関して[OSPF]付録A.2と[OPAQUE]付録A.1を見てください。 6ビットは割り当てられますが、2(E-ビットとN/Pビット)だけが完全にこのセクションで説明されます。
--------------------------------------
| * | O | DC | EA | N/P | MC | E | * |
--------------------------------------
-------------------------------------- | * | O| DC| EA| N/P| M.C.| E| * | --------------------------------------
The Type-7 LSA options field
Type-7 LSAオプション分野
E-bit: Type-5 AS-external-LSAs are not flooded into/through OSPF
stub areas and NSSAs. The E-bit ensures that all members
of a stub area or NSSA agree on that area configuration.
The E-bit is meaningful only in OSPF Hello and Database
Description packets. When the E-bit is clear in the Hello
packet sent out a particular interface, it means that the
router will neither send nor receive Type-5 AS-external-
LSAs on that interface (in other words, the interface
connects to a stub area or NSSA). Two routers will not
become neighbors unless they agree on the state of the E-
bit.
電子ビット: OSPFスタッブ領域とNSSAsを通したASの外部のLSAsがあふれないタイプ-5/。 E-ビットは、スタッブ領域かNSSAのすべてのメンバーがその領域構成に同意するのを確実にします。 E-ビットはOSPF HelloとDatabase記述パケットだけで重要です。 E-ビットがいつHelloパケットで明確であるかが特定のインタフェースを出して、それは、ルータがそのインタフェースでType-5 AS外部のLSAsを送付でない、また受けないことを意味します(言い換えれば、インタフェースはスタッブ領域かNSSAに接続します)。 彼らがEビットの状態に同意しないなら、2つのルータは隣人にならないでしょう。
N-bit: The N-bit describes the router's NSSA capability. The N-
bit is used only in Hello packets and ensures that all
members of an NSSA agree on that area's configuration.
When the N-bit is set in the Hello packet that is sent out
a particular interface, it means that the router will send
and receive Type-7 LSAs on that interface. Two routers
will not form an adjacency unless they agree on the state
of the N-bit. If the N-bit is set in the options field,
the E-bit must be clear.
N-ビット: N-ビットはルータのNSSA能力について説明します。 Nビットは、Helloパケットだけで使用されて、NSSAのすべてのメンバーがその領域の構成に同意するのを確実にします。 N-ビットが設定されるとき、Helloパケットでは、特定のインタフェースは出されていて、それは、ルータがそのインタフェースでType-7 LSAsを送って、受けることを意味します。 彼らがN-ビットの状態に同意しないと、2つのルータは隣接番組を形成しないでしょう。 N-ビットがオプション分野に設定されるなら、E-ビットは明確であるに違いありません。
P-bit: The P-bit is used only in the Type-7 LSA header. It flags
the NSSA border router to translate the Type-7 LSA into a
Type-5 LSA. The default setting for the P-bit is clear.
P-ビット: P-ビットはType-7 LSAヘッダーだけで使用されます。 それは、Type-7 LSAをType-5 LSAに翻訳するためにNSSA境界ルータに旗を揚げさせます。 P-ビット単位で既定の設定は明確です。
Murphy Standards Track [Page 23] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
マーフィーStandardsはOSPFしたがって、短く太くない領域(NSSA)オプション2003年1月にRFC3101を追跡します[23ページ]。
Appendix B: Router-LSAs
付録B: ルータ-LSAs
Router-LSAs are the Type-1 LSAs. Each router in an area originates a router-LSA. The LSA describes the state and cost of the router's links (i.e., interfaces) to the area. All of the router's links to the area must be described in a single router-LSA. For details concerning the construction of router-LSAs, see [OSPF] Section 12.4.1.
ルータ-LSAsはType-1 LSAsです。 領域の各ルータはルータ-LSAを溯源します。 LSAはその領域へのルータのリンク(すなわち、インタフェース)の状態と費用について説明します。 独身のルータ-LSAでその領域へのルータのリンクのすべてについて説明しなければなりません。 ルータ-LSAsの構造に関する詳細に関しては、[OSPF]セクション12.4.1を見てください。
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 Nt|W|V|E|B| 0 | # links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | # TOS | TOS 0 metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOS | 0 | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOS | 0 | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
0 1 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS時代| オプション| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 州のIDをリンクしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 広告ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSチェックサム| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 Nt|W|V|E|B| 0 | # リンク| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IDをリンクしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | リンクデータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| # TOS| TOS0メートル法です。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOS| 0 | メートル法| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOS| 0 | メートル法| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IDをリンクしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | リンクデータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
In router-LSAs, the Link State ID field is set to the router's OSPF Router ID. Router-LSAs are flooded throughout a single area only.
ルータ-LSAsでは、Link州ID分野はルータのOSPF Router IDに設定されます。 ルータ-LSAsはただ一つの領域だけ中で水につかっています。
Murphy Standards Track [Page 24] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
マーフィーStandardsはOSPFしたがって、短く太くない領域(NSSA)オプション2003年1月にRFC3101を追跡します[24ページ]。
bit V
When set, the router is an endpoint of one or more fully
adjacent virtual links having the described area as their
transit area (V is for virtual link endpoint).
Whenが設定するビットV、ルータはそれらのトランジット領域として説明された領域を持っている1個以上の完全に隣接している仮想のリンクの終点(仮想のリンク終点にはVがある)です。
bit E
When set, the router is an AS boundary router (E is for
external). ALL NSSA border routers set bit E in those
router-LSAs originated into directly attached Type-5 capable
areas. An NSSA's AS boundary routers also set bit E in their
router-LSAs originated into the NSSA. (See Section 3.1 for
details.)
ビットE Whenはセットして、ルータはAS境界ルータ(外部にはEがある)です。 ALL NSSA境界ルータは直接付属しているType-5できる領域に溯源されたそれらのルータ-LSAsにビットEをはめ込みます。 また、NSSAのAS境界ルータはNSSAに溯源されたそれらのルータ-LSAsにビットEをはめ込みます。 (詳細に関してセクション3.1を見てください。)
bit B
When set, the router is an area border router (B is for
border).
ビットB Whenはセットして、ルータは境界ルータ(境界にはBがある)です。
bit W
When set, the router is a wild-card multicast receiver (W is
for wild).
ビットW Whenはセットして、ルータはワイルドカードマルチキャスト受信機(荒野にはWがある)です。
bit Nt
When set, the router is an NSSA border router that is
unconditionally translating Type-7 LSAs into Type-5 LSAs (Nt
stands for NSSA translation). Note that such routers have
their NSSATranslatorRole area configuration parameter set to
Always. (See Appendix D and Section 3.1.)
Nt Whenが設定するビット、ルータは無条件にType-7 LSAsをType-5 LSAsに翻訳しているNSSA境界ルータ(NtはNSSA翻訳を表す)です。 そのようなルータでそれらのNSSATranslatorRole領域設定パラメータをAlwaysに設定することに注意してください。 (付録Dとセクション3.1を見てください。)
The remainder of the router-LSAs specification is defined in [OSPF] Section A.4.2.
ルータ-LSAs仕様の残りは[OSPF]セクションA.4.2で定義されます。
Murphy Standards Track [Page 25] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
マーフィーStandardsはOSPFしたがって、短く太くない領域(NSSA)オプション2003年1月にRFC3101を追跡します[25ページ]。
Appendix C: Type-7 LSA Packet Format
付録C: タイプ-7LSAパケット・フォーマット
0 32
------------------------------------
| | Options | 7 |
| -------------------
| Link-State Header |
| |
------------------------------------
| Network Mask |
------------------------------------ ______
|E| TOS | metric | .
------------------------------------ . repeated for each TOS
| Forwarding Address | .
------------------------------------ .
| External Route Tag | ______
------------------------------------
0 32 ------------------------------------ | | オプション| 7 | | ------------------- | リンク州のヘッダー| | | ------------------------------------ | ネットワークマスク| ------------------------------------ ______ |E| TOS| メートル法| . ------------------------------------ . 各TOSのために、繰り返されます。| フォーワーディング・アドレス| . ------------------------------------ . | 外部経路タグ| ______ ------------------------------------
The definitions of the link-state ID, network mask, metrics and external route tag are the same as the definitions for Type-5 LSAs (See [OSPF] Appendix A.4.5), except for the forwarding address and the N/P-bit. The Options field must have the N/P bit set as described in Appendix A when the originating router desires that the external route be propagated throughout the OSPF domain.
リンク州のID、ネットワークマスク、測定基準、および外部経路タグの定義はType-5 LSAsのための定義と同じです([OSPF]付録A.4.5を見てください)、フォーワーディング・アドレスであってPでN/噛み付きにされるのを除いて。 Options分野で、外部経路がOSPFドメイン中で伝播されるという由来しているルータ願望であるときに、Appendix Aで説明されるようにN/Pビットを設定しなければなりません。
Forwarding address
Data traffic for the advertised destination will be forwarded to
this address. If the forwarding address is set to 0.0.0.0, data
traffic will be forwarded to the LSA's originator (i.e., the
responsible NSSA AS boundary router). Normally the next hop
address of an installed AS external route learned by an NSSA ASBR
from an adjacent AS points at one of the adjacent AS's gateway
routers. If this address belongs to a network connected to the
NSSA ASBR via one of its NSSAs' active interfaces, then it is the
forwarding address for the route's Type-7 LSA originated into this
NSSA. For an NSSA with no such network the forwarding address is
either an address from one of its active interfaces or 0.0.0.0.
If the P-bit is set, the forwarding address must be non-zero,
otherwise it may be 0.0.0.0. (See Section 2.3 for details.)
広告を出している目的地のためのフォーワーディング・アドレスData交通をこのアドレスに送るでしょう。 フォーワーディング・アドレスが0.0に.0を設定することであるなら、.0、データ通信量をLSAの創始者に送るでしょう(すなわち、原因となるNSSA AS境界ルータ)。 通常、インストールされたAS外部経路の次のホップアドレスは、NSSA ASBRで隣接しているASから、ASのゲートウェイルータが隣接の1つを指していることを学びました。 このアドレスがNSSAsのアクティブなインタフェースの1つを通してNSSA ASBRに接続されたネットワークに属すなら、それはこのNSSAに溯源されたルートのType-7 LSAのためのフォーワーディング・アドレスです。 そのようなネットワークでないのがあるNSSAに関して、フォーワーディング・アドレスは、アクティブなインタフェースの1つからのアドレスか0.0のどちらかです。.0 .0。 P-ビットが設定されるなら、フォーワーディング・アドレスが非ゼロであるに違いない、さもなければ、それはあるかもしれません。0.0 .0 .0。 (詳細に関してセクション2.3を見てください。)
Murphy Standards Track [Page 26] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
マーフィーStandardsはOSPFしたがって、短く太くない領域(NSSA)オプション2003年1月にRFC3101を追跡します[26ページ]。
Appendix D: Configuration Parameters
付録D: 設定パラメータ
[OSPF] Appendix C.2 lists the area configuration parameters. The area ID and the list of address ranges for Type-3 summary routes remain unchanged. Section 2.2 of this document lists the configuration parameters for Type-7 address ranges. The following area configuration parameters have been added:
[OSPF]付録C.2は領域設定パラメータをリストアップします。 Type-3概要ルートへのアドレスの範囲の領域IDとリストは変わりがありません。 このドキュメントのセクション2.2はType-7アドレスの範囲のための設定パラメータをリストアップします。 以下の領域設定パラメータは加えられます:
NSSATranslatorRole
NSSATranslatorRole
Specifies whether or not an NSSA border router will
unconditionally translate Type-7 LSAs into Type-5 LSAs. When
it is set to Always, an NSSA border router always translates
Type-7 LSAs into Type-5 LSAs regardless of the translator state
of other NSSA border routers. When it is set to Candidate, an
NSSA border router participates in the translator election
process described in Section 3.1. The default setting is
Candidate.
NSSA境界ルータが無条件にType-7 LSAsをType-5 LSAsに翻訳するかどうか指定します。 それがAlwaysに設定されるとき、NSSA境界ルータは他のNSSA境界ルータの翻訳者状態にかかわらずいつもType-7 LSAsをType-5 LSAsに翻訳します。 それがCandidateに設定されるとき、NSSA境界ルータはセクション3.1で説明された翻訳者選挙の過程に参加します。 既定の設定はCandidateです。
TranslatorStabilityInterval
TranslatorStabilityInterval
Defines the length of time an elected Type-7 translator will
continue to perform its translator duties once it has
determined that its translator status has been deposed by
another NSSA border router translator as described in Section
3.1 and 3.3. The default setting is 40 seconds.
選出されたType-7翻訳者が別のNSSA境界ルータ翻訳者がセクション3.1と3.3で説明されるように翻訳者状態を口供したことをいったん決定すると翻訳者義務を実行し続けている時の長さを定義します。 既定の設定は40秒です。
ImportSummaries
ImportSummaries
When set to enabled, OSPF's summary routes are imported into
the NSSA as Type-3 summary-LSAs. When set to disabled, summary
routes are not imported into the NSSA. The default setting is
enabled.
可能にされるのに設定すると、Type-3概要-LSAsとしてOSPFの概要ルートをNSSAに輸入します。 身体障害者に設定される場合、概要ルートはNSSAに輸入されません。 既定の設定は可能にされます。
Implementations must provide a vehicle for setting the P-bit when external routes are imported into the NSSA as Type-7 LSAs. Without configuration, the default setting of the P-bit is clear. (See Section 2.3 and Appendix B.)
実現はType-7 LSAsとして外部経路をNSSAに輸入するときP-ビットを設定するための乗り物を提供しなければなりません。 構成がなければ、P-ビットの既定の設定は明確です。 (セクション2.3と付録B.を見ます)
For NSSAs the ExternalRoutingCapability area configuration parameter must be set to accept Type-7 external routes. Additionally there must be a way of configuring the metric of the default LSA that a border router advertises into its directly attached NSSAs. If a Type-7 default LSA is advertised, its metric type (1 or 2) should also be configurable.
NSSAsにおいて、Type-7外部経路を受け入れるようにExternalRoutingCapability領域設定パラメータを設定しなければなりません。 さらに、境界ルータが直接付属しているNSSAsに広告を出すデフォルトLSAのメートル法を構成する方法があるに違いありません。 また、Type-7デフォルトLSAが広告に掲載されるなら、メートル法のタイプ(1か2)も構成可能であるべきです。
Murphy Standards Track [Page 27] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
マーフィーStandardsはOSPFしたがって、短く太くない領域(NSSA)オプション2003年1月にRFC3101を追跡します[27ページ]。
Appendix E: The P-bit Policy Paradox.
付録E: P-ビット方針パラドックス。
Non-default Type-7 LSAs with the P-bit clear may be installed in the OSPF routing table of NSSA border routers. (See Section 2.5.) These LSAs are not propagated throughout the OSPF domain as translated Type-5 LSAs. (See Section 3.2.) Thus, traffic that is external to an NSSA and that passes through one of the NSSA's border routers may be hijacked into the NSSA by a route installed from a Type-7 LSA with the P-bit clear. This may be contrary to the expected path at the source of the traffic. It may also violate the routing policy intended by the Type-7 LSA's clear P-bit. A Type-7 address range that is configured with DoNotAdvertise exhibits the same paradox for any installed Type-7 LSAs it subsumes, regardless of the P-bit setting.
P-ビットが明確の非デフォルトType-7 LSAsはNSSA境界ルータのOSPF経路指定テーブルにインストールされるかもしれません。 (セクション2.5を見てください。) これらのLSAsは翻訳されたType-5 LSAsとしてOSPFドメイン中で伝播されません。 (セクション3.2を見てください。) したがって、NSSAに外部であり、NSSAの境界ルータの1つを通り抜ける交通はP-ビットが明確な状態でType-7 LSAからインストールされたルートでNSSAにハイジャックされるかもしれません。 これは交通の源の予想された経路とは逆にあるかもしれません。 また、それはType-7 LSAの明確なP-ビットで意図するルーティング方針に違反するかもしれません。 DoNotAdvertiseによって構成されるType-7アドレスの範囲はそれが包括するどんなインストールされたType-7 LSAsのためにも同じパラドックスを示します、P-ビット設定にかかわらず。
This paradox is best illustrated by the following example. Consider an OSPF domain (AS 1842) with connections for default Internet routing and to external AS 4156. NSSA 1 and OSPF Area 2 are partially defined in the following diagram:
以下の例でこのパラドックスを例証するのは最も良いです。 OSPFドメインが(AS1842)であるとデフォルトインターネットルーティングのための接続と、そして、外部のAS4156と考えてください。 NSSA1とOSPF Area2は以下のダイヤグラムで部分的に定義されます:
AS 4156
|
Area 2 |
|
A2 A0 Area 0 C0-----Internet
| | | Default
| | |
| | |
+-----------------B0---------------+
/\
/ \
/ \
Internet------------A1 B1------AS 4156 (P-bit clear)
Default (P-bit set)
NSSA 1
4156として| 領域2| | A2 A0領域0C0-----インターネット| | | デフォルト| | | | | | +-----------------B0---------------+/\/\/\インターネット------------A1 B1------AS4156(はっきりとPで噛み付きます)デフォルト(P-ビットはセットした)NSSA1
Here A0, B0, and C0 are Area 0 routers, A1 and B1 are NSSA 1 routers, and A2 is an Area 2 router. B0 is a border router for both NSSA 1 and Area 2.
ここで、A0、B0、およびC0はArea0ルータです、そして、A1とB1はNSSA1ルータです、そして、A2はArea2ルータです。 B0はNSSA1とArea2の両方のための境界ルータです。
If the Type-7 external routes imported by B1 for AS 4156 are installed on B0 so that the NSSA 1 tree below A1 can take advantage of them, then A2's traffic to AS 4156 is hijacked through B0 by B1, rather than its computed path through A0.
1が木に追い上げるNSSAがA1の下で彼らを利用できるようにAS4156のためにB1によって輸入されたType-7外部経路がB0の上にインストールされるなら、AS4156へのA2の交通はA0を通してB0を通して計算された経路よりむしろB1によってハイジャックされます。
An NSSA border router's installed Type-7 default LSAs will exhibit this paradox when it possesses a Type-7 address range [0,0] configured with DoNotAdvertise, as these LSAs are not propagated even
それにDoNotAdvertiseによって構成されたType-7アドレスの範囲[0、0]があるとき、NSSA境界ルータのインストールされたType-7デフォルトLSAsはこのパラドックスを示すでしょう、これらのLSAsが伝播されないときさえ
Murphy Standards Track [Page 28] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
マーフィーStandardsはOSPFしたがって、短く太くない領域(NSSA)オプション2003年1月にRFC3101を追跡します[28ページ]。
though their P-bit is set. In the example above, if A1's default is installed on B0, which has a configured Type-7 address range [0,0] with DoNotAdvertise set, then A2's Internet traffic is hijacked through B0 by A1 rather than the computed path through C0.
それらのP-ビットは設定されますが。 例では、A1のデフォルトがB0(DoNotAdvertiseがある構成されたType-7アドレスの範囲[0、0]をセットさせる)にインストールされるなら、A2のインターネットトラフィックはC0を通してB0を通して上では、計算された経路よりむしろA1によってハイジャックされます。
Murphy Standards Track [Page 29] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
マーフィーStandardsはOSPFしたがって、短く太くない領域(NSSA)オプション2003年1月にRFC3101を追跡します[29ページ]。
Appendix F: Differences from RFC 1587
付録F: RFC1587からの違い
This section documents the differences between this memo and RFC 1587. All differences are backward-compatible. Implementations of this memo and of RFC 1587 will interoperate.
このセクションはこのメモとRFC1587の違いを記録します。 すべての違いは互換性があります後方の。 このメモとRFC1587の実現は共同利用するでしょう。
F.1 Enhancements to the import of OSPF's summary routes.
OSPFの概要ルートの輸入へのF.1増進。
The import of OSPF's summary routes into an NSSA as Type-3 summary- LSAs is now optional. In RFC 1587 the import of summary routes was mandated in order to guarantee that inter-area summary routing was not obscured by an NSSA's Type-7 AS-external-LSAs. The current recommended default behavior is to import summary routes. When summary routes are not imported into an NSSA, the default LSA originated by its border routers must be a Type-3 summary-LSA.
Type-3概要LSAsとしてのNSSAへのOSPFの概要ルートの輸入は現在、任意です。 RFC1587年に、概要ルートの輸入は、相互領域概要ルーティングがNSSAのType-7 ASの外部のLSAsによってあいまいにされなかったのを保証するために強制されました。 現在のお勧めのデフォルトの振舞いは概要ルートを輸入することです。 概要ルートがNSSAに輸入されないとき、境界ルータによって溯源されたデフォルトLSAはType-3概要-LSAであるに違いありません。
See Sections 1.3 and 2.7 for details.
詳細に関してセクション1.3と2.7を見てください。
F.2 Changes to Type-7 LSAs.
F.2はタイプ-7LSAsに変化します。
The setting of the forwarding address in Type-7 LSAs has been further refined.
Type-7 LSAsのフォーワーディング・アドレスの設定はさらに洗練されました。
See Section 2.3 for details.
詳細に関してセクション2.3を見てください。
F.3 Changes to the Type-7 AS external routing calculation.
F.3はType-7 ASの外部のルーティング計算に変化します。
The Type-7 external route calculation has been revised. Most notably:
Type-7外部経路計算は改訂されました。 最も著しさ:
o The path preference defined in [OSPF] Section 16.4.1 has been
included.
o [OSPF]セクション16.4.1で定義された経路好みは含まれています。
o A Type-7 default route with the P-bit clear will not be
installed on an NSSA border router. This protects the default
routing of other OSPF Areas. (See Appendix E.)
o P-ビットが明確のType-7デフォルトルートはNSSA境界ルータにインストールされないでしょう。 これは他のOSPF Areasのデフォルトルーティングを保護します。 (付録E.を見ます)
o The LSA type of two AS-external-LSAs plays no role in
determining path preference except when the LSAs are
functionally the same (i.e., same destination, cost and non-
zero forwarding address).
o 2ASの外部のLSAsのLSAタイプはLSAsが機能上同じである時以外に、経路好みを決定することにおける役割(すなわち、同じ目的地、費用、およびゼロを転送しないアドレス)を全く果たしません。
See Section 2.5 for details.
詳細に関してセクション2.5を見てください。
Murphy Standards Track [Page 30] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
マーフィーStandardsはOSPFしたがって、短く太くない領域(NSSA)オプション2003年1月にRFC3101を追跡します[30ページ]。
F.4 Changes to translating Type-7 LSAs into Type-5 LSAs
Type-7 LSAsをType-5 LSAsに翻訳することへのF.4変化
The translator election algorithm of RFC 1587 has been updated to close a bug that results when the translator with the highest router ID loses connectivity to the AS's transit topology. The default translator election process occurs only in the absence of an existing translator.
最も高いルータIDをもっている翻訳者がASのトランジットトポロジーに接続性を失うと結果として生じるバグを閉じるためにRFC1587の翻訳者選挙アルゴリズムをアップデートしました。 デフォルト翻訳者選挙の過程は単に既存の翻訳者が不在のとき起こります。
The identity of the translator is optionally configurable, with more than one allowed. This allows the network designer to choose the most cost effective intra-AS route for NSSA originated Type-5 LSA aggregations of Type-7 LSAs.
翻訳者のアイデンティティは許容されたより多くのもので任意に構成可能です。 これで、ネットワーク設計者は最も費用効率がよいNSSAのためのルートがType-5 LSA集合を溯源したイントラ-AS Type-7 LSAsを選ぶことができます。
Self-originated non-default Type-7 LSAs are now included in the translation process.
自己によって溯源された非デフォルトType-7 LSAsは現在、翻訳の過程に含まれています。
The translation process has been strengthened to close some of the weak points of RFC 1587.
RFC1587の弱点のいくつかを閉じるために翻訳の過程を強化してあります。
See Sections 3.1 and 3.2 for details.
詳細に関してセクション3.1と3.2を見てください。
F.5 Changes to flushing translated Type-7 LSAs
洗い流すことへのF.5変化はType-7 LSAsを翻訳しました。
An NSSA border router, which was elected by the augmented RFC 1587 translator selection process defined in Section 3.1 and which has been deposed from its translation duties by another NSSA border router, flushes its self-originated Type-5 LSAs that resulted from the aggregation of Type-7 LSAs. This prevents these obsolete aggregations from short circuiting the preferred path through the new translator(s). A deposed translator continues to maintain its self- originated Type-5 LSAs resulting from translation until they age out normally.
NSSA境界ルータ(セクション3.1で定義された増大しているRFC1587翻訳者選択の過程によって選出されて、別のNSSA境界ルータによって翻訳義務から口供された)はType-7 LSAsの集合から生じた自己によって溯源されたType-5 LSAsを洗い流します。 これは都合のよい経路を短絡させるのから新しい翻訳者までこれらの時代遅れの集合を防ぎます。 口供させられた翻訳者は、自己が通常、彼らが外で年をとるまで翻訳から生じるType-5 LSAsを溯源したと主張し続けています。
See Section 3.3 for details.
詳細に関してセクション3.3を見てください。
F.6 P-bit additions
F.6P-ビット追加
The P-bit default has been defined as clear. RFC 1587 had no default setting. (See Appendix C.)
P-ビットデフォルトは同じくらいはっきりと定義されました。 RFC1587には、既定の設定が全くありませんでした。 (付録C.を見ます)
A discussion on the packet forwarding impact of installing Type-7 LSAs with the P-bit clear on NSSA border routers has been added as Appendix E.
P-ビットが明確な状態でType-7 LSAsをインストールするNSSA境界ルータへのパケット推進影響についての議論はAppendix Eとして加えられます。
Murphy Standards Track [Page 31] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
マーフィーStandardsはOSPFしたがって、短く太くない領域(NSSA)オプション2003年1月にRFC3101を追跡します[31ページ]。
Author's Addresses
作者のアドレス
Pat Murphy US Geological Survey 345 Middlefield Road Menlo Park, California 94560
マーフィー米国の地質調査345Middlefield Roadメンローパーク、パット・カリフォルニア 94560
Phone: (650) 329-4044 EMail: pmurphy@noc.usgs.net
以下に電話をしてください。 (650) 329-4044 メールしてください: pmurphy@noc.usgs.net
Murphy Standards Track [Page 32] RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option January 2003
マーフィーStandardsはOSPFしたがって、短く太くない領域(NSSA)オプション2003年1月にRFC3101を追跡します[32ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Murphy Standards Track [Page 33]
マーフィー標準化過程[33ページ]
一覧
スポンサーリンク
