RFC2178 日本語訳
2178 OSPF Version 2. J. Moy. July 1997. (Format: TXT=495866 bytes) (Obsoletes RFC1583) (Obsoleted by RFC2328) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Moy Request for Comments: 2178 Cascade Communications Corp. Obsoletes: 1583 July 1997 Category: Standards Track
Moyがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 2178は社が時代遅れにするコミュニケーションをどっと落させています: 1583 1997年7月のカテゴリ: 標準化過程
OSPF Version 2
OSPFバージョン2
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)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. It is designed to be run internal to a single Autonomous System. Each OSPF router maintains an identical database describing the Autonomous System's topology. From this database, a routing table is calculated by constructing a shortest- path tree.
このメモはOSPFプロトコルのバージョン2を記録します。 OSPFはリンク州のルーティング・プロトコルです。 それは、独身のAutonomous Systemに内部で実行されるように設計されています。 それぞれのOSPFルータはAutonomous Systemのトポロジーについて説明する同じデータベースを維持します。 このデータベースから、経路指定テーブルは、最も低い経路木を組み立てることによって、計算されます。
OSPF recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic. OSPF provides support for equal-cost multipath. An area routing capability is provided, enabling an additional level of routing protection and a reduction in routing protocol traffic. In addition, all OSPF routing protocol exchanges are authenticated.
最小ルーティング・プロトコルトラフィックを利用して、OSPF recalculatesは位相的に直面してすばやく変化を発送します。 OSPFは等価コストマルチパスのサポートを提供します。 追加レベルのルーティング保護とルーティング・プロトコルトラフィックの減少を可能にして、領域ルーティング能力を提供します。 さらに、すべてのOSPFルーティング・プロトコル交換が認証されます。
The differences between this memo and RFC 1583 are explained in Appendix G. All differences are backward-compatible in nature. Implementations of this memo and of RFC 1583 will interoperate.
このメモとRFC1583の違いはAppendix G.で説明されます。All差は現実に互換性があります後方の。 このメモとRFC1583の実装は共同利用するでしょう。
Please send comments to ospf@gated.cornell.edu.
コメントを ospf@gated.cornell.edu に送ってください。
Table of Contents
目次
1 Introduction ........................................... 5
1.1 Protocol Overview ...................................... 5
1.2 Definitions of commonly used terms ..................... 6
1.3 Brief history of link-state routing technology ........ 9
1.4 Organization of this document ......................... 10
1.5 Acknowledgments ....................................... 11
2 The link-state database: organization and calculations 11
2.1 Representation of routers and networks ................ 11
1つの序論… 5 1.1 概要について議定書の中で述べてください… 5 一般的に使用された期間の1.2の定義… 6 1.3 LinkState方式技術の歴史に事情を知らせてください… 9 1.4 このドキュメントの組織… 10 1.5の承認… 11 2 リンク州のデータベース: ルータとネットワークの組織と計算11 2.1Representation… 11
Moy Standards Track [Page 1] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[1ページ]RFC2178OSPFバージョン1997年7月2日
2.1.1 Representation of non-broadcast networks .............. 13
2.1.2 An example link-state database ........................ 14
2.2 The shortest-path tree ................................ 18
2.3 Use of external routing information ................... 20
2.4 Equal-cost multipath .................................. 22
3 Splitting the AS into Areas ........................... 22
3.1 The backbone of the Autonomous System ................. 23
3.2 Inter-area routing .................................... 23
3.3 Classification of routers ............................. 24
3.4 A sample area configuration ........................... 25
3.5 IP subnetting support ................................. 31
3.6 Supporting stub areas ................................. 32
3.7 Partitions of areas ................................... 33
4 Functional Summary .................................... 34
4.1 Inter-area routing .................................... 35
4.2 AS external routes .................................... 35
4.3 Routing protocol packets .............................. 35
4.4 Basic implementation requirements ..................... 38
4.5 Optional OSPF capabilities ............................ 39
5 Protocol data structures .............................. 40
6 The Area Data Structure ............................... 42
7 Bringing Up Adjacencies ............................... 44
7.1 The Hello Protocol .................................... 44
7.2 The Synchronization of Databases ...................... 45
7.3 The Designated Router ................................. 46
7.4 The Backup Designated Router .......................... 47
7.5 The graph of adjacencies .............................. 48
8 Protocol Packet Processing ............................ 49
8.1 Sending protocol packets .............................. 49
8.2 Receiving protocol packets ............................ 51
9 The Interface Data Structure .......................... 54
9.1 Interface states ...................................... 57
9.2 Events causing interface state changes ................ 59
9.3 The Interface state machine ........................... 61
9.4 Electing the Designated Router ........................ 64
9.5 Sending Hello packets ................................. 66
9.5.1 Sending Hello packets on NBMA networks ................ 67
10 The Neighbor Data Structure ........................... 68
10.1 Neighbor states ....................................... 70
10.2 Events causing neighbor state changes ................. 75
10.3 The Neighbor state machine ............................ 76
10.4 Whether tocome adjacent ............................ 82
10.5 Receiving Hello Packets ............................... 83
10.6 Receiving Database Description Packets ................ 85
10.7 Receiving Link State Request Packets .................. 88
10.8 Sending Database Description Packets .................. 89
10.9 Sending Link State Request Packets .................... 90
10.10 An Example ............................................ 91
2.1.1 非放送網の代理… 13 2.1 .2 例のリンク州のデータベース… 14 2.2 最短パス木… 18 2.3 外部のルーティング情報の使用… 20 2.4等価コストマルチパス… 22 3 分かれる、領域のように… 22 3.1 Autonomous Systemのバックボーン… 23 3.2 相互領域ルーティング… 23 3.3 ルータの分類… 24 3.4 サンプル領域構成… 25 3.5 IPサブネッティングサポート… 31 3.6 スタッブ領域をサポートします… 32 領域の3.7のパーティション… 33 4の機能的な概要… 34 4.1 相互領域ルーティング… 35 4.2個のAS外部経路… 35 4.3 ルーティング・プロトコルパケット… 35 4.4 基本の実装要件… 38 4.5 任意のOSPF能力… 39 5 データ構造について議定書の中で述べてください… 40 6 領域データ構造… 42 7 隣接番組を持って来ます… 44、7.1、こんにちは、議定書を作ってください… 44 7.2 データベースの同期… 45 7.3 代表ルータ… 46 7.4 バックアップはルータを指定しました… 47 7.5 隣接番組のグラフ… 48 8 パケット処理について議定書の中で述べてください… 49 8.1 プロトコルパケットを送ります… 49 8.2 プロトコルパケットを受けます… 51 9 インタフェースデータ構造… 54 9.1 州を連結してください… 57 インタフェースを引き起こす9.2のイベントが変化を述べます… 59 9.3 Interfaceはマシンを述べます… 61 9.4 代表ルータに選出します。 64 9.5 パケットをHelloに送ります… 66 9.5 .1 NBMAネットワークでパケットをHelloに送ります… 67 10、隣人データ構造… 68 10.1 隣人州… 隣人を引き起こす70 10.2のイベントが変化を述べます… 75 10.3 Neighborはマシンを述べます… 76 10.4 tocome隣接しているか否かに関係なく… こんにちはを受ける82 10.5、パケット… 83 10.6 データベース記述パケットを受けます… 85 10.7 リンク状態を受けて、パケットを要求してください… 88 10.8 データベース記述パケットを送ります… 89 10.9 リンク状態を送って、パケットを要求してください… 90 10.10 例… 91
Moy Standards Track [Page 2] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[2ページ]RFC2178OSPFバージョン1997年7月2日
11 The Routing Table Structure ........................... 93
11.1 Routing table lookup .................................. 96
11.2 Sample routing table, without areas ................... 97
11.3 Sample routing table, with areas ...................... 97
12 Link State Advertisements (LSAs) ......................100
12.1 The LSA Header ........................................100
12.1.1 LS age ............................................... 101
12.1.2 Options .............................................. 101
12.1.3 LS type .............................................. 102
12.1.4 Link State ID ........................................ 102
12.1.5 Advertising Router ................................... 104
12.1.6 LS sequence number ................................... 104
12.1.7 LS checksum .......................................... 105
12.2 The link state database .............................. 105
12.3 Representation of TOS ................................ 106
12.4 Originating LSAs ..................................... 107
12.4.1 Router-LSAs .......................................... 110
12.4.1.1 Describing point-to-point interfaces ................. 112
12.4.1.2 Describing broadcast and NBMA interfaces ............. 113
12.4.1.3 Describing virtual links ............................. 113
12.4.1.4 Describing Point-to-MultiPoint interfaces ............ 114
12.4.1.5 Examples of router-LSAs .............................. 114
12.4.2 Network-LSAs ......................................... 116
12.4.2.1 Examples of network-LSAs ............................. 116
12.4.3 Summary-LSAs ......................................... 117
12.4.3.1 Originating summary-LSAs into stub areas ............. 119
12.4.3.2 Examples of summary-LSAs ............................. 119
12.4.4 AS-external-LSAs ..................................... 120
12.4.4.1 Examples of AS-external-LSAs ......................... 121
13 The Flooding Procedure ............................... 122
13.1 Determining which LSA is newer ....................... 126
13.2 Installing LSAs in the database ...................... 127
13.3 Next step in the flooding procedure .................. 128
13.4 Receiving self-originated LSAs ....................... 130
13.5 Sending Link State Acknowledgment packets ............ 131
13.6 Retransmitting LSAs .................................. 133
13.7 Receiving link state acknowledgments ................. 134
14 Aging The Link State Database ........................ 134
14.1 Premature aging of LSAs .............................. 135
15 Virtual Links ........................................ 135
16 Calculation of the routing table ..................... 137
16.1 Calculating the shortest-path tree for an area ....... 138
16.1.1 The next hop calculation ............................. 144
16.2 Calculating the inter-area routes .................... 145
16.3 Examining transit areas' summary-LSAs ................ 146
16.4 Calculating AS external routes ....................... 149
16.4.1 External path preferences ............................ 151
16.5 Incremental updates -- summary-LSAs .................. 151
11 経路指定テーブル構造… 93 11.1 索表を発送します… 96 11.2 領域なしで経路指定テーブルを抽出してください… 97 11.3 領域がある経路指定テーブルを抽出してください… 97 12は州の広告(LSAs)をリンクします…100 12.1 LSAヘッダー…100 12.1 .1LSが年をとります… 101 12.1 .2のオプション… 101 12.1 .3LSがタイプします… 102 12.1 .4 州のIDをリンクしてください… 102 12.1 .5広告ルータ… 104 12.1.6LS一連番号… 104 12.1 .7 LSチェックサム… 105 12.2 リンク州のデータベース… 105 12.3 TOSの表現… 106 12.4 LSAsを溯源します… 107 12.4 .1ルータ-LSAs… 110 12.4 .1 .1 ポイントツーポイントについて説明するのは連結します… 112 12.4 .1 .2 放送とNBMAについて説明するのは連結します… 113 12.4 .1 .3 仮想のリンクについて説明します… 113 12.4 .1 .4 PointからMultiPointについて説明するのは連結します… 114 12.4 .1 ルータ-LSAsに関する.5の例… 114 12.4 .2ネットワーク-LSAs… 116 12.4 .2 ネットワーク-LSAsに関する.1の例… 116 12.4 .3概要-LSAs… 117 12.4 .3 .1 概要-LSAsをスタッブ領域に溯源します… 119 12.4 .3 概要-LSAsに関する.2の例… 119 12.4 .4 外部のLSAsとして… 120 12.4 .4の.1の例、外部のLSAsとして… 121 13 氾濫手順… 122 どのLSAを決定する13.1は、より新しいです… 126 13.2 LSAsをデータベースにインストールします… 127 13.3 次に、氾濫手順で踏んでください… 128 13.4 受信は自己にLSAsを溯源しました… 130 13.5 州AcknowledgmentパケットをLinkに送ります… 131 13.6 LSAsを再送します… 133 13.7 リンクを受けて、承認を述べてください… 134 14 リンクの年をとって、データベースを述べてください… 134 14.1 LSAsの時期尚早な年をとること… 135 15 仮想のリンク… 135 16 経路指定テーブルの計算… 137 16.1 最短パス木について領域に計算します… 138 16.1 .1 次のホップ計算… 144 16.2 相互領域ルートを計算します… 145 16.3 トランジット領域の概要-LSAsを調べます… 146 16.4 計算のAS外部経路… 149 16.4 .1 外部の経路好み… 151 16.5 増加のアップデート(概要-LSAs)… 151
Moy Standards Track [Page 3] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[3ページ]RFC2178OSPFバージョン1997年7月2日
16.6 Incremental updates -- AS-external-LSAs .............. 152
16.7 Events generated as a result of routing table changes 153
16.8 Equal-cost multipath ................................. 154
Footnotes ............................................ 155
References ........................................... 158
A OSPF data formats .................................... 160
A.1 Encapsulation of OSPF packets ........................ 160
A.2 The Options field .................................... 162
A.3 OSPF Packet Formats .................................. 163
A.3.1 The OSPF packet header ............................... 164
A.3.2 The Hello packet ..................................... 166
A.3.3 The Database Description packet ...................... 168
A.3.4 The Link State Request packet ........................ 170
A.3.5 The Link State Update packet ......................... 171
A.3.6 The Link State Acknowledgment packet ................. 172
A.4 LSA formats .......................................... 173
A.4.1 The LSA header ....................................... 174
A.4.2 Router-LSAs .......................................... 176
A.4.3 Network-LSAs ......................................... 179
A.4.4 Summary-LSAs ......................................... 180
A.4.5 AS-external-LSAs ..................................... 182
B Architectural Constants .............................. 184
C Configurable Constants ............................... 186
C.1 Global parameters .................................... 186
C.2 Area parameters ...................................... 187
C.3 Router interface parameters .......................... 188
C.4 Virtual link parameters .............................. 190
C.5 NBMA network parameters .............................. 191
C.6 Point-to-MultiPoint network parameters ............... 191
C.7 Host route parameters ................................ 192
D Authentication ....................................... 193
D.1 Null authentication .................................. 193
D.2 Simple password authentication ....................... 193
D.3 Cryptographic authentication ......................... 194
D.4 Message generation ................................... 196
D.4.1 Generating Null authentication ....................... 196
D.4.2 Generating Simple password authentication ............ 197
D.4.3 Generating Cryptographic authentication .............. 197
D.5 Message verification ................................. 198
D.5.1 Verifying Null authentication ........................ 199
D.5.2 Verifying Simple password authentication ............. 199
D.5.3 Verifying Cryptographic authentication ............... 199
E An algorithm for assigning Link State IDs ............ 201
F Multiple interfaces to the same network/subnet ....... 203
G Differences from RFC 1583 ............................ 204
G.1 Enhancements to OSPF authentication .................. 204
G.2 Addition of Point-to-MultiPoint interface ............ 204
G.3 Support for overlapping area ranges .................. 205
16.6 増加のアップデート--ASの外部のLSAs… 152 16.7のイベントが経路指定テーブル変化153の結果、16.8Equal-費用多重通路を生成しました… 154 脚注をつけます。 155の参照箇所… 158 OSPFデータ形式… 160 OSPFパケットのA.1カプセル化… A.2Optionsがさばく160… 162 A.3 OSPFパケット・フォーマット… 163 OSPFパケットのヘッダーのA.3.1… 164A.3.2、Helloパケット… 166A.3.3、Database記述パケット… 168A.3.4、Link州Requestパケット… 170A.3.5、Link州Updateパケット… 171A.3.6、Link州Acknowledgmentパケット… 172 A.4 LSA形式… 173 LSAヘッダーのA.4.1… 174 A.4.2ルータ-LSAs… 176 A.4.3ネットワーク-LSAs… 179 A.4.4概要-LSAs… 180A.4.5、外部のLSAsとして… 182 B建築定数… 184 Cの構成可能な定数… 186 C.1のグローバルなパラメタ… 186 C.2領域パラメタ… 187 C.3ルータインタフェース・パラメータ… 188 C.4の仮想のリンクパラメータ… 190 C.5 NBMAはパラメタをネットワークでつなぎます… 191 C.6のポイントからMultiPointはパラメタをネットワークでつなぎます… 191 C.7はルートパラメタをホスティングします… 192 D認証… 193 D.1のヌル認証… 193 D.2の簡単なパスワード認証… 193 D.3の暗号の認証… 194D.4メッセージ世代… Nullが認証であると生成する196D.4.1… Simpleがパスワード認証であると生成する196D.4.2… Cryptographicが認証であると生成する197D.4.3… 197 D.5メッセージ検証… Null認証について確かめる198D.5.1… Simpleパスワード認証について確かめる199D.5.2… Cryptographic認証について確かめる199D.5.3… 州IDをLinkに割り当てるための1アルゴリズムあたり199E… 201F倍数は同じネットワーク/サブネットに連結します… 203 RFC1583からのG差… 204 OSPF認証へのG.1増進… PointからMultiPointへのインタフェースの204G.2追加… 204 重複する部分のG.3サポートは及びます… 205
Moy Standards Track [Page 4] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[4ページ]RFC2178OSPFバージョン1997年7月2日
G.4 A modification to the flooding algorithm ............. 206
G.5 Introduction of the MinLSArrival constant ............ 206
G.6 Optionally advertising point-to-point links as subnets 207
G.7 Advertising same external route from multiple areas .. 207
G.8 Retransmission of initial Database Description packets 209
G.9 Detecting interface MTU mismatches ................... 209
G.10 Deleting the TOS routing option ...................... 209
Security Considerations .............................. 210
Author's Address ..................................... 211
氾濫アルゴリズムへのG.4A変更… MinLSArrival定数の206G.5導入… 206 任意にポイントツーポイントの広告を出すG.6がサブネットとして複数の領域から207のG.7 Advertisingの同じ外部経路をリンクします。 207 209G.9 DetectingインタフェースMTUがミスマッチする初期のDatabase記述パケットのG.8 Retransmission… TOSルーティングオプションを削除する209G.10… 209 セキュリティ問題… 210作者のアドレス… 211
1. Introduction
1. 序論
This document is a specification of the Open Shortest Path First (OSPF) TCP/IP internet routing protocol. OSPF is classified as an Interior Gateway Protocol (IGP). This means that it distributes routing information between routers belonging to a single Autonomous System. The OSPF protocol is based on link-state or SPF technology. This is a departure from the Bellman-Ford base used by traditional TCP/IP internet routing protocols.
このドキュメントはオープンShortest Path First(OSPF)TCP/IPインターネットルーティング・プロトコルの仕様です。 OSPFはInteriorゲートウェイプロトコル(IGP)として分類されます。 これは、独身のAutonomous Systemに属すルータの間にルーティング情報を分配することを意味します。 OSPFプロトコルはリンク状態かSPF技術に基づいています。 これは伝統的なTCP/IPインターネットルーティング・プロトコルによって使用されるBellman-フォードベースからの出発です。
The OSPF protocol was developed by the OSPF working group of the Internet Engineering Task Force. It has been designed expressly for the TCP/IP internet environment, including explicit support for CIDR and the tagging of externally-derived routing information. OSPF also provides for the authentication of routing updates, and utilizes IP multicast when sending/receiving the updates. In addition, much work has been done to produce a protocol that responds quickly to topology changes, yet involves small amounts of routing protocol traffic.
OSPFプロトコルはインターネット・エンジニアリング・タスク・フォースのOSPFワーキンググループによって開発されました。 それはTCP/IPインターネット環境のために明白に設計されています、CIDRの明白なサポートと外部的に派生しているルーティング情報のタグ付けを含んでいて。 OSPFはまた、ルーティングアップデートの認証に備えて、アップデートを送るか、または受けるとき、IPマルチキャストを利用します。 さらに、すばやくトポロジー変化に応じますが、少量のルーティング・プロトコルトラフィックにかかわるプロトコルを作成するために多くの仕事をしました。
1.1. Protocol overview
1.1. プロトコル概要
OSPF routes IP packets based solely on the destination IP address found in the IP packet header. IP packets are routed "as is" -- they are not encapsulated in any further protocol headers as they transit the Autonomous System. OSPF is a dynamic routing protocol. It quickly detects topological changes in the AS (such as router interface failures) and calculates new loop-free routes after a period of convergence. This period of convergence is short and involves a minimum of routing traffic.
OSPFは唯一IPパケットのヘッダーで見つけられた送付先IPアドレスに基づくIPパケットを発送します。 IPパケットは「そのままで」発送されます--彼らがAutonomous Systemを通過するとき、それらはどんな一層のプロトコルヘッダーでもカプセル化されません。 OSPFはダイナミックルーティングプロトコルです。 それは、AS(ルータインタフェース失敗などの)にすぐに位相的な変化を検出して、集合の一区切りの後に新しい無輪のルートを計算します。 この期間の集合は、短く、最小ルーティングトラフィックにかかわります。
In a link-state routing protocol, each router maintains a database describing the Autonomous System's topology. This database is referred to as the link-state database. Each participating router has an identical database. Each individual piece of this database is a particular router's local state (e.g., the router's usable interfaces and reachable neighbors). The router distributes its local state throughout the Autonomous System by flooding.
LinkState方式プロトコルでは、各ルータはAutonomous Systemのトポロジーについて説明するデータベースを維持します。 このデータベースはリンク州のデータベースと呼ばれます。 それぞれの参加ルータには、同じデータベースがあります。 このデータベースの各個体は特定のルータの地方の状態(例えば、ルータの使用可能なインタフェースと届いている隣人)です。 ルータは氾濫で地方の状態をAutonomous Systemに分配します。
Moy Standards Track [Page 5] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[5ページ]RFC2178OSPFバージョン1997年7月2日
All routers run the exact same algorithm, in parallel. From the link-state database, each router constructs a tree of shortest paths with itself as root. This shortest-path tree gives the route to each destination in the Autonomous System. Externally derived routing information appears on the tree as leaves.
すべてのルータが平行の全く同じアルゴリズムを実行します。 リンク州のデータベースから、各ルータは根としてそれ自体で最短パスの木を組み立てます。 この最短パス木はAutonomous Systemの各目的地に進発令を下します。 外部的に派生しているルーティング情報は葉として木の上に現れます。
When several equal-cost routes to a destination exist, traffic is distributed equally among them. The cost of a route is described by a single dimensionless metric.
目的地への数個の等しい費用ルートが存在するとき、トラフィックはそれらの中で等しく分配されます。 ルートの費用はaシングル点によってメートル法で説明されます。
OSPF allows sets of networks to be grouped together. Such a grouping is called an area. The topology of an area is hidden from the rest of the Autonomous System. This information hiding enables a significant reduction in routing traffic. Also, routing within the area is determined only by the area's own topology, lending the area protection from bad routing data. An area is a generalization of an IP subnetted network.
OSPFは、ネットワークのセットが一緒に分類されるのを許容します。 そのような組分けは領域と呼ばれます。 Autonomous Systemの残り領域のトポロジーを隠されます。 この情報隠蔽はルーティングトラフィックのかなりの減少を可能にします。 また、領域の中のルーティングも領域の自己のトポロジーだけのそばで決定しています、悪いルーティングデータから領域保護を貸して。 領域はIPサブネット化したネットワークの一般化です。
OSPF enables the flexible configuration of IP subnets. Each route distributed by OSPF has a destination and mask. Two different subnets of the same IP network number may have different sizes (i.e., different masks). This is commonly referred to as variable length subnetting. A packet is routed to the best (i.e., longest or most specific) match. Host routes are considered to be subnets whose masks are "all ones" (0xffffffff).
OSPFはIPサブネットのフレキシブルな構成を可能にします。 OSPFによって分配された各ルートは目的地とマスクを持っています。 同じIPネットワーク・ナンバーの2つの異なったサブネットには、異なったサイズ(すなわち、異なったマスク)があるかもしれません。 これは一般的に可変長サブネッティングと呼ばれます。 パケットは最も良い(すなわち、最も長いか最も特定の)マッチに発送されます。 ホストルートはマスクが「すべてのもの」(0xffffffff)であるサブネットであると考えられます。
All OSPF protocol exchanges are authenticated. This means that only trusted routers can participate in the Autonomous System's routing. A variety of authentication schemes can be used; in fact, separate authentication schemes can be configured for each IP subnet.
すべてのOSPFプロトコル交換が認証されます。 これは、それが、ルータがAutonomous Systemのルーティングに参加できると信じただけであることを意味します。 さまざまな認証体系を使用できます。 事実上、それぞれのIPサブネットのために別々の認証体系を構成できます。
Externally derived routing data (e.g., routes learned from an Exterior Gateway Protocol such as BGP; see [Ref23]) is advertised throughout the Autonomous System. This externally derived data is kept separate from the OSPF protocol's link state data. Each external route can also be tagged by the advertising router, enabling the passing of additional information between routers on the boundary of the Autonomous System.
Autonomous System中に外部的に派生しているルーティングデータ(例えばルートはBGPなどのExteriorゲートウェイプロトコルから学びました; [Ref23]を見る)の広告を出します。 この外部的に派生しているデータはOSPFプロトコルのリンク州のデータから別々に保たれます。 また、広告ルータで各外部経路にタグ付けをすることができます、Autonomous Systemを境としてルータの間の追加情報の通過を可能にして。
1.2. Definitions of commonly used terms
1.2. 一般的に使用された期間の定義
This section provides definitions for terms that have a specific meaning to the OSPF protocol and that are used throughout the text. The reader unfamiliar with the Internet Protocol Suite is referred to [Ref13] for an introduction to IP.
このセクションはOSPFプロトコルに特定の意味を持って、テキスト中で使用される用語に定義を提供します。 インターネットプロトコルSuiteになじみのない読者はIPへの紹介について言及されます[Ref13]。
Moy Standards Track [Page 6] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[6ページ]RFC2178OSPFバージョン1997年7月2日
Router
A level three Internet Protocol packet switch. Formerly called a
gateway in much of the IP literature.
ルータA級試験threeインターネットプロトコルパケット交換機。 以前、IP文学の多くでゲートウェイと呼ばれます。
Autonomous System
A group of routers exchanging routing information via a common
routing protocol. Abbreviated as AS.
一般的なルーティングでルーティング情報を交換するルータの自治のSystem Aグループは議定書を作ります。 簡略化されています。
Interior Gateway Protocol
The routing protocol spoken by the routers belonging to an
Autonomous system. Abbreviated as IGP. Each Autonomous System has
a single IGP. Separate Autonomous Systems may be running
different IGPs.
Autonomousシステムに属すルータによって話されて、ルーティングが議定書の中で述べる内部のゲートウェイプロトコル。 IGPが簡略化されています。 各Autonomous Systemには、独身のIGPがあります。 別々のAutonomous Systemsは実行している異なったIGPsであるかもしれません。
Router ID
A 32-bit number assigned to each router running the OSPF protocol.
This number uniquely identifies the router within an Autonomous
System.
OSPFを実行しながら各ルータに割り当てられたルータのIDのA32ビットの番号は議定書を作ります。 この数はAutonomous Systemの中で唯一ルータを特定します。
Network
In this memo, an IP network/subnet/supernet. It is possible for
one physical network to be assigned multiple IP network/subnet
numbers. We consider these to be separate networks. Point-to-
point physical networks are an exception - they are considered a
single network no matter how many (if any at all) IP
network/subnet numbers are assigned to them.
Inをネットワークでつないでください。このメモ、IPネットワーク/サブネット/supernet。 複数のIPネットワーク/サブネット番号が1つの物理ネットワークに配属されるのは、可能です。 私たちは、これらが別々のネットワークであると考えます。 ポイントからポイントへの物理ネットワークは例外です--いくつの(全くいずれかであるなら)IPネットワーク/サブネット番号がそれらに割り当てられても、それらはただ一つのネットワークであると考えられます。
Network mask
A 32-bit number indicating the range of IP addresses residing on a
single IP network/subnet/supernet. This specification displays
network masks as hexadecimal numbers. For example, the network
mask for a class C IP network is displayed as 0xffffff00. Such a
mask is often displayed elsewhere in the literature as
255.255.255.0.
IPの範囲を示すネットワークのマスクのAの32ビットの番号が単一のIPネットワーク/サブネット/supernetの住んでいることを扱います。 この仕様は16進数としてネットワークマスクを表示します。 例えば、0xffffff00としてクラスC IPネットワークのためのネットワークマスクを表示します。 255.255として文学のほかの場所に表示して、しばしばそのようなマスクはそうです。.255 .0。
Point-to-point networks
A network that joins a single pair of routers. A 56Kb serial line
is an example of a point-to-point network.
ポイントツーポイントは1組のルータに合流するAネットワークをネットワークでつなぎます。 56KBのシリアル・ラインは二地点間ネットワークに関する例です。
Moy Standards Track [Page 7] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[7ページ]RFC2178OSPFバージョン1997年7月2日
Broadcast networks
Networks supporting many (more than two) attached routers,
together with the capability to address a single physical message
to all of the attached routers (broadcast). Neighboring routers
are discovered dynamically on these nets using OSPF's Hello
Protocol. The Hello Protocol itself takes advantage of the
broadcast capability. The OSPF protocol makes further use of
multicast capabilities, if they exist. Each pair of routers on a
broadcast network is assumed to be able to communicate directly.
An ethernet is an example of a broadcast network.
多く(2以上)をサポートする放送網Networksがルータを付けました、付属ルータ(放送)のすべてにただ一つの物理メッセージを扱う能力と共に。 隣接しているルータは、これらのネットでOSPFのHelloプロトコルを使用することでダイナミックに発見されます。 Helloプロトコル自体は放送能力を利用します。 存在しているなら、OSPFプロトコルはさらにマルチキャスト能力を利用します。 放送網のそれぞれの組のルータが直接伝達できると思われます。 イーサネットは放送網に関する例です。
Non-broadcast networks
Networks supporting many (more than two) routers, but having no
broadcast capability. Neighboring routers are maintained on these
nets using OSPF's Hello Protocol. However, due to the lack of
broadcast capability, some configuration information may be
necessary to aid in the discovery of neighbors. On non-broadcast
networks, OSPF protocol packets that are normally multicast need
to be sent to each neighboring router, in turn. An X.25 Public
Data Network (PDN) is an example of a non-broadcast network.
多くの(2以上)ルータをサポートしますが、放送能力が全くない非放送網Networks。 隣接しているルータは、これらのネットでOSPFのHelloプロトコルを使用することで維持されます。 しかしながら、放送能力の不足のために、何らかの設定情報が、隣人の発見で支援するのに必要であるかもしれません。 非放送網では、OSPFは通常、順番にそれぞれの隣接しているルータに送られるべきマルチキャストの必要性であるパケットについて議定書の中で述べます。 X.25 Public Data Network(PDN)は非放送網に関する例です。
OSPF runs in one of two modes over non-broadcast networks. The
first mode, called non-broadcast multi-access or NBMA, simulates
the operation of OSPF on a broadcast network. The second mode,
called Point-to-MultiPoint, treats the non-broadcast network as a
collection of point-to-point links. Non-broadcast networks are
referred to as NBMA networks or Point-to-MultiPoint networks,
depending on OSPF's mode of operation over the network.
OSPFは非放送網の上に2つのモードの1つへ駆け込みます。 非放送マルチアクセスかNBMAと呼ばれる最初のモードは放送網におけるOSPFの操作をシミュレートします。 PointからMultiPointと呼ばれる2番目のモードはポイントツーポイント接続の収集として非放送網を扱います。 ネットワークの上でOSPFの運転モードによって、非放送網はNBMAネットワークかPointからMultiPointへのネットワークと呼ばれます。
Interface
The connection between a router and one of its attached networks.
An interface has state information associated with it, which is
obtained from the underlying lower level protocols and the routing
protocol itself. An interface to a network has associated with it
a single IP address and mask (unless the network is an unnumbered
point-to-point network). An interface is sometimes also referred
to as a link.
ルータと付属ネットワークの1つとの関係を連結してください。 インタフェースには、それに関連している州の情報があります。(それは、基本的な下のレベルプロトコルとルーティング・プロトコル自体から得られます)。 ネットワークへのインタフェースはただ一つのIPアドレスとマスクをそれに関連づけました(ネットワークが無数の二地点間ネットワークでないなら)。 また、インタフェースは時々リンクと呼ばれます。
Neighboring routers
Two routers that have interfaces to a common network. Neighbor
relationships are maintained by, and usually dynamically
discovered by, OSPF's Hello Protocol.
一般的なネットワークにインタフェースを持っているルータTwoルータを近所付き合いさせます。 関係が維持されて、通常、ダイナミックに発見される隣人、OSPFのHelloプロトコル。
Adjacency
A relationship formed between selected neighboring routers for the
purpose of exchanging routing information. Not every pair of
neighboring routers become adjacent.
隣接番組A関係はルーティング情報を交換する目的のために選択された隣接しているルータの間で形成されました。 すべての組のどんな隣接しているルータも隣接するようになりません。
Moy Standards Track [Page 8] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[8ページ]RFC2178OSPFバージョン1997年7月2日
Link state advertisement
Unit of data describing the local state of a router or network.
For a router, this includes the state of the router's interfaces
and adjacencies. Each link state advertisement is flooded
throughout the routing domain. The collected link state
advertisements of all routers and networks forms the protocol's
link state database. Throughout this memo, link state
advertisement is abbreviated as LSA.
データがルータかネットワークの地方の事情について説明する州の広告Unitをリンクしてください。 ルータのために、これはルータのインタフェースと隣接番組の状態を含んでいます。 それぞれのリンク州の広告は経路ドメイン中で水につかっています。 すべてのルータとネットワークの集まっているリンク州の広告はプロトコルのリンク州のデータベースを形成します。 このメモ中では、リンク州の広告はLSAが簡略化されています。
Hello Protocol
The part of the OSPF protocol used to establish and maintain
neighbor relationships. On broadcast networks the Hello Protocol
can also dynamically discover neighboring routers.
こんにちは、OSPFの部分が議定書の中で述べるプロトコルは以前はよくそうしていました。隣人が関係であることを確証して、支持してください。 また、放送網では、Helloプロトコルはダイナミックに隣接しているルータを発見できます。
Flooding
The part of the OSPF protocol that distributes and synchronizes
the link-state database between OSPF routers.
OSPFルータの間のリンク州のデータベースを分配して、同期させるOSPFプロトコルの部分をあふれさせます。
Designated Router
Each broadcast and NBMA network that has at least two attached
routers has a Designated Router. The Designated Router generates
an LSA for the network and has other special responsibilities in
the running of the protocol. The Designated Router is elected by
the Hello Protocol.
指定されたRouter Eachは放送します、そして、少なくとも2つの付属ルータを持っているNBMAネットワークがDesignated Routerを持っています。 Designated RouterはネットワークのためにLSAを生成して、プロトコルの稼働で他の特別な責任を持っています。 Designated RouterはHelloプロトコルによって選出されます。
The Designated Router concept enables a reduction in the number of
adjacencies required on a broadcast or NBMA network. This in turn
reduces the amount of routing protocol traffic and the size of the
link-state database.
Designated Router概念は放送かNBMAネットワークで必要である隣接番組の数の減少を可能にします。 これはルーティング・プロトコルトラフィックの量とリンク州のデータベースのサイズを順番に減少させます。
Lower-level protocols
The underlying network access protocols that provide services to
the Internet Protocol and in turn the OSPF protocol. Examples of
these are the X.25 packet and frame levels for X.25 PDNs, and the
ethernet data link layer for ethernets.
基本的さがネットワークでつなぐ低レベルプロトコルはインターネットプロトコルに対するサービスを提供するプロトコルにアクセスします、そして、順番に、OSPFは議定書を作ります。 これらに関する例は、X.25 PDNsのためのX.25パケットとフレーム・レベルと、イーサネットのためのイーサネットデータ・リンク層です。
1.3. Brief history of link-state routing technology
1.3. LinkState方式技術に関する小史
OSPF is a link state routing protocol. Such protocols are also referred to in the literature as SPF-based or distributed-database protocols. This section gives a brief description of the developments in link-state technology that have influenced the OSPF protocol.
OSPFはリンク州のルーティング・プロトコルです。 また、そのようなプロトコルは文学にSPFベースか分散データベースプロトコルと呼ばれます。 このセクションはリンク州の技術におけるOSPFプロトコルに影響を及ぼした開発の簡単な説明を与えます。
The first link-state routing protocol was developed for use in the ARPANET packet switching network. This protocol is described in [Ref3]. It has formed the starting point for all other link-state protocols. The homogeneous ARPANET environment, i.e., single-vendor
最初のLinkState方式プロトコルはアルパネットパケット交換網における使用のために開発されました。 このプロトコルは[Ref3]で説明されます。 それは他のすべてのリンク州のプロトコルのための出発点を形成しました。 すなわち、均質のアルパネット環境、シングルベンダー
Moy Standards Track [Page 9] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[9ページ]RFC2178OSPFバージョン1997年7月2日
packet switches connected by synchronous serial lines, simplified the design and implementation of the original protocol.
パケット交換機は同期シリアル・ラインのそばで接続して、簡素化されて、オリジナルのデザインと実装は議定書を作ります。
Modifications to this protocol were proposed in [Ref4]. These modifications dealt with increasing the fault tolerance of the routing protocol through, among other things, adding a checksum to the LSAs (thereby detecting database corruption). The paper also included means for reducing the routing traffic overhead in a link- state protocol. This was accomplished by introducing mechanisms which enabled the interval between LSA originations to be increased by an order of magnitude.
このプロトコルへの変更は[Ref4]で提案されました。 LSAsにチェックサムを特に加えることでルーティングの耐障害性を増強する対処されたこれらの変更が議定書を作ります(その結果、データベース不正を検出します)。 また、含まれていた紙は、ルーティングトラフィックオーバーヘッドを下げるためにリンク州のプロトコルを意味します。 これは、LSA創作の間隔が1桁増強されるのを可能にしたメカニズムを紹介することによって、達成されました。
A link-state algorithm has also been proposed for use as an ISO IS-IS routing protocol. This protocol is described in [Ref2]. The protocol includes methods for data and routing traffic reduction when operating over broadcast networks. This is accomplished by election of a Designated Router for each broadcast network, which then originates an LSA for the network.
また、リンク州のアルゴリズムが使用のために提案された、ISO IS存在、ルーティング・プロトコル このプロトコルは[Ref2]で説明されます。 放送網の上で作動するとき、プロトコルはデータのためのメソッドとルーティング交通量削減を含んでいます。 これはネットワークのためのLSAがその時起因する各放送網のためにDesignated Routerの選挙で達成されます。
The OSPF Working Group of the IETF has extended this work in developing the OSPF protocol. The Designated Router concept has been greatly enhanced to further reduce the amount of routing traffic required. Multicast capabilities are utilized for additional routing bandwidth reduction. An area routing scheme has been developed enabling information hiding/protection/reduction. Finally, the algorithms have been tailored for efficient operation in TCP/IP internets.
IETFのOSPF作業部会はOSPFプロトコルを開発する際にこの仕事を広げました。 Designated Router概念は、トラフィックが必要としたルーティングの量をさらに減少させるために大いに高められました。 マルチキャスト能力は追加ルーティング帯域幅削減に利用されます。 情報隠蔽/保護/減少を可能にしながら、領域ルーティング体系を開発してあります。 最終的に、アルゴリズムはTCP/IPインターネットにおける効率的な操作のために合わせました。
1.4. Organization of this document
1.4. このドキュメントの組織
The first three sections of this specification give a general overview of the protocol's capabilities and functions. Sections 4-16 explain the protocol's mechanisms in detail. Packet formats, protocol constants and configuration items are specified in the appendices.
この仕様の最初の3つのセクションがプロトコルの能力と機能の概要を与えます。 セクション4-16は詳細にプロトコルのメカニズムについて説明します。 パケット・フォーマット、プロトコル定数、およびコンフィギュレーション品目は付録で指定されます。
Labels such as HelloInterval encountered in the text refer to protocol constants. They may or may not be configurable. Architectural constants are summarized in Appendix B. Configurable constants are summarized in Appendix C.
テキストで遭遇するHelloIntervalなどのラベルはプロトコル定数について言及します。 それらは構成可能であるかもしれません。 建築定数はAppendix B.にまとめられます。Configurable定数はAppendix Cにまとめられます。
The detailed specification of the protocol is presented in terms of data structures. This is done in order to make the explanation more precise. Implementations of the protocol are required to support the functionality described, but need not use the precise data structures that appear in this memo.
プロトコルの仕様詳細はデータ構造で提示されます。 説明をより正確にするようにこれをします。 プロトコルの実装は、機能性が説明したサポートに必要ですが、このメモに現れる正確な資料構造を使用する必要はありません。
Moy Standards Track [Page 10] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[10ページ]RFC2178OSPFバージョン1997年7月2日
1.5. Acknowledgments
1.5. 承認
The author would like to thank Ran Atkinson, Fred Baker, Jeffrey Burgan, Rob Coltun, Dino Farinacci, Vince Fuller, Phanindra Jujjavarapu, Milo Medin, Tom Pusateri, Kannan Varadhan, Zhaohui Zhang and the rest of the OSPF Working Group for the ideas and support they have given to this project.
作者は、このプロジェクトに与えたのをRanアトキンソン、フレッド・ベイカー、ジェフリー・ブルガン、ロブColtun、ディーノ・ファリナッチ、ビンス・フラー、Phanindra Jujjavarapu、ミロ・メディン、トムPusateri、Kannan Varadhan、Zhaohuiチャン、および考えとサポートのためのOSPF作業部会の残りに感謝したがっています。
The OSPF Point-to-MultiPoint interface is based on work done by Fred Baker.
OSPF PointからMultiPointへのインタフェースはフレッド・ベイカーによって行われた仕事に基づいています。
The OSPF Cryptographic Authentication option was developed by Fred Baker and Ran Atkinson.
OSPF Cryptographic Authenticationオプションはフレッド・ベイカーとRanアトキンソンによって開発されました。
2. The Link-state Database: organization and calculations
2. リンク州のデータベース: 組織と計算
The following subsections describe the organization of OSPF's link- state database, and the routing calculations that are performed on the database in order to produce a router's routing table.
以下の小区分はOSPFリンクの州のデータベースの組織、およびルータの経路指定テーブルを生産するためにデータベースに実行されるルーティング計算について説明します。
2.1. Representation of routers and networks
2.1. ルータとネットワークの代理
The Autonomous System's link-state database describes a directed graph. The vertices of the graph consist of routers and networks. A graph edge connects two routers when they are attached via a physical point-to-point network. An edge connecting a router to a network indicates that the router has an interface on the network. Networks can be either transit or stub networks. Transit networks are those capable of carrying data traffic that is neither locally originated nor locally destined. A transit network is represented by a graph vertex having both incoming and outgoing edges. A stub network's vertex has only incoming edges.
Autonomous Systemのリンク州のデータベースは有向グラフについて説明します。 グラフの頭頂はルータとネットワークから成ります。 それらが物理的な二地点間ネットワークを通して付けられているとき、グラフ縁は2つのルータを接続します。 ルータをネットワークに関連づける縁は、ルータがネットワークにインタフェースを持っているのを示します。 ネットワークは、トランジットかスタッブネットワークのどちらかであるかもしれません。 輸送網は局所的に溯源されないで、また局所的に運命づけられていないデータ通信量を運ぶことができるそれらです。 トランジットネットワークは両方の送受信の強味を持っているグラフ頂点によって代表されます。 スタッブネットワークの頂点には、入って来る強味しかありません。
The neighborhood of each network node in the graph depends on the network's type (point-to-point, broadcast, NBMA or Point-to- MultiPoint) and the number of routers having an interface to the network. Three cases are depicted in Figure 1a. Rectangles indicate routers. Circles and oblongs indicate networks. Router names are prefixed with the letters RT and network names with the letter N. Router interface names are prefixed by the letter I. Lines between routers indicate point-to-point networks. The left side of the figure shows networks with their connected routers, with the resulting graphs shown on the right.
グラフによるそれぞれのネットワーク・ノードの近所はネットワークのタイプ(ポイントツーポイント、放送、NBMAまたはPointからMultiPoint)とネットワークにインタフェースを持っているルータの数に頼っています。 3つのケースが図1aに表現されます。 長方形はルータを示します。 円と長方形はネットワークを示します。 ルータ名は手紙RTとネットワーク名で文字N.で前に置かれています。Routerインタフェース名はルータの間のI.線が、ポイントツーポイントがネットワークでつなぐのを示す手紙で前に置かれています。 図の左側はそれらの接続ルータ、右に示される結果として起こるグラフでネットワークを見せています。
Moy Standards Track [Page 11] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[11ページ]RFC2178OSPFバージョン1997年7月2日
**FROM**
****から
* |RT1|RT2|
+---+Ia +---+ * ------------
|RT1|------|RT2| T RT1| | X |
+---+ Ib+---+ O RT2| X | |
* Ia| | X |
* Ib| X | |
* |RT1|RT2| +---+ Ia+---+ * ------------ |RT1|------|RT2| T RT1| | X| +---+ イブ+---+ ○ RT2| X| | * Ia| | X| * イブ| X| |
Physical point-to-point networks
物理的な二地点間ネットワーク
**FROM**
+---+ *
|RT7| * |RT7| N3|
+---+ T ------------
| O RT7| | |
+----------------------+ * N3| X | |
N3 *
****+から---+ * |RT7| * |RT7| N3| +---+ T------------ | ○ RT7| | | +----------------------+ *N3| X| | N3*
Stub networks
スタッブネットワーク
+---+ +---+
|RT3| |RT4| |RT3|RT4|RT5|RT6|N2 |
+---+ +---+ * ------------------------
| N2 | * RT3| | | | | X |
+----------------------+ T RT4| | | | | X |
| | O RT5| | | | | X |
+---+ +---+ * RT6| | | | | X |
|RT5| |RT6| * N2| X | X | X | X | |
+---+ +---+
+---+ +---+ |RT3| |RT4| |RT3|RT4|RT5|RT6|N2| +---+ +---+ * ------------------------ | N2| * RT3| | | | | X| +----------------------+ T RT4| | | | | X| | | ○ RT5| | | | | X| +---+ +---+ *RT6| | | | | X| |RT5| |RT6| * N2| X| X| X| X| | +---+ +---+
Broadcast or NBMA networks
放送かNBMAネットワーク
Figure 1a: Network map components
図1a: ネットワーク地図の部品
Networks and routers are represented by vertices. An edge connects Vertex A to Vertex B iff the intersection of Column A and Row B is marked with an X.
ネットワークとルータは頭頂によって代表されます。 縁はVertex B iffにVertex Aを接続します。Column Aと通りBの交差点はXと共に示されます。
The top of Figure 1a shows two routers connected by a point-to-point link. In the resulting link-state database graph, the two router vertices are directly connected by a pair of edges, one in each direction. Interfaces to point-to-point networks need not be assigned IP addresses. When interface addresses are assigned, they are modelled as stub links, with each router advertising a stub connection to the other router's interface address. Optionally, an IP
図1aの先端は、2つのルータがポイントツーポイント接続のそばで接続したのを示します。 結果として起こるリンク州のデータベースグラフでは、2つのルータ頭頂が1組の縁によって直接接続されて、あるコネが各方向です。 IPアドレスは二地点間ネットワークへのインタフェースに割り当てられる必要はありません。 インターフェース・アドレスが割り当てられるとき、スタッブがもう片方のルータのインターフェース・アドレスとのスタッブ接続をそれぞれのルータ広告にリンクするとき、それらはモデル化されます。 任意に、IP
Moy Standards Track [Page 12] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[12ページ]RFC2178OSPFバージョン1997年7月2日
subnet can be assigned to the point-to-point network. In this case, both routers advertise a stub link to the IP subnet, instead of advertising each others' IP interface addresses.
指すポイントのネットワークにサブネットを配属できます。 この場合、両方のルータはIPサブネットへのスタッブリンクの広告を出します、それぞれ他のもののIPインターフェース・アドレスの広告を出すことの代わりに。
The middle of Figure 1a shows a network with only one attached router (i.e., a stub network). In this case, the network appears on the end of a stub connection in the link-state database's graph.
図1aの中央は1つの付属ルータ(すなわち、スタッブネットワーク)だけでネットワークを見せています。 この場合、ネットワークはリンク州のデータベースのグラフにスタッブ接続の終わりに現れます。
When multiple routers are attached to a broadcast network, the link- state database graph shows all routers bidirectionally connected to the network vertex. This is pictured at the bottom of Figure 1a.
複数のルータが放送網に付けられているとき、リンク州のデータベースグラフは、双方向がネットワーク頂点に接続したのをすべてのルータに示します。 これは図1aの下部に描写されます。
Each network (stub or transit) in the graph has an IP address and associated network mask. The mask indicates the number of nodes on the network. Hosts attached directly to routers (referred to as host routes) appear on the graph as stub networks. The network mask for a host route is always 0xffffffff, which indicates the presence of a single node.
グラフによる各ネットワーク(スタッブかトランジット)には、IPアドレスと関連ネットワークマスクがあります。 マスクはネットワークのノードの数を示します。 ルータ(ホストルートと呼ばれる)への直接添付のホストはスタッブネットワークとしてグラフで現れます。 いつもホストルートへのネットワークマスクは0xffffffffです。(その0xffffffffはただ一つのノードの存在を示します)。
2.1.1. Representation of non-broadcast networks
2.1.1. 非放送網の代理
As mentioned previously, OSPF can run over non-broadcast networks in one of two modes: NBMA or Point-to-MultiPoint. The choice of mode determines the way that the Hello protocol and flooding work over the non-broadcast network, and the way that the network is represented in the link-state database.
既述のとおり、OSPFは2つのモードの1つで非放送網をひくことができます: NBMAかポイントツーマルチポイント。 モードの選択は、非放送網の上でHelloプロトコルと氾濫が働いている方法を決定して、リンク州のデータベースでネットワークが代表される方法を決定します。
In NBMA mode, OSPF emulates operation over a broadcast network: a Designated Router is elected for the NBMA network, and the Designated Router originates an LSA for the network. The graph representation for broadcast networks and NBMA networks is identical. This representation is pictured in the middle of Figure 1a.
NBMAモードで、OSPFは放送網の上の操作を見習います: Designated RouterはNBMAネットワークのために選出されます、そして、Designated RouterはネットワークのためにLSAを溯源します。 放送網とNBMAネットワークのグラフ表現は同じです。 この表現は図1aの中央に描写されます。
NBMA mode is the most efficient way to run OSPF over non-broadcast networks, both in terms of link-state database size and in terms of the amount of routing protocol traffic. However, it has one significant restriction: it requires all routers attached to the NBMA network to be able to communicate directly. This restriction may be met on some non-broadcast networks, such as an ATM subnet utilizing SVCs. But it is often not met on other non-broadcast networks, such as PVC-only Frame Relay networks. On non-broadcast networks where not all routers can communicate directly you can break the non-broadcast network into logical subnets, with the routers on each subnet being able to communicate directly, and then run each separate subnet as an NBMA network (see [Ref15]). This however requires quite a bit of administrative overhead, and is prone to misconfiguration. It is probably better to run such a non-broadcast network in Point-to- Multipoint mode.
NBMAモードは非放送網の上と、そして、リンク州のデータベースサイズとルーティング・プロトコルトラフィックの量に関してOSPFを実行する最も効率的な方法です。 しかしながら、それには、1つの重要な制限があります: 直接伝達できるのがNBMAネットワークに付けられたすべてのルータを必要とします。 この制限は、ATMサブネットなどのいくつかの非放送網にSVCsを利用することで迎えられるかもしれません。 しかし、それはPVCだけFrame Relayネットワークなどの他の非放送網でしばしば会われるというわけではありません。 すべてのルータが直接伝達できるというわけではない非放送網では、あなたは非放送網を論理的なサブネットに細かく分けることができます、各サブネットのルータがNBMAネットワークとして直接伝達して、次に、それぞれの別々のサブネットを実行できる状態で([Ref15]を見てください)。 これは、しかしながら、かなりの管理オーバーヘッドを必要として、misconfigurationの傾向があります。 Pointから多点へのモードでそのような非放送網を経営しているのはたぶんより良いです。
Moy Standards Track [Page 13] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[13ページ]RFC2178OSPFバージョン1997年7月2日
In Point-to-MultiPoint mode, OSPF treats all router-to-router connections over the non-broadcast network as if they were point-to- point links. No Designated Router is elected for the network, nor is there an LSA generated for the network. In fact, a vertex for the Point-to-MultiPoint network does not appear in the graph of the link-state database.
PointからMultiPointへのモードで、OSPFはまるで彼らがポイントからポイントへのリンクであるかのようにルータからルータとの非放送網の上のすべての接続を扱います。 Designated Routerは全くネットワークのために選出されません、そして、ネットワークのために生成されたLSAがありません。 事実上、PointからMultiPointへのネットワークのための頂点はリンク州のデータベースのグラフに現れません。
Figure 1b illustrates the link-state database representation of a Point-to-MultiPoint network. On the left side of the figure, a Point-to-MultiPoint network is pictured. It is assumed that all routers can communicate directly, except for routers RT4 and RT5. I3 though I6 indicate the routers' IP interface addresses on the Point- to-MultiPoint network. In the graphical representation of the link- state database, routers that can communicate directly over the Point-to-MultiPoint network are joined by bidirectional edges, and each router also has a stub connection to its own IP interface address (which is in contrast to the representation of real point- to-point links; see Figure 1a).
図1bはPointからMultiPointへのネットワークのリンク州のデータベース代理を例証します。 図の左側では、PointからMultiPointへのネットワークが描写されています。 ルータのRT4とRT5を除いて、すべてのルータが直接伝達できると思われます。 I6はルータのIPを示しますが、I3はMultiPointへのPointネットワークにアドレスを連結します。 リンク州のデータベースのグラフ表示に、PointからMultiPointへのネットワークの上で直接伝達できるルータは双方向の縁によって接合されます、そして、また、各ルータには、それ自身のIPインターフェース・アドレスにはスタッブ接続があります。(ポイントへの本当のポイントリンクの表現; 図1a)を見ることと対照的になっている。
On some non-broadcast networks, use of Point-to-MultiPoint mode and data-link protocols such as Inverse ARP (see [Ref14]) will allow autodiscovery of OSPF neighbors even though broadcast support is not available.
いくつかの非放送網では、放送サポートは利用可能ではありませんが、Inverse ARP([Ref14]を見る)などのPointからMultiPointへのモードとデータリンクプロトコルの使用はOSPF隣人のautodiscoveryを許容するでしょう。
2.1.2. An example link-state database
2.1.2. 例のリンク州のデータベース
Figure 2 shows a sample map of an Autonomous System. The rectangle labelled H1 indicates a host, which has a SLIP connection to Router RT12. Router RT12 is therefore advertising a host route. Lines between routers indicate physical point-to-point networks. The only point-to-point network that has been assigned interface addresses is the one joining Routers RT6 and RT10. Routers RT5 and RT7 have BGP connections to other Autonomous Systems. A set of BGP-learned routes have been displayed for both of these routers.
図2はAutonomous Systemのサンプル地図を示しています。 H1とラベルされた長方形はホストを示します。(Router RT12にはそのホストは、SLIP接続がいます)。 したがって、ルータRT12はホストルートの広告を出しています。 ルータの間の線は物理的な二地点間ネットワークを示します。 インターフェース・アドレスが配属された唯一の二地点間ネットワークがRouters RT6とRT10を接合するものです。 他のAutonomous SystemsにはルータのRT5とRT7がBGP接続がいます。これらのルータの両方のために1セットのBGPが学術的なルートを表示しました。
A cost is associated with the output side of each router interface. This cost is configurable by the system administrator. The lower the cost,the more likely the interface is to be used to forward data traffic. Costs are also associated with the externally derived routing data (e.g., the BGP-learned routes).
費用はそれぞれのルータインタフェースのアウトプット側に関連しています。 この費用はシステム管理者が構成可能です。 費用が低ければ低いほど、インタフェースは、データ通信量を進めるのにより使用されそうです。 また、コストも外部的に派生しているルーティングデータ(例えば、BGPが学術的なルート)に関連しています。
The directed graph resulting from the map in Figure 2 is depicted in Figure 3. Arcs are labelled with the cost of the corresponding router output interface. Arcs having no labelled cost have a cost of 0. Note that arcs leading from networks to routers always have cost 0; they are significant nonetheless. Note also that the externally derived routing data appears on the graph as stubs.
図2の地図から生じる有向グラフは図3に表現されます。 アークは対応するルータ出力インタフェースの費用でラベルされます。 ラベルされた費用を全く持っていないアークが0の費用を持っています。 ネットワークからルータまで導くアークがいつも0かかったことに注意してください。 それらはそれにもかかわらず、重要です。 また、外部的に派生しているルーティングデータがスタッブとしてグラフで現れることに注意してください。
Moy Standards Track [Page 14] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[14ページ]RFC2178OSPFバージョン1997年7月2日
**FROM**
+---+ +---+
|RT3| |RT4| |RT3|RT4|RT5|RT6|
+---+ +---+ * --------------------
I3| N2 |I4 * RT3| | X | X | X |
+----------------------+ T RT4| X | | | X |
I5| |I6 O RT5| X | | | X |
+---+ +---+ * RT6| X | X | X | |
|RT5| |RT6| * I3| X | | | |
+---+ +---+ I4| | X | | |
I5| | | X | |
I6| | | | X |
****+から---+ +---+ |RT3| |RT4| |RT3|RT4|RT5|RT6| +---+ +---+ * -------------------- I3| N2|I4*RT3| | X| X| X| +----------------------+ T RT4| X| | | X| I5| |I6O RT5| X| | | X| +---+ +---+ *RT6| X| X| X| | |RT5| |RT6| * I3| X| | | | +---+ +---+ I4| | X| | | I5| | | X| | I6| | | | X|
Figure 1b: Network map components
Point-to-MultiPoint networks
図1b: ネットワーク地図コンポーネントPointからMultiPointへのネットワーク
All routers can communicate directly over N2, except
routers RT4 and RT5. I3 through I6 indicate IP
interface addresses
ルータのRT4とRT5を除いて、すべてのルータがN2の上で直接伝達できます。 I3からI6はIPインターフェース・アドレスを示します。
Moy Standards Track [Page 15] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[15ページ]RFC2178OSPFバージョン1997年7月2日
+
| 3+---+ N12 N14
N1|--|RT1|\ 1 \ N13 /
| +---+ \ 8\ |8/8
+ \ ____ \|/
/ \ 1+---+8 8+---+6
* N3 *---|RT4|------|RT5|--------+
\____/ +---+ +---+ |
+ / | |7 |
| 3+---+ / | | |
N2|--|RT2|/1 |1 |6 |
| +---+ +---+8 6+---+ |
+ |RT3|--------------|RT6| |
+---+ +---+ |
|2 Ia|7 |
| | |
+---------+ | |
N4 | |
| |
| |
N11 | |
+---------+ | |
| | | N12
|3 | |6 2/
+---+ | +---+/
|RT9| | |RT7|---N15
+---+ | +---+ 9
|1 + | |1
_|__ | Ib|5 __|_
/ \ 1+----+2 | 3+----+1 / \
* N9 *------|RT11|----|---|RT10|---* N6 *
\____/ +----+ | +----+ \____/
| | |
|1 + |1
+--+ 10+----+ N8 +---+
|H1|-----|RT12| |RT8|
+--+SLIP +----+ +---+
|2 |4
| |
+---------+ +--------+
N10 N7
+ | 3+---+ N12 N14 N1|--|RT1|1円の\N13/| +---+ \ 8\ |8/8 + \ ____ \|/ / \ 1+---+8 8+---+6 *N3*---|RT4|------|RT5|--------+ \____/ +---+ +---+ | + / | |7 | | 3+---+ / | | | N2|--|RT2|/1 |1 |6 | | +---+ +---+8 6+---+ | + |RT3|--------------|RT6| | +---+ +---+ | |2 Ia|7 | | | | +---------+ | | N4| | | | | | N11| | +---------+ | | | | | N12|3 | |6 2/ +---+ | +---+/ |RT9| | |RT7|---N15+---+ | +---+ 9 |1 + | |1 _|__ | イブ|5 __|_ / \ 1+----+2 | 3+----+1/\*N9*------|RT11|----|---|RT10|---* N6*\____/ +----+ | +----+ \____/ | | | |1 + |1 +--+ 10+----+ N8+---+ |H1|-----|RT12| |RT8| +--+ メモ用紙+----+ +---+ |2 |4 | | +---------+ +--------+ N10 N7
Figure 2: A sample Autonomous System
図2: サンプルAutonomous System
Moy Standards Track [Page 16] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[16ページ]RFC2178OSPFバージョン1997年7月2日
**FROM**
****から
|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|
|1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9|
----- ---------------------------------------------
RT1| | | | | | | | | | | | |0 | | | |
RT2| | | | | | | | | | | | |0 | | | |
RT3| | | | | |6 | | | | | | |0 | | | |
RT4| | | | |8 | | | | | | | |0 | | | |
RT5| | | |8 | |6 |6 | | | | | | | | | |
RT6| | |8 | |7 | | | | |5 | | | | | | |
RT7| | | | |6 | | | | | | | | |0 | | |
* RT8| | | | | | | | | | | | | |0 | | |
* RT9| | | | | | | | | | | | | | | |0 |
T RT10| | | | | |7 | | | | | | | |0 |0 | |
O RT11| | | | | | | | | | | | | | |0 |0 |
* RT12| | | | | | | | | | | | | | | |0 |
* N1|3 | | | | | | | | | | | | | | | |
N2| |3 | | | | | | | | | | | | | | |
N3|1 |1 |1 |1 | | | | | | | | | | | | |
N4| | |2 | | | | | | | | | | | | | |
N6| | | | | | |1 |1 | |1 | | | | | | |
N7| | | | | | | |4 | | | | | | | | |
N8| | | | | | | | | |3 |2 | | | | | |
N9| | | | | | | | |1 | |1 |1 | | | | |
N10| | | | | | | | | | | |2 | | | | |
N11| | | | | | | | |3 | | | | | | | |
N12| | | | |8 | |2 | | | | | | | | | |
N13| | | | |8 | | | | | | | | | | | |
N14| | | | |8 | | | | | | | | | | | |
N15| | | | | | |9 | | | | | | | | | |
H1| | | | | | | | | | | |10| | | | |
| RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT| |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9| ----- --------------------------------------------- RT1| | | | | | | | | | | | |0 | | | | RT2| | | | | | | | | | | | |0 | | | | RT3| | | | | |6 | | | | | | |0 | | | | RT4| | | | |8 | | | | | | | |0 | | | | RT5| | | |8 | |6 |6 | | | | | | | | | | RT6| | |8 | |7 | | | | |5 | | | | | | | RT7| | | | |6 | | | | | | | | |0 | | | * RT8| | | | | | | | | | | | | |0 | | | * RT9| | | | | | | | | | | | | | | |0 | T RT10| | | | | |7 | | | | | | | |0 |0 | | ○ RT11| | | | | | | | | | | | | | |0 |0 | * RT12| | | | | | | | | | | | | | | |0 | * N1|3 | | | | | | | | | | | | | | | | N2| |3 | | | | | | | | | | | | | | | N3|1 |1 |1 |1 | | | | | | | | | | | | | N4| | |2 | | | | | | | | | | | | | | N6| | | | | | |1 |1 | |1 | | | | | | | N7| | | | | | | |4 | | | | | | | | | N8| | | | | | | | | |3 |2 | | | | | | N9| | | | | | | | |1 | |1 |1 | | | | | N10| | | | | | | | | | | |2 | | | | | N11| | | | | | | | |3 | | | | | | | | N12| | | | |8 | |2 | | | | | | | | | | N13| | | | |8 | | | | | | | | | | | | N14| | | | |8 | | | | | | | | | | | | N15| | | | | | |9 | | | | | | | | | | H1| | | | | | | | | | | |10| | | | |
Figure 3: The resulting directed graph
図3: 結果として起こる有向グラフ
Networks and routers are represented by vertices.
An edge of cost X connects Vertex A to Vertex B iff
the intersection of Column A and Row B is marked
with an X.
ネットワークとルータは頭頂によって代表されます。 費用Xの縁はVertex B iffにVertex Aを接続します。Column Aと通りBの交差点はXと共に示されます。
The link-state database is pieced together from LSAs generated by the routers. In the associated graphical representation, the neighborhood of each router or transit network is represented in a single, separate LSA. Figure 4 shows these LSAs graphically. Router RT12 has an interface to two broadcast networks and a SLIP line to a host. Network N6 is a broadcast network with three attached routers. The cost of all links from Network N6 to its attached routers is 0.
リンク州のデータベースはルータによって生成されたLSAsから継ぎを当てられます。 関連グラフ表示で、それぞれのルータかトランジットネットワークの近所は単一の、そして、別々のLSAで代表されます。 図4はグラフィカルにこれらのLSAsを示しています。 ルータRT12は2つの放送網へのインタフェースとSLIP系列をホストに持っています。 ネットワークN6は3つの付属ルータがある放送網です。 Network N6から付属ルータへのすべてのリンクの費用は0です。
Moy Standards Track [Page 17] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[17ページ]RFC2178OSPFバージョン1997年7月2日
Note that the LSA for Network N6 is actually generated by one of the network's attached routers: the router that has been elected Designated Router for the network.
Network N6のためのLSAが実際にネットワークの付属ルータの1つによって生成されることに注意してください: ネットワークのためにDesignated Routerに選出されたルータ。
2.2. The shortest-path tree
2.2. 最短パス木
When no OSPF areas are configured, each router in the Autonomous System has an identical link-state database, leading to an identical graphical representation. A router generates its routing table from this graph by calculating a tree of shortest paths with the router itself as root. Obviously, the shortest- path tree depends on the router doing the calculation. The shortest-path tree for Router RT6 in our example is depicted in Figure 5.
OSPF領域が全く構成されないとき、Autonomous Systemの各ルータには、同じリンク州のデータベースがあります、同じグラフ表示に通じて。 ルータは、根としてルータ自体でこのグラフから最短パスの木について計算することによって、経路指定テーブルを生成します。 明らかに、最も低い経路木は計算をするルータによります。 私たちの例のRouter RT6のための最短パス木は図5に表現されます。
The tree gives the entire path to any destination network or host. However, only the next hop to the destination is used in the forwarding process. Note also that the best route to any router has also been calculated. For the processing of external data, we note the next hop and distance to any router advertising external routes. The resulting routing table for Router RT6 is pictured in Table 2. Note that there is a separate route for each end of a numbered point-to-point network (in this case, the serial line between Routers RT6 and RT10).
木はどんな送信先ネットワークやホストにも全体の経路を与えます。 しかしながら、目的地への次のホップだけが推進プロセスで使用されます。 また、また、どんなルータへの最も良いルートも計算してあることに注意してください。 外部のデータの処理のために、私たちは、次のホップに注意して、どんなルータ広告にも外部経路を遠ざけます。 Router RT6のための結果として起こる経路指定テーブルはTable2に描写されます。 別々のルートが番号付の二地点間ネットワーク(この場合Routers RT6とRT10の間のシリアル・ライン)の各端の間あることに注意してください。
**FROM** **FROM**
****からの****から
|RT12|N9|N10|H1| |RT9|RT11|RT12|N9|
* -------------------- * ----------------------
* RT12| | | | | * RT9| | | |0 |
T N9|1 | | | | T RT11| | | |0 |
O N10|2 | | | | O RT12| | | |0 |
* H1|10 | | | | * N9| | | | |
* *
RT12's router-LSA N9's network-LSA
| RT12|N9|N10|H1| |RT9|RT11|RT12|N9| * -------------------- * ---------------------- * RT12| | | | | * RT9| | | |0 | T N9|1 | | | | T RT11| | | |0 | ○ N10|2 | | | | ○ RT12| | | |0 | * H1|10 | | | | * N9| | | | | * * RT12のルータ-LSA N9のネットワーク-LSA
Figure 4: Individual link state components
図4: 個々のリンク州の部品
Networks and routers are represented by vertices.
An edge of cost X connects Vertex A to Vertex B iff
the intersection of Column A and Row B is marked
with an X.
ネットワークとルータは頭頂によって代表されます。 費用Xの縁はVertex B iffにVertex Aを接続します。Column Aと通りBの交差点はXと共に示されます。
Moy Standards Track [Page 18] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[18ページ]RFC2178OSPFバージョン1997年7月2日
RT6(origin)
RT5 o------------o-----------o Ib
/|\ 6 |\ 7
8/8|8\ | \
/ | \ 6| \
o | o | \7
N12 o N14 | \
N13 2 | \
N4 o-----o RT3 \
/ \ 5
1/ RT10 o-------o Ia
/ |\
RT4 o-----o N3 3| \1
/| | \ N6 RT7
/ | N8 o o---------o
/ | | | /|
RT2 o o RT1 | | 2/ |9
/ | | |RT8 / |
/3 |3 RT11 o o o o
/ | | | N12 N15
N2 o o N1 1| |4
| |
N9 o o N7
/|
/ |
N11 RT9 / |RT12
o--------o-------o o--------o H1
3 | 10
|2
|
o N10
RT6(発生源)RT5o------------o-----------o イブ/|\ 6 |\ 7 8/8|8\ | \ / | \ 6| \o| o | 7円のN12o N14| N13 2円| \N4o-----o RT3\/\5 1/ RT10o-------o Ia/|\RT4o-----o N3 3| \1 /| | \N6 RT7/| N8o o---------o / | | | /| RT2o o RT1| | 2/ |9 / | | |RT8/| /3 |3 RT11o o o o/| | | N12 N15 N2o o N1 1| |4 | | N9o o N7/| / | N11 RT9/|RT12o--------o-------o o--------o H1 3| 10 |2 | o N10
Figure 5: The SPF tree for Router RT6
図5: Router RT6のためのSPF木
Edges that are not marked with a cost have a cost of of zero (these
are network-to-router links). Routes to networks N12-N15 are external
information that is considered in Section 2.3
そうする縁はaで費用をマークしませんでした。ゼロ(これらはネットワークからルータへのリンクである)について費用を持っています。 ネットワークN12-N15へのルートはセクション2.3で考えられる外部の情報です。
Moy Standards Track [Page 19] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[19ページ]RFC2178OSPFバージョン1997年7月2日
Destination Next Hop Distance
__________________________________
N1 RT3 10
N2 RT3 10
N3 RT3 7
N4 RT3 8
Ib * 7
Ia RT10 12
N6 RT10 8
N7 RT10 12
N8 RT10 10
N9 RT10 11
N10 RT10 13
N11 RT10 14
H1 RT10 21
__________________________________
RT5 RT5 6
RT7 RT10 8
次のホップが遠ざける目的地__________________________________ N1 RT3 10N2 RT3 10N3 RT3 7 N4 RT3 8イブ*7Ia RT10 12 N6 RT10 8N7 RT10 12 N8 RT10 10 N9 RT10 11 N10 RT10 13 N11 RT10 14 H1 RT10 21__________________________________ RT5 RT5 6 RT7 RT10 8
Table 2: The portion of Router RT6's routing table listing local
destinations.
テーブル2: 地方の目的地を記載するRouter RT6の経路指定テーブルの一部。
Routes to networks belonging to other AS'es (such as N12) appear as dashed lines on the shortest path tree in Figure 5. Use of this externally derived routing information is considered in the next section.
他のAS'es(N12などの)に属すネットワークへのルートは投げつけられた線として図5の最短パス木の上に現れます。 この外部的に派生しているルーティング情報の使用は次のセクションで考えられます。
2.3. Use of external routing information
2.3. 外部のルーティング情報の使用
After the tree is created the external routing information is examined. This external routing information may originate from another routing protocol such as BGP, or be statically configured (static routes). Default routes can also be included as part of the Autonomous System's external routing information.
木が作成された後に、外部のルーティング情報は調べられます。 この外部のルーティング情報は、BGPなどの別のルーティング・プロトコルから発するか、または静的に構成されるかもしれません(スタティックルート)。 また、Autonomous Systemの外部のルーティング情報の一部としてデフォルトルートを含むことができます。
External routing information is flooded unaltered throughout the AS. In our example, all the routers in the Autonomous System know that Router RT7 has two external routes, with metrics 2 and 9.
外部のルーティング情報はAS中で非変更されていた状態で水につかっています。 私たちの例では、Autonomous Systemのすべてのルータが、Router RT7には2個の外部経路があるのを知っています、測定基準2と9で。
OSPF supports two types of external metrics. Type 1 external metrics are expressed in the same units as OSPF interface cost (i.e., in terms of the link state metric). Type 2 external metrics are an order of magnitude larger; any Type 2 metric is considered greater than the cost of any path internal to the AS. Use of Type 2 external metrics assumes that routing between AS'es is the major cost of routing a packet, and eliminates the need for conversion of external costs to internal link state metrics.
OSPFは2つのタイプの外部の測定基準をサポートします。 タイプの1の外部の測定基準はOSPFインタフェース費用(すなわち、リンク状態メートル法の)と同じユニットに表されます。 タイプ2の外部の測定基準は1桁より大きいです。 Type2メートル法であることは、いくらか、ASへの内部の考えられたいずれの費用より大きい経路です。 Typeの2の外部の測定基準の使用は、AS'esの間のルーティングがパケットを発送する主要な費用であると仮定して、外部のコストの変換の必要性を内部のリンク州の測定基準に排除します。
Moy Standards Track [Page 20] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[20ページ]RFC2178OSPFバージョン1997年7月2日
As an example of Type 1 external metric processing, suppose that the Routers RT7 and RT5 in Figure 2 are advertising Type 1 external metrics. For each advertised external route, the total cost from Router RT6 is calculated as the sum of the external route's advertised cost and the distance from Router RT6 to the advertising router. When two routers are advertising the same external destination, RT6 picks the advertising router providing the minimum total cost. RT6 then sets the next hop to the external destination equal to the next hop that would be used when routing packets to the chosen advertising router.
Typeの1の外部のメトリック処理に関する例として、図2のRouters RT7とRT5がTypeの1の外部の測定基準の広告を出していると仮定してください。 それぞれの広告を出している外部経路において、外部経路の合計がRouter RT6から広告ルータまで費用と距離の広告を出したので、Router RT6からの総費用は計算されます。 2つのルータが同じ外部の目的地の広告を出しているとき、RT6は、最小の総費用を提供しながら、広告ルータを選びます。 そしてRT6は選ばれた広告ルータにパケットを発送するとき使用される次のホップと等しい外部の目的地に次のホップを設定します。
In Figure 2, both Router RT5 and RT7 are advertising an external route to destination Network N12. Router RT7 is preferred since it is advertising N12 at a distance of 10 (8+2) to Router RT6, which is better than Router RT5's 14 (6+8). Table 3 shows the entries that are added to the routing table when external routes are examined:
図2では、Router RT5とRT7の両方が目的地Network N12に外部経路の広告を出しています。 ルータRT7がそれが10の遠方の広告N12であって、好まれる、(8、+2、)、Router RT6に、どちらがRouter RT5の14より良いか、(6、+8、) テーブル3は、外部経路がいつ調べられるかを経路指定テーブルに加えられるエントリーに案内します:
Destination Next Hop Distance
__________________________________
N12 RT10 10
N13 RT5 14
N14 RT5 14
N15 RT10 17
次のホップが遠ざける目的地__________________________________ N12 RT10 10 N13 RT5 14N14 RT5 14N15 RT10 17
Table 3: The portion of Router RT6's routing table
listing external destinations.
テーブル3: 外部の目的地を記載するRouter RT6の経路指定テーブルの一部。
Processing of Type 2 external metrics is simpler. The AS boundary router advertising the smallest external metric is chosen, regardless of the internal distance to the AS boundary router. Suppose in our example both Router RT5 and Router RT7 were advertising Type 2 external routes. Then all traffic destined for Network N12 would be forwarded to Router RT7, since 2 < 8. When several equal-cost Type 2 routes exist, the internal distance to the advertising routers is used to break the tie.
Type2の外部の測定基準の処理は、より簡単です。 広告を出す中で外部最も小さいAS境界ルータ、メートル法、AS境界ルータへの内部の距離にかかわらず、選ばれています。 私たちの例でRouter RT5とRouter RT7の両方が広告Type2外部経路であったと仮定してください。 そして、2<8以来Network N12のために運命づけられたすべての交通をRouter RT7に送るでしょう。 数個ときに、等しい費用Type2ルートは存在していて、広告ルータへの内部の距離は、繋がりを壊すのに使用されます。
Both Type 1 and Type 2 external metrics can be present in the AS at the same time. In that event, Type 1 external metrics always take precedence.
Type1とType2の外部の測定基準の両方が同時に、ASに存在している場合があります。 その場合には、Type1の外部の測定基準はいつも優先します。
This section has assumed that packets destined for external destinations are always routed through the advertising AS boundary router. This is not always desirable. For example, suppose in Figure 2 there is an additional router attached to Network N6, called Router RTX. Suppose further that RTX does not participate in OSPF
このセクションは、外部の目的地に運命づけられたパケットが広告AS境界ルータを通していつも発送されると仮定しました。 これはいつも望ましいというわけではありません。 例えば、図2でRouter RTXと呼ばれるNetwork N6に付けられた追加ルータがあると仮定してください。 RTXがOSPFに参加しないとさらに仮定してください。
Moy Standards Track [Page 21] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[21ページ]RFC2178OSPFバージョン1997年7月2日
routing, but does exchange BGP information with the AS boundary router RT7. Then, Router RT7 would end up advertising OSPF external routes for all destinations that should be routed to RTX. An extra hop will sometimes be introduced if packets for these destinations need always be routed first to Router RT7 (the advertising router).
AS境界ルータRT7とBGP情報を交換するのを除いたルーティング。 そして、Router RT7は結局、RTXに発送されるべきであるすべての目的地にOSPF外部経路の広告を出すでしょう。 いつも最初に、Router RT7(広告ルータ)にこれらの目的地へのパケットを発送しなければならないと、時々余分なホップを導入するでしょう。
To deal with this situation, the OSPF protocol allows an AS boundary router to specify a "forwarding address" in its AS- external-LSAs. In the above example, Router RT7 would specify RTX's IP address as the "forwarding address" for all those destinations whose packets should be routed directly to RTX.
この状況に対処するために、OSPFプロトコルで、AS境界ルータはASの外部のLSAsの「フォーワーディング・アドレス」を指定できます。 上記の例では、Router RT7はパケットが直接RTXに発送されるべきであるそれらのすべての目的地への「フォーワーディング・アドレス」としてRTXのIPアドレスを指定するでしょう。
The "forwarding address" has one other application. It enables routers in the Autonomous System's interior to function as "route servers". For example, in Figure 2 the router RT6 could become a route server, gaining external routing information through a combination of static configuration and external routing protocols. RT6 would then start advertising itself as an AS boundary router, and would originate a collection of OSPF AS-external-LSAs. In each AS- external-LSA, Router RT6 would specify the correct Autonomous System exit point to use for the destination through appropriate setting of the LSA's "forwarding address" field.
「フォーワーディング・アドレス」には、他の1つのアプリケーションがあります。 それは、Autonomous Systemの内部のルータが「ルートサーバ」として機能するのを可能にします。 例えば、図2では、ルータRT6はルートサーバになることができました、静的な構成と外部のルーティング・プロトコルの組み合わせで外部のルーティング情報を獲得して。 RT6は次に、AS境界ルータとして自分を売り込み始めて、OSPF ASの外部のLSAsの収集を溯源するでしょう。 それぞれのASの外部のLSAでは、Router RT6は目的地にLSAの「フォーワーディング・アドレス」分野の適切な設定を通して使用する正しいAutonomous Systemエキジットポイントを指定するでしょう。
2.4. Equal-cost multipath
2.4. 等価コストマルチパス
The above discussion has been simplified by considering only a single route to any destination. In reality, if multiple equal-cost routes to a destination exist, they are all discovered and used. This requires no conceptual changes to the algorithm, and its discussion is postponed until we consider the tree-building process in more detail.
上の議論は、どんな目的地ともただ一つのルートだけを考えることによって、簡素化されました。 目的地への複数の等しい費用ルートが存在しているなら、それらは、ほんとうは、すべて発見されて、使用されます。 これはアルゴリズムへの概念変化を全く必要としません、そして、私たちがさらに詳細に木建築の過程を考えるまで、議論は延期されます。
With equal cost multipath, a router potentially has several available next hops towards any given destination.
等しい費用多重通路によって、ルータは潜在的にどんな与えられた目的地に向かっても次のいくつかの利用可能なホップを持っています。
3. Splitting the AS into Areas
3. 分かれる、領域
OSPF allows collections of contiguous networks and hosts to be grouped together. Such a group, together with the routers having interfaces to any one of the included networks, is called an area. Each area runs a separate copy of the basic link-state routing algorithm. This means that each area has its own link-state database and corresponding graph, as explained in the previous section.
OSPFは、隣接のネットワークとホストの収集が一緒に分類されるのを許容します。 そのようなグループは含まれているネットワークのいずれにもインタフェースを持っているルータと共に領域と呼ばれます。 各領域は基本的なリンク州のルーティング・アルゴリズムの別々のコピーを動かします。 これは、前項で説明されるように各領域にはそれ自身のリンク州のデータベースと対応するグラフがあることを意味します。
The topology of an area is invisible from the outside of the area. Conversely, routers internal to a given area know nothing of the detailed topology external to the area. This isolation of knowledge enables the protocol to effect a marked reduction in routing traffic
領域のトポロジーは領域の外部から目に見えません。 逆に、与えられた領域への内部のルータはその領域への外部の詳細なトポロジーについて何も知りません。 知識のこの孤立は、プロトコルがルーティング交通の著しい減少に作用するのを可能にします。
Moy Standards Track [Page 22] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[22ページ]RFC2178OSPFバージョン1997年7月2日
as compared to treating the entire Autonomous System as a single link-state domain.
ただ一つのリンク州のドメインとして全体のAutonomous Systemを扱うと比べて。
With the introduction of areas, it is no longer true that all routers in the AS have an identical link-state database. A router actually has a separate link-state database for each area it is connected to. (Routers connected to multiple areas are called area border routers). Two routers belonging to the same area have, for that area, identical area link-state databases.
領域の導入では、ASのすべてのルータには同じリンク州のデータベースがあるのは、もう本当ではありません。 ルータには、それが関連づけられる各領域のための別々のリンク州のデータベースが実際にあります。 (複数の領域に関連づけられたルータは境界ルータと呼ばれます。) 同じ領域に属す2つのルータが同じ領域リンク州のデータベースをその領域に持っています。
Routing in the Autonomous System takes place on two levels, depending on whether the source and destination of a packet reside in the same area (intra-area routing is used) or different areas (inter-area routing is used). In intra-area routing, the packet is routed solely on information obtained within the area; no routing information obtained from outside the area can be used. This protects intra-area routing from the injection of bad routing information. We discuss inter-area routing in Section 3.2.
Autonomous Systemのルート設定は2つのレベルで行われます、パケットのソースと目的地が同じ領域(イントラ領域ルーティングは使用されている)か異なった領域にあるかどうかに(相互領域ルーティングは使用されています)よって。 イントラ領域ルーティングで、パケットは唯一領域の中で得られた情報で発送されます。 領域の外から得られなかったルーティング情報は全く使用できます。 これは悪いルーティング情報の注射からイントラ領域ルーティングを保護します。 私たちはセクション3.2で相互領域ルーティングについて議論します。
3.1. The backbone of the Autonomous System
3.1. Autonomous Systemの背骨
The OSPF backbone is the special OSPF Area 0 (often written as Area 0.0.0.0, since OSPF Area ID's are typically formatted as IP addresses). The OSPF backbone always contains all area border routers. The backbone is responsible for distributing routing information between non-backbone areas. The backbone must be contiguous. However, it need not be physically contiguous; backbone connectivity can be established/maintained through the configuration of virtual links.
OSPF背骨が特別なOSPF Area0である、(Areaとしてしばしば書かれている、0.0、.0、.0、OSPF Area IDがIPアドレスとして通常フォーマットされている、) OSPF背骨はいつもすべての境界ルータを含みます。 背骨は非背骨領域の間にルーティング情報を分配するのに原因となります。 背骨は隣接であるに違いありません。 しかしながら、それは物理的に隣接である必要はありません。 仮想のリンクの構成を通して背骨の接続性を確立するか、または維持できます。
Virtual links can be configured between any two backbone routers that have an interface to a common non-backbone area. Virtual links belong to the backbone. The protocol treats two routers joined by a virtual link as if they were connected by an unnumbered point-to- point backbone network. On the graph of the backbone, two such routers are joined by arcs whose costs are the intra-area distances between the two routers. The routing protocol traffic that flows along the virtual link uses intra-area routing only.
一般的な非背骨領域にインタフェースを持っているどんな2つの背骨ルータの間でも仮想のリンクを構成できます。 仮想のリンクは背骨に属します。 まるでそれらが無数のポイントからポイントへの背骨ネットワークによって接続されるかのように2つのルータが仮想のリンクで参加したプロトコルの御馳走。 背骨のグラフでは、そのような2つのルータがコストが2つのルータの間のイントラ領域距離であるアークによって接合されます。 仮想のリンクに沿って流れるルーティング・プロトコル交通はイントラ領域ルーティングだけを使用します。
3.2. Inter-area routing
3.2. 相互領域ルーティング
When routing a packet between two non-backbone areas the backbone is used. The path that the packet will travel can be broken up into three contiguous pieces: an intra-area path from the source to an area border router, a backbone path between the source and destination areas, and then another intra-area path to the destination. The algorithm finds the set of such paths that have the smallest cost.
2つの非背骨領域の間にパケットを発送するとき、背骨は使用されています。 パケットが旅行する経路を3つの隣接の断片に終えることができます: ソースから境界ルータまでのイントラ領域経路、ソースと目的地の地域の間の背骨経路、およびそして、目的地への別のイントラ領域経路。 アルゴリズムは最も少ない費用を持っているそのような経路のセットを見つけます。
Moy Standards Track [Page 23] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[23ページ]RFC2178OSPFバージョン1997年7月2日
Looking at this another way, inter-area routing can be pictured as forcing a star configuration on the Autonomous System, with the backbone as hub and each of the non-backbone areas as spokes.
この別の方法を見て、星の構成をAutonomous Systemに押しつけるとして相互領域ルーティングについて描写できます、スポークとしてのハブとしての背骨とそれぞれの非背骨領域で。
The topology of the backbone dictates the backbone paths used between areas. The topology of the backbone can be enhanced by adding virtual links. This gives the system administrator some control over the routes taken by inter-area traffic.
背骨のトポロジーは領域の間で使用される背骨経路を書き取ります。 仮想のリンクを加えることによって、背骨のトポロジーを高めることができます。 これは相互領域交通で取られたルートの何らかの支配力をシステム管理者に与えます。
The correct area border router to use as the packet exits the source area is chosen in exactly the same way routers advertising external routes are chosen. Each area border router in an area summarizes for the area its cost to all networks external to the area. After the SPF tree is calculated for the area, routes to all inter-area destinations are calculated by examining the summaries of the area border routers.
パケットがソース部門を出るとき、使用する正しい境界ルータは外部経路の広告を出すルータが選ばれているまさに同じように選ばれています。 領域の各境界ルータはその領域への外部のすべてのネットワークへの費用を領域へまとめます。 SPF木が領域に計算された後に、すべての相互領域の目的地へのルートは、境界ルータの概要を調べることによって、計算されます。
3.3. Classification of routers
3.3. ルータの分類
Before the introduction of areas, the only OSPF routers having a specialized function were those advertising external routing information, such as Router RT5 in Figure 2. When the AS is split into OSPF areas, the routers are further divided according to function into the following four overlapping categories:
領域の導入の前に、専門化している機能を持っていた唯一のOSPFルータが外部のルーティング情報の広告を出すものでした、図2のRouter RT5などのように。 ASがOSPF領域に分割されるとき、以下の4へのカテゴリを重ね合わせる機能に応じて、ルータはさらに分割されます:
Internal routers
A router with all directly connected networks belonging to the
same area. These routers run a single copy of the basic routing
algorithm.
すべてがある内部のルータAルータは直接同じ領域に属すネットワークを接続しました。 これらのルータは基本的なルーティング・アルゴリズムのただ一つのコピーを動かします。
Area border routers
A router that attaches to multiple areas. Area border routers run
multiple copies of the basic algorithm, one copy for each attached
area. Area border routers condense the topological information of
their attached areas for distribution to the backbone. The
backbone in turn distributes the information to the other areas.
複数の領域に付く境界ルータAルータ。 境界ルータは基本的なアルゴリズムの複数のコピー、それぞれの付属領域あたりのコピー1部を動かします。 境界ルータは分配のためにそれらの付属領域の位相的な情報を背骨に凝縮します。 背骨は順番に他の領域に情報を分配します。
Backbone routers
A router that has an interface to the backbone area. This
includes all routers that interface to more than one area (i.e.,
area border routers). However, backbone routers do not have to be
area border routers. Routers with all interfaces connecting to
the backbone area are supported.
背骨領域にインタフェースを持っている背骨ルータAルータ。 これは1つ以上の領域(すなわち、境界ルータ)に連結するすべてのルータを含んでいます。 しかしながら、背骨ルータは境界ルータである必要はありません。 すべてのインタフェースが背骨領域に接続するルータは支持されます。
Moy Standards Track [Page 24] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[24ページ]RFC2178OSPFバージョン1997年7月2日
AS boundary routers
A router that exchanges routing information with routers belonging
to other Autonomous Systems. Such a router advertises AS external
routing information throughout the Autonomous System. The paths
to each AS boundary router are known by every router in the AS.
This classification is completely independent of the previous
classifications: AS boundary routers may be internal or area
border routers, and may or may not participate in the backbone.
他のAutonomous Systemsそのようなルータに属すルータとルーティング情報を交換するAS境界ルータAルータがAutonomous System中にASの外部のルーティング情報の広告を出します。 それぞれのAS境界ルータへの経路はASであらゆるルータによって知られています。 この分類は前の分類から完全に独立しています: AS境界ルータは、内部か領域境界ルータであるかもしれなく、背骨に参加するかもしれません。
3.4. A sample area configuration
3.4. サンプル領域構成
Figure 6 shows a sample area configuration. The first area consists of networks N1-N4, along with their attached routers RT1-RT4. The second area consists of networks N6-N8, along with their attached routers RT7, RT8, RT10 and RT11. The third area consists of networks N9-N11 and Host H1, along with their attached routers RT9, RT11 and RT12. The third area has been configured so that networks N9-N11 and Host H1 will all be grouped into a single route, when advertised external to the area (see Section 3.5 for more details).
図6はサンプル領域構成を示しています。 最初の領域はそれらの付属ルータRT1-RT4に伴うネットワークN1-N4から成ります。 2番目の領域はそれらの付属ルータのRT7、RT8、RT10、およびRT11に伴うネットワークN6-N8から成ります。 3番目の領域はそれらの付属ルータのRT9、RT11、およびRT12に伴うネットワークのN9-N11とHost H1から成ります。 3番目の領域はネットワークのN9-N11とHost H1がただ一つのルートにすべて分類されるように、構成されました、その領域に外部であることの形で広告を出すと(その他の詳細に関してセクション3.5を見てください)。
In Figure 6, Routers RT1, RT2, RT5, RT6, RT8, RT9 and RT12 are internal routers. Routers RT3, RT4, RT7, RT10 and RT11 are area border routers. Finally, as before, Routers RT5 and RT7 are AS boundary routers.
図6では、Routers RT1、RT2、RT5、RT6、RT8、RT9、およびRT12は内部のルータです。 ルータのRT3、RT4、RT7、RT10、およびRT11は境界ルータです。 最終的で、従来と同様、Routers RT5とRT7はAS境界ルータです。
Figure 7 shows the resulting link-state database for the Area 1. The figure completely describes that area's intra-area routing.
図7はArea1のための結果として起こるリンク州のデータベースを示しています。 図は、掘りながら、その領域のイントラ領域について完全に説明します。
Moy Standards Track [Page 25] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[25ページ]RFC2178OSPFバージョン1997年7月2日
...........................
. + .
. | 3+---+ . N12 N14
. N1|--|RT1|\ 1 . \ N13 /
. | +---+ \ . 8\ |8/8
. + \ ____ . \|/
. / \ 1+---+8 8+---+6
. * N3 *---|RT4|------|RT5|--------+
. \____/ +---+ +---+ |
. + / \ . |7 |
. | 3+---+ / \ . | |
. N2|--|RT2|/1 1\ . |6 |
. | +---+ +---+8 6+---+ |
. + |RT3|------|RT6| |
. +---+ +---+ |
. 2/ . Ia|7 |
. / . | |
. +---------+ . | |
.Area 1 N4 . | |
........................... | |
.......................... | |
. N11 . | |
. +---------+ . | |
. | . | | N12
. |3 . Ib|5 |6 2/
. +---+ . +----+ +---+/
. |RT9| . .........|RT10|.....|RT7|---N15.
. +---+ . . +----+ +---+ 9 .
. |1 . . + /3 1\ |1 .
. _|__ . . | / \ __|_ .
. / \ 1+----+2 |/ \ / \ .
. * N9 *------|RT11|----| * N6 * .
. \____/ +----+ | \____/ .
. | . . | | .
. |1 . . + |1 .
. +--+ 10+----+ . . N8 +---+ .
. |H1|-----|RT12| . . |RT8| .
. +--+SLIP +----+ . . +---+ .
. |2 . . |4 .
. | . . | .
. +---------+ . . +--------+ .
. N10 . . N7 .
. . .Area 2 .
.Area 3 . ................................
..........................
........................... . + . . | 3+---+ . N12 N14N1|--|RT1|1円の\N13/。| +---+ \ . 8\ |8/8 . + \ ____ . \|/ . / \ 1+---+8 8+---+6 *N3*---|RT4|------|RT5|--------+ . \____/ +---+ +---+ | . + / \ . |7 | . | 3+---+ / \ . | | . N2|--|RT2|/1 1\ . |6 | . | +---+ +---+8 6+---+ | . + |RT3|------|RT6| | . +---+ +---+ | . 2 /Ia|7 | . / . | | . +---------+ . | | .Area1N4。| | ........................... | | .......................... | | . N11。| | . +---------+ . | | . | . | | N12。|3 . イブ|5 |6 2/ . +---+ . +----+ +---+/ . |RT9| . .........|RT10|.....|RT7|---N15。 . +---+ . . +----+ +---+ 9 . . |1 . . + /3 1\ |1 . . _|__ . . | / \ __|_ . . / \ 1+----+2 |/\/\*N9*------|RT11|----| * N6*\____/ +----+ | \____/ . . | . . | | . . |1 . . + |1 . . +--+ 10+----+ . . N8+---+ . . |H1|-----|RT12| . . |RT8| . . +--+ メモ用紙+----+ . . +---+ . . |2 . . |4 . . | . . | . . +---------+ . . +--------+ N10N7 . . . .Area2. .Area3。 ..........................
Figure 6: A sample OSPF area configuration
図6: サンプルOSPF領域構成
Moy Standards Track [Page 26] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[26ページ]RFC2178OSPFバージョン1997年7月2日
It also shows the complete view of the internet for the two internal routers RT1 and RT2. It is the job of the area border routers, RT3 and RT4, to advertise into Area 1 the distances to all destinations external to the area. These are indicated in Figure 7 by the dashed stub routes. Also, RT3 and RT4 must advertise into Area 1 the location of the AS boundary routers RT5 and RT7. Finally, AS- external-LSAs from RT5 and RT7 are flooded throughout the entire AS, and in particular throughout Area 1. These LSAs are included in Area 1's database, and yield routes to Networks N12-N15.
また、それは2の内部のルータRT1とRT2のためにインターネットの完全な視点を示しています。 それは、その領域への外部のすべての目的地への距離のArea1に広告を出すためには境界ルータ、RT3、およびRT4の仕事です。 これらは図7で投げつけられたスタッブルートで示されます。 また、RT3とRT4はASルータRT5境界とRT7の位置のArea1に広告を出さなければなりません。 最終的に、RT5とRT7からの外部のLSAsのASは全体のAS中と、そして、特にArea1中で水につかっています。 これらのLSAsはArea1のデータベースで含められていて、Networks N12-N15にルートを譲ります。
Routers RT3 and RT4 must also summarize Area 1's topology for distribution to the backbone. Their backbone LSAs are shown in Table 4. These summaries show which networks are contained in Area 1 (i.e., Networks N1-N4), and the distance to these networks from the routers RT3 and RT4 respectively.
また、ルータのRT3とRT4は分配のためにArea1のトポロジーを背骨へまとめなければなりません。 彼らの背骨LSAsはTable4で見せられます。 これらの概要は、ルータのRT3とRT4からどのネットワークがArea1(すなわち、Networks N1-N4)、および距離にこれらのネットワークに含まれているかをそれぞれ示します。
The link-state database for the backbone is shown in Figure 8. The set of routers pictured are the backbone routers. Router RT11 is a backbone router because it belongs to two areas. In order to make the backbone connected, a virtual link has been configured between Routers R10 and R11.
背骨のためのリンク州のデータベースは図8に示されます。 描写されたルータのセットは背骨ルータです。 2つの領域に属すので、ルータRT11は背骨ルータです。 背骨を接続させるために、仮想のリンクはRouters R10とR11の間で構成されました。
The area border routers RT3, RT4, RT7, RT10 and RT11 condense the routing information of their attached non-backbone areas for distribution via the backbone; these are the dashed stubs that appear in Figure 8. Remember that the third area has been configured to condense Networks N9-N11 and Host H1 into a single route. This yields a single dashed line for networks N9-N11 and Host H1 in Figure 8. Routers RT5 and RT7 are AS boundary routers; their externally derived information also appears on the graph in Figure 8 as stubs.
境界ルータのRT3、RT4、RT7、RT10、およびRT11は分配のために背骨でそれらの付属非背骨領域のルーティング情報を凝縮します。 これらは図8に載っている投げつけられたスタッブです。 3番目の領域がNetworks N9-N11とHost H1をただ一つのルートに凝縮するために構成されたのを覚えていてください。 これは図8でネットワークのN9-N11とHost H1に、ただ一つの投げつけられた線をもたらします。 ルータのRT5とRT7はAS境界ルータです。 また、それらの外部的に派生している情報はスタッブとして図8のグラフで現れます。
Network RT3 adv. RT4 adv.
_____________________________
N1 4 4
N2 4 4
N3 1 1
N4 2 3
ネットワークRT3副詞 RT4副詞 _____________________________ N1 4 4 N2 4 4 N3 1 1 N4 2 3
Table 4: Networks advertised to the backbone
by Routers RT3 and RT4.
テーブル4: ネットワークはRouters RT3とRT4で背骨に広告を出しました。
Moy Standards Track [Page 27] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[27ページ]RFC2178OSPFバージョン1997年7月2日
|RT|RT|RT|RT|RT|RT|
|1 |2 |3 |4 |5 |7 |N3|
----- -------------------
RT1| | | | | | |0 |
RT2| | | | | | |0 |
RT3| | | | | | |0 |
* RT4| | | | | | |0 |
* RT5| | |14|8 | | | |
T RT7| | |20|14| | | |
O N1|3 | | | | | | |
* N2| |3 | | | | | |
* N3|1 |1 |1 |1 | | | |
N4| | |2 | | | | |
Ia,Ib| | |20|27| | | |
N6| | |16|15| | | |
N7| | |20|19| | | |
N8| | |18|18| | | |
N9-N11,H1| | |29|36| | | |
N12| | | | |8 |2 | |
N13| | | | |8 | | |
N14| | | | |8 | | |
N15| | | | | |9 | |
| RT|RT|RT|RT|RT|RT| |1 |2 |3 |4 |5 |7 |N3| ----- ------------------- RT1| | | | | | |0 | RT2| | | | | | |0 | RT3| | | | | | |0 | * RT4| | | | | | |0 | * RT5| | |14|8 | | | | T RT7| | |20|14| | | | ○ N1|3 | | | | | | | * N2| |3 | | | | | | * N3|1 |1 |1 |1 | | | | N4| | |2 | | | | | Ia、イブ| | |20|27| | | | N6| | |16|15| | | | N7| | |20|19| | | | N8| | |18|18| | | | N9-N11、H1| | |29|36| | | | N12| | | | |8 |2 | | N13| | | | |8 | | | N14| | | | |8 | | | N15| | | | | |9 | |
Figure 7: Area 1's Database.
図7: 領域1データベース。
Networks and routers are represented by vertices.
An edge of cost X connects Vertex A to Vertex B iff
the intersection of Column A and Row B is marked
with an X.
ネットワークとルータは頭頂によって代表されます。 費用Xの縁はVertex B iffにVertex Aを接続します。Column Aと通りBの交差点はXと共に示されます。
Moy Standards Track [Page 28] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[28ページ]RFC2178OSPFバージョン1997年7月2日
**FROM**
****から
|RT|RT|RT|RT|RT|RT|RT
|3 |4 |5 |6 |7 |10|11|
------------------------
RT3| | | |6 | | | |
RT4| | |8 | | | | |
RT5| |8 | |6 |6 | | |
RT6|8 | |7 | | |5 | |
RT7| | |6 | | | | |
* RT10| | | |7 | | |2 |
* RT11| | | | | |3 | |
T N1|4 |4 | | | | | |
O N2|4 |4 | | | | | |
* N3|1 |1 | | | | | |
* N4|2 |3 | | | | | |
Ia| | | | | |5 | |
Ib| | | |7 | | | |
N6| | | | |1 |1 |3 |
N7| | | | |5 |5 |7 |
N8| | | | |4 |3 |2 |
N9-N11,H1| | | | | | |11|
N12| | |8 | |2 | | |
N13| | |8 | | | | |
N14| | |8 | | | | |
N15| | | | |9 | | |
| RT|RT|RT|RT|RT|RT|RT|3 |4 |5 |6 |7 |10|11| ------------------------ RT3| | | |6 | | | | RT4| | |8 | | | | | RT5| |8 | |6 |6 | | | RT6|8 | |7 | | |5 | | RT7| | |6 | | | | | * RT10| | | |7 | | |2 | * RT11| | | | | |3 | | T N1|4 |4 | | | | | | ○ N2|4 |4 | | | | | | * N3|1 |1 | | | | | | * N4|2 |3 | | | | | | Ia| | | | | |5 | | イブ| | | |7 | | | | N6| | | | |1 |1 |3 | N7| | | | |5 |5 |7 | N8| | | | |4 |3 |2 | N9-N11、H1| | | | | | |11| N12| | |8 | |2 | | | N13| | |8 | | | | | N14| | |8 | | | | | N15| | | | |9 | | |
Figure 8: The backbone's database.
エイト環: 背骨のデータベース。
Networks and routers are represented by vertices.
An edge of cost X connects Vertex A to Vertex B iff
the intersection of Column A and Row B is marked
with an X.
ネットワークとルータは頭頂によって代表されます。 費用Xの縁はVertex B iffにVertex Aを接続します。Column Aと通りBの交差点はXと共に示されます。
The backbone enables the exchange of summary information between area border routers. Every area border router hears the area summaries from all other area border routers. It then forms a picture of the distance to all networks outside of its area by examining the collected LSAs, and adding in the backbone distance to each advertising router.
背骨は境界ルータの間の概要情報の交換を可能にします。 あらゆる境界ルータが他のすべての境界ルータから領域概要を聞きます。 次に、それは距離の絵をすべてのネットワークに形成します。それぞれの広告ルータに集まっているLSAsを調べて、背骨距離を加えるのによる領域の外。
Again using Routers RT3 and RT4 as an example, the procedure goes as follows: They first calculate the SPF tree for the backbone. This gives the distances to all other area border routers. Also noted are the distances to networks (Ia and Ib) and AS boundary routers (RT5 and RT7) that belong to the backbone. This calculation is shown in Table 5.
再び例としてRouters RT3とRT4を使用して、手順は以下の通り行きます: 彼らは最初に、背骨のためにSPF木について計算します。 これは他のすべての境界ルータに距離を与えます。 また、注意されているのは、背骨に属すネットワーク(Iaとイブ)とAS境界ルータ(RT5とRT7)への距離です。 この計算はTable5に示されます。
Moy Standards Track [Page 29] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[29ページ]RFC2178OSPFバージョン1997年7月2日
Next, by looking at the area summaries from these area border routers, RT3 and RT4 can determine the distance to all networks outside their area. These distances are then advertised internally to the area by RT3 and RT4. The advertisements that Router RT3 and RT4 will make into Area 1 are shown in Table 6. Note that Table 6 assumes that an area range has been configured for the backbone which groups Ia and Ib into a single LSA.
これらの境界ルータから領域概要を見ることによって、次です、RT3とRT4はそれらの領域の外のすべてのネットワークに距離を測定できます。 そして、これらの距離はRT3とRT4によって内部的にその領域に広告を出されます。 Router RT3とRT4がArea1にする広告はTable6に示されます。 Table6が、領域の範囲がIaとイブを独身のLSAに分類する背骨のために構成されたと仮定することに注意してください。
The information imported into Area 1 by Routers RT3 and RT4 enables an internal router, such as RT1, to choose an area border router intelligently. Router RT1 would use RT4 for traffic to Network N6, RT3 for traffic to Network N10, and would load share between the two for traffic to Network N8.
Routers RT3とRT4によってArea1に輸入された情報は、内部のルータ、RT1としてのそのようなものが知的に境界ルータを選ぶのを可能にします。 ルータRT1はNetwork N6への交通へのRT4、Network N10への交通へのRT3を使用して、2つの間のシェアをNetwork N8への交通にロードするでしょう。
dist from dist from
RT3 RT4
__________________________________
to RT3 * 21
to RT4 22 *
to RT7 20 14
to RT10 15 22
to RT11 18 25
__________________________________
to Ia 20 27
to Ib 15 22
__________________________________
to RT5 14 8
to RT7 20 14
RT3 RT4からのdistからのdist__________________________________ RT11 18 25へのRT10 15 22へのRT7 20 14へのRT4 22*へのRT3*21に__________________________________ イブ15 22へのIa20 27に__________________________________ RT7 20 14へのRT5 14 8に
Table 5: Backbone distances calculated
by Routers RT3 and RT4.
テーブル5: Routers RT3とRT4によって計算されたバックボーン距離。
Destination RT3 adv. RT4 adv.
_________________________________
Ia,Ib 20 27
N6 16 15
N7 20 19
N8 18 18
N9-N11,H1 29 36
_________________________________
RT5 14 8
RT7 20 14
目的地RT3副詞 RT4副詞 _________________________________ Ia、イブ20 27N6 16 15N7 20 19N8 18 18N9-N11、H1 29 36_________________________________ RT5 14 8RT7 20 14
Table 6: Destinations advertised into Area 1
by Routers RT3 and RT4.
テーブル6: Routers RT3とRT4によってArea1に広告に掲載された目的地。
Moy Standards Track [Page 30] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[30ページ]RFC2178OSPFバージョン1997年7月2日
Router RT1 can also determine in this manner the shortest path to the AS boundary routers RT5 and RT7. Then, by looking at RT5 and RT7's AS-external-LSAs, Router RT1 can decide between RT5 or RT7 when sending to a destination in another Autonomous System (one of the networks N12-N15).
また、ルータRT1はこの様にASルータRT5境界とRT7に最短パスを決定できます。 そして、RT5とRT7のASの外部のLSAsを見ることによって、別のAutonomous Systemの目的地に発信するとき(ネットワークN12-N15の1つ)、Router RT1はRT5かRT7についてどちらかに決めることができます。
Note that a failure of the line between Routers RT6 and RT10 will cause the backbone to become disconnected. Configuring a virtual link between Routers RT7 and RT10 will give the backbone more connectivity and more resistance to such failures.
バックボーンがRouters RT6とRT10の間の系列の失敗によって切断されるようになることに注意してください。 Routers RT7とRT10との仮想のリンクを構成すると、より多くの接続性とそのような失敗への、より多くの抵抗がバックボーンに与えられるでしょう。
3.5. IP subnetting support
3.5. IPサブネッティングサポート
OSPF attaches an IP address mask to each advertised route. The mask indicates the range of addresses being described by the particular route. For example, a summary-LSA for the destination 128.185.0.0 with a mask of 0xffff0000 actually is describing a single route to the collection of destinations 128.185.0.0 - 128.185.255.255. Similarly, host routes are always advertised with a mask of 0xffffffff, indicating the presence of only a single destination.
OSPFはIPアドレスマスクをそれぞれの広告を出しているルートに取り付けます。 マスクは特定のルートで説明されるアドレスの範囲を示します。 例えば、目的地への概要-LSA、128.185、.0、.0、実際に0xffff0000のマスクでただ一つのルートを目的地の収集に説明している、128.185、.0、.0、--128.185 .255 .255。 同様に、単一の目的地だけの存在を示して、いつも0xffffffffのマスクでホストルートの広告を出します。
Including the mask with each advertised destination enables the implementation of what is commonly referred to as variable-length subnetting. This means that a single IP class A, B, or C network number can be broken up into many subnets of various sizes. For example, the network 128.185.0.0 could be broken up into 62 variable-sized subnets: 15 subnets of size 4K, 15 subnets of size 256, and 32 subnets of size 8. Table 7 shows some of the resulting network addresses together with their masks.
それぞれの広告を出している目的地があるマスクを含んでいると、一般的に可変長のサブネッティングと呼ばれることに関する実装は可能にされます。 これは、ただ一つのIPのクラスA、B、またはCネットワーク・ナンバーを様々なサイズの多くのサブネットに終えることができることを意味します。 例えば、.0が62の変数サイズのサブネットに壊れるかもしれないネットワーク128.185.0: 4Kのサイズの15サブネット、サイズ8のサイズ256、および32サブネットの15サブネット。 テーブル7はそれらのマスクと共に結果として起こるネットワーク・アドレスのいくつかを示しています。
Network address IP address mask Subnet size
_______________________________________________
128.185.16.0 0xfffff000 4K
128.185.1.0 0xffffff00 256
128.185.0.8 0xfffffff8 8
ネットワーク・アドレスIPアドレスマスクSubnetサイズ_______________________________________________ 128.185.16.0 0 4K128.185.1.0 0のxfffff000xffffff00 256 128.185.0.8 0xfffffff8 8
Table 7: Some sample subnet sizes.
テーブル7: 或るものはサブネットサイズを抽出します。
There are many possible ways of dividing up a class A, B, and C network into variable sized subnets. The precise procedure for doing so is beyond the scope of this specification. This specification however establishes the following guideline: When an IP packet is forwarded, it is always forwarded to the network that is the best match for the packet's destination. Here best match is synonymous with the longest or most specific match. For example, the default
可変大きさで分けられたサブネットにはクラスA、B、およびCネットワークに分割する多くの可能な方法があります。 そうするための正確な手順はこの仕様の範囲を超えています。 しかしながら、この仕様は以下のガイドラインを確立します: IPパケットを進めるとき、いつもパケットの目的地への最も良いマッチであるネットワークにそれを送ります。 ここで、最も良いマッチは最も長いか最も特定のマッチと同義です。 例えば、デフォルト
Moy Standards Track [Page 31] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[31ページ]RFC2178OSPFバージョン1997年7月2日
route with destination of 0.0.0.0 and mask 0x00000000 is always a match for every IP destination. Yet it is always less specific than any other match. Subnet masks must be assigned so that the best match for any IP destination is unambiguous.
いつも0.0の.0の.0とマスク0x00000000の目的地があるルートはあらゆるIPの目的地へのマッチです。 しかし、それはいかなる他のマッチよりもいつも特定ではありません。 どんなIPの目的地への最も良いマッチも明白であるように、サブネットマスクを割り当てなければなりません。
Attaching an address mask to each route also enables the support of IP supernetting. For example, a single physical network segment could be assigned the [address,mask] pair [192.9.4.0,0xfffffc00]. The segment would then be single IP network, containing addresses from the four consecutive class C network numbers 192.9.4.0 through 192.9.7.0. Such addressing is now becoming commonplace with the advent of CIDR (see [Ref10]).
また、アドレスマスクを各ルートに取り付けると、IPスーパーネッティングのサポートは可能にされます。 例えば、[アドレス、マスク]組にただ一つの物理ネットワークセグメントを配属できた、[192.9、.4、.0、0xfffffc00] そしてセグメントはただ一つのIPネットワークでしょう、4の連続したクラスCネットワーク・ナンバーからのアドレスを含んでいて192.9、.4、.0、通じて、192.9 .7 .0。 現在、そのようなアドレシングはCIDRの到来で平凡になっています([Ref10]を見てください)。
In order to get better aggregation at area boundaries, area address ranges can be employed (see Section C.2 for more details). Each address range is defined as an [address,mask] pair. Many separate networks may then be contained in a single address range, just as a subnetted network is composed of many separate subnets. Area border routers then summarize the area contents (for distribution to the backbone) by advertising a single route for each address range. The cost of the route is the maximum cost to any of the networks falling in the specified range.
エリアの境界における、より良い集合を得るために、領域のアドレスの範囲を使うことができます(その他の詳細に関してセクションC.2を見てください)。 それぞれのアドレスの範囲は[アドレス、マスク]組と定義されます。 次に、多くの別々のネットワークがただ一つのアドレスの範囲に保管されるかもしれません、ちょうどサブネット化したネットワークが多くの別々のサブネットで構成されるように。 そして、境界ルータは、それぞれのアドレスの範囲にただ一つのルートの広告を出すことによって、領域コンテンツ(バックボーンへの分配のための)をまとめます。 ルートの費用は指定された範囲で転ぶネットワークのどれかへの最大の費用です。
For example, an IP subnetted network might be configured as a single OSPF area. In that case, a single address range could be configured: a class A, B, or C network number along with its natural IP mask. Inside the area, any number of variable sized subnets could be defined. However, external to the area a single route for the entire subnetted network would be distributed, hiding even the fact that the network is subnetted at all. The cost of this route is the maximum of the set of costs to the component subnets.
例えば、IPサブネット化したネットワークはただ一つのOSPF領域として構成されるかもしれません。 その場合、ただ一つのアドレスの範囲を構成できました: クラスA、B、またはCは自然なIPマスクに伴う数をネットワークでつなぎます。 領域の中では、いろいろな可変大きさで分けられたサブネットを定義できました。 しかしながら、領域のa全体のサブネット化したネットワークに、ただ一つのルートへの外部は分配されるでしょう、ネットワークが全く「副-網で覆」われるという事実さえ隠して。 このルートの費用はコンポーネントサブネットへのコストのセットの最大です。
3.6. Supporting stub areas
3.6. スタッブ領域をサポートします。
In some Autonomous Systems, the majority of the link-state database may consist of AS-external-LSAs. An OSPF AS-external-LSA is usually flooded throughout the entire AS. However, OSPF allows certain areas to be configured as "stub areas". AS-external-LSAs are not flooded into/throughout stub areas; routing to AS external destinations in these areas is based on a (per-area) default only. This reduces the link-state database size, and therefore the memory requirements, for a stub area's internal routers.
いくつかのAutonomous Systemsでは、リンク州のデータベースの大部分がASの外部のLSAsから成るかもしれません。 通常、OSPF ASの外部のLSAは全体のAS中で水につかっています。 しかしながら、OSPFは、ある一定の領域が「スタッブ領域」として構成されるのを許容します。 ASの外部のLSAsはスタッブ領域中に/へあふれません。 これらの領域のASの外部の目的地へのルーティングは(領域)デフォルトだけに基づいています。 これは、スタッブ領域の内部のルータのためにリンク州のデータベースサイズを減少させて、したがって、メモリ要件を減少させます。
In order to take advantage of the OSPF stub area support, default routing must be used in the stub area. This is accomplished as follows. One or more of the stub area's area border routers must advertise a default route into the stub area via summary-LSAs. These summary defaults are flooded throughout the stub area, but no
OSPFスタッブ領域サポートを利用するために、スタッブ領域でデフォルトルーティングを使用しなければなりません。 これは以下の通り達成されます。 スタッブ領域の境界ルータのより多くのひとりは概要-LSAsを通してスタッブ領域にデフォルトルートの広告を出さなければなりません。 これらの概要デフォルトはスタッブ領域中で水につかっていますが、いいえ
Moy Standards Track [Page 32] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[32ページ]RFC2178OSPFバージョン1997年7月2日
further. (For this reason these defaults pertain only to the particular stub area). These summary default routes will be used for any destination that is not explicitly reachable by an intra-area or inter-area path (i.e., AS external destinations).
さらに。 (これらのデフォルトが特定のスタッブ領域だけに関係するこの理由による。) これらの概要デフォルトルートはどんなイントラ領域か相互領域経路(すなわち、ASの外部の目的地)で明らかに届いていない目的地にも使用されるでしょう。
An area can be configured as a stub when there is a single exit point from the area, or when the choice of exit point need not be made on a per-external-destination basis. For example, Area 3 in Figure 6 could be configured as a stub area, because all external traffic must travel though its single area border router RT11. If Area 3 were configured as a stub, Router RT11 would advertise a default route for distribution inside Area 3 (in a summary-LSA), instead of flooding the AS-external-LSAs for Networks N12-N15 into/throughout the area.
ただ一つのエキジットポイントが領域から来ているか、またはaで外部の目的地単位でエキジットポイントの選択をする必要はないとき、スタッブとして領域を構成できます。基礎。 例えば、スタッブ領域として図6のArea3を構成できました、もっとも、すべての域外交通がただ一つの境界ルータRT11を旅行しなければならないので。 Area3がスタッブとして構成されるなら、Router RT11はArea3(概要-LSAの)の中の分配のためのデフォルトルートの広告を出すでしょうに、領域中にNetworks N12-N15のためのASの外部のLSAsを/へあふれさせることの代わりに。
The OSPF protocol ensures that all routers belonging to an area agree on whether the area has been configured as a stub. This guarantees that no confusion will arise in the flooding of AS-external-LSAs.
OSPFプロトコルは、領域に属すすべてのルータが、領域がスタッブとして構成されたかどうか同意するのを確実にします。 これは、混乱が全くASの外部のLSAsの氾濫で起こらないのを保証します。
There are a couple of restrictions on the use of stub areas. Virtual links cannot be configured through stub areas. In addition, AS boundary routers cannot be placed internal to stub areas.
スタッブ領域の使用には2、3の制限があります。 スタッブ領域を通って仮想のリンクを構成できません。 さらに、領域を引き抜くために内部でAS境界ルータを置くことができません。
3.7. Partitions of areas
3.7. 領域のパーティション
OSPF does not actively attempt to repair area partitions. When an area becomes partitioned, each component simply becomes a separate area. The backbone then performs routing between the new areas. Some destinations reachable via intra-area routing before the partition will now require inter-area routing.
OSPFは、領域パーティションを修理するのを活発に試みません。 領域が仕切られるようになると、各コンポーネントは単に分離した部分になります。 そして、バックボーンは新しい領域の間のルーティングを実行します。 パーティションの前のイントラ領域ルーティングを通して届いているいくつかの目的地が現在、相互領域ルーティングを必要とするでしょう。
However, in order to maintain full routing after the partition, an address range must not be split across multiple components of the area partition. Also, the backbone itself must not partition. If it does, parts of the Autonomous System will become unreachable. Backbone partitions can be repaired by configuring virtual links (see Section 15).
しかしながら、パーティションの後に完全なルーティングを維持するために、領域パーティションの複数のコンポーネントの向こう側にアドレスの範囲を分けてはいけません。 また、バックボーン自体は仕切ってはいけません。 そうすると、Autonomous Systemの部分は手が届かなくなるでしょう。 仮想のリンクを構成することによって、バックボーンパーティションを修理できます(セクション15を見てください)。
Another way to think about area partitions is to look at the Autonomous System graph that was introduced in Section 2. Area IDs can be viewed as colors for the graph's edges.[1] Each edge of the graph connects to a network, or is itself a point-to-point network. In either case, the edge is colored with the network's Area ID.
領域パーティションについて考える別の方法はセクション2で導入されたAutonomous Systemグラフを見ることです。 グラフのもののために縁を.[1]に着色するとき、領域IDを見ることができます。グラフの各縁は、ネットワークに接続するか、またはそれ自体で二地点間ネットワークです。 どちらの場合ではも、縁はネットワークのArea IDと共に着色されます。
A group of edges, all having the same color, and interconnected by vertices, represents an area. If the topology of the Autonomous System is intact, the graph will have several regions of color, each color being a distinct Area ID.
縁のグループ(頭頂によって同じ色を持って、インタコネクトされたすべて)は領域を表します。 Autonomous Systemのトポロジーが完全であるなら、グラフには、色(異なったArea IDである各色)のいくつかの領域があるでしょう。
Moy Standards Track [Page 33] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[33ページ]RFC2178OSPFバージョン1997年7月2日
When the AS topology changes, one of the areas may become partitioned. The graph of the AS will then have multiple regions of the same color (Area ID). The routing in the Autonomous System will continue to function as long as these regions of same color are connected by the single backbone region.
ASトポロジーが変化すると、領域の1つは仕切られるようになるかもしれません。 そして、ASのグラフには、同じ色(Area ID)の複数の領域があるでしょう。 Autonomous Systemでのルーティングは、同じ色のこれらの領域がただ一つのバックボーン領域によってつなげられる限り、機能し続けるでしょう。
4. Functional Summary
4. 機能的な概要
A separate copy of OSPF's basic routing algorithm runs in each area. Routers having interfaces to multiple areas run multiple copies of the algorithm. A brief summary of the routing algorithm follows.
別々のコピーのOSPFの基本的なルーティング・アルゴリズムは各領域へ駆け込みます。 複数の領域にインタフェースを持っているルータがアルゴリズムの複本を実行します。 ルーティング・アルゴリズムの簡潔な概要は従います。
When a router starts, it first initializes the routing protocol data structures. The router then waits for indications from the lower- level protocols that its interfaces are functional.
ルータが始まるとき、それは最初に、ルーティング・プロトコルデータ構造を初期化します。 そして、ルータは低い平らなプロトコルからのインタフェースが機能的であるという指摘を待っています。
A router then uses the OSPF's Hello Protocol to acquire neighbors. The router sends Hello packets to its neighbors, and in turn receives their Hello packets. On broadcast and point-to-point networks, the router dynamically detects its neighboring routers by sending its Hello packets to the multicast address AllSPFRouters. On non- broadcast networks, some configuration information may be necessary in order to discover neighbors. On broadcast and NBMA networks the Hello Protocol also elects a Designated router for the network.
そして、ルータは、隣人を取得するのにOSPFのHelloプロトコルを使用します。 ルータは、隣人へのパケットをHelloに送って、順番に彼らのHelloパケットを受けます。 放送と二地点間ネットワークでは、ルータは、マルチキャストアドレスAllSPFRoutersにHelloパケットを送ることによって、ダイナミックに隣接しているルータを検出します。 非放送網では、何らかの設定情報が、隣人を発見するのに必要であるかもしれません。 またHelloプロトコルがネットワークのためにDesignatedルータに選ぶ放送とNBMAネットワークに関して。
The router will attempt to form adjacencies with some of its newly acquired neighbors. Link-state databases are synchronized between pairs of adjacent routers. On broadcast and NBMA networks, the Designated Router determines which routers should become adjacent.
ルータは、何人かの新たに取得された隣人と共に隣接番組を形成するのを試みるでしょう。 リンク州のデータベースは組の隣接しているルータの間で同期します。 放送とNBMAネットワークでは、Designated Routerは、どのルータが隣接するようになるべきであるかを決定します。
Adjacencies control the distribution of routing information. Routing updates are sent and received only on adjacencies.
隣接番組はルーティング情報の分配を制御します。 隣接番組だけでルート設定アップデートを送って、受けます。
A router periodically advertises its state, which is also called link state. Link state is also advertised when a router's state changes. A router's adjacencies are reflected in the contents of its LSAs. This relationship between adjacencies and link state allows the protocol to detect dead routers in a timely fashion.
ルータは定期的に状態の広告を出します。(また、それは、リンク状態と呼ばれます)。 また、ルータの状態が変化するとき、リンク状態の広告を出します。 ルータの隣接番組はLSAsのコンテンツに反映されます。 隣接番組とリンク状態とのこの関係は、直ちに死んでいるルータを検出するためにプロトコルを許容します。
LSAs are flooded throughout the area. The flooding algorithm is reliable, ensuring that all routers in an area have exactly the same link-state database. This database consists of the collection of LSAs originated by each router belonging to the area. From this database each router calculates a shortest-path tree, with itself as root. This shortest-path tree in turn yields a routing table for the protocol.
LSAsは領域中で水につかっています。 領域のすべてのルータにはまさに同じリンク州のデータベースがあるのを確実にして、氾濫アルゴリズムは信頼できます。 このデータベースは領域に属す各ルータによって溯源されたLSAsの収集から成ります。 このデータベースから、各ルータは根としてそれ自体がいる最短パス木について計算します。 この最短パス木は順番にプロトコルのための経路指定テーブルをもたらします。
Moy Standards Track [Page 34] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[34ページ]RFC2178OSPFバージョン1997年7月2日
4.1. Inter-area routing
4.1. 相互領域ルーティング
The previous section described the operation of the protocol within a single area. For intra-area routing, no other routing information is pertinent. In order to be able to route to destinations outside of the area, the area border routers inject additional routing information into the area. This additional information is a distillation of the rest of the Autonomous System's topology.
前項はただ一つの領域の中でプロトコルの操作について説明しました。 イントラ領域ルーティングにおいて、他のどんなルーティング情報も適切ではありません。 領域の外部を目的地に発送できるように、境界ルータは追加ルーティング情報を領域に注ぎます。 この追加情報はAutonomous Systemのトポロジーの残りの蒸留です。
This distillation is accomplished as follows: Each area border router is by definition connected to the backbone. Each area border router summarizes the topology of its attached non-backbone areas for transmission on the backbone, and hence to all other area border routers. An area border router then has complete topological information concerning the backbone, and the area summaries from each of the other area border routers. From this information, the router calculates paths to all inter-area destinations. The router then advertises these paths into its attached areas. This enables the area's internal routers to pick the best exit router when forwarding traffic inter-area destinations.
この蒸留は以下の通り実行されます: 各境界ルータは定義上バックボーンに関連づけられます。 各境界ルータはトランスミッションのためにバックボーンの上と、そして、したがって、他のすべての境界ルータへ付属非バックボーン領域のトポロジーをまとめます。 そして、境界ルータには、バックボーンの完全な位相的な情報、およびそれぞれの他の境界ルータからの領域概要があります。 この情報から、ルータはすべての相互領域の目的地に経路について計算します。 そして、ルータは付属領域にこれらの経路の広告を出します。 トラフィック相互領域の目的地を進めるとき、これは、領域の内部のルータが最も良い出口ルータを選ぶのを可能にします。
4.2. AS external routes
4.2. AS外部経路
Routers that have information regarding other Autonomous Systems can flood this information throughout the AS. This external routing information is distributed verbatim to every participating router. There is one exception: external routing information is not flooded into "stub" areas (see Section 3.6).
他のAutonomous Systemsの情報を持っているルータはAS中にこの情報をあふれさせることができます。 この外部のルーティング情報はあらゆる参加ルータに逐語的に分配されます。 1つの例外があります: 外部のルーティング情報は「スタッブ」領域へあふれません(セクション3.6を見てください)。
To utilize external routing information, the path to all routers advertising external information must be known throughout the AS (excepting the stub areas). For that reason, the locations of these AS boundary routers are summarized by the (non-stub) area border routers.
外部のルーティング情報、経路をすべてのルータ広告に利用するために、AS(スタッブ領域を除いた)中で外部の情報を知っていなければなりません。 その理由で、これらのAS境界ルータの位置は(非スタッブの)境界ルータによってまとめられます。
4.3. Routing protocol packets
4.3. ルーティング・プロトコルパケット
The OSPF protocol runs directly over IP, using IP protocol 89. OSPF does not provide any explicit fragmentation/reassembly support. When fragmentation is necessary, IP fragmentation/reassembly is used. OSPF protocol packets have been designed so that large protocol packets can generally be split into several smaller protocol packets. This practice is recommended; IP fragmentation should be avoided whenever possible.
IPプロトコル89を使用して、OSPFプロトコルは直接IPをひきます。 OSPFは少しの明白な断片化/再アセンブリサポートも提供しません。 断片化が必要であるときに、IP断片化/再アセンブリは使用されています。 OSPFプロトコルパケットは、一般に、大きいプロトコルパケットをいくつかの、より小さいプロトコルパケットに分けることができるように設計されています。 この習慣はお勧めです。 可能であるときはいつも、IP断片化は避けられるべきです。
Routing protocol packets should always be sent with the IP TOS field set to 0. If at all possible, routing protocol packets should be given preference over regular IP data traffic, both when being sent
いつもIP TOS分野セットでルーティング・プロトコルパケットを0に送るべきです。 できれば、ともに送ると、定期的なIPデータ通信量の上の優先をルーティング・プロトコルパケットに与えるべきです。
Moy Standards Track [Page 35] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[35ページ]RFC2178OSPFバージョン1997年7月2日
and received. As an aid to accomplishing this, OSPF protocol packets should have their IP precedence field set to the value Internetwork Control (see [Ref5]).
そして、受け取られています。 これを達成することへの援助として、OSPFプロトコルパケットで、それらのIP先行分野を値のInternetwork Controlに設定するはずです([Ref5]を見てください)。
All OSPF protocol packets share a common protocol header that is described in Appendix A. The OSPF packet types are listed below in Table 8. Their formats are also described in Appendix A.
すべてのOSPFプロトコルパケットがAppendix A.で説明される一般的なプロトコルヘッダーを共有します。OSPFパケットタイプはTable8に以下に記載されています。 また、それらの形式はAppendix Aで説明されます。
Type Packet name
Protocol function
__________________________________________________________
1 Hello Discover/maintain neighbors
2 Database Description Summarize database contents
3 Link State Request Database download
4 Link State Update Database update
5 Link State Ack Flooding acknowledgment
タイプPacket名前プロトコル機能__________________________________________________________ こんにちは、Discover/が隣人2Database記述Summarizeデータベースコンテンツ3Link州Request Databaseダウンロード4Link州Update Database最新版5のLink州Ack Flooding承認であることを支持する1
Table 8: OSPF packet types.
テーブル8: OSPFパケットはタイプされます。
OSPF's Hello protocol uses Hello packets to discover and maintain neighbor relationships. The Database Description and Link State Request packets are used in the forming of adjacencies. OSPF's reliable update mechanism is implemented by the Link State Update and Link State Acknowledgment packets.
OSPFのHelloプロトコルは、隣人関係を発見して、維持するのにHelloパケットを使用します。 Database記述とLink州Requestパケットは隣接番組の形成に使用されます。 OSPFの信頼できるアップデートメカニズムはLink州UpdateとLink州Acknowledgmentパケットによって実装されます。
Each Link State Update packet carries a set of new link state advertisements (LSAs) one hop further away from their point of origination. A single Link State Update packet may contain the LSAs of several routers. Each LSA is tagged with the ID of the originating router and a checksum of its link state contents. Each LSA also has a type field; the different types of OSPF LSAs are listed below in Table 9.
それぞれのLink州Updateパケットは新しいリンク州の広告(LSAs)ワンバウンドのセットを彼らの創作のポイントからさらに遠いまで運びます。 単一のLink州UpdateパケットはいくつかのルータのLSAsを含むかもしれません。 各LSAは起因するルータのIDとリンク州のコンテンツのチェックサムでタグ付けをされます。 また、各LSAには、タイプ分野があります。 OSPF LSAsの異なったタイプはTable9に以下に記載されています。
OSPF routing packets (with the exception of Hellos) are sent only over adjacencies. This means that all OSPF protocol packets travel a single IP hop, except those that are sent over virtual adjacencies. The IP source address of an OSPF protocol packet is one end of a router adjacency, and the IP destination address is either the other end of the adjacency or an IP multicast address.
OSPFルーティングパケット(ハローズを除いた)を隣接番組だけの上に送ります。 これは、仮想の隣接番組の上に送られるものを除いて、すべてのOSPFプロトコルパケットが単一のIPホップを旅行することを意味します。 受信者IPアドレスは、OSPFプロトコルパケットのIPソースアドレスがルータ隣接番組の片端であり、隣接番組のもう一方の端かIPマルチキャストアドレスです。
Moy Standards Track [Page 36] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[36ページ]RFC2178OSPFバージョン1997年7月2日
LS LSA LSA description
type name
________________________________________________________
1 Router-LSAs Originated by all routers.
This LSA describes
the collected states of the
router's interfaces to an
area. Flooded throughout a
single area only.
________________________________________________________
2 Network-LSAs Originated for broadcast
and NBMA networks by
the Designated Router. This
LSA contains the
list of routers connected
to the network. Flooded
throughout a single area only.
________________________________________________________
3,4 Summary-LSAs Originated by area border
routers, and flooded through-
out the LSA's associated
area. Each summary-LSA
describes a route to a
destination outside the area,
yet still inside the AS
(i.e., an inter-area route).
Type 3 summary-LSAs describe
routes to networks. Type 4
summary-LSAs describe
routes to AS boundary routers.
________________________________________________________
5 AS-external-LSAs Originated by AS boundary
routers, and flooded through-
out the AS. Each
AS-external-LSA describes
a route to a destination in
another Autonomous System.
Default routes for the AS can
also be described by
AS-external-LSAs.
LS LSA LSA記述型名________________________________________________________ 1 すべてのルータによるルータ-LSAs Originated。 このLSAはルータのインタフェースの集まっている州について領域に説明します。 ただ一つの領域だけ中で水につかります。 ________________________________________________________ 2 放送のためのネットワーク-LSAs OriginatedとDesignated RouterによるNBMAネットワーク。 このLSAはネットワークに関連づけられたルータのリストを含んでいます。 ただ一つの領域だけ中で水につかります。 ________________________________________________________ 3 4 領域のそばのSummary-LSAs Originatedはルータに接して、通じてLSAの関連領域を水浸しにしました。 各概要-LSAは領域と、まだまだASの中の目的地(すなわち、相互領域ルート)にルートを説明します。 タイプ3概要-LSAsがルートをネットワークに説明します。 タイプ4概要-LSAsがAS境界ルータにルートを説明します。 ________________________________________________________ ASによる5のASの外部のLSAs Originated境界ルータ、水につかる、ASから、突き抜けます。 それぞれのASの外部のLSAは別のAutonomous Systemの目的地にルートを説明します。 また、ASの外部のLSAsはASのためのデフォルトルートを説明できます。
Table 9: OSPF link state advertisements (LSAs).
テーブル9: OSPFは州の広告(LSAs)をリンクします。
Moy Standards Track [Page 37] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[37ページ]RFC2178OSPFバージョン1997年7月2日
4.4. Basic implementation requirements
4.4. 基本の実装要件
An implementation of OSPF requires the following pieces of system support:
OSPFの実装は以下のシステム支援を必要とします:
Timers
Two different kind of timers are required. The first kind, called
"single shot timers", fire once and cause a protocol event to be
processed. The second kind, called "interval timers", fire at
continuous intervals. These are used for the sending of packets
at regular intervals. A good example of this is the regular
broadcast of Hello packets. The granularity of both kinds of
timers is one second.
タイマTwo異なった種類のタイマが必要です。 最初の親切で、呼ばれた「単一のショットタイマ」は、一度発火して、プロトコルイベントを処理させます。 2番目の親切で、呼ばれた「インタバルタイマ」は連続した間隔に発火します。 これらはパケットの発信に一定の間隔を置いて使用されます。 この好例はHelloパケットの定期的な放送です。 両方の種類のタイマの粒状は1秒です。
Interval timers should be implemented to avoid drift. In some
router implementations, packet processing can affect timer
execution. When multiple routers are attached to a single
network, all doing broadcasts, this can lead to the
synchronization of routing packets (which should be avoided). If
timers cannot be implemented to avoid drift, small random amounts
should be added to/subtracted from the interval timer at each
firing.
インタバルタイマは、ドリフトを避けるために実装されるべきです。 いくつかのルータ実装では、パケット処理はタイマ実行に影響できます。 すべて放送して、複数のルータがただ一つのネットワークに付けられているとき、これはルーティングパケット(避けられるべきである)の同期に通じることができます。 ドリフトを避けるためにタイマを実装することができないなら、少無作為の量は、各発火のときにインタバルタイマから加えられるべきであるか、または引き算されるべきです。
IP multicast
Certain OSPF packets take the form of IP multicast datagrams.
Support for receiving and sending IP multicast datagrams, along
with the appropriate lower-level protocol support, is required.
The IP multicast datagrams used by OSPF never travel more than one
hop. For this reason, the ability to forward IP multicast
datagrams is not required. For information on IP multicast, see
[Ref7].
IPマルチキャストCertain OSPFパケットはIPマルチキャストデータグラムの形を取ります。IPマルチキャストデータグラムを受けて、送るサポートが適切な低レベルプロトコルサポートと共に必要です。 OSPFによって使用されたIPマルチキャストデータグラムはワンバウンドであるより決して移動しません。 この理由で、IPマルチキャストデータグラムを進める能力は必要ではありません。 IPマルチキャストの情報に関しては、[Ref7]を見てください。
Variable-length subnet support
The router's IP protocol support must include the ability to
divide a single IP class A, B, or C network number into many
subnets of various sizes. This is commonly called variable-length
subnetting; see Section 3.5 for details.
ルータのIPプロトコルがサポートする可変長のサブネットサポートはただ一つのIPのクラスA、B、またはCネットワーク・ナンバーを様々なサイズの多くのサブネットに分割する能力を含まなければなりません。 これは一般的に可変長のサブネッティングと呼ばれます。 詳細に関してセクション3.5を見てください。
IP supernetting support
The router's IP protocol support must include the ability to
aggregate contiguous collections of IP class A, B, and C networks
into larger quantities called supernets. Supernetting has been
proposed as one way to improve the scaling of IP routing in the
worldwide Internet. For more information on IP supernetting, see
[Ref10].
ルータのIPプロトコルがサポートするIPスーパーネッティングサポートはIPのクラスAの隣接の収集に集める能力を含まなければなりません、B、多く以上の量へのCネットワークは、「スーパー-ネット」と呼びました。 スーパーネッティングは世界的なインターネットでIPルーティングのスケーリングを改良することにおける一方通行として提案されました。 IPスーパーネッティングの詳しい情報に関しては、[Ref10]を見てください。
Moy Standards Track [Page 38] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[38ページ]RFC2178OSPFバージョン1997年7月2日
Lower-level protocol support
The lower level protocols referred to here are the network access
protocols, such as the Ethernet data link layer. Indications must
be passed from these protocols to OSPF as the network interface
goes up and down. For example, on an ethernet it would be
valuable to know when the ethernet transceiver cable becomes
unplugged.
下のレベルプロトコルがここと呼んだ低レベルプロトコルサポートはネットワークアクセス・プロトコルです、イーサネットデータ・リンク層などのように。 ネットワーク・インターフェースが上下するのに応じて、指摘をこれらのプロトコルからOSPFまで通過しなければなりません。 例えば、イーサネットでは、イーサネットトランシーバーケーブルがいつプラグを抜かれるようになるかを知るのは貴重でしょう。
Non-broadcast lower-level protocol support
On non-broadcast networks, the OSPF Hello Protocol can be aided by
providing an indication when an attempt is made to send a packet
to a dead or non-existent router. For example, on an X.25 PDN a
dead neighboring router may be indicated by the reception of a
X.25 clear with an appropriate cause and diagnostic, and this
information would be passed to OSPF.
非放送低レベルプロトコルサポートOn放送の非ネットワーク、死んでいるか実在しないルータにパケットを送るのを試みをするとき指示を提供することによって、OSPF Helloプロトコルを支援できます。 例えば、死んでいる隣接しているルータはX.25のレセプションによって示されて、適切な原因と病気の特徴でクリアしてください、そして、この情報がOSPFに通過されるだろうというX.25 PDNの上では、ことであるかもしれません。
List manipulation primitives
Much of the OSPF functionality is described in terms of its
operation on lists of LSAs. For example, the collection of LSAs
that will be retransmitted to an adjacent router until
acknowledged are described as a list. Any particular LSA may be
on many such lists. An OSPF implementation needs to be able to
manipulate these lists, adding and deleting constituent LSAs as
necessary.
OSPFの機能性のリスト操作基関数MuchはLSAsのリストで操作で説明されます。 例えば、リストとして記述されていた状態で承認されるまで隣接しているルータに再送されるLSAsの収集。 いくらかの特定のLSAがそのような多くのリストにあるかもしれません。 必要に応じて構成しているLSAsを加えて、削除して、OSPF実装は、これらのリストを操ることができる必要があります。
Tasking support
Certain procedures described in this specification invoke other
procedures. At times, these other procedures should be executed
in-line, that is, before the current procedure is finished. This
is indicated in the text by instructions to execute a procedure.
At other times, the other procedures are to be executed only when
the current procedure has finished. This is indicated by
instructions to schedule a task.
この仕様で説明されたサポートCertain手順に仕事を課して、他の手順を呼び出してください。 時には、すなわち、終わる前にこれらの他の手順はインラインで実行されるべきです。 これは、手順を実行するためにテキストで指示で示されます。 他の手順は現在の手順が他の時に終わったときだけ、実行されることです。 これは、タスクの計画をするように指示で示されます。
4.5. Optional OSPF capabilities
4.5. 任意のOSPF能力
The OSPF protocol defines several optional capabilities. A router indicates the optional capabilities that it supports in its OSPF Hello packets, Database Description packets and in its LSAs. This enables routers supporting a mix of optional capabilities to coexist in a single Autonomous System.
OSPFプロトコルはいくつかの任意の能力を定義します。 ルータはそれがOSPF Helloパケットでサポートする任意の能力を示します、パケットとそのLSAsのDatabase記述。 これは独身のAutonomous Systemに共存する任意の能力のミックスをサポートするルータを可能にします。
Some capabilities must be supported by all routers attached to a specific area. In this case, a router will not accept a neighbor's Hello Packet unless there is a match in reported capabilities (i.e., a capability mismatch prevents a neighbor relationship from forming). An example of this is the ExternalRoutingCapability (see below).
特定の領域に付けられたすべてのルータでいくつかの能力をサポートしなければなりません。 この場合、報告された能力にマッチがないと(すなわち、能力ミスマッチは、隣人関係が形成されるのを防ぎます)、ルータは隣人のHello Packetを受け入れないでしょう。 この例はExternalRoutingCapability(以下を見る)です。
Moy Standards Track [Page 39] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[39ページ]RFC2178OSPFバージョン1997年7月2日
Other capabilities can be negotiated during the Database Exchange process. This is accomplished by specifying the optional capabilities in Database Description packets. A capability mismatch with a neighbor in this case will result in only a subset of the link state database being exchanged between the two neighbors.
Database Exchangeプロセスの間、他の能力を交渉できます。 これは、Database記述パケットで任意の能力を指定することによって、達成されます。 この場合、隣人がいる能力ミスマッチは2人の隣人の間で交換されるリンク州のデータベースの部分集合だけをもたらすでしょう。
The routing table build process can also be affected by the presence/absence of optional capabilities. For example, since the optional capabilities are reported in LSAs, routers incapable of certain functions can be avoided when building the shortest path tree.
また、テーブルがプロセスを建てるルーティングは任意の能力の存在/欠如で影響を受けることができます。 任意の能力がLSAsで報告されるので、最短パス木を建てるとき、例えば、ある機能で不可能なルータを避けることができます。
The OSPF optional capabilities defined in this memo are listed below. See Section A.2 for more information.
このメモで定義されたOSPFの任意の能力は以下に記載されています。 詳しい情報に関してセクションA.2を見てください。
ExternalRoutingCapability
Entire OSPF areas can be configured as "stubs" (see Section 3.6).
AS-external-LSAs will not be flooded into stub areas. This
capability is represented by the E-bit in the OSPF Options field
(see Section A.2). In order to ensure consistent configuration of
stub areas, all routers interfacing to such an area must have the
E-bit clear in their Hello packets (see Sections 9.5 and 10.5).
「スタッブ」としてExternalRoutingCapability Entire OSPF領域を構成できます(セクション3.6を見てください)。 ASの外部のLSAsはスタッブ領域へあふれないでしょう。 この能力はOSPF Options分野にE-ビットによって表されます(セクションA.2を見てください)。 スタッブ領域の一貫した構成を確実にするために、そのような領域に連結するすべてのルータで、E-ビットはそれらのHelloパケットで明確にならなければなりません(セクション9.5と10.5を見てください)。
5. Protocol Data Structures
5. プロトコルデータ構造
The OSPF protocol is described herein in terms of its operation on various protocol data structures. The following list comprises the top-level OSPF data structures. Any initialization that needs to be done is noted. OSPF areas, interfaces and neighbors also have associated data structures that are described later in this specification.
OSPFプロトコルは様々なプロトコルデータ構造で操作でここに説明されます。 以下のリストはトップレベルOSPFデータ構造を包括します。 する必要があるどんな初期化も注意されます。 また、OSPF領域、インタフェース、および隣人には、後でこの仕様で説明される関連データ構造があります。
Router ID
A 32-bit number that uniquely identifies this router in the AS.
One possible implementation strategy would be to use the smallest
IP interface address belonging to the router. If a router's OSPF
Router ID is changed, the router's OSPF software should be
restarted before the new Router ID takes effect. In this case the
router should flush its self-originated LSAs from the routing
domain (see Section 14.1) before restarting, or they will persist
for up to MaxAge minutes.
ASで唯一このルータを特定するルータのIDのA32ビットの番号。 1つの可能な実装戦略はルータに属す最も小さいIPインターフェース・アドレスを使用するだろうことです。 ルータのOSPF Router IDを変えるなら、新しいRouter IDが効く前にルータのOSPFソフトウェアを再開するべきです。 この場合、ルータが再開する前に、経路ドメイン(セクション14.1を見る)から自己によって溯源されたLSAsを洗い流すべきですか、または彼らはMaxAgeまで分間固執するでしょう。
Area structures
Each one of the areas to which the router is connected has its own
data structure. This data structure describes the working of the
basic OSPF algorithm. Remember that each area runs a separate
copy of the basic OSPF algorithm.
領域は接続されたルータがそれ自身のデータ構造を持っている領域のEach1を構造化します。 このデータ構造は基本的なOSPFアルゴリズムの働きについて説明します。 各領域が基本的なOSPFアルゴリズムの別々のコピーを動かすのを覚えていてください。
Moy Standards Track [Page 40] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[40ページ]RFC2178OSPFバージョン1997年7月2日
Backbone (area) structure
The OSPF backbone area is responsible for the dissemination of
inter-area routing information.
バックボーン(領域)構造、OSPFバックボーン領域は相互領域ルーティング情報の普及に原因となります。
Virtual links configured
The virtual links configured with this router as one endpoint. In
order to have configured virtual links, the router itself must be
an area border router. Virtual links are identified by the Router
ID of the other endpoint -- which is another area border router.
These two endpoint routers must be attached to a common area,
called the virtual link's Transit area. Virtual links are part of
the backbone, and behave as if they were unnumbered point-to-point
networks between the two routers. A virtual link uses the intra-
area routing of its Transit area to forward packets. Virtual
links are brought up and down through the building of the
shortest-path trees for the Transit area.
仮想のリンクは1つの終点としてこのルータによって構成された仮想のリンクを構成しました。 仮想のリンクを構成したために、ルータ自体は境界ルータでなければなりません。 仮想のリンクはもう片方の終点(別の境界ルータである)のRouter IDによって特定されます。 仮想のリンクのTransit領域と呼ばれる一般的な領域にこれらの2つの終点ルータを付けなければなりません。 仮想のリンクはバックボーンの一部です、そして、まるでそれらが2つのルータの間の無数の二地点間ネットワークであるかのように、振る舞ってください。 仮想のリンクは、パケットを進めるのにTransit領域のイントラ領域ルーティングを使用します。 仮想のリンクはTransit領域のために最短パス木のビルを通して上下に持って来られます。
List of external routes
These are routes to destinations external to the Autonomous
System, that have been gained either through direct experience
with another routing protocol (such as BGP), or through
configuration information, or through a combination of the two
(e.g., dynamic external information to be advertised by OSPF with
configured metric). Any router having these external routes is
called an AS boundary router. These routes are advertised by the
router into the OSPF routing domain via AS-external-LSAs.
外部経路TheseのリストがAutonomous Systemへの外部の目的地へのルートである、別のルーティング・プロトコル(BGPなどの)の直接の経験を通して、または、設定情報を通して、または、2つ(例えば、構成されることでメートル法でOSPFによって広告を出されるべき外部のダイナミックな情報)のものの組み合わせを通してそれを獲得しました。 これらの外部経路を持っているどんなルータもAS境界ルータと呼ばれます。 ルータはASの外部のLSAsを通してOSPF経路ドメインにこれらのルートの広告を出します。
List of AS-external-LSAs
Part of the link-state database. These have originated from the
AS boundary routers. They comprise routes to destinations
external to the Autonomous System. Note that, if the router is
itself an AS boundary router, some of these AS-external-LSAs have
been self-originated.
リンク州のデータベースのASの外部のLSAs Partのリスト。 これらはAS境界ルータから発しました。 彼らはAutonomous Systemへの外部の目的地にルートを包括します。 これらのいくつかのASの外部のLSAsがルータがそれ自体でAS境界ルータであるなら自己に溯源されたことに注意してください。
The routing table
Derived from the link-state database. Each entry in the routing
table is indexed by a destination, and contains the destination's
cost and a set of paths to use in forwarding packets to the
destination. A path is described by its type and next hop. For
more information, see Section 11.
リンク州のデータベースからの経路指定テーブルDerived。 経路指定テーブルの各エントリーは、目的地によって索引をつけられて、推進パケットで目的地に使用する経路の目的地の費用とセットを含んでいます。 経路はタイプと次のホップによって説明されます。 詳しくは、セクション11を見てください。
Moy Standards Track [Page 41] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[41ページ]RFC2178OSPFバージョン1997年7月2日
Figure 9 shows the collection of data structures present in a typical router. The router pictured is RT10, from the map in Figure 6. Note that Router RT10 has a virtual link configured to Router RT11, with Area 2 as the link's Transit area. This is indicated by the dashed line in Figure 9. When the virtual link becomes active, through the building of the shortest path tree for Area 2, it becomes an interface to the backbone (see the two backbone interfaces depicted in Figure 9).
図9は典型的なルータにおける現在のデータ構造の収集を示しています。 描写されたルータは図6の地図からのRT10です。 Router RT10がリンクのTransit領域としてArea2で仮想のリンクをRouter RT11に構成させることに注意してください。 これは図9の投げつけられた系列によって示されます。 仮想のリンクが最短パス木のビルを通してArea2にアクティブになると、それはバックボーンへのインタフェースになります(2つのバックボーンインタフェースが図9に表現されるのを見てください)。
+----+
|RT10|------+
+----+ \+-------------+
/ \ |Routing Table|
/ \ +-------------+
/ \
+------+ / \ +--------+
|Area 2|---+ +---|Backbone|
+------+***********+ +--------+
/ \ * / \
/ \ * / \
+---------+ +---------+ +------------+ +------------+
|Interface| |Interface| |Virtual Link| |Interface Ib|
| to N6 | | to N8 | | to RT11 | +------------+
+---------+ +---------+ +------------+ |
/ \ | | |
/ \ | | |
+--------+ +--------+ | +-------------+ +------------+
|Neighbor| |Neighbor| | |Neighbor RT11| |Neighbor RT6|
| RT8 | | RT7 | | +-------------+ +------------+
+--------+ +--------+ |
|
+-------------+
|Neighbor RT11|
+-------------+
+----+ |RT10|------+ +----+ \+-------------+ / \ |経路指定テーブル| / \ +-------------+ / \ +------+ / \ +--------+ |領域2|---+ +---|バックボーン| +------+***********+ +--------+ / \ * / \ / \ * / \ +---------+ +---------+ +------------+ +------------+ |インタフェース| |インタフェース| |仮想のリンク| |イブを連結してください。| | N6に| | N8に| | RT11に| +------------+ +---------+ +---------+ +------------+ | / \ | | | / \ | | | +--------+ +--------+ | +-------------+ +------------+ |隣人| |隣人| | |隣人RT11| |隣人RT6| | RT8| | RT7| | +-------------+ +------------+ +--------+ +--------+ | | +-------------+ |隣人RT11| +-------------+
Figure 9: Router RT10's Data structures
図9: ルータRT10のData構造
6. The Area Data Structure
6. 領域データ構造
The area data structure contains all the information used to run the basic OSPF routing algorithm. Each area maintains its own link-state database. A network belongs to a single area, and a router interface connects to a single area. Each router adjacency also belongs to a single area.
領域データ構造は基本的なOSPFルーティング・アルゴリズムを実行するのに使用されるすべての情報を含んでいます。 各領域はそれ自身のリンク州のデータベースを維持します。 ネットワークはただ一つの領域に属します、そして、ルータインタフェースはただ一つの領域に接続します。 また、それぞれのルータ隣接番組はただ一つの領域に属します。
Moy Standards Track [Page 42] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[42ページ]RFC2178OSPFバージョン1997年7月2日
The OSPF backbone is the special OSPF area responsible for disseminating inter-area routing information.
OSPFバックボーンは相互領域ルーティング情報を広めるのに原因となる特別なOSPF領域です。
The area link-state database consists of the collection of router- LSAs, network-LSAs and summary-LSAs that have originated from the area's routers. This information is flooded throughout a single area only. The list of AS-external-LSAs (see Section 5) is also considered to be part of each area's link-state database.
領域リンク州のデータベースは領域のルータから発したルータLSAs、ネットワーク-LSAs、および概要-LSAsの収集から成ります。 この情報はただ一つの領域だけ中で水につかっています。 また、ASの外部のLSAs(セクション5を見る)のリストは各領域のリンク州のデータベースの一部であると考えられます。
Area ID
A 32-bit number identifying the area. The Area ID of 0.0.0.0 is
reserved for the backbone.
領域を特定する領域のIDのA32ビットの番号。 Area ID、0.0 .0 .0 バックボーンのために、予約されます。
List of area address ranges
In order to aggregate routing information at area boundaries, area
address ranges can be employed. Each address range is specified by
an [address,mask] pair and a status indication of either Advertise
or DoNotAdvertise (see Section 12.4.3).
領域アドレスのリストはエリアの境界でルーティング情報に集める命令のねらいを定めて、領域のアドレスの範囲は使うことができます。 それぞれのアドレスの範囲が[アドレス、マスク]組とどちらかの状態しるしで指定される、広告、または、DoNotAdvertise(セクション12.4.3を見ます)。
Associated router interfaces
This router's interfaces connecting to the area. A router
interface belongs to one and only one area (or the backbone). For
the backbone area this list includes all the virtual links. A
virtual link is identified by the Router ID of its other endpoint;
its cost is the cost of the shortest intra-area path through the
Transit area that exists between the two routers.
関連ルータはその領域に接続するThisルータのインタフェースを連結します。 ルータインタフェースは唯一無二の1つの領域(または、バックボーン)に属します。 バックボーン領域に、このリストはすべての仮想のリンクを含んでいます。 仮想のリンクは他の終点のRouter IDによって特定されます。 費用は2つのルータの間に存在するTransit領域を通る最も短いイントラ領域経路の費用です。
List of router-LSAs
A router-LSA is generated by each router in the area. It
describes the state of the router's interfaces to the area.
ルータ-LSAs Aルータ-LSAのリストはその領域の各ルータによって生成されます。 それはルータのインタフェースの状態についてその領域に説明します。
List of network-LSAs
One network-LSA is generated for each transit broadcast and NBMA
network in the area. A network-LSA describes the set of routers
currently connected to the network.
ネットワーク-LSAs Oneネットワーク-LSAのリストはその領域のそれぞれのトランジット放送とNBMAネットワークのために生成されます。 ネットワーク-LSAは現在ネットワークに関連づけられているルータのセットについて説明します。
List of summary-LSAs
Summary-LSAs originate from the area's area border routers. They
describe routes to destinations internal to the Autonomous System,
yet external to the area (i.e., inter-area destinations).
概要-LSAs Summary-LSAsのリストは領域の境界ルータから発します。 彼らはAutonomous Systemへの内部の、そして、しかし、その領域への外部の目的地(すなわち、相互領域の目的地)にルートを説明します。
Shortest-path tree
The shortest-path tree for the area, with this router itself as
root. Derived from the collected router-LSAs and network-LSAs by
the Dijkstra algorithm (see Section 16.1).
最短パスは根としてこのルータ自体で最短パス木を領域に木に追い上げます。 集まっているルータ-LSAsとネットワーク-LSAsから、ダイクストラアルゴリズム(セクション16.1を見る)で、派生します。
Moy Standards Track [Page 43] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[43ページ]RFC2178OSPFバージョン1997年7月2日
TransitCapability
This parameter indicates whether the area can carry data traffic
that neither originates nor terminates in the area itself. This
parameter is calculated when the area's shortest-path tree is
built (see Section 16.1, where TransitCapability is set to TRUE if
and only if there are one or more fully adjacent virtual links
using the area as Transit area), and is used as an input to a
subsequent step of the routing table build process (see Section
16.3). When an area's TransitCapability is set to TRUE, the area
is said to be a "transit area".
TransitCapability Thisパラメタは、領域がその領域自体で起因しないで、また終わらないデータ通信量を運ぶことができるかどうかを示します。 そして、領域の最短パス木が組立しているとこのパラメタが計算されている、(セクション16.1を見てください、1つがあるだけであるか、そして、Transit領域として領域を使用するより完全に隣接している仮想のリンク)、入力として、経路指定テーブル体格プロセス(セクション16.3を見る)のその後のステップに使用されます。そこでは、TransitCapabilityがTRUEに用意ができています。 領域のTransitCapabilityがTRUEに用意ができているとき、領域は「トランジット領域」であると言われます。
ExternalRoutingCapability
Whether AS-external-LSAs will be flooded into/throughout the area.
This is a configurable parameter. If AS-external-LSAs are
excluded from the area, the area is called a "stub". Within stub
areas, routing to AS external destinations will be based solely on
a default summary route. The backbone cannot be configured as a
stub area. Also, virtual links cannot be configured through stub
areas. For more information, see Section 3.6.
ExternalRoutingCapability Whether ASの外部のLSAsは領域中に/へあふれるでしょう。 これは構成可能なパラメタです。 ASの外部のLSAsが領域から除かれるなら、領域は「スタッブ」と呼ばれます。 スタッブ領域の中では、ASの外部の目的地へのルーティングは唯一デフォルト概要ルートに拠点を置くでしょう。 スタッブ領域としてバックボーンを構成できません。 また、スタッブ領域を通って仮想のリンクを構成できません。 詳しくは、セクション3.6を見てください。
StubDefaultCost
If the area has been configured as a stub area, and the router
itself is an area border router, then the StubDefaultCost
indicates the cost of the default summary-LSA that the router
should advertise into the area. See Section 12.4.3 for more
information.
StubDefaultCost If、ルータ自体が境界ルータである、領域はスタッブ領域として構成されて、次に、StubDefaultCostはルータが領域に広告を出すべきであるデフォルト概要-LSAの費用を示します。 詳しい情報に関してセクション12.4.3を見てください。
Unless otherwise specified, the remaining sections of this document refer to the operation of the OSPF protocol within a single area.
別の方法で指定されない場合、このドキュメントの残っているセクションはただ一つの領域の中でOSPFプロトコルの操作について言及します。
7. Bringing Up Adjacencies
7. 隣接番組を持って来ます。
OSPF creates adjacencies between neighboring routers for the purpose of exchanging routing information. Not every two neighboring routers will become adjacent. This section covers the generalities involved in creating adjacencies. For further details consult Section 10.
OSPFはルーティング情報を交換する目的のために隣接しているルータの間で隣接番組を作成します。 2つの隣接しているルータ毎は隣接するようにならないでしょう。 このセクションは隣接番組を作成するのにかかわる一般性をカバーします。 さらに詳しい明細についてはセクション10に相談してください。
7.1. The Hello Protocol
7.1. こんにちは、プロトコル
The Hello Protocol is responsible for establishing and maintaining neighbor relationships. It also ensures that communication between neighbors is bidirectional. Hello packets are sent periodically out all router interfaces. Bidirectional communication is indicated when the router sees itself listed in the neighbor's Hello Packet. On broadcast and NBMA networks, the Hello Protocol elects a Designated Router for the network.
Helloプロトコルは隣人関係を確立して、維持するのに原因となります。 また、それは隣人のコミュニケーションが確実に双方向になるようにします。 こんにちは、パケットはそうです。定期的にすべてのルータインタフェースを出しました。 ルータが、それ自体が隣人のHello Packetに記載されているのを見ると、双方向のコミュニケーションは示されます。 放送とNBMAネットワークでは、HelloプロトコルはネットワークのためにDesignated Routerを選出します。
Moy Standards Track [Page 44] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[44ページ]RFC2178OSPFバージョン1997年7月2日
The Hello Protocol works differently on broadcast networks, NBMA networks and Point-to-MultiPoint networks. On broadcast networks, each router advertises itself by periodically multicasting Hello Packets. This allows neighbors to be discovered dynamically. These Hello Packets contain the router's view of the Designated Router's identity, and the list of routers whose Hello Packets have been seen recently.
Helloプロトコルは放送網、NBMAネットワーク、およびPointからMultiPointへのネットワークに異なって取り組みます。 放送網では、各ルータ自体は定期的でマルチキャスティングHello Packetsの広告を出します。 これは、隣人がダイナミックに発見されるのを許容します。 これらのHello PacketsはDesignated Routerのアイデンティティに関するルータの意見、およびHello Packetsが最近見られたルータのリストを含んでいます。
On NBMA networks some configuration information may be necessary for the operation of the Hello Protocol. Each router that may potentially become Designated Router has a list of all other routers attached to the network. A router, having Designated Router potential, sends Hello Packets to all other potential Designated Routers when its interface to the NBMA network first becomes operational. This is an attempt to find the Designated Router for the network. If the router itself is elected Designated Router, it begins sending Hello Packets to all other routers attached to the network.
NBMAネットワークでは、何らかの設定情報がHelloプロトコルの操作に必要であるかもしれません。 潜在的にDesignated Routerになるかもしれない各ルータで、他のすべてのルータのリストをネットワークに添付します。 Designated Routerを潜在的にして、NBMAネットワークへのインタフェースが最初に操作上になると、ルータは他のすべての潜在的Designated RoutersにHello Packetsを送ります。 これはネットワークに関してDesignated Routerを見つける試みです。 ルータ自体がDesignated Routerに選出されるなら、それはネットワークに付けられた他のすべてのルータにHello Packetsを送り始めます。
On Point-to-MultiPoint networks, a router sends Hello Packets to all neighbors with which it can communicate directly. These neighbors may be discovered dynamically through a protocol such as Inverse ARP (see [Ref14]), or they may be configured.
PointからMultiPointへのネットワークでは、ルータはそれが直接伝達できるすべての隣人にHello Packetsを送ります。 これらの隣人がInverse ARPなどのプロトコルを通してダイナミックに発見されるかもしれませんか([Ref14]を見てください)、または彼らは構成されるかもしれません。
After a neighbor has been discovered, bidirectional communication ensured, and (if on a broadcast or NBMA network) a Designated Router elected, a decision is made regarding whether or not an adjacency should be formed with the neighbor (see Section 10.4). If an adjacency is to be formed, the first step is to synchronize the neighbors' link-state databases. This is covered in the next section.
隣人が確実にされた、発見されて、双方向のコミュニケーションと、(放送かNBMAネットワークで)Designated Routerに選出されたなった後に、隣接番組が隣人と共に形成されるべきであるかどうかに関して(セクション10.4を見てください)決定をします。 第一歩は隣接番組が形成されることであるなら、隣人のリンク州のデータベースを同期させることです。 これは次のセクションでカバーされています。
7.2. The Synchronization of Databases
7.2. データベースの同期
In a link-state routing algorithm, it is very important for all routers' link-state databases to stay synchronized. OSPF simplifies this by requiring only adjacent routers to remain synchronized. The synchronization process begins as soon as the routers attempt to bring up the adjacency. Each router describes its database by sending a sequence of Database Description packets to its neighbor. Each Database Description Packet describes a set of LSAs belonging to the router's database. When the neighbor sees an LSA that is more recent than its own database copy, it makes a note that this newer LSA should be requested.
LinkState方式アルゴリズムで、すべてのルータのリンク州のデータベースが連動していた状態で残っているのは、非常に重要です。 隣接しているルータだけが連動したままで残っているのを必要とすることによって、OSPFはこれを簡素化します。 同期プロセスは隣接番組を持って来るルータ試みの次第始まります。 各ルータは、Database記述パケットの系列を隣人に送ることによって、データベースについて説明します。 それぞれのDatabase記述Packetはルータのデータベースに属すLSAsの1セットについて説明します。 隣人がそれ自身のデータベースコピーより最近のLSAを見るとき、このより新しいLSAが要求されているべきであるのはメモを取ります。
This sending and receiving of Database Description packets is called the "Database Exchange Process". During this process, the two routers form a master/slave relationship. Each Database Description
Database記述パケットのこの送受信は「データベース交換プロセス」と呼ばれます。 このプロセスの間、2つのルータがマスター/奴隷関係を形成します。 各データベース記述
Moy Standards Track [Page 45] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[45ページ]RFC2178OSPFバージョン1997年7月2日
Packet has a sequence number. Database Description Packets sent by the master (polls) are acknowledged by the slave through echoing of the sequence number. Both polls and their responses contain summaries of link state data. The master is the only one allowed to retransmit Database Description Packets. It does so only at fixed intervals, the length of which is the configured per-interface constant RxmtInterval.
パケットには、一連番号があります。 マスター(投票)によって送られたデータベース記述Packetsは、一連番号を反響することで奴隷によって承認されます。 投票と彼らの応答の両方がリンク州のデータの合計を含んでいます。 マスターはDatabase記述Packetsを再送できた唯一無二です。 それはそう固定間隔だけで、します。1インタフェースあたりその長さは構成された一定のRxmtIntervalです。
Each Database Description contains an indication that there are more packets to follow --- the M-bit. The Database Exchange Process is over when a router has received and sent Database Description Packets with the M-bit off.
それぞれのDatabase記述は続くより多くのパケットがあるという指示を含んでいます。--- M-ビット。 ルータがDatabase記述Packetsを受けて、M-ビットがオフな状態で送ったとき、Database Exchange Processは終わっています。
During and after the Database Exchange Process, each router has a list of those LSAs for which the neighbor has more up-to-date instances. These LSAs are requested in Link State Request Packets. Link State Request packets that are not satisfied are retransmitted at fixed intervals of time RxmtInterval. When the Database Description Process has completed and all Link State Requests have been satisfied, the databases are deemed synchronized and the routers are marked fully adjacent. At this time the adjacency is fully functional and is advertised in the two routers' router-LSAs.
Database Exchange ProcessとDatabase Exchange Processの後に、各ルータには、隣人が、より最新のインスタンスを持っているそれらのLSAsのリストがあります。 これらのLSAsはLink州Request Packetsで要求されています。 満足していないリンク州Requestパケットは時間RxmtIntervalの固定間隔で、再送されます。 記述Processが完成したDatabaseとすべてのLink州Requestsが満足したとき、データベースは連動していると考えられます、そして、ルータは完全に隣接しているとマークされます。 このとき、隣接番組の完全に機能的であり、2つのルータのルータ-LSAsに広告を出します。
The adjacency is used by the flooding procedure as soon as the Database Exchange Process begins. This simplifies database synchronization, and guarantees that it finishes in a predictable period of time.
Database Exchange Processが始まるとすぐに、隣接番組は氾濫手順で使用されます。 これは、データベース同期を簡素化して、それが予測できる期間で終わるのを保証します。
7.3. The Designated Router
7.3. 代表ルータ
Every broadcast and NBMA network has a Designated Router. The Designated Router performs two main functions for the routing protocol:
あらゆる放送とNBMAネットワークには、Designated Routerがあります。 Designated Routerはルーティング・プロトコルのために2つの主な機能を実行します:
o The Designated Router originates a network-LSA on behalf of
the network. This LSA lists the set of routers (including
the Designated Router itself) currently attached to the
network. The Link State ID for this LSA (see Section
12.1.4) is the IP interface address of the Designated
Router. The IP network number can then be obtained by using
the network's subnet/network mask.
o Designated Routerはネットワークを代表してネットワーク-LSAを溯源します。 このLSAは現在ネットワークに付けられているルータ(Designated Router自身を含んでいる)のセットを記載します。 このLSA(セクション12.1.4を見る)のためのLink州IDはDesignated RouterのIPインターフェース・アドレスです。 そして、ネットワークのサブネット/ネットワークマスクを使用することによって、IPネットワーク・ナンバーを得ることができます。
o The Designated Router becomes adjacent to all other routers
on the network. Since the link state databases are
synchronized across adjacencies (through adjacency bring-up
and then the flooding procedure), the Designated Router
plays a central part in the synchronization process.
o Designated Routerはネットワークの他のすべてのルータに隣接してなります。 そして、以来リンク州のデータベースが隣接番組の向こう側に同期する、(通じて、隣接番組が-上にもたらす、次に、氾濫手順)、Designated Routerは同期プロセスで中央の役割を果たします。
Moy Standards Track [Page 46] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[46ページ]RFC2178OSPFバージョン1997年7月2日
The Designated Router is elected by the Hello Protocol. A router's Hello Packet contains its Router Priority, which is configurable on a per-interface basis. In general, when a router's interface to a network first becomes functional, it checks to see whether there is currently a Designated Router for the network. If there is, it accepts that Designated Router, regardless of its Router Priority. (This makes it harder to predict the identity of the Designated Router, but ensures that the Designated Router changes less often. See below.) Otherwise, the router itself becomes Designated Router if it has the highest Router Priority on the network. A more detailed (and more accurate) description of Designated Router election is presented in Section 9.4.
Designated RouterはHelloプロトコルによって選出されます。 ルータのHello PacketはRouter Priorityを含んでいます。(Router Priorityは1インタフェースあたり1個のベースで構成可能です)。 一般に、ネットワークへのルータのインタフェースが最初に機能的になると、それは、ネットワークに関してDesignated Routerが現在あるかどうか確認するためにチェックします。 あれば、それはRouter PriorityにかかわらずそのDesignated Routerを受け入れます。 (これは、Designated Routerのアイデンティティを予測するのをより困難にしますが、Designated Routerが、よりしばしば変化するのを確実にします。 以下を見てください。) さもなければ、ネットワークで最も高いRouter Priorityを持っているなら、ルータ自体はDesignated Routerになります。 Designated Router選挙の、より詳細で(より正確)の記述はセクション9.4に提示されます。
The Designated Router is the endpoint of many adjacencies. In order to optimize the flooding procedure on broadcast networks, the Designated Router multicasts its Link State Update Packets to the address AllSPFRouters, rather than sending separate packets over each adjacency.
Designated Routerは多くの隣接番組の終点です。 放送網の氾濫手順を最適化するために、発信よりむしろアドレスAllSPFRoutersへのDesignated RouterマルチキャストLink州Update Packetsは各隣接番組の上にパケットを分離します。
Section 2 of this document discusses the directed graph representation of an area. Router nodes are labelled with their Router ID. Transit network nodes are actually labelled with the IP address of their Designated Router. It follows that when the Designated Router changes, it appears as if the network node on the graph is replaced by an entirely new node. This will cause the network and all its attached routers to originate new LSAs. Until the link-state databases again converge, some temporary loss of connectivity may result. This may result in ICMP unreachable messages being sent in response to data traffic. For that reason, the Designated Router should change only infrequently. Router Priorities should be configured so that the most dependable router on a network eventually becomes Designated Router.
このドキュメントのセクション2は領域の有向グラフ表現について論じます。 ルータノードはそれらのRouter IDで分類されます。 トランジットネットワーク・ノードは実際にそれらのDesignated RouterのIPアドレスで分類されます。 Designated Routerが変化するとき、まるでグラフのネットワーク・ノードを完全に新しいノードに取り替えるかのように見えるということになります。 これで、ネットワークとそのすべての付属ルータが新しいLSAsを溯源するでしょう。 リンク州のデータベースが再び一点に集まるまで、接続性のいくらかの一時的な損失が結果として生じるかもしれません。 これはデータ通信量に対応して送られるICMPの手の届かないメッセージをもたらすかもしれません。 その理由で、Designated Routerはまれにだけ変化するはずです。 ルータPrioritiesが構成されるべきであるので、ネットワークで最も信頼できるルータは結局、Designated Routerになります。
7.4. The Backup Designated Router
7.4. バックアップに指定されたルータ
In order to make the transition to a new Designated Router smoother, there is a Backup Designated Router for each broadcast and NBMA network. The Backup Designated Router is also adjacent to all routers on the network, and becomes Designated Router when the previous Designated Router fails. If there were no Backup Designated Router, when a new Designated Router became necessary, new adjacencies would have to be formed between the new Designated Router and all other routers attached to the network. Part of the adjacency forming process is the synchronizing of link-state databases, which can potentially take quite a long time. During this time, the network would not be available for transit data traffic. The Backup Designated obviates the need to form these adjacencies, since they already exist. This means the period of disruption in transit
新しいDesignated Routerへの変遷をより滑らかにするように、それぞれの放送とNBMAネットワークのためのBackup Designated Routerがあります。 Backup Designated Routerはネットワークのすべてのルータに隣接してもいて、前のDesignated Routerが失敗すると、Designated Routerになります。 Backup Designated Routerが全くなければ、新しいDesignated Routerがいつ必要で、新しい隣接番組になったかはネットワークに取り付けられた新しいDesignated Routerと他のすべてのルータの間で形成されなければならないでしょうに。 隣接番組形成プロセスの一部はリンク州のデータベースの連動です。(潜在的に、データベースはかなり長い時間がかかるかもしれません)。 この間に、ネットワークはトランジットデータ通信量に利用可能でないでしょう。 Backup Designatedは、既に存在しているので、これらの隣接番組を形成する必要性を取り除きます。 これはトランジットにおける、分裂の一区切りを意味します。
Moy Standards Track [Page 47] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[47ページ]RFC2178OSPFバージョン1997年7月2日
traffic lasts only as long as it takes to flood the new LSAs (which announce the new Designated Router).
単に新しいLSAs(新しいDesignated Routerを発表する)をあふれさせるにはかかる限り、トラフィックは持続します。
The Backup Designated Router does not generate a network-LSA for the network. (If it did, the transition to a new Designated Router would be even faster. However, this is a tradeoff between database size and speed of convergence when the Designated Router disappears.)
Backup Designated Routerはネットワークのためにネットワーク-LSAを生成しません。 (そうするなら、新しいDesignated Routerへの変遷はさらに速いでしょうに。 しかしながら、Designated Routerが見えなくなるとき、これは集合のデータベースサイズと速度の間の見返りです。)
The Backup Designated Router is also elected by the Hello Protocol. Each Hello Packet has a field that specifies the Backup Designated Router for the network.
また、Backup Designated RouterはHelloプロトコルによって選出されます。 各Hello Packetには、ネットワークにBackup Designated Routerを指定する分野があります。
In some steps of the flooding procedure, the Backup Designated Router plays a passive role, letting the Designated Router do more of the work. This cuts down on the amount of local routing traffic. See Section 13.3 for more information.
氾濫手順の数ステップでは、Backup Designated Routerは受け身の役割を果たします、Designated Routerに一層の仕事をさせて。 これは地方のルーティングトラフィックの量を減らします。 詳しい情報に関してセクション13.3を見てください。
7.5. The graph of adjacencies
7.5. 隣接番組のグラフ
An adjacency is bound to the network that the two routers have in common. If two routers have multiple networks in common, they may have multiple adjacencies between them.
隣接番組は2つのルータが共通であるネットワークに縛られます。 2つのルータが複数のネットワークが共通であるなら、それらの間には、複数の隣接番組があるかもしれません。
One can picture the collection of adjacencies on a network as forming an undirected graph. The vertices consist of routers, with an edge joining two routers if they are adjacent. The graph of adjacencies describes the flow of routing protocol packets, and in particular Link State Update Packets, through the Autonomous System.
人はネットワークにおける非指示されたグラフを形成するとしての隣接番組の収集について描写できます。 頭頂はそれらが隣接しているなら縁が2つのルータを接合しているルータから成ります。 隣接番組のグラフはルーティング・プロトコルパケット、および特にLink州Update Packetsの流れについて説明します、Autonomous Systemを通して。
Two graphs are possible, depending on whether a Designated Router is elected for the network. On physical point-to-point networks, Point-to-MultiPoint networks and virtual links, neighboring routers become adjacent whenever they can communicate directly. In contrast, on broadcast and NBMA networks only the Designated Router and the Backup Designated Router become adjacent to all other routers attached to the network.
Designated Routerがネットワークのために選出されるかどうかによって、2つのグラフが可能です。 物理的な二地点間ネットワークでは、直接伝達できるときはいつも、PointからMultiPointへのネットワークと仮想のリンク、隣接しているルータは隣接するようになります。 対照的に、放送とNBMAネットワークだけでは、Designated RouterとBackup Designated Routerはネットワークに付けられた他のすべてのルータに隣接してなります。
These graphs are shown in Figure 10. It is assumed that Router RT7 has become the Designated Router, and Router RT3 the Backup Designated Router, for the Network N2. The Backup Designated Router performs a lesser function during the flooding procedure than the Designated Router (see Section 13.3). This is the reason for the dashed lines connecting the Backup Designated Router RT3.
これらのグラフは図10に示されます。 Router RT7がDesignated Router、およびRouter RT3Backup Designated Routerになったと思われます、Network N2のために。 Backup Designated Routerは氾濫手順の間、Designated Routerより少ない機能を実行します(セクション13.3を見てください)。 これはBackup Designated Router RT3を接続する投げつけられた系列の理由です。
Moy Standards Track [Page 48] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[48ページ]RFC2178OSPFバージョン1997年7月2日
+---+ +---+
|RT1|------------|RT2| o---------------o
+---+ N1 +---+ RT1 RT2
+---+ +---+ |RT1|------------|RT2| o---------------o +---+ N1+---+ RT1 RT2
RT7
o---------+
+---+ +---+ +---+ /|\ |
|RT7| |RT3| |RT4| / | \ |
+---+ +---+ +---+ / | \ |
| | | / | \ |
+-----------------------+ RT5o RT6o oRT4 |
| | N2 * * * |
+---+ +---+ * * * |
|RT5| |RT6| * * * |
+---+ +---+ *** |
o---------+
RT3
RT7o---------+ +---+ +---+ +---+ /|\ | |RT7| |RT3| |RT4| / | \ | +---+ +---+ +---+ / | \ | | | | / | \ | +-----------------------+ RT5o RT6o oRT4| | | N2***| +---+ +---+ * * * | |RT5| |RT6| * * * | +---+ +---+ *** | o---------+ RT3
Figure 10: The graph of adjacencies
図10: 隣接番組のグラフ
8. Protocol Packet Processing
8. プロトコルパケット処理
This section discusses the general processing of OSPF routing protocol packets. It is very important that the router link-state databases remain synchronized. For this reason, routing protocol packets should get preferential treatment over ordinary data packets, both in sending and receiving.
このセクションはOSPFルーティング・プロトコルパケットの一般的な処理について論じます。 ルータリンク州のデータベースが連動したままで残っているのは、非常に重要です。 この理由で、ルーティング・プロトコルパケットは発信と受信で普通のデータ・パケットの上に優遇を得るはずです。
Routing protocol packets are sent along adjacencies only (with the exception of Hello packets, which are used to discover the adjacencies). This means that all routing protocol packets travel a single IP hop, except those sent over virtual links.
隣接番組だけに沿ってルーティング・プロトコルパケットを送ります。 これは、仮想のリンクの上に送られたものを除いて、すべてのルーティング・プロトコルパケットが単一のIPホップを旅行することを意味します。
All routing protocol packets begin with a standard header. The sections below provide details on how to fill in and verify this standard header. Then, for each packet type, the section giving more details on that particular packet type's processing is listed.
すべてのルーティング・プロトコルパケットが標準のヘッダーと共に始まります。 下のセクションはこの標準のヘッダーに記入して、どう確かめるかに関する詳細を明らかにします。 その時、それぞれのパケットタイプにおいて、その特定のパケットタイプの処理に関するその他の詳細を与えるセクションは記載されています。
8.1. Sending protocol packets
8.1. 送付プロトコルパケット
When a router sends a routing protocol packet, it fills in the fields of the standard OSPF packet header as follows. For more details on the header format consult Section A.3.1:
ルータがルーティング・プロトコルパケットを送るとき、それは以下の標準のOSPFパケットのヘッダーの分野に記入します。 ヘッダー形式に関するその他の詳細に関しては、セクションA.3.1に相談してください:
Moy Standards Track [Page 49] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[49ページ]RFC2178OSPFバージョン1997年7月2日
Version #
Set to 2, the version number of the protocol as documented in this
specification.
2へのバージョン#Set、記録されるとしてのこの仕様によるプロトコルのバージョン番号。
Packet type
The type of OSPF packet, such as Link state Update or Hello
Packet.
パケットはLink州のUpdateかHello PacketなどのOSPFパケットのタイプをタイプします。
Packet length
The length of the entire OSPF packet in bytes, including the
standard OSPF packet header.
パケット長は標準のOSPFパケットのヘッダーを含むバイトで表現される全体のOSPFパケットの長さです。
Router ID
The identity of the router itself (who is originating the packet).
ルータID、ルータ(パケットを溯源している)自体のアイデンティティ。
Area ID
The OSPF area that the packet is being sent into.
領域ID、パケットが送られるOSPF領域。
Checksum
The standard IP 16-bit one's complement checksum of the entire
OSPF packet, excluding the 64-bit authentication field. This
checksum is calculated as part of the appropriate authentication
procedure; for some OSPF authentication types, the checksum
calculation is omitted. See Section D.4 for details.
チェックサム、64ビットの認証分野を除いた全体のOSPFパケットの標準のIP16ビットの1の補数チェックサム。 このチェックサムは適切な認証手順の一部として計算されます。 何人かのOSPF認証タイプにおいて、チェックサム計算は省略されます。 詳細に関してセクションD.4を見てください。
AuType and Authentication
Each OSPF packet exchange is authenticated. Authentication types
are assigned by the protocol and are documented in Appendix D. A
different authentication procedure can be used for each IP
network/subnet. Autype indicates the type of authentication
procedure in use. The 64-bit authentication field is then for use
by the chosen authentication procedure. This procedure should be
the last called when forming the packet to be sent. See Section
D.4 for details.
AuTypeとAuthentication Each OSPFパケット交換は認証されます。 認証タイプを、プロトコルによって割り当てられて、Appendix D.に記録します。それぞれのIPネットワーク/サブネットにA異なった認証手順を用いることができます。 Autypeは使用中の認証手順のタイプを示します。 64ビットの認証分野は選ばれた認証手順によってそして、使用のためのものです。 この手順は送られるパケットを形成するとき呼ばれる最終であるべきです。 詳細に関してセクションD.4を見てください。
Moy Standards Track [Page 50] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[50ページ]RFC2178OSPFバージョン1997年7月2日
The IP destination address for the packet is selected as follows. On physical point-to-point networks, the IP destination is always set to the address AllSPFRouters. On all other network types (including virtual links), the majority of OSPF packets are sent as unicasts, i.e., sent directly to the other end of the adjacency. In this case, the IP destination is just the Neighbor IP address associated with the other end of the adjacency (see Section 10). The only packets not sent as unicasts are on broadcast networks; on these networks Hello packets are sent to the multicast destination AllSPFRouters, the Designated Router and its Backup send both Link State Update Packets and Link State Acknowledgment Packets to the multicast address AllSPFRouters, while all other routers send both their Link State Update and Link State Acknowledgment Packets to the multicast address AllDRouters.
パケットのための受信者IPアドレスは以下の通り選択されます。 物理的な二地点間ネットワークでは、IPの目的地はいつもアドレスAllSPFRoutersに設定されます。 他のすべてのネットワークタイプ(仮想のリンクを含んでいる)で、すなわち、ユニキャストとして直接隣接番組のもう一方の端に送った状態でOSPFパケットの大部分を送ります。 この場合、IPの目的地はただ隣接番組のもう一方の端に関連しているNeighbor IPアドレス(セクション10を見る)です。 ユニキャストが放送網にあるので、唯一のパケットは発信しませんでした。 これらのネットワークでは、マルチキャストの目的地AllSPFRoutersにHelloパケットを送ります、そして、Designated RouterとそのBackupは両方のLink州Update Packetsを送ります、そして、マルチキャストへのLink州Acknowledgment PacketsはAllSPFRoutersを扱います、それらのLink州UpdateとLink州Acknowledgment Packetsの両方が他のすべてのルータでマルチキャストアドレスAllDRoutersに行きますが。
Retransmissions of Link State Update packets are ALWAYS sent as unicasts.
Link州UpdateパケットのRetransmissionsはユニキャストとして送られたALWAYSです。
The IP source address should be set to the IP address of the sending interface. Interfaces to unnumbered point-to-point networks have no associated IP address. On these interfaces, the IP source should be set to any of the other IP addresses belonging to the router. For this reason, there must be at least one IP address assigned to the router.[2] Note that, for most purposes, virtual links act precisely the same as unnumbered point-to-point networks. However, each virtual link does have an IP interface address (discovered during the routing table build process) which is used as the IP source when sending packets over the virtual link.
IPソースアドレスは送付インタフェースのIPアドレスに設定されるべきです。 無数の二地点間ネットワークへのインタフェースには、どんな関連IPアドレスもありません。 これらのインタフェースでは、IPソースはルータに属す他のIPアドレスのいずれへのセットであるべきです。 この理由で、仮想のリンクがほとんどの目的のために無数の二地点間ネットワークと正確に同じに作動するというルータ.[2]メモに割り当てられた少なくとも1つのIPアドレスがあるに違いありません。 しかしながら、それぞれの仮想のリンクには、仮想のリンクの上にパケットを送るときIPソースとして使用されるIPインターフェース・アドレス(経路指定テーブルの間、プロセスを建てるように発見する)があります。
For more information on the format of specific OSPF packet types, consult the sections listed in Table 10.
特定のOSPFパケットタイプの形式の詳しい情報に関しては、Table10に記載されたセクションに相談してください。
Type Packet name detailed section (transmit)
_________________________________________________________
1 Hello Section 9.5
2 Database description Section 10.8
3 Link state request Section 10.9
4 Link state update Section 13.3
5 Link state ack Section 13.5
タイプPacketは詳細なセクションを命名します(伝わってください)。_________________________________________________________ 1 こんにちは、記述セクション10.8 3Linkがセクション10.9 4Link州のアップデートセクション13.3 5Link州のackセクション13.5を要求すると述べるセクション9.5 2Database
Table 10: Sections describing OSPF protocol packet transmission.
テーブル10: OSPFについて説明するセクションがパケット伝送を議定書の中で述べます。
8.2. Receiving protocol packets
8.2. プロトコルパケットを受けます。
Whenever a protocol packet is received by the router it is marked with the interface it was received on. For routers that have virtual links configured, it may not be immediately obvious which interface
ルータでプロトコルパケットを受け取るときはいつも、それは受け取られたインタフェースでマークされます。 仮想のリンクを構成するルータにおいて、どれが連結するかは、すぐに、明白でないかもしれません。
Moy Standards Track [Page 51] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[51ページ]RFC2178OSPFバージョン1997年7月2日
to associate the packet with. For example, consider the Router RT11 depicted in Figure 6. If RT11 receives an OSPF protocol packet on its interface to Network N8, it may want to associate the packet with the interface to Area 2, or with the virtual link to Router RT10 (which is part of the backbone). In the following, we assume that the packet is initially associated with the non-virtual link.[3]
パケットを関連づけるために。 例えば、図6に表現されたRouter RT11を考えてください。 RT11がインタフェースでOSPFプロトコルパケットをNetwork N8に受けるなら、それはArea2へのインタフェース、またはRouter RT10への仮想のリンクにパケットを関連づけたがっているかもしれません(バックボーンの一部です)。 以下では、私たちは、パケットが初めは非仮想のリンクに関連していると思います。[3]
In order for the packet to be accepted at the IP level, it must pass a number of tests, even before the packet is passed to OSPF for processing:
IPレベルでパケットを受け入れるために、多くのテストに合格しなければなりません、パケットが処理のためにOSPFに通過される前にさえ:
o The IP checksum must be correct.
o IPチェックサムは正しいに違いありません。
o The packet's IP destination address must be the IP address
of the receiving interface, or one of the IP multicast
addresses AllSPFRouters or AllDRouters.
o パケットの受信者IPアドレスは受信インタフェースのIPアドレスであるに違いありませんかIPマルチキャストの1つがAllSPFRoutersかAllDRoutersを扱います。
o The IP protocol specified must be OSPF (89).
o 指定されたIPプロトコルはOSPF(89)であるに違いない。
o Locally originated packets should not be passed on to OSPF.
That is, the source IP address should be examined to make
sure this is not a multicast packet that the router itself
generated.
o 局所的に溯源されたパケットをOSPFに通過するべきではありません。 すなわち、ソースIPアドレスは、これがルータ自体が生成したマルチキャストパケットでないことを確実にするために調べられるべきです。
Next, the OSPF packet header is verified. The fields specified in the header must match those configured for the receiving interface. If they do not, the packet should be discarded:
次に、OSPFパケットのヘッダーは確かめられます。 ヘッダーで指定された分野は受信インタフェースに構成されたものに合わなければなりません。 そうしないなら、パケットは捨てられるべきです:
o The version number field must specify protocol version 2.
o バージョンナンバーフィールドはプロトコルバージョン2を指定しなければなりません。
o The Area ID found in the OSPF header must be verified. If
both of the following cases fail, the packet should be
discarded. The Area ID specified in the header must either:
o OSPFヘッダーで見つけられたArea IDについて確かめなければなりません。 以下のケースの両方が失敗するなら、パケットは捨てられるべきです。 ヘッダーで指定されたArea IDはそうしなければなりません:
(1) Match the Area ID of the receiving interface. In this
case, the packet has been sent over a single hop.
Therefore, the packet's IP source address is required to
be on the same network as the receiving interface. This
can be verified by comparing the packet's IP source
address to the interface's IP address, after masking
both addresses with the interface mask. This comparison
should not be performed on point-to-point networks. On
point-to-point networks, the interface addresses of each
end of the link are assigned independently, if they are
assigned at all.
(1) 受信インタフェースのArea IDを合わせてください。 この場合、単一のホップの上にパケットを送りました。 したがって、パケットのIPソースアドレスが、受信インタフェースと同じネットワークにあるのに必要です。 パケットのIPソースアドレスをインタフェースのIPアドレスにたとえることによって、これについて確かめることができます、インタフェースマスクで両方のアドレスにマスクをかけた後に。 二地点間ネットワークにこの比較を実行するべきではありません。 二地点間ネットワークに、リンクのそれぞれの端のインターフェース・アドレスは独自に配属されます、それらが少しでも割り当てられるなら。
Moy Standards Track [Page 52] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[52ページ]RFC2178OSPFバージョン1997年7月2日
(2) Indicate the backbone. In this case, the packet has
been sent over a virtual link. The receiving router
must be an area border router, and the Router ID
specified in the packet (the source router) must be the
other end of a configured virtual link. The receiving
interface must also attach to the virtual link's
configured Transit area. If all of these checks
succeed, the packet is accepted and is from now on
associated with the virtual link (and the backbone
area).
(2) バックボーンを示してください。 この場合、仮想のリンクの上にパケットを送りました。 受信ルータは境界ルータであるに違いありません、そして、パケット(ソースルータ)で指定されたRouter IDは構成された仮想のリンクのもう一方の端であるに違いありません。 また、受信インタフェースは仮想のリンクの構成されたTransit領域に付かなければなりません。 これらのチェックのすべてが成功するなら、パケットは、受け入れられて、これから先、仮想のリンク(そして、バックボーン領域)に関連づけられます。
o Packets whose IP destination is AllDRouters should only be
accepted if the state of the receiving interface is DR or
Backup (see Section 9.1).
o 受信インタフェースの状態がDRかBackup(セクション9.1を見る)である場合にだけIPの目的地がAllDRoutersであるパケットを受け入れるべきです。
o The AuType specified in the packet must match the AuType
specified for the associated area.
o パケットで指定されたAuTypeは関連領域に指定されたAuTypeに合わなければなりません。
o The packet must be authenticated. The authentication
procedure is indicated by the setting of AuType (see
Appendix D). The authentication procedure may use one or
more Authentication keys, which can be configured on a per-
interface basis. The authentication procedure may also
verify the checksum field in the OSPF packet header (which,
when used, is set to the standard IP 16-bit one's complement
checksum of the OSPF packet's contents after excluding the
64-bit authentication field). If the authentication
procedure fails, the packet should be discarded.
o パケットを認証しなければなりません。 認証手順はAuTypeの設定によって示されます(Appendix Dを見てください)。 認証手順がaで構成できる1個以上のAuthenticationキーを使用するかもしれない、-、インタフェース基礎。 また、認証手順はOSPFパケットのヘッダー(使用されると、64ビットの認証分野を除いた後のOSPFパケットのコンテンツの標準のIP16ビットの1の補数チェックサムへのセットである)のチェックサム分野について確かめるかもしれません。 認証手順が失敗するなら、パケットは捨てられるべきです。
If the packet type is Hello, it should then be further processed by the Hello Protocol (see Section 10.5). All other packet types are sent/received only on adjacencies. This means that the packet must have been sent by one of the router's active neighbors. If the receiving interface connects to a broadcast network, Point-to- MultiPoint network or NBMA network the sender is identified by the IP source address found in the packet's IP header. If the receiving interface connects to a point-to-point network or a virtual link, the sender is identified by the Router ID (source router) found in the packet's OSPF header. The data structure associated with the receiving interface contains the list of active neighbors. Packets not matching any active neighbor are discarded.
そして、パケットタイプがHelloであるなら、それはHelloプロトコルによってさらに処理されるべきです(セクション10.5を見てください)。 隣接番組だけに他のすべてのパケットタイプを送るか、または受け取ります。 これは、パケットがルータの活発な隣人のひとりによって送られたに違いないことを意味します。 受信インタフェースが接続するなら、放送網、PointからMultiPointへのネットワークまたはNBMAネットワークに、送付者はパケットのIPヘッダーで見つけられたIPソースアドレスによって特定されます。 受信インタフェースが二地点間ネットワークか仮想のリンクに接続するなら、送付者はパケットのOSPFヘッダーで見つけられたRouter ID(ソースルータ)によって特定されます。 受信インタフェースに関連しているデータ構造は活発な隣人のリストを含んでいます。 どんな活発な隣人にも合っていないパケットは捨てられます。
At this point all received protocol packets are associated with an active neighbor. For the further input processing of specific packet types, consult the sections listed in Table 11.
ここに、すべての容認されたプロトコルパケットが活発な隣人に関連しています。 特定のパケットタイプのさらなる入力処理には、Table11に記載されたセクションに相談してください。
Moy Standards Track [Page 53] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[53ページ]RFC2178OSPFバージョン1997年7月2日
Type Packet name detailed section (receive)
________________________________________________________
1 Hello Section 10.5
2 Database description Section 10.6
3 Link state request Section 10.7
4 Link state update Section 13
5 Link state ack Section 13.7
タイプPacketは詳細なセクションを命名します(受信してください)。________________________________________________________ 1 こんにちは、記述セクション10.6 3Linkがセクション10.7 4Link州のアップデートセクション13 5Link州のackセクション13.7を要求すると述べるセクション10.5 2Database
Table 11: Sections describing OSPF protocol packet reception.
テーブル11: OSPFについて説明するセクションがパケットレセプションについて議定書の中で述べます。
9. The Interface Data Structure
9. インタフェースデータ構造
An OSPF interface is the connection between a router and a network. We assume a single OSPF interface to each attached network/subnet, although supporting multiple interfaces on a single network is considered in Appendix F. Each interface structure has at most one IP interface address.
OSPFインタフェースはルータとネットワークとの関係です。 私たちはそれぞれの付属ネットワーク/サブネットに単一のOSPFインタフェースを仮定して、ただ一つのネットワークの複数のインタフェースをサポートするのは考えられますが、インタフェース構造は最も1つにAppendix F.Eachでは、IPインターフェース・アドレスを持っています。
An OSPF interface can be considered to belong to the area that contains the attached network. All routing protocol packets originated by the router over this interface are labelled with the interface's Area ID. One or more router adjacencies may develop over an interface. A router's LSAs reflect the state of its interfaces and their associated adjacencies.
OSPFインタフェースが付属ネットワークを含む領域に属すと考えることができます。 このインタフェースの上でルータによって溯源されたすべてのルーティング・プロトコルパケットがインタフェースのArea IDでラベルされます。 1つ以上のルータ隣接番組がインタフェースの上で展開するかもしれません。 ルータのLSAsはインタフェースとそれらの関連隣接番組の状態を反映します。
The following data items are associated with an interface. Note that a number of these items are actually configuration for the attached network; such items must be the same for all routers connected to the network.
以下のデータ項目はインタフェースに関連しています。 これらの多くの項目が実際に付属ネットワークのための構成であることに注意してください。 ネットワークに関連づけられたすべてのルータに、そのような項目は同じであるに違いありません。
Type
The OSPF interface type is either point-to-point, broadcast, NBMA,
Point-to-MultiPoint or virtual link.
OSPFインタフェースがタイプするタイプは、ポイントツーポイント、放送、NBMA、PointからMultiPointまたは仮想のリンクです。
State
The functional level of an interface. State determines whether or
not full adjacencies are allowed to form over the interface.
State is also reflected in the router's LSAs.
インタフェースの機能的なレベルを述べてください。 州は、完全な隣接番組がインタフェースの上で形成できるかどうか決定します。 また、状態はルータのLSAsに反映されます。
IP interface address
The IP address associated with the interface. This appears as the
IP source address in all routing protocol packets originated over
this interface. Interfaces to unnumbered point-to-point networks
do not have an associated IP address.
IPアドレスがインタフェースに関連づけたIPインターフェース・アドレス。 すべてのルーティング・プロトコルパケットのIPソースアドレスがこのインタフェースの上で起因したので、これは現れます。 無数の二地点間ネットワークへのインタフェースには、関連IPアドレスがありません。
IP interface mask
Also referred to as the subnet mask, this indicates the portion of
the IP interface address that identifies the attached network.
サブネットマスクと呼ばれたIPインタフェースマスクAlso、これは付属ネットワークを特定するIPインターフェース・アドレスの部分を示します。
Moy Standards Track [Page 54] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[54ページ]RFC2178OSPFバージョン1997年7月2日
Masking the IP interface address with the IP interface mask yields
the IP network number of the attached network. On point-to-point
networks and virtual links, the IP interface mask is not defined.
On these networks, the link itself is not assigned an IP network
number, and so the addresses of each side of the link are assigned
independently, if they are assigned at all.
IPインタフェースマスクでIPインターフェース・アドレスにマスクをかけると、付属ネットワークのIPネットワーク・ナンバーはもたらされます。 二地点間ネットワークと仮想のリンク、IPでは、インタフェースマスクは定義されません。 これらのネットワークでは、IPネットワーク・ナンバーがリンク自体に割り当てられないので、リンクのそれぞれの側面のアドレスは独自に割り当てられます、それらが少しでも割り当てられるなら。
Area ID
The Area ID of the area to which the attached network belongs.
All routing protocol packets originating from the interface are
labelled with this Area ID.
付属ネットワークが属する領域の領域ID Area ID。 インタフェースから発するすべてのルーティング・プロトコルパケットがこのArea IDでラベルされます。
HelloInterval
The length of time, in seconds, between the Hello packets that the
router sends on the interface. Advertised in Hello packets sent
out this interface.
ルータがインタフェースで送るHelloパケットの間の秒の時間の長さのHelloInterval。 Helloの広告に掲載されていて、パケットはこのインタフェースを出しました。
RouterDeadInterval
The number of seconds before the router's neighbors will declare
it down, when they stop hearing the router's Hello Packets.
Advertised in Hello packets sent out this interface.
ルータの隣人の前の秒数が望んでいるRouterDeadIntervalは下にそれを宣言します、彼らが、ルータのHello Packetsを聞くのを止めると。 Helloの広告に掲載されていて、パケットはこのインタフェースを出しました。
InfTransDelay
The estimated number of seconds it takes to transmit a Link State
Update Packet over this interface. LSAs contained in the Link
State Update packet will have their age incremented by this amount
before transmission. This value should take into account
transmission and propagation delays; it must be greater than zero.
概算のInfTransDelayは、Link州Update Packetをこのインタフェースの上に伝えるのにそれがかかる秒に付番します。 Link州Updateパケットに含まれたLSAsはトランスミッションの前にこの量で彼らの時代を増加させるでしょう。 この値はトランスミッションと伝播遅延を考慮に入れるべきです。 それはゼロ以上であるに違いありません。
Router Priority
An 8-bit unsigned integer. When two routers attached to a network
both attempt to become Designated Router, the one with the highest
Router Priority takes precedence. A router whose Router Priority
is set to 0 is ineligible to become Designated Router on the
attached network. Advertised in Hello packets sent out this
interface.
ルータPriority An、8ビットの符号のない整数。 ネットワークに付けられた2つのルータが、Designated Routerになるのをともに試みるとき、最も高いRouter Priorityがあるものは優先します。 Router Priorityが0に用意ができているルータは付属ネットワークでDesignated Routerになるのにおいて不適格です。 Helloの広告に掲載されていて、パケットはこのインタフェースを出しました。
Hello Timer
An interval timer that causes the interface to send a Hello
packet. This timer fires every HelloInterval seconds. Note that
on non-broadcast networks a separate Hello packet is sent to each
qualified neighbor.
こんにちは、Timer An。インタフェースがHelloパケットを送るインタバルタイマ。 あらゆるHelloIntervalが後援するこのタイマ炎。 非放送網では、別々のHelloパケットがそれぞれの適任の隣人に送られることに注意してください。
Wait Timer
A single shot timer that causes the interface to exit the Waiting
state, and as a consequence select a Designated Router on the
network. The length of the timer is RouterDeadInterval seconds.
待ちTimer AはインタフェースがWaiting状態を出るショットタイマを選抜して、結果としてネットワークでDesignated Routerを選定します。 タイマの長さはRouterDeadInterval秒です。
Moy Standards Track [Page 55] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[55ページ]RFC2178OSPFバージョン1997年7月2日
List of neighboring routers
The other routers attached to this network. This list is formed
by the Hello Protocol. Adjacencies will be formed to some of
these neighbors. The set of adjacent neighbors can be determined
by an examination of all of the neighbors' states.
他のルータがこのネットワークに付けた隣接しているルータのリスト。 このリストはHelloプロトコルによって形成されます。 隣接番組は何人かのこれらの隣人に形成されるでしょう。 隣接している隣人のセットは隣人の州のすべての試験で決定できます。
Designated Router
The Designated Router selected for the attached network. The
Designated Router is selected on all broadcast and NBMA networks
by the Hello Protocol. Two pieces of identification are kept for
the Designated Router: its Router ID and its IP interface address
on the network. The Designated Router advertises link state for
the network; this network-LSA is labelled with the Designated
Router's IP address. The Designated Router is initialized to
0.0.0.0, which indicates the lack of a Designated Router.
付属ネットワークのために選択されたDesignated RouterにRouterを指定しました。 Designated Routerはすべての放送とNBMAネットワークでHelloプロトコルによって選択されます。 識別の2つの断片がDesignated Routerのために保たれます: Router IDとそのIPはネットワークにアドレスを連結します。 Designated Routerはネットワークのためにリンク状態の広告を出します。 このネットワーク-LSAはDesignated RouterのIPアドレスでラベルされます。 Designated Routerは0.0に初期化されます。.0 .0 Designated Routerの不足を示す。
Backup Designated Router
The Backup Designated Router is also selected on all broadcast and
NBMA networks by the Hello Protocol. All routers on the attached
network become adjacent to both the Designated Router and the
Backup Designated Router. The Backup Designated Router becomes
Designated Router when the current Designated Router fails. The
Backup Designated Router is initialized to 0.0.0.0, indicating the
lack of a Backup Designated Router.
また、バックアップDesignated Router Backup Designated Routerはすべての放送とNBMAネットワークでHelloプロトコルによって選択されます。 付属ネットワークのすべてのルータがDesignated RouterとBackup Designated Routerの両方に隣接してなります。 現在のDesignated Routerが失敗すると、Backup Designated RouterはDesignated Routerになります。 Backup Designated Routerは0.0に初期化されます。.0 .0 Backup Designated Routerの不足を示します。
Interface output cost(s)
The cost of sending a data packet on the interface, expressed in
the link state metric. This is advertised as the link cost for
this interface in the router-LSA. The cost of an interface must be
greater than zero.
インタフェース出力は(s) リンク状態でメートル法で言い表されたインタフェースにデータ・パケットを送る費用かかります。 ルータ-LSAのこのインタフェースへのリンク費用としてこれの広告を出します。 インタフェースの費用はゼロ以上であるに違いありません。
RxmtInterval
The number of seconds between LSA retransmissions, for adjacencies
belonging to this interface. Also used when retransmitting
Database Description and Link State Request Packets.
RxmtInterval、LSA retransmissionsの間のこのインタフェースに属す隣接番組の秒数。 また、Database記述とLink州Request Packetsを再送するとき、使用されます。
AuType
The type of authentication used on the attached network/subnet.
Authentication types are defined in Appendix D. All OSPF packet
exchanges are authenticated. Different authentication schemes may
be used on different networks/subnets.
付属ネットワーク/サブネットで使用される認証のタイプのAuType。 認証タイプはAppendix D.で定義されます。All OSPFパケット交換は認証されます。 異なった認証体系は異なったネットワーク/サブネットで使用されるかもしれません。
Moy Standards Track [Page 56] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[56ページ]RFC2178OSPFバージョン1997年7月2日
Authentication key
This configured data allows the authentication procedure to
generate and/or verify OSPF protocol packets. The Authentication
key can be configured on a per-interface basis. For example, if
the AuType indicates simple password, the Authentication key would
be a 64-bit clear password which is inserted into the OSPF packet
header. If instead Autype indicates Cryptographic authentication,
then the Authentication key is a shared secret which enables the
generation/verification of message digests which are appended to
the OSPF protocol packets. When Cryptographic authentication is
used, multiple simultaneous keys are supported in order to achieve
smooth key transition (see Section D.3).
認証の主要なThisは、認証手順がOSPFプロトコルパケットについて生成する、そして/または、データで確かめることができるのを構成しました。 1インタフェースあたり1個のベースでAuthenticationキーを構成できます。 AuTypeが簡単なパスワードを示すなら、例えば、AuthenticationキーはOSPFパケットのヘッダーに挿入される64ビットの明確なパスワードでしょう。 Autypeが代わりにCryptographic認証を示すなら、AuthenticationキーはOSPFプロトコルパケットに追加されるメッセージダイジェストの世代/検証を可能にする共有秘密キーです。 Cryptographic認証が使用されているとき、複数の同時のキーが、滑らかな主要な変遷を達成するために支えられます(セクションD.3を見てください)。
9.1. Interface states
9.1. 界面準位
The various states that router interfaces may attain is documented in this section. The states are listed in order of progressing functionality. For example, the inoperative state is listed first, followed by a list of intermediate states before the final, fully functional state is achieved. The specification makes use of this ordering by sometimes making references such as "those interfaces in state greater than X". Figure 11 shows the graph of interface state changes. The arcs of the graph are labelled with the event causing the state change. These events are documented in Section 9.2. The interface state machine is described in more detail in Section 9.3.
ルータインタフェースが達するかもしれない様々な州はこのセクションで記録されます。 機能性を進行することの順に州は記載されています。 例えば、操業していない状態は最終的で、完全に機能的な状態が獲得される前に中間的州のリストがいうことになった記載された1番目です。 仕様は、時々「Xより大きい状態のそれらのインタフェース」などの参照をすることによって、この注文を利用します。 図11は界面準位変化のグラフを示しています。 グラフのアークは州の変化を引き起こすイベントでラベルされます。 これらのイベントはセクション9.2に記録されます。 界面準位マシンはさらに詳細にセクション9.3で説明されます。
Down
This is the initial interface state. In this state, the lower-
level protocols have indicated that the interface is unusable. No
protocol traffic at all will be sent or received on such a
interface. In this state, interface parameters should be set to
their initial values.
下にThisは初期の界面準位です。 この状態では、低い平らなプロトコルは、インタフェースが使用不可能であることを示しました。 そのようなインタフェースに全くいいえプロトコルトラフィックを送るか、または受け取るでしょう。 この状態では、インタフェース・パラメータはそれらの初期の値に設定されるべきです。
Moy Standards Track [Page 57] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[57ページ]RFC2178OSPFバージョン1997年7月2日
+----+ UnloopInd +--------+
|Down|<--------------|Loopback|
+----+ +--------+
|
|InterfaceUp
+-------+ | +--------------+
|Waiting|<-+-------------->|Point-to-point|
+-------+ +--------------+
|
WaitTimer|BackupSeen
|
|
| NeighborChange
+------+ +-+<---------------- +-------+
|Backup|<----------|?|----------------->|DROther|
+------+---------->+-+<-----+ +-------+
Neighbor | |
Change | |Neighbor
| |Change
| +--+
+---->|DR|
+--+
+----+ UnloopInd+--------+ |下に| <、-、-、-、-、-、-、-、-、-、-、-、-、--、|ループバック| +----+ +--------+ | |InterfaceUp+-------+ | +--------------+ |待ち| <、-+-------------->|ポイントツーポイント| +-------+ +--------------+ | WaitTimer|BackupSeen| | | NeighborChange+------+ ++<。---------------- +-------+ |バックアップ| <、-、-、-、-、-、-、-、-、--、|?|----------------->|DROther| +------+---------->++<。-----+ +-------+ 隣人| | 変化| |隣人| |変化| +--+ +---->|博士| +--+
Figure 11: Interface State changes
図11: インタフェース州変化
In addition to the state transitions pictured,
Event InterfaceDown always forces Down State, and
Event LoopInd always forces Loopback State
変遷が描写した状態に加えて、Event InterfaceDownはいつもDown州を強制します、そして、Event LoopIndはいつもLoopback州を強制します。
All interface timers should be disabled, and there should be no
adjacencies associated with the interface.
すべてのインタフェースタイマが損傷されるべきです、そして、インタフェースに関連しているどんな隣接番組もあるべきではありません。
Loopback
In this state, the router's interface to the network is looped
back. The interface may be looped back in hardware or software.
The interface will be unavailable for regular data traffic.
However, it may still be desirable to gain information on the
quality of this interface, either through sending ICMP pings to
the interface or through something like a bit error test. For
this reason, IP packets may still be addressed to an interface in
Loopback state. To facilitate this, such interfaces are
advertised in router-LSAs as single host routes, whose destination
is the IP interface address.[4]
ループバックIn、この状態であり、ネットワークへのルータのインタフェースは輪にし返されます。 インタフェースはハードウェアかソフトウェアで輪にされるかもしれません。 インタフェースは定期的なデータ通信量を入手できなくなるでしょう。 しかしながら、送付ICMPピングを通どちらかだってこのインタフェースの品質でインタフェースに情報を得るか、または誤りテストが何かを通して少し好きであるのがまだ望ましいかもしれません。 この理由で、IPパケットはまだLoopback状態のインタフェースに扱われているかもしれません。 これを容易にするために、ただ一つのホストルートとしての目的地がIPインターフェース・アドレスであるルータ-LSAsにそのようなインタフェースの広告を出します。[4]
Moy Standards Track [Page 58] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[58ページ]RFC2178OSPFバージョン1997年7月2日
Waiting
In this state, the router is trying to determine the identity of
the (Backup) Designated Router for the network. To do this, the
router monitors the Hello Packets it receives. The router is not
allowed to elect a Backup Designated Router nor a Designated
Router until it transitions out of Waiting state. This prevents
unnecessary changes of (Backup) Designated Router.
Inを待っていて、この状態でありルータはネットワークのためにRouterに指定された(バックアップ)にアイデンティティを決定しようとしています。 これをするために、ルータはそれが受けるHello Packetsをモニターします。 ルータは、Waiting状態から移行するまでaをBackup Designated Routerに選出できて、aはDesignated Routerに選出できません。 これはRouterに指定された(バックアップ)の不要な変化を防ぎます。
Point-to-point
In this state, the interface is operational, and connects either
to a physical point-to-point network or to a virtual link. Upon
entering this state, the router attempts to form an adjacency with
the neighboring router. Hello Packets are sent to the neighbor
every HelloInterval seconds.
ポイントツーポイントIn、この状態、インタフェースは、操作上であり、物理的な二地点間ネットワーク、または、仮想のリンクに接続します。 この状態に入ると、ルータは、隣接しているルータで隣接番組を形成するのを試みます。 こんにちは、Packets。あらゆるHelloIntervalが後援する隣人に送ります。
DR Other
The interface is to a broadcast or NBMA network on which another
router has been selected to be the Designated Router. In this
state, the router itself has not been selected Backup Designated
Router either. The router forms adjacencies to both the
Designated Router and the Backup Designated Router (if they
exist).
DR Other、別のルータがDesignated Routerであることが選択された放送かNBMAネットワークにはインタフェースがあります。 この状態では、ルータ自体は選択されたBackup Designated Routerではありません。 ルータはDesignated RouterとBackup Designated Routerの両方に隣接番組を形成します(存在しているなら)。
Backup
In this state, the router itself is the Backup Designated Router
on the attached network. It will be promoted to Designated Router
when the present Designated Router fails. The router establishes
adjacencies to all other routers attached to the network. The
Backup Designated Router performs slightly different functions
during the Flooding Procedure, as compared to the Designated
Router (see Section 13.3). See Section 7.4 for more details on
the functions performed by the Backup Designated Router.
Inのバックアップをとってください。この状態、ルータ自体は付属ネットワークのBackup Designated Routerです。 現在のDesignated Routerが失敗すると、それはDesignated Routerに促進されるでしょう。 ルータはネットワークに付けられた他のすべてのルータに隣接番組を確立します。 Backup Designated RouterはFlooding Procedureの間、わずかに異なった機能を実行します、Designated Routerと比べて(セクション13.3を見てください)。 機能に関するその他の詳細のためのセクション7.4がBackup Designated Routerによって実行されるのを見てください。
DR In this state, this router itself is the Designated Router
on the attached network. Adjacencies are established to all other
routers attached to the network. The router must also originate a
network-LSA for the network node. The network-LSA will contain
links to all routers (including the Designated Router itself)
attached to the network. See Section 7.3 for more details on the
functions performed by the Designated Router.
DR In、この状態、このルータ自体は付属ネットワークのDesignated Routerです。 隣接番組はネットワークに付けられた他のすべてのルータに確立されます。 また、ルータはネットワーク・ノードのためにネットワーク-LSAを溯源しなければなりません。 LSAをネットワークでつなぐのはネットワークに付けられたすべてのルータ(Designated Router自身を含んでいる)へのリンクを含むでしょう。 機能に関するその他の詳細のためのセクション7.3がDesignated Routerによって実行されるのを見てください。
9.2. Events causing interface state changes
9.2. 界面準位変化を引き起こすイベント
State changes can be effected by a number of events. These events are pictured as the labelled arcs in Figure 11. The label definitions are listed below. For a detailed explanation of the effect of these events on OSPF protocol operation, consult Section 9.3.
州の変化は多くのイベントで作用できます。 これらのイベントは図11のラベルされたアークとして描写されます。 ラベル定義は以下に記載されています。 OSPFプロトコル操作へのこれらのイベントの効果の詳説には、セクション9.3に相談してください。
Moy Standards Track [Page 59] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[59ページ]RFC2178OSPFバージョン1997年7月2日
InterfaceUp
Lower-level protocols have indicated that the network interface is
operational. This enables the interface to transition out of Down
state. On virtual links, the interface operational indication is
actually a result of the shortest path calculation (see Section
16.7).
InterfaceUp Lower-レベルプロトコルは、ネットワーク・インターフェースが操作上であることを示しました。 これはDown状態からインタフェースを変遷に可能にします。 仮想のリンクでは、インタフェースの操作上の指示は実際に最短パス計算の結果(セクション16.7を見る)です。
WaitTimer
The Wait Timer has fired, indicating the end of the waiting period
that is required before electing a (Backup) Designated Router.
WaitTimer Wait Timerは発火しました、Routerに指定された(バックアップ)を選出する前に必要である待ちの期間の終わりを示して。
BackupSeen
The router has detected the existence or non-existence of a Backup
Designated Router for the network. This is done in one of two
ways. First, an Hello Packet may be received from a neighbor
claiming to be itself the Backup Designated Router.
Alternatively, an Hello Packet may be received from a neighbor
claiming to be itself the Designated Router, and indicating that
there is no Backup Designated Router. In either case there must
be bidirectional communication with the neighbor, i.e., the router
must also appear in the neighbor's Hello Packet. This event
signals an end to the Waiting state.
BackupSeen、ルータはネットワークのためにBackup Designated Routerの存在か非存在を検出しました。 これは2つの方法の1つで完了しています。 まず最初に、それ自体でBackup Designated Routerであると主張する隣人からHello Packetを受け取るかもしれません。 あるいはまた、それ自体でDesignated Routerであると主張して、Backup Designated Routerが全くないのを示す隣人からHello Packetを受け取るかもしれません。 どちらの場合には、隣人との双方向のコミュニケーションがあるに違いありません、また、すなわち、ルータは隣人のHello Packetに現れなければなりません。 このイベントはWaiting状態の端を示します。
NeighborChange
There has been a change in the set of bidirectional neighbors
associated with the interface. The (Backup) Designated Router
needs to be recalculated. The following neighbor changes lead to
the NeighborChange event. For an explanation of neighbor states,
see Section 10.1.
NeighborChange Thereはインタフェースに関連している双方向の隣人のセットで変化です。 Routerに指定された(バックアップ)は、再計算される必要があります。 以下の隣人変化はNeighborChangeイベントに通じます。 隣人州の説明に関しては、セクション10.1を見てください。
o Bidirectional communication has been established to a
neighbor. In other words, the state of the neighbor has
transitioned to 2-Way or higher.
o 双方向のコミュニケーションは隣人に確立されました。 言い換えれば、隣人の状態は2方法か、より高く移行しました。
o There is no longer bidirectional communication with a
neighbor. In other words, the state of the neighbor has
transitioned to Init or lower.
o もう、隣人との双方向のコミュニケーションがありません。 言い換えれば、隣人の状態はInitか下側に移行しました。
o One of the bidirectional neighbors is newly declaring
itself as either Designated Router or Backup Designated
Router. This is detected through examination of that
neighbor's Hello Packets.
o 双方向の隣人のひとりはDesignated RouterかBackup Designated Routerのどちらかとして新たにそれ自体を宣言しています。 これはその隣人のHello Packetsの試験で検出されます。
o One of the bidirectional neighbors is no longer
declaring itself as Designated Router, or is no longer
declaring itself as Backup Designated Router. This is
again detected through examination of that neighbor's
Hello Packets.
o 双方向の隣人のひとりは、もうDesignated Routerとしてそれ自体を宣言していないか、またはもうBackup Designated Routerとしてそれ自体を宣言していません。 これは再びその隣人のHello Packetsの試験で検出されます。
Moy Standards Track [Page 60] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[60ページ]RFC2178OSPFバージョン1997年7月2日
o The advertised Router Priority for a bidirectional
neighbor has changed. This is again detected through
examination of that neighbor's Hello Packets.
o 双方向の隣人のための広告を出しているRouter Priorityは変化しました。 これは再びその隣人のHello Packetsの試験で検出されます。
LoopInd
An indication has been received that the interface is now looped
back to itself. This indication can be received either from
network management or from the lower level protocols.
インタフェースが現在それ自体に輪にして戻されるというLoopInd An指示を受けました。 ネットワークマネージメントか下のレベルプロトコルからこの指示を受けることができます。
UnloopInd
An indication has been received that the interface is no longer
looped back. As with the LoopInd event, this indication can be
received either from network management or from the lower level
protocols.
インタフェースがもう輪にし返されないというUnloopInd An指示を受けました。 LoopIndイベントでネットワークマネージメントか下のレベルプロトコルからこの指示を受けることができるように。
InterfaceDown
Lower-level protocols indicate that this interface is no longer
functional. No matter what the current interface state is, the new
interface state will be Down.
InterfaceDown Lower-レベルプロトコルは、このインタフェースがもう機能的でないことを示します。 現在の界面準位が何であっても、新しい界面準位はDownになるでしょう。
9.3. The Interface state machine
9.3. Interface州のマシン
A detailed description of the interface state changes follows. Each state change is invoked by an event (Section 9.2). This event may produce different effects, depending on the current state of the interface. For this reason, the state machine below is organized by current interface state and received event. Each entry in the state machine describes the resulting new interface state and the required set of additional actions.
界面準位変化の詳述は続きます。 イベント(セクション9.2)によってそれぞれの州の変化は呼び出されます。 インタフェースの現状のときによって、このイベントは異なった効果を生むかもしれません。 この理由で、以下の州のマシンは現在の界面準位と容認されたイベントによって組織化されます。 州のマシンの各エントリーは結果として起こる新しい界面準位と必要なセットの追加機能について説明します。
When an interface's state changes, it may be necessary to originate a new router-LSA. See Section 12.4 for more details.
インタフェースの状態が変化するとき、新しいルータ-LSAを溯源するのが必要であるかもしれません。 その他の詳細に関してセクション12.4を見てください。
Some of the required actions below involve generating events for the neighbor state machine. For example, when an interface becomes inoperative, all neighbor connections associated with the interface must be destroyed. For more information on the neighbor state machine, see Section 10.3.
以下での必要な動作のいくつかが、隣人州のマシンのためにイベントを生成することを伴います。 インタフェースが効力がなくなるとき、例えば、インタフェースに関連づけられたすべての隣人接続を滅ぼさなければなりません。 隣人州のマシンの詳しい情報に関しては、セクション10.3を見てください。
Moy Standards Track [Page 61] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[61ページ]RFC2178OSPFバージョン1997年7月2日
State(s): Down
州: 下に
Event: InterfaceUp
イベント: InterfaceUp
New state: Depends upon action routine
新しい州: アクションルーチンによります。
Action: Start the interval Hello Timer, enabling the
periodic sending of Hello packets out the interface.
If the attached network is a physical point-to-point
network, Point-to-MultiPoint network or virtual
link, the interface state transitions to Point-to-
Point. Else, if the router is not eligible to
become Designated Router the interface state
transitions to DR Other.
動作: インタフェースからHelloパケットの周期的な発信を可能にして、間隔Hello Timerを始動してください。 付属ネットワークが物理的な二地点間ネットワーク、PointからMultiPointがPointからポイントにネットワークでつなぐか、または移行するという仮想のリンク、インタフェースが、述べることであるなら。 ほかに、ルータがDesignated Routerになるのが適任でないなら、界面準位はDR Otherに移行します。
Otherwise, the attached network is a broadcast or
NBMA network and the router is eligible to become
Designated Router. In this case, in an attempt to
discover the attached network's Designated Router
the interface state is set to Waiting and the single
shot Wait Timer is started. Additionally, if the
network is an NBMA network examine the configured
list of neighbors for this interface and generate
the neighbor event Start for each neighbor that is
also eligible to become Designated Router.
さもなければ、付属ネットワークは、放送かNBMAネットワークです、そして、ルータはDesignated Routerになるのが適任です。 この場合、付属ネットワークのDesignated Routerを発見する試みでは、界面準位はWaitingに設定されます、そして、ただ一つのショットWait Timerは始動されます。 さらに、ネットワークがNBMAネットワークであるならこのインタフェースがないかどうか隣人の構成されたリストを調べてください、そして、それぞれのまた、Designated Routerになるのが適任の隣人のために隣人イベントがStartであると生成してください。
State(s): Waiting
州: 待ち
Event: BackupSeen
イベント: BackupSeen
New state: Depends upon action routine.
新しい州: アクションルーチンによります。
Action: Calculate the attached network's Backup Designated
Router and Designated Router, as shown in Section
9.4. As a result of this calculation, the new state
of the interface will be either DR Other, Backup or
DR.
動作: セクション9.4に示されるように付属ネットワークのBackup Designated RouterとDesignated Routerについて計算してください。 この計算の結果、インタフェースの新しい状態は、DR Other、BackupかDRのどちらかになるでしょう。
State(s): Waiting
州: 待ち
Event: WaitTimer
イベント: WaitTimer
New state: Depends upon action routine.
新しい州: アクションルーチンによります。
Moy Standards Track [Page 62] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[62ページ]RFC2178OSPFバージョン1997年7月2日
Action: Calculate the attached network's Backup Designated
Router and Designated Router, as shown in Section
9.4. As a result of this calculation, the new state
of the interface will be either DR Other, Backup or
DR.
動作: セクション9.4に示されるように付属ネットワークのBackup Designated RouterとDesignated Routerについて計算してください。 この計算の結果、インタフェースの新しい状態は、DR Other、BackupかDRのどちらかになるでしょう。
State(s): DR Other, Backup or DR
州: DRもう一方、バックアップまたはDR
Event: NeighborChange
イベント: NeighborChange
New state: Depends upon action routine.
新しい州: アクションルーチンによります。
Action: Recalculate the attached network's Backup Designated
Router and Designated Router, as shown in Section
9.4. As a result of this calculation, the new state
of the interface will be either DR Other, Backup or
DR.
動作: セクション9.4に示されるように付属ネットワークのBackup Designated RouterとDesignated RouterをRecalculateします。 この計算の結果、インタフェースの新しい状態は、DR Other、BackupかDRのどちらかになるでしょう。
State(s): Any State
州: どんな状態
Event: InterfaceDown
イベント: InterfaceDown
New state: Down
新しい州: 下に
Action: All interface variables are reset, and interface
timers disabled. Also, all neighbor connections
associated with the interface are destroyed. This
is done by generating the event KillNbr on all
associated neighbors (see Section 10.2).
動作: すべてのインタフェース変数が、リセットと、インタフェースタイマ身体障害者です。 また、インタフェースに関連づけられたすべての隣人接続が滅ぼされます。 すべての関連隣人の上でイベントがKillNbrであると生成することによって、これをします(セクション10.2を見てください)。
State(s): Any State
州: どんな状態
Event: LoopInd
イベント: LoopInd
New state: Loopback
新しい州: ループバック
Action: Since this interface is no longer connected to the
attached network the actions associated with the
above InterfaceDown event are executed.
動作: このインタフェースがもう付属ネットワークに関連づけられないので、上のInterfaceDownイベントに関連している動作は実行されます。
State(s): Loopback
州: ループバック
Event: UnloopInd
イベント: UnloopInd
Moy Standards Track [Page 63] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[63ページ]RFC2178OSPFバージョン1997年7月2日
New state: Down
新しい州: 下に
Action: No actions are necessary. For example, the
interface variables have already been reset upon
entering the Loopback state. Note that reception of
an InterfaceUp event is necessary before the
interface again becomes fully functional.
動作: どんな動作も必要ではありません。 例えば、インタフェース変数はLoopback状態に入るとき既にリセットされました。 インタフェースが再び完全に機能的になる前にInterfaceUpイベントのレセプションが必要であることに注意してください。
9.4. Electing the Designated Router
9.4. 指定をルータに選出します。
This section describes the algorithm used for calculating a network's Designated Router and Backup Designated Router. This algorithm is invoked by the Interface state machine. The initial time a router runs the election algorithm for a network, the network's Designated Router and Backup Designated Router are initialized to 0.0.0.0. This indicates the lack of both a Designated Router and a Backup Designated Router.
このセクションはネットワークのDesignated RouterとBackup Designated Routerについて計算するのに使用されるアルゴリズムを説明します。 このアルゴリズムはInterface州のマシンによって呼び出されます。 ネットワークのルータがネットワークのために選挙アルゴリズムを実行する初期の時、Designated Router、およびBackup Designated Routerは0.0に初期化されます。.0 .0。 これはDesignated RouterとBackup Designated Routerの両方の不足を示します。
The Designated Router election algorithm proceeds as follows: Call the router doing the calculation Router X. The list of neighbors attached to the network and having established bidirectional communication with Router X is examined. This list is precisely the collection of Router X's neighbors (on this network) whose state is greater than or equal to 2-Way (see Section 10.1). Router X itself is also considered to be on the list. Discard all routers from the list that are ineligible to become Designated Router. (Routers having Router Priority of 0 are ineligible to become Designated Router.) The following steps are then executed, considering only those routers that remain on the list:
Designated Router選挙アルゴリズムは以下の通り続きます: 計算Router X.をするのにルータに電話をしてください。隣人のリストはネットワークに付きました、そして、Router Xとの双方向のコミュニケーションを確立したのは調べられます。 このリストは正確に状態がこと以上であるRouter Xの隣人(このネットワークの)の収集です。2方法(セクション10.1を見ます)。 また、ルータX自体がリストにあると考えられます。 リストからのすべてのDesignated Routerになるのにおいて不適格なルータを捨ててください。 (0のRouter PriorityがあるルータはDesignated Routerになるのにおいて不適格です。) 次に、リストに残っているそれらのルータだけを考える場合、以下のステップは実行されます:
(1) Note the current values for the network's Designated Router
and Backup Designated Router. This is used later for
comparison purposes.
(1) ネットワークのDesignated RouterとBackup Designated Routerによって現行価値に注意してください。 これは後で比較目的に使用されます。
(2) Calculate the new Backup Designated Router for the network
as follows. Only those routers on the list that have not
declared themselves to be Designated Router are eligible to
become Backup Designated Router. If one or more of these
routers have declared themselves Backup Designated Router
(i.e., they are currently listing themselves as Backup
Designated Router, but not as Designated Router, in their
Hello Packets) the one having highest Router Priority is
declared to be Backup Designated Router. In case of a tie,
the one having the highest Router ID is chosen. If no
routers have declared themselves Backup Designated Router,
(2) 以下のネットワークのために新しいBackup Designated Routerについて計算してください。 リストの上の自分たちがDesignated Routerであると宣言していないそれらのルータだけがBackup Designated Routerになるのが適任です。 これらのルータのものか以上が、自分たちがBackup Designated Routerであると宣言したなら(現在自分たちについてBackup Designated Routerに記載しますが、Designated Routerとして記載しているというわけではありません、それらのHello Packetsで)、持っている中でRouter Priority最も高いものはBackup Designated Routerであると宣言されます。 繋がりの場合には、持っている中でRouter ID最も高いものは選ばれています。 どんなルータも、自分たちがBackup Designated Routerであると宣言していないなら
Moy Standards Track [Page 64] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[64ページ]RFC2178OSPFバージョン1997年7月2日
choose the router having highest Router Priority, (again
excluding those routers who have declared themselves
Designated Router), and again use the Router ID to break
ties.
持っている中でRouter Priority最も高いルータ、(再び、それらのルータを除きます自分たちがDesignated Routerであると宣言した)と選んでください、そして、もう一度Router IDを使用して、結びつきを壊してください。
(3) Calculate the new Designated Router for the network as
follows. If one or more of the routers have declared
themselves Designated Router (i.e., they are currently
listing themselves as Designated Router in their Hello
Packets) the one having highest Router Priority is declared
to be Designated Router. In case of a tie, the one having
the highest Router ID is chosen. If no routers have
declared themselves Designated Router, assign the Designated
Router to be the same as the newly elected Backup Designated
Router.
(3) 以下のネットワークのために新しいDesignated Routerについて計算してください。 ルータのものか以上が、自分たちがDesignated Routerであると宣言したなら(すなわち、彼らは現在、自分達のHello Packetsに自分たちについてDesignated Routerに記載しています)、持っている中でRouter Priority最も高いものはDesignated Routerであると宣言されます。 繋がりの場合には、持っている中でRouter ID最も高いものは選ばれています。 どんなルータも、自分たちがDesignated Routerであると宣言していないなら、新たに選出されたBackup Designated Routerと同じになるようにDesignated Routerを割り当ててください。
(4) If Router X is now newly the Designated Router or newly the
Backup Designated Router, or is now no longer the Designated
Router or no longer the Backup Designated Router, repeat
steps 2 and 3, and then proceed to step 5. For example, if
Router X is now the Designated Router, when step 2 is
repeated X will no longer be eligible for Backup Designated
Router election. Among other things, this will ensure that
no router will declare itself both Backup Designated Router
and Designated Router.[5]
(4) Router Xが現在新たにそうである、Designated Router、新たに、Backup Designated Router、現在は、もうDesignated RouterかもうBackup Designated Routerであり、ステップ2と3を繰り返してください、そして、次に、5に踏みかけてください。 ステップ2が繰り返されるとき、例えば、現在Router XがDesignated Routerであるなら、XはもうBackup Designated Router選挙に適任にならないでしょう。 特に、これは、どんなルータも、それ自体がBackup Designated RouterとDesignated Routerの両方であると宣言しないのを確実にするでしょう。[5]
(5) As a result of these calculations, the router itself may now
be Designated Router or Backup Designated Router. See
Sections 7.3 and 7.4 for the additional duties this would
entail. The router's interface state should be set
accordingly. If the router itself is now Designated Router,
the new interface state is DR. If the router itself is now
Backup Designated Router, the new interface state is Backup.
Otherwise, the new interface state is DR Other.
(5) これらの計算の結果、現在、ルータ自体は、Designated RouterかBackup Designated Routerであるかもしれません。 これが伴う追加関税に関してセクション7.3と7.4を見てください。 ルータの界面準位はそれに従って、設定されるべきです。 現在ルータ自体がDesignated Routerであるなら、新しい界面準位はDRです。現在ルータ自体がBackup Designated Routerであるなら、新しい界面準位はBackupです。 さもなければ、新しい界面準位はDR Otherです。
(6) If the attached network is an NBMA network, and the router
itself has just become either Designated Router or Backup
Designated Router, it must start sending Hello Packets to
those neighbors that are not eligible to become Designated
Router (see Section 9.5.1). This is done by invoking the
neighbor event Start for each neighbor having a Router
Priority of 0.
(6) 付属ネットワークがNBMAネットワークであり、ルータ自体がちょうどDesignated RouterかBackup Designated Routerのどちらかになったところであるなら、それは、それらのDesignated Routerになるのが適任でない隣人にHello Packetsを送り始めなければなりません(セクション9.5.1を見てください)。 0のRouter Priorityを持っている各隣人のために隣人イベントStartを呼び出すことによって、これをします。
(7) If the above calculations have caused the identity of either
the Designated Router or Backup Designated Router to change,
the set of adjacencies associated with this interface will
need to be modified. Some adjacencies may need to be
formed, and others may need to be broken. To accomplish
(7) Designated RouterかBackup Designated Routerのどちらかのアイデンティティが上の計算で変化したなら、このインタフェースに関連している隣接番組のセットは、変更される必要があるでしょう。 いくつかの隣接番組が、形成される必要があるかもしれません、そして、他のものは壊れる必要があるかもしれません。 達成します。
Moy Standards Track [Page 65] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[65ページ]RFC2178OSPFバージョン1997年7月2日
this, invoke the event AdjOK? on all neighbors whose state
is at least 2-Way. This will cause their eligibility for
adjacency to be reexamined (see Sections 10.3 and 10.4).
これ、イベントAdjOKを呼び出してください--少なくとも状態が2方法であるすべての隣人に関して これは再検討されるべき隣接番組のためにそれらの適任を引き起こすでしょう(セクション10.3と10.4を見てください)。
The reason behind the election algorithm's complexity is the desire for an orderly transition from Backup Designated Router to Designated Router, when the current Designated Router fails. This orderly transition is ensured through the introduction of hysteresis: no new Backup Designated Router can be chosen until the old Backup accepts its new Designated Router responsibilities.
選挙アルゴリズムの複雑さの後ろの理由は規則的なBackup Designated RouterからDesignated Routerまでの変遷に関する願望です、現在のDesignated Routerが失敗すると。 この規則的な変遷はヒステリシスの導入で確実にされます: 古いBackupが新しいDesignated Router責任を引き受けるまで、どんな新しいBackup Designated Routerも選ぶことができません。
The above procedure may elect the same router to be both Designated Router and Backup Designated Router, although that router will never be the calculating router (Router X) itself. The elected Designated Router may not be the router having the highest Router Priority, nor will the Backup Designated Router necessarily have the second highest Router Priority. If Router X is not itself eligible to become Designated Router, it is possible that neither a Backup Designated Router nor a Designated Router will be selected in the above procedure. Note also that if Router X is the only attached router that is eligible to become Designated Router, it will select itself as Designated Router and there will be no Backup Designated Router for the network.
上の手順はDesignated RouterとBackup Designated Routerの両方になるように同じくらいルータに選出するかもしれません、そのルータは決して計算のルータ(ルータX)自体でないでしょうが。 選出されたDesignated Routerは持っている中でRouter Priority最も高いルータでないかもしれません、そして、Backup Designated Routerには、2番目に高いRouter Priorityが必ずあるというわけではないでしょう。 Router XがDesignated Routerになるのがそれ自体で適任でないなら、Backup Designated RouterもDesignated Routerも上の手順で選択されないのは、可能です。 また、Router Xが唯一のDesignated Routerになるのが適任の付属ルータであるなら、Designated Routerとしてそれ自体を選定して、ネットワークのためのBackup Designated Routerが全くないことに注意してください。
9.5. Sending Hello packets
9.5. 送付Helloパケット
Hello packets are sent out each functioning router interface. They are used to discover and maintain neighbor relationships.[6] On broadcast and NBMA networks, Hello Packets are also used to elect the Designated Router and Backup Designated Router.
こんにちは、パケットはそうです。それぞれの機能しているルータインタフェースを出しました。 それらは放送とNBMAネットワークで隣人関係.[6]を発見して、維持するのに使用されます、また、Hello Packetsは、Designated RouterとBackup Designated Routerを選出するのに使用されます。
The format of an Hello packet is detailed in Section A.3.2. The Hello Packet contains the router's Router Priority (used in choosing the Designated Router), and the interval between Hello Packets sent out the interface (HelloInterval). The Hello Packet also indicates how often a neighbor must be heard from to remain active (RouterDeadInterval). Both HelloInterval and RouterDeadInterval must be the same for all routers attached to a common network. The Hello packet also contains the IP address mask of the attached network (Network Mask). On unnumbered point-to-point networks and on virtual links this field should be set to 0.0.0.0.
Helloパケットの形式はセクションA.3.2で詳細です。 Hello PacketはルータのRouter Priority(Designated Routerを選ぶ際に、使用される)を含んでいます、そして、Hello Packetsの間隔はインタフェース(HelloInterval)を出しました。 また、Hello Packetは、しばしば隣人からアクティブなままで(RouterDeadInterval)残っているのをどのように聞かなければならないかを示します。 一般的なネットワークに付けられたすべてのルータに、HelloIntervalとRouterDeadIntervalの両方が同じであるに違いありません。 また、Helloパケットは付属ネットワーク(ネットワークMask)のIPアドレスマスクを含んでいます。 無数の二地点間ネットワークと仮想のリンクに関して、この分野は.0に0.0に.0を設定することであるべきです。
The Hello packet's Options field describes the router's optional OSPF capabilities. One optional capability is defined in this specification (see Sections 4.5 and A.2). The E-bit of the Options field should be set if and only if the attached area is capable of processing AS-external-LSAs (i.e., it is not a stub area). If the E-
HelloパケットのOptions分野はルータの任意のOSPF能力について説明します。 1つの任意の能力がこの仕様に基づき定義されます(セクション4.5とA.2を見てください)。 そして、Options分野のE-ビットが設定されるべきである、付属領域は処理のASの外部のLSAsができる場合にだけ(すなわち、それはスタッブ領域ではありません)。 電子
Moy Standards Track [Page 66] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[66ページ]RFC2178OSPFバージョン1997年7月2日
bit is set incorrectly the neighboring routers will refuse to accept the Hello Packet (see Section 10.5). Unrecognized bits in the Hello Packet's Options field should be set to zero.
ビットは不当に設定されて、隣接しているルータが、Hello Packetを受け入れるのを拒否するという(セクション10.5を見てください)ことです。 Hello PacketのOptions分野の認識されていないビットはゼロに設定されるべきです。
In order to ensure two-way communication between adjacent routers, the Hello packet contains the list of all routers on the network from which Hello Packets have been seen recently. The Hello packet also contains the router's current choice for Designated Router and Backup Designated Router. A value of 0.0.0.0 in these fields means that one has not yet been selected.
隣接しているルータの双方向通信を確実にするために、HelloパケットはHello Packetsが最近見られたネットワークにすべてのルータのリストを含んでいます。 また、HelloパケットはDesignated RouterとBackup Designated Routerのためのルータの現在の選択を含んでいます。 値、0.0では、これらの.0がさばく.0は、1つがまだ選択されていないことを意味します。
On broadcast networks and physical point-to-point networks, Hello packets are sent every HelloInterval seconds to the IP multicast address AllSPFRouters. On virtual links, Hello packets are sent as unicasts (addressed directly to the other end of the virtual link) every HelloInterval seconds. On Point-to-MultiPoint networks, separate Hello packets are sent to each attached neighbor every HelloInterval seconds. Sending of Hello packets on NBMA networks is covered in the next section.
放送網と物理的な二地点間ネットワークでは、IPマルチキャストへの秒がAllSPFRoutersを扱うあらゆるHelloIntervalをHelloパケットに送ります。 仮想のリンクに、あらゆるHelloIntervalが後援するユニキャスト(直接仮想のリンクのもう一方の端に送る)としてHelloパケットを送ります。 PointからMultiPointへのネットワークでは、あらゆるHelloIntervalが後援するそれぞれの付属隣人に別々のHelloパケットを送ります。 NBMAネットワークでのHelloパケットの発信は次のセクションでカバーされています。
9.5.1. Sending Hello packets on NBMA networks
9.5.1. NBMAネットワークでパケットをHelloに送ります。
Static configuration information may be necessary in order for the Hello Protocol to function on non-broadcast networks (see Sections C.5 and C.6). On NBMA networks, every attached router which is eligible to become Designated Router becomes aware of all of its neighbors on the network (either through configuration or by some unspecified mechanism). Each neighbor is labelled with the neighbor's Designated Router eligibility.
静的な設定情報が、Helloプロトコルが非放送網で機能するのに必要であるかもしれません(セクションのC.5とC.6を見てください)。 NBMAネットワークでは、あらゆるDesignated Routerになるのが適任の付属ルータがネットワーク(構成を通した、または、何らかの不特定のメカニズムによる)で隣人を皆、意識するようになります。 各隣人は自分のDesignated Router適任でレッテルを貼られます。
The interface state must be at least Waiting for any Hello Packets to be sent out the NBMA interface. Hello Packets are then sent directly (as unicasts) to some subset of a router's neighbors. Sometimes an Hello Packet is sent periodically on a timer; at other times it is sent as a response to a received Hello Packet. A router's hello- sending behavior varies depending on whether the router itself is eligible to become Designated Router.
界面準位はどんなHello Packetsも出される少なくともWaitingがNBMAインタフェースであったならそうしなければなりません。 こんにちは、Packetsはそうです。隣人はそしてにルータの何らかの部分集合に直送しました(ユニキャストとして)。 時々、定期的にHello Packetをタイマに送ります。 他の時に、容認されたHello Packetへの応答としてそれを送ります。 ルータのもの、こんにちは、-、ルータ自体がDesignated Routerになるのが適任であるかどうかよって、送付の振舞いは異なります。
If the router is eligible to become Designated Router, it must periodically send Hello Packets to all neighbors that are also eligible. In addition, if the router is itself the Designated Router or Backup Designated Router, it must also send periodic Hello Packets to all other neighbors. This means that any two eligible routers are always exchanging Hello Packets, which is necessary for the correct operation of the Designated Router election algorithm. To minimize the number of Hello Packets sent, the number of eligible routers on an NBMA network should be kept small.
ルータがDesignated Routerになるのが適任であるなら、それは定期的にすべてのまた、適任の隣人にHello Packetsを送らなければなりません。 また、さらに、ルータがそれ自体でDesignated RouterかBackup Designated Routerであるなら、それは他のすべての隣人に周期的なHello Packetsを送らなければなりません。 これは、どんな2つの適任のルータもいつもHello Packetsを交換していることを意味します。(Hello PacketsがDesignated Router選挙アルゴリズムの正しい操作に必要です)。 Hello Packetsの数を最小にするのは発信して、NBMAネットワークの適任のルータの数は小さく保たれるべきです。
Moy Standards Track [Page 67] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[67ページ]RFC2178OSPFバージョン1997年7月2日
If the router is not eligible to become Designated Router, it must periodically send Hello Packets to both the Designated Router and the Backup Designated Router (if they exist). It must also send an Hello Packet in reply to an Hello Packet received from any eligible neighbor (other than the current Designated Router and Backup Designated Router). This is needed to establish an initial bidirectional relationship with any potential Designated Router.
ルータがDesignated Routerになるのが適任でないなら、それは定期的にDesignated RouterとBackup Designated Routerの両方にHello Packetsを送らなければなりません(彼らが存在するなら)。 また、それはどんな適任の隣人(現在のDesignated RouterとBackup Designated Routerを除いた)からも受け取られたHello Packetに対してHello Packetを送らなければなりません。 これが、どんな潜在的Designated Routerとの初期の双方向の関係も確立するのに必要です。
When sending Hello packets periodically to any neighbor, the interval between Hello Packets is determined by the neighbor's state. If the neighbor is in state Down, Hello Packets are sent every PollInterval seconds. Otherwise, Hello Packets are sent every HelloInterval seconds.
定期的に隣人、いずれへのHello Packetsの間隔をHelloパケットに送るのが隣人の状態のそばで決定しているとき。 州のDownで隣人がそうなら、あらゆるPollIntervalをHello Packetsに送ります。秒。 さもなければ、あらゆるHelloIntervalをHello Packetsに送ります。秒。
10. The Neighbor Data Structure
10. 隣人データ構造
An OSPF router converses with its neighboring routers. Each separate conversation is described by a "neighbor data structure". Each conversation is bound to a particular OSPF router interface, and is identified either by the neighboring router's OSPF Router ID or by its Neighbor IP address (see below). Thus if the OSPF router and another router have multiple attached networks in common, multiple conversations ensue, each described by a unique neighbor data structure. Each separate conversation is loosely referred to in the text as being a separate "neighbor".
OSPFルータは隣接しているルータと話します。 それぞれの別々の会話は「隣人データ構造」によって説明されます。 各会話は、特定のOSPFルータインタフェースに縛られて、隣接しているルータのOSPF Router IDかそのNeighbor IPアドレスによって特定されます(以下を見てください)。 したがって、OSPFルータと別のルータが一般的な倍数の会話で複数の付属ネットワークを持っているなら、続いてください、とそれぞれがユニークな隣人データ構造で説明しました。 それぞれの別々の会話はテキストに緩く別々の「隣人」であると呼ばれます。
The neighbor data structure contains all information pertinent to the forming or formed adjacency between the two neighbors. (However, remember that not all neighbors become adjacent.) An adjacency can be viewed as a highly developed conversation between two routers.
隣人データ構造は、形成に適切なすべての情報を含んだか、または2人の隣人の間で隣接番組を形成しました。 (しかしながら、すべての隣人が隣接するようになるというわけではないのを覚えていてください。) 2つのルータでの高度な会話として隣接番組を見なすことができます。
State
The functional level of the neighbor conversation. This is
described in more detail in Section 10.1.
隣人の会話の機能的なレベルを述べてください。 これはさらに詳細にセクション10.1で説明されます。
Inactivity Timer
A single shot timer whose firing indicates that no Hello Packet
has been seen from this neighbor recently. The length of the
timer is RouterDeadInterval seconds.
不活発Timer Aは発火が、Hello Packetが全く最近この隣人から見られていないのを示すショットタイマを選抜します。 タイマの長さはRouterDeadInterval秒です。
Master/Slave
When the two neighbors are exchanging databases, they form a
master/slave relationship. The master sends the first Database
Description Packet, and is the only part that is allowed to
retransmit. The slave can only respond to the master's Database
Description Packets. The master/slave relationship is negotiated
in state ExStart.
2人の隣人のマスター/奴隷Whenはデータベースを交換していて、それらはマスター/奴隷関係を形成します。 マスターは、最初のDatabase記述Packetを送って、再送できる唯一の部分です。 奴隷はマスターのDatabase記述Packetsに応じることができるだけです。 マスター/奴隷関係は州のExStartで交渉されます。
Moy Standards Track [Page 68] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[68ページ]RFC2178OSPFバージョン1997年7月2日
DD Sequence Number
The DD Sequence number of the Database Description packet that is
currently being sent to the neighbor.
DD Sequence Number、現在隣人に送られるDatabase記述パケットのDD Sequence番号。
Last received Database Description packet
The initialize(I), more (M) and master(MS) bits, Options field,
and DD sequence number contained in the last Database Description
packet received from the neighbor. Used to determine whether the
next Database Description packet received from the neighbor is a
duplicate.
最後の容認されたDatabase記述パケット、一連番号が隣人から受け取られた最後のDatabase記述パケットに含んだマスター(MS)の(I)、より多くの(M)、ビット、Options分野、およびDDを初期化してください。 次のDatabase記述パケットが隣人から受信されたかどうか決定するのに使用されているのは、写しです。
Neighbor ID
The OSPF Router ID of the neighboring router. The Neighbor ID is
learned when Hello packets are received from the neighbor, or is
configured if this is a virtual adjacency (see Section C.4).
隣接しているルータの隣人ID OSPF Router ID。 Neighbor IDは、隣人からHelloパケットを受け取るとき、学術的であるか、またはこれが仮想の隣接番組(セクションC.4を見る)であるなら構成されます。
Neighbor Priority
The Router Priority of the neighboring router. Contained in the
neighbor's Hello packets, this item is used when selecting the
Designated Router for the attached network.
隣接しているルータの隣人Priority Router Priority。 付属ネットワークのためにDesignated Routerを選択するとき、隣人のHelloパケットに含まれて、この項目は使用されています。
Neighbor IP address
The IP address of the neighboring router's interface to the
attached network. Used as the Destination IP address when
protocol packets are sent as unicasts along this adjacency. Also
used in router-LSAs as the Link ID for the attached network if the
neighboring router is selected to be Designated Router (see
Section 12.4.1). The Neighbor IP address is learned when Hello
packets are received from the neighbor. For virtual links, the
Neighbor IP address is learned during the routing table build
process (see Section 15).
隣人IPは隣接しているルータのインタフェースのIPアドレスを付属ネットワークに扱います。 ユニキャストとしてこの隣接番組に沿ってプロトコルパケットを送るとき、Destination IPアドレスとして、使用します。 また、ルータ-LSAsでは、Link IDとして、付属ネットワークのために、隣接しているルータがDesignated Routerであることが選択されるなら(セクション12.4.1を見てください)、使用されます。 隣人からHelloパケットを受け取るとき、Neighbor IPアドレスは学術的です。 仮想のリンク、アドレスが学習されるNeighbor IPに関しては、経路指定テーブルはプロセスを建てます(セクション15を見てください)。
Neighbor Options
The optional OSPF capabilities supported by the neighbor. Learned
during the Database Exchange process (see Section 10.6). The
neighbor's optional OSPF capabilities are also listed in its Hello
packets. This enables received Hello Packets to be rejected (i.e.,
neighbor relationships will not even start to form) if there is a
mismatch in certain crucial OSPF capabilities (see Section 10.5).
The optional OSPF capabilities are documented in Section 4.5.
任意のOSPF能力が隣人でサポートした隣人Options。 Database Exchangeプロセス(セクション10.6を見る)の間、学術的です。 また、隣人の任意のOSPF能力はHelloパケットに記載されています。 ある重要なOSPF能力にミスマッチがあれば(セクション10.5を見てください)、これは、容認されたHello Packetsが拒絶されるのを(すなわち、隣人関係は形成し始めてさえいないでしょう)可能にします。 任意のOSPF能力はセクション4.5に記録されます。
Neighbor's Designated Router
The neighbor's idea of the Designated Router. If this is the
neighbor itself, this is important in the local calculation of the
Designated Router. Defined only on broadcast and NBMA networks.
隣人の隣人のDesignated RouterのDesignated Routerの考え。 隣人自身であるなら、これはDesignated Routerのローカルな計算で重要です。 放送とNBMAネットワークだけでは、定義されます。
Moy Standards Track [Page 69] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[69ページ]RFC2178OSPFバージョン1997年7月2日
Neighbor's Backup Designated Router
The neighbor's idea of the Backup Designated Router. If this is
the neighbor itself, this is important in the local calculation of
the Backup Designated Router. Defined only on broadcast and NBMA
networks.
隣人の隣人のBackup Designated RouterのBackup Designated Routerの考え。 隣人自身であるなら、これはBackup Designated Routerのローカルな計算で重要です。 放送とNBMAネットワークだけでは、定義されます。
The next set of variables are lists of LSAs. These lists describe subsets of the area link-state database. This memo defines five distinct types of LSAs, all of which may be present in an area link- state database: router-LSAs, network-LSAs, and Type 3 and 4 summary- LSAs (all stored in the area data structure), and AS- external-LSAs (stored in the global data structure).
変数の次のセットはLSAsのリストです。 これらのリストは領域リンク州のデータベースの部分集合について説明します。 このメモはLSAsの5つの異なったタイプを定義します:そのすべては領域リンクに州のデータベースを提示することであるかもしれません。 ルータ-LSAs、ネットワーク-LSAs、およびType3と4概要LSAs(領域データ構造で保存されたすべて)、およびASの外部のLSAs(グローバルなデータ構造では、保存されます)。
Link state retransmission list
The list of LSAs that have been flooded but not acknowledged on
this adjacency. These will be retransmitted at intervals until
they are acknowledged, or until the adjacency is destroyed.
リンク州の「再-トランスミッション」はあふれますが、この隣接番組で承認されていないLSAsのリストをリストアップします。 それらが承認されるまでの間隔、または隣接番組が破壊されるまで、これらは再送されるでしょう。
Database summary list
The complete list of LSAs that make up the area link-state
database, at the moment the neighbor goes into Database Exchange
state. This list is sent to the neighbor in Database Description
packets.
データベース概要は領域リンク州のデータベースを作るLSAsに関する全リストをリストアップします、現在、隣人がDatabase Exchange状態に入ります。 Database記述パケットの隣人にこのリストを送ります。
Link state request list
The list of LSAs that need to be received from this neighbor in
order to synchronize the two neighbors' link-state databases.
This list is created as Database Description packets are received,
and is then sent to the neighbor in Link State Request packets.
The list is depleted as appropriate Link State Update packets are
received.
リンク州は、2人の隣人のリンク州のデータベースを同期させるようにこの隣人から受け取られる必要があるLSAsのリストをリストアップするよう要求します。 このリストは、Database記述パケットが受け取られているので作成されて、Link州Requestパケットの隣人に送って、その時です。 適切なLink州Updateパケットが受け取られているとき、リストを使い果たします。
10.1. Neighbor states
10.1. 隣人州
The state of a neighbor (really, the state of a conversation being held with a neighboring router) is documented in the following sections. The states are listed in order of progressing functionality. For example, the inoperative state is listed first, followed by a list of intermediate states before the final, fully functional state is achieved. The specification makes use of this ordering by sometimes making references such as "those neighbors/adjacencies in state greater than X". Figures 12 and 13 show the graph of neighbor state changes. The arcs of the graphs are labelled with the event causing the state change. The neighbor events are documented in Section 10.2.
隣人(本当に隣接しているルータで保持される会話の状態)の状態は以下のセクションで記録されます。 機能性を進行することの順に州は記載されています。 例えば、操業していない状態は最終的で、完全に機能的な状態が獲得される前に中間的州のリストがいうことになった記載された1番目です。 仕様は、時々「Xより大きい状態のそれらの隣人/隣接番組」などの参照をすることによって、この注文を利用します。 数字12と13は隣人州の変化のグラフを示しています。 グラフのアークは州の変化を引き起こす出来事でラベルされます。 隣人出来事はセクション10.2に記録されます。
Moy Standards Track [Page 70] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[70ページ]RFC2178OSPFバージョン1997年7月2日
The graph in Figure 12 shows the state changes effected by the Hello Protocol. The Hello Protocol is responsible for neighbor acquisition and maintenance, and for ensuring two way communication between neighbors.
図12のグラフはHelloプロトコルで作用する州の変化を示しています。 Helloプロトコルは隣人獲得と維持と、隣人の間の双方向通信を確実にするのに原因となります。
The graph in Figure 13 shows the forming of an adjacency. Not every two neighboring routers become adjacent (see Section 10.4). The adjacency starts to form when the neighbor is in state ExStart. After the two routers discover their master/slave status, the state transitions to Exchange. At this point the neighbor starts to be used in the flooding procedure, and the two neighboring routers begin synchronizing their databases. When this synchronization is finished, the neighbor is in state Full and we say that the two routers are fully adjacent. At this point the adjacency is listed in LSAs.
図13のグラフは隣接番組の形成を示しています。 2つの隣接しているルータ毎は隣接するようになりません(セクション10.4を見てください)。 隣人が州のExStartにいるとき、隣接番組は形成し始めます。 2つのルータがそれらのマスター/奴隷状態を発見した後に、状態はExchangeに移行します。 ここに、氾濫手順で隣人は使用され始めます、そして、2つの隣接しているルータがそれらのデータベースを同期させ始めます。 この同期が終わっているとき、隣人は州のFullにいます、そして、私たちは2つのルータに完全に隣接していると言います。 ここに、隣接番組はLSAsに記載されます。
For a more detailed description of neighbor state changes, together with the additional actions involved in each change, see Section 10.3.
隣人州の変化の、より詳細な記述に関しては、各変化にかかわる追加動作と共にセクション10.3を見てください。
Down
This is the initial state of a neighbor conversation. It
indicates that there has been no recent information received from
the neighbor. On NBMA networks, Hello packets may still be sent to
"Down" neighbors, although at a reduced frequency (see Section
9.5.1).
下にThisは隣人の会話の初期状態です。 それは、隣人から受け取られた最近の情報が全くなかったのを示します。 NBMAネットワークでは、換算周波数で送りますが、まだHelloパケットを“Down"隣人に送るかもしれません(セクション9.5.1を見てください)。
Moy Standards Track [Page 71] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[71ページ]RFC2178OSPFバージョン1997年7月2日
+----+
|Down|
+----+
|\
| \Start
| \ +-------+
Hello | +---->|Attempt|
Received | +-------+
| |
+----+<-+ |HelloReceived
|Init|<---------------+
+----+<--------+
| |
|2-Way |1-Way
|Received |Received
| |
+-------+ | +-----+
|ExStart|<--------+------->|2-Way|
+-------+ +-----+
+----+ |下に| +----+ |\ | \始め| \ +-------+ こんにちは| +---->|試み| 受信します。| +-------+ | | +----+ <-+|HelloReceived|イニット| <、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ +----+ <。--------+ | | |2ウェイ|1ウェイ|受信します。|受信します。| | +-------+ | +-----+ |ExStart| <、-、-、-、-、-、-、--+------->|2ウェイ| +-------+ +-----+
Figure 12: Neighbor state changes (Hello Protocol)
図12: 隣人州の変化(こんにちは、プロトコル)
In addition to the state transitions pictured,
Event KillNbr always forces Down State,
Event Inactivity Timer always forces Down State,
Event LLDown always forces Down State
変遷が描写した状態に加えて、Event KillNbrはいつもDown州を強制して、Event Inactivity TimerはいつもDown州を強制して、Event LLDownはいつもDown州を強制します。
Moy Standards Track [Page 72] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[72ページ]RFC2178OSPFバージョン1997年7月2日
+-------+
|ExStart|
+-------+
|
NegotiationDone|
+->+--------+
|Exchange|
+--+--------+
|
Exchange|
Done |
+----+ | +-------+
|Full|<---------+----->|Loading|
+----+<-+ +-------+
| LoadingDone |
+------------------+
+-------+ |ExStart| +-------+ | NegotiationDone| +>+--------+ |交換| +--+--------+ | 交換| します。| +----+ | +-------+ |完全| <、-、-、-、-、-、-、-、--+----->|ローディング| +----+ <++-------+ | LoadingDone| +------------------+
Figure 13: Neighbor state changes (Database Exchange)
図13: 隣人州の変化(データベース交換)
In addition to the state transitions pictured,
Event SeqNumberMismatch forces ExStart state,
Event BadLSReq forces ExStart state,
Event 1-Way forces Init state,
Event KillNbr always forces Down State,
Event InactivityTimer always forces Down State,
Event LLDown always forces Down State,
Event AdjOK? leads to adjacency forming/breaking
ExStartが述べるEvent SeqNumberMismatch力、ExStartが述べるEvent BadLSReq力、Initが述べるEventの1方法の力、Event KillNbrはいつもDown州を強制して、Event InactivityTimerはいつもDown州を強制して、Event LLDownはいつもDown州を強制します、Event AdjOK--変遷が描写した状態に加えて、隣接番組の形成/壊すのに通じます。
Moy Standards Track [Page 73] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[73ページ]RFC2178OSPFバージョン1997年7月2日
Attempt
This state is only valid for neighbors attached to NBMA networks.
It indicates that no recent information has been received from the
neighbor, but that a more concerted effort should be made to
contact the neighbor. This is done by sending the neighbor Hello
packets at intervals of HelloInterval (see Section 9.5.1).
NBMAネットワークに配属される隣人だけに、試みThis状態は有効です。 それは、隣人から最近の情報を全く受け取っていませんが、隣人に連絡するのをより協定している努力をするべきであるのを示します。 HelloIntervalごとに隣人Helloパケットを送ることによって、これをします(セクション9.5.1を見てください)。
Init
In this state, an Hello packet has recently been seen from the
neighbor. However, bidirectional communication has not yet been
established with the neighbor (i.e., the router itself did not
appear in the neighbor's Hello packet). All neighbors in this
state (or higher) are listed in the Hello packets sent from the
associated interface.
イニットIn、この状態であり、Helloパケットは最近、隣人から見られました。 しかしながら、双方向のコミュニケーションは隣人と共にまだ確立されていません(すなわち、ルータ自体は隣人のHelloパケットに現れませんでした)。 この状態(より高い)のすべての隣人が関連インタフェースから送られたHelloパケットに記載されています。
2-Way
In this state, communication between the two routers is
bidirectional. This has been assured by the operation of the
Hello Protocol. This is the most advanced state short of
beginning adjacency establishment. The (Backup) Designated Router
is selected from the set of neighbors in state 2-Way or greater.
2方法のIn、この状態であり、2つのルータのコミュニケーションは双方向です。 これはHelloプロトコルの操作で保証されました。 これによる大部分が隣接番組設立を始めるのに不足していた状態で状態を進めたということです。 Routerに指定された(バックアップ)は、隣人のセットから2州の方法で選択されているか、または、よりすばらしいです。
ExStart
This is the first step in creating an adjacency between the two
neighboring routers. The goal of this step is to decide which
router is the master, and to decide upon the initial DD sequence
number. Neighbor conversations in this state or greater are
called adjacencies.
ExStart Thisは2つの隣接しているルータの間で隣接番組を作成することにおいて第一歩です。 このステップの目標は、どのルータがマスターであるかを決めて、初期のDD一連番号について決めることです。 この状態か、よりすばらしいところの隣人の会話は隣接番組と呼ばれます。
Exchange
In this state the router is describing its entire link state
database by sending Database Description packets to the neighbor.
Each Database Description Packet has a DD sequence number, and is
explicitly acknowledged. Only one Database Description Packet is
allowed outstanding at any one time. In this state, Link State
Request Packets may also be sent asking for the neighbor's more
recent LSAs. All adjacencies in Exchange state or greater are
used by the flooding procedure. In fact, these adjacencies are
fully capable of transmitting and receiving all types of OSPF
routing protocol packets.
Inを交換してください。ルータが隣人への記述パケットをDatabaseに送りながら全体のリンク州のデータベースについて説明しているこの状態。 それぞれのDatabase記述PacketはDD一連番号を持って、明らかに承認されます。 1Database記述Packetだけがいかなる時も、傑出していた状態で許容されています。 また、この状態では、Link州Request Packetsに隣人の、より最近のLSAsを求めさせるかもしれません。 Exchange状態か、よりすばらしいところのすべての隣接番組が氾濫手順で使用されます。 事実上、すべてのタイプのOSPFルーティング・プロトコルパケットを送信して、これらの隣接番組は完全に受けることができます。
Loading
In this state, Link State Request packets are sent to the neighbor
asking for the more recent LSAs that have been discovered (but not
yet received) in the Exchange state.
Exchange状態で発見された(しかし、まだ、受信していません)より最近のLSAsを求める隣人にInを積み込むこれが述べるLink州Requestパケットを送ります。
Moy Standards Track [Page 74] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[74ページ]RFC2178OSPFバージョン1997年7月2日
Full
In this state, the neighboring routers are fully adjacent. These
adjacencies will now appear in router-LSAs and network-LSAs.
Inを洗い張りしてください。この状態、隣接しているルータは完全に隣接しています。 これらの隣接番組は今、ルータ-LSAsとネットワーク-LSAsに現れるでしょう。
10.2. Events causing neighbor state changes
10.2. 隣人状態に変化を引き起こす出来事
State changes can be effected by a number of events. These events are shown in the labels of the arcs in Figures 12 and 13. The label definitions are as follows:
州の変化は多くの出来事で作用できます。 これらの出来事は図12と13のアークのラベルに示されます。 ラベル定義は以下の通りです:
HelloReceived
An Hello packet has been received from the neighbor.
隣人からHelloReceived An Helloパケットを受け取りました。
Start
This is an indication that Hello Packets should now be sent to the
neighbor at intervals of HelloInterval seconds. This event is
generated only for neighbors associated with NBMA networks.
スタートThisは現在HelloInterval秒ごとにHello Packetsを隣人に送るべきであるという指示です。 この出来事はNBMAネットワークに関連している隣人のためだけに発生します。
2-WayReceived
Bidirectional communication has been realized between the two
neighboring routers. This is indicated by the router seeing
itself in the neighbor's Hello packet.
2-WayReceived Bidirectionalコミュニケーションは2つの隣接しているルータの間に実現されました。 これは隣人のHelloパケットでルータの見自体で示されます。
NegotiationDone
The Master/Slave relationship has been negotiated, and DD sequence
numbers have been exchanged. This signals the start of the
sending/receiving of Database Description packets. For more
information on the generation of this event, consult Section 10.8.
Master/奴隷のNegotiationDone関係を交渉しました、そして、DD一連番号を交換しました。 これはDatabase記述パケットの発信/受信の始まりに合図します。 この出来事の世代の詳しい情報に関しては、セクション10.8に相談してください。
ExchangeDone
Both routers have successfully transmitted a full sequence of
Database Description packets. Each router now knows what parts of
its link state database are out of date. For more information on
the generation of this event, consult Section 10.8.
ExchangeDone Bothルータは首尾よくDatabase記述パケットの完全な系列を伝えました。 各ルータは、今、リンク州のデータベースのどんな部分が時代遅れであるかを知っています。 この出来事の世代の詳しい情報に関しては、セクション10.8に相談してください。
BadLSReq
A Link State Request has been received for an LSA not contained in
the database. This indicates an error in the Database Exchange
process.
データベースに含まれなかったLSAのためにBadLSReq A Link州Requestを受け取りました。 これはDatabase Exchangeの過程における誤りを示します。
Loading Done
Link State Updates have been received for all out-of-date portions
of the database. This is indicated by the Link state request list
becoming empty after the Database Exchange process has completed.
ローディングDone Link州Updatesは日付のすべて外のためのデータベースの容認された部分です。 これは過程が完成したDatabase Exchangeの後に空になるLink州の要求リストによって示されます。
Moy Standards Track [Page 75] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[75ページ]RFC2178OSPFバージョン1997年7月2日
AdjOK?
A decision must be made as to whether an adjacency should be
established/maintained with the neighbor. This event will start
some adjacencies forming, and destroy others.
AdjOK? 隣接番組が隣人と共に確立されるべきであるか、または維持されるべきであるかどうかに関して決定をしなければなりません。 この出来事は、いくつかの隣接番組が形成され始めて、他のものを滅ぼすでしょう。
The following events cause well developed neighbors to revert to lesser states. Unlike the above events, these events may occur when the neighbor conversation is in any of a number of states.
以下のイベント原因は、より少ない州に戻るために隣人をよく開発しました。 隣人の会話が多くの州のどれかにあるとき、上の出来事と異なって、これらの出来事は起こるかもしれません。
SeqNumberMismatch
A Database Description packet has been received that either a) has
an unexpected DD sequence number, b) unexpectedly has the Init bit
set or c) has an Options field differing from the last Options
field received in a Database Description packet. Any of these
conditions indicate that some error has occurred during adjacency
establishment.
SeqNumberMismatch A Database記述パケットによる受け取そんなにのどちらかであって、a)には予期していなかったDD一連番号があるか、b)がInitビットを不意に設定させるか、またはc)にDatabase記述パケットに受け取られた最後のOptions野原と異なっているOptions分野があるということでした。 これらの状態のいずれも、何らかの誤りが隣接番組設立の間発生しているのを示します。
1-Way
An Hello packet has been received from the neighbor, in which the
router is not mentioned. This indicates that communication with
the neighbor is not bidirectional.
隣人から1方法のAn Helloパケットを受け取りました。そこでは、ルータが言及されません。 これは、隣人とのコミュニケーションが双方向でないことを示します。
KillNbr
This is an indication that all communication with the neighbor is
now impossible, forcing the neighbor to revert to Down state.
KillNbr Thisは隣人とのすべてのコミュニケーションが現在不可能であるという指示です、隣人にDown状態に先祖帰りをさせて。
InactivityTimer
The inactivity Timer has fired. This means that no Hello packets
have been seen recently from the neighbor. The neighbor reverts to
Down state.
InactivityTimer不活発Timerは発火しました。 これは、Helloパケットが全く最近隣人から見られていないことを意味します。 隣人はDown状態に先祖帰りをします。
LLDown
This is an indication from the lower level protocols that the
neighbor is now unreachable. For example, on an X.25 network this
could be indicated by an X.25 clear indication with appropriate
cause and diagnostic fields. This event forces the neighbor into
Down state.
LLDown Thisは下のレベルプロトコルからの隣人が現在手が届かないという指示です。 例えば、X.25ネットワークでは、適切な原因と診断分野でX.25の明確な指示でこれを示すことができるでしょう。 この出来事はDown状態に隣人を力づくで押します。
10.3. The Neighbor state machine
10.3. Neighbor州のマシン
A detailed description of the neighbor state changes follows. Each state change is invoked by an event (Section 10.2). This event may produce different effects, depending on the current state of the neighbor. For this reason, the state machine below is organized by current neighbor state and received event. Each entry in the state machine describes the resulting new neighbor state and the required set of additional actions.
隣人州の変化の詳述は続きます。 出来事(セクション10.2)によってそれぞれの州の変化は呼び出されます。 隣人の現状のときによって、この出来事は異なった効果を生むかもしれません。 この理由で、以下の州のマシンは現在の隣人国と容認された出来事によって組織化されます。 州のマシンの各エントリーは結果として起こる新しい隣人州と必要なセットの追加機能について説明します。
Moy Standards Track [Page 76] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[76ページ]RFC2178OSPFバージョン1997年7月2日
When a neighbor's state changes, it may be necessary to rerun the Designated Router election algorithm. This is determined by whether the interface NeighborChange event is generated (see Section 9.2). Also, if the Interface is in DR state (the router is itself Designated Router), changes in neighbor state may cause a new network-LSA to be originated (see Section 12.4).
隣人の状態が変化するとき、Designated Router選挙アルゴリズムを再放送するのが必要であるかもしれません。 インタフェースNeighborChange出来事が発生するかどうかによって(セクション9.2を見てください)これは決定します。 また、InterfaceがDR状態にあるなら(ルータはそれ自体でDesignated Routerです)、隣人状態の変化で、新しいネットワーク-LSAを溯源するかもしれません(セクション12.4を見てください)。
When the neighbor state machine needs to invoke the interface state machine, it should be done as a scheduled task (see Section 4.4). This simplifies things, by ensuring that neither state machine will be executed recursively.
隣人州のマシンが、界面準位マシンを呼び出す必要があると、予定されているタスクとしてそれをするべきです(セクション4.4を見てください)。 どちらの州のマシンも再帰的に実行されないのを確実にすることによって、これはものを簡素化します。
State(s): Down
州: 下に
Event: Start
出来事: 始め
New state: Attempt
新しい州: 試み
Action: Send an Hello Packet to the neighbor (this neighbor
is always associated with an NBMA network) and start
the Inactivity Timer for the neighbor. The timer's
later firing would indicate that communication with
the neighbor was not attained.
動作: Hello Packetを隣人に送ってください、そして、(この隣人はいつもNBMAネットワークに関連しています)隣人のためにInactivity Timerを始動してください。 タイマの後の発火は、隣人とのコミュニケーションに達しなかったのを示すでしょう。
State(s): Attempt
州: 試み
Event: HelloReceived
出来事: HelloReceived
New state: Init
新しい州: イニット
Action: Restart the Inactivity Timer for the neighbor, since
the neighbor has now been heard from.
動作: 今隣人から聞かれたので、隣人のためにInactivity Timerを再開してください。
State(s): Down
州: 下に
Event: HelloReceived
出来事: HelloReceived
New state: Init
新しい州: イニット
Action: Start the Inactivity Timer for the neighbor. The
timer's later firing would indicate that the neighbor
is dead.
動作: 隣人のためにInactivity Timerを始動してください。 タイマの後の発火は、隣人が死んでいるのを示すでしょう。
Moy Standards Track [Page 77] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[77ページ]RFC2178OSPFバージョン1997年7月2日
State(s): Init or greater
州: イニットか、よりすばらしいです。
Event: HelloReceived
出来事: HelloReceived
New state: No state change.
新しい州: 州の変化がありません。
Action: Restart the Inactivity Timer for the neighbor, since
the neighbor has again been heard from.
動作: 再び隣人から聞かれたので、隣人のためにInactivity Timerを再開してください。
State(s): Init
州: イニット
Event: 2-WayReceived
出来事: 2-WayReceived
New state: Depends upon action routine.
新しい州: アクションルーチンによります。
Action: Determine whether an adjacency should be established
with the neighbor (see Section 10.4). If not, the
new neighbor state is 2-Way.
動作: 隣接番組が隣人と共に確立されるべきであるかどうか(セクション10.4を見てください)決定してください。 まして、新しい隣人状態は2方法です。
Otherwise (an adjacency should be established) the
neighbor state transitions to ExStart. Upon
entering this state, the router increments the DD
sequence number in the neighbor data structure. If
this is the first time that an adjacency has been
attempted, the DD sequence number should be assigned
some unique value (like the time of day clock). It
then declares itself master (sets the master/slave
bit to master), and starts sending Database
Description Packets, with the initialize (I), more
(M) and master (MS) bits set. This Database
Description Packet should be otherwise empty. This
Database Description Packet should be retransmitted
at intervals of RxmtInterval until the next state is
entered (see Section 10.8).
さもなければ(隣接番組は確立されるべきである)、隣人はExStartへの変遷を述べます。 この状態に入ると、ルータは隣人データ構造におけるDD一連番号を増加します。 これが隣接番組を試みてある1回目であるなら、何らかのユニークな値(時刻時計のような)がDD一連番号に割り当てられるべきです。 次に、マスター(マスター/奴隷ビットをマスターに設定する)であるとそれ自体で宣言して、Database記述Packetsを送り始める、(I)、より多くの(M)、およびビットが設定するマスター(MS)を初期化してください。 そうでなければ、このDatabase記述Packetは空であるべきです。 次の状態が入られるまで(セクション10.8を見てください)、このDatabase記述PacketはRxmtIntervalごとに再送されるべきです。
State(s): ExStart
州: ExStart
Event: NegotiationDone
出来事: NegotiationDone
New state: Exchange
新しい州: 交換
Action: The router must list the contents of its entire area
link state database in the neighbor Database summary
list. The area link state database consists of the
router-LSAs, network-LSAs and summary-LSAs contained
in the area structure, along with the AS-external-
動作: ルータは隣人Database概要リストの全体の領域リンク州のデータベースのコンテンツを記載しなければなりません。 領域リンク州のデータベースは領域構造に含まれたルータ-LSAs、ネットワーク-LSAs、および概要-LSAsから成ります、AS-外部と共に-
Moy Standards Track [Page 78] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[78ページ]RFC2178OSPFバージョン1997年7月2日
LSAs contained in the global structure. AS-
external-LSAs are omitted from a virtual neighbor's
Database summary list. AS-external-LSAs are omitted
from the Database summary list if the area has been
configured as a stub (see Section 3.6). LSAs whose
age is equal to MaxAge are instead added to the
neighbor's Link state retransmission list. A
summary of the Database summary list will be sent to
the neighbor in Database Description packets. Each
Database Description Packet has a DD sequence
number, and is explicitly acknowledged. Only one
Database Description Packet is allowed outstanding
at any one time. For more detail on the sending and
receiving of Database Description packets, see
Sections 10.8 and 10.6.
グローバル構造に含まれたLSAs。 ASの外部のLSAsは仮想の隣人のDatabase概要リストから省略されます。 領域がスタッブとして構成されたなら(セクション3.6を見てください)、ASの外部のLSAsはDatabase概要リストから省略されます。 年令がMaxAgeと等しいLSAsは代わりに隣人のLink州の「再-トランスミッション」リストに追加されます。 Database概要リストの概要をDatabase記述パケットの隣人に送るでしょう。 それぞれのDatabase記述PacketはDD一連番号を持って、明らかに承認されます。 1Database記述Packetだけがいかなる時も、傑出していた状態で許容されています。 Database記述パケットの送受信に関するその他の詳細に関しては、セクション10.8と10.6を見てください。
State(s): Exchange
州: 交換
Event: ExchangeDone
出来事: ExchangeDone
New state: Depends upon action routine.
新しい州: アクションルーチンによります。
Action: If the neighbor Link state request list is empty,
the new neighbor state is Full. No other action is
required. This is an adjacency's final state.
動作: 隣人Link州の要求リストが空であるなら、新しい隣人状態はFullです。 他の動作は全く必要ではありません。 これは隣接番組の最終的な状態です。
Otherwise, the new neighbor state is Loading. Start
(or continue) sending Link State Request packets to
the neighbor (see Section 10.9). These are requests
for the neighbor's more recent LSAs (which were
discovered but not yet received in the Exchange
state). These LSAs are listed in the Link state
request list associated with the neighbor.
さもなければ、新しい隣人状態はLoadingです。 隣人への州RequestパケットをLinkに送り始めてください(続いてください)(セクション10.9を見てください)。 隣人の、より最近のLSAsを求めてこれらは要求(どれが発見されましたが、まだ発見されたというわけではないかはExchange状態で受信された)です。 これらのLSAsは隣人に関連しているLink州の要求リストに記載されています。
State(s): Loading
州: ローディング
Event: Loading Done
出来事: 行われたローディング
New state: Full
新しい州: 完全
Action: No action required. This is an adjacency's final
state.
動作: どんな動作も必要ではありません。 これは隣接番組の最終的な状態です。
Moy Standards Track [Page 79] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[79ページ]RFC2178OSPFバージョン1997年7月2日
State(s): 2-Way
州: 2ウェイ
Event: AdjOK?
出来事: AdjOK?
New state: Depends upon action routine.
新しい州: アクションルーチンによります。
Action: Determine whether an adjacency should be formed with
the neighboring router (see Section 10.4). If not,
the neighbor state remains at 2-Way. Otherwise,
transition the neighbor state to ExStart and perform
the actions associated with the above state machine
entry for state Init and event 2-WayReceived.
動作: 隣接番組が隣接しているルータで形成されるべきであるかどうか(セクション10.4を見てください)決定してください。 そうでなければ、隣人州は2方法に残ります。 さもなければ、隣人がExStartに述べて、上の州のマシンエントリーに関連している動作を実行する変遷はInitとイベント2-WayReceivedを述べます。
State(s): ExStart or greater
州: ExStartか、よりすばらしいです。
Event: AdjOK?
出来事: AdjOK?
New state: Depends upon action routine.
新しい州: アクションルーチンによります。
Action: Determine whether the neighboring router should
still be adjacent. If yes, there is no state change
and no further action is necessary.
動作: 隣接しているルータがまだ隣接しているべきであるかどうか決定してください。 はい、州の変化が全くなくて、またさらなるどんな動作も必要でないなら。
Otherwise, the (possibly partially formed) adjacency
must be destroyed. The neighbor state transitions
to 2-Way. The Link state retransmission list,
Database summary list and Link state request list
are cleared of LSAs.
さもなければ、(ことによると部分的に形成されています)の隣接番組を破壊しなければなりません。 隣人は2方法への変遷を述べます。 Link州の「再-トランスミッション」リスト、Database概要リスト、およびLink州の要求リストはLSAsをきれいにされます。
State(s): Exchange or greater
州: 交換か、よりすばらしいです。
Event: SeqNumberMismatch
出来事: SeqNumberMismatch
New state: ExStart
新しい州: ExStart
Action: The (possibly partially formed) adjacency is torn
down, and then an attempt is made at
reestablishment. The neighbor state first
transitions to ExStart. The Link state
retransmission list, Database summary list and Link
state request list are cleared of LSAs. Then the
router increments the DD sequence number in the
neighbor data structure, declares itself master
(sets the master/slave bit to master), and starts
sending Database Description Packets, with the
initialize (I), more (M) and master (MS) bits set.
動作: (ことによると部分的に形成されています)の隣接番組を取りこわします、そして、次に、再建で試みをします。 隣人は前縁をExStartに述べます。 Link州の「再-トランスミッション」リスト、Database概要リスト、およびLink州の要求リストはLSAsをきれいにされます。 次に、ルータが隣人データ構造におけるDD一連番号を増加して、それ自体がマスター(マスター/奴隷ビットをマスターに設定する)であると宣言して、Database記述Packetsを送り始める、(I)、より多くの(M)、およびビットが設定するマスター(MS)を初期化してください。
Moy Standards Track [Page 80] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[80ページ]RFC2178OSPFバージョン1997年7月2日
This Database Description Packet should be otherwise
empty (see Section 10.8).
そうでなければ、このDatabase記述Packetは空であるべきです(セクション10.8を見てください)。
State(s): Exchange or greater
州: 交換か、よりすばらしいです。
Event: BadLSReq
出来事: BadLSReq
New state: ExStart
新しい州: ExStart
Action: The action for event BadLSReq is exactly the same as
for the neighbor event SeqNumberMismatch. The
(possibly partially formed) adjacency is torn down,
and then an attempt is made at reestablishment. For
more information, see the neighbor state machine
entry that is invoked when event SeqNumberMismatch
is generated in state Exchange or greater.
動作: イベントBadLSReqのための動きはまさに隣人イベントSeqNumberMismatchのように同じです。 (ことによると部分的に形成されています)の隣接番組を取りこわします、そして、次に、再建で試みをします。 詳しくは、イベントSeqNumberMismatchが州のExchangeで発生しているか、または、よりすばらしいときに呼び出される隣人州のマシンエントリーを見てください。
State(s): Any state
州: どんな状態
Event: KillNbr
出来事: KillNbr
New state: Down
新しい州: 下に
Action: The Link state retransmission list, Database summary
list and Link state request list are cleared of
LSAs. Also, the Inactivity Timer is disabled.
動作: Link州の「再-トランスミッション」リスト、Database概要リスト、およびLink州の要求リストはLSAsをきれいにされます。 また、Inactivity Timerも障害があります。
State(s): Any state
州: どんな状態
Event: LLDown
出来事: LLDown
New state: Down
新しい州: 下に
Action: The Link state retransmission list, Database summary
list and Link state request list are cleared of
LSAs. Also, the Inactivity Timer is disabled.
動作: Link州の「再-トランスミッション」リスト、Database概要リスト、およびLink州の要求リストはLSAsをきれいにされます。 また、Inactivity Timerも障害があります。
Moy Standards Track [Page 81] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[81ページ]RFC2178OSPFバージョン1997年7月2日
State(s): Any state
州: どんな状態
Event: InactivityTimer
出来事: InactivityTimer
New state: Down
新しい州: 下に
Action: The Link state retransmission list, Database summary
list and Link state request list are cleared of
LSAs.
動作: Link州の「再-トランスミッション」リスト、Database概要リスト、およびLink州の要求リストはLSAsをきれいにされます。
State(s): 2-Way or greater
州: 2方法か、よりすばらしいです。
Event: 1-WayReceived
出来事: 1-WayReceived
New state: Init
新しい州: イニット
Action: The Link state retransmission list, Database summary
list and Link state request list are cleared of
LSAs.
動作: Link州の「再-トランスミッション」リスト、Database概要リスト、およびLink州の要求リストはLSAsをきれいにされます。
State(s): 2-Way or greater
州: 2方法か、よりすばらしいです。
Event: 2-WayReceived
出来事: 2-WayReceived
New state: No state change.
新しい州: 州の変化がありません。
Action: No action required.
動作: どんな動作も必要ではありません。
State(s): Init
州: イニット
Event: 1-WayReceived
出来事: 1-WayReceived
New state: No state change.
新しい州: 州の変化がありません。
Action: No action required.
動作: どんな動作も必要ではありません。
10.4. Whether to become adjacent
10.4. 隣接するようになるのであるかどうか。
Adjacencies are established with some subset of the router's neighbors. Routers connected by point-to-point networks, Point-to- MultiPoint networks and virtual links always become adjacent. On broadcast and NBMA networks, all routers become adjacent to both the Designated Router and the Backup Designated Router.
隣接番組はルータの隣人の何らかの部分集合で確立されます。 二地点間ネットワーク、PointからMultiPointへのネットワーク、および仮想のリンクによって接続されたルータはいつも隣接するようになります。 放送とNBMAネットワークでは、すべてのルータがDesignated RouterとBackup Designated Routerの両方に隣接してなります。
Moy Standards Track [Page 82] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[82ページ]RFC2178OSPFバージョン1997年7月2日
The adjacency-forming decision occurs in two places in the neighbor state machine. First, when bidirectional communication is initially established with the neighbor, and secondly, when the identity of the attached network's (Backup) Designated Router changes. If the decision is made to not attempt an adjacency, the state of the neighbor communication stops at 2-Way.
隣接番組を形成する決定は隣人州のマシンの2つの場所で起こります。 双方向のコミュニケーションであることの1番目は初めは隣人と共に設立されます、そして、第二に、付属ネットワークの(バックアップ)のアイデンティティがいつRouterを指定したかは変化します。 隣接番組を試みないのを決定をするなら、隣人コミュニケーションの状態は2方法で止まります。
An adjacency should be established with a bidirectional neighbor when at least one of the following conditions holds:
少なくとも以下の条件の1つが持ちこたえるとき、隣接番組は双方向の隣人と共に確立されるべきです:
o The underlying network type is point-to-point
o 基本的なネットワークタイプは二地点間です。
o The underlying network type is Point-to-MultiPoint
o 基本的なネットワークタイプは、PointからMultiPointです。
o The underlying network type is virtual link
o 基本的なネットワークタイプは仮想のリンクです。
o The router itself is the Designated Router
o ルータ自体はDesignated Routerです。
o The router itself is the Backup Designated Router
o ルータ自体はBackup Designated Routerです。
o The neighboring router is the Designated Router
o 隣接しているルータはDesignated Routerです。
o The neighboring router is the Backup Designated Router
o 隣接しているルータはBackup Designated Routerです。
10.5. Receiving Hello Packets
10.5. こんにちはを受ける、パケット
This section explains the detailed processing of a received Hello Packet. (See Section A.3.2 for the format of Hello packets.) The generic input processing of OSPF packets will have checked the validity of the IP header and the OSPF packet header. Next, the values of the Network Mask, HelloInterval, and RouterDeadInterval fields in the received Hello packet must be checked against the values configured for the receiving interface. Any mismatch causes processing to stop and the packet to be dropped. In other words, the above fields are really describing the attached network's configuration. However, there is one exception to the above rule: on point-to-point networks and on virtual links, the Network Mask in the received Hello Packet should be ignored.
このセクションは容認されたHello Packetの詳細な処理について説明します。 (Helloパケットの形式に関してセクションA.3.2を見てください。) OSPFパケットの一般的な入力処理はIPヘッダーとOSPFパケットのヘッダーの正当性をチェックしてしまうでしょう。 次に、受信インタフェースに構成された値に対して容認されたHelloパケットのNetwork Mask、HelloInterval、およびRouterDeadInterval分野の値をチェックしなければなりません。 どんなミスマッチも止める処理とパケットを落とされます。 言い換えれば、上の分野は本当に付属ネットワークの構成について説明しています。 しかしながら、上の規則への1つの例外があります: 二地点間ネットワークの上と、そして、仮想のリンクの上では、容認されたHello PacketのNetwork Maskは無視されるべきです。
The receiving interface attaches to a single OSPF area (this could be the backbone). The setting of the E-bit found in the Hello Packet's Options field must match this area's ExternalRoutingCapability. If AS-external-LSAs are not flooded into/throughout the area (i.e, the area is a "stub") the E-bit must be clear in received Hello Packets, otherwise the E-bit must be set. A mismatch causes processing to stop and the packet to be dropped. The setting of the rest of the bits in the Hello Packet's Options field should be ignored.
受信インタフェースはただ一つのOSPF領域に付きます(これは背骨であるかもしれません)。 Hello PacketのOptions野原で発見されるE-ビットの設定はこの領域のExternalRoutingCapabilityに合わなければなりません。 ASの外部のLSAsが領域中に/へあふれないなら(i.e、領域は「スタッブ」です)E-ビットが容認されたHello Packetsで明確であるに違いない、さもなければ、E-ビットを設定しなければなりません。 ミスマッチは止める処理とパケットを落とされます。 Hello PacketのOptions分野のビットの残りの設定は無視されるべきです。
Moy Standards Track [Page 83] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[83ページ]RFC2178OSPFバージョン1997年7月2日
At this point, an attempt is made to match the source of the Hello Packet to one of the receiving interface's neighbors. If the receiving interface connects to a broadcast, Point-to-MultiPoint or NBMA network the source is identified by the IP source address found in the Hello's IP header. If the receiving interface connects to a point-to-point link or a virtual link, the source is identified by the Router ID found in the Hello's OSPF packet header. The interface's current list of neighbors is contained in the interface's data structure. If a matching neighbor structure cannot be found, (i.e., this is the first time the neighbor has been detected), one is created. The initial state of a newly created neighbor is set to Down.
ここに、受信インタフェースの隣人のひとりにHello Packetの源を合わせるのを試みをします。 受信インタフェースが接続するなら、放送、PointからMultiPointまたはNBMAネットワークに、ソースはHelloのIPヘッダーで見つけられたIPソースアドレスによって特定されます。 受信インタフェースがポイントツーポイント接続か仮想のリンクに接続するなら、ソースはHelloのOSPFパケットのヘッダーで見つけられたRouter IDによって特定されます。 インタフェースの隣人の現在のリストはインタフェースのデータ構造に含まれています。 合っている隣人構造を見つけることができないなら(すなわち、これが隣人が検出されたのは、初めてです)、1つは作成されます。 新たに作成された隣人の初期状態はDownに設定されます。
When receiving an Hello Packet from a neighbor on a broadcast, Point-to-MultiPoint or NBMA network, set the neighbor structure's Neighbor ID equal to the Router ID found in the packet's OSPF header. When receiving an Hello on a point-to-point network (but not on a virtual link) set the neighbor structure's Neighbor IP address to the packet's IP source address.
放送、PointからMultiPointまたはNBMAネットワークで隣人からHello Packetを受けるときには、隣人構造のパケットのOSPFヘッダーで見つけられたRouter IDと等しいNeighbor IDを設定してください。 二地点間ネットワーク(しかし、どんな仮想のリンクの上にもそうしない)でHelloを受けるときには、隣人構造のNeighbor IPアドレスをパケットのIPソースアドレスに設定してください。
Now the rest of the Hello Packet is examined, generating events to be given to the neighbor and interface state machines. These state machines are specified either to be executed or scheduled (see Section 4.4). For example, by specifying below that the neighbor state machine be executed in line, several neighbor state transitions may be effected by a single received Hello:
現在、Hello Packetの残りは調べられます、隣人に与えられているイベントと界面準位がマシンであると生成して。 これらの州のマシンは、実行されるか、または予定されるために指定されます(セクション4.4を見てください)。 例えば、以下で隣人州のマシンが系列で実行されると指定することによって、いくつかの隣人状態遷移が独身の容認されたHelloが作用されるかもしれません:
o Each Hello Packet causes the neighbor state machine to be
executed with the event HelloReceived.
o 各Hello PacketはイベントHelloReceivedと共に隣人州のマシンを実行させます。
o Then the list of neighbors contained in the Hello Packet is
examined. If the router itself appears in this list, the
neighbor state machine should be executed with the event 2-
WayReceived. Otherwise, the neighbor state machine should
be executed with the event 1-WayReceived, and the processing
of the packet stops.
o そして、Hello Packetに含まれた隣人のリストは調べられます。 ルータ自体がこのリストに現れるなら、隣人州のマシンはイベント2WayReceivedと共に実行されるべきです。 さもなければ、隣人州のマシンはイベント1-WayReceivedと共に実行されるべきです、そして、パケットの処理は止まります。
o Next, the Hello Packet's Router Priority field is examined.
If this field is different than the one previously received
from the neighbor, the receiving interface's state machine
is scheduled with the event NeighborChange. In any case,
the Router Priority field in the neighbor data structure
should be updated accordingly.
o 次に、Hello PacketのRouter Priority分野は調べられます。 この分野がものが以前に隣人から受信されたより異なるなら、受信インタフェースの州のマシンはイベントNeighborChangeと共に予定されています。 どのような場合でも、それに従って、隣人データ構造におけるRouter Priority分野をアップデートするべきです。
o Next the Designated Router field in the Hello Packet is
examined. If the neighbor is both declaring itself to be
Designated Router (Designated Router field = Neighbor IP
address) and the Backup Designated Router field in the
o 次に、Hello PacketのDesignated Router分野は調べられます。 隣人が、それ自体がDesignated Router(隣人IPアドレスにRouter分野=を指定する)であるとともに宣言しているか、そして、Backup Designated Routerは中でさばきます。
Moy Standards Track [Page 84] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[84ページ]RFC2178OSPFバージョン1997年7月2日
packet is equal to 0.0.0.0 and the receiving interface is in
state Waiting, the receiving interface's state machine is
scheduled with the event BackupSeen. Otherwise, if the
neighbor is declaring itself to be Designated Router and it
had not previously, or the neighbor is not declaring itself
Designated Router where it had previously, the receiving
interface's state machine is scheduled with the event
NeighborChange. In any case, the Neighbors' Designated
Router item in the neighbor structure is updated
accordingly.
パケットによる.0と受信インタフェースがある.0が、Waiting、受信インタフェースの州が機械加工すると述べる0.0への同輩がイベントBackupSeenと共に予定されているということです。 さもなければ、以前に、そうしていなかったか、隣人が、それ自体がDesignated Routerであると宣言していて、または隣人が、それ自体がそれが以前にそうしたDesignated Routerであると宣言していないなら、受信インタフェースの州のマシンはイベントNeighborChangeと共に予定されています。 どのような場合でも、それに従って、隣人構造のネイバーズのDesignated Routerの品目をアップデートします。
o Finally, the Backup Designated Router field in the Hello
Packet is examined. If the neighbor is declaring itself to
be Backup Designated Router (Backup Designated Router field
= Neighbor IP address) and the receiving interface is in
state Waiting, the receiving interface's state machine is
scheduled with the event BackupSeen. Otherwise, if the
neighbor is declaring itself to be Backup Designated Router
and it had not previously, or the neighbor is not declaring
itself Backup Designated Router where it had previously, the
receiving interface's state machine is scheduled with the
event NeighborChange. In any case, the Neighbor's Backup
Designated Router item in the neighbor structure is updated
accordingly.
o 最終的に、Hello PacketのBackup Designated Router分野は調べられます。 隣人が、それ自体がBackup Designated Routerであると宣言していて(Designated Router分野=隣人IPアドレスのバックアップをとってください)、受信インタフェースが州のWaitingにあるなら、受信インタフェースの州のマシンはイベントBackupSeenと共に予定されています。 さもなければ、以前に、そうしていなかったか、隣人が、それ自体がBackup Designated Routerであると宣言していて、または隣人が、それ自体がそれが以前にそうしたBackup Designated Routerであると宣言していないなら、受信インタフェースの州のマシンはイベントNeighborChangeと共に予定されています。 どのような場合でも、それに従って、隣人構造のNeighborのBackup Designated Routerの品目をアップデートします。
On NBMA networks, receipt of an Hello Packet may also cause an Hello Packet to be sent back to the neighbor in response. See Section 9.5.1 for more details.
また、NBMAネットワークでは、Hello Packetの領収書で、応答における隣人にHello Packetを送り返すかもしれません。 その他の詳細に関してセクション9.5.1を見てください。
10.6. Receiving Database Description Packets
10.6. データベース記述パケットを受けます。
This section explains the detailed processing of a received Database Description Packet. The incoming Database Description Packet has already been associated with a neighbor and receiving interface by the generic input packet processing (Section 8.2). Whether the Database Description packet should be accepted, and if so, how it should be further processed depends upon the neighbor state.
このセクションは容認されたDatabase記述Packetの詳細な処理について説明します。 入って来るDatabase記述Packetは既に隣人に関連していてジェネリック入力パケット処理(セクション8.2)でインタフェースを受けました。 そうだとすれば、Database記述パケットを受け入れるべきであり、それがどうさらに処理されるべきであるかが隣人状態によるか否かに関係なく。
If a Database Description packet is accepted, the following packet fields should be saved in the corresponding neighbor data structure under "last received Database Description packet": the packet's initialize(I), more (M) and master(MS) bits, Options field, and DD sequence number. If these fields are set identically in two consecutive Database Description packets received from the neighbor, the second Database Description packet is considered to be a "duplicate" in the processing described below.
Database記述パケットを受け入れるなら、「Database記述パケットは最後に受信した」下の対応する隣人データ構造で以下のパケット分野を節約するべきです: パケットのものは(I)、より多くの(M)、マスター(MS)ビット、Options分野、およびDD一連番号を初期化します。 隣人から受け取られた2つの連続したDatabase記述パケットが同様にこれらの分野にはめ込まれるなら、2番目のDatabase記述パケットは以下で説明された処理における「写し」であると考えられます。
Moy Standards Track [Page 85] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[85ページ]RFC2178OSPFバージョン1997年7月2日
If the Interface MTU field in the Database Description packet indicates an IP datagram size that is larger than the router can accept on the receiving interface without fragmentation, the Database Description packet is rejected. Otherwise, if the neighbor state is:
Database記述パケットのInterface MTU分野がルータが受信インタフェースで断片化なしで受け入れることができるより大きいIPデータグラムサイズを示すなら、Database記述パケットは拒絶されます。 さもなければ、隣人であるなら、状態は以下の通りです。
Down
The packet should be rejected.
パケットの下側に拒絶されるべきです。
Attempt
The packet should be rejected.
パケットを試みてください。拒絶されるべきです。
Init
The neighbor state machine should be executed with the event 2-
WayReceived. This causes an immediate state change to either
state 2-Way or state ExStart. If the new state is ExStart, the
processing of the current packet should then continue in this new
state by falling through to case ExStart below.
隣人州が機械加工するイニットはイベント2WayReceivedと共に実行されるべきです。 これは、即座の州の変化が2方法を述べるか、またはExStartを述べることを引き起こします。 そして、新しい状態がExStartであるなら、現在のパケットの処理は、通り抜けて落ちるのによるこの新しい状態で以下のExStartをケースに入れ続けるべきです。
2-Way
The packet should be ignored. Database Description Packets are
used only for the purpose of bringing up adjacencies.[7]
パケットが無視されるべき2方法。 データベース記述Packetsは隣接番組を持って来る目的にだけ使用されます。[7]
ExStart
If the received packet matches one of the following cases, then
the neighbor state machine should be executed with the event
NegotiationDone (causing the state to transition to Exchange), the
packet's Options field should be recorded in the neighbor
structure's Neighbor Options field and the packet should be
accepted as next in sequence and processed further (see below).
Otherwise, the packet should be ignored.
次に、以下のケースのパケットマッチ1、隣人州のマシンがそうするべきである受け取られていることのExStart IfがイベントNegotiationDone(Exchangeへの変遷に状態を引き起こす)と共に実行されて、パケットのOptions分野が隣人構造のNeighbor Options分野に記録されるべきであり、パケットは、次として連続して認められて、さらに処理されるべきです(以下を見てください)。 さもなければ、パケットは無視されるべきです。
o The initialize(I), more (M) and master(MS) bits are set,
the contents of the packet are empty, and the neighbor's
Router ID is larger than the router's own. In this case
the router is now Slave. Set the master/slave bit to
slave, and set the neighbor data structure's DD sequence
number to that specified by the master.
o (I)を初期化してください、より多くの(M)とマスター(MS)ビットが設定されて、パケットの内容が空であり、隣人のRouter IDはルータが自己であるより大きいです。 この場合、現在、ルータはSlaveです。 マスター/奴隷ビットに身を粉にして働くように設定してください、そして、隣人データ構造のDD一連番号をマスターによって指定されたそれに設定してください。
o The initialize(I) and master(MS) bits are off, the
packet's DD sequence number equals the neighbor data
structure's DD sequence number (indicating
acknowledgment) and the neighbor's Router ID is smaller
than the router's own. In this case the router is
Master.
o (I)とビットがあるマスター(MS)を初期化してください、パケットのDD一連番号が隣人データ構造のDD一連番号と等しく(承認を示して)、隣人のRouter IDはルータが自己であるより小さいです。 この場合、ルータはMasterです。
Moy Standards Track [Page 86] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[86ページ]RFC2178OSPFバージョン1997年7月2日
Exchange
Duplicate Database Description packets are discarded by the
master, and cause the slave to retransmit the last Database
Description packet that it had sent. Otherwise (the packet is not
a duplicate):
交換Duplicate Database記述パケットで、マスターによって捨てられて、奴隷はそれが送った最後のDatabase記述パケットを再送します。 そうでなければ(パケットは写しではありません):
o If the state of the MS-bit is inconsistent with the
master/slave state of the connection, generate the
neighbor event SeqNumberMismatch and stop processing the
packet.
o MS-ビットの状態が接続のマスター/奴隷制度の州に反するなら、隣人イベントがSeqNumberMismatchであると生成してください、そして、パケットを処理するのを止めてください。
o If the initialize(I) bit is set, generate the neighbor
event SeqNumberMismatch and stop processing the packet.
o (I)を初期化してください。ビットはセットして、隣人イベントがSeqNumberMismatchであると生成して、パケットを処理するのを止めることです。
o If the packet's Options field indicates a different set
of optional OSPF capabilities than were previously
received from the neighbor (recorded in the Neighbor
Options field of the neighbor structure), generate the
neighbor event SeqNumberMismatch and stop processing the
packet.
o パケットのOptions分野が任意の異なったOSPF能力を示すなら、以前に隣人(隣人構造のNeighbor Options分野に記録される)から受け取ったより隣人イベントがSeqNumberMismatchであり、停止処理がパケットであると生成してください。
o Database Description packets must be processed in
sequence, as indicated by the packets' DD sequence
numbers. If the router is master, the next packet
received should have DD sequence number equal to the DD
sequence number in the neighbor data structure. If the
router is slave, the next packet received should have DD
sequence number equal to one more than the DD sequence
number stored in the neighbor data structure. In either
case, if the packet is the next in sequence it should be
accepted and its contents processed as specified below.
o パケットのDD一連番号によって示されるように連続してデータベース記述パケットを処理しなければなりません。 ルータがマスターであるなら、受け取られた次のパケットは隣人データ構造におけるDD一連番号と等しいDD一連番号を持っているはずです。 ルータが奴隷であるなら、受け取られた次のパケットは隣人データ構造で保存されたDD一連番号より1つと等しいDD一連番号を持っているはずです。 どちらかの場合では、パケットが連続してそれがそうするべきである次であるなら、受け入れて以下で指定されるとして処理されたそのコンテンツになってください。
o Else, generate the neighbor event SeqNumberMismatch and
stop processing the packet.
o ほかに、隣人イベントがSeqNumberMismatchであると生成してください、そして、パケットを処理するのを止めてください。
Loading or Full
In this state, the router has sent and received an entire sequence
of Database Description Packets. The only packets received should
be duplicates (see above). In particular, the packet's Options
field should match the set of optional OSPF capabilities
previously indicated by the neighbor (stored in the neighbor
structure's Neighbor Options field). Any other packets received,
including the reception of a packet with the Initialize(I) bit
set, should generate the neighbor event SeqNumberMismatch.[8]
Duplicates should be discarded by the master. The slave must
respond to duplicates by repeating the last Database Description
packet that it had sent.
ローディングかFull In、この状態であり、ルータは、Database記述Packetsの全体の系列を送って、受け取りました。 受け取られた唯一のパケットが写しであるべきです(上を見てください)。 特に、パケットのOptions分野は以前に隣人(隣人構造のNeighbor Options分野では、保存される)によって示された任意のOSPF能力のセットに合うべきです。 いかなる他のパケットも受信されて、Initialize(I)ビットがあるパケットのレセプションが設定して、隣人イベントSeqNumberMismatch.[8]写しであると生成するべきである包含はマスターによって捨てられるべきです。 奴隷は、それが発信したと最後のDatabase記述パケットを繰り返すのによる写しに応答しなければなりません。
Moy Standards Track [Page 87] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[87ページ]RFC2178OSPFバージョン1997年7月2日
When the router accepts a received Database Description Packet as the next in sequence the packet contents are processed as follows. For each LSA listed, the LSA's LS type is checked for validity. If the LS type is unknown (e.g., not one of the LS types 1-5 defined by this specification), or if this is an AS-external-LSA (LS type = 5) and the neighbor is associated with a stub area, generate the neighbor event SeqNumberMismatch and stop processing the packet. Otherwise, the router looks up the LSA in its database to see whether it also has an instance of the LSA. If it does not, or if the database copy is less recent (see Section 13.1), the LSA is put on the Link state request list so that it can be requested (immediately or at some later time) in Link State Request Packets.
ルータが次として容認されたDatabase記述Packetを認めるとき、連続してパケット含有量は以下の通り処理されます。 LSAが記載したそれぞれに関しては、LSAのLSタイプは正当性がないかどうかチェックされます。 LSタイプが未知である(例えば、LSのどんなひとりもこの仕様で定義された1-5をタイプしません)、これがASの外部のLSA(LSは=5をタイプする)であり、または隣人がスタッブ領域に関連しているなら、隣人イベントがSeqNumberMismatchであると生成してください、そして、パケットを処理するのを止めてください。 さもなければ、ルータは、また、それにはLSAのインスタンスがあるかどうか確認するためにデータベースでLSAを見上げます。 そうしないか、またはデータベースコピーがそれほど最近でないなら(セクション13.1を見てください)、LSAは、Link州Request Packetsでそれを要求できる(すぐにか何らかの後の時間に)ようにLink州の要求リストに載せられます。
When the router accepts a received Database Description Packet as the next in sequence, it also performs the following actions, depending on whether it is master or slave:
また、ルータが次として連続して容認されたDatabase記述Packetを認めるとき、以下の動作を実行します、それがマスターかそれとも奴隷であるかに頼っていて:
Master
Increments the DD sequence number in the neighbor data structure.
If the router has already sent its entire sequence of Database
Description Packets, and the just accepted packet has the more bit
(M) set to 0, the neighbor event ExchangeDone is generated.
Otherwise, it should send a new Database Description to the slave.
Incrementsが隣人データ構造でDD一連番号であるとマスタリングしてください。 ルータが既にDatabase記述Packetsの全体の系列を送って、ただ受け入れられたパケットで、より多くのビット(M)を0に設定するなら、隣人イベントExchangeDoneは発生しています。 さもなければ、それは新しいDatabase記述を奴隷に送るべきです。
Slave
Sets the DD sequence number in the neighbor data structure to the
DD sequence number appearing in the received packet. The slave
must send a Database Description Packet in reply. If the received
packet has the more bit (M) set to 0, and the packet to be sent by
the slave will also have the M-bit set to 0, the neighbor event
ExchangeDone is generated. Note that the slave always generates
this event before the master.
奴隷Sets、容認されたパケットに現れるDD一連番号への隣人データ構造におけるDD一連番号。 奴隷は回答でDatabase記述Packetを送らなければなりません。 容認されたパケットで、より多くのビット(M)を0に設定して、また、奴隷によって送られるパケットでM-ビットを0に設定するなら、隣人イベントExchangeDoneは発生しています。 奴隷がマスターの前でいつもこのイベントを生成することに注意してください。
10.7. Receiving Link State Request Packets
10.7. リンク州のリクエスト・パケットを受けます。
This section explains the detailed processing of received Link State Request packets. Received Link State Request Packets specify a list of LSAs that the neighbor wishes to receive. Link State Request Packets should be accepted when the neighbor is in states Exchange, Loading, or Full. In all other states Link State Request Packets should be ignored.
このセクションは容認されたLink州Requestパケットの詳細な処理について説明します。 容認されたLink州Request Packetsは隣人が受け取りたがっているLSAsのリストを指定します。 隣人が州のExchange、Loading、またはFullにいるとき、リンク州Request Packetsを受け入れるべきです。 全部で、他の州のLink州Request Packetsは無視されるべきです。
Moy Standards Track [Page 88] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[88ページ]RFC2178OSPFバージョン1997年7月2日
Each LSA specified in the Link State Request packet should be located in the router's database, and copied into Link State Update packets for transmission to the neighbor. These LSAs should NOT be placed on the Link state retransmission list for the neighbor. If an LSA cannot be found in the database, something has gone wrong with the Database Exchange process, and neighbor event BadLSReq should be generated.
Link州Requestパケットで指定された各LSAはルータのデータベースに位置していて、隣人への伝送のためLink州Updateパケットにコピーされるべきです。 隣人のためにLink州の「再-トランスミッション」リストにこれらのLSAsを置くべきではありません。 データベースでLSAを見つけることができないなら、何かがDatabase Exchangeプロセスで支障をきたしました、そして、隣人イベントBadLSReqは生成されるべきです。
10.8. Sending Database Description Packets
10.8. 送付データベース記述パケット
This section describes how Database Description Packets are sent to a neighbor. The Database Description packet's Interface MTU field is set to the size of the largest IP datagram that can be sent out the sending interface, without fragmentation. Common MTUs in use in the Internet can be found in Table 7-1 of [Ref22]. Interface MTU should be set to 0 in Database Description packets sent over virtual links.
このセクションはどうDatabase記述Packetsを送るかを隣人に説明します。 Database記述パケットのInterface MTU分野は設定されて、それが最も大きいIPデータグラムであることができることのサイズに、送付インタフェースが出されていました、断片化なしでことです。 [Ref22]のTable7-1でインターネットで使用中の一般的なMTUsを見つけることができます。 インタフェースMTUはパケットが仮想のリンクの上に送ったDatabase記述で0に用意ができるべきです。
The router's optional OSPF capabilities (see Section 4.5) are transmitted to the neighbor in the Options field of the Database Description packet. The router should maintain the same set of optional capabilities throughout the Database Exchange and flooding procedures. If for some reason the router's optional capabilities change, the Database Exchange procedure should be restarted by reverting to neighbor state ExStart. One optional capability is defined in this specification (see Sections 4.5 and A.2). The E-bit should be set if and only if the attached network belongs to a non- stub area. Unrecognized bits in the Options field should be set to zero. The sending of Database Description packets depends on the neighbor's state. In state ExStart the router sends empty Database Description packets, with the initialize (I), more (M) and master (MS) bits set. These packets are retransmitted every RxmtInterval seconds.
ルータの任意のOSPF能力(セクション4.5を見る)はDatabase記述パケットのOptions分野の隣人に伝えられます。 ルータはDatabase Exchangeと氾濫手順中で同じセットの任意の能力を維持するべきです。 ある理由でルータの任意の能力が変化するなら、Database Exchange手順は、隣人州のExStartに戻ることによって、再開されるべきです。 1つの任意の能力がこの仕様に基づき定義されます(セクション4.5とA.2を見てください)。 そして、E-ビットが設定されるべきである、付属ネットワークが非スタッブの領域に属す場合にだけ。 Options分野の認識されていないビットはゼロに設定されるべきです。 Database記述パケットの発信は隣人の状態に依存します。 州のExStartでは、ルータが空のDatabase記述パケットを送る、(I)、より多くの(M)、およびビットが設定するマスター(MS)を初期化してください。 これらのパケットは再送されます。あらゆるRxmtIntervalが後援します。
In state Exchange the Database Description Packets actually contain summaries of the link state information contained in the router's database. Each LSA in the area's link-state database (at the time the neighbor transitions into Exchange state) is listed in the neighbor Database summary list. Each new Database Description Packet copies its DD sequence number from the neighbor data structure and then describes the current top of the Database summary list. Items are removed from the Database summary list when the previous packet is acknowledged.
州のExchangeでは、Database記述Packetsは実際にルータのデータベースに含まれたリンク州の情報の概要を含んでいます。 領域のリンク州のデータベース(Exchangeへの隣人変遷が述べる時間の)の各LSAは隣人Database概要リストに記載されています。 それぞれの新しいDatabase記述Packetは隣人データ構造からDD一連番号をコピーして、次に、Database概要リストの現在の上部について説明します。 前のパケットが承認されるとき、商品はDatabase概要リストから取り外されます。
In state Exchange, the determination of when to send a Database Description packet depends on whether the router is master or slave:
州のExchangeでは、いつDatabase記述パケットを送るかに関する決断をルータがマスターかそれとも奴隷であるかに頼っています:
Moy Standards Track [Page 89] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[89ページ]RFC2178OSPFバージョン1997年7月2日
Master
Database Description packets are sent when either a) the slave
acknowledges the previous Database Description packet by echoing
the DD sequence number or b) RxmtInterval seconds elapse without
an acknowledgment, in which case the previous Database Description
packet is retransmitted.
a) 奴隷がDD一連番号かb)を反響することによって前のDatabase記述パケットを承認すると、マスターDatabase記述パケットを送ります。 RxmtInterval秒は承認なしで経過します、その場合、前のDatabase記述パケットが再送されます。
Slave
Database Description packets are sent only in response to Database
Description packets received from the master. If the Database
Description packet received from the master is new, a new Database
Description packet is sent, otherwise the previous Database
Description packet is resent.
単にマスターから受け取られたDatabase記述パケットに対応して奴隷Database記述パケットを送ります。 マスターから受け取られたDatabase記述パケットが新しいなら、新しいDatabase記述パケットを送ります。さもなければ、前のDatabase記述パケットを再送します。
In states Loading and Full the slave must resend its last Database Description packet in response to duplicate Database Description packets received from the master. For this reason the slave must wait RouterDeadInterval seconds before freeing the last Database Description packet. Reception of a Database Description packet from the master after this interval will generate a SeqNumberMismatch neighbor event.
州のLoadingとFullでは、奴隷はマスターから受け取られた写しDatabase記述パケットに対応して最後のDatabase記述パケットを再送しなければなりません。 この理由で、最後のDatabase記述パケットを解放する前に、奴隷はRouterDeadInterval秒を待たなければなりません。 この間隔の後のマスターからのDatabase記述パケットのレセプションはSeqNumberMismatch隣人イベントを生成するでしょう。
10.9. Sending Link State Request Packets
10.9. 送付リンク州のリクエスト・パケット
In neighbor states Exchange or Loading, the Link state request list contains a list of those LSAs that need to be obtained from the neighbor. To request these LSAs, a router sends the neighbor the beginning of the Link state request list, packaged in a Link State Request packet.
隣人州のExchangeかLoadingでは、Link州の要求リストは隣人から得られる必要があるそれらのLSAsのリストを含んでいます。 これらのLSAsを要求するために、ルータはLink州RequestパケットでパッケージされたLink州の要求リストの始まりを隣人に送ります。
When the neighbor responds to these requests with the proper Link State Update packet(s), the Link state request list is truncated and a new Link State Request packet is sent. This process continues until the Link state request list becomes empty. Unsatisfied Link State Request packets are retransmitted at intervals of RxmtInterval. There should be at most one Link State Request packet outstanding at any one time.
隣人が適切なLink州Updateパケットでこれらの要求に応じるとき、Link州の要求リストは端が欠けています、そして、新しいLink州Requestパケットを送ります。 Link州の要求リストが空になるまで、このプロセスは持続します。 満たされていないLink州RequestパケットはRxmtIntervalごとに再送されます。 いかなる時も未払いのLink州Requestパケットが最も1つにあるはずです。
When the Link state request list becomes empty, and the neighbor state is Loading (i.e., a complete sequence of Database Description packets has been sent to and received from the neighbor), the Loading Done neighbor event is generated.
Link州の要求リストが空になって、隣人状態がLoading(すなわち、Database記述パケットの完全な配列は、隣人から送って受け取られている)であるときに、Loading Done隣人イベントは発生しています。
Moy Standards Track [Page 90] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[90ページ]RFC2178OSPFバージョン1997年7月2日
10.10. An Example
10.10. 例
Figure 14 shows an example of an adjacency forming. Routers RT1 and RT2 are both connected to a broadcast network. It is assumed that RT2 is the Designated Router for the network, and that RT2 has a higher Router ID than Router RT1.
図14は、隣接番組に関する例が形成されるのを示します。 ルータのRT1とRT2はともに放送網に接続されます。 RT2がネットワークのためのDesignated Routerであり、RT2にはRouter RT1より高いRouter IDがあると思われます。
The neighbor state changes realized by each router are listed on the sides of the figure.
各ルータによって実感された隣人州の変化は図の側面に記載されています。
At the beginning of Figure 14, Router RT1's interface to the network becomes operational. It begins sending Hello Packets, although it doesn't know the identity of the Designated Router or of any other neighboring routers. Router RT2 hears this hello (moving the neighbor to Init state), and in its next Hello Packet indicates that it is itself the Designated Router and that it has heard Hello Packets from RT1. This in turn causes RT1 to go to state ExStart, as it starts to bring up the adjacency.
図14の始めに、ネットワークへのRouter RT1のインタフェースは操作上になります。 それはHello Packetsを送り始めます、Designated Routerかいかなる他の隣接しているルータのアイデンティティも知りませんが。 ルータRT2がこれを聞く、こんにちは、(隣人をInit状態に動かします)、そして、次では、Hello Packetは、それがそれ自体でDesignated Routerであることを示して、それはRT1からHello Packetsを聞きました。 これで、隣接番組を持って来始めるとき、RT1はExStartを述べに順番に行きます。
RT1 begins by asserting itself as the master. When it sees that RT2 is indeed the master (because of RT2's higher Router ID), RT1 transitions to slave state and adopts its neighbor's DD sequence number. Database Description packets are then exchanged, with polls coming from the master (RT2) and responses from the slave (RT1). This sequence of Database Description Packets ends when both the poll and associated response has the M-bit off.
RT1は、マスターとしてそれ自体について断言することによって、始まります。 本当に、RT2がマスター(RT2の、より高いRouter IDによる)であることが見るとき、RT1は奴隷制度の州に移行して、隣人のDD一連番号を採用します。 そして、投票がマスター(RT2)と応答から奴隷(RT1)から来ていて、データベース記述パケットを交換します。 投票と関連応答の両方であるときに、Database記述Packetsエンドのこの系列はM-ビットを休みにします。
In this example, it is assumed that RT2 has a completely up to date database. In that case, RT2 goes immediately into Full state. RT1 will go into Full state after updating the necessary parts of its database. This is done by sending Link State Request Packets, and receiving Link State Update Packets in response. Note that, while RT1 has waited until a complete set of Database Description Packets has been received (from RT2) before sending any Link State Request Packets, this need not be the case. RT1 could have interleaved the sending of Link State Request Packets with the reception of Database Description Packets.
この例では、RT2には完全に最新のデータベースがあると思われます。 その場合、RT2はすぐFull状態に入ります。 データベースの必要な部分をアップデートした後に、RT1はFull状態に入るでしょう。 Link州Request Packetsを送って、応答でLink州Update Packetsを受けることによって、これをします。 RT1がどんなLink州Request Packetsも送る前にDatabase記述Packetsの完全なセットを受け取るまで(RT2から)待った間これがそうである必要はないことに注意してください。 RT1はDatabase記述Packetsのレセプションに伴うLink州Request Packetsの発信をはさみ込んだかもしれません。
Moy Standards Track [Page 91] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[91ページ]RFC2178OSPFバージョン1997年7月2日
+---+ +---+
|RT1| |RT2|
+---+ +---+
+---+ +---+ |RT1| |RT2| +---+ +---+
Down Down
Hello(DR=0,seen=0)
------------------------------>
Hello (DR=RT2,seen=RT1,...) Init
<------------------------------
ExStart D-D (Seq=x,I,M,Master)
------------------------------>
D-D (Seq=y,I,M,Master) ExStart
<------------------------------
Exchange D-D (Seq=y,M,Slave)
------------------------------>
D-D (Seq=y+1,M,Master) Exchange
<------------------------------
D-D (Seq=y+1,M,Slave)
------------------------------>
...
...
...
D-D (Seq=y+n, Master)
<------------------------------
D-D (Seq=y+n, Slave)
Loading ------------------------------>
LS Request Full
------------------------------>
LS Update
<------------------------------
LS Request
------------------------------>
LS Update
<------------------------------
Full
こんにちは、下に、下に、(DR=0、見られた=0)------------------------------>、こんにちは、(DR=RT2、見られた=RT1) イニット<。------------------------------ ExStart忌わしいです(Seq=x、I、M、マスター)。------------------------------>(Seq=y、I、M、マスター)忌わしいExStart<。------------------------------ 交換忌わしいです(Seq=y(M)は身を粉にして働きます)。------------------------------>の忌わしい(+1(M)がマスタリングするSeq=y)交換<。------------------------------ 忌わしいです(Seq=y+1(M)は身を粉にして働きます)。------------------------------>… ... ... 忌わしい(Seq=y+n、マスター)<。------------------------------ 忌わしい(Seq=y+n、奴隷)ローディング------------------------------LSがいっぱいに要求する>。------------------------------>LSアップデート<。------------------------------ LS要求------------------------------>LSアップデート<。------------------------------ 完全
Figure 14: An adjacency bring-up example
図14: 隣接番組は例を持って来ます。
Moy Standards Track [Page 92] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[92ページ]RFC2178OSPFバージョン1997年7月2日
11. The Routing Table Structure
11. 経路指定テーブル構造
The routing table data structure contains all the information necessary to forward an IP data packet toward its destination. Each routing table entry describes the collection of best paths to a particular destination. When forwarding an IP data packet, the routing table entry providing the best match for the packet's IP destination is located. The matching routing table entry then provides the next hop towards the packet's destination. OSPF also provides for the existence of a default route (Destination ID = DefaultDestination, Address Mask = 0x00000000). When the default route exists, it matches all IP destinations (although any other matching entry is a better match). Finding the routing table entry that best matches an IP destination is further described in Section 11.1.
経路指定テーブルデータ構造はIPデータ・パケットを目的地に向かって送るのに必要なすべての情報を含んでいます。 それぞれの経路指定テーブルエントリーは最も良い経路の収集について特定の目的地に説明します。 IPデータ・パケットを進めるとき、パケットのIPの目的地に提供する中でマッチ最も良い経路指定テーブルエントリーは見つけられています。 そして、合っている経路指定テーブルエントリーはパケットの目的地に向かって次のホップを提供します。 また、OSPFはデフォルトルートの存在に備えます(Destination IDはDefaultDestination、Address Mask=0x00000000と等しいです)。 デフォルトルートが存在するとき、それはすべてのIPの目的地に合っています(いかなる他の合っているエントリーもより良いマッチですが)。 ルーティングがIPの目的地に最もよく合っているテーブル項目であることがわかるのとセクション11.1でさらに説明されます。
There is a single routing table in each router. Two sample routing tables are described in Sections 11.2 and 11.3. The building of the routing table is discussed in Section 16.
各ルータには単一の経路指定テーブルがあります。 2個のサンプル経路指定テーブルがセクション11.2と11.3で説明されます。 セクション16で経路指定テーブルのビルについて議論します。
The rest of this section defines the fields found in a routing table entry. The first set of fields describes the routing table entry's destination.
このセクションの残りは経路指定テーブルエントリーで見つけられた分野を定義します。 分野の第一セットは経路指定テーブルエントリーの目的地について説明します。
Destination Type
Destination type is either "network" or "router". Only network entries
are actually used when forwarding IP data traffic. Router routing
table entries are used solely as intermediate steps in the routing
table build process.
目的地Type Destinationタイプは、「ネットワーク」か「ルータ」のどちらかです。 IPデータ通信量を進めるとき、ネットワークエントリーだけが実際に使用されます。 経路指定テーブルの途中経過がプロセスを建てるとき、ルータ経路指定テーブルエントリーは唯一使用されます。
A network is a range of IP addresses, to which IP data traffic may be
forwarded. This includes IP networks (class A, B, or C), IP subnets,
IP supernets and single IP hosts. The default route also falls into
this category.
ネットワークはさまざまなIPアドレスです。(IPデータ通信量はそのアドレスに送られるかもしれません)。 これはIPネットワーク(クラスA、B、またはC)、IPサブネット、IP「スーパー-ネット」、および独身のIPホストを含んでいます。 また、デフォルトルートはこのカテゴリになります。
Router entries are kept for area border routers and AS boundary
routers. Routing table entries for area border routers are used when
calculating the inter-area routes (see Section 16.2), and when
maintaining configured virtual links (see Section 15). Routing table
entries for AS boundary routers are used when calculating the AS
external routes (see Section 16.4).
ルータエントリーは境界ルータとAS境界ルータのために保たれます。 相互領域ルートを計算するとき、境界ルータが使用されていて(セクション16.2を見てください)、構成された仮想のリンクを維持するとき(セクション15を見ます)、テーブル項目を発送します。 AS外部経路を計算するとき、AS境界ルータのための経路指定テーブルエントリーは使用されています(セクション16.4を見てください)。
Destination ID
The destination's identifier or name. This depends on the
Destination Type. For networks, the identifier is their associated IP
address. For routers, the identifier is the OSPF Router ID.[9]
目的地ID、目的地の識別子か名前。 これはDestination Typeによります。 ネットワークにおいて、識別子はそれらの関連IPアドレスです。 ルータのために、識別子はOSPF Router IDです。[9]
Moy Standards Track [Page 93] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[93ページ]RFC2178OSPFバージョン1997年7月2日
Address Mask
Only defined for networks. The network's IP address together with its
address mask defines a range of IP addresses. For IP subnets, the
address mask is referred to as the subnet mask. For host routes, the
mask is "all ones" (0xffffffff).
ネットワークのために定義されたMask Onlyを扱ってください。 アドレスマスクに伴うネットワークのIPアドレスはさまざまなIPアドレスを定義します。 IPサブネットにおいて、アドレスマスクはサブネットマスクと呼ばれます。 ホストルートに、マスクは「すべてのもの」(0xffffffff)です。
Optional Capabilities
When the destination is a router this field indicates the optional
OSPF capabilities supported by the destination router. The only
optional capability defined by this specification is the ability to
process AS-external-LSAs. For a further discussion of OSPF's optional
capabilities, see Section 4.5.
Optional Capabilities When the destination is a router this field indicates the optional OSPF capabilities supported by the destination router. The only optional capability defined by this specification is the ability to process AS-external-LSAs. For a further discussion of OSPF's optional capabilities, see Section 4.5.
The set of paths to use for a destination may vary based on the OSPF area to which the paths belong. This means that there may be multiple routing table entries for the same destination, depending on the values of the next field.
The set of paths to use for a destination may vary based on the OSPF area to which the paths belong. This means that there may be multiple routing table entries for the same destination, depending on the values of the next field.
Area
This field indicates the area whose link state information has led
to the routing table entry's collection of paths. This is called
the entry's associated area. For sets of AS external paths, this
field is not defined. For destinations of type "router", there
may be separate sets of paths (and therefore separate routing
table entries) associated with each of several areas. For example,
this will happen when two area border routers share multiple areas
in common. For destinations of type "network", only the set of
paths associated with the best area (the one providing the
preferred route) is kept.
Area This field indicates the area whose link state information has led to the routing table entry's collection of paths. This is called the entry's associated area. For sets of AS external paths, this field is not defined. For destinations of type "router", there may be separate sets of paths (and therefore separate routing table entries) associated with each of several areas. For example, this will happen when two area border routers share multiple areas in common. For destinations of type "network", only the set of paths associated with the best area (the one providing the preferred route) is kept.
The rest of the routing table entry describes the set of paths to the destination. The following fields pertain to the set of paths as a whole. In other words, each one of the paths contained in a routing table entry is of the same path-type and cost (see below).
The rest of the routing table entry describes the set of paths to the destination. The following fields pertain to the set of paths as a whole. In other words, each one of the paths contained in a routing table entry is of the same path-type and cost (see below).
Path-type
There are four possible types of paths used to route traffic to
the destination, listed here in order of preference: intra-area,
inter-area, type 1 external or type 2 external. Intra-area paths
indicate destinations belonging to one of the router's attached
areas. Inter-area paths are paths to destinations in other OSPF
areas. These are discovered through the examination of received
summary-LSAs. AS external paths are paths to destinations
external to the AS. These are detected through the examination of
received AS-external-LSAs.
Path-type There are four possible types of paths used to route traffic to the destination, listed here in order of preference: intra-area, inter-area, type 1 external or type 2 external. Intra-area paths indicate destinations belonging to one of the router's attached areas. Inter-area paths are paths to destinations in other OSPF areas. These are discovered through the examination of received summary-LSAs. AS external paths are paths to destinations external to the AS. These are detected through the examination of received AS-external-LSAs.
Moy Standards Track [Page 94] RFC 2178 OSPF Version 2 July 1997
Moy Standards Track [Page 94] RFC 2178 OSPF Version 2 July 1997
Cost
The link state cost of the path to the destination. For all paths
except type 2 external paths this describes the entire path's
cost. For Type 2 external paths, this field describes the cost of
the portion of the path internal to the AS. This cost is
calculated as the sum of the costs of the path's constituent
links.
Cost The link state cost of the path to the destination. For all paths except type 2 external paths this describes the entire path's cost. For Type 2 external paths, this field describes the cost of the portion of the path internal to the AS. This cost is calculated as the sum of the costs of the path's constituent links.
Type 2 cost
Only valid for type 2 external paths. For these paths, this field
indicates the cost of the path's external portion. This cost has
been advertised by an AS boundary router, and is the most
significant part of the total path cost. For example, a type 2
external path with type 2 cost of 5 is always preferred over a
path with type 2 cost of 10, regardless of the cost of the two
paths' internal components.
Type 2 cost Only valid for type 2 external paths. For these paths, this field indicates the cost of the path's external portion. This cost has been advertised by an AS boundary router, and is the most significant part of the total path cost. For example, a type 2 external path with type 2 cost of 5 is always preferred over a path with type 2 cost of 10, regardless of the cost of the two paths' internal components.
Link State Origin
Valid only for intra-area paths, this field indicates the LSA
(router-LSA or network-LSA) that directly references the
destination. For example, if the destination is a transit
network, this is the transit network's network-LSA. If the
destination is a stub network, this is the router-LSA for the
attached router. The LSA is discovered during the shortest-path
tree calculation (see Section 16.1). Multiple LSAs may reference
the destination, however a tie-breaking scheme always reduces the
choice to a single LSA. The Link State Origin field is not used by
the OSPF protocol, but it is used by the routing table calculation
in OSPF's Multicast routing extensions (MOSPF).
Link State Origin Valid only for intra-area paths, this field indicates the LSA (router-LSA or network-LSA) that directly references the destination. For example, if the destination is a transit network, this is the transit network's network-LSA. If the destination is a stub network, this is the router-LSA for the attached router. The LSA is discovered during the shortest-path tree calculation (see Section 16.1). Multiple LSAs may reference the destination, however a tie-breaking scheme always reduces the choice to a single LSA. The Link State Origin field is not used by the OSPF protocol, but it is used by the routing table calculation in OSPF's Multicast routing extensions (MOSPF).
When multiple paths of equal path-type and cost exist to a destination (called elsewhere "equal-cost" paths), they are stored in a single routing table entry. Each one of the "equal-cost" paths is distinguished by the following fields:
When multiple paths of equal path-type and cost exist to a destination (called elsewhere "equal-cost" paths), they are stored in a single routing table entry. Each one of the "equal-cost" paths is distinguished by the following fields:
Next hop
The outgoing router interface to use when forwarding traffic to
the destination. On broadcast, Point-to-MultiPoint and NBMA
networks, the next hop also includes the IP address of the next
router (if any) in the path towards the destination.
Next hop The outgoing router interface to use when forwarding traffic to the destination. On broadcast, Point-to-MultiPoint and NBMA networks, the next hop also includes the IP address of the next router (if any) in the path towards the destination.
Advertising router
Valid only for inter-area and AS external paths. This field
indicates the Router ID of the router advertising the summary-LSA
or AS-external-LSA that led to this path.
Advertising router Valid only for inter-area and AS external paths. This field indicates the Router ID of the router advertising the summary-LSA or AS-external-LSA that led to this path.
Moy Standards Track [Page 95] RFC 2178 OSPF Version 2 July 1997
Moy Standards Track [Page 95] RFC 2178 OSPF Version 2 July 1997
11.1. Routing table lookup
11.1. Routing table lookup
When an IP data packet is received, an OSPF router finds the routing table entry that best matches the packet's destination. This routing table entry then provides the outgoing interface and next hop router to use in forwarding the packet. This section describes the process of finding the best matching routing table entry. The process consists of a number of steps, wherein the collection of routing table entries is progressively pruned. In the end, the single routing table entry remaining is called the "best match".
When an IP data packet is received, an OSPF router finds the routing table entry that best matches the packet's destination. This routing table entry then provides the outgoing interface and next hop router to use in forwarding the packet. This section describes the process of finding the best matching routing table entry. The process consists of a number of steps, wherein the collection of routing table entries is progressively pruned. In the end, the single routing table entry remaining is called the "best match".
Before the lookup begins, "discard" routing table entries should be inserted into the routing table for each of the router's active area address ranges (see Section 3.5). (An area range is considered "active" if the range contains one or more networks reachable by intra-area paths.) The destination of a "discard" entry is the set of addresses described by its associated active area address range, and the path type of each "discard" entry is set to "inter-area".[10]
Before the lookup begins, "discard" routing table entries should be inserted into the routing table for each of the router's active area address ranges (see Section 3.5). (An area range is considered "active" if the range contains one or more networks reachable by intra-area paths.) The destination of a "discard" entry is the set of addresses described by its associated active area address range, and the path type of each "discard" entry is set to "inter-area".[10]
Note that the steps described below may fail to produce a best match routing table entry (i.e., all existing routing table entries are pruned for some reason or another), or the best match routing table entry may be one of the above "discard" routing table entries. In these cases, the packet's IP destination is considered unreachable. Instead of being forwarded, the packet should be discarded and an ICMP destination unreachable message should be returned to the packet's source.
Note that the steps described below may fail to produce a best match routing table entry (i.e., all existing routing table entries are pruned for some reason or another), or the best match routing table entry may be one of the above "discard" routing table entries. In these cases, the packet's IP destination is considered unreachable. Instead of being forwarded, the packet should be discarded and an ICMP destination unreachable message should be returned to the packet's source.
(1) Select the complete set of "matching" routing table entries
from the routing table. Each routing table entry describes
a (set of) path(s) to a range of IP addresses. If the data
packet's IP destination falls into an entry's range of IP
addresses, the routing table entry is called a match. (It is
quite likely that multiple entries will match the data
packet. For example, a default route will match all
packets.)
(1) Select the complete set of "matching" routing table entries from the routing table. Each routing table entry describes a (set of) path(s) to a range of IP addresses. If the data packet's IP destination falls into an entry's range of IP addresses, the routing table entry is called a match. (It is quite likely that multiple entries will match the data packet. For example, a default route will match all packets.)
(2) Reduce the set of matching entries to those having the most
preferential path-type (see Section 11). OSPF has a four
level hierarchy of paths. Intra-area paths are the most
preferred, followed in order by inter-area, type 1 external
and type 2 external paths.
(2) Reduce the set of matching entries to those having the most preferential path-type (see Section 11). OSPF has a four level hierarchy of paths. Intra-area paths are the most preferred, followed in order by inter-area, type 1 external and type 2 external paths.
(3) Select the remaining routing table entry that provides the
most specific (longest) match. Another way of saying this is
to choose the remaining entry that specifies the narrowest
range of IP addresses.[11] For example, the entry for the
address/mask pair of (128.185.1.0, 0xffffff00) is more
(3) Select the remaining routing table entry that provides the most specific (longest) match. Another way of saying this is to choose the remaining entry that specifies the narrowest range of IP addresses.[11] For example, the entry for the address/mask pair of (128.185.1.0, 0xffffff00) is more
Moy Standards Track [Page 96] RFC 2178 OSPF Version 2 July 1997
Moy Standards Track [Page 96] RFC 2178 OSPF Version 2 July 1997
specific than an entry for the pair (128.185.0.0,
0xffff0000). The default route is the least specific match,
since it matches all destinations.
specific than an entry for the pair (128.185.0.0, 0xffff0000). The default route is the least specific match, since it matches all destinations.
11.2. Sample routing table, without areas
11.2. Sample routing table, without areas
Consider the Autonomous System pictured in Figure 2. No OSPF areas have been configured. A single metric is shown per outbound interface. The calculation of Router RT6's routing table proceeds as described in Section 2.2. The resulting routing table is shown in Table 12. Destination types are abbreviated: Network as "N", Router as "R".
Consider the Autonomous System pictured in Figure 2. No OSPF areas have been configured. A single metric is shown per outbound interface. The calculation of Router RT6's routing table proceeds as described in Section 2.2. The resulting routing table is shown in Table 12. Destination types are abbreviated: Network as "N", Router as "R".
There are no instances of multiple equal-cost shortest paths in this example. Also, since there are no areas, there are no inter-area paths.
There are no instances of multiple equal-cost shortest paths in this example. Also, since there are no areas, there are no inter-area paths.
Routers RT5 and RT7 are AS boundary routers. Intra-area routes have been calculated to Routers RT5 and RT7. This allows external routes to be calculated to the destinations advertised by RT5 and RT7 (i.e., Networks N12, N13, N14 and N15). It is assumed all AS-external-LSAs originated by RT5 and RT7 are advertising type 1 external metrics. This results in type 1 external paths being calculated to destinations N12-N15.
Routers RT5 and RT7 are AS boundary routers. Intra-area routes have been calculated to Routers RT5 and RT7. This allows external routes to be calculated to the destinations advertised by RT5 and RT7 (i.e., Networks N12, N13, N14 and N15). It is assumed all AS-external-LSAs originated by RT5 and RT7 are advertising type 1 external metrics. This results in type 1 external paths being calculated to destinations N12-N15.
11.3. Sample routing table, with areas
11.3. Sample routing table, with areas
Consider the previous example, this time split into OSPF areas. An OSPF area configuration is pictured in Figure 6. Router RT4's routing table will be described for this area configuration. Router RT4 has a connection to Area 1 and a backbone connection. This causes Router RT4 to view the AS as the concatenation of the two graphs shown in Figures 7 and 8. The resulting routing table is displayed in Table 13.
Consider the previous example, this time split into OSPF areas. An OSPF area configuration is pictured in Figure 6. Router RT4's routing table will be described for this area configuration. Router RT4 has a connection to Area 1 and a backbone connection. This causes Router RT4 to view the AS as the concatenation of the two graphs shown in Figures 7 and 8. The resulting routing table is displayed in Table 13.
Moy Standards Track [Page 97] RFC 2178 OSPF Version 2 July 1997
Moy Standards Track [Page 97] RFC 2178 OSPF Version 2 July 1997
Type Dest Area Path Type Cost Next Adv.
Hop(s) Router(s)
____________________________________________________________
N N1 0 intra-area 10 RT3 *
N N2 0 intra-area 10 RT3 *
N N3 0 intra-area 7 RT3 *
N N4 0 intra-area 8 RT3 *
N Ib 0 intra-area 7 * *
N Ia 0 intra-area 12 RT10 *
N N6 0 intra-area 8 RT10 *
N N7 0 intra-area 12 RT10 *
N N8 0 intra-area 10 RT10 *
N N9 0 intra-area 11 RT10 *
N N10 0 intra-area 13 RT10 *
N N11 0 intra-area 14 RT10 *
N H1 0 intra-area 21 RT10 *
R RT5 0 intra-area 6 RT5 *
R RT7 0 intra-area 8 RT10 *
____________________________________________________________
N N12 * type 1 ext. 10 RT10 RT7
N N13 * type 1 ext. 14 RT5 RT5
N N14 * type 1 ext. 14 RT5 RT5
N N15 * type 1 ext. 17 RT10 RT7
Type Dest Area Path Type Cost Next Adv. Hop(s) Router(s) ____________________________________________________________ N N1 0 intra-area 10 RT3 * N N2 0 intra-area 10 RT3 * N N3 0 intra-area 7 RT3 * N N4 0 intra-area 8 RT3 * N Ib 0 intra-area 7 * * N Ia 0 intra-area 12 RT10 * N N6 0 intra-area 8 RT10 * N N7 0 intra-area 12 RT10 * N N8 0 intra-area 10 RT10 * N N9 0 intra-area 11 RT10 * N N10 0 intra-area 13 RT10 * N N11 0 intra-area 14 RT10 * N H1 0 intra-area 21 RT10 * R RT5 0 intra-area 6 RT5 * R RT7 0 intra-area 8 RT10 * ____________________________________________________________ N N12 * type 1 ext. 10 RT10 RT7 N N13 * type 1 ext. 14 RT5 RT5 N N14 * type 1 ext. 14 RT5 RT5 N N15 * type 1 ext. 17 RT10 RT7
Table 12: The routing table for Router RT6
(no configured areas).
Table 12: The routing table for Router RT6 (no configured areas).
Again, Routers RT5 and RT7 are AS boundary routers. Routers RT3, RT4, RT7, RT10 and RT11 are area border routers. Note that there are two routing entries for the area border router RT3, since it has two areas in common with RT4 (Area 1 and the backbone).
Again, Routers RT5 and RT7 are AS boundary routers. Routers RT3, RT4, RT7, RT10 and RT11 are area border routers. Note that there are two routing entries for the area border router RT3, since it has two areas in common with RT4 (Area 1 and the backbone).
Backbone paths have been calculated to all area border routers. These are used when determining the inter-area routes. Note that all of the inter-area routes are associated with the backbone; this is always the case when the calculating router is itself an area border router. Routing information is condensed at area boundaries. In this example, we assume that Area 3 has been defined so that networks N9-N11 and the host route to H1 are all condensed to a single route when advertised into the backbone (by Router RT11). Note that the cost of this route is the maximum of the set of costs to its individual components.
Backbone paths have been calculated to all area border routers. These are used when determining the inter-area routes. Note that all of the inter-area routes are associated with the backbone; this is always the case when the calculating router is itself an area border router. Routing information is condensed at area boundaries. In this example, we assume that Area 3 has been defined so that networks N9-N11 and the host route to H1 are all condensed to a single route when advertised into the backbone (by Router RT11). Note that the cost of this route is the maximum of the set of costs to its individual components.
Moy Standards Track [Page 98] RFC 2178 OSPF Version 2 July 1997
Moy Standards Track [Page 98] RFC 2178 OSPF Version 2 July 1997
There is a virtual link configured between Routers RT10 and RT11. Without this configured virtual link, RT11 would be unable to advertise a route for networks N9-N11 and Host H1 into the backbone, and there would not be an entry for these networks in Router RT4's routing table.
There is a virtual link configured between Routers RT10 and RT11. Without this configured virtual link, RT11 would be unable to advertise a route for networks N9-N11 and Host H1 into the backbone, and there would not be an entry for these networks in Router RT4's routing table.
In this example there are two equal-cost paths to Network N12. However, they both use the same next hop (Router RT5).
In this example there are two equal-cost paths to Network N12. However, they both use the same next hop (Router RT5).
Type Dest Area Path Type Cost Next Adv.
Hops(s) Router(s)
__________________________________________________________________
N N1 1 intra-area 4 RT1 *
N N2 1 intra-area 4 RT2 *
N N3 1 intra-area 1 * *
N N4 1 intra-area 3 RT3 *
R RT3 1 intra-area 1 * *
__________________________________________________________________
N Ib 0 intra-area 22 RT5 *
N Ia 0 intra-area 27 RT5 *
R RT3 0 intra-area 21 RT5 *
R RT5 0 intra-area 8 * *
R RT7 0 intra-area 14 RT5 *
R RT10 0 intra-area 22 RT5 *
R RT11 0 intra-area 25 RT5 *
__________________________________________________________________
N N6 0 inter-area 15 RT5 RT7
N N7 0 inter-area 19 RT5 RT7
N N8 0 inter-area 18 RT5 RT7
N N9-N11,H1 0 inter-area 36 RT5 RT11
__________________________________________________________________
N N12 * type 1 ext. 16 RT5 RT5,RT7
N N13 * type 1 ext. 16 RT5 RT5
N N14 * type 1 ext. 16 RT5 RT5
N N15 * type 1 ext. 23 RT5 RT7
Type Dest Area Path Type Cost Next Adv. Hops(s) Router(s) __________________________________________________________________ N N1 1 intra-area 4 RT1 * N N2 1 intra-area 4 RT2 * N N3 1 intra-area 1 * * N N4 1 intra-area 3 RT3 * R RT3 1 intra-area 1 * * __________________________________________________________________ N Ib 0 intra-area 22 RT5 * N Ia 0 intra-area 27 RT5 * R RT3 0 intra-area 21 RT5 * R RT5 0 intra-area 8 * * R RT7 0 intra-area 14 RT5 * R RT10 0 intra-area 22 RT5 * R RT11 0 intra-area 25 RT5 * __________________________________________________________________ N N6 0 inter-area 15 RT5 RT7 N N7 0 inter-area 19 RT5 RT7 N N8 0 inter-area 18 RT5 RT7 N N9-N11,H1 0 inter-area 36 RT5 RT11 __________________________________________________________________ N N12 * type 1 ext. 16 RT5 RT5,RT7 N N13 * type 1 ext. 16 RT5 RT5 N N14 * type 1 ext. 16 RT5 RT5 N N15 * type 1 ext. 23 RT5 RT7
Table 13: Router RT4's routing table
in the presence of areas.
Table 13: Router RT4's routing table in the presence of areas.
Router RT4's routing table would improve (i.e., some of the paths in the routing table would become shorter) if an additional virtual link were configured between Router RT4 and Router RT3. The new virtual link would itself be associated with the first entry for area border router RT3 in Table 13 (an intra-area path through Area 1). This would yield a cost of 1 for the virtual link. The routing table entries changes that would be caused by the addition of this virtual
Router RT4's routing table would improve (i.e., some of the paths in the routing table would become shorter) if an additional virtual link were configured between Router RT4 and Router RT3. The new virtual link would itself be associated with the first entry for area border router RT3 in Table 13 (an intra-area path through Area 1). This would yield a cost of 1 for the virtual link. The routing table entries changes that would be caused by the addition of this virtual
Moy Standards Track [Page 99] RFC 2178 OSPF Version 2 July 1997
Moy Standards Track [Page 99] RFC 2178 OSPF Version 2 July 1997
link are shown in Table 14.
link are shown in Table 14.
12. Link State Advertisements (LSAs)
12. Link State Advertisements (LSAs)
Each router in the Autonomous System originates one or more link state advertisements (LSAs). This memo defines five distinct types of LSAs, which are described in Section 4.3. The collection of LSAs forms the link-state database. Each separate type of LSA has a separate function. Router-LSAs and network-LSAs describe how an area's routers and networks are interconnected. Summary-LSAs provide a way of condensing an area's routing information. AS-external-LSAs provide a way of transparently advertising externally-derived routing information throughout the Autonomous System.
Each router in the Autonomous System originates one or more link state advertisements (LSAs). This memo defines five distinct types of LSAs, which are described in Section 4.3. The collection of LSAs forms the link-state database. Each separate type of LSA has a separate function. Router-LSAs and network-LSAs describe how an area's routers and networks are interconnected. Summary-LSAs provide a way of condensing an area's routing information. AS-external-LSAs provide a way of transparently advertising externally-derived routing information throughout the Autonomous System.
Each LSA begins with a standard 20-byte header. This LSA header is discussed below.
Each LSA begins with a standard 20-byte header. This LSA header is discussed below.
Type Dest Area Path Type Cost Next Adv.
Hop(s) Router(s)
________________________________________________________________
N Ib 0 intra-area 16 RT3 *
N Ia 0 intra-area 21 RT3 *
R RT3 0 intra-area 1 * *
R RT10 0 intra-area 16 RT3 *
R RT11 0 intra-area 19 RT3 *
________________________________________________________________
N N9-N11,H1 0 inter-area 30 RT3 RT11
Type Dest Area Path Type Cost Next Adv. Hop(s) Router(s) ________________________________________________________________ N Ib 0 intra-area 16 RT3 * N Ia 0 intra-area 21 RT3 * R RT3 0 intra-area 1 * * R RT10 0 intra-area 16 RT3 * R RT11 0 intra-area 19 RT3 * ________________________________________________________________ N N9-N11,H1 0 inter-area 30 RT3 RT11
Table 14: Changes resulting from an
additional virtual link.
Table 14: Changes resulting from an additional virtual link.
12.1. The LSA Header
12.1. The LSA Header
The LSA header contains the LS type, Link State ID and Advertising Router fields. The combination of these three fields uniquely identifies the LSA.
The LSA header contains the LS type, Link State ID and Advertising Router fields. The combination of these three fields uniquely identifies the LSA.
There may be several instances of an LSA present in the Autonomous System, all at the same time. It must then be determined which instance is more recent. This determination is made by examining the LS sequence, LS checksum and LS age fields. These fields are also contained in the 20-byte LSA header.
There may be several instances of an LSA present in the Autonomous System, all at the same time. It must then be determined which instance is more recent. This determination is made by examining the LS sequence, LS checksum and LS age fields. These fields are also contained in the 20-byte LSA header.
Several of the OSPF packet types list LSAs. When the instance is not important, an LSA is referred to by its LS type, Link State ID and Advertising Router (see Link State Request Packets). Otherwise, the LS sequence number, LS age and LS checksum fields must also be
Several of the OSPF packet types list LSAs. When the instance is not important, an LSA is referred to by its LS type, Link State ID and Advertising Router (see Link State Request Packets). Otherwise, the LS sequence number, LS age and LS checksum fields must also be
Moy Standards Track [Page 100] RFC 2178 OSPF Version 2 July 1997
Moy Standards Track [Page 100] RFC 2178 OSPF Version 2 July 1997
referenced.
referenced.
A detailed explanation of the fields contained in the LSA header follows.
A detailed explanation of the fields contained in the LSA header follows.
12.1.1. LS age
12.1.1. LS age
This field is the age of the LSA in seconds. It should be processed as an unsigned 16-bit integer. It is set to 0 when the LSA is originated. It must be incremented by InfTransDelay on every hop of the flooding procedure. LSAs are also aged as they are held in each router's database.
This field is the age of the LSA in seconds. It should be processed as an unsigned 16-bit integer. It is set to 0 when the LSA is originated. It must be incremented by InfTransDelay on every hop of the flooding procedure. LSAs are also aged as they are held in each router's database.
The age of an LSA is never incremented past MaxAge. LSAs having age MaxAge are not used in the routing table calculation. When an LSA's age first reaches MaxAge, it is reflooded. An LSA of age MaxAge is finally flushed from the database when it is no longer needed to ensure database synchronization. For more information on the aging of LSAs, consult Section 14.
The age of an LSA is never incremented past MaxAge. LSAs having age MaxAge are not used in the routing table calculation. When an LSA's age first reaches MaxAge, it is reflooded. An LSA of age MaxAge is finally flushed from the database when it is no longer needed to ensure database synchronization. For more information on the aging of LSAs, consult Section 14.
The LS age field is examined when a router receives two instances of an LSA, both having identical LS sequence numbers and LS checksums. An instance of age MaxAge is then always accepted as most recent; this allows old LSAs to be flushed quickly from the routing domain. Otherwise, if the ages differ by more than MaxAgeDiff, the instance having the smaller age is accepted as most recent.[12] See Section 13.1 for more details.
The LS age field is examined when a router receives two instances of an LSA, both having identical LS sequence numbers and LS checksums. An instance of age MaxAge is then always accepted as most recent; this allows old LSAs to be flushed quickly from the routing domain. Otherwise, if the ages differ by more than MaxAgeDiff, the instance having the smaller age is accepted as most recent.[12] See Section 13.1 for more details.
12.1.2. Options
12.1.2. Options
The Options field in the LSA header indicates which optional capabilities are associated with the LSA. OSPF's optional capabilities are described in Section 4.5. One optional capability is defined by this specification, represented by the E-bit found in the Options field. The unrecognized bits in the Options field should be set to zero. The E-bit represents OSPF's ExternalRoutingCapability. This bit should be set in all LSAs associated with the backbone, and all LSAs associated with non-stub areas (see Section 3.6). It should also be set in all AS-external-LSAs. It should be reset in all router-LSAs, network-LSAs and summary-LSAs associated with a stub area. For all LSAs, the setting of the E-bit is for informational purposes only; it does not affect the routing table calculation.
The Options field in the LSA header indicates which optional capabilities are associated with the LSA. OSPF's optional capabilities are described in Section 4.5. One optional capability is defined by this specification, represented by the E-bit found in the Options field. The unrecognized bits in the Options field should be set to zero. The E-bit represents OSPF's ExternalRoutingCapability. This bit should be set in all LSAs associated with the backbone, and all LSAs associated with non-stub areas (see Section 3.6). It should also be set in all AS-external-LSAs. It should be reset in all router-LSAs, network-LSAs and summary-LSAs associated with a stub area. For all LSAs, the setting of the E-bit is for informational purposes only; it does not affect the routing table calculation.
Moy Standards Track [Page 101] RFC 2178 OSPF Version 2 July 1997
Moy Standards Track [Page 101] RFC 2178 OSPF Version 2 July 1997
12.1.3. LS type
12.1.3. LS type
The LS type field dictates the format and function of the LSA. LSAs of different types have different names (e.g., router-LSAs or network-LSAs). All LSA types defined by this memo, except the AS- external-LSAs (LS type = 5), are flooded throughout a single area only. AS-external-LSAs are flooded throughout the entire Autonomous System, excepting stub areas (see Section 3.6). Each separate LSA type is briefly described below in Table 15.
The LS type field dictates the format and function of the LSA. LSAs of different types have different names (e.g., router-LSAs or network-LSAs). All LSA types defined by this memo, except the AS- external-LSAs (LS type = 5), are flooded throughout a single area only. AS-external-LSAs are flooded throughout the entire Autonomous System, excepting stub areas (see Section 3.6). Each separate LSA type is briefly described below in Table 15.
12.1.4. Link State ID
12.1.4. Link State ID
This field identifies the piece of the routing domain that is being described by the LSA. Depending on the LSA's LS type, the Link State ID takes on the values listed in Table 16.
This field identifies the piece of the routing domain that is being described by the LSA. Depending on the LSA's LS type, the Link State ID takes on the values listed in Table 16.
Actually, for Type 3 summary-LSAs (LS type = 3) and AS-external-LSAs (LS type = 5), the Link State ID may additionally have one or more of the destination network's "host" bits set. For example, when originating an AS-external-LSA for the network 10.0.0.0 with mask of 255.0.0.0, the Link State ID can be set to anything in the range 10.0.0.0 through 10.255.255.255 inclusive (although 10.0.0.0 should be used whenever possible). The freedom to set certain host bits allows a router to originate separate LSAs for two networks having the same address but different masks. See Appendix E for details.
Actually, for Type 3 summary-LSAs (LS type = 3) and AS-external-LSAs (LS type = 5), the Link State ID may additionally have one or more of the destination network's "host" bits set. For example, when originating an AS-external-LSA for the network 10.0.0.0 with mask of 255.0.0.0, the Link State ID can be set to anything in the range 10.0.0.0 through 10.255.255.255 inclusive (although 10.0.0.0 should be used whenever possible). The freedom to set certain host bits allows a router to originate separate LSAs for two networks having the same address but different masks. See Appendix E for details.
Moy Standards Track [Page 102] RFC 2178 OSPF Version 2 July 1997
Moy Standards Track [Page 102] RFC 2178 OSPF Version 2 July 1997
LS Type LSA description
________________________________________________
1 These are the router-LSAs.
They describe the collected
states of the router's
interfaces. For more information,
consult Section 12.4.1.
________________________________________________
2 These are the network-LSAs.
They describe the set of routers
attached to the network. For
more information, consult
Section 12.4.2.
________________________________________________
3 or 4 These are the summary-LSAs.
They describe inter-area routes,
and enable the condensation of
routing information at area
borders. Originated by area border
routers, the Type 3 summary-LSAs
describe routes to networks while the
Type 4 summary-LSAs describe routes to
AS boundary routers.
________________________________________________
5 These are the AS-external-LSAs.
Originated by AS boundary routers,
they describe routes
to destinations external to the
Autonomous System. A default route for
the Autonomous System can also be
described by an AS-external-LSA.
LS Type LSA description ________________________________________________ 1 These are the router-LSAs. They describe the collected states of the router's interfaces. For more information, consult Section 12.4.1. ________________________________________________ 2 These are the network-LSAs. They describe the set of routers attached to the network. For more information, consult Section 12.4.2. ________________________________________________ 3 or 4 These are the summary-LSAs. They describe inter-area routes, and enable the condensation of routing information at area borders. Originated by area border routers, the Type 3 summary-LSAs describe routes to networks while the Type 4 summary-LSAs describe routes to AS boundary routers. ________________________________________________ 5 These are the AS-external-LSAs. Originated by AS boundary routers, they describe routes to destinations external to the Autonomous System. A default route for the Autonomous System can also be described by an AS-external-LSA.
Table 15: OSPF link state advertisements (LSAs).
Table 15: OSPF link state advertisements (LSAs).
LS Type Link State ID
_______________________________________________
1 The originating router's Router ID.
2 The IP interface address of the
network's Designated Router.
3 The destination network's IP address.
4 The Router ID of the described AS
boundary router.
5 The destination network's IP address.
LS Type Link State ID _______________________________________________ 1 The originating router's Router ID. 2 The IP interface address of the network's Designated Router. 3 The destination network's IP address. 4 The Router ID of the described AS boundary router. 5 The destination network's IP address.
Table 16: The LSA's Link State ID.
Table 16: The LSA's Link State ID.
Moy Standards Track [Page 103] RFC 2178 OSPF Version 2 July 1997
Moy Standards Track [Page 103] RFC 2178 OSPF Version 2 July 1997
When the LSA is describing a network (LS type = 2, 3 or 5), the network's IP address is easily derived by masking the Link State ID with the network/subnet mask contained in the body of the LSA. When the LSA is describing a router (LS type = 1 or 4), the Link State ID is always the described router's OSPF Router ID.
When the LSA is describing a network (LS type = 2, 3 or 5), the network's IP address is easily derived by masking the Link State ID with the network/subnet mask contained in the body of the LSA. When the LSA is describing a router (LS type = 1 or 4), the Link State ID is always the described router's OSPF Router ID.
When an AS-external-LSA (LS Type = 5) is describing a default route, its Link State ID is set to DefaultDestination (0.0.0.0).
When an AS-external-LSA (LS Type = 5) is describing a default route, its Link State ID is set to DefaultDestination (0.0.0.0).
12.1.5. Advertising Router
12.1.5. Advertising Router
This field specifies the OSPF Router ID of the LSA's originator. For router-LSAs, this field is identical to the Link State ID field. Network-LSAs are originated by the network's Designated Router. Summary-LSAs originated by area border routers. AS-external-LSAs are originated by AS boundary routers.
This field specifies the OSPF Router ID of the LSA's originator. For router-LSAs, this field is identical to the Link State ID field. Network-LSAs are originated by the network's Designated Router. Summary-LSAs originated by area border routers. AS-external-LSAs are originated by AS boundary routers.
12.1.6. LS sequence number
12.1.6. LS sequence number
The sequence number field is a signed 32-bit integer. It is used to detect old and duplicate LSAs. The space of sequence numbers is linearly ordered. The larger the sequence number (when compared as signed 32-bit integers) the more recent the LSA. To describe to sequence number space more precisely, let N refer in the discussion below to the constant 2**31.
The sequence number field is a signed 32-bit integer. It is used to detect old and duplicate LSAs. The space of sequence numbers is linearly ordered. The larger the sequence number (when compared as signed 32-bit integers) the more recent the LSA. To describe to sequence number space more precisely, let N refer in the discussion below to the constant 2**31.
The sequence number -N (0x80000000) is reserved (and unused). This leaves -N + 1 (0x80000001) as the smallest (and therefore oldest) sequence number; this sequence number is referred to as the constant InitialSequenceNumber. A router uses InitialSequenceNumber the first time it originates any LSA. Afterwards, the LSA's sequence number is incremented each time the router originates a new instance of the LSA. When an attempt is made to increment the sequence number past the maximum value of N - 1 (0x7fffffff; also referred to as MaxSequenceNumber), the current instance of the LSA must first be flushed from the routing domain. This is done by prematurely aging the LSA (see Section 14.1) and reflooding it. As soon as this flood has been acknowledged by all adjacent neighbors, a new instance can be originated with sequence number of InitialSequenceNumber.
The sequence number -N (0x80000000) is reserved (and unused). This leaves -N + 1 (0x80000001) as the smallest (and therefore oldest) sequence number; this sequence number is referred to as the constant InitialSequenceNumber. A router uses InitialSequenceNumber the first time it originates any LSA. Afterwards, the LSA's sequence number is incremented each time the router originates a new instance of the LSA. When an attempt is made to increment the sequence number past the maximum value of N - 1 (0x7fffffff; also referred to as MaxSequenceNumber), the current instance of the LSA must first be flushed from the routing domain. This is done by prematurely aging the LSA (see Section 14.1) and reflooding it. As soon as this flood has been acknowledged by all adjacent neighbors, a new instance can be originated with sequence number of InitialSequenceNumber.
The router may be forced to promote the sequence number of one of its LSAs when a more recent instance of the LSA is unexpectedly received during the flooding process. This should be a rare event. This may indicate that an out-of-date LSA, originated by the router itself before its last restart/reload, still exists in the Autonomous System. For more information see Section 13.4.
The router may be forced to promote the sequence number of one of its LSAs when a more recent instance of the LSA is unexpectedly received during the flooding process. This should be a rare event. This may indicate that an out-of-date LSA, originated by the router itself before its last restart/reload, still exists in the Autonomous System. For more information see Section 13.4.
Moy Standards Track [Page 104] RFC 2178 OSPF Version 2 July 1997
Moy Standards Track [Page 104] RFC 2178 OSPF Version 2 July 1997
12.1.7. LS checksum
12.1.7. LS checksum
This field is the checksum of the complete contents of the LSA, excepting the LS age field. The LS age field is excepted so that an LSA's age can be incremented without updating the checksum. The checksum used is the same that is used for ISO connectionless datagrams; it is commonly referred to as the Fletcher checksum. It is documented in Annex B of [Ref6]. The LSA header also contains the length of the LSA in bytes; subtracting the size of the LS age field (two bytes) yields the amount of data to checksum.
This field is the checksum of the complete contents of the LSA, excepting the LS age field. The LS age field is excepted so that an LSA's age can be incremented without updating the checksum. The checksum used is the same that is used for ISO connectionless datagrams; it is commonly referred to as the Fletcher checksum. It is documented in Annex B of [Ref6]. The LSA header also contains the length of the LSA in bytes; subtracting the size of the LS age field (two bytes) yields the amount of data to checksum.
The checksum is used to detect data corruption of an LSA. This corruption can occur while an LSA is being flooded, or while it is being held in a router's memory. The LS checksum field cannot take on the value of zero; the occurrence of such a value should be considered a checksum failure. In other words, calculation of the checksum is not optional.
The checksum is used to detect data corruption of an LSA. This corruption can occur while an LSA is being flooded, or while it is being held in a router's memory. The LS checksum field cannot take on the value of zero; the occurrence of such a value should be considered a checksum failure. In other words, calculation of the checksum is not optional.
The checksum of an LSA is verified in two cases: a) when it is received in a Link State Update Packet and b) at times during the aging of the link state database. The detection of a checksum failure leads to separate actions in each case. See Sections 13 and 14 for more details.
The checksum of an LSA is verified in two cases: a) when it is received in a Link State Update Packet and b) at times during the aging of the link state database. The detection of a checksum failure leads to separate actions in each case. See Sections 13 and 14 for more details.
Whenever the LS sequence number field indicates that two instances of an LSA are the same, the LS checksum field is examined. If there is a difference, the instance with the larger LS checksum is considered to be most recent.[13] See Section 13.1 for more details.
Whenever the LS sequence number field indicates that two instances of an LSA are the same, the LS checksum field is examined. If there is a difference, the instance with the larger LS checksum is considered to be most recent.[13] See Section 13.1 for more details.
12.2. The link state database
12.2. The link state database
A router has a separate link state database for every area to which it belongs. All routers belonging to the same area have identical link state databases for the area.
A router has a separate link state database for every area to which it belongs. All routers belonging to the same area have identical link state databases for the area.
The databases for each individual area are always dealt with separately. The shortest path calculation is performed separately for each area (see Section 16). Components of the area link-state database are flooded throughout the area only. Finally, when an adjacency (belonging to Area A) is being brought up, only the database for Area A is synchronized between the two routers.
The databases for each individual area are always dealt with separately. The shortest path calculation is performed separately for each area (see Section 16). Components of the area link-state database are flooded throughout the area only. Finally, when an adjacency (belonging to Area A) is being brought up, only the database for Area A is synchronized between the two routers.
The area database is composed of router-LSAs, network-LSAs and summary-LSAs (all listed in the area data structure). In addition, external routes (AS-external-LSAs) are included in all non-stub area databases (see Section 3.6).
The area database is composed of router-LSAs, network-LSAs and summary-LSAs (all listed in the area data structure). In addition, external routes (AS-external-LSAs) are included in all non-stub area databases (see Section 3.6).
Moy Standards Track [Page 105] RFC 2178 OSPF Version 2 July 1997
Moy Standards Track [Page 105] RFC 2178 OSPF Version 2 July 1997
An implementation of OSPF must be able to access individual pieces of an area database. This lookup function is based on an LSA's LS type, Link State ID and Advertising Router.[14] There will be a single instance (the most up-to-date) of each LSA in the database. The database lookup function is invoked during the LSA flooding procedure (Section 13) and the routing table calculation (Section 16). In addition, using this lookup function the router can determine whether it has itself ever originated a particular LSA, and if so, with what LS sequence number.
An implementation of OSPF must be able to access individual pieces of an area database. This lookup function is based on an LSA's LS type, Link State ID and Advertising Router.[14] There will be a single instance (the most up-to-date) of each LSA in the database. The database lookup function is invoked during the LSA flooding procedure (Section 13) and the routing table calculation (Section 16). In addition, using this lookup function the router can determine whether it has itself ever originated a particular LSA, and if so, with what LS sequence number.
An LSA is added to a router's database when either a) it is received during the flooding process (Section 13) or b) it is originated by the router itself (Section 12.4). An LSA is deleted from a router's database when either a) it has been overwritten by a newer instance during the flooding process (Section 13) or b) the router originates a newer instance of one of its self-originated LSAs (Section 12.4) or c) the LSA ages out and is flushed from the routing domain (Section 14).
An LSA is added to a router's database when either a) it is received during the flooding process (Section 13) or b) it is originated by the router itself (Section 12.4). An LSA is deleted from a router's database when either a) it has been overwritten by a newer instance during the flooding process (Section 13) or b) the router originates a newer instance of one of its self-originated LSAs (Section 12.4) or c) the LSA ages out and is flushed from the routing domain (Section 14).
Whenever an LSA is deleted from the database it must also be removed from all neighbors' Link state retransmission lists (see Section 10).
Whenever an LSA is deleted from the database it must also be removed from all neighbors' Link state retransmission lists (see Section 10).
12.3. Representation of TOS
12.3. Representation of TOS
For backward compatibility with previous versions of the OSPF specification ([Ref9]), TOS-specific information can be included in router-LSAs, summary-LSAs and AS-external-LSAs. The encoding of TOS in OSPF LSAs is specified in Table 17. That table relates the OSPF encoding to the IP packet header's TOS field (defined in [Ref12]). The OSPF encoding is expressed as a decimal integer, and the IP packet header's TOS field is expressed in the binary TOS values used in [Ref12].
For backward compatibility with previous versions of the OSPF specification ([Ref9]), TOS-specific information can be included in router-LSAs, summary-LSAs and AS-external-LSAs. The encoding of TOS in OSPF LSAs is specified in Table 17. That table relates the OSPF encoding to the IP packet header's TOS field (defined in [Ref12]). The OSPF encoding is expressed as a decimal integer, and the IP packet header's TOS field is expressed in the binary TOS values used in [Ref12].
Moy Standards Track [Page 106] RFC 2178 OSPF Version 2 July 1997
Moy Standards Track [Page 106] RFC 2178 OSPF Version 2 July 1997
OSPF encoding RFC 1349 TOS values
___________________________________________
0 0000 normal service
2 0001 minimize monetary cost
4 0010 maximize reliability
6 0011
8 0100 maximize throughput
10 0101
12 0110
14 0111
16 1000 minimize delay
18 1001
20 1010
22 1011
24 1100
26 1101
28 1110
30 1111
OSPF encoding RFC 1349 TOS values ___________________________________________ 0 0000 normal service 2 0001 minimize monetary cost 4 0010 maximize reliability 6 0011 8 0100 maximize throughput 10 0101 12 0110 14 0111 16 1000 minimize delay 18 1001 20 1010 22 1011 24 1100 26 1101 28 1110 30 1111
Table 17: Representing TOS in OSPF.
Table 17: Representing TOS in OSPF.
12.4. Originating LSAs
12.4. Originating LSAs
Into any given OSPF area, a router will originate several LSAs. Each router originates a router-LSA. If the router is also the Designated Router for any of the area's networks, it will originate network-LSAs for those networks.
Into any given OSPF area, a router will originate several LSAs. Each router originates a router-LSA. If the router is also the Designated Router for any of the area's networks, it will originate network-LSAs for those networks.
Area border routers originate a single summary-LSA for each known inter-area destination. AS boundary routers originate a single AS- external-LSA for each known AS external destination. Destinations are advertised one at a time so that the change in any single route can be flooded without reflooding the entire collection of routes. During the flooding procedure, many LSAs can be carried by a single Link State Update packet.
Area border routers originate a single summary-LSA for each known inter-area destination. AS boundary routers originate a single AS- external-LSA for each known AS external destination. Destinations are advertised one at a time so that the change in any single route can be flooded without reflooding the entire collection of routes. During the flooding procedure, many LSAs can be carried by a single Link State Update packet.
As an example, consider Router RT4 in Figure 6. It is an area border router, having a connection to Area 1 and the backbone. Router RT4 originates 5 distinct LSAs into the backbone (one router-LSA, and one summary-LSA for each of the networks N1-N4). Router RT4 will also originate 8 distinct LSAs into Area 1 (one router-LSA and seven summary-LSAs as pictured in Figure 7). If RT4 has been selected as Designated Router for Network N3, it will also originate a network- LSA for N3 into Area 1.
As an example, consider Router RT4 in Figure 6. It is an area border router, having a connection to Area 1 and the backbone. Router RT4 originates 5 distinct LSAs into the backbone (one router-LSA, and one summary-LSA for each of the networks N1-N4). Router RT4 will also originate 8 distinct LSAs into Area 1 (one router-LSA and seven summary-LSAs as pictured in Figure 7). If RT4 has been selected as Designated Router for Network N3, it will also originate a network- LSA for N3 into Area 1.
In this same figure, Router RT5 will be originating 3 distinct AS- external-LSAs (one for each of the networks N12-N14). These will be flooded throughout the entire AS, assuming that none of the areas
In this same figure, Router RT5 will be originating 3 distinct AS- external-LSAs (one for each of the networks N12-N14). These will be flooded throughout the entire AS, assuming that none of the areas
Moy Standards Track [Page 107] RFC 2178 OSPF Version 2 July 1997
Moy Standards Track [Page 107] RFC 2178 OSPF Version 2 July 1997
have been configured as stubs. However, if area 3 has been configured as a stub area, the AS-external-LSAs for networks N12-N14 will not be flooded into area 3 (see Section 3.6). Instead, Router RT11 would originate a default summary- LSA that would be flooded throughout area 3 (see Section 12.4.3). This instructs all of area 3's internal routers to send their AS external traffic to RT11.
have been configured as stubs. However, if area 3 has been configured as a stub area, the AS-external-LSAs for networks N12-N14 will not be flooded into area 3 (see Section 3.6). Instead, Router RT11 would originate a default summary- LSA that would be flooded throughout area 3 (see Section 12.4.3). This instructs all of area 3's internal routers to send their AS external traffic to RT11.
Whenever a new instance of an LSA is originated, its LS sequence number is incremented, its LS age is set to 0, its LS checksum is calculated, and the LSA is added to the link state database and flooded out the appropriate interfaces. See Section 13.2 for details concerning the installation of the LSA into the link state database. See Section 13.3 for details concerning the flooding of newly originated LSAs.
Whenever a new instance of an LSA is originated, its LS sequence number is incremented, its LS age is set to 0, its LS checksum is calculated, and the LSA is added to the link state database and flooded out the appropriate interfaces. See Section 13.2 for details concerning the installation of the LSA into the link state database. See Section 13.3 for details concerning the flooding of newly originated LSAs.
The ten events that can cause a new instance of an LSA to be originated are:
The ten events that can cause a new instance of an LSA to be originated are:
(1) The LS age field of one of the router's self-originated LSAs
reaches the value LSRefreshTime. In this case, a new
instance of the LSA is originated, even though the contents
of the LSA (apart from the LSA header) will be the same.
This guarantees periodic originations of all LSAs. This
periodic updating of LSAs adds robustness to the link state
algorithm. LSAs that solely describe unreachable
destinations should not be refreshed, but should instead be
flushed from the routing domain (see Section 14.1).
(1) The LS age field of one of the router's self-originated LSAs reaches the value LSRefreshTime. In this case, a new instance of the LSA is originated, even though the contents of the LSA (apart from the LSA header) will be the same. This guarantees periodic originations of all LSAs. This periodic updating of LSAs adds robustness to the link state algorithm. LSAs that solely describe unreachable destinations should not be refreshed, but should instead be flushed from the routing domain (see Section 14.1).
When whatever is being described by an LSA changes, a new LSA is originated. However, two instances of the same LSA may not be originated within the time period MinLSInterval. This may require that the generation of the next instance be delayed by up to MinLSInterval. The following events may cause the contents of an LSA to change. These events should cause new originations if and only if the contents of the new LSA would be different:
When whatever is being described by an LSA changes, a new LSA is originated. However, two instances of the same LSA may not be originated within the time period MinLSInterval. This may require that the generation of the next instance be delayed by up to MinLSInterval. The following events may cause the contents of an LSA to change. These events should cause new originations if and only if the contents of the new LSA would be different:
(2) An interface's state changes (see Section 9.1). This may
mean that it is necessary to produce a new instance of the
router-LSA.
(2) An interface's state changes (see Section 9.1). This may mean that it is necessary to produce a new instance of the router-LSA.
(3) An attached network's Designated Router changes. A new
router-LSA should be originated. Also, if the router itself
is now the Designated Router, a new network-LSA should be
produced. If the router itself is no longer the Designated
Router, any network-LSA that it might have originated for
the network should be flushed from the routing domain (see
Section 14.1).
(3) An attached network's Designated Router changes. A new router-LSA should be originated. Also, if the router itself is now the Designated Router, a new network-LSA should be produced. If the router itself is no longer the Designated Router, any network-LSA that it might have originated for the network should be flushed from the routing domain (see Section 14.1).
Moy Standards Track [Page 108] RFC 2178 OSPF Version 2 July 1997
Moy Standards Track [Page 108] RFC 2178 OSPF Version 2 July 1997
(4) One of the neighboring routers changes to/from the FULL
state. This may mean that it is necessary to produce a new
instance of the router-LSA. Also, if the router is itself
the Designated Router for the attached network, a new
network-LSA should be produced.
(4) One of the neighboring routers changes to/from the FULL state. This may mean that it is necessary to produce a new instance of the router-LSA. Also, if the router is itself the Designated Router for the attached network, a new network-LSA should be produced.
The next four events concern area border routers only:
The next four events concern area border routers only:
(5) An intra-area route has been added/deleted/modified in the
routing table. This may cause a new instance of a summary-
LSA (for this route) to be originated in each attached area
(possibly including the backbone).
(5) An intra-area route has been added/deleted/modified in the routing table. This may cause a new instance of a summary- LSA (for this route) to be originated in each attached area (possibly including the backbone).
(6) An inter-area route has been added/deleted/modified in the
routing table. This may cause a new instance of a summary-
LSA (for this route) to be originated in each attached area
(but NEVER for the backbone).
(6) An inter-area route has been added/deleted/modified in the routing table. This may cause a new instance of a summary- LSA (for this route) to be originated in each attached area (but NEVER for the backbone).
(7) The router becomes newly attached to an area. The router
must then originate summary-LSAs into the newly attached
area for all pertinent intra-area and inter-area routes in
the router's routing table. See Section 12.4.3 for more
details.
(7) The router becomes newly attached to an area. The router must then originate summary-LSAs into the newly attached area for all pertinent intra-area and inter-area routes in the router's routing table. See Section 12.4.3 for more details.
(8) When the state of one of the router's configured virtual
links changes, it may be necessary to originate a new
router-LSA into the virtual link's Transit area (see the
discussion of the router-LSA's bit V in Section 12.4.1), as
well as originating a new router-LSA into the backbone.
(8) When the state of one of the router's configured virtual links changes, it may be necessary to originate a new router-LSA into the virtual link's Transit area (see the discussion of the router-LSA's bit V in Section 12.4.1), as well as originating a new router-LSA into the backbone.
The last two events concern AS boundary routers (and former AS boundary routers) only:
The last two events concern AS boundary routers (and former AS boundary routers) only:
(9) An external route gained through direct experience with an
external routing protocol (like BGP) changes. This will
cause an AS boundary router to originate a new instance of
an AS-external-LSA.
(9) An external route gained through direct experience with an external routing protocol (like BGP) changes. This will cause an AS boundary router to originate a new instance of an AS-external-LSA.
(10)
A router ceases to be an AS boundary router, perhaps after
restarting. In this situation the router should flush all
AS-external-LSAs that it had previously originated. These
LSAs can be flushed via the premature aging procedure
specified in Section 14.1.
(10) A router ceases to be an AS boundary router, perhaps after restarting. In this situation the router should flush all AS-external-LSAs that it had previously originated. These LSAs can be flushed via the premature aging procedure specified in Section 14.1.
Moy Standards Track [Page 109] RFC 2178 OSPF Version 2 July 1997
Moy Standards Track [Page 109] RFC 2178 OSPF Version 2 July 1997
The construction of each type of LSA is explained in detail below. In general, these sections describe the contents of the LSA body (i.e., the part coming after the 20-byte LSA header). For information concerning the building of the LSA header, see Section 12.1.
The construction of each type of LSA is explained in detail below. In general, these sections describe the contents of the LSA body (i.e., the part coming after the 20-byte LSA header). For information concerning the building of the LSA header, see Section 12.1.
12.4.1. Router-LSAs
12.4.1. Router-LSAs
A router originates a router-LSA for each area that it belongs to. Such an LSA describes the collected states of the router's links to the area. The LSA is flooded throughout the particular area, and no further. The format of a router-LSA is shown in Appendix A (Section A.4.2). The first 20 bytes of the LSA consist of the generic LSA header that was discussed in Section 12.1. router-LSAs have LS type = 1.
A router originates a router-LSA for each area that it belongs to. Such an LSA describes the collected states of the router's links to the area. The LSA is flooded throughout the particular area, and no further. The format of a router-LSA is shown in Appendix A (Section A.4.2). The first 20 bytes of the LSA consist of the generic LSA header that was discussed in Section 12.1. router-LSAs have LS type = 1.
A router also indicates whether it is an area border router, or an AS boundary router, by setting the appropriate bits
A router also indicates whether it is an area border router, or an AS boundary router, by setting the appropriate bits
....................................
. 192.1.2 Area 1 .
. + .
. | .
. | 3+---+1 .
. N1 |--|RT1|-----+ .
. | +---+ \ .
. | \ _______N3 .
. + \/ \ . 1+---+
. * 192.1.1 *------|RT4|
. + /\_______/ . +---+
. | / | .
. | 3+---+1 / | .
. N2 |--|RT2|-----+ 1| .
. | +---+ +---+8 . 6+---+
. | |RT3|----------------|RT6|
. + +---+ . +---+
. 192.1.3 |2 . 18.10.0.6|7
. | . |
. +------------+ .
. 192.1.4 (N4) .
....................................
.................................... . 192.1.2 Area 1 . . + . . | . . | 3+---+1 . . N1 |--|RT1|-----+ . . | +---+ \ . . | \ _______N3 . . + \/ \ . 1+---+ . * 192.1.1 *------|RT4| . + /\_______/ . +---+ . | / | . . | 3+---+1 / | . . N2 |--|RT2|-----+ 1| . . | +---+ +---+8 . 6+---+ . | |RT3|----------------|RT6| . + +---+ . +---+ . 192.1.3 |2 . 18.10.0.6|7 . | . | . +------------+ . . 192.1.4 (N4) . ....................................
Figure 15: Area 1 with IP addresses shown
Figure 15: Area 1 with IP addresses shown
(bit B and bit E, respectively) in its router-LSAs. This enables paths to those types of routers to be saved in the routing table, for later processing of summary-LSAs and AS-external-LSAs. Bit B should be set whenever the router is actively attached to two or more areas, even if the router is not currently attached to the OSPF backbone
(bit B and bit E, respectively) in its router-LSAs. This enables paths to those types of routers to be saved in the routing table, for later processing of summary-LSAs and AS-external-LSAs. Bit B should be set whenever the router is actively attached to two or more areas, even if the router is not currently attached to the OSPF backbone
Moy Standards Track [Page 110] RFC 2178 OSPF Version 2 July 1997
Moy Standards Track [Page 110] RFC 2178 OSPF Version 2 July 1997
area. Bit E should never be set in a router-LSA for a stub area (stub areas cannot contain AS boundary routers).
area. Bit E should never be set in a router-LSA for a stub area (stub areas cannot contain AS boundary routers).
In addition, the router sets bit V in its router-LSA for Area A if and only if the router is the endpoint of one or more fully adjacent virtual links having Area A as their Transit area. The setting of bit V enables other routers in Area A to discover whether the area supports transit traffic (see TransitCapability in Section 6).
In addition, the router sets bit V in its router-LSA for Area A if and only if the router is the endpoint of one or more fully adjacent virtual links having Area A as their Transit area. The setting of bit V enables other routers in Area A to discover whether the area supports transit traffic (see TransitCapability in Section 6).
The router-LSA then describes the router's working connections (i.e., interfaces or links) to the area. Each link is typed according to the kind of attached network. Each link is also labelled with its Link ID. This Link ID gives a name to the entity that is on the other end of the link. Table 18 summarizes the values used for the Type and Link ID fields.
The router-LSA then describes the router's working connections (i.e., interfaces or links) to the area. Each link is typed according to the kind of attached network. Each link is also labelled with its Link ID. This Link ID gives a name to the entity that is on the other end of the link. Table 18 summarizes the values used for the Type and Link ID fields.
Link type Description Link ID
__________________________________________________
1 Point-to-point Neighbor Router ID
link
2 Link to transit Interface address of
network Designated Router
3 Link to stub IP network number
network
4 Virtual link Neighbor Router ID
Link type Description Link ID __________________________________________________ 1 Point-to-point Neighbor Router ID link 2 Link to transit Interface address of network Designated Router 3 Link to stub IP network number network 4 Virtual link Neighbor Router ID
Table 18: Link descriptions in the
router-LSA.
Table 18: Link descriptions in the router-LSA.
In addition, the Link Data field is specified for each link. This field gives 32 bits of extra information for the link. For links to transit networks, numbered point-to-point links and virtual links, this field specifies the IP interface address of the associated router interface (this is needed by the routing table calculation, see Section 16.1.1). For links to stub networks, this field specifies the stub network's IP address mask. For unnumbered point- to-point links, the Link Data field should be set to the unnumbered interface's MIB-II [Ref8] ifIndex value.
In addition, the Link Data field is specified for each link. This field gives 32 bits of extra information for the link. For links to transit networks, numbered point-to-point links and virtual links, this field specifies the IP interface address of the associated router interface (this is needed by the routing table calculation, see Section 16.1.1). For links to stub networks, this field specifies the stub network's IP address mask. For unnumbered point- to-point links, the Link Data field should be set to the unnumbered interface's MIB-II [Ref8] ifIndex value.
Finally, the cost of using the link for output is specified. The output cost of a link is configurable. With the exception of links to stub networks, the output cost must always be non-zero.
Finally, the cost of using the link for output is specified. The output cost of a link is configurable. With the exception of links to stub networks, the output cost must always be non-zero.
To further describe the process of building the list of link descriptions, suppose a router wishes to build a router-LSA for Area A. The router examines its collection of interface data structures. For each interface, the following steps are taken:
To further describe the process of building the list of link descriptions, suppose a router wishes to build a router-LSA for Area A. The router examines its collection of interface data structures. For each interface, the following steps are taken:
Moy Standards Track [Page 111] RFC 2178 OSPF Version 2 July 1997
Moy Standards Track [Page 111] RFC 2178 OSPF Version 2 July 1997
o If the attached network does not belong to Area A, no
links are added to the LSA, and the next interface should be
examined.
o If the attached network does not belong to Area A, no links are added to the LSA, and the next interface should be examined.
o If the state of the interface is Down, no links are added.
o If the state of the interface is Down, no links are added.
o If the state of the interface is Loopback, add a Type 3
link (stub network) as long as this is not an interface to an
unnumbered point-to-point network. The Link ID should be set to
the IP interface address, the Link Data set to the
mask 0xffffffff (indicating a host route), and the cost set to 0.
o If the state of the interface is Loopback, add a Type 3 link (stub network) as long as this is not an interface to an unnumbered point-to-point network. The Link ID should be set to the IP interface address, the Link Data set to the mask 0xffffffff (indicating a host route), and the cost set to 0.
o Otherwise, the link descriptions added to the router-LSA
depend on the OSPF interface type. Link descriptions used for
point-to-point interfaces are specified in Section 12.4.1.1, for
virtual links in Section 12.4.1.2, for broadcast and NBMA
interfaces in 12.4.1.3, and for Point-to-MultiPoint interfaces in
12.4.1.4.
o Otherwise, the link descriptions added to the router-LSA depend on the OSPF interface type. Link descriptions used for point-to-point interfaces are specified in Section 12.4.1.1, for virtual links in Section 12.4.1.2, for broadcast and NBMA interfaces in 12.4.1.3, and for Point-to-MultiPoint interfaces in 12.4.1.4.
After consideration of all the router interfaces, host links are added to the router-LSA by examining the list of attached hosts belonging to Area A. A host route is represented as a Type 3 link (stub network) whose Link ID is the host's IP address, Link Data is the mask of all ones (0xffffffff), and cost the host's configured cost (see Section C.7).
After consideration of all the router interfaces, host links are added to the router-LSA by examining the list of attached hosts belonging to Area A. A host route is represented as a Type 3 link (stub network) whose Link ID is the host's IP address, Link Data is the mask of all ones (0xffffffff), and cost the host's configured cost (see Section C.7).
12.4.1.1. Describing point-to-point interfaces
12.4.1.1. Describing point-to-point interfaces
For point-to-point interfaces, one or more link descriptions are added to the router-LSA as follows:
For point-to-point interfaces, one or more link descriptions are added to the router-LSA as follows:
o If the neighboring router is fully adjacent, add a
Type 1 link (point-to-point). The Link ID should be set to the
Router ID of the neighboring router. For numbered point-to-point
networks, the Link Data should specify the IP interface address.
For unnumbered point-to-point networks, the Link Data field
should specify the interface's MIB-II [Ref8] ifIndex value. The
cost should be set to the output cost of the point-to-point
interface.
o If the neighboring router is fully adjacent, add a Type 1 link (point-to-point). The Link ID should be set to the Router ID of the neighboring router. For numbered point-to-point networks, the Link Data should specify the IP interface address. For unnumbered point-to-point networks, the Link Data field should specify the interface's MIB-II [Ref8] ifIndex value. The cost should be set to the output cost of the point-to-point interface.
o In addition, as long as the state of the interface
is "Point-to-Point" (and regardless of the neighboring router
state), a Type 3 link (stub network) should be added. There are
two forms that this stub link can take:
o In addition, as long as the state of the interface is "Point-to-Point" (and regardless of the neighboring router state), a Type 3 link (stub network) should be added. There are two forms that this stub link can take:
Moy Standards Track [Page 112] RFC 2178 OSPF Version 2 July 1997
Moy Standards Track [Page 112] RFC 2178 OSPF Version 2 July 1997
Option 1
Assuming that the neighboring router's IP address is known, set
the Link ID of the Type 3 link to the neighbor's IP address, the
Link Data to the mask 0xffffffff (indicating a host route), and
the cost to the interface's configured output cost.[15]
Option 1 Assuming that the neighboring router's IP address is known, set the Link ID of the Type 3 link to the neighbor's IP address, the Link Data to the mask 0xffffffff (indicating a host route), and the cost to the interface's configured output cost.[15]
Option 2
If a subnet has been assigned to the point-to-point link, set the
Link ID of the Type 3 link to the subnet's IP address, the Link
Data to the subnet's mask, and the cost to the interface's
configured output cost.[16]
Option 2 If a subnet has been assigned to the point-to-point link, set the Link ID of the Type 3 link to the subnet's IP address, the Link Data to the subnet's mask, and the cost to the interface's configured output cost.[16]
12.4.1.2. Describing broadcast and NBMA interfaces
12.4.1.2. Describing broadcast and NBMA interfaces
For operational broadcast and NBMA interfaces, a single link description is added to the router-LSA as follows:
For operational broadcast and NBMA interfaces, a single link description is added to the router-LSA as follows:
o If the state of the interface is Waiting, add a Type
3 link (stub network) with Link ID set to the IP network number
of the attached network, Link Data set to the attached network's
address mask, and cost equal to the interface's configured output
cost.
o If the state of the interface is Waiting, add a Type 3 link (stub network) with Link ID set to the IP network number of the attached network, Link Data set to the attached network's address mask, and cost equal to the interface's configured output cost.
o Else, there has been a Designated Router elected for
the attached network. If the router is fully adjacent to the
Designated Router, or if the router itself is Designated Router
and is fully adjacent to at least one other router, add a single
Type 2 link (transit network) with Link ID set to the IP
interface address of the attached network's Designated Router
(which may be the router itself), Link Data set to the router's
own IP interface address, and cost equal to the interface's
configured output cost. Otherwise, add a link as if the
interface state were Waiting (see above).
o Else, there has been a Designated Router elected for the attached network. If the router is fully adjacent to the Designated Router, or if the router itself is Designated Router and is fully adjacent to at least one other router, add a single Type 2 link (transit network) with Link ID set to the IP interface address of the attached network's Designated Router (which may be the router itself), Link Data set to the router's own IP interface address, and cost equal to the interface's configured output cost. Otherwise, add a link as if the interface state were Waiting (see above).
12.4.1.3. Describing virtual links
12.4.1.3. Describing virtual links
For virtual links, a link description is added to the router-LSA only when the virtual neighbor is fully adjacent. In this case, add a Type 4 link (virtual link) with Link ID set to the Router ID of the virtual neighbor, Link Data set to the IP interface address associated with the virtual link and cost set to the cost calculated for the virtual link during the routing table calculation (see Section 15).
For virtual links, a link description is added to the router-LSA only when the virtual neighbor is fully adjacent. In this case, add a Type 4 link (virtual link) with Link ID set to the Router ID of the virtual neighbor, Link Data set to the IP interface address associated with the virtual link and cost set to the cost calculated for the virtual link during the routing table calculation (see Section 15).
Moy Standards Track [Page 113] RFC 2178 OSPF Version 2 July 1997
Moy Standards Track [Page 113] RFC 2178 OSPF Version 2 July 1997
12.4.1.4. Describing Point-to-MultiPoint interfaces
12.4.1.4. Describing Point-to-MultiPoint interfaces
For operational Point-to-MultiPoint interfaces, one or more link descriptions are added to the router-LSA as follows:
For operational Point-to-MultiPoint interfaces, one or more link descriptions are added to the router-LSA as follows:
o A single Type 3 link (stub network) is added with
Link ID set to the router's own IP interface address, Link Data
set to the mask 0xffffffff (indicating a host route), and cost
set to 0.
o A single Type 3 link (stub network) is added with Link ID set to the router's own IP interface address, Link Data set to the mask 0xffffffff (indicating a host route), and cost set to 0.
o For each fully adjacent neighbor associated with the
interface, add an additional Type 1 link (point-to-point) with
Link ID set to the Router ID of the neighboring router, Link Data
set to the IP interface address and cost equal to the interface's
configured output cost.
o For each fully adjacent neighbor associated with the interface, add an additional Type 1 link (point-to-point) with Link ID set to the Router ID of the neighboring router, Link Data set to the IP interface address and cost equal to the interface's configured output cost.
12.4.1.5. Examples of router-LSAs
12.4.1.5. Examples of router-LSAs
Consider the router-LSAs generated by Router RT3, as pictured in Figure 6. The area containing Router RT3 (Area 1) has been redrawn, with actual network addresses, in Figure 15. Assume that the last byte of all of RT3's interface addresses is 3, giving it the interface addresses 192.1.1.3 and 192.1.4.3, and that the other routers have similar addressing schemes. In addition, assume that all links are functional, and that Router IDs are assigned as the smallest IP interface address.
Consider the router-LSAs generated by Router RT3, as pictured in Figure 6. The area containing Router RT3 (Area 1) has been redrawn, with actual network addresses, in Figure 15. Assume that the last byte of all of RT3's interface addresses is 3, giving it the interface addresses 192.1.1.3 and 192.1.4.3, and that the other routers have similar addressing schemes. In addition, assume that all links are functional, and that Router IDs are assigned as the smallest IP interface address.
RT3 originates two router-LSAs, one for Area 1 and one for the backbone. Assume that Router RT4 has been selected as the Designated router for network 192.1.1.0. RT3's router-LSA for Area 1 is then shown below. It indicates that RT3 has two connections to Area 1, the first a link to the transit network 192.1.1.0 and the second a link to the stub network 192.1.4.0. Note that the transit network is identified by the IP interface of its Designated Router (i.e., the Link ID = 192.1.1.4 which is the Designated Router RT4's IP interface to 192.1.1.0). Note also that RT3 has indicated that it is an area border router.
RT3は背骨のために2ルータ-LSAs、Area1と1のためのものを溯源します。 Router RT4がネットワーク192.1.1のためのDesignatedルータとして.0に選定されたと仮定してください。 そして、Area1のためのRT3のルータ-LSAは以下で見せられます。 それが、RT3が2つのArea1、1日接続のためにトランジットネットワークにリンクを持っているのを示す、192.1、.1、.0、スタッブネットワークへの2番目のaリンク、192.1、.4、.0 どれにDesignated Router RT4のIPインタフェースがあるか。トランジットネットワークがDesignated RouterのIPインタフェースによって特定されることに注意してください、(すなわち、Link IDが等しい、192.1、.1、.4、192.1 .1 .0)。 また、RT3が、それが境界ルータであることを示したことに注意してください。
Moy Standards Track [Page 114] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[114ページ]RFC2178OSPFバージョン1997年7月2日
; RT3's router-LSA for Area 1
; 領域1へのRT3のルータ-LSA
LS age = 0 ;always true on origination
Options = (E-bit) ;
LS type = 1 ;indicates router-LSA
Link State ID = 192.1.1.3 ;RT3's Router ID
Advertising Router = 192.1.1.3 ;RT3's Router ID
bit E = 0 ;not an AS boundary router
bit B = 1 ;area border router
#links = 2
Link ID = 192.1.1.4 ;IP address of Desig. Rtr.
Link Data = 192.1.1.3 ;RT3's IP interface to net
Type = 2 ;connects to transit network
# TOS metrics = 0
metric = 1
LSは=0に年をとらせます; 創作Options=でいつも本当です(電子ビットの)。 LSは=1をタイプします; 2Link.3; RT3のRouter ID Advertising Router=192.1.1.3; RT3のRouter IDビットE=0; AS境界ルータビットB=1でない; 境界ルータ#リンク=ID=192.1にルータ-LSA Link州ID=192.1.1を示します。.1 .4 ; DesigのIPアドレス。 Rtr。 リンクData=192.1.1.3; ネットのType=2へのRT3のIPインタフェース;はトランジットネットワーク#TOS測定基準=0にメートル法の=1を関連づけます。
Link ID = 192.1.4.0 ;IP Network number
Link Data = 0xffffff00 ;Network mask
Type = 3 ;connects to stub network
# TOS metrics = 0
metric = 2
IP Network番号Link Dataが0xffffff00と等しいという.0がネットワークでつなぐリンクID=192.1.4はType=3にマスクをかけます; スタッブネットワーク#TOS測定基準=0にメートル法の=2を関連づけます。
Next RT3's router-LSA for the backbone is shown. It indicates that RT3 has a single attachment to the backbone. This attachment is via an unnumbered point-to-point link to Router RT6. RT3 has again indicated that it is an area border router.
背骨のための次のRT3のルータ-LSAは見せられます。 それは、RT3がただ一つの付属を背骨に持っているのを示します。 Router RT6への無数のポイントツーポイント接続を通してこの付属はあります。 RT3は、それが境界ルータであることを再び示しました。
; RT3's router-LSA for the backbone
; 背骨のためのRT3のルータ-LSA
LS age = 0 ;always true on origination
Options = (E-bit) ;
LS type = 1 ;indicates router-LSA
Link State ID = 192.1.1.3 ;RT3's router ID
Advertising Router = 192.1.1.3 ;RT3's router ID
bit E = 0 ;not an AS boundary router
bit B = 1 ;area border router
#links = 1
Link ID = 18.10.0.6 ;Neighbor's Router ID
Link Data = 0.0.0.3 ;MIB-II ifIndex of P-P link
Type = 1 ;connects to router
# TOS metrics = 0
metric = 8
LSは=0に年をとらせます; 創作Options=でいつも本当です(電子ビットの)。 LSは=1をタイプします; ルータ-LSA Link州ID=192.1.1.3 ; .3; RT3のルータIDビットE=0; AS境界ルータビットBでない=1(18.10.0P-Pの.6; 隣人のRouter ID Link Data=0.0.0.3; MIB-II ifIndexリンクType=1Linkの境界ルータ#リンク=ID=1)がルータ#TOS測定基準=0のメートル法の=8に接続するRT3のルータID Advertising Router=192.1.1を示します。
Moy Standards Track [Page 115] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[115ページ]RFC2178OSPFバージョン1997年7月2日
12.4.2. Network-LSAs
12.4.2. ネットワーク-LSAs
A network-LSA is generated for every transit broadcast or NBMA network. (A transit network is a network having two or more attached routers). The network-LSA describes all the routers that are attached to the network.
ネットワーク-LSAはあらゆるトランジット放送かNBMAネットワークのために発生します。 (トランジットネットワークは2を持っているネットワークであるか以上はルータを付けました。) LSAをネットワークでつなぐのはネットワークに付けられているすべてのルータについて説明します。
The Designated Router for the network originates the LSA. The Designated Router originates the LSA only if it is fully adjacent to at least one other router on the network. The network-LSA is flooded throughout the area that contains the transit network, and no further. The network-LSA lists those routers that are fully adjacent to the Designated Router; each fully adjacent router is identified by its OSPF Router ID. The Designated Router includes itself in this list.
ネットワークのためのDesignated RouterはLSAを溯源します。 それが完全に溯源する場合にだけ、Designated Routerはネットワークの他の少なくとも1つのルータに隣接してLSAを溯源します。 LSAをネットワークでつなぐのはトランジットネットワークを含む領域に、これ以上水につかっています。 LSAをネットワークでつなぐのはDesignated Routerに隣接して完全にそうであるそれらのルータを記載します。 それぞれの完全に隣接しているルータはOSPF Router IDによって特定されます。 Designated Routerはこのリストにそれ自体を含んでいます。
The Link State ID for a network-LSA is the IP interface address of the Designated Router. This value, masked by the network's address mask (which is also contained in the network-LSA) yields the network's IP address.
ネットワーク-LSAのためのLink州IDはDesignated RouterのIPインターフェース・アドレスです。 この値であり、ネットワークのアドレスによってマスクをかけられて、マスク(また、ネットワーク-LSAに含まれている)はネットワークのIPアドレスをもたらします。
A router that has formerly been the Designated Router for a network, but is no longer, should flush the network-LSA that it had previously originated. This LSA is no longer used in the routing table calculation. It is flushed by prematurely incrementing the LSA's age to MaxAge and reflooding (see Section 14.1). In addition, in those rare cases where a router's Router ID has changed, any network-LSAs that were originated with the router's previous Router ID must be flushed. Since the router may have no idea what it's previous Router ID might have been, these network-LSAs are indicated by having their Link State ID equal to one of the router's IP interface addresses and their Advertising Router equal to some value other than the router's current Router ID (see Section 13.4 for more details).
もうネットワークのための以前Designated Routerであるのではなくあるルータはそれが以前に溯源したネットワーク-LSAを洗い流すべきです。 このLSAはもう経路指定テーブル計算に使用されません。 それは、早まってまでにLSAの時代を増加しながらMaxAgeに洗い流されて、「再-あふれ」ています(セクション14.1を見てください)。 さらに、ルータのRouter IDが変化したそれらのまれなケースの中では、ルータの前のRouter IDと共に溯源されたどんなネットワーク-LSAsも洗い流さなければなりません。 以来、ルータは、彼らのルータのIPインターフェース・アドレスの1つと等しいLink州IDとそれらのルータの現在のRouter ID以外の何らかの値と等しいAdvertising Routerを持ちながら、何による前のRouter IDがあったかもしれなくて、これらのネットワーク-LSAsが示されるということであるかが分からないかもしれません(その他の詳細に関してセクション13.4を見てください)。
12.4.2.1. Examples of network-LSAs
12.4.2.1. ネットワーク-LSAsに関する例
Again consider the area configuration in Figure 6. Network-LSAs are originated for Network N3 in Area 1, Networks N6 and N8 in Area 2, and Network N9 in Area 3. Assuming that Router RT4 has been selected as the Designated Router for Network N3, the following network-LSA is generated by RT4 on behalf of Network N3 (see Figure 15 for the address assignments):
もう一度図6での領域構成を考えてください。 ネットワーク-LSAsはArea1のNetwork N3、Area2のNetworks N6とN8、およびArea3のNetwork N9のために溯源されます。 Router RT4がNetwork N3のためのDesignated Routerとして選定されたと仮定して、以下のネットワーク-LSAはRT4によってNetwork N3を代表して発生します(アドレス課題に関して図15を見てください):
Moy Standards Track [Page 116] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[116ページ]RFC2178OSPFバージョン1997年7月2日
; Network-LSA for Network N3
; ネットワークN3のためのネットワーク-LSA
LS age = 0 ;always true on origination
Options = (E-bit) ;
LS type = 2 ;indicates network-LSA
Link State ID = 192.1.1.4 ;IP address of Desig. Rtr.
Advertising Router = 192.1.1.4 ;RT4's Router ID
Network Mask = 0xffffff00
Attached Router = 192.1.1.4 ;Router ID
Attached Router = 192.1.1.1 ;Router ID
Attached Router = 192.1.1.2 ;Router ID
Attached Router = 192.1.1.3 ;Router ID
LSは=0に年をとらせます; 創作Options=でいつも本当です(電子ビットの)。 LSは=2をタイプします; ネットワーク-LSA Link州ID=192.1.1.4 ; DesigのIPアドレスを示します。 Rtr。 広告ルータ=192.1.1.4; RT4のルータIDネットワークマスク=0xffffff00はルータ=192.1.1.4を付けました; Router IDはルータ=192.1.1.1を付けました; Router IDはルータ=192.1.1.2; ルータのIDの付属ルータ=192.1.1.3; Router IDを付けました。
12.4.3. Summary-LSAs
12.4.3. 概要-LSAs
The destination described by a summary-LSA is either an IP network, an AS boundary router or a range of IP addresses. Summary-LSAs are flooded throughout a single area only. The destination described is one that is external to the area, yet still belongs to the Autonomous System.
概要-LSAによって説明された目的地はIPネットワーク、AS境界ルータまたはさまざまなIPが記述するどちらかです。 概要-LSAsはただ一つの領域だけ中で水につかっています。 説明された目的地はその領域に外部ですが、まだAutonomous Systemに属しているものです。
Summary-LSAs are originated by area border routers. The precise summary routes to advertise into an area are determined by examining the routing table structure (see Section 11) in accordance with the algorithm described below. Note that only intra-area routes are advertised into the backbone, while both intra-area and inter-area routes are advertised into the other areas.
概要-LSAsは境界ルータによって溯源されます。 領域に広告を出す正確な概要ルートは以下でアルゴリズムによると、経路指定テーブル構造(セクション11を見る)を調べることによって説明されていた状態で決定しています。 イントラ領域ルートだけが背骨に広告を出すことに注意してください、イントラ領域と相互領域ルートの両方が他の領域に広告に掲載されていますが。
To determine which routes to advertise into an attached Area A, each routing table entry is processed as follows. Remember that each routing table entry describes a set of equal-cost best paths to a particular destination:
付属Area Aにどのルートの広告を出したらよいかを決定するために、それぞれの経路指定テーブルエントリーは以下の通り処理されます。 それぞれの経路指定テーブルエントリーが1セットの等しい費用の最も良い経路について特定の目的地に説明するのを覚えていてください:
o Only Destination Types of network and AS boundary router
are advertised in summary-LSAs. If the routing table entry's
Destination Type is area border router, examine the next routing
table entry.
o 概要-LSAsにネットワークとAS境界ルータのDestination Typesだけの広告を出します。 経路指定テーブルエントリーのDestination Typeが領域境界ルータであるなら、次の経路指定テーブルエントリーを調べてください。
o AS external routes are never advertised in summary-LSAs.
If the routing table entry has Path-type of type 1 external or
type 2 external, examine the next routing table entry.
o 決して概要-LSAsにAS外部経路の広告を出しません。 経路指定テーブルエントリーにタイプ1外部かタイプのPath-タイプ2外部があるなら、次の経路指定テーブルエントリーを調べてください。
o Else, if the area associated with this set of paths is
the Area A itself, do not generate a summary-LSA for the
route.[17]
o ほかに、このセットの経路に関連している領域がArea A自身であるなら、概要-LSAをルートに発生させないでください。[17]
Moy Standards Track [Page 117] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[117ページ]RFC2178OSPFバージョン1997年7月2日
o Else, if the next hops associated with this set of paths
belong to Area A itself, do not generate a summary-LSA for the
route.[18] This is the logical equivalent of a Distance Vector
protocol's split horizon logic.
o このセットの経路に関連している次のホップがArea A自身に属すなら、ほかに、概要-LSAをルート.[18]に発生させないでください。これはDistance Vectorプロトコルの分裂地平線論理の論理的な同等物です。
o Else, if the routing table cost equals or exceeds the
value LSInfinity, a summary-LSA cannot be generated for this
route.
o ほかに、経路指定テーブル費用が値のLSInfinityを等しい、または超えているなら、概要-LSAはこのルートに発生できません。
o Else, if the destination of this route is an AS boundary
router, a summary-LSA should be originated if and only if the
routing table entry describes the preferred path to the AS
boundary router (see Step 3 of Section 16.4). If so, a Type 4
summary-LSA is originated for the destination, with Link State ID
equal to the AS boundary router's Router ID and metric equal to
the routing table entry's cost. Note: these LSAs should not be
generated if Area A has been configured as a stub area.
o そして、ほかに、概要-LSAがこのルートの目的地がAS境界ルータであるなら、溯源されるべきである、経路指定テーブルエントリーがAS境界ルータに都合のよい経路について説明する場合にだけ(セクション16.4のStep3を見てください)。 そうだとすれば、Type4概要-LSAは目的地に溯源されます、経路指定テーブルエントリーの費用へのAS境界ルータのRouter IDとメートル法の同輩と等しいLink州IDと共に。 以下に注意してください。 Area Aがスタッブ領域として構成されたなら、これらのLSAsは発生するべきではありません。
o Else, the Destination type is network. If this is an
inter-area route, generate a Type 3 summary-LSA for the
destination, with Link State ID equal to the network's address (if
necessary, the Link State ID can also have one or more of the
network's host bits set; see Appendix E for details) and metric
equal to the routing table cost.
o ほかに、Destinationタイプはネットワークです。 これが相互領域ルートであるなら、Type3概要-LSAを目的地に発生させてください、経路指定テーブル費用へのネットワークのアドレス(また、必要なら、Link州IDはネットワークのホストビットの1つ以上を設定させることができます; 詳細に関してAppendix Eを見る)とメートル法の同輩と等しいLink州IDと共に。
o The one remaining case is an intra-area route to a network. This
means that the network is contained in one of the router's
directly attached areas. In general, this information must be
condensed before appearing in summary-LSAs. Remember that an area
has a configured list of address ranges, each range consisting of
an [address,mask] pair and a status indication of either Advertise
or DoNotAdvertise. At most a single Type 3 summary-LSA is
originated for each range. When the range's status indicates
Advertise, a Type 3 summary-LSA is generated with Link State ID
equal to the range's address (if necessary, the Link State ID can
also have one or more of the range's "host" bits set; see Appendix
E for details) and cost equal to the largest cost of any of the
component networks. When the range's status indicates
DoNotAdvertise, the Type 3 summary-LSA is suppressed and the
component networks remain hidden from other areas.
o 1つの残っているケースがネットワークへのイントラ領域ルートです。 これは、ネットワークがルータの直接付属している領域の1つに含まれていることを意味します。 一般に、概要-LSAsに現れる前に、この情報を凝縮しなければなりません。 領域にはaがあるのがアドレスの範囲、[アドレス、マスク]組から成る各範囲、およびどちらかの状態しるしについて広告と記載するように構成しました。覚えている、または、DoNotAdvertise。 高々、独身のType3概要-LSAは各範囲に溯源されます。 範囲の状態が、広告を示すとき、Type3概要-LSAは範囲のコンポーネントネットワークのどれかの最も大きい費用と等しいアドレス(また、必要なら、Link州IDは範囲の「ホスト」ビットの1つ以上を設定させることができます; 詳細に関してAppendix Eを見る)と費用と等しいLink州IDと共に発生します。 範囲の状態がDoNotAdvertiseを示すとき、Type3概要-LSAは抑圧されます、そして、他の領域隠されたままで、コンポーネントネットワークは残っています。
By default, if a network is not contained in any explicitly configured address range, a Type 3 summary-LSA is generated with Link State ID equal to the network's address (if necessary, the Link State ID can also have one or more of the network's "host" bits set; see Appendix E for details) and metric equal to the network's routing table cost.
デフォルトで、ネットワークがどんな明らかに構成されたアドレスの範囲にも保管されていないなら、Type3概要-LSAはネットワークのアドレス(また、必要なら、Link州IDはネットワークの「ホスト」ビットの1つ以上を設定させることができます; 詳細に関してAppendix Eを見る)とメートル法の同輩と等しいLink州IDと共にネットワークの経路指定テーブル費用に発生します。
Moy Standards Track [Page 118] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[118ページ]RFC2178OSPFバージョン1997年7月2日
If an area is capable of carrying transit traffic (i.e., its TransitCapability is set to TRUE), routing information concerning backbone networks should not be condensed before being summarized into the area. Nor should the advertisement of backbone networks into transit areas be suppressed. In other words, the backbone's configured ranges should be ignored when originating summary-LSAs into transit areas.
領域がトランジット交通を運ぶことができるなら(すなわち、TransitCapabilityはTRUEに用意ができています)、領域へまとめる前に背骨ネットワークのルーティング情報を凝縮するべきではありません。 また、トランジット領域への背骨ネットワークの広告を抑圧するべきではありません。 言い換えれば、概要-LSAsをトランジット領域に溯源するとき、背骨の構成された範囲は無視されるべきです。
If a router advertises a summary-LSA for a destination which then becomes unreachable, the router must then flush the LSA from the routing domain by setting its age to MaxAge and reflooding (see Section 14.1). Also, if the destination is still reachable, yet can no longer be advertised according to the above procedure (e.g., it is now an inter-area route, when it used to be an intra-area route associated with some non-backbone area; it would thus no longer be advertisable to the backbone), the LSA should also be flushed from the routing domain.
ルータが次に手が届かなくなる目的地に概要-LSAの広告を出すなら、ルータは広告を出さなければならなくて、次に、経路ドメインからMaxAgeに時代を設定して、「再-あふれ」ることによって、LSAを洗い流してください(セクション14.1を見てください)。 また、また、目的地をまだ届いていますが、上の手順に従ってもう広告に掲載できないなら(現在例えば、それは相互領域ルートです、それが以前、何らかの非背骨領域に関連しているイントラ領域ルートであったときに; その結果、それはもう背骨に「広告を出-可能」でないでしょう)、LSAは経路ドメインから洗い流されるべきです。
12.4.3.1. Originating summary-LSAs into stub areas
12.4.3.1. 概要-LSAsをスタッブ領域に溯源します。
The algorithm in Section 12.4.3 is optional when Area A is an OSPF stub area. Area border routers connecting to a stub area can originate summary-LSAs into the area according to the Section 12.4.3's algorithm, or can choose to originate only a subset of the summary-LSAs, possibly under configuration control. The fewer LSAs originated, the smaller the stub area's link state database, further reducing the demands on its routers' resources. However, omitting LSAs may also lead to sub-optimal inter-area routing, although routing will continue to function.
Area AがOSPFスタッブ領域であるときに、セクション12.4.3におけるアルゴリズムは任意です。 スタッブ領域に接続する境界ルータは、セクション12.4.3アルゴリズムによると、概要-LSAsを領域に溯源できるか、または概要-LSAsの部分集合だけを溯源するのを選ぶことができます、ことによると構成管理で。 LSAsが由来しなければ由来しないほど、ルータのリソースでさらに要求を抑えるスタッブ領域のリンク州のデータベースは、より小さいです。 しかしながら、ルーティングは、機能し続けるでしょうが、また、LSAsを省略するのはサブ最適の相互領域ルーティングに通じるかもしれません。
As specified in Section 12.4.3, Type 4 summary-LSAs (ASBR-summary- LSAs) are never originated into stub areas.
セクション12.4.3で指定されるように、Type4概要-LSAs(ASBR-概要LSAs)はスタッブ領域に決して溯源されません。
In a stub area, instead of importing external routes each area border router originates a "default summary-LSA" into the area. The Link State ID for the default summary-LSA is set to DefaultDestination, and the metric set to the (per-area) configurable parameter StubDefaultCost. Note that StubDefaultCost need not be configured identically in all of the stub area's area border routers.
スタッブ領域では、外部経路を輸入することの代わりに、各境界ルータが「デフォルト概要-LSA」を領域に溯源します。 デフォルト概要-LSAのためのLink州IDはDefaultDestination、および(領域)構成可能なパラメタStubDefaultCostへのメートル法のセットに設定されます。 StubDefaultCostが同様にスタッブ領域の境界ルータのすべてで構成される必要はないことに注意してください。
12.4.3.2. Examples of summary-LSAs
12.4.3.2. 概要-LSAsに関する例
Consider again the area configuration in Figure 6. Routers RT3, RT4, RT7, RT10 and RT11 are all area border routers, and therefore are originating summary-LSAs. Consider in particular Router RT4. Its routing table was calculated as the example in Section 11.3. RT4 originates summary-LSAs into both the backbone and Area 1. Into the backbone, Router RT4 originates separate LSAs for each of the
もう一度図6での領域構成を考えてください。 ルータのRT3、RT4、RT7、RT10、およびRT11は境界ルータであり、したがって、由来している概要-LSAsです。 Router RT4を特に考えてください。 経路指定テーブルはセクション11.3の例として計算されました。 RT4は背骨とArea1の両方に概要-LSAsを溯源します。 背骨に、Router RT4はそれぞれのために別々のLSAsを溯源します。
Moy Standards Track [Page 119] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[119ページ]RFC2178OSPFバージョン1997年7月2日
networks N1-N4. Into Area 1, Router RT4 originates separate LSAs for networks N6-N8 and the AS boundary routers RT5,RT7. It also condenses host routes Ia and Ib into a single summary-LSA. Finally, the routes to networks N9,N10,N11 and Host H1 are advertised by a single summary-LSA. This condensation was originally performed by the router RT11.
N1-N4をネットワークでつなぎます。 Area1に、Router RT4はネットワークのN6-N8とASルータRT5境界、RT7のために別々のLSAsを溯源します。 また、それはホストルートのIaとイブを独身の概要-LSAに凝縮します。 最終的に、ネットワークのN9、N10、N11、およびHost H1へのルートは独身の概要-LSAによって広告を出されます。 この凝縮は元々、ルータRT11によって実行されました。
These LSAs are illustrated graphically in Figures 7 and 8. Two of the summary-LSAs originated by Router RT4 follow. The actual IP addresses for the networks and routers in question have been assigned in Figure 15.
これらのLSAsは図7と8でグラフィカルに例証されます。 2由来された概要-LSAs Router RT4が続きます。 図15で問題のネットワークとルータのための実際のIPアドレスを割り当ててあります。
; Summary-LSA for Network N1,
; originated by Router RT4 into the backbone
; ネットワークN1のための概要-LSA。 Router RT4で、背骨に由来します。
LS age = 0 ;always true on origination
Options = (E-bit) ;
LS type = 3 ;Type 3 summary-LSA
Link State ID = 192.1.2.0 ;N1's IP network number
Advertising Router = 192.1.1.4 ;RT4's ID
metric = 4
LSは=0に年をとらせます; 創作Options=でいつも本当です(電子ビットの)。 LSは=3; メートル法で3概要-LSA Link州ID=192.1.2.0; N1のIPネットワーク数のAdvertising Router=192.1.1.4; RT4のIDをタイプする=4をタイプします。
; Summary-LSA for AS boundary router RT7
; originated by Router RT4 into Area 1
; ASのための概要-LSA境界ルータRT7。 Router RT4で、Area1に由来します。
LS age = 0 ;always true on origination
Options = (E-bit) ;
LS type = 4 ;Type 4 summary-LSA
Link State ID = Router RT7's ID
Advertising Router = 192.1.1.4 ;RT4's ID
metric = 14
LSは=0に年をとらせます; 創作Options=でいつも本当です(電子ビットの)。 LSは=4; メートル法で4概要-LSA Link州ID=ルータRT7のID Advertising Router=192.1.1.4 ; RT4のIDをタイプする=14をタイプします。
12.4.4. AS-external-LSAs
12.4.4. 外部のLSAs
AS-external-LSAs describe routes to destinations external to the Autonomous System. Most AS-external-LSAs describe routes to specific external destinations; in these cases the LSA's Link State ID is set to the destination network's IP address (if necessary, the Link State ID can also have one or more of the network's "host" bits set; see Appendix E for details). However, a default route for the Autonomous System can be described in an AS-external-LSA by setting the LSA's Link State ID to DefaultDestination (0.0.0.0). AS-external-LSAs are originated by AS boundary routers. An AS boundary router originates a single AS-external-LSA for each external route that it has learned, either through another routing protocol (such as BGP), or through configuration information.
ASの外部のLSAsはAutonomous Systemへの外部の目的地にルートを説明します。 ほとんどのASの外部のLSAsが特定の外部の目的地にルートを説明します。 これらの場合では、LSAのLink州IDは送信先ネットワークのIPアドレスに設定されます(また、必要なら、Link州IDはネットワークの「ホスト」ビットの1つ以上を設定させることができます; 詳細に関してAppendix Eを見てください)。 しかしながら、ASの外部のLSAでLSAのLink州IDをDefaultDestinationに設定することによってAutonomous Systemのためのデフォルトルートを説明できる、(0.0 .0 .0)。 ASの外部のLSAsはAS境界ルータによって溯源されます。 AS境界ルータはそれが別のルーティング・プロトコル(BGPなどの)を通して、または、設定情報を通して学んだ各外部経路に独身のAS外部のLSAを溯源します。
Moy Standards Track [Page 120] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[120ページ]RFC2178OSPFバージョン1997年7月2日
AS-external-LSAs are the only type of LSAs that are flooded throughout the entire Autonomous System; all other types of LSAs are specific to a single area. However, AS-external-LSAs are not flooded into/throughout stub areas (see Section 3.6). This enables a reduction in link state database size for routers internal to stub areas.
ASの外部のLSAsはLSAsの唯一の全体のAutonomous System中で水につかっているタイプです。 LSAsの他のすべてのタイプがただ一つの領域に特定です。 しかしながら、ASの外部のLSAsはスタッブ領域中に/へあふれません(セクション3.6を見てください)。 これは領域を引き抜くためには内部のルータのためにリンク州のデータベースサイズの減少を可能にします。
The metric that is advertised for an external route can be one of two types. Type 1 metrics are comparable to the link state metric. Type 2 metrics are assumed to be larger than the cost of any intra-AS path.
外部経路に広告に掲載されているメートル法は2つのタイプのひとりであることができます。 タイプ1測定基準はリンク状態にメートル法で匹敵しています。 タイプ2測定基準がどんなイントラ-AS経路の費用よりも大きいと思われます。
If a router advertises an AS-external-LSA for a destination which then becomes unreachable, the router must then flush the LSA from the routing domain by setting its age to MaxAge and reflooding (see Section 14.1).
ルータが次に手が届かなくなる目的地にASの外部のLSAの広告を出すなら、ルータは広告を出さなければならなくて、次に、経路ドメインからMaxAgeに時代を設定して、「再-あふれ」ることによって、LSAを洗い流してください(セクション14.1を見てください)。
12.4.4.1. Examples of AS-external-LSAs
12.4.4.1. 例、外部のLSAs
Consider once again the AS pictured in Figure 6. There are two AS boundary routers: RT5 and RT7. Router RT5 originates three AS- external-LSAs, for networks N12-N14. Router RT7 originates two AS- external-LSAs, for networks N12 and N15. Assume that RT7 has learned its route to N12 via BGP, and that it wishes to advertise a Type 2 metric to the AS. RT7 would then originate the following LSA for N12:
もう一度図6に描写されたASを考えてください。 2つのAS境界ルータがあります: RT5とRT7。 ルータRT5はネットワークのための外部のLSAsの3AS N12-N14を溯源します。 ルータRT7はネットワークのN12とN15のために2ASの外部のLSAsを溯源します。 RT7がBGPを通してルートをN12に学んで、ASへのメートル法のType2の広告を出したがっていると仮定してください。 次に、RT7はN12のために以下のLSAを溯源するでしょう:
; AS-external-LSA for Network N12,
; originated by Router RT7
; 外部のLSA、ネットワークN12のために。 Router RT7で、由来します。
LS age = 0 ;always true on origination
Options = (E-bit) ;
LS type = 5 ;AS-external-LSA
Link State ID = N12's IP network number
Advertising Router = Router RT7's ID
bit E = 1 ;Type 2 metric
metric = 2
Forwarding address = 0.0.0.0
LSは=0に年をとらせます; 創作Options=でいつも本当です(電子ビットの)。 LSは=5; ルータASの外部のLSA Link州ID=N12のIPネットワーク・ナンバーAdvertising Router=RT7のIDビットE=1; タイプ2メートル法のメートル法の=2Forwardingアドレス=0.0.0.0をタイプします。
In the above example, the forwarding address field has been set to 0.0.0.0, indicating that packets for the external destination should be forwarded to the advertising OSPF router (RT7). This is not always desirable. Consider the example pictured in Figure 16. There are three OSPF routers (RTA, RTB and RTC) connected to a common network. Only one of these routers, RTA, is exchanging BGP information with the non-OSPF router RTX. RTA must then originate AS- external-LSAs for those destinations it has learned from RTX. By using the AS- external-LSA's forwarding address field, RTA can specify that packets
上記の例では、推進アドレス・フィールドは設定されました。0.0 .0 .0 外部の目的地へのパケットが広告OSPFルータ(RT7)に送られるべきであるのを示します。 これはいつも望ましいというわけではありません。 図16に描写された例を考えてください。 一般的なネットワークに関連づけられた3つのOSPFルータ(RTA、RTB、およびRTC)があります。 これらのルータの1つ(RTA)だけが非OSPFルータRTXとBGP情報を交換しています。 そして、RTAはそれがRTXから学んだそれらの目的地にLSAsである状態で外部のASを溯源しなければなりません。 AS外部のLSA推進アドレス・フィールドを使用することによって、RTAはそのパケットを指定できます。
Moy Standards Track [Page 121] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[121ページ]RFC2178OSPFバージョン1997年7月2日
for these destinations be forwarded directly to RTX. Without this feature, Routers RTB and RTC would take an extra hop to get to these destinations.
これらの目的地に関しては、直接RTXに送ってください。 この特徴がなければ、Routers RTBとRTCは、これらの目的地に着くように余分なホップを取るでしょう。
Note that when the forwarding address field is non-zero, it should point to a router belonging to another Autonomous System.
推進アドレス・フィールドが非ゼロであるときに、別のAutonomous Systemに属すルータを示すべきであることに注意してください。
A forwarding address can also be specified for the default route. For example, in figure 16 RTA may want to specify that all externally- destined packets should by default be forwarded to its BGP peer RTX. The resulting AS-external-LSA is pictured below. Note that the Link State ID is set to DefaultDestination.
また、デフォルトルートにフォーワーディング・アドレスを指定できます。 例えば、図では、16RTAは、すべての外部的に運命づけられたパケットがデフォルトでBGP同輩RTXに送られるべきであると指定したがっているかもしれません。 結果として起こるAS外部のLSAは以下に描写されます。 Link州IDがDefaultDestinationに設定されることに注意してください。
; Default route, originated by Router RTA
; Packets forwarded through RTX
; Router RTAによって溯源されたデフォルトルート。 RTXを通して進められたパケット
LS age = 0 ;always true on origination
Options = (E-bit) ;
LS type = 5 ;AS-external-LSA
Link State ID = DefaultDestination ; default route
Advertising Router = Router RTA's ID
bit E = 1 ;Type 2 metric
metric = 1
Forwarding address = RTX's IP address
LSは=0に年をとらせます; 創作Options=でいつも本当です(電子ビットの)。 LSは=5をタイプします; ASの外部のLSA Link州IDはDefaultDestinationと等しいです。 ルータデフォルトルートAdvertising Router=RTAのIDビットE=1; タイプメートル法のメートル法の2の=の1Forwardingのアドレス=RTXのIPアドレス
In figure 16, suppose instead that both RTA and RTB exchange BGP information with RTX. In this case, RTA and RTB would originate the same set of AS-external-LSAs. These LSAs, if they specify the same metric, would be functionally equivalent since they would specify the same destination and forwarding address (RTX). This leads to a clear duplication of effort. If only one of RTA or RTB originated the set of AS-external-LSAs, the routing would remain the same, and the size of the link state database would decrease. However, it must be unambiguously defined as to which router originates the LSAs (otherwise neither may, or the identity of the originator may oscillate). The following rule is thereby established: if two routers, both reachable from one another, originate functionally equivalent AS-external-LSAs (i.e., same destination, cost and non- zero forwarding address), then the LSA originated by the router having the highest OSPF Router ID is used. The router having the lower OSPF Router ID can then flush its LSA. Flushing an LSA is discussed in Section 14.1.
16図では、代わりにRTAとRTBの両方がBGP情報をRTXと交換すると仮定してください。 この場合、RTAとRTBはASの外部のLSAsの同じセットを溯源するでしょう。 彼らは同じ目的地とフォーワーディング・アドレス(RTX)を指定するでしょう、したがって、彼らが同じようにメートル法で指定するなら、これらのLSAsは機能上同等でしょう。 これは努力の明確な複製に通じます。 RTAかRTBの唯一の1つがASの外部のLSAsのセットを溯源するなら、ルーティングは同じままで残っているでしょうに、そして、リンク州のデータベースのサイズは減少するでしょう。 しかしながら、どのルータがLSAsを溯源するかに関して明白にそれを定義しなければなりません(そうでなければ、どちらもそうするかもしれませんか、または創始者のアイデンティティは振動するかもしれません)。 その結果、以下の規則は確立されます: お互いからともに届いている2つのルータが機能上同等なAS外部のLSAs(すなわち、同じ目的地、費用、およびゼロを転送しないアドレス)を溯源するなら、持っている中でOSPF Router ID最も高いルータによって溯源されたLSAは使用されています。 そして、下側のOSPF Router IDを持っているルータはLSAを洗い流すことができます。 セクション14.1でLSAを洗い流すのと議論します。
13. The Flooding Procedure
13. 氾濫手順
Link State Update packets provide the mechanism for flooding LSAs. A Link State Update packet may contain several distinct LSAs, and floods each LSA one hop further from its point of origination. To
リンク州Updateパケットは氾濫LSAsにメカニズムを供給します。 Link州Updateパケットは、数個の異なったLSAsを含むかもしれなくて、さらに創作のポイントからのワンバウンドのそれぞれのLSAをあふれさせます。 to
Moy Standards Track [Page 122] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[122ページ]RFC2178OSPFバージョン1997年7月2日
make the flooding procedure reliable, each LSA must be acknowledged separately. Acknowledgments are transmitted in Link State Acknowledgment packets. Many separate acknowledgments can also be grouped together into a single packet.
別々に信頼できる氾濫手順、承認されていて、LSAがそうしなければならないそれぞれを作ってください。 承認はLink州Acknowledgmentパケットで伝えられます。 また、多くの別々の承認を単一のパケットに一緒に分類できます。
The flooding procedure starts when a Link State Update packet has been received. Many consistency checks have been made on the received packet before being handed to the flooding procedure (see Section 8.2). In particular, the Link State Update packet has been associated with a particular neighbor, and a particular area. If the neighbor is in a lesser state than Exchange, the packet should be dropped without further processing.
Link州Updateパケットを受け取ったとき、氾濫手順は始まります。 氾濫手順に手渡す前に容認されたパケットの上で多くの一貫性チェックをしました(セクション8.2を見てください)。 Link州Updateパケットは特定の隣人、および特定の領域に特に、関連しています。 隣人がExchangeより少ない状態にあるなら、パケットはさらなる処理なしで落とされるべきです。
+
|
+---+.....|.BGP
|RTA|-----|.....+---+
+---+ |-----|RTX|
| +---+
+---+ |
|RTB|-----|
+---+ |
|
+---+ |
|RTC|-----|
+---+ |
|
+
+ | +---+.....|.BGP|RTA|-----|.....+---+ +---+ |-----|RTX| | +---+ +---+ | |RTB|-----| +---+ | | +---+ | |RTC|-----| +---+ | | +
Figure 16: Forwarding address example
図16: フォーワーディング・アドレスの例
All types of LSAs, other than AS-external-LSAs, are associated with a specific area. However, LSAs do not contain an area field. An LSA's area must be deduced from the Link State Update packet header.
ASの外部のLSAs以外のLSAsのすべてのタイプが特定の領域に関連しています。 しかしながら、LSAsは領域分野を含んでいません。 Link州のUpdateパケットのヘッダーからLSAの領域を推論しなければなりません。
For each LSA contained in a Link State Update packet, the following steps are taken:
Link州Updateパケットに含まれた各LSAにおいて、以下の方法を取ります:
(1) Validate the LSA's LS checksum. If the checksum turns out to be
invalid, discard the LSA and get the next one from the Link
State Update packet.
(1) LSAのLSチェックサムを有効にしてください。 チェックサムが無効であると判明するなら、LSAを捨ててください、そして、Link州Updateパケットから次のものを得てください。
(2) Examine the LSA's LS type. If the LS type is unknown, discard
the LSA and get the next one from the Link State Update Packet.
This specification defines LS types 1-5 (see Section 4.3).
(2) LSAのLSタイプを調べてください。 LSタイプが未知であるなら、LSAを捨ててください、そして、Link州Update Packetから次のものを得てください。 この仕様はLSタイプ1-5を定義します(セクション4.3を見てください)。
(3) Else if this is an AS-external-LSA (LS type = 5), and the area
これであるなら、(3)はほかのASの外部のLSA(LSは=5をタイプする)と、領域です。
Moy Standards Track [Page 123] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[123ページ]RFC2178OSPFバージョン1997年7月2日
has been configured as a stub area, discard the LSA and get the
next one from the Link State Update Packet. AS-external-LSAs
are not flooded into/throughout stub areas (see Section 3.6).
Link州Update Packetからスタッブ領域として構成されて、LSAを捨てて、次のものを得るのを持っています。 ASの外部のLSAsはスタッブ領域中に/へあふれません(セクション3.6を見てください)。
(4) Else if the LSA's LS age is equal to MaxAge, and there is
currently no instance of the LSA in the router's link state
database, then take the following actions:
(4) LSAのLS年令がMaxAgeと等しく、ルータのリンク州のデータベースにLSAの例が全く現在なければ、ほかに、以下の行動を取ってください:
(a) Acknowledge the receipt of the LSA by sending a Link State
Acknowledgment packet back to the sending neighbor (see
Section 13.5).
(a) Link州Acknowledgmentパケットを送付隣人に送り返すことによって、LSAの領収書を受け取ったことを知らせてください(セクション13.5を見てください)。
(b) Purge all outstanding requests for equal or previous
instances of the LSA from the sending neighbor's Link State
Request list (see Section 10).
(b) 送付隣人のLink州RequestリストからLSAの等しいか前の例を求めるすべての傑出している要求を掃除してください(セクション10を見てください)。
(c) If the sending neighbor is in state Exchange or in state
Loading, then install the MaxAge LSA in the link state
database. Otherwise, simply discard the LSA. In either
case, examine the next LSA (if any) listed in the Link State
Update packet.
(c) 送付隣人が州のExchangeか州のLoadingにいるなら、リンク州のデータベースにMaxAge LSAをインストールしてください。 さもなければ、単にLSAを捨ててください。 どちらの場合ではも、Link州Updateパケットに記載された次のLSA(もしあれば)を調べてください。
(5) Otherwise, find the instance of this LSA that is currently
contained in the router's link state database. If there is no
database copy, or the received LSA is more recent than the
database copy (see Section 13.1 below for the determination of
which LSA is more recent) the following steps must be performed:
(5) さもなければ、現在ルータのリンク州のデータベースに含まれているこのLSAの例を見つけてください。 データベースコピーが全くないか、または容認されたLSAが以下が踏むデータベースコピー(LSAが、より最近である決断に関して以下のセクション13.1を見る)を実行しなければならないより最近なら:
(a) If there is already a database copy, and if the database
copy was installed less than MinLSArrival seconds ago,
discard the new LSA (without acknowledging it) and examine
the next LSA (if any) listed in the Link State Update
packet.
(a) データベースコピーが既にあって、データベースコピーがMinLSArrival秒ほどインストールされなかった、前、新しいLSA(それを承認することのない)を捨ててください、そして、Link州Updateパケットに記載された次のLSA(もしあれば)を調べてください。
(b) Otherwise immediately flood the new LSA out some subset of
the router's interfaces (see Section 13.3). In some cases
(e.g., the state of the receiving interface is DR and the
LSA was received from a router other than the Backup DR) the
LSA will be flooded back out the receiving interface. This
occurrence should be noted for later use by the
acknowledgment process (Section 13.5).
(b) さもなければ、至急、ルータのインタフェースの何らかの部分集合から新しいLSAをあふれさせてください(セクション13.3を見てください)。 水浸しにして戻されて、受信が連結するというLSAがそうするいくつかの場合(例えば、受信インタフェースの状態はDRです、そして、Backup DR以外のルータからLSAを受け取った)ではことになってください。 この発生は後の使用で承認工程(セクション13.5)で有名であるべきです。
(c) Remove the current database copy from all neighbors' Link
state retransmission lists.
(c) すべての隣人のLink州の「再-トランスミッション」リストから現在のデータベースコピーを取り外してください。
(d) Install the new LSA in the link state database (replacing
the current database copy). This may cause the routing
table calculation to be scheduled. In addition, timestamp
(d) リンク州のデータベースに新しいLSAをインストールしてください(現在のデータベースコピーを取り替えて)。 これで、経路指定テーブル計算を予定するかもしれません。 添加、タイムスタンプで
Moy Standards Track [Page 124] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[124ページ]RFC2178OSPFバージョン1997年7月2日
the new LSA with the current time (i.e., the time it was
received). The flooding procedure cannot overwrite the
newly installed LSA until MinLSArrival seconds have elapsed.
The LSA installation process is discussed further in Section
13.2.
現在の時間(すなわち、それが受け取られた時)がある新しいLSA。 MinLSArrival秒が経過するまで、氾濫手順は新たにインストールされたLSAを上書きできません。 セクション13.2で、より詳しくLSAインストールの過程について議論します。
(e) Possibly acknowledge the receipt of the LSA by sending a
Link State Acknowledgment packet back out the receiving
interface. This is explained below in Section 13.5.
(e) Link州Acknowledgmentパケットを送るのによるLSAの領収書が受信インタフェースの手を引くとことによると認めてください。 これはセクション13.5で以下で説明されます。
(f) If this new LSA indicates that it was originated by the
receiving router itself (i.e., is considered a self-
originated LSA), the router must take special action, either
updating the LSA or in some cases flushing it from the
routing domain. For a description of how self-originated
LSAs are detected and subsequently handled, see Section
13.4.
(f) この新しいLSAが、受信ルータ(すなわち、自己の溯源されたLSAであると考えられる)自体によってそれが溯源されたのを示すなら、ルータは特別な行動を取らなければなりません、LSAをアップデートするか、またはいくつかの場合、経路ドメインからそれを洗い流して。 自己によって溯源されたLSAsがどう検出されて、次に扱われるかに関する記述に関しては、セクション13.4を見てください。
(6) Else, if there is an instance of the LSA on the sending
neighbor's Link state request list, an error has occurred in the
Database Exchange process. In this case, restart the Database
Exchange process by generating the neighbor event BadLSReq for
the sending neighbor and stop processing the Link State Update
packet.
(6) ほかに、LSAの例が送付隣人のLink州の要求リストにあれば、誤りはDatabase Exchangeの過程で発生しました。 この場合、送付隣人のために隣人イベントBadLSReqを発生させることによって、Database Exchangeの過程を再開してください、そして、Link州Updateパケットを処理するのを止めてください。
(7) Else, if the received LSA is the same instance as the database
copy (i.e., neither one is more recent) the following two steps
should be performed:
(7) ほかに、以下の2ステップは容認されたLSAがデータベースコピーと同じ例(すなわち、どちらも、より最近でない)であるなら実行されるべきです:
(a) If the LSA is listed in the Link state retransmission list
for the receiving adjacency, the router itself is expecting
an acknowledgment for this LSA. The router should treat the
received LSA as an acknowledgment by removing the LSA from
the Link state retransmission list. This is termed an
"implied acknowledgment". Its occurrence should be noted
for later use by the acknowledgment process (Section 13.5).
(a) LSAが受信隣接番組のためのLink州の「再-トランスミッション」リストに記載されるなら、ルータ自体はこのLSAのために承認を予想しています。 ルータは、Link州の「再-トランスミッション」リストからLSAを取り外すことによって、容認されたLSAを承認として扱うべきです。 これは「暗示している承認」と呼ばれます。 発生は後の使用で承認工程(セクション13.5)で有名であるべきです。
(b) Possibly acknowledge the receipt of the LSA by sending a
Link State Acknowledgment packet back out the receiving
interface. This is explained below in Section 13.5.
(b) Link州Acknowledgmentパケットを送るのによるLSAの領収書が受信インタフェースの手を引くとことによると認めてください。 これはセクション13.5で以下で説明されます。
(8) Else, the database copy is more recent. If the database copy
has LS age equal to MaxAge and LS sequence number equal to
MaxSequenceNumber, simply discard the received LSA without
acknowledging it. (In this case, the LSA's LS sequence number is
wrapping, and the MaxSequenceNumber LSA must be completely
flushed before any new LSA instance can be introduced).
Otherwise, send the database copy back to the sending neighbor,
(8) ほかに、データベースコピーは、より最近です。 データベースコピーにMaxAgeと等しいLS年令とLS一連番号があるなら、それを承認しないで、MaxSequenceNumberと等しくて、単に容認されたLSAを捨ててください。 (この場合LSAのLS一連番号はラッピングです、そして、どんな新しいLSA例も紹介できる前にMaxSequenceNumber LSAを完全に洗い流さなければなりません。) さもなければ、データベースコピーを送付隣人に送り返してください。
Moy Standards Track [Page 125] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[125ページ]RFC2178OSPFバージョン1997年7月2日
encapsulated within a Link State Update Packet. The Link State
Update Packet should be unicast to the neighbor. In so doing, do
not put the database copy of the LSA on the neighbor's link
state retransmission list, and do not acknowledge the received
(less recent) LSA instance.
Link州Update Packetの中で要約されます。 Link州Update Packetは隣人へのユニキャストであるべきです。 そうする際に、隣人のリンク州の「再-トランスミッション」リストにLSAのデータベースコピーを載せないでください、そして、容認された(それほど最近でない)LSA例を承認しないでください。
13.1. Determining which LSA is newer
13.1. どちらのLSAが、より新しいかを決定します。
When a router encounters two instances of an LSA, it must determine which is more recent. This occurred above when comparing a received LSA to its database copy. This comparison must also be done during the Database Exchange procedure which occurs during adjacency bring- up.
ルータがLSAの2つの例に遭遇すると、それは、どちらが、より最近であるかを決定しなければなりません。 容認されたLSAをデータベースコピーと比較するとき、これは上に起こりました。 この比較はそうしなければなりません、また、隣接番組の間に起こるDatabase Exchange手順の間、してください。上をもたらします。
An LSA is identified by its LS type, Link State ID and Advertising Router. For two instances of the same LSA, the LS sequence number, LS age, and LS checksum fields are used to determine which instance is more recent:
LSAはLink州のLSタイプ、ID、およびAdvertising Routerによって特定されます。 同じLSAの2つの例において、LS一連番号、LS時代、およびLSチェックサム分野はどちらの例が、より最近であるかを決定するために費やされます:
o The LSA having the newer LS sequence number is more recent.
See Section 12.1.6 for an explanation of the LS sequence number
space. If both instances have the same LS sequence number, then:
o より新しいLS一連番号があるLSAは、より最近です。 LS一連番号スペースの説明に関してセクション12.1.6を見てください。 次に、両方の例に同じLS一連番号があるなら:
o If the two instances have different LS checksums, then the
instance having the larger LS checksum (when considered as a 16-
bit unsigned integer) is considered more recent.
o 2つの例に異なったLSチェックサムがあるなら、より大きいLSチェックサム(16の噛み付いている符号のない整数であるとみなされると)を持っている例は、より最近であると考えられます。
o Else, if only one of the instances has its LS age field set
to MaxAge, the instance of age MaxAge is considered to be more
recent.
o ほかに、例の唯一の1つでLS時代分野をMaxAgeに設定するなら、時代MaxAgeの例が、より最近であると考えられます。
o Else, if the LS age fields of the two instances differ by
more than MaxAgeDiff, the instance having the smaller (younger)
LS age is considered to be more recent.
o ほかに、2つの例のLS時代分野がMaxAgeDiff以上で異なるなら、よりわずかな(より若い)LS時代を過す例が、より最近であると考えられます。
o Else, the two instances are considered to be identical.
o ほかに、2つの例が同じであると考えられます。
Moy Standards Track [Page 126] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[126ページ]RFC2178OSPFバージョン1997年7月2日
13.2. Installing LSAs in the database
13.2. LSAsをデータベースにインストールします。
Installing a new LSA in the database, either as the result of flooding or a newly self-originated LSA, may cause the OSPF routing table structure to be recalculated. The contents of the new LSA should be compared to the old instance, if present. If there is no difference, there is no need to recalculate the routing table. When comparing an LSA to its previous instance, the following are all considered to be differences in contents:
氾濫の結果か新たに自己によって溯源されたLSAとして新しいLSAをデータベースにインストールするのに、OSPF経路指定テーブル構造について再計算するかもしれません。 新しいLSAのコンテンツは、古い例と比較されていて、存在しているべきです。 違いが全くなければ、ルーティングがテーブルの上に置くrecalculateにおける必要は全くありません。 前の例とLSAを比較するとき、以下はコンテンツの違いであるとすべて考えられます:
o The LSA's Options field has changed.
o LSAのOptions分野は変化しました。
o One of the LSA instances has LS age set to MaxAge, and
the other does not.
o LSA例の1つで、LS時代をMaxAgeに設定します、そして、もう片方はさせません。
o The length field in the LSA header has changed.
o LSAヘッダーの長さの分野は変化しました。
o The body of the LSA (i.e., anything outside the 20-byte
LSA header) has changed. Note that this excludes changes in LS
Sequence Number and LS Checksum.
o LSA(すなわち、20バイトのLSAヘッダーの外の何でも)のボディーは変化しました。 これがLS Sequence NumberとLS Checksumにおける変化を除くことに注意してください。
If the contents are different, the following pieces of the routing table must be recalculated, depending on the new LSA's LS type field:
内容が異なるなら、経路指定テーブルの以下の断片について再計算しなければなりません、新しいLSAのLSタイプフィールドによって:
Router-LSAs and network-LSAs
The entire routing table must be recalculated, starting with the
shortest path calculations for each area (not just the area whose
link-state database has changed). The reason that the shortest
path calculation cannot be restricted to the single changed area
has to do with the fact that AS boundary routers may belong to
multiple areas. A change in the area currently providing the best
route may force the router to use an intra-area route provided by
a different area.[19]
ルータ-LSAsと全体のネットワーク-LSAs経路指定テーブルについて再計算しなければなりません、各領域(リンク州のデータベースが変化した領域であるだけではない)のための最短パス計算から始まって。 最短パス計算がただ一つの変えられた領域に制限されない場合がある理由はAS境界ルータが複数の領域に属すかもしれないという事実と関係があります。 現在提供する中でルート最も良い領域の変化によって、ルータはやむを得ず異なった領域によって提供されたイントラ領域ルートを使用するかもしれません。[19]
Summary-LSAs
The best route to the destination described by the summary-LSA
must be recalculated (see Section 16.5). If this destination is
an AS boundary router, it may also be necessary to re-examine all
the AS-external-LSAs.
目的地への最も良いルートが概要-LSAで説明した概要-LSAsについて再計算しなければなりません(セクション16.5を見てください)。 また、この目的地がAS境界ルータであるなら、すべてのASの外部のLSAsを再検討するのも必要であるかもしれません。
AS-external-LSAs
The best route to the destination described by the AS-external-LSA
must be recalculated (see Section 16.6).
目的地への最も良いルートがASの外部のLSAで説明したASの外部のLSAsについて再計算しなければなりません(セクション16.6を見てください)。
Also, any old instance of the LSA must be removed from the
database when the new LSA is installed. This old instance must
also be removed from all neighbors' Link state retransmission
lists (see Section 10).
また、新しいLSAをインストールするとき、データベースからLSAのどんな古い例も取り除かなければなりません。 また、すべての隣人のLink州の「再-トランスミッション」リストからこの古い例を取り除かなければなりません(セクション10を見てください)。
Moy Standards Track [Page 127] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[127ページ]RFC2178OSPFバージョン1997年7月2日
13.3. Next step in the flooding procedure
13.3. 氾濫手順における次のステップ
When a new (and more recent) LSA has been received, it must be flooded out some set of the router's interfaces. This section describes the second part of flooding procedure (the first part being the processing that occurred in Section 13), namely, selecting the outgoing interfaces and adding the LSA to the appropriate neighbors' Link state retransmission lists. Also included in this part of the flooding procedure is the maintenance of the neighbors' Link state request lists.
新しくて(より最近)のLSAを受け取ったとき、水浸しにされて、或るものがルータのインタフェースをセットしたということであるに違いありません。 このセクションは、すなわち、外向的なインタフェースを選択して、適切な隣人のLink州の「再-トランスミッション」リストにLSAを追加しながら、氾濫手順(セクション13に起こった処理である最初の部分)の第二部について説明します。 また、氾濫手順のこの部分に含まれているのは、隣人のLink州の要求リストの維持です。
This section is equally applicable to the flooding of an LSA that the router itself has just originated (see Section 12.4).
このセクションは等しくルータ自体がちょうど溯源したLSAの氾濫に適切です(セクション12.4を見てください)。
For these LSAs, this section provides the entirety of the flooding procedure (i.e., the processing of Section 13 is not performed, since, for example, the LSA has not been received from a neighbor and therefore does not need to be acknowledged).
これらのLSAsのために、このセクションは氾濫手順の全体を提供します(すなわち、セクション13の処理が実行されません、例えば、LSAは隣人から受け取られていなくて、したがって、承認される必要はありません)。
Depending upon the LSA's LS type, the LSA can be flooded out only certain interfaces. These interfaces, defined by the following, are called the eligible interfaces:
LSAのLSタイプに頼っていて、あるインタフェースだけからLSAをあふれさせることができます。 以下によって定義されたこれらのインタフェースは適任のインタフェースと呼ばれます:
AS-external-LSAs (LS Type = 5)
AS-external-LSAs are flooded throughout the entire AS, with the
exception of stub areas (see Section 3.6). The eligible
interfaces are all the router's interfaces, excluding virtual
links and those interfaces attaching to stub areas.
ASの外部のLSAs(LS Type=5)のASの外部のLSAsは全体のAS中で水につかっています、スタッブ領域を除いて(セクション3.6を見てください)。 領域を引き抜くために付く仮想のリンクとそれらのインタフェースを除いて、適任のインタフェースはすべてのルータのインタフェースです。
All other LS types
All other types are specific to a single area (Area A). The
eligible interfaces are all those interfaces attaching to the Area
A. If Area A is the backbone, this includes all the virtual
links.
他のLSタイプAll他のすべてのタイプがただ一つの領域(領域A)に特定です。 適任のインタフェースはすべてArea A.に付くそれらのインタフェースです。If Area Aが背骨である、これはすべての仮想のリンクを含んでいます。
Link state databases must remain synchronized over all adjacencies associated with the above eligible interfaces. This is accomplished by executing the following steps on each eligible interface. It should be noted that this procedure may decide not to flood an LSA out a particular interface, if there is a high probability that the attached neighbors have already received the LSA. However, in these cases the flooding procedure must be absolutely sure that the neighbors eventually do receive the LSA, so the LSA is still added to each adjacency's Link state retransmission list. For each eligible interface:
リンク州のデータベースは上の適任のインタフェースに関連しているすべての隣接番組の上で連動したままで残らなければなりません。 これは、それぞれの適任のインタフェースにおける以下のステップを実行することによって、達成されます。 この手順が、特定のインタフェースでありそれが高い確率にいればLSAを水浸しにしないように、付属隣人が既にLSAを受け取ったと決めるかもしれないことに注意されるべきです。 しかしながら、これらの場合を、氾濫手順が隣人が結局LSAを受け取るのを絶対に確認していなければならないので、LSAはまだ各隣接番組のLink州の「再-トランスミッション」リストに追加されています。 それぞれの適任のインタフェースに:
Moy Standards Track [Page 128] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[128ページ]RFC2178OSPFバージョン1997年7月2日
(1) Each of the neighbors attached to this interface are
examined, to determine whether they must receive the new
LSA. The following steps are executed for each neighbor:
(1) このインタフェースに付けられた隣人各人は、彼らが新しいLSAを受けなければならないかどうか決定するために調べられます。 以下のステップは各隣人のために実行されます:
(a) If the neighbor is in a lesser state than Exchange, it
does not participate in flooding, and the next neighbor
should be examined.
(a) 隣人がExchangeより少ない状態にあるなら、氾濫に参加しません、そして、次の隣人は調べられるべきです。
(b) Else, if the adjacency is not yet full (neighbor state
is Exchange or Loading), examine the Link state request
list associated with this adjacency. If there is an
instance of the new LSA on the list, it indicates that
the neighboring router has an instance of the LSA
already. Compare the new LSA to the neighbor's copy:
(b) 隣接番組がまだ完全でないなら(隣人状態は、ExchangeかLoadingです)、ほかに、この隣接番組に関連しているLink州の要求リストを調べてください。 新しいLSAの例がリストにあれば、それは、隣接しているルータにはLSAの例が既にあるのを示します。 新しいLSAを隣人のコピーと比較してください:
o If the new LSA is less recent, then examine the next
neighbor.
o 新しいLSAがそれほど最近でないなら、次の隣人を調べてください。
o If the two copies are the same instance, then delete
the LSA from the Link state request list, and
examine the next neighbor.[20]
o コピー2部が同じ例であるなら、Link州の要求リストからLSAを削除してください、そして、次の隣人を調べてください。[20]
o Else, the new LSA is more recent. Delete the LSA
from the Link state request list.
o ほかに、新しいLSAは、より最近です。 Link州の要求リストからLSAを削除してください。
(c) If the new LSA was received from this neighbor, examine
the next neighbor.
(c) この隣人から新しいLSAを受け取ったなら、次の隣人を調べてください。
(d) At this point we are not positive that the neighbor has
an up-to-date instance of this new LSA. Add the new LSA
to the Link state retransmission list for the adjacency.
This ensures that the flooding procedure is reliable;
the LSA will be retransmitted at intervals until an
acknowledgment is seen from the neighbor.
(d) ここに、私たちは隣人にはこの新しいLSAの最新の例があるのを確信していません。 隣接番組のためのLink州の「再-トランスミッション」リストに新しいLSAを追加してください。 これは、氾濫手順が信頼できるのを確実にします。 間隔を置いて、承認が隣人から見られるまで、LSAは再送されるでしょう。
(2) The router must now decide whether to flood the new LSA out
this interface. If in the previous step, the LSA was NOT
added to any of the Link state retransmission lists, there
is no need to flood the LSA out the interface and the next
interface should be examined.
(2) ルータは、現在、新しいLSAを水浸しにするために、これが連結するかどうか決めなければなりません。 ステップ、前のLSAが加えられないなら、LSAを水浸しにするために、記載して、ある州の「再-トランスミッション」がそうしなければならないLinkのいずれにも、インタフェースと次のインタフェースは調べられるでしょうに。
(3) If the new LSA was received on this interface, and it was
received from either the Designated Router or the Backup
Designated Router, chances are that all the neighbors have
received the LSA already. Therefore, examine the next
interface.
(3) このインタフェースに新しいLSAを受け取って、Designated RouterかBackup Designated Routerのどちらかからそれを受け取ったなら、機会はすべての隣人が既にLSAを受け取ったということです。 したがって、次のインタフェースを調べてください。
Moy Standards Track [Page 129] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[129ページ]RFC2178OSPFバージョン1997年7月2日
(4) If the new LSA was received on this interface, and the
interface state is Backup (i.e., the router itself is the
Backup Designated Router), examine the next interface. The
Designated Router will do the flooding on this interface.
However, if the Designated Router fails the router (i.e.,
the Backup Designated Router) will end up retransmitting the
updates.
(4) このインタフェースに新しいLSAを受け取って、界面準位がBackup(すなわち、ルータ自体はBackup Designated Routerである)であるなら、次のインタフェースを調べてください。 Designated Routerはこのインタフェースで氾濫させるでしょう。 しかしながら、Designated Routerが失敗すると、ルータ(すなわち、Backup Designated Router)は結局、アップデートを再送するでしょう。
(5) If this step is reached, the LSA must be flooded out the
interface. Send a Link State Update packet (including the
new LSA as contents) out the interface. The LSA's LS age
must be incremented by InfTransDelay (which must be > 0)
when it is copied into the outgoing Link State Update packet
(until the LS age field reaches the maximum value of
MaxAge).
(5) このステップに達しているなら、LSAはインタフェースから水につかっているに違いありません。 インタフェースからLink州Updateパケット(コンテンツとして新しいLSAを含んでいる)を送ってください。 それが出発しているLink州Updateパケットにコピーされるとき(LS時代分野がMaxAgeの最大値に達するまで)、InfTransDelay(>0であるに違いない)はLSAのLS時代を増加しなければなりません。
On broadcast networks, the Link State Update packets are
multicast. The destination IP address specified for the
Link State Update Packet depends on the state of the
interface. If the interface state is DR or Backup, the
address AllSPFRouters should be used. Otherwise, the
address AllDRouters should be used.
放送網では、Link州Updateパケットはマルチキャストです。 Link州Update Packetに指定された送付先IPアドレスはインタフェースの状態に依存します。 界面準位がDRかBackupであるなら、アドレスAllSPFRoutersは使用されるべきです。 さもなければ、アドレスAllDRoutersは使用されるべきです。
On non-broadcast networks, separate Link State Update
packets must be sent, as unicasts, to each adjacent neighbor
(i.e., those in state Exchange or greater). The destination
IP addresses for these packets are the neighbors' IP
addresses.
非放送網に、別々のLink州Updateパケットを送らなければなりません、ユニキャストとして、それぞれの隣接している隣人(すなわち、州のExchangeか、よりすばらしいところのそれら)に。 これらのパケットのための送付先IPアドレスは隣人のIPアドレスです。
13.4. Receiving self-originated LSAs
13.4. 受信は自己にLSAsを溯源しました。
It is a common occurrence for a router to receive self-originated LSAs via the flooding procedure. A self-originated LSA is detected when either 1) the LSA's Advertising Router is equal to the router's own Router ID or 2) the LSA is a network-LSA and its Link State ID is equal to one of the router's own IP interface addresses.
ルータが氾濫手順で自己によって溯源されたLSAsを受け取るのは、よくあります。 自己によって溯源されたLSAによる1であることの)ルータの自己のRouter IDか2への同輩) LSAがネットワーク-LSAであるというLSAのAdvertising Routerによることであり検出されて、Link州IDがルータの自己のIPインターフェース・アドレスの1つと等しいということです。
However, if the received self-originated LSA is newer than the last instance that the router actually originated, the router must take special action. The reception of such an LSA indicates that there are LSAs in the routing domain that were originated by the router before the last time it was restarted. In most cases, the router must then advance the LSA's LS sequence number one past the received LS sequence number, and originate a new instance of the LSA.
しかしながら、容認された自己によって溯源されたLSAがルータが実際に溯源した最終審より新しいなら、ルータは特別な行動を取らなければなりません。 そのようなLSAのレセプションは、LSAsがそれが前回再開されたとき以前ルータによって溯源された経路ドメインにあるのを示します。 多くの場合、ルータは、次に、容認されたLS一連番号の先でLSAのLS一連番号1を進めて、LSAの新しい例を溯源しなければなりません。
It may be the case the router no longer wishes to originate the received LSA. Possible examples include: 1) the LSA is a summary-LSA or AS-external-LSA and the router no longer has an (advertisable)
ルータがもう容認されたLSAを溯源したがっていないのは、ケースであるかもしれません。 可能な例は: 1) LSAは概要-LSAかASの外部のLSAです、そして、もうルータはLSAであったことそのような。(「広告を出-可能」)
Moy Standards Track [Page 130] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[130ページ]RFC2178OSPFバージョン1997年7月2日
route to the destination, 2) the LSA is a network-LSA but the router is no longer Designated Router for the network or 3) the LSA is a network-LSA whose Link State ID is one of the router's own IP interface addresses but whose Advertising Router is not equal to the router's own Router ID (this latter case should be rare, and it indicates that the router's Router ID has changed since originating the LSA). In all these cases, instead of updating the LSA, the LSA should be flushed from the routing domain by incrementing the received LSA's LS age to MaxAge and reflooding (see Section 14.1).
目的地へのルート、2) LSAはネットワーク-LSAですが、ルータはネットワークか3のためのもうDesignated Router) LSAがLink州IDがルータの自己のIPインターフェース・アドレスの1つですが、Advertising Routerがルータの自己のRouter IDと等しくないネットワーク-LSA(この後者のケースはまれであるはずです、そして、それはLSAを溯源して以来ルータのRouter IDが変化しているのを示す)であるということです。 これらのすべての場合では、LSAをアップデートすることの代わりに、LSAは容認されたLSAのLS時代をMaxAgeに増加して、「再-あふれ」るのによる経路ドメインから紅潮しているべきです(セクション14.1を見てください)。
13.5. Sending Link State Acknowledgment packets
13.5. 送付Link州Acknowledgmentパケット
Each newly received LSA must be acknowledged. This is usually done by sending Link State Acknowledgment packets. However, acknowledgments can also be accomplished implicitly by sending Link State Update packets (see step 7a of Section 13).
それぞれの新たに受け取られたLSAを承認しなければなりません。 通常、州AcknowledgmentパケットをLinkに送ることによって、これをします。 しかしながら、また、州UpdateパケットをLinkに送ることによって、それとなく承認を実行できます(セクション13のステップ7aを見てください)。
Many acknowledgments may be grouped together into a single Link State Acknowledgment packet. Such a packet is sent back out the interface which received the LSAs. The packet can be sent in one of two ways: delayed and sent on an interval timer, or sent directly (as a unicast) to a particular neighbor. The particular acknowledgment strategy used depends on the circumstances surrounding the receipt of the LSA.
多くの承認が単一のLink州Acknowledgmentパケットに一緒に分類されるかもしれません。 パケットが送られるそのようなものはLSAsを受けたインタフェースの手を引きます。 2つの方法の1つでパケットを送ることができます: インタバルタイマを遅らせて、転送したか、または特定の隣人に直送しました(ユニキャストとして)。 戦略が使用した特定の承認はLSAの領収書を囲む事情に依存します。
Sending delayed acknowledgments accomplishes several things: 1) it facilitates the packaging of multiple acknowledgments in a single Link State Acknowledgment packet, 2) it enables a single Link State Acknowledgment packet to indicate acknowledgments to several neighbors at once (through multicasting) and 3) it randomizes the Link State Acknowledgment packets sent by the various routers attached to a common network. The fixed interval between a router's delayed transmissions must be short (less than RxmtInterval) or needless retransmissions will ensue.
遅れた承認を送ると、数個のものが達成されます: 1) それは単一のLink州Acknowledgmentパケットがすぐに(マルチキャスティングを通して)数人の隣人に承認を示すのを可能にするという単一のLink州Acknowledgmentパケット、2における)複数の承認とそれが様々な添付のルータによって送られたLink州Acknowledgmentパケットをランダマイズする3の)パッケージを容易にします。一般的なネットワーク。 ルータの遅れたトランスミッションの固定間隔が短いに違いありませんか(RxmtIntervalよりそれほど)、または不必要な「再-トランスミッション」は続くでしょう。
Direct acknowledgments are sent to a particular neighbor in response to the receipt of duplicate LSAs. These acknowledgments are sent as unicasts, and are sent immediately when the duplicate is received.
写しLSAsの領収書に対応してダイレクト承認を特定の隣人に送ります。 これらの承認をユニキャストとして送って、すぐ写しが受け取られているとき、送ります。
The precise procedure for sending Link State Acknowledgment packets is described in Table 19. The circumstances surrounding the receipt of the LSA are listed in the left column. The acknowledgment action then taken is listed in one of the two right columns. This action depends on the state of the concerned interface; interfaces in state Backup behave differently from interfaces in all other states. Delayed acknowledgments must be delivered to all adjacent routers associated with the interface. On broadcast networks, this is accomplished by sending the delayed Link State Acknowledgment packets
送付Link州Acknowledgmentパケットのための正確な手順はTable19で説明されます。 LSAの領収書を囲む事情は左のコラムにリストアップされています。 承認動作、次に、取っているのは、正しい2つのコラムの記載されたコネ1です。 この動作を関係があるインタフェースの状態に依存します。 Backupが他のすべての州のインタフェースと異なって振る舞わせる状態のインタフェース。 インタフェースに関連しているすべての隣接しているルータに遅れた承認を提供しなければなりません。 放送網では、これは、遅れたLink州Acknowledgmentパケットを送ることによって、達成されます。
Moy Standards Track [Page 131] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[131ページ]RFC2178OSPFバージョン1997年7月2日
as multicasts. The Destination IP address used depends on the state of the interface. If the interface state is DR or Backup, the destination AllSPFRouters is used. In all other states, the destination AllDRouters is used. On non-broadcast networks, delayed Link State Acknowledgment packets must be unicast separately over each adjacency (i.e., neighbor whose state is >= Exchange).
マルチキャストとして。 アドレスが使用したDestination IPはインタフェースの状態に依存します。 界面準位がDRかBackupであるなら、目的地AllSPFRoutersは使用されています。 他のすべての州では、目的地AllDRoutersが使用されています。 非放送網では、遅れたLink州Acknowledgmentパケットは別々に各隣接番組の上のユニキャストであるに違いありません(すなわち、状態が>である隣人は交換と等しいです)。
Action taken in state
Circumstances Backup All other states
_______________________________________________________________
LSA has No acknowledgment No acknowledgment
been flooded back sent. sent.
out receiving in-
terface (see Sec-
tion 13, step 5b).
_______________________________________________________________
LSA is Delayed acknowledg- Delayed ack-
more recent than ment sent if adver- nowledgment sent.
database copy, but tisement received
was not flooded from Designated
back out receiving Router, otherwise
interface do nothing
_______________________________________________________________
LSA is a Delayed acknowledg- No acknowledgment
duplicate, and was ment sent if adver- sent.
treated as an im- tisement received
plied acknowledg- from Designated
ment (see Section Router, otherwise
13, step 7a). do nothing
_______________________________________________________________
LSA is a Direct acknowledg- Direct acknowledg-
duplicate, and was ment sent. ment sent.
not treated as an
implied ack-
nowledgment.
_______________________________________________________________
LSA's LS Direct acknowledg- Direct acknowledg-
age is equal to ment sent. ment sent.
MaxAge, and there is
no current instance
of the LSA
in the link state
database (see
Section 13, step 4).
州のCircumstances Backup All他の州で取られた行動_______________________________________________________________ LSAには、あふれ返さない承認が全く発信したという承認が全くありません。送って. 中で外で受信するのはterfaceされます(Sec- tion13を見てください、ステップ5b)。 _______________________________________________________________ 受け取られたtisementは外でRouterを受けるDesignated後部からあふれませんでした。adver- nowledgmentが. データベースコピーを送ったなら、LSAはmentが発信したより最近の遅れたDelayed acknowledgのackですが、さもなければ、インタフェースは何もしません。_______________________________________________________________ LSAはDelayed acknowledgいいえ承認写しです、そして、adverが. 不-tisementとして扱われた容認された運航されたacknowledg Designated mentを送ったなら、mentを送りました。(セクションRouter、そうでなければ13を見てください、ステップ7a)、何もしないでください。_______________________________________________________________ LSAによるDirect acknowledgがacknowledg写しを指示するということです、そして、. 送られたmentが送られたmentはことです。暗示しているack- nowledgmentとして扱われません。 _______________________________________________________________ LSA LS Direct acknowledgのダイレクトacknowledg年令は送られたmentと等しいです。mentは発信しました。 MaxAge、リンク州のデータベースにはLSAのどんな現在の例もありません(セクション13、ステップ4を見てください)。
Table 19: Sending link state acknowledgments.
テーブル19: リンク州の承認を送ります。
Moy Standards Track [Page 132] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[132ページ]RFC2178OSPFバージョン1997年7月2日
The reasoning behind sending the above packets as multicasts is best explained by an example. Consider the network configuration depicted in Figure 15. Suppose RT4 has been elected as Designated Router, and RT3 as Backup Designated Router for the network N3. When Router RT4 floods a new LSA to Network N3, it is received by routers RT1, RT2, and RT3. These routers will not flood the LSA back onto net N3, but they still must ensure that their link-state databases remain synchronized with their adjacent neighbors. So RT1, RT2, and RT4 are waiting to see an acknowledgment from RT3. Likewise, RT4 and RT3 are both waiting to see acknowledgments from RT1 and RT2. This is best achieved by sending the acknowledgments as multicasts.
例でマルチキャストとして上のパケットを送る後ろの推理について説明するのは最も良いです。 図15に表現されたネットワーク・コンフィギュレーションを考えてください。 RT4がDesignated Router、およびネットワークN3のためのBackup Designated RouterとしてのRT3として選出されたと仮定してください。 Router RT4が新しいLSAをNetwork N3へあふれさせるとき、それはルータのRT1、RT2、およびRT3によって受け取られます。 これらのルータはネットのN3へLSAをあふれて戻させないでしょうが、それらは、それらのリンク州のデータベースが彼らの隣接している隣人に連動したままで残っているのをまだ確実にしなければなりません。 それで、RT1、RT2、およびRT4は、RT3から承認を見るのを待っています。 同様に、RT4とRT3はRT1から承認を見るのを待って、RT2の両方です。 マルチキャストとして承認を送ることによってこれを達成するのは最も良いです。
The reason that the acknowledgment logic for Backup DRs is slightly different is because they perform differently during the flooding of LSAs (see Section 13.3, step 4).
Backup DRsのための承認論理がわずかに異なっている理由は彼らがLSAsの氾濫の間、異なって働くから(セクション13.3を見てください、ステップ4)です。
13.6. Retransmitting LSAs
13.6. LSAsを再送します。
LSAs flooded out an adjacency are placed on the adjacency's Link state retransmission list. In order to ensure that flooding is reliable, these LSAs are retransmitted until they are acknowledged. The length of time between retransmissions is a configurable per- interface value, RxmtInterval. If this is set too low for an interface, needless retransmissions will ensue. If the value is set too high, the speed of the flooding, in the face of lost packets, may be affected.
隣接番組から水につかっているLSAsは隣接番組のLink州の「再-トランスミッション」リストに置かれます。 氾濫が信頼できるのを確実にするために、彼らが承認されるまで、これらのLSAsは再送されます。 「再-トランスミッション」の間の時間の長さが構成可能なaである、-、RxmtInterval、値を連結してください。 これがインタフェースのときにあまりに低く予定されると、不必要な「再-トランスミッション」は続くでしょう。 値があまり高く設定されるなら、無くなっているパケットに直面して、氾濫の速度は影響を受けるかもしれません。
Several retransmitted LSAs may fit into a single Link State Update packet. When LSAs are to be retransmitted, only the number fitting in a single Link State Update packet should be sent. Another packet of retransmissions can be sent whenever some of the LSAs are acknowledged, or on the next firing of the retransmission timer.
数個の再送されたLSAsが単一のLink州Updateパケットに収まるかもしれません。 LSAsを再送することになっているとき、単一のLink州Updateパケットをうまくはめ込む数だけを送るべきです。 承認されるか、または再送信タイマーの次の発火にいくつかのLSAsがあるときはいつも、「再-トランスミッション」の別のパケットを送ることができます。
Link State Update Packets carrying retransmissions are always sent as unicasts (directly to the physical address of the neighbor). They are never sent as multicasts. Each LSA's LS age must be incremented by InfTransDelay (which must be > 0) when it is copied into the outgoing Link State Update packet (until the LS age field reaches the maximum value of MaxAge).
ユニキャスト(直接隣人の物理アドレスへの)としていつも「再-トランスミッション」を運ぶリンク州Update Packetsを送ります。 マルチキャストとしてそれらを決して送りません。 それが出発しているLink州Updateパケットにコピーされるとき(LS時代分野がMaxAgeの最大値に達するまで)、InfTransDelay(>0であるに違いない)は各LSAのLS時代を増加しなければなりません。
If an adjacent router goes down, retransmissions may occur until the adjacency is destroyed by OSPF's Hello Protocol. When the adjacency is destroyed, the Link state retransmission list is cleared.
隣接しているルータが落ちるなら、隣接番組がOSPFのHelloプロトコルによって破壊されるまで、「再-トランスミッション」は現れるかもしれません。 隣接番組が破壊されるとき、Link州の「再-トランスミッション」リストはきれいにされます。
Moy Standards Track [Page 133] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[133ページ]RFC2178OSPFバージョン1997年7月2日
13.7. Receiving link state acknowledgments
13.7. リンク州の承認を受けます。
Many consistency checks have been made on a received Link State Acknowledgment packet before it is handed to the flooding procedure. In particular, it has been associated with a particular neighbor. If this neighbor is in a lesser state than Exchange, the Link State Acknowledgment packet is discarded.
氾濫手順にそれを手渡す前に容認されたLink州Acknowledgmentパケットの上で多くの一貫性チェックをしました。 それは特定の隣人に特に、関連しています。 この隣人がExchangeより少ない状態にあるなら、Link州Acknowledgmentパケットは捨てられます。
Otherwise, for each acknowledgment in the Link State Acknowledgment packet, the following steps are performed:
さもなければ、Link州Acknowledgmentパケットでの各承認において、以下のステップは実行されます:
o Does the LSA acknowledged have an instance on the Link state
retransmission list for the neighbor? If not, examine the
next acknowledgment. Otherwise:
o 承認されたLSAは隣人へのLink州の「再-トランスミッション」リストに例を持っていますか? そうでなければ、次の承認を調べてください。 そうでなければ:
o If the acknowledgment is for the same instance that is
contained on the list, remove the item from the list and
examine the next acknowledgment. Otherwise:
o 承認がリストに含まれている同じ例のためのものであるなら、リストから商品を取り外してください、そして、次の承認を調べてください。 そうでなければ:
o Log the questionable acknowledgment, and examine the next
one.
o 疑わしい承認を登録してください、そして、次のものを調べてください。
14. Aging The Link State Database
14. リンク州のデータベースの年をとります。
Each LSA has an LS age field. The LS age is expressed in seconds. An LSA's LS age field is incremented while it is contained in a router's database. Also, when copied into a Link State Update Packet for flooding out a particular interface, the LSA's LS age is incremented by InfTransDelay.
各LSAには、LS時代分野があります。 LS時代は秒に表されます。 それはルータのデータベースに含まれていますが、LSAのLS時代分野は増加されています。 また、特定のインタフェースを水浸しにするためにLink州Update Packetにコピーされると、LSAのLS時代はInfTransDelayによって増加されます。
An LSA's LS age is never incremented past the value MaxAge. LSAs having age MaxAge are not used in the routing table calculation. As a router ages its link state database, an LSA's LS age may reach MaxAge.[21] At this time, the router must attempt to flush the LSA from the routing domain. This is done simply by reflooding the MaxAge LSA just as if it was a newly originated LSA (see Section 13.3).
LSAのLS時代は値のMaxAgeの先で決して増加されません。 時代MaxAgeを持っているLSAsが経路指定テーブル計算に使用されません。 ルータがリンク州のデータベースに年をとらせるのに従って、LSAのLS時代はこのときMaxAge.[21]に達するかもしれなくて、ルータは、経路ドメインからLSAを洗い流すのを試みなければなりません。 単にまるでまさしくそれが新たに溯源されたLSA(セクション13.3を見る)であるかのようにMaxAge LSAを「再-あふれ」させることによって、これをします。
When creating a Database summary list for a newly forming adjacency, any MaxAge LSAs present in the link state database are added to the neighbor's Link state retransmission list instead of the neighbor's Database summary list. See Section 10.3 for more details.
新たに形成している隣接番組のためのDatabase概要リストを作成するとき、リンク州のデータベースの現在のどんなMaxAge LSAsも隣人のDatabase概要リストの代わりに隣人のLink州の「再-トランスミッション」リストに追加されます。 その他の詳細に関してセクション10.3を見てください。
A MaxAge LSA must be removed immediately from the router's link state database as soon as both a) it is no longer contained on any neighbor Link state retransmission lists and b) none of the router's neighbors are in states Exchange or Loading.
すぐ両方ともう同じくらいすぐどんな隣人Link州の「再-トランスミッション」リストにも含まれたルータのリンク州のデータベースからMaxAge LSAを取り外さなければなりません、そして、b) ルータの隣人のだれも州のExchangeかLoadingにいません。
Moy Standards Track [Page 134] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[134ページ]RFC2178OSPFバージョン1997年7月2日
When, in the process of aging the link state database, an LSA's LS age hits a multiple of CheckAge, its LS checksum should be verified. If the LS checksum is incorrect, a program or memory error has been detected, and at the very least the router itself should be restarted.
リンク州のデータベースの年をとることの途中にLSAのLS時代がCheckAgeの倍数を打つと、LSチェックサムは確かめられるべきです。 LSチェックサムが不正確であるなら、プログラムかメモリ誤りが検出されました、そして、少なくとも、ルータ自体は再開されるべきです。
14.1. Premature aging of LSAs
14.1. LSAsの時期尚早な年をとること
An LSA can be flushed from the routing domain by setting its LS age to MaxAge and reflooding the LSA. This procedure follows the same course as flushing an LSA whose LS age has naturally reached the value MaxAge (see Section 14). In particular, the MaxAge LSA is removed from the router's link state database as soon as a) it is no longer contained on any neighbor Link state retransmission lists and b) none of the router's neighbors are in states Exchange or Loading. We call the setting of an LSA's LS age to MaxAge "premature aging".
LSAは経路ドメインからLS時代をMaxAgeに設定することによって紅潮していてLSAを「再-あふれ」させることができます。 この手順はLS時代が自然に値のMaxAgeに達したLSAを洗い流すのと同じコースに続きます(セクション14を見てください)。 a) それがもうどんな隣人Link州の「再-トランスミッション」リストにも含まれていないとすぐに、特に、MaxAge LSAはルータのリンク州のデータベースから取り外されます、そして、b) ルータの隣人のだれも州のExchangeかLoadingにいません。 私たちは「時期尚早な年をとMaxAge」にLSAのLS時代の設定を呼びます。
Premature aging is used when it is time for a self-originated LSA's sequence number field to wrap. At this point, the current LSA instance (having LS sequence number MaxSequenceNumber) must be prematurely aged and flushed from the routing domain before a new instance with sequence number equal to InitialSequenceNumber can be originated. See Section 12.1.6 for more information.
自己によって溯源されたLSAの一連番号分野が包装する時間であるとき、時期尚早な年をとるのは使用されています。 ここに、InitialSequenceNumberと等しい一連番号がある新しい例を溯源できる前に、経路ドメインから現在のLSA例(LS一連番号MaxSequenceNumberを持っている)を早まって、熟成して、洗い流さなければなりません。 詳しい情報に関してセクション12.1.6を見てください。
Premature aging can also be used when, for example, one of the router's previously advertised external routes is no longer reachable. In this circumstance, the router can flush its AS- external-LSA from the routing domain via premature aging. This procedure is preferable to the alternative, which is to originate a new LSA for the destination specifying a metric of LSInfinity. Premature aging is also be used when unexpectedly receiving self- originated LSAs during the flooding procedure (see Section 13.4).
また、例えば、ルータの以前に広告を出した外部経路の1つがもう届いていないとき、時期尚早な年をとることを使用できます。 この状況では、ルータは時期尚早な年をとることを通して経路ドメインからASの外部のLSAを洗い流すことができます。 この手順はLSInfinityにおけるメートル法のaを指定する目的地に新しいLSAを溯源することである代替手段より望ましいです。 時期尚早な年をとるのはそうです、また、不意に自己を受けるとLSAsが氾濫手順の間、溯源された(セクション13.4を見てください)ときには、使用されてください。
A router may only prematurely age its own self-originated LSAs. The router may not prematurely age LSAs that have been originated by other routers. An LSA is considered self- originated when either 1) the LSA's Advertising Router is equal to the router's own Router ID or 2) the LSA is a network-LSA and its Link State ID is equal to one of the router's own IP interface addresses.
ルータは早まって、それ自身の自己によって溯源されたLSAsに年をとらせるだけであるかもしれません。 ルータは早まって、他のルータによって溯源されたLSAsに年をとらせないかもしれません。 LSAによる1であるときに溯源された自己) LSAのAdvertising Routerによるルータの自己のRouter IDか2への同輩) LSAがネットワーク-LSAであり、Link州IDがルータの自己のIPインターフェース・アドレスの1つと等しいということであるという考えられて、ことです。
15. Virtual Links
15. 仮想のリンク
The single backbone area (Area ID = 0.0.0.0) cannot be disconnected, or some areas of the Autonomous System will become unreachable. To establish/maintain connectivity of the backbone, virtual links can be configured through non-backbone areas. Virtual links serve to connect physically separate components of the backbone. The two endpoints of a virtual link are area border routers. The virtual
ただ一つの背骨領域、(Area ID=0.0に、外されて、.0が)そうすることができないか、またはAutonomous Systemのいくつかの領域が望んでいる.0は手が届かなくなります。 背骨の接続性を確立するか、または維持するために、非背骨領域を通って仮想のリンクを構成できます。 仮想のリンクは、背骨の肉体的に別々のコンポーネントを接続するのに役立ちます。 仮想のリンクの2つの終点が境界ルータです。 仮想
Moy Standards Track [Page 135] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[135ページ]RFC2178OSPFバージョン1997年7月2日
link must be configured in both routers. The configuration information in each router consists of the other virtual endpoint (the other area border router), and the non-backbone area the two routers have in common (called the Transit area). Virtual links cannot be configured through stub areas (see Section 3.6).
両方のルータでリンクを構成しなければなりません。 各ルータにおける設定情報は他の仮想の終点(もう片方の境界ルータ)、および2つのルータが共通である非背骨領域(Transit領域と呼ばれる)から成ります。 スタッブ領域を通って仮想のリンクを構成できません(セクション3.6を見てください)。
The virtual link is treated as if it were an unnumbered point-to- point network belonging to the backbone and joining the two area border routers. An attempt is made to establish an adjacency over the virtual link. When this adjacency is established, the virtual link will be included in backbone router-LSAs, and OSPF packets pertaining to the backbone area will flow over the adjacency. Such an adjacency has been referred to in this document as a "virtual adjacency".
仮想のリンクはまるでそれが無数のポイントからポイントへの背骨に属して、2つの境界ルータに合流するネットワークであるかのように扱われます。 仮想のリンクの上に隣接番組を確立するのを試みをします。 この隣接番組が確立されるとき、仮想のリンクは背骨ルータ-LSAsに含まれるでしょう、そして、背骨領域に関係するOSPFパケットが隣接番組の上を流れるでしょう。 そのような隣接番組は本書では「仮想の隣接番組」と呼ばれました。
In each endpoint router, the cost and viability of the virtual link is discovered by examining the routing table entry for the other endpoint router. (The entry's associated area must be the configured Transit area). This is called the virtual link's corresponding routing table entry. The InterfaceUp event occurs for a virtual link when its corresponding routing table entry becomes reachable. Conversely, the InterfaceDown event occurs when its routing table entry becomes unreachable. In other words, the virtual link's viability is determined by the existence of an intra-area path, through the Transit area, between the two endpoints. Note that a virtual link whose underlying path has cost greater than hexadecimal 0xffff (the maximum size of an interface cost in a router-LSA) should be considered inoperational (i.e., treated the same as if the path did not exist).
それぞれの終点ルータでは、仮想のリンクの費用と生存力は、もう片方の終点ルータのための経路指定テーブルエントリーを調べることによって、発見されます。 (エントリーの関連地域は構成されたTransit領域であるに違いありません。) これは仮想のリンクの対応する経路指定テーブルエントリーと呼ばれます。 対応する経路指定テーブルエントリーが届くようになると、InterfaceUp出来事は仮想のリンクに起こります。 逆に、経路指定テーブルエントリーが手が届かなくなると、InterfaceDown出来事は起こります。 言い換えれば、仮想のリンクの生存力はイントラ領域経路の存在で決定します、Transit領域を通って、2つの終点の間で。 基本的な経路が費用を16進0xffff(ルータ-LSAのインタフェース費用の最大サイズ)よりすばらしくする仮想のリンクがinoperational(すなわち、まるで経路が存在していないかのように同じように扱われる)であると考えられるべきであることに注意してください。
The other details concerning virtual links are as follows:
仮想のリンクに関する他の詳細は以下の通りです:
o AS-external-LSAs are NEVER flooded over virtual adjacencies. This would be duplication of effort, since the same AS-external-LSAs are already flooded throughout the virtual link's Transit area. For this same reason, AS-external-LSAs are not summarized over virtual adjacencies during the Database Exchange process.
o ASの外部のLSAsは仮想の隣接番組の上で決して水につかっていません。 同じASの外部のLSAsが仮想のリンクのTransit領域中で既に水につかっているので、これは努力の複製でしょう。 この同じ理由で、ASの外部のLSAsはDatabase Exchangeの過程の間、仮想の隣接番組の上へまとめられません。
o The cost of a virtual link is NOT configured. It is defined to be the cost of the intra-area path between the two defining area border routers. This cost appears in the virtual link's corresponding routing table entry. When the cost of a virtual link changes, a new router-LSA should be originated for the backbone area.
o 仮想のリンクの費用は構成されません。 それは、境界ルータを定義する2つの間のイントラ領域経路の費用になるように定義されます。 この費用は仮想のリンクの対応する経路指定テーブルエントリーに現れます。 仮想のリンクの費用が変化するとき、新しいルータ-LSAは背骨領域に溯源されるべきです。
o Just as the virtual link's cost and viability are determined by the routing table build process (through construction of the routing table entry for the other endpoint), so are the IP interface address for the virtual interface and the virtual neighbor's IP address.
o ちょうど経路指定テーブル成型の過程(もう片方の終点のための経路指定テーブルエントリーの工事による)で仮想のリンクの費用と生存力が決定するように、仮想インターフェースへのIPインターフェース・アドレスと仮想の隣人のIPアドレスもそうです。
Moy Standards Track [Page 136] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[136ページ]RFC2178OSPFバージョン1997年7月2日
These are used when sending OSPF protocol packets over the virtual link. Note that when one (or both) of the virtual link endpoints connect to the Transit area via an unnumbered point-to-point link, it may be impossible to calculate either the virtual interface's IP address and/or the virtual neighbor's IP address, thereby causing the virtual link to fail.
仮想のリンクの上にプロトコルパケットをOSPFに送るとき、これらは使用されています。 仮想のリンクの1つ(ともに)であるときに、終点が無数のポイントツーポイント接続を通してTransit領域に接続するというメモ、仮想インターフェースのIPアドレス、そして/または、仮想の隣人のIPアドレスについて計算するのは不可能であるかもしれません、その結果、仮想のリンクが失敗することを引き起こします。
o In each endpoint's router-LSA for the backbone, the virtual link is represented as a Type 4 link whose Link ID is set to the virtual neighbor's OSPF Router ID and whose Link Data is set to the virtual interface's IP address. See Section 12.4.1 for more information.
o 背骨のための各終点のルータ-LSAでは、仮想のリンクはLink IDが仮想の隣人のOSPF Router IDに設定されて、Link Dataが仮想インターフェースのIPアドレスに用意ができているType4リンクとして表されます。 詳しい情報に関してセクション12.4.1を見てください。
o A non-backbone area can carry transit data traffic (i.e., is considered a "transit area") if and only if it serves as the Transit area for one or more fully adjacent virtual links (see TransitCapability in Sections 6 and 16.1). Such an area requires special treatment when summarizing backbone networks into it (see Section 12.4.3), and during the routing calculation (see Section 16.3).
o そして、非背骨領域がトランジットデータ通信量(すなわち、「トランジット領域」であると考えられる)を運ぶことができる、Transit領域として個人的にはか、より完全に隣接している仮想のリンクに役立つ場合にだけ(セクション6と16.1でTransitCapabilityを見てください)。 それ(セクション12.4.3を見る)の中と、そして、ルーティング計算間背骨ネットワークをまとめるとき、そのような領域は特別な処理を必要とします(セクション16.3を見てください)。
o The time between link state retransmissions, RxmtInterval, is configured for a virtual link. This should be well over the expected round-trip delay between the two routers. This may be hard to estimate for a virtual link; it is better to err on the side of making it too large.
o リンク州の「再-トランスミッション」の間の時間(RxmtInterval)は仮想のリンクに構成されます。 2つのルータの間には、予想された往復の遅れのかなり上にこれはあるべきです。 これは仮想のリンクに見積もっているのは困難であるかもしれません。 それを大きくし過ぎることの側で間違えるほうがよいです。
16. Calculation of the routing table
16. 経路指定テーブルの計算
This section details the OSPF routing table calculation. Using its attached areas' link state databases as input, a router runs the following algorithm, building its routing table step by step. At each step, the router must access individual pieces of the link state databases (e.g., a router-LSA originated by a certain router). This access is performed by the lookup function discussed in Section 12.2. The lookup process may return an LSA whose LS age is equal to MaxAge. Such an LSA should not be used in the routing table calculation, and is treated just as if the lookup process had failed.
このセクションはOSPF経路指定テーブル計算を詳しく述べます。 入力されるように付属領域のリンク州のデータベースを使用して、ルータは以下のアルゴリズムを走らせます、一歩一歩経路指定テーブルを組立てて。 各ステップでは、ルータはリンク州のデータベースの個体にアクセスしなければなりません(例えば、ルータ-LSAはあるルータで由来しました)。 このアクセスはセクション12.2で議論したルックアップ機能によって実行されます。 ルックアップの過程はLS年令がMaxAgeと等しいLSAを返すかもしれません。 そのようなLSAを経路指定テーブル計算に使用するべきでなくて、まるでまさしくルックアップの過程が失敗したかのように扱います。
The OSPF routing table's organization is explained in Section 11. Two examples of the routing table build process are presented in Sections 11.2 and 11.3. This process can be broken into the following steps:
OSPF経路指定テーブルの組織はセクション11で説明されます。 経路指定テーブル成型の過程に関する2つの例がセクション11.2と11.3に提示されます。 以下の階段をこの過程に細かく分けることができます:
(1) The present routing table is invalidated. The routing table is
built again from scratch. The old routing table is saved so
that changes in routing table entries can be identified.
(1) 現在の経路指定テーブルは無効にされます。 経路指定テーブルは最初から、再び組立てられます。 古い経路指定テーブルは、経路指定テーブルエントリーにおける変化を特定できるように取っておかれます。
Moy Standards Track [Page 137] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[137ページ]RFC2178OSPFバージョン1997年7月2日
(2) The intra-area routes are calculated by building the shortest-
path tree for each attached area. In particular, all routing
table entries whose Destination Type is "area border router" are
calculated in this step. This step is described in two parts.
At first the tree is constructed by only considering those links
between routers and transit networks. Then the stub networks
are incorporated into the tree. During the area's shortest-path
tree calculation, the area's TransitCapability is also
calculated for later use in Step 4.
(2) イントラ領域ルートは、それぞれの付属領域に最も低い経路木を建てることによって、計算されます。 特に、Destination Typeが「領域境界ルータ」であるすべての経路指定テーブルエントリーがこのステップで計算されます。 このステップは2つの部品で説明されます。 初めに、木は、ルータと輸送網とのそれらのリンクを考えるだけで組み立てられます。 そして、スタッブネットワークは木に組み入れられます。 また、領域の最短パス木の計算の間、領域のTransitCapabilityはStep4における後の使用のために計算されます。
(3) The inter-area routes are calculated, through examination of
summary-LSAs. If the router is attached to multiple areas
(i.e., it is an area border router), only backbone summary-LSAs
are examined.
(3) 相互領域ルートは概要-LSAsの試験で計算されます。 ルータが複数の領域に付けられるなら(すなわち、それは境界ルータです)、背骨だけ概要-LSAsは調べられます。
(4) In area border routers connecting to one or more transit areas
(i.e, non-backbone areas whose TransitCapability is found to be
TRUE), the transit areas' summary-LSAs are examined to see
whether better paths exist using the transit areas than were
found in Steps 2-3 above.
(4) 1つ以上のトランジット領域(i.e、TransitCapabilityがTRUEであることがわかっている非背骨領域)に接続する境界ルータでは、トランジット領域の概要-LSAsは、上でSteps2-3で見つけられたより良い経路がトランジット領域を使用することで存在するかどうか確認するために調べられます。
(5) Routes to external destinations are calculated, through
examination of AS-external-LSAs. The locations of the AS
boundary routers (which originate the AS-external-LSAs) have
been determined in steps 2-4.
(5) 外部の目的地へのルートはASの外部のLSAsの試験で計算されます。 AS境界ルータ(ASの外部のLSAsを溯源する)の位置はステップ2-4で断固としています。
Steps 2-5 are explained in further detail below.
ステップ2-5は以下の詳細で説明されます。
Changes made to routing table entries as a result of these calculations can cause the OSPF protocol to take further actions. For example, a change to an intra-area route will cause an area border router to originate new summary-LSAs (see Section 12.4). See
これらの計算の結果、経路指定テーブルエントリーにされた変更で、OSPFプロトコルはさらなる行動を取ることができます。 例えば、イントラ領域ルートへの変化で、境界ルータは新しい概要-LSAsを溯源するでしょう(セクション12.4を見てください)。 見てください。
Section 16.7 for a complete list of the OSPF protocol actions resulting from routing table changes.
OSPFに関する全リストのためのセクション16.7は経路指定テーブル変化から生じる動作について議定書の中で述べます。
16.1. Calculating the shortest-path tree for an area
16.1. 最短パス木について領域に計算します。
This calculation yields the set of intra-area routes associated with an area (called hereafter Area A). A router calculates the shortest-path tree using itself as the root.[22] The formation of the shortest path tree is done here in two stages. In the first stage, only links between routers and transit networks are considered. Using the Dijkstra algorithm, a tree is formed from this subset of the link state database. In the second stage, leaves are added to the tree by considering the links to stub networks.
この計算は領域(今後、Area Aと呼ぶ)に関連しているイントラ領域ルートのセットをもたらします。 ルータは、最短パス木の構成がここ、2つの段階で行われる根の.[22]としてそれ自体を使用することで最短パス木について計算します。 第一段階では、ルータと輸送網とのリンクだけが考えられます。 ダイクストラアルゴリズムを使用して、木はリンク州のデータベースのこの部分集合から形成されます。 2番目の段階では、リンクがネットワークを引き抜くと考えることによって、葉は木に加えられます。
Moy Standards Track [Page 138] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[138ページ]RFC2178OSPFバージョン1997年7月2日
The procedure will be explained using the graph terminology that was introduced in Section 2. The area's link state database is represented as a directed graph. The graph's vertices are routers, transit networks and stub networks. The first stage of the procedure concerns only the transit vertices (routers and transit networks) and their connecting links. Throughout the shortest path calculation, the following data is also associated with each transit vertex:
手順は、セクション2で紹介されたグラフ用語を使用することで説明されるでしょう。 領域のリンク州のデータベースは有向グラフとして表されます。 グラフの頭頂は、ルータと、輸送網とスタッブネットワークです。 手順の第一段階はトランジット頭頂(ルータと輸送網)とそれらの結合リンクだけに関係があります。 また、最短パス計算の間中、以下のデータもそれぞれのトランジット頂点に関連しています:
Vertex (node) ID
A 32-bit number uniquely identifying the vertex. For router
vertices this is the router's OSPF Router ID. For network
vertices, this is the IP address of the network's Designated
Router.
唯一頂点を特定する頂点の(ノード)IDのA32ビットの番号。 ルータ頭頂に関しては、これはルータのOSPF Router IDです。 ネットワーク頭頂に関しては、これはネットワークのDesignated RouterのIPアドレスです。
An LSA
Each transit vertex has an associated LSA. For router
vertices, this is a router-LSA. For transit networks, this
is a network-LSA (which is actually originated by the
network's Designated Router). In any case, the LSA's Link
State ID is always equal to the above Vertex ID.
LSA Eachトランジット頂点には、関連LSAがあります。 ルータ頭頂に関しては、これはルータ-LSAです。 輸送網において、これはネットワーク-LSA(実際にネットワークのDesignated Routerによって溯源される)です。 どのような場合でも、LSAのLink州IDはいつも上のVertex IDと等しいです。
List of next hops
The list of next hops for the current set of shortest paths
from the root to this vertex. There can be multiple
shortest paths due to the equal-cost multipath capability.
Each next hop indicates the outgoing router interface to use
when forwarding traffic to the destination. On broadcast,
Point-to-MultiPoint and NBMA networks, the next hop also
includes the IP address of the next router (if any) in the
path towards the destination.
次のリストは現在のセットの最短パスのために根からこの頂点まで次のホップのリストを飛び越します。 等価コストマルチパス能力への複数の最短パス支払われるべきものがあることができます。 次の各ホップは交通を目的地に送るとき使用する外向的なルータインタフェースを示します。 また、放送、PointからMultiPoint、およびNBMAネットワークでは、次のホップは経路で次のルータ(もしあれば)のIPアドレスを目的地に向かって含めます。
Distance from root
The link state cost of the current set of shortest paths
from the root to the vertex. The link state cost of a path
is calculated as the sum of the costs of the path's
constituent links (as advertised in router-LSAs and
network-LSAs). One path is said to be "shorter" than
another if it has a smaller link state cost.
根から、現在のセットの最短パスのリンク州の費用を根から頂点まで遠ざけてください。 経路の成分のコストの合計がリンクされるとき(ルータ-LSAsとネットワーク-LSAsの広告に掲載されているように)、経路のリンク州の費用は計算されます。 それによりわずかなリンク州の費用があるなら、1つの経路が「別のものより短い」と言われます。
The first stage of the procedure (i.e., the Dijkstra algorithm) can now be summarized as follows. At each iteration of the algorithm, there is a list of candidate vertices. Paths from the root to these vertices have been found, but not necessarily the shortest ones. However, the paths to the candidate vertex that is closest to the root are guaranteed to be shortest; this vertex is added to the shortest-path tree, removed from the candidate list, and its adjacent
現在、以下の通り手順(すなわち、ダイクストラアルゴリズム)の第一段階をまとめることができます。 アルゴリズムの各繰り返しには、候補頭頂のリストがあります。 根からこれらの頭頂までの経路が見つけられましたが、必ず最も短い方に見つけられていません。 しかしながら、根の最も近くにある候補頂点への経路は最も短くなるように保証されます。 この頂点は候補リストから取り除かれた最短パス木に加えられます、そして、それは隣接しています。
Moy Standards Track [Page 139] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[139ページ]RFC2178OSPFバージョン1997年7月2日
vertices are examined for possible addition to/modification of the candidate list. The algorithm then iterates again. It terminates when the candidate list becomes empty.
頭頂は候補リストの/変更への可能な添加がないかどうか調べられます。 その時が再び繰り返すアルゴリズム。 候補リストが空になると、それは終わります。
The following steps describe the algorithm in detail. Remember that we are computing the shortest path tree for Area A. All references to link state database lookup below are from Area A's database.
以下のステップは詳細にアルゴリズムを説明します。 私たちがArea A.のために最短パス木を計算しているのを覚えていてください。以下の州のデータベースルックアップをリンクするAll参照はArea Aのデータベースから来ています。
(1) Initialize the algorithm's data structures. Clear the list
of candidate vertices. Initialize the shortest-path tree to
only the root (which is the router doing the calculation).
Set Area A's TransitCapability to FALSE.
(1) アルゴリズムのデータ構造を初期化してください。 候補頭頂をリストから取り除いてください。 根(計算をするルータである)だけに最短パス木を初期化してください。 領域AのTransitCapabilityを誤っているのに設定してください。
(2) Call the vertex just added to the tree vertex V. Examine
the LSA associated with vertex V. This is a lookup in the
Area A's link state database based on the Vertex ID. If
this is a router-LSA, and bit V of the router-LSA (see
Section A.4.2) is set, set Area A's TransitCapability to
TRUE. In any case, each link described by the LSA gives the
cost to an adjacent vertex. For each described link, (say
it joins vertex V to vertex W):
(2) 頂点がただLSAが頂点V.Thisに関連づけた木の頂点V.Examineに加えた呼び出しはVertex IDに基づくArea Aのリンク州のデータベースのルックアップです。 これがルータ-LSAであり、ルータ-LSA(セクションA.4.2を見る)のビットVが設定されるなら、Area AのTransitCapabilityをTRUEに設定してください。 どのような場合でも、LSAによって説明された各リンクは隣接している頂点への費用を与えます。 説明されたそれぞれに関してはリンクしてください、(頂点Vを頂点Wに接合すると言います):
(a) If this is a link to a stub network, examine the next
link in V's LSA. Links to stub networks will be
considered in the second stage of the shortest path
calculation.
(a) これがスタッブネットワークへのリンクであるなら、V LSAで次のリンクを調べてください。 ネットワークを引き抜くリンクは最短パス計算の2番目の段階で考えられるでしょう。
(b) Otherwise, W is a transit vertex (router or transit
network). Look up the vertex W's LSA (router-LSA or
network-LSA) in Area A's link state database. If the
LSA does not exist, or its LS age is equal to MaxAge, or
it does not have a link back to vertex V, examine the
next link in V's LSA.[23]
(b) さもなければ、Wはトランジット頂点(ルータかトランジットネットワーク)です。 Area Aのリンク州のデータベースで頂点WのLSA(ルータ-LSAかネットワーク-LSA)を見上げてください。 LSAが存在していないか、LS年令がMaxAgeと等しいか、または頂点Vにリンクを返してもらわないなら、V LSAで次のリンクを調べてください。[23]
(c) If vertex W is already on the shortest-path tree,
examine the next link in the LSA.
(c) 最短パス木の上に頂点Wが既にあるなら、LSAで次のリンクを調べてください。
(d) Calculate the link state cost D of the resulting path
from the root to vertex W. D is equal to the sum of the
link state cost of the (already calculated) shortest
path to vertex V and the advertised cost of the link
between vertices V and W. If D is:
(d) 結果として起こる根から頂点W.Dまでの経路のリンク州の費用Dが頂点Vへの(既に計算されています)の最短パスのリンク州の費用と頭頂Vの間のリンクの広告を出している費用の合計と等しく、W.If Dは以下の通りであると見込んでください。
o Greater than the value that already appears for
vertex W on the candidate list, then examine the
next link.
o 候補リストで既に頂点Wの弁護に出廷する値よりすばらしくて、そして、次のリンクを調べてください。
Moy Standards Track [Page 140] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[140ページ]RFC2178OSPFバージョン1997年7月2日
o Equal to the value that appears for vertex W on the
candidate list, calculate the set of next hops that
result from using the advertised link. Input to
this calculation is the destination (W), and its
parent (V). This calculation is shown in Section
16.1.1. This set of hops should be added to the
next hop values that appear for W on the candidate
list.
o 候補リストで頂点Wの弁護に出廷する値と等しいです、広告を出しているリンクを使用するので、結果として生じる次のホップのセットについて計算してください。 この計算に入力されているのは、目的地(W)と、その親(V)です。 この計算はセクション16.1.1で示されます。 このセットのホップは候補リストでWの弁護に出廷する次のホップ値に加えられるべきです。
o Less than the value that appears for vertex W on the
candidate list, or if W does not yet appear on the
candidate list, then set the entry for W on the
candidate list to indicate a distance of D from the
root. Also calculate the list of next hops that
result from using the advertised link, setting the
next hop values for W accordingly. The next hop
calculation is described in Section 16.1.1; it takes
as input the destination (W) and its parent (V).
o 候補リストで頂点Wの弁護に出廷する値よりそれほど、またはWが候補リストにまだ現れていないなら、根からDの距離に示す候補リストにWのためのエントリーを設定してください。 また、広告を出しているリンクを使用するので、結果として生じる次のホップのリストについて計算してください、それに従って、次のホップ値をWに設定して。 次のホップ計算はセクション16.1.1で説明されます。 目的地(W)とその親(V)を入力するとき、それは取ります。
(3) If at this step the candidate list is empty, the shortest-
path tree (of transit vertices) has been completely built
and this stage of the procedure terminates. Otherwise,
choose the vertex belonging to the candidate list that is
closest to the root, and add it to the shortest-path tree
(removing it from the candidate list in the process). Note
that when there is a choice of vertices closest to the root,
network vertices must be chosen before router vertices in
order to necessarily find all equal-cost paths. This is
consistent with the tie-breakers that were introduced in the
modified Dijkstra algorithm used by OSPF's Multicast routing
extensions (MOSPF).
(3) 候補リストがこのステップで空であるなら、最も低い経路木(トランジット頭頂の)は完全に建てられました、そして、手順のこのステージは終わります。 さもなければ、根の最も近くにある候補リストに属す頂点を選んでください、そして、最短パス木(過程による候補リストからそれを取り除く)にそれを加えてください。 頭頂の選択が根の最も近くにあるとき、必ずすべての等しい費用経路を見つけるためにルータ頭頂の前でネットワーク頭頂を選ばなければならないことに注意してください。 これはOSPFのMulticastルーティング拡張子(MOSPF)で使用される変更されたダイクストラアルゴリズムで導入されたタイブレークと一致しています。
(4) Possibly modify the routing table. For those routing table
entries modified, the associated area will be set to Area A,
the path type will be set to intra-area, and the cost will
be set to the newly discovered shortest path's calculated
distance.
(4) ことによると経路指定テーブルを変更してください。 エントリーが変更したテーブルを発送するものにおいて、関連領域はArea Aに設定されて、経路タイプはイントラ領域に用意ができて、費用は新たに発見された最短パスの計算された距離に設定されるでしょう。
If the newly added vertex is an area border router or AS
boundary router, a routing table entry is added whose
destination type is "router". The Options field found in
the associated router-LSA is copied into the routing table
entry's Optional capabilities field. Call the newly added
vertex Router X. If Router X is the endpoint of one of the
calculating router's virtual links, and the virtual link
uses Area A as Transit area: the virtual link is declared
up, the IP address of the virtual interface is set to the IP
address of the outgoing interface calculated above for
新たに加えられた頂点が境界ルータかAS境界ルータであるなら、目的地タイプが「ルータ」である経路指定テーブルエントリーは加えられます。 関連ルータ-LSAで見つけられたOptions分野は経路指定テーブルエントリーのOptional能力分野にコピーされます。 Router X.に新たに加えられた頂点に電話をしてください。If Router Xは計算のルータの仮想のリンクの1つの終点です、そして、仮想のリンクはTransit領域としてArea Aを使用します: 仮想のリンクは上がると申告されて、仮想インターフェースのIPアドレスは外向的なインタフェースのアドレスが上で計算したIPに設定されます。
Moy Standards Track [Page 141] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[141ページ]RFC2178OSPFバージョン1997年7月2日
Router X, and the virtual neighbor's IP address is set to
Router X's interface address (contained in Router X's
router-LSA) that points back to the root of the shortest-
path tree; equivalently, this is the interface that points
back to Router X's parent vertex on the shortest-path tree
(similar to the calculation in Section 16.1.1).
ルータX、および仮想の隣人のIPアドレスは最も低い経路木の根を示すRouter Xのインターフェース・アドレス(Router Xのルータ-LSAでは、含まれている)に設定されます。 同等に、これは最短パス木(セクション16.1.1における計算と同様の)の上にRouter Xの親頂点を示すインタフェースです。
If the newly added vertex is a transit network, the routing
table entry for the network is located. The entry's
Destination ID is the IP network number, which can be
obtained by masking the Vertex ID (Link State ID) with its
associated subnet mask (found in the body of the associated
network-LSA). If the routing table entry already exists
(i.e., there is already an intra-area route to the
destination installed in the routing table), multiple
vertices have mapped to the same IP network. For example,
this can occur when a new Designated Router is being
established. In this case, the current routing table entry
should be overwritten if and only if the newly found path is
just as short and the current routing table entry's Link
State Origin has a smaller Link State ID than the newly
added vertex' LSA.
新たに加えられた頂点がトランジットネットワークであるなら、ネットワークのための経路指定テーブルエントリーは見つけられています。 エントリーのDestination IDはIPネットワーク・ナンバーです。(関連サブネットマスク(関連ネットワーク-LSAのボディーでは、見つけられる)でVertex ID(リンク州ID)にマスクをかけることによって、そのネットワーク・ナンバーを得ることができます)。 経路指定テーブルエントリーが既に存在しているなら(すなわち、既に、経路指定テーブルにインストールされた目的地へのイントラ領域ルートがあります)、複数の頭頂が同じIPにネットワークを写像しました。 新しいDesignated Routerが設立されているとき、例えば、これは起こることができます。 そして、'この場合現在の経路指定テーブルエントリーが上書きされるべきである、新たに見つけられた経路がちょうど同じくらい短く、現在の経路指定テーブルエントリーのLink州Originに新たに加えられた頂点'LSAより小さいLink州IDがある場合にだけ。
If there is no routing table entry for the network (the
usual case), a routing table entry for the IP network should
be added. The routing table entry's Link State Origin
should be set to the newly added vertex' LSA.
ネットワーク(普通のケース)のための経路指定テーブルエントリーが全くなければ、IPネットワークのための経路指定テーブルエントリーは加えられるべきです。 '経路指定テーブルエントリー'のLink州Originは新たに加えられた頂点'LSAに用意ができるべきです。
(5) Iterate the algorithm by returning to Step 2.
(5) Step2に戻ることによって、アルゴリズムを繰り返してください。
The stub networks are added to the tree in the procedure's second stage. In this stage, all router vertices are again examined. Those that have been determined to be unreachable in the above first phase are discarded. For each reachable router vertex (call it V), the associated router-LSA is found in the link state database. Each stub network link appearing in the LSA is then examined, and the following steps are executed:
スタッブネットワークはプロシージャの2番目の段階の木に加えられます。 この段階では、すべてのルータ頭頂が再び調べられます。 上の第1段階で手が届かないと決心しているものは捨てられます。 それぞれの届いているルータ頂点(それをVと呼ぶ)に関しては、関連ルータ-LSAはリンク州のデータベースで見つけられます。 次に、LSAに現れるそれぞれのスタッブネットワークリンクは調べられます、そして、以下のステップは実行されます:
(1) Calculate the distance D of stub network from the root. D
is equal to the distance from the root to the router vertex
(calculated in stage 1), plus the stub network link's
advertised cost. Compare this distance to the current best
cost to the stub network. This is done by looking up the
stub network's current routing table entry. If the
calculated distance D is larger, go on to examine the next
stub network link in the LSA.
(1) 根からスタッブネットワークの距離Dについて計算してください。 Dはルータ頂点(段階1では、計算される)、および根から広告を出しているスタッブネットワークリンクの費用まで距離と等しいです。 スタッブネットワークへの現在の最も良い費用にこの距離をたとえてください。 スタッブネットワークの現在の経路指定テーブルエントリーを見上げることによって、これをします。 計算された距離Dが、より大きいなら、LSAで次のスタッブネットワークリンクを調べ続けてください。
Moy Standards Track [Page 142] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[142ページ]RFC2178OSPFバージョン1997年7月2日
(2) If this step is reached, the stub network's routing table
entry must be updated. Calculate the set of next hops that
would result from using the stub network link. This
calculation is shown in Section 16.1.1; input to this
calculation is the destination (the stub network) and the
parent vertex (the router vertex). If the distance D is the
same as the current routing table cost, simply add this set
of next hops to the routing table entry's list of next hops.
In this case, the routing table already has a Link State
Origin. If this Link State Origin is a router-LSA whose
Link State ID is smaller than V's Router ID, reset the Link
State Origin to V's router-LSA.
(2) このステップに達しているなら、スタッブネットワークの経路指定テーブルエントリーをアップデートしなければなりません。 スタッブネットワークリンクを使用するので、結果として生じる次のホップのセットについて計算してください。 この計算はセクション16.1.1で示されます。 この計算に入力されているのは、目的地(スタッブネットワーク)と親頂点(ルータ頂点)です。 距離Dが現在の経路指定テーブル費用と同じであるなら、単に経路指定テーブルエントリーの次のホップのリストにこのセットの次のホップを追加してください。 この場合、経路指定テーブルには、Link州Originが既にあります。 このLink州OriginがLink州IDがV Router IDより小さいルータ-LSAであるなら、Vルータ-LSAにLink州Originをリセットしてください。
Otherwise D is smaller than the routing table cost.
Overwrite the current routing table entry by setting the
routing table entry's cost to D, and by setting the entry's
list of next hops to the newly calculated set. Set the
routing table entry's Link State Origin to V's router-LSA.
Then go on to examine the next stub network link.
さもなければ、Dは経路指定テーブル費用より小さいです。 経路指定テーブルエントリーの費用をDに設定して、エントリーの次のホップのリストを新たに計算されたセットに設定することによって、現在の経路指定テーブルエントリーを上書きしてください。 経路指定テーブルエントリーのLink州OriginをVルータ-LSAに設定してください。 そして、次のスタッブネットワークリンクを調べ続けてください。
For all routing table entries added/modified in the second stage, the associated area will be set to Area A and the path type will be set to intra-area. When the list of reachable router-LSAs is exhausted, the second stage is completed. At this time, all intra-area routes associated with Area A have been determined.
2番目の段階で加えられるか、または変更されたすべての経路指定テーブルエントリーにおいて関連領域はArea Aに設定されるでしょう、そして、経路タイプはイントラ領域に用意ができるでしょう。 届いているルータ-LSAsのリストが空になるとき、2番目のステージは完成します。 このとき、Area Aに関連しているすべてのイントラ領域ルートが決定しています。
The specification does not require that the above two stage method be used to calculate the shortest path tree. However, if another algorithm is used, an identical tree must be produced. For this reason, it is important to note that links between transit vertices must be bidirectional in order to be included in the above tree. It should also be mentioned that more efficient algorithms exist for calculating the tree; for example, the incremental SPF algorithm described in [Ref1].
仕様は、上の2ステージ方法が最短パス木について計算するのに使用されるのを必要としません。 しかしながら、別のアルゴリズムが使用されているなら、同じ木を生産しなければなりません。 この理由で、トランジット頭頂の間のリンクが上の木に含まれているように双方向でなければならないことに注意するのは重要です。 また、より効率的なアルゴリズムが木について計算するために存在すると言及されるべきです。 例えば[Ref1]で説明された増加のSPFアルゴリズム。
Moy Standards Track [Page 143] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[143ページ]RFC2178OSPFバージョン1997年7月2日
16.1.1. The next hop calculation
16.1.1. 次のホップ計算
This section explains how to calculate the current set of next hops to use for a destination. Each next hop consists of the outgoing interface to use in forwarding packets to the destination together with the IP address of the next hop router (if any). The next hop calculation is invoked each time a shorter path to the destination is discovered. This can happen in either stage of the shortest-path tree calculation (see Section 16.1). In stage 1 of the shortest-path tree calculation a shorter path is found as the destination is added to the candidate list, or when the destination's entry on the candidate list is modified (Step 2d of Stage 1). In stage 2 a shorter path is discovered each time the destination's routing table entry is modified (Step 2 of Stage 2).
このセクションは目的地に使用する現在のセットの次のホップについて計算する方法を説明します。 次の各ホップは次のホップルータ(もしあれば)のIPアドレスと共に推進パケットで目的地に使用する外向的なインタフェースから成ります。 目的地への、より短い経路が発見されるたびに次のホップ計算は呼び出されます。 これは最短パス木の計算のどちらの段階でも起こることができます(セクション16.1を見てください)。 最短パス木の計算の段階1では、目的地が候補リストに追加されるとき、より短い経路は見つけられて、候補リストの上の目的地のエントリーがいつ変更されているかを(Stage1のステップ2d)そうされます。 段階2では、目的地の経路指定テーブルエントリーが変更されているたびに(Stage2のステップ2)より短い経路は発見されます。
The set of next hops to use for the destination may be recalculated several times during the shortest-path tree calculation, as shorter and shorter paths are discovered. In the end, the destination's routing table entry will always reflect the next hops resulting from the absolute shortest path(s).
目的地に使用する次のホップのセットは最短パス木の計算の間、何度か再計算されるかもしれません、ますます短い経路が発見されるように。 結局、目的地の経路指定テーブルエントリーはいつも絶対最短パスから生じる次のホップを反映するでしょう。
Input to the next hop calculation is a) the destination and b) its parent in the current shortest path between the root (the calculating router) and the destination. The parent is always a transit vertex (i.e., always a router or a transit network).
次のホップ計算に入力されているのは、根(計算のルータ)と目的地の間の現在の最短パスでa) 目的地とb) その親です。 いつも親はトランジット頂点(すなわち、いつもルータかトランジットネットワーク)です。
If there is at least one intervening router in the current shortest path between the destination and the root, the destination simply inherits the set of next hops from the parent. Otherwise, there are two cases. In the first case, the parent vertex is the root (the calculating router itself). This means that the destination is either a directly connected network or directly connected router. The outgoing interface in this case is simply the OSPF interface connecting to the destination network/router. If the destination is a router which connects to the calculating router via a Point-to- MultiPoint network, the destination's next hop IP address(es) can be determined by examining the destination's router-LSA: each link pointing back to the calculating router and having a Link Data field belonging to the Point-to-MultiPoint network provides an IP address of the next hop router. If the destination is a directly connected network, or a router which connects to the calculating router via a point-to-point interface, no next hop IP address is required. If the destination is a router connected to the calculating router via a virtual link, the setting of the next hop should be deferred until the calculation in Section 16.3.
目的地と根の間には、現在の最短パスに少なくとも1つの介入しているルータがあれば、目的地は親から次のホップのセットを単に引き継ぎます。 さもなければ、2つのケースがあります。 前者の場合、親頂点は根(計算のルータ自体)です。 これは、目的地が直接接続されたネットワークか直接接続されたルータのどちらかであることを意味します。 この場合、外向的なインタフェースは単に送信先ネットワーク/ルータに接続するOSPFインタフェースです。 目的地がPointからMultiPointへのネットワークを通して計算のルータに接続するルータであるなら、目的地の次のホップIPアドレス(es)は目的地のルータ-LSAを調べることによって、決定できます: 計算のルータを示して、PointからMultiPointへのネットワークに属すLink Data分野を持っている各リンクが次のホップルータのIPアドレスを提供します。 目的地が直接接続されたネットワーク、または二地点間インタフェースを通して計算のルータに接続するルータであるなら、次のホップIPアドレスは全く必要ではありません。 目的地が仮想のリンクを通して計算のルータに関連づけられたルータであるなら、次のホップの設定はセクション16.3で計算まで延期されるべきです。
Moy Standards Track [Page 144] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[144ページ]RFC2178OSPFバージョン1997年7月2日
In the second case, the parent vertex is a network that directly connects the calculating router to the destination router. The list of next hops is then determined by examining the destination's router-LSA. For each link in the router-LSA that points back to the parent network, the link's Link Data field provides the IP address of a next hop router. The outgoing interface to use can then be derived from the next hop IP address (or it can be inherited from the parent network).
2番目の場合では、親頂点は直接計算のルータを目的地のルータに関連づけるネットワークです。 そして、次のホップのリストは、目的地のルータ-LSAを調べることによって、決定します。 親ネットワークへの指すルータ-LSA後部の各リンクに、リンクのLink Data分野は次のホップルータのIPアドレスを供給します。 そして、次のホップIPアドレスから使用する外向的なインタフェースを得ることができます(親ネットワークからそれを引き継ぐことができます)。
16.2. Calculating the inter-area routes
16.2. 相互領域ルートを計算します。
The inter-area routes are calculated by examining summary-LSAs. If the router has active attachments to multiple areas, only backbone summary-LSAs are examined. Routers attached to a single area examine that area's summary-LSAs. In either case, the summary-LSAs examined below are all part of a single area's link state database (call it Area A).
相互領域ルートは、概要-LSAsを調べることによって、計算されます。 ルータが複数の領域にアクティブな付属を持っているなら、背骨だけ概要-LSAsは調べられます。 ただ一つの領域に付けられたルータはその領域の概要-LSAsを調べます。 どちらかの場合では、以下で調べられた概要-LSAsはすべてただ一つの領域のリンク州のデータベースの一部(それをArea Aと呼ぶ)です。
Summary-LSAs are originated by the area border routers. Each summary-LSA in Area A is considered in turn. Remember that the destination described by a summary-LSA is either a network (Type 3 summary-LSAs) or an AS boundary router (Type 4 summary-LSAs). For each summary-LSA:
概要-LSAsは境界ルータによって溯源されます。 Area Aの各概要-LSAは順番に考えられます。 概要-LSAによって説明された目的地がネットワーク(3概要-LSAsをタイプする)かAS境界ルータのどちらかであることを覚えていてください(4概要-LSAsをタイプしてください)。 各概要-LSAのために:
(1) If the cost specified by the LSA is LSInfinity, or if the
LSA's LS age is equal to MaxAge, then examine the the next
LSA.
(1) LSAによって指定された費用がLSInfinityである、またはLSAのLS年令がMaxAgeと等しいなら、次のLSAを調べてください。
(2) If the LSA was originated by the calculating router itself,
examine the next LSA.
(2) LSAが計算のルータ自体によって溯源されたなら、次のLSAを調べてください。
(3) If it is a Type 3 summary-LSA, and the collection of
destinations described by the summary-LSA equals one of the
router's configured area address ranges (see Section 3.5),
and the particular area address range is active, then the
summary-LSA should be ignored. "Active" means that there
are one or more reachable (by intra-area paths) networks
contained in the area range.
(3) それがType3概要-LSAであり、ルータの構成された領域アドレスの概要-LSA同輩1によって説明された目的地の収集が及んで(セクション3.5を見てください)、特定の領域のアドレスの範囲がアクティブであるなら、概要-LSAは無視されるべきです。 「アクティブ」は、領域の範囲に保管されていた1つ以上の届いている(イントラ領域経路のそばの)ネットワークがあることを意味します。
(4) Else, call the destination described by the LSA N (for Type
3 summary-LSAs, 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), and the area border originating the LSA
BR. Look up the routing table entry for BR having Area A as
its associated area. If no such entry exists for router BR
(i.e., BR is unreachable in Area A), do nothing with this
LSA and consider the next in the list. Else, this LSA
(4) ほかに、LSA N(Type3概要-LSAsにおいて、ネットワーク/サブネットマスクがLSAのボディーに含まれている状態でLSAのLink州IDにマスクをかけることによって、Nのアドレスを得ます)によって説明された目的地、およびLSA BRを溯源する領域の境界に電話をしてください。 関連領域としてArea Aを持っているBRのために経路指定テーブルエントリーを見上げてください。 どれかそのようなエントリーがルータBRのために存在しないなら(すなわち、BRはArea Aで手が届きません)、このLSAと共に何もしないでください、そして、リストの次を考えてください。 ほか、このLSA
Moy Standards Track [Page 145] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[145ページ]RFC2178OSPFバージョン1997年7月2日
describes an inter-area path to destination N, whose cost is
the distance to BR plus the cost specified in the LSA. Call
the cost of this inter-area path IAC.
費用がBRへの距離とLSAで指定された費用である目的地Nに相互領域経路について説明します。 IACにこの相互領域経路の費用に電話をしてください。
(5) Next, look up the routing table entry for the destination N.
(If N is an AS boundary router, look up the "router" routing
table entry associated with Area A). If no entry exists for
N or if the entry's path type is "type 1 external" or "type
2 external", then install the inter-area path to N, with
associated area Area A, cost IAC, next hop equal to the list
of next hops to router BR, and Advertising router equal to
BR.
(5) 次に、目的地N.のための経路指定テーブルエントリーを見上げてください(NがAS境界ルータであるなら、Area Aに関連している「ルータ」経路指定テーブルエントリーを見上げてください)。 エントリーが全くNのために存在していないか、エントリーの経路タイプが「外部であることの形で1をタイプする」か、または「外部であることの形で2をタイプし」て、次に、相互領域経路をNにインストールすることであるなら、関連領域Area Aと共に、IAC、BRと等しいルータBR、およびAdvertisingルータへの次のホップのリストと等しい次のホップかかってください。
(6) Else, if the paths present in the table are intra-area
paths, do nothing with the LSA (intra-area paths are always
preferred).
(6) ほかに、テーブルの現在の経路がイントラ領域経路であるなら、LSAと共に何もしないでください(イントラ領域経路はいつも好まれます)。
(7) Else, the paths present in the routing table are also
inter-area paths. Install the new path through BR if it is
cheaper, overriding the paths in the routing table.
Otherwise, if the new path is the same cost, add it to the
list of paths that appear in the routing table entry.
(7) ほかに、また、経路指定テーブルの現在の経路は相互領域経路です。 経路指定テーブルの経路をくつがえして、それが、より安いなら、BRを通して新しい経路をインストールしてください。 さもなければ、新しい経路が同じ費用であるなら経路指定テーブルエントリーに現れる経路のリストにそれを追加してください。
16.3. Examining transit areas' summary-LSAs
16.3. トランジット領域の概要-LSAsを調べます。
This step is only performed by area border routers attached to one or more non-backbone areas that are capable of carrying transit traffic (i.e., "transit areas", or those areas whose TransitCapability parameter has been set to TRUE in Step 2 of the Dijkstra algorithm (see Section 16.1).
このステップはトランジット交通を運ぶことができる1つ以上の非背骨領域への添付の境界ルータによって実行されるだけです。(すなわち、TransitCapabilityパラメタがダイクストラアルゴリズムのStep2にTRUEに設定された(セクション16.1を見ます)「トランジット領域」、またはそれらの領域。
The purpose of the calculation below is to examine the transit areas to see whether they provide any better (shorter) paths than the paths previously calculated in Sections 16.1 and 16.2. Any paths found that are better than or equal to previously discovered paths are installed in the routing table.
以下の計算の目的はそれらが何か以前にセクション16.1と16.2で計算された経路より良い(より短い)経路を提供するかどうかを見るためにトランジット領域を調べることです。 見つけられた以前に発見された経路と、より良いか、または等しいどんな経路も経路指定テーブルにインストールされます。
The calculation proceeds as follows. All the transit areas' summary- LSAs are examined in turn. Each such summary-LSA describes a route through a transit area Area A to a Network 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) or in the case of a Type 4 summary-LSA, to an AS boundary router N. Suppose also that the summary-LSA was originated by an area border router BR.
計算は以下の通り続きます。 すべてのトランジット領域概要のLSAsは順番に調べられます。 また、概要-LSAがN(ネットワーク/サブネットマスクがLSAのボディーに含まれている状態でLSAのLink州IDにマスクをかけることによって、Nのアドレスを得る)かType4概要-LSAの場合におけるNetwork、AS境界ルータN.Supposeへのトランジット領域Area Aを通したルートでしたが、領域境界ルータBRによって溯源されて、そのような概要-LSAが説明するそれぞれ。
(1) If the cost advertised by the summary-LSA is LSInfinity, or
if the LSA's LS age is equal to MaxAge, then examine the
next LSA.
(1) 概要-LSAによって広告に掲載された費用がLSInfinityである、またはLSAのLS年令がMaxAgeと等しいなら、次のLSAを調べてください。
Moy Standards Track [Page 146] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[146ページ]RFC2178OSPFバージョン1997年7月2日
(2) If the summary-LSA was originated by the calculating router
itself, examine the next LSA.
(2) 概要-LSAが計算のルータ自体によって溯源されたなら、次のLSAを調べてください。
(3) Look up the routing table entry for N. (If N is an AS
boundary router, look up the "router" routing table entry
associated with the backbone area). If it does not exist, or
if the route type is other than intra-area or inter-area, or
if the area associated with the routing table entry is not
the backbone area, then examine the next LSA. In other
words, this calculation only updates backbone intra-area
routes found in Section 16.1 and inter-area routes found in
Section 16.2.
(3) N.のための経路指定テーブルエントリーを見上げてください(NがAS境界ルータであるなら、背骨領域に関連している「ルータ」経路指定テーブルエントリーを見上げてください)。 存在していないか、イントラ領域か相互領域を除いて、ルートタイプがある、または経路指定テーブルエントリーに関連している地域が背骨領域でないなら、次のLSAを調べてください。 言い換えれば、この計算はセクション16.1で見つけられた背骨イントラ領域ルートとセクション16.2で見つけられた相互領域ルートをアップデートするだけです。
(4) Look up the routing table entry for the advertising router
BR associated with the Area A. If it is unreachable, examine
the next LSA. Otherwise, the cost to destination N is the
sum of the cost in BR's Area A routing table entry and the
cost advertised in the LSA. Call this cost IAC.
(4) 広告ルータBRがArea A.Ifにそれを関連づけたので、経路指定テーブルエントリーへの一見は手が届かなく、次のLSAを調べてください。 目的地Nへの費用は、さもなければ、BRのArea A経路指定テーブルエントリーにおける、費用の合計とLSAの広告に掲載された費用です。 IACにこの費用に電話をしてください。
(5) If this cost is less than the cost occurring in N's routing
table entry, overwrite N's list of next hops with those used
for BR, and set N's routing table cost to IAC. Else, if IAC
is the same as N's current cost, add BR's list of next hops
to N's list of next hops. In any case, the area associated
with N's routing table entry must remain the backbone area,
and the path type (either intra-area or inter-area) must
also remain the same.
(5) この費用がNの経路指定テーブルエントリーに起こる費用以下であるなら、それらがBRに使用されている状態で、Nの次のホップのリストを上書きしてください、そして、Nの経路指定テーブル費用をIACに設定してください。 IACがNの現在の費用と同じであるなら、ほかに、BRの次のホップのリストをNの次のホップのリストに追加してください。 どのような場合でも、Nの経路指定テーブルエントリーに関連している領域は背骨領域のままで残らなければなりません、そして、また、経路タイプ(イントラ領域か相互領域のどちらか)は同じままでいなければなりません。
Moy Standards Track [Page 147] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[147ページ]RFC2178OSPFバージョン1997年7月2日
. Area 1 (transit) . +
. . |
. +---+1 1+---+100 |
. |RT2|----------|RT4|=========|
. 1/+---+********* +---+ |
. /******* . |
. 1/*Virtual . |
1+---+/* Link . Net|work
=======|RT1|* . | N1
+---+\ . |
. \ . |
. \ . |
. 1\+---+1 1+---+20 |
. |RT3|----------|RT5|=========|
. +---+ +---+ |
. . |
........................ +
. 領域1(トランジット)+。| . +---+1 1+---+100 | . |RT2|----------|RT4|=========| . 1/+---+********* +---+ | . /******* . | . 1/*仮想です。| 1+---+/*リンクネット|仕事=======|RT1|* . | N1+---+\ . | . \ . | . \ . | . 1\+---+1 1+---+20 | . |RT3|----------|RT5|=========| . +---+ +---+ | . . | ........................ +
Figure 17: Routing through transit areas
図17: トランジット領域を通るルート設定
It is important to note that the above calculation never makes unreachable destinations reachable, but instead just potentially finds better paths to already reachable destinations. The calculation installs any better cost found into the routing table entry, from which it may be readvertised in summary-LSAs to other areas.
上の計算が手の届かない目的地を届くように決してしませんが、代わりにちょうど潜在的に既に届いている目的地により良い経路に当たることに注意するのは重要です。 計算はそれが他の領域への概要-LSAsに「再-広告を出」すかもしれない経路指定テーブルエントリーに見つけられたどんなより良い費用もインストールします。
As an example of the calculation, consider the Autonomous System pictured in Figure 17. There is a single non-backbone area (Area 1) that physically divides the backbone into two separate pieces. To maintain connectivity of the backbone, a virtual link has been configured between routers RT1 and RT4. On the right side of the figure, Network N1 belongs to the backbone. The dotted lines indicate that there is a much shorter intra-area backbone path between router RT5 and Network N1 (cost 20) than there is between Router RT4 and Network N1 (cost 100). Both Router RT4 and Router RT5 will inject summary-LSAs for Network N1 into Area 1.
計算に関する例と、図17に描写されたAutonomous Systemを考えてください。 物理的に背骨を2つの別々の断片に分割するただ一つの非背骨領域(領域1)があります。 背骨の接続性を維持するために、仮想のリンクはルータのRT1とRT4の間で構成されました。 図の右側では、Network N1が背骨に属します。 点線は、Router RT4とNetwork N1の間には、あるよりルータRT5とNetwork N1の間には、はるかに短いイントラ領域背骨経路があるのを示します(20かかってください)(100かかってください)。 Router RT4とRouter RT5の両方がNetwork N1のための概要-LSAsをArea1に注ぐでしょう。
After the shortest-path tree has been calculated for the backbone in Section 16.1, Router RT1 (left end of the virtual link) will have calculated a path through Router RT4 for all data traffic destined for Network N1. However, since Router RT5 is so much closer to Network N1, all routers internal to Area 1 (e.g., Routers RT2 and RT3) will forward their Network N1 traffic towards Router RT5, instead of RT4. And indeed, after examining Area 1's summary-LSAs by the above calculation, Router RT1 will also forward Network N1 traffic towards RT5. Note that in this example the virtual link
最短パス木がセクション16.1における背骨のために計算された後に、Router RT1(仮想のリンクの左の端)はRouter RT4を通してNetwork N1のために運命づけられたすべてのデータ通信量に経路について計算してしまうでしょう。 しかしながら、したがって、Router RT5がNetwork N1にはるかに近いので、Area1(例えば、Routers RT2とRT3)への内部のすべてのルータがそれらのNetwork N1交通をRouter RT5に向かって送るでしょう、RT4の代わりに。 本当に、そして、また、上の計算でArea1の概要-LSAsを調べた後に、Router RT1はRT5に向かった交通をNetwork N1に送るでしょう。 この例の仮想がリンクされることに注意してください。
Moy Standards Track [Page 148] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[148ページ]RFC2178OSPFバージョン1997年7月2日
enables transit data traffic to be forwarded through Area 1, but the actual path the transit data traffic takes does not follow the virtual link. In other words, virtual links allow transit traffic to be forwarded through an area, but do not dictate the precise path that the traffic will take.
トランジットデータ通信量がArea1を通して進めます、トランジットデータ通信量が取る実際の経路だけが仮想のリンクに続かないということであることを可能にします。 言い換えれば、仮想のリンクは、トランジット交通が領域を通って進められるのを許容しますが、交通が取る正確な経路を書き取りません。
16.4. Calculating AS external routes
16.4. 計算のAS外部経路
AS external routes are calculated by examining AS-external-LSAs. 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:
AS外部経路は、ASの外部のLSAsを調べることによって、計算されます。 それぞれのASの外部のLSAsは順番に考えられます。 ほとんどのASの外部のLSAsが特定のIPの目的地にルートを説明します。 また、ASの外部のLSAはAutonomous Systemのためにデフォルトルートを説明できます(Destination IDがDefaultDestinationと等しいです、ネットワーク/サブネットマスク=0x00000000)。 それぞれのASの外部のLSAのために:
(1) If the cost specified by the LSA is LSInfinity, or if the
LSA's LS age is equal to MaxAge, then examine the next LSA.
(1) LSAによって指定された費用がLSInfinityである、またはLSAのLS年令がMaxAgeと等しいなら、次のLSAを調べてください。
(2) If the LSA was originated by the calculating router itself,
examine the next LSA.
(2) LSAが計算のルータ自体によって溯源されたなら、次のLSAを調べてください。
(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 (potentially one per attached
area) for the AS boundary router (ASBR) that originated the
LSA. If no entries exist for router ASBR (i.e., ASBR is
unreachable), do nothing with this LSA and consider the next
in the list.
(3) ネットワーク/サブネットマスクがLSAのボディーに含まれている状態でLSAのLink州IDにマスクをかけることによって、目的地がLSA N.Nのアドレスで説明した呼び出しを得ます。 LSAを溯源したAS境界ルータ(ASBR)のための経路指定テーブルエントリー(潜在的に付属領域あたり1つ)を見上げてください。 エントリーが全くルータASBRのために存在しないなら(すなわち、ASBRは手が届きません)、このLSAと共に何もしないでください、そして、リストの次を考えてください。
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.
ほかに、このLSAはフォーワーディング・アドレスがASの外部のLSAで指定した目的地N.ExamineにASの外部の経路について説明します。 これは目的地へのパケットが送られるべきであるIPアドレスを示します。
If the forwarding address is set to 0.0.0.0, packets should
be sent to the ASBR itself. Among the multiple routing table
entries for the ASBR, select the preferred entry as follows.
If RFC1583Compatibility is set to "disabled", prune the set
of routing table entries for the ASBR as described in
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.
フォーワーディング・アドレスが0.0に.0を設定することであるなら、.0、パケットをASBR自身に送るべきです。 ASBRにおいて複数の経路指定テーブルエントリーの中では、以下の都合のよいエントリーを選択してください。 RFC1583Compatibilityが「身体障害者」に用意ができているなら、ASBRのためにセクション16.4.1で説明されるように経路指定テーブルエントリーのセットから余計なものを取り除いてください。 どのような場合でも、残っている経路指定テーブルエントリーの中で最小費用がある経路指定テーブルエントリーを選択してください。 複数の最低回線料金自動選択機能テーブル項目があるとき、関連領域が持っている中でOSPF Area ID(無記名の32ビットの整数であるとみなされると)最も大きいエントリーは選ばれています。
Moy Standards Track [Page 149] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[149ページ]RFC2178OSPFバージョン1997年7月2日
If the forwarding address is non-zero, look up the
forwarding address in the routing table.[24] The matching
routing table entry must specify an intra-area or inter-area
path; if no such path exists, do nothing with the LSA and
consider the next in the list.
フォーワーディング・アドレスが非ゼロであるなら、経路指定テーブル.[24]のフォーワーディング・アドレスを調べてください。合っている経路指定テーブルエントリーはイントラ領域か相互領域経路を指定しなければなりません。 何かそのような経路が存在しないなら、LSAと共に何もしないでください、そして、リストの次を考えてください。
(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.
(4) Xが費用がLSAで指定したASBR/フォーワーディング・アドレス、およびYのための都合のよい経路指定テーブルエントリーで指定された費用であることをさせてください。 リンク状態では、Xはメートル法です、そして、Yはaタイプ1か2外部メートル法です。
(5) Look up the routing table entry for the destination N. If
no entry exists for N, install the AS external path to N,
with next hop equal to the list of next hops to the
forwarding address, and advertising router equal to 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.
(5) どんなエントリーも存在しない目的地N.Ifへの経路指定テーブルエントリーにほら、N、ASの外部の経路をNにインストールしてください、ASBRと等しいフォーワーディング・アドレス、および広告ルータへの次のホップのリストと等しい次のホップで。 外部のメートル法のタイプが1歳であるなら、経路タイプは1つの外部をタイプするように用意ができています、そして、費用はX+Yと等しいです。 外部のメートル法のタイプが2歳であるなら、経路タイプは2外部をタイプするように用意ができています、そして、ルートの費用のリンク州の部品はXです、そして、2がかかるタイプはYです。
(6) Compare the AS external path described by the LSA with the
existing paths in N's routing table entry, as follows. 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 N's routing table entry's list of
paths.
(6) Nの経路指定テーブルエントリーでLSAによって説明されたASの外部の経路を既存の経路にたとえてください、以下の通りです。 新しい経路が好まれるなら、それはNの経路指定テーブルエントリーで現在の経路を取り替えます。 新しい経路が等しい好みのものであるなら、それはNの経路指定テーブルエントリーの経路のリストに追加されます。
(a) Intra-area and inter-area paths are always preferred
over AS external paths.
(a) イントラ領域と相互領域経路はASの外部の経路よりいつも好まれます。
(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.
(b) 1の外部の経路がいつも好まれるタイプは2つの外部の経路をタイプします。 すべての経路がそうであるときには2つの外部の経路をタイプしてください、そして、最も小さい広告を出しているタイプ2がメートル法であることでの経路はいつも好まれます。
(c) If the new AS external path is still indistinguishable
from the current paths in the 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.
(c) 新しいAS外部の経路がNの経路指定テーブルエントリーにおける現在の経路からまだ区別がつかなく、RFC1583Compatibilityが「身体障害者」に用意ができているなら、イントラ-AS経路に基づく都合のよい経路をASBR/フォーワーディング・アドレスに選択してください、セクション16.4.1で指定されるように。
Moy Standards Track [Page 150] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[150ページ]RFC2178OSPFバージョン1997年7月2日
(d) If the new AS external path is still indistinguishable
from the current paths in the 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 forwarding
address 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 forwarding
addresses.
(d) 新しいAS外部の経路がNの経路指定テーブルエントリーにおける現在の経路からまだ区別がつかないなら、最小費用比較に基づく都合のよい経路を選択してください。 1の外部の経路がフォーワーディング・アドレスへの距離と広告を出しているタイプ1の合計をメートル法であるとして見ながら比較されるタイプ(X+Y)。 等しいタイプ2測定基準が距離をフォーワーディング・アドレスに見せながら比較される2の外部の経路広告をタイプしてください。
16.4.1. External path preferences
16.4.1. 外部の経路好み
When multiple intra-AS paths are available to ASBRs/forwarding addresses, the following rules indicate which paths are preferred. These rules apply when the same ASBR is reachable through multiple areas, or when trying to decide which of several AS-external-LSAs should be preferred. In the former case the paths all terminate at the same ASBR, while in the latter the paths terminate at separate ASBRs/forwarding addresses. In either case, each path is represented by a separate routing table entry as defined in Section 11.
複数のイントラ-AS経路がASBRs/フォーワーディング・アドレスに利用可能であるときに、以下の規則は、どの経路が好まれるかを示します。 同じASBRが複数の領域を通って届いているか、または数個のASの外部のLSAsのどれが好まれるべきであるかを決めようとするとき、これらの規則は適用されます。 前の場合では、経路は同じASBRですべて終わります、後者では、経路が別々のASBRs/フォーワーディング・アドレスで終わりますが。 どちらの場合ではも、各経路はセクション11で定義されるように別々の経路指定テーブルエントリーで表されます。
This section only applies when RFC1583Compatibility is set to "disabled".
RFC1583Compatibilityが「身体障害者」に用意ができているときだけ、このセクションは適用されます。
The path preference rules, stated from highest to lowest preference, are as follows. Note that as a result of these rules, there may still be multiple paths of the highest preference. In this case, the path to use must be determined based on cost, as described in Section 16.4.
最も高い好みから最も低い好みまで述べられた経路優先規則は以下の通りです。 これらの規則の結果、最も高い好みの複数の経路がまだあるかもしれないことに注意してください。 この場合、使用する経路は費用に基づいてセクション16.4で説明されるように決定しているに違いありません。
o Intra-area paths using non-backbone areas are always the
most preferred.
o イントラ..領域..経路..使用..背骨..領域..いつも..最も..都合のよい
o Otherwise, intra-area backbone paths are preferred.
o さもなければ、イントラ領域背骨経路は好まれます。
o Inter-area paths are the least preferred.
o 領域..経路..最も..都合のよい
16.5. Incremental updates -- summary-LSAs
16.5. アップデート増加--概要-LSAs
When a new summary-LSA is received, it is not necessary to recalculate the entire routing table. Call the destination described by the summary-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), and let Area A be the area to which the LSA belongs. There are then two separate cases:
新しい概要-LSAが受け取られているとき、それは全体のルーティングがテーブルの上に置くrecalculateに必要ではありません。 概要-LSA Nによって説明された目的地に電話をしてください、そして、(ネットワーク/サブネットマスクがLSAのボディーに含まれている状態でLSAのLink州IDにマスクをかけることによって、Nのアドレスを得ます)Area AがLSAが属する領域であることをさせてください。 その時、2回の別件があります:
Moy Standards Track [Page 151] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[151ページ]RFC2178OSPFバージョン1997年7月2日
Case 1: Area A is the backbone and/or the router is not an area
border router.
In this case, the following calculations must be performed.
First, if there is presently an inter-area route to the
destination N, N's routing table entry is invalidated, saving the
entry's values for later comparisons. Then the calculation in
Section 16.2 is run again for the single destination N. In this
calculation, all of Area A's summary-LSAs that describe a route to
N are examined. In addition, if the router is an area border
router attached to one or more transit areas, the calculation in
Section 16.3 must be run again for the single destination. If the
results of these calculations have changed the cost/path to an AS
boundary router (as would be the case for a Type 4 summary-LSA) or
to any forwarding addresses, all AS- external-LSAs will have to be
reexamined by rerunning the calculation in Section 16.4.
Otherwise, if N is now newly unreachable, the calculation in
Section 16.4 must be rerun for the single destination N, in case
an alternate external route to N exists.
ケース1: 領域Aは背骨です、そして、ルータは境界ルータではありません。 この場合、以下の計算を実行しなければなりません。 まず最初に、目的地Nへの相互領域ルートが現在あれば、Nの経路指定テーブルエントリーは無効にされます、後の比較のためにエントリーの値を節約して。 次に、セクション16.2における計算は再び単一の目的地N.Inへ走ります。この計算、ルートをNに説明するArea Aの概要-LSAsのすべてが調べられます。 さらに、ルータが1つ以上のトランジット領域に付けられた境界ルータであるなら、再びセクション16.3における計算を単一の目的地へ走らせなければなりません。 これらの計算の結果が費用/経路をAS境界ルータ(Type4概要-LSAのためにそうであるように)、または、どんなフォーワーディング・アドレスにも変えたなら、すべてのASの外部のLSAsが、セクション16.4で計算を再放送することによって、再検討されなければならないでしょう。 さもなければ、Nが現在新たに手が届かないなら、単一の目的地Nにセクション16.4における計算を再放送しなければなりません、Nへの交互の外部経路が存在するといけないので。
Case 2: Area A is a transit area and the router is an area border
router.
In this case, the following calculations must be performed.
First, if N's routing table entry presently contains one or more
inter-area paths that utilize the transit area Area A, these paths
should be removed. If this removes all paths from the routing
table entry, the entry should be invalidated. The entry's old
values should be saved for later comparisons. Next the calculation
in Section 16.3 must be run again for the single destination N. If
the results of this calculation have caused the cost to N to
increase, the complete routing table calculation must be rerun
starting with the Dijkstra algorithm specified in Section 16.1.
Otherwise, if the cost/path to an AS boundary router (as would be
the case for a Type 4 summary-LSA) or to any forwarding addresses
has changed, all AS-external-LSAs will have to be reexamined by
rerunning the calculation in Section 16.4. Otherwise, if N is now
newly unreachable, the calculation in Section 16.4 must be rerun
for the single destination N, in case an alternate external route
to N exists.
ケース2: 地域Aはトランジット領域です、そして、ルータは境界ルータです。 この場合、以下の計算を実行しなければなりません。 まず最初に、Nの経路指定テーブルエントリーが現在トランジット領域Area Aを利用する1つ以上の相互領域経路を含むなら、これらの経路を取り除くべきです。 これが経路指定テーブルエントリーからすべての経路を取り除くなら、エントリーは無効にされるべきです。 エントリーの古い値は後の比較のために節約されるべきです。 次に、再びNへの費用がこの計算の結果で増加させた単一の目的地N.Ifへセクション16.3における計算を走らせなければならなくて、セクション16.1で指定されたダイクストラアルゴリズムをきっかけに完全な経路指定テーブル計算を再放送しなければなりません。 さもなければ、AS境界ルータ(Type4概要-LSAのためにそうであるように)、または、どんなフォーワーディング・アドレスへの費用/経路が変化したなら、すべてのASの外部のLSAsが、セクション16.4で計算を再放送することによって、再検討されなければならないでしょう。 さもなければ、Nが現在新たに手が届かないなら、単一の目的地Nにセクション16.4における計算を再放送しなければなりません、Nへの交互の外部経路が存在するといけないので。
16.6. Incremental updates -- AS-external-LSAs
16.6. アップデート増加--ASの外部のLSAs
When a new AS-external-LSA is received, it is not necessary to recalculate the entire routing table. Call the destination described by the AS-external-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).
新しいAS外部のLSAが受け取られているとき、それは全体のルーティングがテーブルの上に置くrecalculateに必要ではありません。 ネットワーク/サブネットマスクがLSAのボディーに含まれている状態でLSAのLink州IDにマスクをかけることによって、目的地がASの外部のLSA N.Nのアドレスで説明した呼び出しを得ます。 目的地へのイントラ領域か相互領域ルートが既にあれば、どんな再計算も必要ではありません(内部のルートは優先します)。
Moy Standards Track [Page 152] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[152ページ]RFC2178OSPFバージョン1997年7月2日
Otherwise, the procedure in Section 16.4 will have to be performed, but only for those AS-external-LSAs whose destination is N. Before this procedure is performed, the present routing table entry for N should be invalidated.
目的地がN.BeforeであるそれらのASの外部のLSAsだけに関して、この手順は実行されます、そして、さもなければ、セクション16.4の手順は実行されなければならないでしょうが、Nのための現在の経路指定テーブルエントリーは無効にされるべきです。
16.7. Events generated as a result of routing table changes
16.7. 経路指定テーブル変化の結果、発生する出来事
Changes to routing table entries sometimes cause the OSPF area border routers to take additional actions. These routers need to act on the following routing table changes:
経路指定テーブルエントリーへの変化で、OSPF境界ルータは時々追加行動を取ります。 これらのルータは、以下の経路指定テーブル変化に影響する必要があります:
o The cost or path type of a routing table entry has changed.
If the destination described by this entry is a Network or AS
boundary router, and this is not simply a change of AS external
routes, new summary-LSAs may have to be generated (potentially one
for each attached area, including the backbone). See Section
12.4.3 for more information. If a previously advertised entry has
been deleted, or is no longer advertisable to a particular area,
the LSA must be flushed from the routing domain by setting its LS
age to MaxAge and reflooding (see Section 14.1).
o 経路指定テーブルエントリーの費用か経路タイプが変化しました。 このエントリーで説明された目的地がNetworkかAS境界ルータであり、これが単にAS外部経路の変化でないなら、新しい概要-LSAsは発生しなければならないかもしれません(潜在的に背骨を含むそれぞれの付属領域あたり1つ)。 詳しい情報に関してセクション12.4.3を見てください。 以前に広告を出したエントリーが削除されたか、またはもう特定の領域に「広告を出-可能」でないなら、LSAはLS時代をMaxAgeに設定して、「再-あふれ」るのによる経路ドメインから紅潮しているに違いありません(セクション14.1を見てください)。
o A routing table entry associated with a configured virtual
link has changed. The destination of such a routing table entry
is an area border router. The change indicates a modification to
the virtual link's cost or viability.
o 構成された仮想のリンクに関連している経路指定テーブルエントリーは変化しました。 そのような経路指定テーブルエントリーの目的地は境界ルータです。 変化は仮想のリンクの費用か生存力への変更を示します。
If the entry indicates that the area border router is newly
reachable, the corresponding virtual link is now operational. An
InterfaceUp event should be generated for the virtual link, which
will cause a virtual adjacency to begin to form (see Section
10.3). At this time the virtual link's IP interface address and
the virtual neighbor's Neighbor IP address are also calculated.
エントリーが、境界ルータが新たに届いているのを示すなら、対応する仮想のリンクは現在、操作上です。 InterfaceUp出来事は仮想のリンクに発生するべきです(セクション10.3を見てください)。(仮想の隣接番組はそれで、形成し始めるでしょう)。 また、このとき、仮想のリンクのIPインターフェース・アドレスと仮想の隣人のNeighbor IPアドレスは計算されます。
If the entry indicates that the area border router is no longer
reachable, the virtual link and its associated adjacency should be
destroyed. This means an InterfaceDown event should be generated
for the associated virtual link.
エントリーが、境界ルータがもう届いていないのを示すなら、仮想のリンクとその関連隣接番組は破壊されるべきです。 これは、InterfaceDown出来事が関連仮想のリンクに発生するべきであることを意味します。
If the cost of the entry has changed, and there is a fully
established virtual adjacency, a new router-LSA for the backbone
must be originated. This in turn may cause further routing table
changes.
エントリーの費用が変化して、完全に確立した仮想の隣接番組があれば、背骨のための新しいルータ-LSAを溯源しなければなりません。 これは順番に一層の経路指定テーブル変化を引き起こすかもしれません。
Moy Standards Track [Page 153] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[153ページ]RFC2178OSPFバージョン1997年7月2日
16.8. Equal-cost multipath
16.8. 等価コストマルチパス
The OSPF protocol maintains multiple equal-cost routes to all destinations. This can be seen in the steps used above to calculate the routing table, and in the definition of the routing table structure.
OSPFプロトコルは複数の等しい費用ルートをすべての目的地に維持します。 経路指定テーブルについて計算するのに上で使用されたステップ、および経路指定テーブル構造の定義でこれを見ることができます。
Each one of the multiple routes will be of the same type (intra-area, inter-area, type 1 external or type 2 external), cost, and will have the same associated area. However, each route specifies a separate next hop and Advertising router.
複数のルートの各々は、(イントラ領域、相互領域、タイプ1外部またはタイプ2外部)がかかる同じタイプにはあって、同じ関連領域を持つでしょう。 しかしながら、各ルートは次の別々のホップとAdvertisingルータを指定します。
There is no requirement that a router running OSPF keep track of all possible equal-cost routes to a destination. An implementation may choose to keep only a fixed number of routes to any given destination. This does not affect any of the algorithms presented in this specification.
OSPFを実行するルータがすべての可能な等しい費用ルートの目的地に動向をおさえるという要件が全くありません。 実装は、どんな与えられた目的地にもルートの定数だけを保つのを選ぶかもしれません。 これはこの仕様に提示されたアルゴリズムのいずれにも影響しません。
Moy Standards Track [Page 154] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[154ページ]RFC2178OSPFバージョン1997年7月2日
Footnotes
脚注
[1]The graph's vertices represent either routers, transit networks, or stub networks. Since routers may belong to multiple areas, it is not possible to color the graph's vertices.
[1] グラフの頭頂はルータ、輸送網かスタッブネットワークのどちらかを代表します。 ルータが複数の領域に属すかもしれないので、グラフの頭頂を着色するのは可能ではありません。
[2]It is possible for all of a router's interfaces to be unnumbered point-to-point links. In this case, an IP address must be assigned to the router. This address will then be advertised in the router's router-LSA as a host route.
[2] ルータのインタフェースのすべてが無数のポイントツーポイント接続であることは可能です。 この場合、IPアドレスをルータに割り当てなければなりません。 そして、ホストルートとしてルータのルータ-LSAにこのアドレスの広告を出すでしょう。
[3]Note that in these cases both interfaces, the non-virtual and the virtual, would have the same IP address.
[3] 同じIPが両方のインタフェース、非仮想、および仮想で扱うこれらの場合でそれに注意してください。
[4]Note that no host route is generated for, and no IP packets can be addressed to, interfaces to unnumbered point-to-point networks. This is regardless of such an interface's state.
[4] ホストルートを生成して、IPパケットを全く扱うことができないそのノーに注意してください、無数の二地点間ネットワークへのインタフェース。 これはそのようなインタフェースの状態にかかわらずあります。
[5]It is instructive to see what happens when the Designated Router for the network crashes. Call the Designated Router for the network RT1, and the Backup Designated Router RT2. If Router RT1 crashes (or maybe its interface to the network dies), the other routers on the network will detect RT1's absence within RouterDeadInterval seconds. All routers may not detect this at precisely the same time; the routers that detect RT1's absence before RT2 does will, for a time, select RT2 to be both Designated Router and Backup Designated Router. When RT2 detects that RT1 is gone it will move itself to Designated Router. At this time, the remaining router having highest Router Priority will be selected as Backup Designated Router.
[5] ネットワークのためのDesignated Routerがダウンすると何が起こるかわかるのはためになっています。 ネットワークのためのDesignated RouterをRT1、およびBackup Designated Router RT2と呼んでください。 Router RT1がダウンすると(多分、ネットワークへのインタフェースは死にます)、ネットワークの他のルータはRouterDeadInterval秒以内にRT1の不在を検出するでしょう。 すべてのルータは正確に同時にこれを検出しないかもしれません。 RT2が検出する前にRT1の不在を検出するルータはそうするでしょう、時間、Designated RouterとBackup Designated Routerの両方である選んだRT2。 RT2がそれを検出するときのどんどんやられて、それ自体をDesignated Routerに動かすというRT1によることです。 このとき、持っている中でRouter Priority最も高い残っているルータはBackup Designated Routerとして選定されるでしょう。
[6]On point-to-point networks, the lower level protocols indicate whether the neighbor is up and running. Likewise, existence of the neighbor on virtual links is indicated by the routing table calculation. However, in both these cases, the Hello Protocol is still used. This ensures that communication between the neighbors is bidirectional, and that each of the neighbors has a functioning routing protocol layer.
[6] 二地点間ネットワークでは、下のレベルプロトコルは、隣人が活動しているかどうかを示します。 同様に、仮想のリンクの上の隣人の存在は経路指定テーブル計算で示されます。 しかしながら、これらの場合の両方では、Helloプロトコルはまだ使用されています。 これは隣人のコミュニケーションが双方向であり、隣人各人には機能しているルーティングプロトコル層があるのを確実にします。
[7]When the identity of the Designated Router is changing, it may be quite common for a neighbor in this state to send the router a Database Description packet; this means that there is some momentary disagreement on the Designated Router's identity.
[7] Designated Routerのアイデンティティが変化するとき、この状態の隣人がDatabase記述パケットをルータに送るのは、全く一般的であるかもしれません。 これは、何らかの瞬間の不一致がDesignated Routerのアイデンティティにあることを意味します。
[8]Note that it is possible for a router to resynchronize any of its fully established adjacencies by setting the adjacency's state back to ExStart. This will cause the other end of the adjacency to process a SeqNumberMismatch event, and therefore to also go back to ExStart state.
[8] ルータが隣接番組の状態をExStartに遅らせることによって完全に確立した隣接番組のどれかを再連動させるのが、可能であることに注意してください。 これは隣接番組のもう一方の端がSeqNumberMismatchイベントを処理して、したがって、また、ExStart状態に戻ることを引き起こすでしょう。
Moy Standards Track [Page 155] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[155ページ]RFC2178OSPFバージョン1997年7月2日
[9]The address space of IP networks and the address space of OSPF Router IDs may overlap. That is, a network may have an IP address which is identical (when considered as a 32-bit number) to some router's Router ID.
[9] IPネットワークのアドレス空間とOSPF Router IDのアドレス空間は重なるかもしれません。 すなわち、ネットワークには、何らかのルータのRouter IDと同じ(32ビットの数であるとみなされると)IPアドレスがあるかもしれません。
[10]"Discard" entries are necessary to ensure that route summarization at area boundaries will not cause packet looping.
[10] 「捨ててください」というエントリーが、エリアの境界のルート総括がパケットループを引き起こさないのを保証するのに必要です。
[11]It is assumed that, for two different address ranges matching the destination, one range is more specific than the other. Non- contiguous subnet masks can be configured to violate this assumption. Such subnet mask configurations cannot be handled by the OSPF protocol.
[11] 目的地に合っている2つの異なったアドレスの範囲には、1つの範囲がもう片方より特定であると思われます。 この仮定に違反するために非隣接のサブネットマスクを構成できます。 OSPFプロトコルはそのようなサブネットマスク構成を扱うことができません。
[12]MaxAgeDiff is an architectural constant. It indicates the maximum dispersion of ages, in seconds, that can occur for a single LSA instance as it is flooded throughout the routing domain. If two LSAs differ by more than this, they are assumed to be different instances of the same LSA. This can occur when a router restarts and loses track of the LSA's previous LS sequence number. See Section 13.4 for more details.
[12] MaxAgeDiffは建築定数です。 それは秒のそれが経路ドメイン中で水につかっているときただ一つのLSAインスタンスのために起こることができる時代の最大の分散を示します。 2LSAsがこれ以上で異なるなら、彼らは同じLSAの異なったインスタンスであると思われます。 ルータがLSAの前のLS一連番号を再開して、見失うとき、これは起こることができます。 その他の詳細に関してセクション13.4を見てください。
[13]When two LSAs have different LS checksums, they are assumed to be separate instances. This can occur when a router restarts, and loses track of the LSA's previous LS sequence number. In the case where the two LSAs have the same LS sequence number, it is not possible to determine which LSA is actually newer. However, if the wrong LSA is accepted as newer, the originating router will simply originate another instance. See Section 13.4 for further details.
[13] 2LSAsに異なったLSチェックサムがあると、それらは別々のインスタンスであると思われます。 ルータがLSAの前のLS一連番号を再開して、見失うとき、これは起こることができます。 2LSAsが同じLS一連番号を持っている場合では、どちらのLSAが実際により新しいかを決定するのは可能ではありません。 しかしながら、間違ったLSAが、より新しいとして認められると、起因するルータは単に別のインスタンスを溯源するでしょう。 さらに詳しい明細についてはセクション13.4を見てください。
[14]There is one instance where a lookup must be done based on partial information. This is during the routing table calculation, when a network-LSA must be found based solely on its Link State ID. The lookup in this case is still well defined, since no two network- LSAs can have the same Link State ID.
[14] 1つのインスタンスが部分的な情報に基づいてルックアップをしなければならないところにあります。 唯一Link州IDでネットワーク-LSAがベースであることがわからなければならないとき、これは経路指定テーブル計算の間、あります。 この場合、ルックアップはまだよく定義されています、2ネットワークがないLSAsが同じLink州IDを持つことができるので。
[15]This is the way RFC 1583 specified point-to-point representation. It has three advantages: a) it does not require allocating a subnet to the point-to-point link, b) it tends to bias the routing so that packets destined for the point-to-point interface will actually be received over the interface (which is useful for diagnostic purposes) and c) it allows network bootstrapping of a neighbor, without requiring that the bootstrap program contain an OSPF implementation.
[15] これは道です。RFC1583の指定されたポイントからポイント表示。 それには、3つの利点があります: a) それは、指すポイントへのサブネットリンク、それは実際にインタフェース(診断目的で役に立つ)の上に二地点間インタフェースに運命づけられたパケットを受け取るようにルーティングに偏るために傾向があるb)、およびそれが隣人のネットワークブートストラップ法を許容するc)を割り当てるのを必要としません、ローディング・プログラムがOSPF実装を含む必要でない。
[16]This is the more traditional point-to-point representation used by protocols such as RIP.
[16] これはRIPなどのプロトコルによって使用されるより伝統的な二地点間表現です。
Moy Standards Track [Page 156] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[156ページ]RFC2178OSPFバージョン1997年7月2日
[17]This clause covers the case: Inter-area routes are not summarized to the backbone. This is because inter-area routes are always associated with the backbone area.
[17] この節はケースをカバーしています: 相互領域ルートはバックボーンへまとめられません。 これは相互領域ルートがいつもバックボーン領域に関連しているからです。
[18]This clause is only invoked when a non-backbone Area A supports transit data traffic (i.e., has TransitCapability set to TRUE). For example, in the area configuration of Figure 6, Area 2 can support transit traffic due to the configured virtual link between Routers RT10 and RT11. As a result, Router RT11 need only originate a single summary-LSA into Area 2 (having the collapsed destination N9-N11,H1), since all of Router RT11's other eligible routes have next hops belonging to Area 2 itself (and as such only need be advertised by other area border routers; in this case, Routers RT10 and RT7).
[18] 非バックボーンArea Aが、トランジットがデータ通信量(すなわち、TransitCapabilityをTRUEに用意ができさせる)であるとサポートするときだけ、この節は呼び出されます。 例えば、図6の領域構成では、Area2は、Routers RT10とRT11との構成された仮想のリンクのためトランジットがトラフィックであるとサポートすることができます。 その結果、Router RT11は独身の概要-LSAをArea2に溯源するだけでよいです(潰れている目的地N9-N11、H1を持っていて)、Router RT11の他の適任のルートのすべてが次のホップにArea2自身に属させるので(Routers RT10とRT7、そのような必要性だけとして、他の境界ルータで、この場合広告を出してください)。
[19]By keeping more information in the routing table, it is possible for an implementation to recalculate the shortest path tree for only a single area. In fact, there are incremental algorithms that allow an implementation to recalculate only a portion of a single area's shortest path tree [Ref1]. However, these algorithms are beyond the scope of this specification.
[19] ただ一つの領域だけへの実装に、経路指定テーブルでは、それがrecalculateに可能であるという詳しい情報を保つのによる最短パス木。 事実上、ただ一つの領域の最短パス木[Ref1]のrecalculateへの一部だけを実装に許容する増加のアルゴリズムがあります。 しかしながら、これらのアルゴリズムはこの仕様の範囲を超えています。
[20]This is how the Link state request list is emptied, which eventually causes the neighbor state to transition to Full. See Section 10.9 for more details.
[20] これはLink州の要求リスト(結局、Fullへの変遷に隣人状態を引き起こす)がどう空にされているかということです。 その他の詳細に関してセクション10.9を見てください。
[21]It should be a relatively rare occurrence for an LSA's LS age to reach MaxAge in this fashion. Usually, the LSA will be replaced by a more recent instance before it ages out.
[21]LSAのLSの期間、こんなやり方でMaxAgeに達するのは、比較的まれな発生であるべきです。 通常、外で年をとる前にLSAをより最近のインスタンスに取り替えるでしょう。
[22]Strictly speaking, because of equal-cost multipath, the algorithm does not create a tree. We continue to use the "tree" terminology because that is what occurs most often in the existing literature.
[22] 等価コストマルチパスのために、厳密に言うと、アルゴリズムは木を作成しません。 私たちは、それがたいてい既存文献に起こることであるので「木」用語を使用し続けています。
[23]Note that the presence of any link back to V is sufficient; it need not be the matching half of the link under consideration from V to W. This is enough to ensure that, before data traffic flows between a pair of neighboring routers, their link state databases will be synchronized.
[23] Vへのどんなリンクの存在も十分であることに注意してください。 VからW.Thisまで考慮での半分の合っているリンクが、データ通信量が1組の隣接しているルータの間を流れる前にそれらのリンク州のデータベースが同期するのを保証できるくらいのことである必要はありません。
[24]When the forwarding address is non-zero, it should point to a router belonging to another Autonomous System. See Section 12.4.4 for more details.
[24] フォーワーディング・アドレスが非ゼロであるときに、それは別のAutonomous Systemに属すルータを示すべきです。 その他の詳細に関してセクション12.4.4を見てください。
Moy Standards Track [Page 157] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[157ページ]RFC2178OSPFバージョン1997年7月2日
References
参照
[Ref1] McQuillan, J., I. Richer and E. Rosen, "ARPANET Routing
Algorithm Improvements", BBN Technical Report 3803, April
1978.
[Ref1] マッキランとJ.とI.リシェとE.ローゼン、「アルパネットルーティング・アルゴリズム改良」、BBN技術報告書3803、1978年4月。
[Ref2] Digital Equipment Corporation, "Information processing
systems -- Data communications -- Intermediate System to
Intermediate System Intra-Domain Routing Protocol", October
1987.
[Ref2]ディジタルイクイップメント社、「情報処理システム--データ通信--Intermediate System Intra-ドメインルート設定プロトコルへの中間的System」1987年10月。
[Ref3] McQuillan, J. et.al., "The New Routing Algorithm for the
ARPANET", IEEE Transactions on Communications, May 1980.
[Ref3]マッキラン、J.et.al、「アルパネットのための新しいルーティング・アルゴリズム」、Communications、5月1980日のIEEE Transactions
[Ref4] Perlman, R., "Fault-Tolerant Broadcast of Routing
Information", Computer Networks, December 1983.
[Ref4] パールマン、R.、「経路情報のフォールトトレラント放送」、コンピュータネットワーク、1983年12月。
[Ref5] Postel, J., "Internet Protocol", STD 5, RFC 791,
USC/Information Sciences Institute, September 1981.
[Ref5] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、科学が1981年9月に設けるUSC/情報。
[Ref6] McKenzie, A., "ISO Transport Protocol specification ISO DP
8073", RFC 905, ISO, April 1984.
[Ref6] マッケンジー、A.、「ISO Transportプロトコル仕様ISO DP8073」、RFC905、ISO、1984年4月。
[Ref7] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, Stanford University, May 1988.
[Ref7] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、スタンフォード大学、1988年5月。
[Ref8] McCloghrie, K., and M. Rose, "Management Information Base
for network management of TCP/IP-based internets: MIB-II",
STD 17, RFC 1213, Hughes LAN Systems, Performance Systems
International, March 1991.
[Ref8] McCloghrie、K.、およびM.ローズ、「TCP/IPベースのインターネットのネットワークマネージメントのための管理Information基地:」 「MIB-II」、STD17、RFC1213、ヒューズLANシステム、国際言語運用機構、1991年3月。
[Ref9] Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March
1994.
[Ref9]Moy、J.、「OSPF、バージョン2インチ、RFC1583、Proteon Inc.、1994インチ年3月。
[Ref10] Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless
Inter-Domain Routing (CIDR): an Address Assignment and
Aggregation Strategy", RFC1519, BARRNet, cisco, MERIT,
OARnet, September 1993.
[Ref10] フラー、V.、T.李、J.ユー、およびK.Varadhan、「以下を掘る(CIDR)階級のない相互ドメイン」 「Address AssignmentとAggregation Strategy」、RFC1519、BARRNet、コクチマス、MERIT、OARnet、9月1993日
[Ref11] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, USC/Information Sciences Institute, October 1994.
[Ref11] USC/情報科学が1994年10月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、STD2、RFC1700。
[Ref12] Almquist, P., "Type of Service in the Internet Protocol
Suite", RFC 1349, July 1992.
[Ref12] Almquist、P.、「インターネットプロトコル群のサービスのタイプ」、RFC1349、1992年7月。
[Ref13] Leiner, B., et.al., "The DARPA Internet Protocol Suite", DDN
Protocol Handbook, April 1985.
[Ref13] Leiner、B.、et.al、「DARPAインターネットプロトコル群」、DDNプロトコルHandbook、4月1985日
Moy Standards Track [Page 158] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[158ページ]RFC2178OSPFバージョン1997年7月2日
[Ref14] Bradley, T., and C. Brown, "Inverse Address Resolution
Protocol", RFC 1293, January 1992.
[Ref14] ブラッドリー、T.とC.ブラウン、「逆さのアドレス解決プロトコル」、RFC1293、1992年1月。
[Ref15] deSouza, O., and M. Rodrigues, "Guidelines for Running OSPF
Over Frame Relay Networks", RFC 1586, March 1994.
[Ref15] deSouza、O.、およびM.ロドリーグ、「フレームリレーネットワークの上にOSPFを実行するためのガイドライン」、RFC1586、1994年3月。
[Ref16] Bellovin, S., "Security Problems in the TCP/IP Protocol
Suite", ACM Computer Communications Review, Volume 19,
Number 2, pp. 32-38, April 1989.
[Ref16] Bellovin、S.、「TCP/IPプロトコル群の警備上の問題」、ACMコンピュータCommunications Review、Volume19、Number2、ページ 32-38と、1989年4月。
[Ref17] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[Ref17] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。
[Ref18] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon,
Inc., March 1994.
[Ref18] Moy、J.、「OSPFへのマルチキャスト拡大」、RFC1584、Proteon Inc.、1994年3月。
[Ref19] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587,
RainbowBridge Communications, Stanford University, March
1994.
フラー、[Ref19] Coltun、R.、およびRFC1587、RainbowBridgeコミュニケーション、スタンフォード大学、1994年3月対「OSPF NSSAオプション」
[Ref20] Ferguson, D., "The OSPF External Attributes LSA", work in
progress.
[Ref20] ファーガソン、D.、「OSPFの外部の属性LSA」が進行中で働いています。
[Ref21] Moy, J., "Extending OSPF to Support Demand Circuits", RFC
1793, Cascade, April 1995.
[Ref21]Moy J. (「要求が回路であるとサポートするためにOSPFを広げている」RFC1793)は1995年4月にどっと落します。
[Ref22] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
DECWRL, Stanford University, November 1990.
[Ref22] ムガール人とJ.とS.デアリング、「経路MTU発見」、RFC1191、DECWRL、スタンフォード大学、1990年11月。
[Ref23] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-
4)", RFC 1771, T.J. Watson Research Center, IBM Corp., cisco
Systems, March 1995.
[Ref23] RekhterとY.とT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP4)」、RFC1771、T.J.ワトソン研究所、IBM社、コクチマスSystems(1995年3月)。
[Ref24] Hinden, R., "Internet Routing Protocol Standardization
Criteria", BBN, October 1991.
[Ref24] Hinden、R.、「インターネットルーティング・プロトコル標準化評価基準」、BBN、1991年10月。
Moy Standards Track [Page 159] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[159ページ]RFC2178OSPFバージョン1997年7月2日
A. OSPF data formats
A。 OSPFデータ形式
This appendix describes the format of OSPF protocol packets and OSPF LSAs. The OSPF protocol runs directly over the IP network layer. Before any data formats are described, the details of the OSPF encapsulation are explained.
この付録はOSPFプロトコルパケットとOSPF LSAsの形式について説明します。 OSPFプロトコルは直接IPネットワーク層をひきます。 どんなデータ形式も説明される前に、OSPFカプセル化の詳細は説明されます。
Next the OSPF Options field is described. This field describes various capabilities that may or may not be supported by pieces of the OSPF routing domain. The OSPF Options field is contained in OSPF Hello packets, Database Description packets and in OSPF LSAs.
次に、OSPF Options分野は説明されます。 この分野はOSPF経路ドメインの断片によってサポートされるかもしれない様々な能力について説明します。 OSPF Options分野はOSPF Helloパケット、Database記述パケット、およびOSPF LSAsに含まれています。
OSPF packet formats are detailed in Section A.3. A description of OSPF LSAs appears in Section A.4.
OSPFパケット・フォーマットはセクションA.3で詳細です。 OSPF LSAsの記述はセクションA.4に現れます。
A.1 Encapsulation of OSPF packets
OSPFパケットのA.1カプセル化
OSPF runs directly over the Internet Protocol's network layer. OSPF packets are therefore encapsulated solely by IP and local data-link headers.
OSPFは直接インターネットプロトコルのネットワーク層をひきます。 したがって、OSPFパケットは唯一IPと地元のデータ・リンクヘッダーによってカプセルに入れられます。
OSPF does not define a way to fragment its protocol packets, and depends on IP fragmentation when transmitting packets larger than the network MTU. If necessary, the length of OSPF packets can be up to 65,535 bytes (including the IP header). The OSPF packet types that are likely to be large (Database Description Packets, Link State Request, Link State Update, and Link State Acknowledgment packets) can usually be split into several separate protocol packets, without loss of functionality. This is recommended; IP fragmentation should be avoided whenever possible. Using this reasoning, an attempt should be made to limit the sizes of OSPF packets sent over virtual links to 576 bytes unless Path MTU Discovery is being performed (see [Ref22]).
OSPFはプロトコルパケットを断片化する方法を定義しないで、ネットワークMTUより大きいパケットを伝えるとき、IP断片化によります。 必要なら、OSPFパケットの長さは最大6万5535バイトであるかもしれません(IPヘッダーを含んでいて)。 通常、大きい傾向があるOSPFパケットタイプ(データベース記述Packets、Link州Request、Link州Update、およびLink州Acknowledgmentパケット)はいくつかの別々のプロトコルパケットに分けることができます、機能性の損失なしで。 これはお勧めです。 可能であるときはいつも、IP断片化は避けられるべきです。 この推理を使用して、Path MTUディスカバリーを実行していない場合([Ref22]を見てください)576バイトへの仮想のリンクの上に送られたOSPFパケットのサイズを制限するのを試みをするべきです。
The other important features of OSPF's IP encapsulation are:
OSPFのIPカプセル化の他の重要な特徴は以下の通りです。
o Use of IP multicast. Some OSPF messages are multicast, when
sent over broadcast networks. Two distinct IP multicast addresses
are used. Packets sent to these multicast addresses should never
be forwarded; they are meant to travel a single hop only. To
ensure that these packets will not travel multiple hops, their IP
TTL must be set to 1.
o IPマルチキャストの使用。 放送網の上に送ると、いくつかのOSPFメッセージがマルチキャストです。 2つの異なったIPマルチキャストアドレスが使用されています。 これらのマルチキャストアドレスに送られたパケットを決して進めるべきではありません。 彼らは単一のホップだけを旅行することになっています。 これらのパケットが複数のホップを旅行しないのを保証するために、それらのIP TTLは1に用意ができなければなりません。
Moy Standards Track [Page 160] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[160ページ]RFC2178OSPFバージョン1997年7月2日
AllSPFRouters
This multicast address has been assigned the value 224.0.0.5. All
routers running OSPF should be prepared to receive packets sent to
this address. Hello packets are always sent to this destination.
Also, certain OSPF protocol packets are sent to this address
during the flooding procedure.
AllSPFRouters Thisマルチキャストアドレスに値224.0を割り当ててあります。.0 .5。 OSPFを実行するすべてのルータがこのアドレスに送られたパケットを受けるように準備されるべきです。 こんにちは、この目的地に送って、いつもパケットはそうです。 また、氾濫手順の間、あるOSPFプロトコルパケットをこのアドレスに送ります。
AllDRouters
This multicast address has been assigned the value 224.0.0.6. Both
the Designated Router and Backup Designated Router must be
prepared to receive packets destined to this address. Certain
OSPF protocol packets are sent to this address during the flooding
procedure.
AllDRouters Thisマルチキャストアドレスに値224.0を割り当ててあります。.0 .6。 このアドレスに運命づけられたパケットを受けるようにDesignated RouterとBackup Designated Routerの両方を準備しなければなりません。 氾濫手順の間、あるOSPFプロトコルパケットをこのアドレスに送ります。
o OSPF is IP protocol number 89. This number has been registered
with the Network Information Center. IP protocol number
assignments are documented in [Ref11].
o OSPFはIPプロトコル番号89です。 この数はNetworkインフォメーション・センターに示されました。 IPプロトコル番号課題は[Ref11]に記録されます。
o All OSPF routing protocol packets are sent using the normal
service TOS value of binary 0000 defined in [Ref12].
o すべてのOSPFルーティング・プロトコルパケットに[Ref12]で定義された2進の0000年の正常なサービスTOS価値を使用させます。
o Routing protocol packets are sent with IP precedence set to
Internetwork Control. OSPF protocol packets should be given
precedence over regular IP data traffic, in both sending and
receiving. Setting the IP precedence field in the IP header to
Internetwork Control [Ref5] may help implement this objective.
o Internetwork Controlに設定されたIP先行と共にルーティング・プロトコルパケットを送ります。 発信と受信の両方の定期的なIPデータ通信量の上の優先権をOSPFプロトコルパケットに与えるべきです。 Internetwork Control[Ref5]へのIPヘッダーにIP先行分野をはめ込むのは、この目的を実装するのを助けるかもしれません。
Moy Standards Track [Page 161] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[161ページ]RFC2178OSPFバージョン1997年7月2日
A.2 The Options field
A.2はOptions分野です。
The OSPF Options field is present in OSPF Hello packets, Database Description packets and all LSAs. The Options field enables OSPF routers to support (or not support) optional capabilities, and to communicate their capability level to other OSPF routers. Through this mechanism routers of differing capabilities can be mixed within an OSPF routing domain.
OSPF Options分野はOSPF Helloパケット、Database記述パケット、およびすべてのLSAsに存在しています。 Options分野は、OSPFルータが(または、サポートでない)任意の能力をサポートして、それらの能力レベルを他のOSPFルータに伝えるのを可能にします。 このメカニズムを通して、異なった能力のルータはOSPF経路ドメインの中で複雑であることができます。
When used in Hello packets, the Options field allows a router to reject a neighbor because of a capability mismatch. Alternatively, when capabilities are exchanged in Database Description packets a router can choose not to forward certain LSAs to a neighbor because of its reduced functionality. Lastly, listing capabilities in LSAs allows routers to forward traffic around reduced functionality routers, by excluding them from parts of the routing table calculation.
Helloパケットで使用されると、Options分野で、ルータは能力ミスマッチで隣人を拒絶できます。 Database記述パケットで能力を交換するとき、あるいはまた、ルータは、減少している機能性のためにあるLSAsを隣人に送らないのを選ぶことができます。 最後に、ルータはLSAsに能力を記載するのに減少している機能性ルータの周りにトラフィックを送ることができます、経路指定テーブル計算の部品にそれらを入れないようにすることによって。
Five bits of the OSPF Options field have been assigned, although only one (the E-bit) is described completely by this memo. Each bit is described briefly below. Routers should reset (i.e. clear) unrecognized bits in the Options field when sending Hello packets or Database Description packets and when originating LSAs. Conversely, routers encountering unrecognized Option bits in received Hello Packets, Database Description packets or LSAs should ignore the capability and process the packet/LSA normally.
OSPF Options分野の5ビットを割り当ててあります、1つ(E-ビット)だけが完全にこのメモで説明されますが。 各ビットは簡潔に以下で説明されます。 HelloパケットかDatabase記述パケットといつにLSAsを溯源させるかとき、ルータはOptions分野に(すなわち、明確)の認識されていないビットをリセットするべきです。 逆に、Database記述の容認されたHello Packetsで認識されていないOptionビットに遭遇するルータ、パケットまたはLSAsが能力を無視して、通常、パケット/LSAを処理するはずです。
+------------------------------------+
| * | * | DC | EA | N/P | MC | E | * |
+------------------------------------+
+------------------------------------+ | * | * | DC| EA| N/P| M.C.| E| * | +------------------------------------+
The Options field
Options分野
E-bit
This bit describes the way AS-external-LSAs are flooded, as
described in Sections 3.6, 9.5, 10.8 and 12.1.2 of this memo.
電子ビットThisビットはASの外部のLSAsが水につかっている方法を述べます、この.2のセクション3.6、9.5、10.8、および12.1メモで説明されるように。
MC-bit
This bit describes whether IP multicast datagrams are forwarded
according to the specifications in [Ref18].
ビットThisビットM.C.は、IPマルチキャストデータグラムが[Ref18]の仕様通りに進められるかどうか説明します。
N/P-bit
This bit describes the handling of Type-7 LSAs, as specified in
[Ref19].
PでN/噛み付いているThisビットは[Ref19]で指定されるようにType-7 LSAsの取り扱いについて説明します。
EA-bit
This bit describes the router's willingness to receive and
forward External-Attributes-LSAs, as specified in [Ref20].
EA-ビットThisビットは[Ref20]で指定されるように受信するルータの意欲と前進のExternal属性LSAsについて説明します。
Moy Standards Track [Page 162] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[162ページ]RFC2178OSPFバージョン1997年7月2日
DC-bit
This bit describes the router's handling of demand circuits, as
specified in [Ref21].
DC-ビットThisビットは[Ref21]で指定されるように要求回路のルータの取り扱いについて説明します。
A.3 OSPF Packet Formats
A.3 OSPFパケット・フォーマット
There are five distinct OSPF packet types. All OSPF packet types begin with a standard 24 byte header. This header is described first. Each packet type is then described in a succeeding section. In these sections each packet's division into fields is displayed, and then the field definitions are enumerated.
5つの異なったOSPFパケットタイプがあります。 すべてのOSPFパケットタイプが24バイトの標準のヘッダーと共に始まります。 このヘッダーは最初に、説明されます。 そして、それぞれのパケットタイプは続くセクションで説明されます。 これらのセクションで、分野への各パケットの分割を表示します、そして、次に、フィールド定義を列挙します。
All OSPF packet types (other than the OSPF Hello packets) deal with lists of LSAs. For example, Link State Update packets implement the flooding of LSAs throughout the OSPF routing domain. Because of this, OSPF protocol packets cannot be parsed unless the format of LSAs is also understood. The format of LSAs is described in Section A.4.
すべてのOSPFパケットタイプ(OSPF Helloパケットを除いた)がLSAsのリストに対処します。 例えば、Link州UpdateパケットはOSPF経路ドメイン中でLSAsの氾濫を実装します。 これのために、また、LSAsの形式が理解されていない場合、OSPFプロトコルパケットを分析できません。 LSAsの形式はセクションA.4で説明されます。
The receive processing of OSPF packets is detailed in Section 8.2. The sending of OSPF packets is explained in Section 8.1.
セクション8.2で詳述したOSPFパケットの処理を受けてください。 OSPFパケットの発信はセクション8.1で説明されます。
Moy Standards Track [Page 163] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[163ページ]RFC2178OSPFバージョン1997年7月2日
A.3.1 The OSPF packet header
OSPFパケットのヘッダーのA.3.1
Every OSPF packet starts with a standard 24 byte header. This header contains all the information necessary to determine whether the packet should be accepted for further processing. This determination is described in Section 8.2 of the specification.
あらゆるOSPFパケットが24バイトの標準のヘッダーから始めます。 このヘッダーはパケットがさらなる処理のために受け入れられるべきであるかどうか決定するのに必要なすべての情報を含んでいます。 この決断は仕様のセクション8.2で説明されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | Type | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン#| タイプ| パケット長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルータID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 領域ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| AuType| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version #
The OSPF version number. This specification documents version 2
of the protocol.
OSPFバージョンが付番するバージョン#。 この仕様はプロトコルのバージョン2を記録します。
Type
The OSPF packet types are as follows. See Sections A.3.2 through
A.3.6 for details.
OSPFパケットがタイプするタイプは以下の通りです。 詳細のためにセクションA.3.2をA.3.6で見てください。
Type Description
________________________________
1 Hello
2 Database Description
3 Link State Request
4 Link State Update
5 Link State Acknowledgment
型記述________________________________ こんにちは、2データベース記述3リンク州が、4リンク州のアップデート5がリンクするよう要求する1は承認を述べます。
Packet length
The length of the OSPF protocol packet in bytes. This length
includes the standard OSPF header.
パケット長、バイトで表現されるOSPFプロトコルパケットの長さ。 この長さは標準のOSPFヘッダーを含んでいます。
Router ID
The Router ID of the packet's source.
パケットのソースのルータID Router ID。
Moy Standards Track [Page 164] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[164ページ]RFC2178OSPFバージョン1997年7月2日
Area ID
A 32 bit number identifying the area that this packet belongs
to. All OSPF packets are associated with a single area. Most
travel a single hop only. Packets travelling over a virtual
link are labelled with the backbone Area ID of 0.0.0.0.
領域ID A32はこのパケットが属す領域を特定する数に噛み付きました。 すべてのOSPFパケットがただ一つの領域に関連しています。 大部分は単一のホップだけを旅行します。 仮想のリンクの上に移動するパケットは0.0のバックボーンArea IDでラベルされます。.0 .0。
Checksum
The standard IP checksum of the entire contents of the packet,
starting with the OSPF packet header but excluding the 64-bit
authentication field. This checksum is calculated as the 16-bit
one's complement of the one's complement sum of all the 16-bit
words in the packet, excepting the authentication field. If the
packet's length is not an integral number of 16-bit words, the
packet is padded with a byte of zero before checksumming. The
checksum is considered to be part of the packet authentication
procedure; for some authentication types the checksum
calculation is omitted.
チェックサム、OSPFパケットのヘッダーにもかかわらず、64ビットの認証分野を除くことをきっかけにパケットの全体のコンテンツの標準のIPチェックサム。 このチェックサムはパケットでのすべての16ビットの単語の1の補数合計の16ビットの1の補数として計算されます、認証分野を除いて。 パケットの長さが整数の16ビットの単語でないなら、パケットはchecksummingする前に、1バイトのゼロで水増しされます。 チェックサムはパケット認証手順の一部であると考えられます。 何人かの認証タイプにおいて、チェックサム計算は省略されます。
AuType
Identifies the authentication procedure to be used for the
packet. Authentication is discussed in Appendix D of the
specification. Consult Appendix D for a list of the currently
defined authentication types.
AuType Identifies、パケットに使用されるべき認証手順。 仕様のAppendix Dで認証について議論します。 現在定義された認証タイプのリストのためにAppendix Dに相談してください。
Authentication
A 64-bit field for use by the authentication scheme. See
Appendix D for details.
認証体系による使用のための認証のA64ビットの分野。 詳細に関してAppendix Dを見てください。
Moy Standards Track [Page 165] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[165ページ]RFC2178OSPFバージョン1997年7月2日
A.3.2 The Hello packet
A.3.2はHelloパケットです。
Hello packets are OSPF packet type 1. These packets are sent periodically on all interfaces (including virtual links) in order to establish and maintain neighbor relationships. In addition, Hello Packets are multicast on those physical networks having a multicast or broadcast capability, enabling dynamic discovery of neighboring routers.
こんにちは、パケットはそうです。OSPFパケットは1をタイプします。 隣人関係を確立して、維持するためにすべてのインタフェース(仮想のリンクを含んでいる)で定期的にこれらのパケットを送ります。 さらに、Hello Packetsはマルチキャストか放送能力(隣接しているルータの可能なダイナミックな発見)を持っているそれらの物理ネットワークのマルチキャストです。
All routers connected to a common network must agree on certain parameters (Network mask, HelloInterval and RouterDeadInterval). These parameters are included in Hello packets, so that differences can inhibit the forming of neighbor relationships. A detailed explanation of the receive processing for Hello packets is presented in Section 10.5. The sending of Hello packets is covered in Section 9.5.
一般的なネットワークに関連づけられたすべてのルータが、あるパラメタ(ネットワークマスク、HelloInterval、およびRouterDeadInterval)に同意しなければなりません。 これらのパラメタは、違いが隣人関係の形成を禁止できるように、Helloパケットに含まれています。 Aが説明を詳しく述べた、パケットがセクション10.5に提示されるHelloのために処理を受けてください。 Helloパケットの発信はセクション9.5でカバーされています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 1 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | Options | Rtr Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RouterDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Designated Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Designated Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン#| 1 | パケット長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルータID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 領域ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| AuType| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ネットワークマスク| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HelloInterval| オプション| Rtr Pri| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RouterDeadInterval| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 代表ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バックアップに指定されたルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 隣人| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
Moy Standards Track [Page 166] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[166ページ]RFC2178OSPFバージョン1997年7月2日
Network mask
The network mask associated with this interface. For example,
if the interface is to a class B network whose third byte is
used for subnetting, the network mask is 0xffffff00.
ネットワークマスクがこのインタフェースに関連づけたマスクをネットワークでつないでください。 例えば、3番目のバイトがサブネッティングに使用されるクラスBネットワークにインタフェースがあるなら、ネットワークマスクは0xffffff00です。
Options
The optional capabilities supported by the router, as documented
in Section A.2.
任意の能力がセクションA.2に記録されるようにルータでサポートしたオプション。
HelloInterval
The number of seconds between this router's Hello packets.
HelloInterval、このルータのHelloパケットの間の秒数。
Rtr Pri
This router's Router Priority. Used in (Backup) Designated
Router election. If set to 0, the router will be ineligible to
become (Backup) Designated Router.
Rtr Pri ThisルータのRouter Priority。 Router選挙に指定された(バックアップ)では、使用されています。 0に設定されると、ルータはRouterに指定された(バックアップ)になるのにおいて不適格になるでしょう。
RouterDeadInterval
The number of seconds before declaring a silent router down.
RouterDeadInterval、静かなルータを宣言する前の秒数はダウンします。
Designated Router
The identity of the Designated Router for this network, in the
view of the sending router. The Designated Router is identified
here by its IP interface address on the network. Set to 0.0.0.0
if there is no Designated Router.
このネットワークのために送付ルータの視点でDesignated RouterのアイデンティティにRouterを指定しました。 Designated Routerはここでネットワークに関するIPインターフェース・アドレスによって特定されます。 0.0に.0を設定してください。.0 Designated Routerが全くなければ。
Backup Designated Router
The identity of the Backup Designated Router for this network,
in the view of the sending router. The Backup Designated Router
is identified here by its IP interface address on the network.
Set to 0.0.0.0 if there is no Backup Designated Router.
Designated Routerのバックアップをとってください。送付ルータの視点におけるこのネットワークのためのBackup Designated Routerのアイデンティティ。 Backup Designated Routerはここでネットワークに関するIPインターフェース・アドレスによって特定されます。 0.0に.0を設定してください。.0 Backup Designated Routerが全くなければ。
Neighbor
The Router IDs of each router from whom valid Hello packets have
been seen recently on the network. Recently means in the last
RouterDeadInterval seconds.
ネットワークで有効なHelloパケットが最近見られたそれぞれのルータのRouter IDを近所付き合いさせてください。 最後のRouterDeadInterval秒に最近、意味します。
Moy Standards Track [Page 167] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[167ページ]RFC2178OSPFバージョン1997年7月2日
A.3.3 The Database Description packet
A.3.3はDatabase記述パケットです。
Database Description packets are OSPF packet type 2. These packets are exchanged when an adjacency is being initialized. They describe the contents of the link-state database. Multiple packets may be used to describe the database. For this purpose a poll-response procedure is used. One of the routers is designated to be the master, the other the slave. The master sends Database Description packets (polls) which are acknowledged by Database Description packets sent by the slave (responses). The responses are linked to the polls via the packets' DD sequence numbers.
データベース記述パケットはOSPFパケットタイプ2です。 隣接番組を初期化しているとき、これらのパケットを交換します。 彼らはリンク州のデータベースのコンテンツについて説明します。 複数のパケットが、データベースについて説明するのに使用されるかもしれません。 このために投票応答手順は使用されています。 ルータの1つはマスターになるように指定されて、もう片方が奴隷です。 マスターは奴隷(応答)によって送られたDatabase記述パケットによって承認される記述パケット(投票)をDatabaseに送ります。 応答はパケットのDD一連番号で投票にリンクされます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 2 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface MTU | Options |0|0|0|0|0|I|M|MS
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DD sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン#| 2 | パケット長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルータID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 領域ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| AuType| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェースMTU| オプション|0|0|0|0|0|I|M|+++++++++++++++++++++++++++++++++さん| DD一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | + LSAヘッダー-+| | +- -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
The format of the Database Description packet is very similar to both the Link State Request and Link State Acknowledgment packets. The main part of all three is a list of items, each item describing a piece of the link-state database. The sending of Database
Database記述パケットの形式はLink州RequestとLink州Acknowledgmentパケットの両方と非常に同様です。 すべての3の主部は項目、リンク州のデータベースの1つの断片について説明する各個条のリストです。 Databaseの発信
Moy Standards Track [Page 168] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[168ページ]RFC2178OSPFバージョン1997年7月2日
Description Packets is documented in Section 10.8. The reception of Database Description packets is documented in Section 10.6.
記述Packetsはセクション10.8に記録されます。 Database記述パケットのレセプションはセクション10.6に記録されます。
Interface MTU
The size in bytes of the largest IP datagram that can be sent out
the associated interface, without fragmentation. The MTUs of
common Internet link types can be found in Table 7-1 of [Ref22].
Interface MTU should be set to 0 in Database Description packets
sent over virtual links.
MTUを連結してください。それが最も大きいIPデータグラムであることができることのバイトで表現されるサイズは関連インタフェースを出しました、断片化なしで。 [Ref22]のTable7-1で一般的なインターネットリンク型のMTUsを見つけることができます。 インタフェースMTUはパケットが仮想のリンクの上に送ったDatabase記述で0に用意ができるべきです。
Options
The optional capabilities supported by the router, as documented
in Section A.2.
任意の能力がセクションA.2に記録されるようにルータでサポートしたオプション。
I-bit
The Init bit. When set to 1, this packet is the first in the
sequence of Database Description Packets.
Initが噛み付いたI-ビット。 1に設定されると、このパケットはDatabase記述Packetsの系列で1番目です。
M-bit
The More bit. When set to 1, it indicates that more Database
Description Packets are to follow.
Moreが噛み付いたM-ビット。 1に設定されると、それは、より多くのDatabase記述Packetsが続くことになっているのを示します。
MS-bit
The Master/Slave bit. When set to 1, it indicates that the router
is the master during the Database Exchange process. Otherwise,
the router is the slave.
Master/奴隷が噛み付いたMS-ビット。 1に設定されると、それは、ルータがDatabase Exchangeプロセスの間マスターであることを示します。 さもなければ、ルータは奴隷です。
DD sequence number
Used to sequence the collection of Database Description Packets.
The initial value (indicated by the Init bit being set) should be
unique. The DD sequence number then increments until the complete
database description has been sent.
Database記述Packetsの収集を配列するDD一連番号Used。 初期の値(設定されるInitビットで、示される)はユニークであるべきです。 記述を送る完全なデータベースまでのDDの一連番号の当時の増分。
The rest of the packet consists of a (possibly partial) list of the link-state database's pieces. Each LSA in the database is described by its LSA header. The LSA header is documented in Section A.4.1. It contains all the information required to uniquely identify both the LSA and the LSA's current instance.
パケットの残りはリンク州のデータベースの片の(ことによると部分的)のリストから成ります。 データベースの各LSAはLSAヘッダーによって説明されます。 LSAヘッダーはセクションA.4.1に記録されます。 それは唯一LSAとLSAの現在のインスタンスの両方を特定するのに必要であるすべての情報を含んでいます。
Moy Standards Track [Page 169] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[169ページ]RFC2178OSPFバージョン1997年7月2日
A.3.4 The Link State Request packet
A.3.4はLink州Requestパケットです。
Link State Request packets are OSPF packet type 3. After exchanging Database Description packets with a neighboring router, a router may find that parts of its link-state database are out-of-date. The Link State Request packet is used to request the pieces of the neighbor's database that are more up-to-date. Multiple Link State Request packets may need to be used.
リンク州RequestパケットはOSPFパケットタイプ3です。 Database記述パケットを隣接しているルータと交換した後に、ルータによって、リンク州のデータベースの部分が時代遅れであることがわかるかもしれません。 Link州Requestパケットは、隣人のデータベースの、より最新の断片を要求するのに使用されます。 複数のLink州Requestパケットが、使用される必要があるかもしれません。
A router that sends a Link State Request packet has in mind the precise instance of the database pieces it is requesting. Each instance is defined by its LS sequence number, LS checksum, and LS age, although these fields are not specified in the Link State Request Packet itself. The router may receive even more recent instances in response.
Link州Requestパケットを送るルータはそれが要求しているデータベース片の正確なインスタンスを考えています。 各インスタンスはLS一連番号、LSチェックサム、およびLS時代までに定義されます、これらの分野はLink州Request Packet自身で指定されませんが。 ルータは応答におけるさらに最近のインスタンスを受けるかもしれません。
The sending of Link State Request packets is documented in Section 10.9. The reception of Link State Request packets is documented in Section 10.7.
Link州Requestパケットの発信はセクション10.9に記録されます。 Link州Requestパケットのレセプションはセクション10.7に記録されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 3 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン#| 3 | パケット長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルータID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 領域ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| AuType| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSはタイプします。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 州のIDをリンクしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 広告ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
Each LSA requested is specified by its LS type, Link State ID, and Advertising Router. This uniquely identifies the LSA, but not its instance. Link State Request packets are understood to be requests for the most recent instance (whatever that might be).
LSAが要求したそれぞれがLink州のLSタイプ、ID、およびAdvertising Routerによって指定されます。 これは唯一インスタンスではなく、LSAを特定します。 リンク州Requestパケットは最新のインスタンス(それはことなら何でもであるかもしれない)を求める要求であることが理解されています。
Moy Standards Track [Page 170] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[170ページ]RFC2178OSPFバージョン1997年7月2日
A.3.5 The Link State Update packet
A.3.5はLink州Updateパケットです。
Link State Update packets are OSPF packet type 4. These packets implement the flooding of LSAs. Each Link State Update packet carries a collection of LSAs one hop further from their origin. Several LSAs may be included in a single packet.
リンク州UpdateパケットはOSPFパケットタイプ4です。 これらのパケットはLSAsの氾濫を実装します。 それぞれのLink州Updateパケットはさらに彼らの発生源からのワンバウンドのLSAsの収集を運びます。 数個のLSAsが単一のパケットに含まれるかもしれません。
Link State Update packets are multicast on those physical networks that support multicast/broadcast. In order to make the flooding procedure reliable, flooded LSAs are acknowledged in Link State Acknowledgment packets. If retransmission of certain LSAs is necessary, the retransmitted LSAs are always carried by unicast Link State Update packets. For more information on the reliable flooding of LSAs, consult Section 13.
リンク州Updateパケットはマルチキャスト/放送をサポートするそれらの物理ネットワークのマルチキャストです。 氾濫手順を信頼できるようにするように、水につかっているLSAsはLink州Acknowledgmentパケットで承認されます。 あるLSAsの「再-トランスミッション」が必要であるなら、再送されたLSAsはいつもユニキャストLink州Updateパケットによって運ばれます。 LSAsの信頼できる氾濫の詳しい情報に関しては、セクション13に相談してください。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 4 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # LSAs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- +-+
| LSAs |
+- +-+
| ... |
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン#| 4 | パケット長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルータID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 領域ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| AuType| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # LSAs| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- +-+ | LSAs| +- +-+ | ... |
# LSAs
The number of LSAs included in this update.
# このアップデートにLSAsの数を含んでいるLSAs。
The body of the Link State Update packet consists of a list of LSAs. Each LSA begins with a common 20 byte header, described in Section A.4.1. Detailed formats of the different types of LSAs are described in Section A.4.
Link州UpdateパケットのボディーはLSAsのリストから成ります。 各LSAはセクションA.4.1で説明された20バイトの一般的なヘッダーと共に始まります。 LSAsの異なったタイプの詳細な形式はセクションA.4で説明されます。
Moy Standards Track [Page 171] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[171ページ]RFC2178OSPFバージョン1997年7月2日
A.3.6 The Link State Acknowledgment packet
A.3.6はLink州Acknowledgmentパケットです。
Link State Acknowledgment Packets are OSPF packet type 5. To make the flooding of LSAs reliable, flooded LSAs are explicitly acknowledged. This acknowledgment is accomplished through the sending and receiving of Link State Acknowledgment packets. Multiple LSAs can be acknowledged in a single Link State Acknowledgment packet.
リンク州Acknowledgment PacketsはOSPFパケットタイプ5です。 LSAsの氾濫を信頼できるようにするように、水につかっているLSAsは明らかに承認されます。 この承認はLink州Acknowledgmentパケットの送受信で実行されます。 単一のLink州Acknowledgmentパケットで複数のLSAsを承認できます。
Depending on the state of the sending interface and the sender of the corresponding Link State Update packet, a Link State Acknowledgment packet is sent either to the multicast address AllSPFRouters, to the multicast address AllDRouters, or as a unicast. The sending of Link State Acknowledgment packets is documented in Section 13.5. The reception of Link State Acknowledgment packets is documented in Section 13.7.
対応するLink州Updateパケットの送付インタフェースと送付者の状態によって、マルチキャストアドレスAllSPFRoutersか、マルチキャストアドレスAllDRoutersか、ユニキャストとしてLink州Acknowledgmentパケットを送ります。 Link州Acknowledgmentパケットの発信はセクション13.5に記録されます。 Link州Acknowledgmentパケットのレセプションはセクション13.7に記録されます。
The format of this packet is similar to that of the Data Description packet. The body of both packets is simply a list of LSA headers.
このパケットの形式はData記述パケットのものと同様です。 両方のパケットのボディーは単にLSAヘッダーのリストです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 5 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン#| 5 | パケット長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルータID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 領域ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| AuType| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | + LSAヘッダー-+| | +- -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
Moy Standards Track [Page 172] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[172ページ]RFC2178OSPFバージョン1997年7月2日
Each acknowledged LSA is described by its LSA header. The LSA header is documented in Section A.4.1. It contains all the information required to uniquely identify both the LSA and the LSA's current instance.
それぞれの承認されたLSAはLSAヘッダーによって説明されます。 LSAヘッダーはセクションA.4.1に記録されます。 それは唯一LSAとLSAの現在のインスタンスの両方を特定するのに必要であるすべての情報を含んでいます。
A.4 LSA formats
A.4 LSA形式
This memo defines five distinct types of LSAs. Each LSA begins with a standard 20 byte LSA header. This header is explained in Section A.4.1. Succeeding sections then diagram the separate LSA types.
このメモはLSAsの5つの異なったタイプを定義します。 各LSAは20バイトの標準のLSAヘッダーと共に始まります。 このヘッダーはセクションA.4.1で説明されます。 そして、続くセクションは別々のLSAタイプを図解します。
Each LSA describes a piece of the OSPF routing domain. Every router originates a router-LSA. In addition, whenever the router is elected Designated Router, it originates a network-LSA. Other types of LSAs may also be originated (see Section 12.4). All LSAs are then flooded throughout the OSPF routing domain. The flooding algorithm is reliable, ensuring that all routers have the same collection of LSAs. (See Section 13 for more information concerning the flooding algorithm). This collection of LSAs is called the link-state database.
各LSAはOSPF経路ドメインの1つの断片について説明します。 あらゆるルータがルータ-LSAを溯源します。 さらに、ルータがDesignated Routerに選出されるときはいつも、それはネットワーク-LSAを溯源します。 また、LSAsの他のタイプは溯源されるかもしれません(セクション12.4を見てください)。 すべてのLSAsがその時、OSPF経路ドメイン中で水につかっています。 すべてのルータにはLSAsの同じ収集があるのを確実にして、氾濫アルゴリズムは信頼できます。 (詳しい情報に関して氾濫アルゴリズムに関してセクション13を見ます。) LSAsのこの収集はリンク州のデータベースと呼ばれます。
From the link state database, each router constructs a shortest path tree with itself as root. This yields a routing table (see Section 11). For the details of the routing table build process, see Section 16.
リンク州のデータベースから、各ルータは根としてそれ自体で最短パス木を組み立てます。 これは経路指定テーブルをもたらします(セクション11を見てください)。 経路指定テーブルの細部に関しては、プロセスを建ててください、そして、セクション16を見てください。
Moy Standards Track [Page 173] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[173ページ]RFC2178OSPFバージョン1997年7月2日
A.4.1 The LSA header
LSAヘッダーのA.4.1
All LSAs begin with a common 20 byte header. This header contains enough information to uniquely identify the LSA (LS type, Link State ID, and Advertising Router). Multiple instances of the LSA may exist in the routing domain at the same time. It is then necessary to determine which instance is more recent. This is accomplished by examining the LS age, LS sequence number and LS checksum fields that are also contained in the LSA header.
すべてのLSAsが20バイトの一般的なヘッダーと共に始まります。 このヘッダーは唯一、LSA(Link州のLSタイプ、ID、およびAdvertising Router)を特定できるくらいの情報を含んでいます。 LSAの複数のインスタンスが同時に、経路ドメインに存在するかもしれません。 どちらのインスタンスが、より最近であるかを決定するのがその時、必要です。 これは、また、LSAヘッダーに含まれているLS時代、LS一連番号、およびLSチェックサム分野を調べることによって、達成されます。
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 | LS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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時代| オプション| LSはタイプします。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 州のIDをリンクしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 広告ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSチェックサム| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LS age
The time in seconds since the LSA was originated.
LSは秒のLSAが溯源されて以来の時に年をとります。
Options
The optional capabilities supported by the described portion of
the routing domain. OSPF's optional capabilities are documented
in Section A.2.
任意の能力が経路ドメインの説明された部分でサポートしたオプション。 OSPFの任意の能力はセクションA.2に記録されます。
LS type
The type of the LSA. Each LSA type has a separate advertisement
format. The LSA types defined in this memo are as follows (see
Section 12.1.3 for further explanation):
LSはLSAのタイプをタイプします。 それぞれのLSAタイプには、別々の広告形式があります。 このメモで定義されたLSAタイプは以下の通りです(詳細な説明に関してセクション12.1.3を見てください):
LS Type Description
___________________________________
1 Router-LSAs
2 Network-LSAs
3 Summary-LSAs (IP network)
4 Summary-LSAs (ASBR)
5 AS-external-LSAs
LS型記述___________________________________ 1 ルータ-LSAs2Network-LSAs3Summary-LSAs(IPネットワーク)4Summary-LSAs(ASBR)5ASの外部のLSAs
Moy Standards Track [Page 174] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[174ページ]RFC2178OSPFバージョン1997年7月2日
Link State ID
This field identifies the portion of the internet environment
that is being described by the LSA. The contents of this field
depend on the LSA's LS type. For example, in network-LSAs the
Link State ID is set to the IP interface address of the
network's Designated Router (from which the network's IP address
can be derived). The Link State ID is further discussed in
Section 12.1.4.
Thisがさばくリンク州IDはLSAによって説明されているインターネット環境の部分を特定します。 この分野の内容はLSAのLSタイプに頼っています。 例えば、ネットワーク-LSAsでは、Link州IDはネットワークのDesignated Router(ネットワークのIPアドレスを引き出すことができる)のIPインターフェース・アドレスに設定されます。 セクション12.1.4でLink州IDについてさらに議論します。
Advertising Router
The Router ID of the router that originated the LSA. For
example, in network-LSAs this field is equal to the Router ID of
the network's Designated Router.
LSAを溯源したルータのRouter Router IDの広告を出します。 例えば、ネットワーク-LSAsでは、この分野はネットワークのDesignated RouterのRouter IDと等しいです。
LS sequence number
Detects old or duplicate LSAs. Successive instances of an LSA
are given successive LS sequence numbers. See Section 12.1.6
for more details.
LS一連番号Detects老人か写しLSAs。 連続したLS一連番号をLSAの連続したインスタンスに与えます。 その他の詳細に関してセクション12.1.6を見てください。
LS checksum
The Fletcher checksum of the complete contents of the LSA,
including the LSA header but excluding the LS age field. See
Section 12.1.7 for more details.
LSAにもかかわらず、LSAヘッダーを含んでいますが、LS時代を除く完全なコンテンツのフレッチャーチェックサムがさばくLSチェックサム。 その他の詳細に関してセクション12.1.7を見てください。
length
The length in bytes of the LSA. This includes the 20 byte LSA
header.
長さ、LSAのバイトで表現される長さ。 これは20バイトのLSAヘッダーを含んでいます。
Moy Standards Track [Page 175] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[175ページ]RFC2178OSPFバージョン1997年7月2日
A.4.2 Router-LSAs
A.4.2ルータ-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 Section 12.4.1.
ルータ-LSAsはType1LSAsです。 領域の各ルータはルータ-LSAを溯源します。 LSAはその領域へのルータのリンク(すなわち、インタフェース)の状態と費用について説明します。 独身のルータ-LSAでその領域へのルータのリンクのすべてについて説明しなければなりません。 ルータ-LSAsの構造に関する詳細に関しては、セクション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 |V|E|B| 0 | # links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | # TOS | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOS | 0 | TOS 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 |V|E|B| 0 | # リンク| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IDをリンクしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | リンクデータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| # TOS| メートル法| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOS| 0 | TOSメートル法です。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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はただ一つの領域だけ中で水につかっています。
bit V
When set, the router is an endpoint of one or more fully adjacent
virtual links having the described area as Transit area (V is for
virtual link endpoint).
Whenが設定するビットV、ルータはTransit領域として説明された領域を持っている1個以上の完全に隣接している仮想のリンクの終点(仮想のリンク終点にはVがある)です。
Moy Standards Track [Page 176] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[176ページ]RFC2178OSPFバージョン1997年7月2日
bit E
When set, the router is an AS boundary router (E is for external).
ビットE Whenはセットして、ルータはAS境界ルータ(外部にはEがある)です。
bit B
When set, the router is an area border router (B is for border).
ビットB Whenはセットして、ルータは境界ルータ(境界にはBがある)です。
# links
The number of router links described in this LSA. This must be
the total collection of router links (i.e., interfaces) to the
area.
# ルータリンクの数がこのLSAで説明したリンク。 これはその領域へのルータリンク(すなわち、インタフェース)の総収集であるに違いありません。
The following fields are used to describe each router link (i.e., interface). Each router link is typed (see the below Type field). The Type field indicates the kind of link being described. It may be a link to a transit network, to another router or to a stub network. The values of all the other fields describing a router link depend on the link's Type. For example, each link has an associated 32-bit Link Data field. For links to stub networks this field specifies the network's IP address mask. For other link types the Link Data field specifies the router interface's IP address.
以下の分野は、それぞれのルータリンクについて説明するのに使用されます(すなわち、連結してください)。 それぞれのルータリンクはタイプされます(下にType分野を見てください)。 Type分野は説明されるリンクの種類を示します。 それはトランジットネットワーク、または、別のルータ、または、スタッブネットワークへのリンクであるかもしれません。 ルータリンクについて説明する他のすべての分野の値はリンクのTypeに依存します。 例えば、各リンクには、関連32ビットのLink Data分野があります。 リンクがネットワークを引き抜くように、この分野はネットワークのIPアドレスマスクを指定します。 他のリンク型として、Link Data分野はルータインタフェースのIPアドレスを指定します。
Type
A quick description of the router link. One of the following.
Note that host routes are classified as links to stub networks
with network mask of 0xffffffff.
ルータリンクのA迅速な記述をタイプしてください。 以下の1つ。 ホストルートが0xffffffffのネットワークマスクでネットワークを引き抜くためにリンクとして分類されることに注意してください。
Type Description
__________________________________________________
1 Point-to-point connection to another router
2 Connection to a transit network
3 Connection to a stub network
4 Virtual link
型記述__________________________________________________ 1 aへの2Connectionが通過する別のルータへの二地点間接続はスタッブネットワーク4Virtualリンクに3Connectionをネットワークでつなぎます。
Link ID
Identifies the object that this router link connects to. Value
depends on the link's Type. When connecting to an object that
also originates an LSA (i.e., another router or a transit
network) the Link ID is equal to the neighboring LSA's Link
State ID. This provides the key for looking up the neighboring
LSA in the link state database during the routing table
calculation. See Section 12.2 for more details.
ID Identifiesをリンクしてください。このルータリンクが接続するオブジェクト。 値はリンクのTypeに依存します。 また、LSA(すなわち、別のルータかトランジットネットワーク)を溯源するオブジェクトに接続するとき、Link IDは隣接しているLSAのLink州IDと等しいです。 これは経路指定テーブル計算の間、リンク州のデータベースで隣接しているLSAを見上げるためのキーを提供します。 その他の詳細に関してセクション12.2を見てください。
Moy Standards Track [Page 177] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[177ページ]RFC2178OSPFバージョン1997年7月2日
Type Link ID
______________________________________
1 Neighboring router's Router ID
2 IP address of Designated Router
3 IP network/subnet number
4 Neighboring router's Router ID
リンクIDをタイプしてください。______________________________________ Designated Router3IPネットワーク/サブネットNo.4NeighboringルータのRouter IDに関する1つの隣接しているルータのRouter ID2IPアドレス
Link Data
Value again depends on the link's Type field. For connections to
stub networks, Link Data specifies the network's IP address
mask. For unnumbered point-to-point connections, it specifies
the interface's MIB-II [Ref8] ifIndex value. For the other link
types it specifies the router interface's IP address. This
latter piece of information is needed during the routing table
build process, when calculating the IP address of the next hop.
See Section 16.1.1 for more details.
リンクData Valueは再びリンクのTypeフィールドによります。 接続がネットワークを引き抜くように、Link DataはネットワークのIPアドレスマスクを指定します。 無数の二地点間接続として、それはインタフェースのMIB-II[Ref8]ifIndex価値を指定します。 他のリンク型として、それはルータインタフェースのIPアドレスを指定します。 次のホップのIPアドレスについて計算するとき、この後者の情報がテーブルがプロセスを建てるルーティングの間、必要です。 その他の詳細に関してセクション16.1.1を見てください。
# TOS
The number of different TOS metrics given for this link, not
counting the required link metric (referred to as the TOS 0
metric in [Ref9]). For example, if no additional TOS metrics
are given, this field is set to 0.
# TOS、必要なリンクを数えるのではなく、このリンクにメートル法で([Ref9]のメートル法のTOS0と呼ばれます)与えられた異なったTOS測定基準の数。 例えば、どんな追加TOS測定基準も与えないなら、この分野を0に設定します。
metric
The cost of using this router link.
メートル法、このルータリンクを使用する費用。
Additional TOS-specific information may also be included, for backward compatibility with previous versions of the OSPF specification ([Ref9]). Within each link, and for each desired TOS, TOS TOS-specific link information may be encoded as follows:
また、追加TOS-特殊情報はOSPF仕様([Ref9])の旧バージョンとの後方の互換性のために含まれるかもしれません。 各リンク以内とそれぞれの必要なTOSに関して、TOS TOS特有のリンク情報は以下の通りコード化されるかもしれません:
TOS IP Type of Service that this metric refers to. The encoding of
TOS in OSPF LSAs is described in Section 12.3.
ServiceのTOS IP Type、これほどメートル法、そんなに言及します。 OSPF LSAsでのTOSのコード化はセクション12.3で説明されます。
TOS metric
TOS-specific metric information.
TOSのメートル法のTOS特有のメートル法の情報。
Moy Standards Track [Page 178] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[178ページ]RFC2178OSPFバージョン1997年7月2日
A.4.3 Network-LSAs
A.4.3ネットワーク-LSAs
Network-LSAs are the Type 2 LSAs. A network-LSA is originated for each broadcast and NBMA network in the area which supports two or more routers. The network-LSA is originated by the network's Designated Router. The LSA describes all routers attached to the network, including the Designated Router itself. The LSA's Link State ID field lists the IP interface address of the Designated Router.
ネットワーク-LSAsはType2LSAsです。 ネットワーク-LSAは2つ以上のルータをサポートする領域のそれぞれの放送とNBMAネットワークのために溯源されます。 LSAをネットワークでつなぐのは自分のDesignated Routerによって溯源されます。 LSAはDesignated Router自身を含むネットワークに付けられたすべてのルータについて説明します。 LSAのLink州ID分野はDesignated RouterのIPインターフェース・アドレスを記載します。
The distance from the network to all attached routers is zero. This is why metric fields need not be specified in the network-LSA. For details concerning the construction of network-LSAs, see Section 12.4.2.
ネットワークから付属すべてのルータまでの距離はゼロです。 これはメートル法の分野がネットワーク-LSAで指定される必要はない理由です。 ネットワーク-LSAsの構造に関する詳細に関しては、セクション12.4.2を見てください。
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 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attached Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
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時代| オプション| 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 州のIDをリンクしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 広告ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSチェックサム| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ネットワークマスク| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 付属ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
Network Mask
The IP address mask for the network. For example, a class A
network would have the mask 0xff000000.
アドレスがネットワークのためにマスクをかけるMask IPをネットワークでつないでください。 例えば、クラスAネットワークには、マスク0xff000000があるでしょう。
Attached Router
The Router IDs of each of the routers attached to the network.
Actually, only those routers that are fully adjacent to the
Designated Router are listed. The Designated Router includes
itself in this list. The number of routers included can be
deduced from the LSA header's length field.
それぞれのルータの付属Router Router IDはネットワークに付きました。 それは完全にそうです。実際にそれらのルータだけ、記載されたDesignated Routerに隣接して。 Designated Routerはこのリストにそれ自体を含んでいます。 LSAヘッダーの長さの分野からルータを含む数を推論できます。
Moy Standards Track [Page 179] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[179ページ]RFC2178OSPFバージョン1997年7月2日
A.4.4 Summary-LSAs
A.4.4概要-LSAs
Summary-LSAs are the Type 3 and 4 LSAs. These LSAs are originated by area border routers. Summary-LSAs describe inter-area destinations. For details concerning the construction of summary-LSAs, see Section 12.4.3.
概要-LSAsはType3と4LSAsです。 これらのLSAsは境界ルータによって溯源されます。 概要-LSAsは相互領域の目的地について説明します。 概要-LSAsの構造に関する詳細に関しては、セクション12.4.3を見てください。
Type 3 summary-LSAs are used when the destination is an IP network. In this case the LSA's Link State ID field is an IP network number (if necessary, the Link State ID can also have one or more of the network's "host" bits set; see Appendix E for details). When the destination is an AS boundary router, a Type 4 summary-LSA is used, and the Link State ID field is the AS boundary router's OSPF Router ID. (To see why it is necessary to advertise the location of each ASBR, consult Section 16.4.) Other than the difference in the Link State ID field, the format of Type 3 and 4 summary-LSAs is identical.
目的地がIPネットワークであるときに、タイプ3概要-LSAsが使用されています。 この場合、LSAのLink州ID分野はIPネットワーク・ナンバー(また、必要なら、Link州IDはネットワークの「ホスト」ビットの1つ以上を設定させることができます; 詳細に関してAppendix Eを見る)です。 目的地がAS境界ルータであるときに、Type4概要-LSAは使用されています、そして、Link州ID分野はAS境界ルータのOSPF Router IDです。 (それぞれのASBRの位置の広告を出すのがなぜ必要であるかを確認するには、セクション16.4に相談してください。) Link州ID分野の違いを除いて、Type3と4概要-LSAsの形式は同じです。
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 | 3 or 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOS | TOS metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
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時代| オプション| 3か4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 州のIDをリンクしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 広告ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSチェックサム| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ネットワークマスク| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | メートル法| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOS| TOSメートル法です。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
For stub areas, Type 3 summary-LSAs can also be used to describe a (per-area) default route. Default summary routes are used in stub areas instead of flooding a complete set of external routes. When describing a default summary route, the summary-LSA's Link State ID is always set to DefaultDestination (0.0.0.0) and the Network Mask is set to 0.0.0.0.
また、スタッブ領域において、(領域)デフォルトルートを説明するのにType3概要-LSAsを使用できます。 デフォルト概要ルートは完全な外部経路をあふれさせることの代わりにスタッブ領域で使用されます。 デフォルト概要ルートを説明するとき、概要-LSA Link州IDがいつもDefaultDestinationに設定される、(0.0、.0、.0と)Network Maskは.0に0.0に.0を設定することです。
Moy Standards Track [Page 180] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[180ページ]RFC2178OSPFバージョン1997年7月2日
Network Mask
For Type 3 summary-LSAs, this indicates the destination network's
IP address mask. For example, when advertising the location of a
class A network the value 0xff000000 would be used. This field is
not meaningful and must be zero for Type 4 summary-LSAs.
Mask For Type3概要-LSAsをネットワークでつないでください、そして、これは送信先ネットワークのIPアドレスマスクを示します。 クラスAネットワークの位置の広告を出すとき、例えば、値の0xff000000は使用されるでしょう。 この分野は、重要でなく、Type4概要-LSAsのためのゼロでなければなりません。
metric
The cost of this route. Expressed in the same units as the
interface costs in the router-LSAs.
メートル法、このルートの費用。 インタフェースコストと同じユニットでは、ルータ-LSAsで言い表されます。
Additional TOS-specific information may also be included, for backward compatibility with previous versions of the OSPF specification ([Ref9]). For each desired TOS, TOS-specific information is encoded as follows:
また、追加TOS-特殊情報はOSPF仕様([Ref9])の旧バージョンとの後方の互換性のために含まれるかもしれません。 それぞれの必要なTOSに関しては、TOS-特殊情報は以下の通りコード化されます:
TOS IP Type of Service that this metric refers to. The encoding of
TOS in OSPF LSAs is described in Section 12.3.
ServiceのTOS IP Type、これほどメートル法、そんなに言及します。 OSPF LSAsでのTOSのコード化はセクション12.3で説明されます。
TOS metric
TOS-specific metric information.
TOSのメートル法のTOS特有のメートル法の情報。
Moy Standards Track [Page 181] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[181ページ]RFC2178OSPFバージョン1997年7月2日
A.4.5 AS-external-LSAs
A.4.5、外部のLSAs
AS-external-LSAs are the Type 5 LSAs. These LSAs are originated by AS boundary routers, and describe destinations external to the AS. For details concerning the construction of AS-external-LSAs, see Section 12.4.3.
ASの外部のLSAsはType5LSAsです。 これらのLSAsはAS境界ルータによって溯源されて、ASへの外部の目的地について説明します。 ASの外部のLSAsの構造に関する詳細に関しては、セクション12.4.3を見てください。
AS-external-LSAs usually describe a particular external destination. For these LSAs the Link State ID field specifies an IP network number (if necessary, the Link State ID can also have one or more of the network's "host" bits set; see Appendix E for details). AS- external-LSAs are also used to describe a default route. Default routes are used when no specific route exists to the destination. When describing a default route, the Link State ID is always set to DefaultDestination (0.0.0.0) and the Network Mask is set to 0.0.0.0.
通常、ASの外部のLSAsは特定の外部の目的地について説明します。 これらのLSAsとして、Link州ID分野はIPネットワーク・ナンバーを指定します(また、必要なら、Link州IDはネットワークの「ホスト」ビットの1つ以上を設定させることができます; 詳細に関してAppendix Eを見てください)。 また、ASの外部のLSAsは、デフォルトルートを説明するのに使用されます。 どんな特定のルートも目的地に存在しないとき、デフォルトルートは使用されています。 デフォルトルートを説明するとき、Link州IDがいつもDefaultDestinationに設定される、(0.0、.0、.0と)Network Maskは.0に0.0に.0を設定することです。
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 | 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| 0 | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forwarding address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Route Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| TOS | TOS metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forwarding address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Route Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
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時代| オプション| 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 州のIDをリンクしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 広告ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSチェックサム| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ネットワークマスク| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| 0 | メートル法| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | フォーワーディング・アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 外部経路タグ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| TOS| TOSメートル法です。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | フォーワーディング・アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 外部経路タグ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
Moy Standards Track [Page 182] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[182ページ]RFC2178OSPFバージョン1997年7月2日
Network Mask
The IP address mask for the advertised destination. For
example, when advertising a class A network the mask 0xff000000
would be used.
アドレスが広告を出している目的地にマスクをかけるMask IPをネットワークでつないでください。 クラスAネットワークの広告を出すとき、例えば、マスク0xff000000は使用されるでしょう。
bit E
The type of external metric. If bit E is set, the metric
specified is a Type 2 external metric. This means the metric is
considered larger than any link state path. If bit E is zero,
the specified metric is a Type 1 external metric. This means
that it is expressed in the same units as the link state metric
(i.e., the same units as interface cost).
外部のタイプのEに噛み付いて、メートル法にしました。 ビットEが設定されるなら、指定されたメートル法はa Type2外部メートル法です。 これは、メートル法がどんなリンク州の経路よりも大きいと考えられることを意味します。 噛み付かれるならEがゼロである、メートル法で指定されて、Type1外部はメートル法ですか? これは、それがリンク状態と同じユニットでメートル法で(すなわち、インタフェース費用と同じユニット)言い表されることを意味します。
metric
The cost of this route. Interpretation depends on the external
type indication (bit E above).
メートル法、このルートの費用。 解釈は外部のタイプ指示(上のEに噛み付く)によります。
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 instead to the LSA's originator (i.e.,
the responsible AS boundary router).
広告を出している目的地へのフォーワーディング・アドレスDataトラフィックをこのアドレスに送るでしょう。 Forwardingであるならアドレスを設定します。0.0 .0 .0 代わりにLSAの創始者(すなわち、原因となるAS境界ルータ)にデータ通信量を送るでしょう。
External Route Tag
A 32-bit field attached to each external route. This is not
used by the OSPF protocol itself. It may be used to communicate
information between AS boundary routers; the precise nature of
such information is outside the scope of this specification.
外部のRoute Tag A32ビットの分野は各外部経路に付きました。 これはOSPFプロトコル自体によって使用されません。 それはAS境界ルータの間の情報を伝えるのに使用されるかもしれません。 この仕様の範囲の外にそのような情報の正確な本質があります。
Additional TOS-specific information may also be included, for backward compatibility with previous versions of the OSPF specification ([Ref9]). For each desired TOS, TOS-specific information is encoded as follows:
また、追加TOS-特殊情報はOSPF仕様([Ref9])の旧バージョンとの後方の互換性のために含まれるかもしれません。 それぞれの必要なTOSに関しては、TOS-特殊情報は以下の通りコード化されます:
TOS The Type of Service that the following fields concern. The
encoding of TOS in OSPF LSAs is described in Section 12.3.
以下の分野が関するServiceのTOS Type。 OSPF LSAsでのTOSのコード化はセクション12.3で説明されます。
bit E
For backward-compatibility with [Ref9].
[Ref9]との後方の互換性のビットE For。
TOS metric
TOS-specific metric information.
TOSのメートル法のTOS特有のメートル法の情報。
Forwarding address
For backward-compatibility with [Ref9].
[Ref9]との後方の互換性のアドレスForを進めます。
External Route Tag
For backward-compatibility with [Ref9].
[Ref9]との後方の互換性の外部のRoute Tag For。
Moy Standards Track [Page 183] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[183ページ]RFC2178OSPFバージョン1997年7月2日
B. Architectural Constants
B。 建築定数
Several OSPF protocol parameters have fixed architectural values. These parameters have been referred to in the text by names such as LSRefreshTime. The same naming convention is used for the configurable protocol parameters. They are defined in Appendix C.
いくつかのOSPFプロトコルパラメタが建築的価値を修理しました。 これらのパラメタはテキストにLSRefreshTimeなどの名前によって示されました。 同じ命名規則は構成可能なプロトコルパラメタに使用されます。 それらはAppendix Cで定義されます。
The name of each architectural constant follows, together with its value and a short description of its function.
それぞれの建築定数の名前は値と機能の短い記述と共に従います。
LSRefreshTime
The maximum time between distinct originations of any particular
LSA. If the LS age field of one of the router's self-originated
LSAs reaches the value LSRefreshTime, a new instance of the LSA is
originated, even though the contents of the LSA (apart from the
LSA header) will be the same. The value of LSRefreshTime is set
to 30 minutes.
最大がどんな特定のLSAの異なった創作の間でも調節するLSRefreshTime。 ルータの自己によって溯源されたLSAsの1つのLS時代分野が値のLSRefreshTimeに達するなら、LSAの新しいインスタンスは溯源されます、LSA(LSAヘッダーは別として)のコンテンツが同じになるでしょうが。 LSRefreshTimeの値は30分に設定されます。
MinLSInterval
The minimum time between distinct originations of any particular
LSA. The value of MinLSInterval is set to 5 seconds.
最小限がどんな特定のLSAの異なった創作の間でも調節するMinLSInterval。 MinLSIntervalの値は5秒に設定されます。
MinLSArrival
For any particular LSA, the minimum time that must elapse
between reception of new LSA instances during flooding. LSA
instances received at higher frequencies are discarded. The value
of MinLSArrival is set to 1 second.
MinLSArrival For、どんな特定のLSA、氾濫の間に新しいLSAインスタンスのレセプションの間で経過しなければならない最小の時間。 高周波化で受け取られたLSAインスタンスは捨てられます。 MinLSArrivalの値は1秒に設定されます。
MaxAge
The maximum age that an LSA can attain. When an LSA's LS age field
reaches MaxAge, it is reflooded in an attempt to flush the LSA
from the routing domain (See Section 14). LSAs of age MaxAge are
not used in the routing table calculation. The value of MaxAge is
set to 1 hour.
LSAが達することができる最大の時代のMaxAge。 LSAのLS時代分野がMaxAgeに達するとき、それは経路ドメインからLSAを洗い流す試みで「再-あふれ」ます(セクション14を見てください)。 時代MaxAgeのLSAsは経路指定テーブル計算に使用されません。 MaxAgeの値は1時間に設定されます。
CheckAge
When the age of an LSA in the link state database hits a multiple
of CheckAge, the LSA's checksum is verified. An incorrect
checksum at this time indicates a serious error. The value of
CheckAge is set to 5 minutes.
リンク州のデータベースのLSAの時代のCheckAge WhenはCheckAgeの倍数に当って、LSAのチェックサムは確かめられます。 不正確なチェックサムはこのとき、重大な誤りを示します。 CheckAgeの値は5分に設定されます。
MaxAgeDiff
The maximum time dispersion that can occur, as an LSA is flooded
throughout the AS. Most of this time is accounted for by the LSAs
sitting on router output queues (and therefore not aging) during
the flooding process. The value of MaxAgeDiff is set to 15
minutes.
MaxAgeDiff、LSAがAS中で水につかっているとき起こることができる最大の時間分散。 この時間の大部分は氾濫プロセスの間にルータ出力キュー(したがって、年をとらないで)に座るLSAsによって説明されます。 MaxAgeDiffの値は15分に設定されます。
Moy Standards Track [Page 184] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[184ページ]RFC2178OSPFバージョン1997年7月2日
LSInfinity
The metric value indicating that the destination described by an
LSA is unreachable. Used in summary-LSAs and AS-external-LSAs as
an alternative to premature aging (see Section 14.1). It is
defined to be the 24-bit binary value of all ones: 0xffffff.
LSAによって説明された目的地が手が届かないのを示しながら、メートル法のLSInfinityは評価します。 概要-LSAsとASの外部のLSAsでは、時期尚早な年をとること(セクション14.1を見る)に代わる手段として、使用されています。 それはすべてのものの24ビットの2進の値になるように定義されます: 0xffffff。
DefaultDestination
The Destination ID that indicates the default route. This route
is used when no other matching routing table entry can be found.
The default destination can only be advertised in AS-external-
LSAs and in stub areas' type 3 summary-LSAs. Its value is the IP
address 0.0.0.0. Its associated Network Mask is also always
0.0.0.0.
デフォルトルートを示すDefaultDestination Destination ID。 他の合っている経路指定テーブルエントリーを全く見つけることができないとき、このルートは使用されています。 AS外部のLSAsとスタッブ領域のタイプ3概要-LSAsでデフォルトの目的地の広告を出すことができるだけです。 値はIPアドレス0.0.0.0です。 いつもも関連Network Maskはそうです。0.0 .0 .0。
InitialSequenceNumber
The value used for LS Sequence Number when originating the first
instance of any LSA. Its value is the signed 32-bit integer
0x80000001.
InitialSequenceNumber、どんなLSAの最初のインスタンスも溯源するときLS Sequence Numberに使用される値。 値は署名している32ビットの整数0x80000001です。
MaxSequenceNumber
The maximum value that LS Sequence Number can attain. Its value
is the signed 32-bit integer 0x7fffffff.
MaxSequenceNumber、LS Sequence Numberが達することができる最大値。 値は署名している32ビットの整数0x7fffffffです。
Moy Standards Track [Page 185] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[185ページ]RFC2178OSPFバージョン1997年7月2日
C. Configurable Constants
C。 構成可能な定数
The OSPF protocol has quite a few configurable parameters. These parameters are listed below. They are grouped into general functional categories (area parameters, interface parameters, etc.). Sample values are given for some of the parameters.
OSPFプロトコルには、かなり多くの構成可能なパラメタがあります。 これらのパラメタは以下にリストアップされています。 それらは一般的な機能的なカテゴリ(領域パラメタ、インタフェース・パラメータなど)に分類されます。 パラメタのいくつかのために標本値を与えます。
Some parameter settings need to be consistent among groups of routers. For example, all routers in an area must agree on that area's parameters, and all routers attached to a network must agree on that network's IP network number and mask.
いくつかのパラメタ設定が、ルータのグループで一貫している必要があります。 例えば、領域のすべてのルータがその領域のパラメタに同意しなければなりません、そして、ネットワークに付けられたすべてのルータがそのネットワークのIPネットワーク・ナンバーとマスクに同意しなければなりません。
Some parameters may be determined by router algorithms outside of this specification (e.g., the address of a host connected to the router via a SLIP line). From OSPF's point of view, these items are still configurable.
いくつかのパラメタがこの仕様の外でルータアルゴリズムで決定するかもしれません(例えばホストのアドレスはSLIP系列でルータに接続しました)。 OSPFの観点から、これらの項目はまだ構成可能です。
C.1 Global parameters
C.1のグローバルなパラメタ
In general, a separate copy of the OSPF protocol is run for each area. Because of this, most configuration parameters are defined on a per-area basis. The few global configuration parameters are listed below.
一般に、OSPFプロトコルの別々のコピーは各領域に動かされます。 これのために、ほとんどの設定パラメータが地域制で定義されます。 わずかなグローバルな設定パラメータが以下にリストアップされています。
Router ID
This is a 32-bit number that uniquely identifies the router in
the Autonomous System. One algorithm for Router ID assignment is
to choose the largest or smallest IP address assigned to the
router. If a router's OSPF Router ID is changed, the router's
OSPF software should be restarted before the new Router ID takes
effect. Before restarting in order to change its Router ID, the
router should flush its self-originated LSAs from the routing
domain (see Section 14.1), or they will persist for up to MaxAge
minutes.
ルータID ThisはAutonomous Systemで唯一ルータを特定する32ビットの数です。 Router ID課題のための1つのアルゴリズムは最も大きいかルータに割り当てられる中で最も小さいIPアドレスを選ぶことです。 ルータのOSPF Router IDを変えるなら、新しいRouter IDが効く前にルータのOSPFソフトウェアを再開するべきです。 Router IDを変えるために再開する前に、ルータが経路ドメインから自己によって溯源されたLSAsを洗い流すべきですか(セクション14.1を見てください)、または彼らはMaxAgeまで分間固執するでしょう。
RFC1583Compatibility
Controls the preference rules used in Section 16.4 when choosing
among multiple AS-external-LSAs advertising the same destination.
When set to "enabled", the preference rules remain those
specified by RFC 1583 ([Ref9]). When set to "disabled", the
preference rules are those stated in Section 16.4.1, which
prevent routing loops when AS- external-LSAs for the same
destination have been originated from different areas (see
Section G.7). Set to "enabled" by default.
同じ目的地の広告を出す複数のASの外部のLSAsの中で選ぶとき優先規則がセクション16.4で使用したRFC1583Compatibility Controls。 「可能にされること」に設定されると、優先規則はRFC1583([Ref9])によって指定されたもののままで残っています。 「身体障害者」に設定されると、優先規則は同じ目的地への外部のLSAsのASが異なった領域から溯源されたとき、輪を発送するのを防ぐセクション16.4.1で述べられたもの(セクションG.7を見る)です。 デフォルトで「可能にされること」にセットしてください。
Moy Standards Track [Page 186] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[186ページ]RFC2178OSPFバージョン1997年7月2日
In order to minimize the chance of routing loops, all OSPF
routers in an OSPF routing domain should have
RFC1583Compatibility set identically. When there are routers
present that have not been updated with the functionality
specified in Section 16.4.1 of this memo, all routers should have
RFC1583Compatibility set to "enabled". Otherwise, all routers
should have RFC1583Compatibility set to "disabled", preventing
all routing loops.
ルーティング輪の機会を最小にするために、OSPF経路ドメインのすべてのOSPFルータで、同様にRFC1583Compatibilityを用意ができさせるべきです。 機能性がこの.1のセクション16.4メモで指定されている状態でアップデートされていないルータプレゼントがあるとき、すべてのルータで、「可能にされること」にRFC1583Compatibilityを用意ができさせるべきです。 さもなければ、すべてのルータで、すべてのルーティング輪を防いで、「身体障害者」にRFC1583Compatibilityを用意ができさせるべきです。
C.2 Area parameters
C.2領域パラメタ
All routers belonging to an area must agree on that area's configuration. Disagreements between two routers will lead to an inability for adjacencies to form between them, with a resulting hindrance to the flow of routing protocol and data traffic. The following items must be configured for an area:
領域に属すすべてのルータがその領域の構成に同意しなければなりません。 2つのルータの不一致はそれらの間で結果として起こる妨害でルーティング・プロトコルとデータ通信量の流れに隣接番組を形成できないことにつながるでしょう。 以下の項目を領域に構成しなければなりません:
Area ID
This is a 32-bit number that identifies the area. The Area ID of
0.0.0.0 is reserved for the backbone. If the area represents a
subnetted network, the IP network number of the subnetted network
may be used for the Area ID.
領域ID Thisは領域を特定する32ビットの数です。 Area ID、0.0 .0 .0 バックボーンのために、予約されます。 領域がサブネット化したネットワークを代表するなら、サブネット化したネットワークのIPネットワーク・ナンバーはArea IDに使用されるかもしれません。
List of address ranges
An OSPF area is defined as a list of address ranges. Each address
range consists of the following items:
アドレス範囲An OSPF部門のリストはアドレスの範囲のリストと定義されます。 それぞれのアドレスの範囲は以下の項目から成ります:
[IP address, mask]
Describes the collection of IP addresses contained in the
address range. Networks and hosts are assigned to an area
depending on whether their addresses fall into one of the
area's defining address ranges. Routers are viewed as
belonging to multiple areas, depending on their attached
networks' area membership.
[IPアドレス、マスク]はアドレスの範囲に保管されていたIPアドレスの収集について説明します。 ネットワークとホストは彼らのアドレスが、領域がアドレスの範囲を定義するものになるかどうかによる領域に選任されます。 ルータはそれらの付属ネットワークの領域会員資格によって、複数の領域に属すと見なされます。
Status Set to either Advertise or DoNotAdvertise. Routing
information is condensed at area boundaries. External to the
area, at most a single route is advertised (via a summary-
LSA) for each address range. The route is advertised if and
only if the address range's Status is set to Advertise.
Unadvertised ranges allow the existence of certain networks
to be intentionally hidden from other areas. Status is set to
Advertise by default.
どちらかへの状態Set、広告、または、DoNotAdvertise。 ルート設定情報はエリアの境界で凝縮します。 その領域に外部であり、高々、それぞれのアドレスの範囲にただ一つのルートの広告を出します(概要LSAを通して)。 範囲のStatusはアドレスである場合にだけ用意ができています。そして、ルートの広告を出す、広告。 Unadvertised範囲で、故意にあるネットワークの存在を他の領域から隠します。 状態が設定される、広告、デフォルトで。
Moy Standards Track [Page 187] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[187ページ]RFC2178OSPFバージョン1997年7月2日
As an example, suppose an IP subnetted network is to be its
own OSPF area. The area would be configured as a single
address range, whose IP address is the address of the
subnetted network, and whose mask is the natural class A, B,
or C address mask. A single route would be advertised
external to the area, describing the entire subnetted
network.
例として、IPサブネット化したネットワークによるそれ自身のOSPF領域であることになっていると仮定してください。 領域はマスクがIPアドレスがサブネット化したネットワークのアドレスであり、自然類A、B、またはCアドレスマスクであるただ一つのアドレスの範囲として構成されるでしょう。 全体のサブネット化したネットワークについて説明して、ただ一つのルートのその領域に外部であることの形で広告を出すでしょう。
ExternalRoutingCapability
Whether AS-external-LSAs will be flooded into/throughout the
area. If AS-external-LSAs are excluded from the area, the
area is called a "stub". Internal to stub areas, routing to
external destinations will be based solely on a default
summary route. The backbone cannot be configured as a stub
area. Also, virtual links cannot be configured through stub
areas. For more information, see Section 3.6.
ExternalRoutingCapability Whether ASの外部のLSAsは領域中に/へあふれるでしょう。 ASの外部のLSAsが領域から除かれるなら、領域は「スタッブ」と呼ばれます。 領域を引き抜くために内部であり、外部の目的地へのルーティングは唯一デフォルト概要ルートに基づくでしょう。 スタッブ領域としてバックボーンを構成できません。 また、スタッブ領域を通って仮想のリンクを構成できません。 詳しくは、セクション3.6を見てください。
StubDefaultCost
If the area has been configured as a stub area, and the
router itself is an area border router, then the
StubDefaultCost indicates the cost of the default summary-LSA
that the router should advertise into the area.
StubDefaultCost If、ルータ自体が境界ルータである、領域はスタッブ領域として構成されて、次に、StubDefaultCostはルータが領域に広告を出すべきであるデフォルト概要-LSAの費用を示します。
C.3 Router interface parameters
C.3ルータインタフェース・パラメータ
Some of the configurable router interface parameters (such as IP interface address and subnet mask) actually imply properties of the attached networks, and therefore must be consistent across all the routers attached to that network. The parameters that must be configured for a router interface are:
構成可能なルータインタフェース・パラメータ(IPインターフェース・アドレスやサブネットマスクなどの)のいくつかが、実際に付属ネットワークの特性を含意して、したがって、そのネットワークに付けられたすべてのルータの向こう側に一貫しているに違いありません。 ルータインタフェースに構成しなければならないパラメタは以下の通りです。
IP interface address
The IP protocol address for this interface. This uniquely
identifies the router over the entire internet. An IP address is
not required on point-to-point networks. Such a point-to-point
network is called "unnumbered".
IPインタフェースは、IPプロトコルがこのインタフェースへのアドレスであると扱います。 これは全体のインターネットの上で唯一ルータを特定します。 IPアドレスは二地点間ネットワークで必要ではありません。 そのような二地点間ネットワークは「無数である」と呼ばれます。
IP interface mask
Also referred to as the subnet/network mask, this indicates the
portion of the IP interface address that identifies the attached
network. Masking the IP interface address with the IP interface
mask yields the IP network number of the attached network. On
point-to-point networks and virtual links, the IP interface mask
is not defined. On these networks, the link itself is not
assigned an IP network number, and so the addresses of each side
of the link are assigned independently, if they are assigned at
all.
サブネット/ネットワークマスクと呼ばれたIPインタフェースマスクAlso、これは付属ネットワークを特定するIPインターフェース・アドレスの部分を示します。 IPインタフェースマスクでIPインターフェース・アドレスにマスクをかけると、付属ネットワークのIPネットワーク・ナンバーはもたらされます。 二地点間ネットワークと仮想のリンク、IPでは、インタフェースマスクは定義されません。 これらのネットワークでは、IPネットワーク・ナンバーがリンク自体に割り当てられないので、リンクのそれぞれの側面のアドレスは独自に割り当てられます、それらが少しでも割り当てられるなら。
Moy Standards Track [Page 188] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[188ページ]RFC2178OSPFバージョン1997年7月2日
Area ID
The OSPF area to which the attached network belongs.
領域ID、付属ネットワークが属するOSPF領域。
Interface output cost
The cost of sending a packet on the interface, expressed in the
link state metric. This is advertised as the link cost for this
interface in the router's router-LSA. The interface output cost
must always be greater than 0.
インタフェース出力はリンク状態でメートル法で言い表されたインタフェースにパケットを送る費用かかります。 ルータのルータ-LSAのこのインタフェースへのリンク費用としてこれの広告を出します。 いつもインタフェース製作費は0以上であるに違いありません。
RxmtInterval
The number of seconds between LSA retransmissions, for
adjacencies belonging to this interface. Also used when
retransmitting Database Description and Link State Request
Packets. This should be well over the expected round-trip delay
between any two routers on the attached network. The setting of
this value should be conservative or needless retransmissions
will result. Sample value for a local area network: 5 seconds.
RxmtInterval、LSA retransmissionsの間のこのインタフェースに属す隣接番組の秒数。 また、Database記述とLink州Request Packetsを再送するとき、使用されます。 付属ネットワークのどんな2つのルータの間にはも、予想された往復の遅れのかなり上にこれはあるべきです。 この価値の設定が保守的であるべきですか、または不必要な「再-トランスミッション」は結果として生じるでしょう。 ローカル・エリア・ネットワークのために値を抽出してください: 5秒。
InfTransDelay
The estimated number of seconds it takes to transmit a Link State
Update Packet over this interface. LSAs contained in the update
packet must have their age incremented by this amount before
transmission. This value should take into account the
transmission and propagation delays of the interface. It must be
greater than 0. Sample value for a local area network: 1 second.
概算のInfTransDelayは、Link州Update Packetをこのインタフェースの上に伝えるのにそれがかかる秒に付番します。 アップデートパケットに含まれたLSAsはトランスミッションの前にこの量で彼らの時代を増加させなければなりません。 この値はインタフェースのトランスミッションと伝播遅延を考慮に入れるべきです。 それは0以上であるに違いありません。 ローカル・エリア・ネットワークのために値を抽出してください: 1 2番目に。
Router Priority
An 8-bit unsigned integer. When two routers attached to a network
both attempt to become Designated Router, the one with the
highest Router Priority takes precedence. If there is still a
tie, the router with the highest Router ID takes precedence. A
router whose Router Priority is set to 0 is ineligible to become
Designated Router on the attached network. Router Priority is
only configured for interfaces to broadcast and NBMA networks.
ルータPriority An、8ビットの符号のない整数。 ネットワークに付けられた2つのルータが、Designated Routerになるのをともに試みるとき、最も高いRouter Priorityがあるものは優先します。 繋がりがまだあれば、最も高いRouter IDがあるルータは優先します。 Router Priorityが0に用意ができているルータは付属ネットワークでDesignated Routerになるのにおいて不適格です。 ルータPriorityは放送するインタフェースとNBMAネットワークのために構成されるだけです。
HelloInterval
The length of time, in seconds, between the Hello Packets that
the router sends on the interface. This value is advertised in
the router's Hello Packets. It must be the same for all routers
attached to a common network. The smaller the HelloInterval, the
faster topological changes will be detected; however, more OSPF
routing protocol traffic will ensue. Sample value for a X.25 PDN
network: 30 seconds. Sample value for a local area network: 10
seconds.
ルータがインタフェースで送るHello Packetsの間の秒の時間の長さのHelloInterval。 ルータのHello Packetsにこの値の広告を出します。 一般的なネットワークに付けられたすべてのルータに、それは同じであるに違いありません。 HelloIntervalが小さければ小さいほど、位相的な変化は、より速く検出されるでしょう。 しかしながら、より多くのOSPFルーティング・プロトコルトラフィックが続くでしょう。 X.25 PDNネットワークのために値を抽出してください: 30秒。 ローカル・エリア・ネットワークのために値を抽出してください: 10秒。
Moy Standards Track [Page 189] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[189ページ]RFC2178OSPFバージョン1997年7月2日
RouterDeadInterval
After ceasing to hear a router's Hello Packets, the number of
seconds before its neighbors declare the router down. This is
also advertised in the router's Hello Packets in their
RouterDeadInterval field. This should be some multiple of the
HelloInterval (say 4). This value again must be the same for all
routers attached to a common network.
RouterDeadInterval Afterが、ルータのHello Packetsを聞くのをやめて、隣人がルータを宣言する前に秒数はダウンします。 また、彼らのRouterDeadInterval分野のルータのHello Packetsにこれの広告を出します。 これはHelloIntervalの何らかの倍数であるべきです(4を言ってください)。 一般的なネットワークに付けられたすべてのルータには、この値は再び同じでなければなりません。
AuType
Identifies the authentication procedure to be used on the
attached network. This value must be the same for all routers
attached to the network. See Appendix D for a discussion of the
defined authentication types.
AuType Identifies、付属ネットワークで使用されるべき認証手順。 ネットワークに付けられたすべてのルータに、この値は同じであるに違いありません。 定義された認証の議論のためのAppendix Dがタイプするのを確実にしてください。
Authentication key
This configured data allows the authentication procedure to
verify OSPF protocol packets received over the interface. For
example, if the AuType indicates simple password, the
Authentication key would be a clear 64-bit password.
Authentication keys associated with the other OSPF authentication
types are discussed in Appendix D.
認証の主要なThisは、認証手順がデータでインタフェースの上に受け取られたOSPFプロトコルパケットについて確かめることができるのを構成しました。 例えば、AuTypeが簡単なパスワードを示すなら、Authenticationキーは明確な64ビットのパスワードでしょう。 Appendix Dで他のOSPF認証タイプに関連している認証キーについて議論します。
C.4 Virtual link parameters
C.4の仮想のリンクパラメータ
Virtual links are used to restore/increase connectivity of the backbone. Virtual links may be configured between any pair of area border routers having interfaces to a common (non-backbone) area. The virtual link appears as an unnumbered point-to-point link in the graph for the backbone. The virtual link must be configured in both of the area border routers.
仮想のリンクは、バックボーンの接続性を回復するか、または増強するのに使用されます。 仮想のリンクは、一般的な(非バックボーンの)領域にインタフェースを持ちながら、どんな組の境界ルータの間でも構成されるかもしれません。 仮想のリンクは無数のポイントツーポイント接続としてバックボーンのためのグラフに現れます。 境界ルータの両方で仮想のリンクを構成しなければなりません。
A virtual link appears in router-LSAs (for the backbone) as if it were a separate router interface to the backbone. As such, it has all of the parameters associated with a router interface (see Section C.3). Although a virtual link acts like an unnumbered point-to-point link, it does have an associated IP interface address. This address is used as the IP source in OSPF protocol packets it sends along the virtual link, and is set dynamically during the routing table build process. Interface output cost is also set dynamically on virtual links to be the cost of the intra-area path between the two routers. The parameter RxmtInterval must be configured, and should be well over the expected round-trip delay between the two routers. This may be hard to estimate for a virtual link; it is better to err on the side of making it too large. Router Priority is not used on virtual links.
仮想のリンクはまるでそれがバックボーンへの別々のルータインタフェースであるかのようにルータ-LSAs(バックボーンのための)に現れます。 そういうものとして、それには、ルータインタフェースに関連しているパラメタのすべてがあります(セクションC.3を見てください)。 仮想のリンクは無数のポイントツーポイント接続のように作動しますが、それには、関連IPインターフェース・アドレスがあります。 このアドレスは、それが仮想のリンクに沿って送るOSPFプロトコルパケットのIPソースとして使用されて、セットが経路指定テーブルの間、ダイナミックにプロセスを建てるということです。 また、仮想のリンクは、2つのルータの間のイントラ領域経路の費用になるようにダイナミックにインタフェース製作費にけしかけられます。 パラメタRxmtIntervalは構成しなければならなくて、2つのルータの間には、予想された往復の遅れのかなり上にあるはずです。 これは仮想のリンクに見積もっているのは困難であるかもしれません。 それを大きくし過ぎることの側で間違えるほうがよいです。 ルータPriorityは仮想のリンクの上に使用されません。
Moy Standards Track [Page 190] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[190ページ]RFC2178OSPFバージョン1997年7月2日
A virtual link is defined by the following two configurable parameters: the Router ID of the virtual link's other endpoint, and the (non-backbone) area through which the virtual link runs (referred to as the virtual link's Transit area). Virtual links cannot be configured through stub areas.
仮想のリンクは以下の2つの構成可能なパラメタによって定義されます: 仮想のリンクの他の終点のRouter ID、および仮想のリンクが動く(非バックボーンの)領域(仮想のリンクのTransit領域と呼ばれます)。 スタッブ領域を通って仮想のリンクを構成できません。
C.5 NBMA network parameters
C.5 NBMA回路パラメータ
OSPF treats an NBMA network much like it treats a broadcast network. Since there may be many routers attached to the network, a Designated Router is selected for the network. This Designated Router then originates a network-LSA, which lists all routers attached to the NBMA network.
放送網を扱うようにOSPFはNBMAネットワークを扱います。 ネットワークに付けられた多くのルータがあるかもしれないので、Designated Routerはネットワークのために選択されます。 そして、このDesignated Routerはネットワーク-LSAを溯源します。(LSAはNBMAネットワークに付けられたすべてのルータを記載します)。
However, due to the lack of broadcast capabilities, it may be necessary to use configuration parameters in the Designated Router selection. These parameters will only need to be configured in those routers that are themselves eligible to become Designated Router (i.e., those router's whose Router Priority for the network is non- zero), and then only if no automatic procedure for discovering neighbors exists:
しかしながら、放送能力の不足のために、Designated Router選択に設定パラメータを使用するのが必要であるかもしれません。 これらのパラメタは、それらのDesignated Router(すなわち、ネットワークのためのRouter Priorityが非ゼロであるルータのそれらのもの)になるのが自分たちで適任のルータで構成されるのが必要であり、隣人を発見するためのどんな自動手順も存在しない場合にだけ、そして必要があるでしょう:
List of all other attached routers
The list of all other routers attached to the NBMA network. Each
router is listed by its IP interface address on the network.
Also, for each router listed, that router's eligibility to become
Designated Router must be defined. When an interface to a NBMA
network comes up, the router sends Hello Packets only to those
neighbors eligible to become Designated Router, until the
identity of the Designated Router is discovered.
他のリストは他のすべてのルータのリストがNBMAネットワークに付けたルータを付けました。 各ルータはIPインターフェース・アドレスによってネットワークに記載されます。 Designated Routerになる各ルータが記載したのでそのルータのも適任を定義しなければなりません。 NBMAネットワークへのインタフェースが来るとき、ルータはDesignated Routerになるのが適任のそれらの隣人だけにHello Packetsを送ります、Designated Routerのアイデンティティが発見されるまで。
PollInterval
If a neighboring router has become inactive (Hello Packets have
not been seen for RouterDeadInterval seconds), it may still be
necessary to send Hello Packets to the dead neighbor. These
Hello Packets will be sent at the reduced rate PollInterval,
which should be much larger than HelloInterval. Sample value for
a PDN X.25 network: 2 minutes.
PollInterval Ifのa隣接しているルータが不活発になった、(こんにちは、PacketsがRouterDeadInterval秒の間、見られていない、)、死んでいる隣人にHello Packetsを送るのがまだ必要であるかもしれません。 割引料金PollIntervalでこれらのHello Packetsを送るでしょう。(PollIntervalはHelloIntervalよりはるかに大きいはずです)。 PDN X.25ネットワークのために値を抽出してください: 2 書き留めます。
C.6 Point-to-MultiPoint network parameters
C.6ポイントからMultiPointへの回路パラメータ
On Point-to-MultiPoint networks, it may be necessary to configure the set of neighbors that are directly reachable over the Point-to- MultiPoint network. Each neighbor is identified by its IP address on the Point-to-MultiPoint network. Designated Routers are not elected on Point-to-MultiPoint networks, so the Designated Router eligibility of configured neighbors is undefined.
PointからMultiPointへのネットワークでは、PointからMultiPointへのネットワークの上で直接届いている隣人のセットを構成するのが必要であるかもしれません。 各隣人はPointからMultiPointへのネットワークに関するIPアドレスによって特定されます。 指定されたRoutersがPointからMultiPointへのネットワークで選出されないので、構成された隣人のDesignated Router適任は未定義です。
Moy Standards Track [Page 191] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[191ページ]RFC2178OSPFバージョン1997年7月2日
Alternatively, neighbors on Point-to-MultiPoint networks may be dynamically discovered by lower-level protocols such as Inverse ARP ([Ref14]).
あるいはまた、PointからMultiPointへのネットワークの隣人はInverse ARP([Ref14])などの低レベルプロトコルによってダイナミックに発見されるかもしれません。
C.7 Host route parameters
C.7ホストルートパラメタ
Host routes are advertised in router-LSAs as stub networks with mask 0xffffffff. They indicate either router interfaces to point-to-point networks, looped router interfaces, or IP hosts that are directly connected to the router (e.g., via a SLIP line). For each host directly connected to the router, the following items must be configured:
スタッブネットワークとしてルータ-LSAsにマスク0xffffffffでホストルートの広告を出します。 彼らは二地点間ネットワークへのルータインタフェース、輪にされたルータインタフェースか直接ルータ(例えば、SLIP系列を通した)に接続されるIPホストのどちらかを示します。 直接ルータに接続された各ホストに関しては、以下の項目を構成しなければなりません:
Host IP address
The IP address of the host.
ホストIPはホストのIPアドレスを扱います。
Cost of link to host
The cost of sending a packet to the host, in terms of the link
state metric. However, since the host probably has only a single
connection to the internet, the actual configured cost in many
cases is unimportant (i.e., will have no effect on routing).
メートル法でリンク状態に関してパケットをホストに送る費用を接待するリンクの費用。 しかしながら、ホストがたぶんインターネットに単独結合しか持っていないので、多くの場合、実際の構成された費用は重要ではありません(すなわち、ルーティングでは、効き目がないでしょう)。
Area ID
The OSPF area to which the host belongs.
領域ID、ホストが属するOSPF領域。
Moy Standards Track [Page 192] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[192ページ]RFC2178OSPFバージョン1997年7月2日
D. Authentication
D。 認証
All OSPF protocol exchanges are authenticated. The OSPF packet header (see Section A.3.1) includes an authentication type field, and 64-bits of data for use by the appropriate authentication scheme (determined by the type field).
すべてのOSPFプロトコル交換が認証されます。 適切な認証体系(タイプ分野のそばで断固とした)でOSPFパケットのヘッダー(セクションA.3.1を見る)は使用のための認証タイプ分野、および64ビットのデータを入れます。
The authentication type is configurable on a per-interface (or equivalently, on a per-network/subnet) basis. Additional authentication data is also configurable on a per-interface basis.
または、認証タイプがインタフェースで構成可能である、(同等である、ネットワーク/サブネット) ベースで。 また、追加認証データも1インタフェースあたり1個のベースで構成可能です。
Authentication types 0, 1 and 2 are defined by this specification. All other authentication types are reserved for definition by the IANA (iana@ISI.EDU). The current list of authentication types is described below in Table 20.
認証タイプ0、1、および2はこの仕様で定義されます。 他のすべての認証タイプが定義のためにIANA( iana@ISI.EDU )によって予約されます。 認証タイプの現在のリストはTable20で以下で説明されます。
AuType Description
___________________________________________
0 Null authentication
1 Simple password
2 Cryptographic authentication
All others Reserved for assignment by the
IANA (iana@ISI.EDU)
AuType記述___________________________________________ 0 IANAによる課題のために1つのヌル認証Simpleパスワード2Cryptographic認証All他のものReserved( iana@ISI.EDU )
Table 20: OSPF authentication types.
テーブル20: OSPF認証タイプ。
D.1 Null authentication
D.1のヌル認証
Use of this authentication type means that routing exchanges over the network/subnet are not authenticated. The 64-bit authentication field in the OSPF header can contain anything; it is not examined on packet reception. When employing Null authentication, the entire contents of each OSPF packet (other than the 64-bit authentication field) are checksummed in order to detect data corruption.
この認証タイプの使用は、ネットワーク/サブネットの上のルーティング交換が認証されないことを意味します。 OSPFヘッダーの64ビットの認証分野は何でも含むことができます。 それはパケットレセプションで調べられません。 Null認証を使うとき、それぞれのOSPFパケット(64ビットの認証分野を除いた)の全体の内容は、データの汚染を検出するためにchecksummedされます。
D.2 Simple password authentication
D.2の簡単なパスワード認証
Using this authentication type, a 64-bit field is configured on a per-network basis. All packets sent on a particular network must have this configured value in their OSPF header 64-bit authentication field. This essentially serves as a "clear" 64- bit password. In addition, the entire contents of each OSPF packet (other than the 64-bit authentication field) are checksummed in order to detect data corruption.
この認証タイプを使用して、64ビットの分野は1ネットワークあたり1個のベースで構成されます。 すべてのパケットが、特定のネットワークがそれらのOSPFのヘッダーの64ビットの認証分野にこの構成された値を持たなければならないのを転送しました。 「明確な」64がパスワードに噛み付いたので、これは本質的には役立ちます。 さらに、それぞれのOSPFパケット(64ビットの認証分野を除いた)の全体の内容は、データの汚染を検出するためにchecksummedされます。
Moy Standards Track [Page 193] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[193ページ]RFC2178OSPFバージョン1997年7月2日
Simple password authentication guards against routers inadvertently joining the routing domain; each router must first be configured with its attached networks' passwords before it can participate in routing. However, simple password authentication is vulnerable to passive attacks currently widespread in the Internet (see [Ref16]). Anyone with physical access to the network can learn the password and compromise the security of the OSPF routing domain.
簡単なパスワード認証はうっかり経路ドメインを接合するルータに用心します。 ルーティングに参加できる前に最初に、付属ネットワークのパスワードで各ルータを構成しなければなりません。 しかしながら、簡単なパスワード認証は現在インターネットで広範囲の受け身の攻撃に被害を受け易いです([Ref16]を見てください)。 ネットワークへの物理的なアクセスのだれでも、パスワードを学んで、OSPF経路ドメインのセキュリティに感染することができます。
D.3 Cryptographic authentication
D.3の暗号の認証
Using this authentication type, a shared secret key is configured in all routers attached to a common network/subnet. For each OSPF protocol packet, the key is used to generate/verify a "message digest" that is appended to the end of the OSPF packet. The message digest is a one-way function of the OSPF protocol packet and the secret key. Since the secret key is never sent over the network in the clear, protection is provided against passive attacks.
この認証タイプを使用して、共有された秘密鍵は一般的なネットワーク/サブネットに付けられたすべてのルータで構成されます。 それぞれのOSPFプロトコルパケットに関しては、キーは、OSPFパケットの端まで追加される「メッセージダイジェスト」について生成するか、または確かめるのに使用されます。 メッセージダイジェストはOSPFプロトコルパケットと秘密鍵に関する一方向関数です。 明確のネットワークの上に秘密鍵を決して送らないので、受け身の攻撃に対して保護を提供します。
The algorithms used to generate and verify the message digest are specified implicitly by the secret key. This specification completely defines the use of OSPF Cryptographic authentication when the MD5 algorithm is used.
メッセージダイジェストを生成して、確かめるのに使用されるアルゴリズムは秘密鍵によってそれとなく指定されます。 MD5アルゴリズムが使用されているとき、この仕様はOSPF Cryptographic認証の使用を完全に定義します。
In addition, a non-decreasing sequence number is included in each OSPF protocol packet to protect against replay attacks. This provides long term protection; however, it is still possible to replay an OSPF packet until the sequence number changes. To implement this feature, each neighbor data structure
さらに、非減少している一連番号は、反射攻撃から守るためにそれぞれのOSPFプロトコルパケットに含まれています。 これは長期保護を提供します。 しかしながら、一連番号が変化するまで、OSPFパケットを再演するのはまだ可能です。 この特徴、それぞれの隣人データ構造を実装するために
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Key ID | Auth Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 主要なID| Auth Dataレン| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 暗号の一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Usage of the Authentication field
in the OSPF packet header when Cryptographic
Authentication is employed
図18: Cryptographic Authenticationであるときに、OSPFパケットのヘッダーのAuthentication分野の用法は採用しています。
contains a new field called the "cryptographic sequence number". This field is initialized to zero, and is also set to zero whenever the neighbor's state transitions to "Down". Whenever an OSPF packet is accepted as authentic, the cryptographic sequence number is set to the received packet's sequence number.
「暗号の一連番号」と呼ばれる新しい分野を含んでいます。 この分野は、ゼロに初期化されて、隣人の状態が“Down"に移行するときはいつも、また、ゼロに設定されます。 OSPFパケットが正統であるとして認められるときはいつも、暗号の一連番号は容認されたパケットの一連番号に設定されます。
Moy Standards Track [Page 194] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[194ページ]RFC2178OSPFバージョン1997年7月2日
This specification does not provide a rollover procedure for the cryptographic sequence number. When the cryptographic sequence number that the router is sending hits the maximum value, the router should reset the cryptographic sequence number that it is sending back to 0. After this is done, the router's neighbors will reject the router's OSPF packets for a period of RouterDeadInterval, and then the router will be forced to reestablish all adjacencies over the interface. However, it is expected that many implementations will use "seconds since reboot" (or "seconds since 1960", etc.) as the cryptographic sequence number. Such a choice will essentially prevent rollover, since the cryptographic sequence number field is 32 bits in length.
この仕様はロールオーバー手順を暗号の一連番号に提供しません。 ルータが送る暗号の一連番号が最大値を打つと、ルータはそれが0に返送する暗号の一連番号をリセットするべきです。 これが完了していた後に、ルータの隣人はしばらくRouterDeadIntervalについてルータのOSPFパケットを拒絶するでしょう、そして、次に、ルータはインタフェースの上ですべての隣接番組をやむを得ず回復させるでしょう。 しかしながら、多くの実装が暗号の一連番号として「リブート以来の秒」(または、「1960年以来の秒」など)を使用すると予想されます。 そのような選択は、長さが暗号の一連番号分野が32ビットであるので、本質的にはロールオーバーを防ぐでしょう。
The OSPF Cryptographic authentication option does not provide confidentiality.
OSPF Cryptographic認証オプションは秘密性を提供しません。
When cryptographic authentication is used, the 64-bit Authentication field in the standard OSPF packet header is redefined as shown in Figure 18. The new field definitions are as follows:
暗号の認証が使用されているとき、標準のOSPFパケットのヘッダーの64ビットのAuthentication分野は図18に示されるように再定義されます。 新しいフィールド定義は以下の通りです:
Key ID
This field identifies the algorithm and secret key used to create
the message digest appended to the OSPF packet. Key Identifiers
are unique per-interface (or equivalently, per- subnet).
Thisがさばく主要なIDはOSPFパケットに追加されたメッセージダイジェストを作成するのに使用されるアルゴリズムと秘密鍵を特定します。 または、主要なIdentifiersがユニークなインタフェースである、(同等である、-、サブネット)
Auth Data Len
The length in bytes of the message digest appended to the OSPF
packet.
Auth Dataレン、OSPFパケットに追加されたメッセージダイジェストのバイトで表現される長さ。
Cryptographic sequence number
An unsigned 32-bit non-decreasing sequence number. Used to guard
against replay attacks.
暗号の一連番号An未署名の32ビットの非減少している一連番号。 反射攻撃に用心するのにおいて、使用されています。
The message digest appended to the OSPF packet is not actually considered part of the OSPF protocol packet: the message digest is not included in the OSPF header's packet length, although it is included in the packet's IP header length field.
OSPFパケットに追加されたメッセージダイジェストはOSPFプロトコルパケットの一部であると実際に考えられません: メッセージダイジェストはOSPFヘッダーのパケット長に含まれていません、それがパケットのIPヘッダ長分野に含まれていますが。
Each key is identified by the combination of interface and Key ID. An interface may have multiple keys active at any one time. This enables smooth transition from one key to another. Each key has four time constants associated with it. These time constants can be expressed in terms of a time-of-day clock, or in terms of a router's local clock (e.g., number of seconds since last reboot):
各キーはインタフェースとKey IDの組み合わせで特定されます。 インタフェースで、複数のキーがいかなる時も、アクティブになるかもしれません。 これは1個のキーからの別のものへのスムーズな移行を可能にします。 各キーには、それに関連している4つの時定数があります。 時刻時計、またはルータの地方の時計に関してこれらの時定数を表すことができます(例えば秒数は最後に以来、リブートされます):
KeyStartAccept
The time that the router will start accepting packets that
have been created with the given key.
ルータが与えられたキーで作成されたパケットを受け入れ始める時間のKeyStartAccept。
Moy Standards Track [Page 195] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[195ページ]RFC2178OSPFバージョン1997年7月2日
KeyStartGenerate
The time that the router will start using the key for packet
generation.
ルータがパケット世代にキーを使用し始める時間のKeyStartGenerate。
KeyStopGenerate
The time that the router will stop using the key for packet
generation.
ルータが、パケット世代にキーを使用するのを止める時間のKeyStopGenerate。
KeyStopAccept
The time that the router will stop accepting packets that
have been created with the given key.
ルータが、与えられたキーで作成されたパケットを受け入れるのを止める時間のKeyStopAccept。
In order to achieve smooth key transition, KeyStartAccept should be less than KeyStartGenerate and KeyStopGenerate should be less than KeyStopAccept. If KeyStopGenerate and KeyStopAccept are left unspecified, the key's lifetime is infinite. When a new key replaces an old, the KeyStartGenerate time for the new key must be less than or equal to the KeyStopGenerate time of the old key.
KeyStartAcceptがKeyStartGenerate滑らかな主要な変遷を達成するための以下であるべきであり、KeyStopGenerateはKeyStopAccept以下であるべきです。 KeyStopGenerateとKeyStopAcceptが不特定のままにされるなら、キーの寿命は無限です。 新しいキーが老人を取り替えるとき、新しいキーのためのKeyStartGenerate時間は古いキーのKeyStopGenerateより時間以下であるに違いありません。
Key storage should persist across a system restart, warm or cold, to avoid operational issues. In the event that the last key associated with an interface expires, it is unacceptable to revert to an unauthenticated condition, and not advisable to disrupt routing. Therefore, the router should send a "last authentication key expiration" notification to the network manager and treat the key as having an infinite lifetime until the lifetime is extended, the key is deleted by network management, or a new key is configured.
主要なストレージは、操作上の問題を避けるために暖かいか冷たいシステムリスタートの向こう側に持続するべきです。 インタフェースに関連している最後のキーが期限が切れる場合、ルーティングを混乱させるのは、非認証された状態に振り向けるのにおいて容認できなくて、賢明ではありません。 したがって、ルータが、「最後の認証の主要な満了」通知をネットワークマネージャに送って、寿命が拡張されるまで無限の生涯を持っているとしてキーを扱うべきですか、キーがネットワークマネージメントで削除されるか、または新しいキーは構成されます。
D.4 Message generation
D.4メッセージ世代
After building the contents of an OSPF packet, the authentication procedure indicated by the sending interface's Autype value is called before the packet is sent. The authentication procedure modifies the OSPF packet as follows.
OSPFパケットのコンテンツを築き上げた後に、パケットを送る前に送付インタフェースのAutype値によって示された認証手順を呼びます。 認証手順は以下のOSPFパケットを変更します。
D.4.1 Generating Null authentication
Nullが認証であると生成するD.4.1
When using Null authentication, the packet is modified as follows:
Null認証を使用するとき、パケットは以下の通り変更されます:
(1) The Autype field in the standard OSPF header is set to
0.
(1) 標準のOSPFヘッダーのAutype分野は0に設定されます。
Moy Standards Track [Page 196] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[196ページ]RFC2178OSPFバージョン1997年7月2日
(2) The checksum field in the standard OSPF header is set to
the standard IP checksum of the entire contents of the packet,
starting with the OSPF packet header but excluding the 64-bit
authentication field. This checksum is calculated as the 16-bit
one's complement of the one's complement sum of all the 16-bit
words in the packet, excepting the authentication field. If the
packet's length is not an integral number of 16-bit words, the
packet is padded with a byte of zero before checksumming.
(2) 標準のOSPFヘッダーのチェックサム分野はパケットの全体のコンテンツの標準のIPチェックサムに設定されます、OSPFパケットのヘッダーから始めますが、64ビットの認証分野を除いて。 このチェックサムはパケットでのすべての16ビットの単語の1の補数合計の16ビットの1の補数として計算されます、認証分野を除いて。 パケットの長さが整数の16ビットの単語でないなら、パケットはchecksummingする前に、1バイトのゼロで水増しされます。
D.4.2 Generating Simple password authentication
Simpleがパスワード認証であると生成するD.4.2
When using Simple password authentication, the packet is modified as follows:
Simpleパスワード認証を使用するとき、パケットは以下の通り変更されます:
(1) The Autype field in the standard OSPF header is set to 1.
(1) 標準のOSPFヘッダーのAutype分野は1に設定されます。
(2) The checksum field in the standard OSPF header is set to the
standard IP checksum of the entire contents of the packet,
starting with the OSPF packet header but excluding the 64-bit
authentication field. This checksum is calculated as the 16-bit
one's complement of the one's complement sum of all the 16-bit
words in the packet, excepting the authentication field. If the
packet's length is not an integral number of 16-bit words, the
packet is padded with a byte of zero before checksumming.
(2) 標準のOSPFヘッダーのチェックサム分野はパケットの全体のコンテンツの標準のIPチェックサムに設定されます、OSPFパケットのヘッダーから始めますが、64ビットの認証分野を除いて。 このチェックサムはパケットでのすべての16ビットの単語の1の補数合計の16ビットの1の補数として計算されます、認証分野を除いて。 パケットの長さが整数の16ビットの単語でないなら、パケットはchecksummingする前に、1バイトのゼロで水増しされます。
(3) The 64-bit authentication field in the OSPF packet header
is set to the 64-bit password (i.e., authentication key) that has
been configured for the interface.
(3) OSPFパケットのヘッダーの64ビットの認証分野はインタフェースに構成された64ビットのパスワード(すなわち、認証キー)に設定されます。
D.4.3 Generating Cryptographic authentication
Cryptographicが認証であると生成するD.4.3
When using Cryptographic authentication, there may be multiple keys configured for the interface. In this case, among the keys that are valid for message generation (i.e, that have KeyStartGenerate <= current time < KeyStopGenerate) choose the one with the most recent KeyStartGenerate time. Using this key, modify the packet as follows:
Cryptographic認証を使用するとき、インタフェースに構成された複数のキーがあるかもしれません。 この場合、メッセージ世代(i. e、それはKeyStartGenerate<が現在の時間<KeyStopGenerateとの等しさにする)のために有効なキーの中では、最新のKeyStartGenerate時間があるものを選んでください。 このキーを使用して、以下のパケットを変更してください:
(1) The Autype field in the standard OSPF header is set to
2.
(1) 標準のOSPFヘッダーのAutype分野は2に設定されます。
(2) The checksum field in the standard OSPF header is not
calculated, but is instead set to 0.
(2) 標準のOSPFヘッダーのチェックサム分野は、計算されませんが、代わりに0に設定されます。
(3) The Key ID (see Figure 18) is set to the chosen key's
Key ID.
(3) Key ID(図18を見る)は選ばれたキーのKey IDに設定されます。
Moy Standards Track [Page 197] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[197ページ]RFC2178OSPFバージョン1997年7月2日
(4) The Auth Data Len field is set to the length in bytes of
the message digest that will be appended to the OSPF packet. When
using MD5 as the authentication algorithm, Auth Data Len will be
16.
(4) Auth Dataレン分野はOSPFパケットに追加されるメッセージダイジェストのバイトで表現される長さに設定されます。 認証アルゴリズムとしてMD5を使用するとき、Auth Dataレンは16歳になるでしょう。
(5) The 32-bit Cryptographic sequence number (see Figure 18)
is set to a non-decreasing value (i.e., a value at least as large
as the last value sent out the interface). The precise values to
use in the cryptographic sequence number field are
implementation-specific. For example, it may be based on a
simple counter, or be based on the system's clock.
(5) 32ビットのCryptographic一連番号(図18を見る)は非減少している値(すなわち、最終値がインタフェースを出したのと少なくとも同じくらい大きい値)に設定されます。 暗号の一連番号分野で使用する正確な値は実装特有です。 例えば、それは、簡単なカウンタに基づいているか、またはシステムの時計に基づくかもしれません。
(6) The message digest is then calculated and appended to
the OSPF packet. The authentication algorithm to be used in
calculating the digest is indicated by the key itself. Input to
the authentication algorithm consists of the OSPF packet and the
secret key. When using MD5 as the authentication algorithm, the
message digest calculation proceeds as follows:
(6) OSPFパケットにメッセージダイジェストを次に、計算して、追加します。 ダイジェストについて計算する際に使用されるべき認証アルゴリズムはキー自体によって示されます。 認証アルゴリズムへの入力はOSPFパケットと秘密鍵から成ります。 認証アルゴリズムとしてMD5を使用するとき、メッセージダイジェスト計算は以下の通り続きます:
(a) The 16 byte MD5 key is appended to the OSPF packet.
(a) 16バイトのMD5キーをOSPFパケットに追加します。
(b) Trailing pad and length fields are added, as specified in
[Ref17].
(b) 引きずっているパッドと長さの分野は[Ref17]で指定されるように加えられます。
(c) The MD5 authentication algorithm is run over the
concatenation of the OSPF packet, secret key, pad and
length fields, producing a 16 byte message digest (see
[Ref17]).
(c) 16バイトのメッセージダイジェストを作成して、MD5認証アルゴリズムはOSPFパケット、秘密鍵、パッド、および長さの分野の連結の上の走行([Ref17]を見る)です。
(d) The MD5 digest is written over the OSPF key (i.e.,
appended to the original OSPF packet). The digest is not
counted in the OSPF packet's length field, but is included
in the packet's IP length field. Any trailing pad or
length fields beyond the digest are not counted or
transmitted.
(d) MD5ダイジェストはOSPFキー(すなわち、オリジナルのOSPFパケットに追加する)の上に書かれています。 ダイジェストは、OSPFパケットの長さの分野で数えられませんが、パケットのIP長さの分野に含まれています。 ダイジェストを超えたどんな引きずっているパッドや長さの野原も、数えられもしませんし、送られもしません。
D.5 Message verification
D.5メッセージ検証
When an OSPF packet has been received on an interface, it must be authenticated. The authentication procedure is indicated by the setting of Autype in the standard OSPF packet header, which matches the setting of Autype for the receiving OSPF interface.
インタフェースにOSPFパケットを受け取ったとき、それを認証しなければなりません。 認証手順は標準のOSPFパケットのヘッダーでAutypeの設定によって示されます。(そのパケットのヘッダーは、受信OSPFインタフェースへのAutypeの設定に合っています)。
If an OSPF protocol packet is accepted as authentic, processing of the packet continues as specified in Section 8.2. Packets which fail authentication are discarded.
OSPFプロトコルパケットが正統であるとして認められるなら、パケットの処理はセクション8.2で指定されるように続きます。 認証に失敗するパケットは捨てられます。
Moy Standards Track [Page 198] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[198ページ]RFC2178OSPFバージョン1997年7月2日
D.5.1 Verifying Null authentication
Null認証について確かめるD.5.1
When using Null authentication, the checksum field in the OSPF header must be verified. It must be set to the 16-bit one's complement of the one's complement sum of all the 16-bit words in the packet, excepting the authentication field. (If the packet's length is not an integral number of 16-bit words, the packet is padded with a byte of zero before checksumming.)
Null認証を使用するとき、OSPFヘッダーのチェックサム分野について確かめなければなりません。 パケットでのすべての16ビットの単語の1の補数合計の16ビットの1の補数にそれを設定しなければなりません、認証分野を除いて。 (パケットの長さが整数の16ビットの単語でないなら、パケットはchecksummingする前に、1バイトのゼロで水増しされます。)
D.5.2 Verifying Simple password authentication
Simpleパスワード認証について確かめるD.5.2
When using Simple password authentication, the received OSPF packet is authenticated as follows:
Simpleパスワード認証を使用するとき、容認されたOSPFパケットは以下の通り認証されます:
(1) The checksum field in the OSPF header must be verified.
It must be set to the 16-bit one's complement of the
one's complement sum of all the 16-bit words in the
packet, excepting the authentication field. (If the
packet's length is not an integral number of 16-bit
words, the packet is padded with a byte of zero before
checksumming.)
(1) OSPFヘッダーのチェックサム分野について確かめなければなりません。 パケットでのすべての16ビットの単語の1の補数合計の16ビットの1の補数にそれを設定しなければなりません、認証分野を除いて。 (パケットの長さが整数の16ビットの単語でないなら、パケットはchecksummingする前に、1バイトのゼロで水増しされます。)
(2) The 64-bit authentication field in the OSPF packet
header must be equal to the 64-bit password (i.e.,
authentication key) that has been configured for the
interface.
(2) OSPFパケットのヘッダーの64ビットの認証分野はインタフェースに構成された64ビットのパスワード(すなわち、認証キー)と等しいに違いありません。
D.5.3 Verifying Cryptographic authentication
Cryptographic認証について確かめるD.5.3
When using Cryptographic authentication, the received OSPF packet is authenticated as follows:
Cryptographic認証を使用するとき、容認されたOSPFパケットは以下の通り認証されます:
(1) Locate the receiving interface's configured key having
Key ID equal to that specified in the received OSPF
packet (see Figure 18). If the key is not found, or if
the key is not valid for reception (i.e., current time <
KeyStartAccept or current time >= KeyStopAccept), the
OSPF packet is discarded.
(1) それと等しいKey IDが容認されたOSPFパケットで指定した受信インタフェースの構成された主要な有の場所を見つけてください(図18を見てください)。 キーが見つけられないか、またはレセプションには、キーが有効でないなら(すなわち、現在の時間<KeyStartAcceptか現在の時間>がKeyStopAcceptと等しいです)、OSPFパケットは捨てられます。
(2) If the cryptographic sequence number found in the OSPF
header (see Figure 18) is less than the cryptographic
sequence number recorded in the sending neighbor's data
structure, the OSPF packet is discarded.
(2) OSPFヘッダー(図18を見る)で見つけられた暗号の一連番号が送付隣人のデータ構造に記録された暗号の一連番号より少ないなら、OSPFパケットは捨てられます。
(3) Verify the appended message digest in the following
steps:
(3) 以下のステップにおける追加されたメッセージダイジェストを確かめてください:
(a) The received digest is set aside.
(a) 受け取られていているダイジェストはかたわらに置かれます。
Moy Standards Track [Page 199] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[199ページ]RFC2178OSPFバージョン1997年7月2日
(b) A new digest is calculated, as specified in Step 6
of Section D.4.3.
(b) 新しいダイジェストはセクションD.4.3のStep6で指定されるように計算されます。
(c) The calculated and received digests are compared. If
they do not match, the OSPF packet is discarded. If
they do match, the OSPF protocol packet is accepted
as authentic, and the "cryptographic sequence
number" in the neighbor's data structure is set to
the sequence number found in the packet's OSPF
header.
(c) 計算されて受け取られていているダイジェストは比較されます。 彼らが合っていないなら、OSPFパケットは捨てられます。 彼らが合っているなら、OSPFプロトコルパケットは正統であるとして認められます、そして、隣人のデータ構造における「暗号の一連番号」はパケットのOSPFヘッダーで見つけられた一連番号に設定されます。
Moy Standards Track [Page 200] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[200ページ]RFC2178OSPFバージョン1997年7月2日
E. An algorithm for assigning Link State IDs
E。 州IDをLinkに割り当てるためのアルゴリズム
The Link State ID in AS-external-LSAs and summary-LSAs is usually set to the described network's IP address. However, if necessary one or more of the network's host bits may be set in the Link State ID. This allows the router to originate separate LSAs for networks having the same address, yet different masks. Such networks can occur in the presence of supernetting and subnet 0s (see [Ref10]).
通常、ASの外部のLSAsと概要-LSAsのLink州IDは説明されたネットワークのIPアドレスに設定されます。 しかしながら、必要ならネットワークのホストビットの1つ以上はLink州IDに設定されるかもしれません。 これで、ルータはしかし、同じアドレスを持っているネットワーク、異なったマスクのために別々のLSAsを溯源できます。 そのようなネットワークはスーパーネッティングとサブネット0sがあるとき起こることができます([Ref10]を見てください)。
This appendix gives one possible algorithm for setting the host bits in Link State IDs. The choice of such an algorithm is a local decision. Separate routers are free to use different algorithms, since the only LSAs affected are the ones that the router itself originates. The only requirement on the algorithms used is that the network's IP address should be used as the Link State ID whenever possible; this maximizes interoperability with OSPF implementations predating RFC 1583.
この付録はLink州IDにホストビットをはめ込むための1つの可能なアルゴリズムを与えます。 そのようなアルゴリズムの選択はローカルの決定です。 別々のルータは自由に異なったアルゴリズムを使用できます、影響を受ける唯一のLSAsがルータ自体が溯源するものであるので。 使用されるアルゴリズムに関する唯一の要件は可能であるときはいつも、ネットワークのIPアドレスがLink州IDとして使用されるべきであるということです。 これはOSPF実装がRFC1583より前に起こっている相互運用性を最大にします。
The algorithm below is stated for AS-external-LSAs. This is only for clarity; the exact same algorithm can be used for summary-LSAs. Suppose that the router wishes to originate an AS-external-LSA for a network having address NA and mask NM1. The following steps are then used to determine the LSA's Link State ID:
以下のアルゴリズムはASの外部のLSAsのために述べられています。 これは明快のためだけのものです。 概要-LSAsに全く同じアルゴリズムを使用できます。 ネットワークのためのASの外部のLSA有を溯源するというルータ願望がNAとマスクNM1を扱うと仮定してください。 次に、以下のステップはLSAのLink州IDを決定するのに使用されます:
(1) Determine whether the router is already originating an AS-
external-LSA with Link State ID equal to NA (in such an LSA the
router itself will be listed as the LSA's Advertising Router).
If not, the Link State ID is set equal to NA and the algorithm
terminates. Otherwise,
(1) ルータがNAと等しいLink州IDと共にASの外部のLSAを既に溯源しているかどうか(そのようなLSAでは、ルータ自体はLSAのAdvertising Routerとして記載されるでしょう)決定してください。 まして、Link州IDはNAと等しいセットです、そして、アルゴリズムは終わります。 そうでなければ
(2) Obtain the network mask from the body of the already existing
AS-external-LSA. Call this mask NM2. There are then two cases:
(2) 既に既存のAS外部のLSAのボディーからネットワークマスクを入手してください。 このマスクをNM2と呼んでください。 その時、2つのケースがあります:
o NM1 is longer (i.e., more specific) than NM2. In this case,
set the Link State ID in the new LSA to be the network
[NA,NM1] with all the host bits set (i.e., equal to NA or'ed
together with all the bits that are not set in NM1, which is
network [NA,NM1]'s broadcast address).
o NM1はNM2より長いです(すなわち、より特定の)。 この場合、ビットが設定するすべてのホストと共に新しいLSAのLink州IDにネットワーク[NA、NM1]であるように設定してください(すなわち、NM1に設定されるというわけではないすべてのビットと共にNA or'edと等しくて、どれがネットワーク[NA、NM1]であるかは放送演説です)。
o NM2 is longer than NM1. In this case, change the existing
LSA (having Link State ID of NA) to reference the new
network [NA,NM1] by incrementing the sequence number,
changing the mask in the body to NM1 and inserting the cost
of the new network. Then originate a new LSA for the old
network [NA,NM2], with Link State ID equal to NA or'ed
together with the bits that are not set in NM2 (i.e.,
network [NA,NM2]'s broadcast address).
o NM2はNM1より長いです。 この場合、一連番号を増加することによって、参照への新しさ既存のLSA(NAのLink州IDを持っている)ネットワーク[NA、NM1]を変えてください、ボディーでマスクをNM1に変えて、新しいネットワークの費用を挿入して。 次に、古いネットワーク[NA、NM2]のために新しいLSAを溯源してください、NM2に設定されない(すなわち、ネットワーク[NA、NM2]はアドレスを放送しました)ビットと共にNA or'edと等しいLink州IDと共に。
Moy Standards Track [Page 201] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[201ページ]RFC2178OSPFバージョン1997年7月2日
The above algorithm assumes that all masks are contiguous; this ensures that when two networks have the same address, one mask is more specific than the other. The algorithm also assumes that no network exists having an address equal to another network's broadcast address. Given these two assumptions, the above algorithm always produces unique Link State IDs. The above algorithm can also be reworded as follows: When originating an AS-external-LSA, try to use the network number as the Link State ID. If that produces a conflict, examine the two networks in conflict. One will be a subset of the other. For the less specific network, use the network number as the Link State ID and for the more specific use the network's broadcast address instead (i.e., flip all the "host" bits to 1). If the most specific network was originated first, this will cause you to originate two LSAs at once.
上のアルゴリズムは、すべてのマスクが隣接であると仮定します。 これは1個のマスクが確実に2つのネットワークに同じアドレスがあるとき、もう片方より特定になるようにします。 また、アルゴリズムは、ネットワークが全く別のネットワークの放送演説と等しいアドレスを持ちながら存在しないと仮定します。 これらの2つの仮定を考えて、上のアルゴリズムはいつもユニークなLink州IDを生産します。 また、以下の通り上のアルゴリズムを言い換えることができます: ASの外部のLSAを溯源するときには、Link州IDとしてネットワーク・ナンバーを使用するようにしてください。 それが闘争を起こすなら、闘争で2つのネットワークを調べてください。 1つはもう片方の部分集合になるでしょう。 それほど特定でないネットワークには、Link州IDとしてネットワーク・ナンバーを使用してください。そうすれば、より特定の使用のために、ネットワークは代わりにアドレスを放送しました(すなわち、1にすべての「ホスト」ビット宙返りしてください)。 最も特定のネットワークが最初に溯源されたなら、これで、あなたはすぐに、2LSAsを溯源するでしょう。
As an example of the algorithm, consider its operation when the following sequence of events occurs in a single router (Router A).
イベントの以下の系列がただ一つのルータ(ルータA)で起こったら、アルゴリズムに関する例と、操作を考えてください。
(1) Router A wants to originate an AS-external-LSA for
[10.0.0.0,255.255.255.0]:
(1)ルータAがASの外部のLSAを溯源したがっている、[10.0 .0 .0、255.255、.255、.0]:
(a) A Link State ID of 10.0.0.0 is used.
(a) 10.0のLink州ID、.0 .0は使用されています。
(2) Router A then wants to originate an AS-external-LSA for
[10.0.0.0,255.255.0.0]:
次に、(2)ルータAがASの外部のLSAを溯源したがっている、[10.0 .0 .0、255.255、.0、.0]:
(a) The LSA for [10.0.0,0,255.255.255.0] is reoriginated using a
new Link State ID of 10.0.0.255.
.0は、]10.0の新しいLink州IDを使用することで再起因します。(a) LSA、[10.0、.0、0,255.255、.255、.0 .255。
(b) A Link State ID of 10.0.0.0 is used for
[10.0.0.0,255.255.0.0].
(b) 10.0のLink州ID、.0が使用されている.0、[10.0 .0 .0 255.255 .0 .0]。
(3) Router A then wants to originate an AS-external-LSA for
[10.0.0.0,255.0.0.0]:
次に、(3)ルータAがASの外部のLSAを溯源したがっている、[10.0 .0 .0、255.0、.0、.0]:
(a) The LSA for [10.0.0.0,255.255.0.0] is reoriginated using a
new Link State ID of 10.0.255.255.
.0は、]10.0の新しいLink州IDを使用することで再起因します。(a) LSA、[10.0 .0 .0、255.255、.0、.255 .255。
(b) A Link State ID of 10.0.0.0 is used for
[10.0.0.0,255.0.0.0].
(b) 10.0のLink州ID、.0が使用されている.0、[10.0 .0 .0 255.0 .0 .0]。
(c) The network [10.0.0.0,255.255.255.0] keeps its Link State ID
of 10.0.0.255.
(c) ネットワーク、[10.0の10.0.0.0、255.255.255.0の]おはじきのLink州ID、.0 .255。
Moy Standards Track [Page 202] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[202ページ]RFC2178OSPFバージョン1997年7月2日
F. Multiple interfaces to the same network/subnet
F。 同じネットワーク/サブネットへの複数のインタフェース
There are at least two ways to support multiple physical interfaces to the same IP subnet. Both methods will interoperate with implementations of RFC 1583 (and of course this memo). The two methods are sketched briefly below. An assumption has been made that each interface has been assigned a separate IP address (otherwise, support for multiple interfaces is more of a link-level or ARP issue than an OSPF issue).
同じIPサブネットに複数の物理インターフェースをサポートする少なくとも2つの方法があります。 両方のメソッドはRFC1583(そして、もちろんこのメモ)の実装で共同利用するでしょう。 2つのメソッドが簡潔に以下にスケッチされます。 別々のIPアドレスを各インタフェースに割り当ててあるという(さもなければ、複数のインタフェースのサポートは、OSPF問題よりリンク・レベルかARP問題です)仮定はされました。
Method 1:
Run the entire OSPF functionality over both interfaces, sending and
receiving hellos, flooding, supporting separate interface and
neighbor FSMs for each interface, etc. When doing this all other
routers on the subnet will treat the two interfaces as separate
neighbors, since neighbors are identified (on broadcast and NBMA
networks) by their IP address.
メソッド1: 全体のOSPFの機能性を両方のインタフェースの上に実行してください、hellosを送って、受けて、氾濫、各インタフェースなどのために別々のインタフェースと隣人FSMsをサポートして これをするとき、サブネットに関する他のすべてのルータが別々の隣人として2つのインタフェースを扱うでしょう、隣人がそれらのIPアドレスによって特定されるので(放送とNBMAネットワークで)。
Method 1 has the following disadvantages:
メソッド1には、以下の損失があります:
(1) You increase the total number of neighbors and adjacencies.
(1) あなたは隣人と隣接番組の総数を増強します。
(2) You lose the bidirectionality test on both interfaces, since
bidirectionality is based on Router ID.
(2) あなたは、両方のインタフェース双方向性であるので、双方向性なテストを失います。Router IDに基づいています。
(3) You have to consider both interfaces together during the
Designated Router election, since if you declare both to be
DR simultaneously you can confuse the tie-breaker (which is
Router ID).
(3) あなたはDesignated Router選挙の間、両方のインタフェースを一緒に考えなければなりません、同時に両方がDRであると宣言するならあなたがタイブレーク(Router IDである)を混乱させることができるので。
Method 2:
Run OSPF over only one interface (call it the primary interface),
but include both the primary and secondary interfaces in your
Router-LSA.
メソッド2: 1つのインタフェースだけの上にOSPFを実行しなさい、ただし、(それを主要インターフェースと呼んでください)Router-LSAで両方のプライマリの、そして、セカンダリのインタフェースを含めてください。
Method 2 has the following disadvantages:
メソッド2には、以下の損失があります:
(1) You lose the bidirectionality test on the secondary
interface.
(1) あなたはセカンダリインタフェースの双方向性なテストを失います。
(2) When the primary interface fails, you need to promote the
secondary interface to primary status.
(2) 主要インターフェースが失敗すると、あなたは、セカンダリインタフェースをプライマリ状態に促進する必要があります。
Moy Standards Track [Page 203] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[203ページ]RFC2178OSPFバージョン1997年7月2日
G. Differences from RFC 1583
G。 RFC1583からの違い
This section documents the differences between this memo and RFC 1583. All differences are backward-compatible. Implementations of this memo and of RFC 1583 will interoperate.
このセクションはこのメモとRFC1583の違いを記録します。 すべての違いは互換性があります後方の。 このメモとRFC1583の実装は共同利用するでしょう。
G.1 Enhancements to OSPF authentication
OSPF認証へのG.1増進
An additional OSPF authentication type has been added: the Cryptographic authentication type. This has been defined so that any arbitrary "Keyed Message Digest" algorithm can be used for packet authentication. Operation using the MD5 algorithm is completely specified (see Appendix D).
追加OSPF認証タイプは加えられます: Cryptographic認証タイプ。 これは、パケット認証にどんな任意の「合わせられたメッセージダイジェスト」アルゴリズムも使用できるように定義されました。 MD5アルゴリズムを使用する操作が完全に指定されます(Appendix Dを見てください)。
A number of other changes were also made to OSPF packet authentication, affecting the following Sections:
また、以下のセクションに影響して、他の多くの変更をOSPFパケット認証にしました:
o The authentication type is now specified per-interface,
rather than per-area (Sections 6, 9, C.2 and C.3).
o 認証タイプは領域(セクション6、9、C.2、およびC.3)よりむしろ現在指定されたインタフェースです。
o The OSPF packet header checksum is now considered part of
the authentication procedure, and so has been moved out of the
packet send and receive logic (Sections 8.1 and 8.2) and into the
description of authentication types (Appendix D).
o 現在認証手順の一部であると考えられるので、OSPFパケットのヘッダーチェックサムは、引っ越されて、パケットが論理(セクション8.1と8.2)を送って、受け取って、認証の記述に、(付録D)にタイプされているということです。
o In Appendix D, sections detailing message generation and
message verification have been added.
o Appendix Dでは、メッセージ世代とメッセージ検証について詳述するセクションが加えられます。
o For the OSPF Cryptographic authentication type, a discussion
of key management, including the requirement for simultaneous
support of multiple keys, key lifetimes and smooth key
transition, has been added to Appendix D.
o OSPF Cryptographic認証タイプにおいて、複数のキー、主要な生涯、および滑らかな主要な変遷の同時のサポートのための要件を含むかぎ管理の議論はAppendix Dに加えられます。
G.2 Addition of Point-to-MultiPoint interface
PointからMultiPointへのインタフェースのG.2追加
This memo adds an additional method for running OSPF over non- broadcast networks: the Point-to-Multipoint network. To implement this addition, the language of RFC 1583 has been altered slightly. References to "multi-access" networks have been deleted. The term "non-broadcast networks" is now used to describe networks which can connect many routers, but which do not natively support broadcast/multicast (such as a public Frame relay network). Over non-broadcast networks, there are two options for running OSPF: modelling them as "NBMA networks" or as "Point-to-MultiPoint networks". NBMA networks require full mesh connectivity between routers; when employing NBMA networks in the presence of partial mesh connectivity, multiple NBMA networks must be configured, as described in [Ref15]. In contrast, Point-to-Multipoint networks have been
このメモは実行しているOSPFのために非放送網の上で追加メソッドを加えます: Pointから多点へのネットワーク。 この追加を実装するために、RFC1583の言語はわずかに変更されました。 「マルチアクセス」ネットワークの参照は削除されました。 「非放送網」という期間は現在、多くのルータを接続できますが、サポート放送/マルチキャストのネイティブでないネットワーク(公立のFrameリレーネットワークなどの)について説明するのにおいて使用されています。 非放送網の上に、実行しているOSPFのための2つのオプションがあります: 「NBMAネットワーク」として、または、「ポイントからMultiPointへのネットワーク」としてそれらをモデル化します。 NBMAネットワークはルータの間の完全なメッシュの接続性を必要とします。 部分的なメッシュの接続性があるときNBMAネットワークを使うとき、複数のNBMAネットワークを構成しなければなりません、[Ref15]で説明されるように。 対照的に、Pointから多点へのネットワークがありました。
Moy Standards Track [Page 204] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[204ページ]RFC2178OSPFバージョン1997年7月2日
designed to work simply and naturally when faced with partial mesh connectivity.
簡単に自然に働くために、部分的なメッシュの接続性が直面されていると、設計されます。
The addition of Point-to-MultiPoint networks has impacted the text in many places, which are briefly summarized below:
PointからMultiPointへのネットワークの参加は多くの場所でテキストに影響を与えました:(場所は簡潔に以下へまとめられます)。
o Section 2 describing the OSPF link-state database has been
split into additional subsections, with one of the subsections
(Section 2.1.1) describing the differing map representations of
the two non-broadcast network options. This subsection also
contrasts the NBMA network and Point- to-MultiPoint network
options, and describes the situations when one is preferable to
the other.
o OSPFリンク州のデータベースについて説明するセクション2が追加小区分に分割されました、小区分(セクション2.1.1)の1つが2つの非放送網オプションの異なった地図表現について説明している状態で。 この小区分は、また、NBMAネットワークとMultiPointへのPointネットワークオプションを対照して、1つがもう片方より望ましいときに、状況について説明します。
o In contrast to NBMA networks, Point-to-MultiPoint networks
have the following properties. Adjacencies are established
between all neighboring routers (Sections 4, 7.1, 7.5, 9.5 and
10.4). There is no Designated Router or Backup Designated Router
for a Point-to-MultiPoint network (Sections 7.3 and 7.4). No
network-LSA is originated for Point-to-MultiPoint networks
(Sections 12.4.2 and A.4.3). Router Priority is not configured
for Point-to-MultiPoint interfaces, nor for neighbors on Point-
to-MultiPoint networks (Sections C.3 and C.6).
o NBMAネットワークと対照して、PointからMultiPointへのネットワークには、以下の特性があります。 隣接番組はすべての隣接しているルータ(セクション4、7.1、7.5、9.5、および10.4)の間で確立されます。 PointからMultiPointへのネットワーク(セクション7.3と7.4)のためのどんなDesignated RouterもBackup Designated Routerもありません。 ネットワーク-LSAは全くPointからMultiPointへのネットワーク(セクション12.4の.2とA.4.3)のために溯源されません。 ルータPriorityはPointからMultiPointへのインタフェース、およびMultiPointへのPointネットワーク(セクションのC.3とC.6)の隣人のために構成されません。
o The Interface FSM for a Point-to-MultiPoint interface is
identical to that used for point-to-point interfaces. Two states
are possible: "Down" and "Point-to-Point" (Section 9.3).
o PointからMultiPointへのインタフェースへのInterface FSMは二地点間インタフェースに使用されるそれと同じです。 2つの州が可能です: "Down"と「ポイントツーポイント。」(セクション9.3)
o When originating a router-LSA, and Point-to-MultiPoint
interface is reported as a collection of "point-to-point links"
to all of the interface's adjacent neighbors, together with a
single stub link advertising the interface's IP address with a
cost of 0 (Section 12.4.1.4).
o 「ポイントツーポイント接続」のa収集としてインタフェースの隣接している隣人のすべてに報告されていて、単一のスタッブと共に、ルータ-LSA、およびPointからMultiPointへのインタフェースを溯源するのが、そうであるときには0の費用でインタフェースのIPアドレスの広告を出しながらリンクしてください、(セクション12.4 .1 .4)。
o When flooding out a non-broadcast interface (when either in
NBMA or Point-to-MultiPoint mode) the Link State Update or Link
State Acknowledgment packet must be replicated in order to be
sent to each of the interface's neighbors (see Sections 13.3 and
13.5).
o 非放送インタフェースを水浸しにするとき(NBMAかPointからMultiPointへのモードで)、インタフェースの隣人各人に送るためにLink州UpdateかLink州Acknowledgmentパケットを模写しなければなりません(セクション13.3と13.5を見てください)。
G.3 Support for overlapping area ranges
重複する部分のG.3サポートは及びます。
RFC 1583 requires that all networks falling into a given area range actually belong to a single area. This memo relaxes that restriction. This is useful in the following example. Suppose that [10.0.0.0, 255.0.0.0] is carved up into subnets. Most of these subnets are assigned to a single OSPF area (call it Area X), while a few subnets are assigned to other areas. In order to get this configuration to
RFC1583は、与えられた領域の範囲に落ちるすべてのネットワークが実際にただ一つの領域に属すのを必要とします。 このメモはその規制を緩和します。 これは以下の例で役に立ちます。 それを仮定してください、[10.0 .0 .0 255.0 .0 .0は]サブネットに分割されます。 これらのサブネットの大部分はただ一つのOSPF領域に割り当てられます(それをArea Xと呼んでください)、いくつかのサブネットが他の領域に割り当てられますが。 この構成を得ます。
Moy Standards Track [Page 205] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[205ページ]RFC2178OSPFバージョン1997年7月2日
work with RFC 1583, you must not summarize the subnets of Area X with the single range [10.0.0.0, 255.0.0.0], because then the subnets of 10.0.0.0 belonging to other areas would become unreachable. However, with this memo you can summarize the subnets in Area X, provided that the subnets belonging to other areas are not summarized.
RFC1583との仕事、あなたがただ一つの範囲でArea Xのサブネットをまとめてはいけない、[10.0 .0 .0 255.0 .0 .0、]次に、サブネット、10.0では、他の領域への.0.0属は手が届かなくなるでしょう。 しかしながら、このメモで、あなたはArea Xにサブネットをまとめることができます、他の領域に属すサブネットがまとめられなければ。
Implementation details for this change can be found in Sections 11.1 and 16.2.
セクション11.1と16.2でこの変化のための実装の詳細を見つけることができます。
G.4 A modification to the flooding algorithm
G.4は氾濫アルゴリズムへの変更です。
The OSPF flooding algorithm has been modified as follows. When a Link State Update Packet is received that contains an LSA instance which is actually less recent than the the router's current database copy, the router will now in most cases respond by flooding back its database copy. This is in contrast to the RFC 1583 behavior, which was to simply throw the received LSA away.
OSPF氾濫アルゴリズムは以下の通り変更されました。 Link州Update Packetが受け取られているとき、それは実際にルータの現在のデータベースコピーより最近でないLSAインスタンスを含んでいて、多くの場合、ルータは現在、氾濫後部のそばでデータベースコピーを反応させるでしょう。 これは単に容認されたLSAを捨てることであったRFC1583の振舞いと対照的になっています。
Detailed description of the change can be found in Step 8 of Section 13.
セクション13のStep8で変化の詳述を見つけることができます。
This change improves MaxAge processing. There are times when MaxAge LSAs stay in a router's database for extended intervals: 1) when they are stuck in a retransmission queue on a slow link or 2) when a router is not properly flushing them from its database, due to software bugs. The prolonged existence of these MaxAge LSAs can inhibit the flooding of new instances of the LSA. New instances typically start with LS sequence number equal to InitialSequenceNumber, and are treated as less recent (and hence were discarded according to RFC 1583) by routers still holding MaxAge instances. However, with the above change to flooding, a router holding a MaxAge instance will flood back the MaxAge instance. When this flood reaches the LSA's originator, it will then pick the next highest LS sequence number and reflood, overwriting the MaxAge instance.
この変化はMaxAge処理を改良します。 MaxAge LSAsが延ばされた間隔の間にルータのデータベースに滞在する回があります: 1) それらはいつ再送キューで遅いリンクに張り付けられるか、そして、2) ルータがデータベースからそれらを適切に洗い流していないとき、ソフトウェアへの支払われるべきものは急いで去ります。 これらのMaxAge LSAsの長引いている存在はLSAの新しいインスタンスの氾濫を抑制できます。 新しいインスタンスは、InitialSequenceNumberと等しいLS一連番号から通常始まって、まだ成立しているそれほどルータによる最近(そして、したがって、RFC1583によると、捨てられた)でないMaxAgeインスタンスとして扱われます。 しかしながら、氾濫への上の変化で、MaxAgeインスタンスを保持するルータはMaxAgeインスタンスをあふれ返させるでしょう。 この洪水がLSAの創始者に届くと、次の最も高いLS一連番号と再冠水を選ぶでしょう、MaxAgeインスタンスを上書きして。
G.5 Introduction of the MinLSArrival constant
MinLSArrival定数のG.5導入
OSPF limits the frequency that new instances of any particular LSA can be accepted during flooding. This is extra protection, just in case a neighboring router is violating the mandated limit on LSA (re)originations (namely, one per LSA in any MinLSInterval).
OSPFは氾濫の間、受け入れた状態でどんな特定のLSAの新しいインスタンスもあることができる頻度を制限します。 これは特別な防護措置です、ただ隣接しているルータがLSA(re)創作(すなわち、どんなMinLSIntervalのLSAあたり1つも)における強制された限界に違反しているといけないので。
Moy Standards Track [Page 206] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[206ページ]RFC2178OSPFバージョン1997年7月2日
In RFC 1583, the frequency at which new LSA instances were accepted was also set equal to once every MinLSInterval seconds. However, in some circumstances this led to unwanted link state retransmissions, even when the LSA originator was obeying the MinLSInterval limit on originations. This was due to either 1) choice of clock granularity in some OSPF implementations or 2) differing clock speed in neighboring routers.
RFC1583では、新しいLSAインスタンスが受け入れられた頻度はまた、かつてのあらゆるMinLSIntervalと等しい状態で設定された秒でした。 しかしながら、いくつかの事情では、これは求められていないリンク州の「再-トランスミッション」に通じました、LSA創始者が創作におけるMinLSInterval限界に従ったときさえ。 これは隣接しているルータにおける何らかのOSPF実装か2における時計粒状) 異なったクロックスピードの1)選択のためでした。
To alleviate this problem, the frequency at which new LSA instances are accepted during flooding has now been increased to once every MinLSArrival seconds, whose value is set to 1. This change is reflected in Steps 5a and 5d of Section 13, and in Appendix B.
この問題、新しいLSAインスタンスが受け入れて、今かつてのあらゆるMinLSArrivalに氾濫を増強してあるということである頻度を軽減するために、秒であり、だれの値があるかは1にセットしました。 この変化はセクション13のSteps 5aと5d、およびAppendix Bに反映されます。
G.6 Optionally advertising point-to-point links as subnets
サブネットとして任意にポイントツーポイント接続の広告を出すG.6
When describing a point-to-point interface in its router-LSA, a router may now advertise a stub link to the point-to-point network's subnet. This is specified as an alternative to the RFC 1583 behavior, which is to advertise a stub link to the neighbor's IP address. See Sections 12.4.1 and 12.4.1.1 for details.
現在ルータ-LSAで二地点間インタフェースについて説明するとき、ルータは指すポイントへのスタッブリンクネットワークのサブネットの広告を出すかもしれません。 これは隣人のIPアドレスへのスタッブリンクの広告を出すことである1583年のRFC振舞いに代わる手段として指定されます。 セクション12.4.1と12.4を見てください。.1 .1 詳細のために。
G.7 Advertising same external route from multiple areas
複数の領域から同じ外部経路の広告を出すG.7
This document fixes routing loops which can occur in RFC 1583 when the same external destination is advertised by AS boundary routers in separate areas. There are two manifestations of this problem. The first, discovered by Dennis Ferguson, occurs when an aggregated forwarding address is in use. In this case, the desirability of the forwarding address can change for the worse as a packet crosses an area aggregation boundary on the way to the forwarding address, which in turn can cause the preference of AS-external-LSAs to change, resulting in a routing loop.
このドキュメントは同じ外部の目的地が分離した部分のAS境界ルータによって広告に掲載されるRFC1583年に現れることができるルーティング輪を修理します。 この問題の2つの顕現があります。 集められたフォーワーディング・アドレスが使用中であるときに、デニスファーガソンによって発見された1番目は起こります。 この場合、アドレスがパケットとして悪化させることができる推進の願わしさはASの外部のLSAsの好みが順番に変化できるフォーワーディング・アドレスへの途中と領域集合境界に交差します、ルーティング輪をもたらして。
The second manifestation was discovered by Richard Woundy. It is caused by an incomplete application of OSPF's preference of intra- area routes over inter-area routes: paths to any given ASBR/forwarding address are selected first based on intra-area preference, while the comparison between separate ASBRs/forwarding addresses is driven only by cost, ignoring intra-area preference. His example is replicated in Figure 19. Both router A3 and router B3 are originating an AS-external-LSA for 10.0.0.0/8, with the same type 2 metric. Router A1 selects B1 as its next hop towards 10.0.0.0/8, based on shorter cost to ASBR B3 (via B1->B2->B3). However, the shorter route to B3 is not available to B1, due to B1's preference for the (higher cost) intra-area route to B3 through Area A. This leads B1 to select A1 as its next hop to 10.0.0.0/8, resulting in a routing loop.
2番目の顕現はリチャードWoundyによって発見されました。 それは相互領域ルートの上でOSPFのイントラ領域ルートの好みの不完全な出願で引き起こされます: どんな与えられたASBR/フォーワーディング・アドレスへの経路も最初に、イントラ領域好みに基づいて選択されます、別々のASBRs/フォーワーディング・アドレスでの比較が費用だけによって動かされますが、イントラ領域好みを無視して。 彼の例は図19で模写されます。 ルータA3とルータB3の両方が10.0のためにASの外部のLSAを溯源しています。.0 同じタイプ2がメートル法であることでの.0/8。 B1を通してルータA1が次のホップとして10.0に向かってB1を選定する、.0、ASBR B3への、より短い費用に基づいた.0/8、(-、>B2->、B3) しかしながら、B3へのいっそう早く行けるルートはB1に利用可能ではありません、B3へのA.Thisが、B1が次のホップとしてのA1を選択するように導くAreaを通した(より高い費用)イントラ領域ルートのためのB1の好みのため。10.0 .0 .0/8、ルーティング輪をもたらすこと。
Moy Standards Track [Page 207] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[207ページ]RFC2178OSPFバージョン1997年7月2日
The following two changes have been made to prevent these routing loops:
以下の2つの変更がこれらのルーティング輪を防ぐと行われました:
o When originating a type 3 summary-LSA for a configured area
address range, the cost of the summary-LSA is now set to the
maximum cost of the range's component networks (instead of the
previous algorithm which set the cost to the minimum component
cost). This change affects Sections 3.5 and 12.4.3, Figures 7
and 8, and Tables 6 and 13.
o 現在タイプ3概要-LSAを構成された領域のアドレスの範囲に溯源するとき、概要-LSAの費用は範囲のコンポーネントネットワークの最大の費用(最小のコンポーネント費用に費用を設定した前のアルゴリズムの代わりに)に設定されます。 この変化はセクション3.5と12.4.3、図7と8、およびTables6と13に影響します。
o The preference rules for choosing among multiple AS-
external-LSAs have been changed. Where previously cost was the
only determining factor, now the preference is driven first by
type of path (intra-area or inter-area, through non-backbone area
or through backbone) to the ASBR/forwarding address, using cost
only to break ties. This change affects Sections 16.4 and 16.4.1.
o 複数のASの外部のLSAsの中で選ぶための優先規則を変えました。 現在以前に費用が唯一の決定的要因、好みであったところに、費用を使用しますが、結びつきを壊して、駆動1番目がASBR/フォーワーディング・アドレスへの経路(非バックボーン領域を通る、または、バックボーンを通したイントラ領域か相互領域)のタイプでありますか? この変化はセクション16.4と16.4.1に影響します。
After implementing this change, the example in Figure 19 is modified as follows. Router A1 now chooses A3 as the next
この変化を実装した後に、図19の例は以下の通り変更されます。 ルータA1は現在、次としてA3を選びます。
10.0.0.0/8
----------
|
+----+
| XX |
+----+
RIP / \ RIP
--------------------- --------------------
! !
! !
+----+ +----+ 1 +----+......+----+....
| A3 |------| A1 |---------------| B1 |------| B3 | .
+----+ 6 +----+ +----+ 8 +----+ .
1| . / .
OSPF backbone | . / .
+----+ 2 / .
| B2 |------- Area A.
+----+................
10.0.0.0/8 ---------- | +----+ | XX| +----+ リップ/\リップ--------------------- -------------------- ! ! ! ! +----+ +----+ 1 +----+......+----+.... | A3|------| A1|---------------| B1|------| B3| . +----+ 6 +----+ +----+ 8 +----+ . 1| . /OSPFバックボーン| . / . +----+ 2 / . | B2|------- 領域A.+----+................
Figure 19: Example routing loop when the
same external route is advertised from multiple
areas
図19: 同じ外部経路が複数の領域から広告に掲載されるとき輪を発送する例
hop to 10.0.0.0/8, while B1 chooses B3 as next hop. The reason for both choices is that ASBRs/forwarding addresses are now chosen based first on intra-area preference, and then by cost.
10.0まで跳んでください。.0 B1が次のホップとしてB3を選ぶ間の.0/8。 両方の選択の理由はアドレスが現在選ばれているASBRs/推進がイントラ領域好み、およびそして、費用で1番目を基礎づけたということです。
Moy Standards Track [Page 208] RFC 2178 OSPF Version 2 July 1997
Moy標準化過程[208ページ]RFC2178OSPFバージョン1997年7月2日
Unfortunately, this change is not backward compatible. While the change prevents routing loops when all routers run the new preference rules, it can actually create routing loops when some routers are running the new preference rules and other routers implement RFC 1583. For this reason, a new configuration parameter has been added: RFC1583Compatibility. Only when RFC1583Compatibility is set to "disabled" will the new preference rules take effect. See Appendix C for more details.
残念ながら、この変化は後方にありません。互換性がある。 いくつかのルータが新しい優先規則を実行しているとき、変化が、すべてのルータが新しい優先規則を実行するとき、輪を発送するのを防いでいる間、実際にルーティング輪を作成できます、そして、他のルータはRFCが1583であると実装します。 この理由で、新しい設定パラメータは加えられます: RFC1583Compatibility。 RFC1583Compatibilityが「身体障害者」に用意ができているときだけ、新しい優先規則は実施するでしょう。 その他の詳細に関してAppendix Cを見てください。
G.8 Retransmission of initial Database Description packets
初期のDatabase記述パケットのG.8 Retransmission
一覧
スポンサーリンク
