RFC2328 日本語訳
2328 OSPF Version 2. J. Moy. April 1998. (Format: TXT=447367 bytes) (Obsoletes RFC2178) (Also STD0054) (Status: STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Moy Request for Comments: 2328 Ascend Communications, Inc. STD: 54 April 1998 Obsoletes: 2178 Category: Standards Track
Moyがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 2328はコミュニケーションInc.STDを昇ります: 54 1998年4月は以下を時代遅れにします。 2178年のカテゴリ: 標準化過程
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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
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はLinkState方式プロトコルです。 それは、独身の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 2178 are explained in
Appendix G. All differences are backward-compatible in nature.
このメモとRFC2178の違いはAppendix G.で説明されます。All差は現実に互換性があります後方の。
Moy Standards Track [Page 1] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[1ページ]RFC2328OSPFバージョン1998年4月2日
Implementations of this memo and of RFCs 2178, 1583, and 1247 will
interoperate.
このメモ、RFCs2178、1583、および1247年の実現は共同利用するでしょう。
Please send comments to ospf@gated.cornell.edu.
コメントを ospf@gated.cornell.edu に送ってください。
Table of Contents
目次
1 Introduction ........................................... 6
1.1 Protocol Overview ...................................... 6
1.2 Definitions of commonly used terms ..................... 8
1.3 Brief history of link-state routing technology ........ 11
1.4 Organization of this document ......................... 12
1.5 Acknowledgments ....................................... 12
2 The link-state database: organization and calculations 13
2.1 Representation of routers and networks ................ 13
2.1.1 Representation of non-broadcast networks .............. 15
2.1.2 An example link-state database ........................ 18
2.2 The shortest-path tree ................................ 21
2.3 Use of external routing information ................... 23
2.4 Equal-cost multipath .................................. 26
3 Splitting the AS into Areas ........................... 26
3.1 The backbone of the Autonomous System ................. 27
3.2 Inter-area routing .................................... 27
3.3 Classification of routers ............................. 28
3.4 A sample area configuration ........................... 29
3.5 IP subnetting support ................................. 35
3.6 Supporting stub areas ................................. 37
3.7 Partitions of areas ................................... 38
4 Functional Summary .................................... 40
4.1 Inter-area routing .................................... 41
4.2 AS external routes .................................... 41
4.3 Routing protocol packets .............................. 42
4.4 Basic implementation requirements ..................... 43
4.5 Optional OSPF capabilities ............................ 46
5 Protocol data structures .............................. 47
6 The Area Data Structure ............................... 49
7 Bringing Up Adjacencies ............................... 52
7.1 The Hello Protocol .................................... 52
7.2 The Synchronization of Databases ...................... 53
7.3 The Designated Router ................................. 54
7.4 The Backup Designated Router .......................... 56
7.5 The graph of adjacencies .............................. 56
1つの序論… 6 1.1 概観について議定書の中で述べてください… 6 一般的に使用された期間の1.2の定義… 8 1.3 LinkState方式技術の歴史に事情を知らせてください… 11 1.4 このドキュメントの組織… 12 1.5の承認… 12 2 リンク州のデータベース: ルータとネットワークの組織と計算13 2.1Representation… 13 2.1 .1 非放送網の代理… 15 2.1 .2 例のリンク州のデータベース… 18 2.2 最短パス木… 21 2.3 外部のルーティング情報の使用… 23 2.4等価コストマルチパス… 26 3 分かれる、領域のように… 26 3.1 Autonomous Systemの背骨… 27 3.2 相互領域ルーティング… 27 3.3 ルータの分類… 28 3.4 サンプル領域構成… 29 3.5 IPサブネッティングサポート… 35 3.6 スタッブ領域を支持します… 37 領域の3.7のパーティション… 38 4の機能的な概要… 40 4.1 相互領域ルーティング… 41 4.2個のAS外部経路… 41 4.3 ルーティング・プロトコルパケット… 42 4.4 基本の実現要件… 43 4.5 任意のOSPF能力… 46 5 データ構造について議定書の中で述べてください… 47 6 領域データ構造… 49 7 隣接番組を持って来ます… 52、7.1、こんにちは、議定書を作ってください… 52 7.2 データベースの同期… 53 7.3 代表ルータ… 54 7.4 バックアップはルータを指定しました… 56 7.5 隣接番組のグラフ… 56
Moy Standards Track [Page 2] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[2ページ]RFC2328OSPFバージョン1998年4月2日
8 Protocol Packet Processing ............................ 58
8.1 Sending protocol packets .............................. 58
8.2 Receiving protocol packets ............................ 61
9 The Interface Data Structure .......................... 63
9.1 Interface states ...................................... 67
9.2 Events causing interface state changes ................ 70
9.3 The Interface state machine ........................... 72
9.4 Electing the Designated Router ........................ 75
9.5 Sending Hello packets ................................. 77
9.5.1 Sending Hello packets on NBMA networks ................ 79
10 The Neighbor Data Structure ........................... 80
10.1 Neighbor states ....................................... 83
10.2 Events causing neighbor state changes ................. 87
10.3 The Neighbor state machine ............................ 89
10.4 Whether to become adjacent ............................ 95
10.5 Receiving Hello Packets ............................... 96
10.6 Receiving Database Description Packets ................ 99
10.7 Receiving Link State Request Packets ................. 102
10.8 Sending Database Description Packets ................. 103
10.9 Sending Link State Request Packets ................... 104
10.10 An Example ........................................... 105
11 The Routing Table Structure .......................... 107
11.1 Routing table lookup ................................. 111
11.2 Sample routing table, without areas .................. 111
11.3 Sample routing table, with areas ..................... 112
12 Link State Advertisements (LSAs) ..................... 115
12.1 The LSA Header ....................................... 116
12.1.1 LS age ............................................... 116
12.1.2 Options .............................................. 117
12.1.3 LS type .............................................. 117
12.1.4 Link State ID ........................................ 117
12.1.5 Advertising Router ................................... 119
12.1.6 LS sequence number ................................... 120
12.1.7 LS checksum .......................................... 121
12.2 The link state database .............................. 121
12.3 Representation of TOS ................................ 122
12.4 Originating LSAs ..................................... 123
12.4.1 Router-LSAs .......................................... 126
12.4.1.1 Describing point-to-point interfaces ................. 130
12.4.1.2 Describing broadcast and NBMA interfaces ............. 130
12.4.1.3 Describing virtual links ............................. 131
12.4.1.4 Describing Point-to-MultiPoint interfaces ............ 131
8 パケット処理について議定書の中で述べてください… 58 8.1 プロトコルパケットを送ります… 58 8.2 プロトコルパケットを受けます… 61 9 インタフェースデータ構造… 63 9.1 州を連結してください… 67 インタフェースを引き起こす9.2回の出来事が変化を述べます… 70 9.3 Interfaceはマシンを述べます… 72 9.4 代表ルータに選出します。 75 9.5 パケットをHelloに送ります… 77 9.5 .1 NBMAネットワークでパケットをHelloに送ります… 79 10、隣人データ構造… 80 10.1 隣人州… 隣人を引き起こす83 10.2回の出来事が変化を述べます… 87 10.3 Neighborはマシンを述べます… 89 10.4、隣接するようになるように… こんにちはを受ける95 10.5、パケット… 96 10.6 データベース記述パケットを受けます… 99 10.7 リンク状態を受けて、パケットを要求してください… 102 10.8 データベース記述パケットを送ります… 103 10.9 リンク状態を送って、パケットを要求してください… 104 10.10 例… 105 11 経路指定テーブル構造… 107 11.1 索表を発送します… 111 11.2 領域なしで経路指定テーブルを抽出してください… 111 11.3 領域がある経路指定テーブルを抽出してください… 112 12 州の広告(LSAs)をリンクしてください… 115 12.1 LSAヘッダー… 116 12.1 .1LSが年をとります… 116 12.1 .2のオプション… 117 12.1 .3LSがタイプします… 117 12.1 .4 州のIDをリンクしてください… 117 12.1 .5広告ルータ… 119 12.1.6LS一連番号… 120 12.1 .7 LSチェックサム… 121 12.2 リンク州のデータベース… 121 12.3 TOSの表現… 122 12.4 由来しているLSAs… 123 12.4 .1ルータ-LSAs… 126 12.4 .1 .1 ポイントツーポイントについて説明するのは連結します… 130 12.4 .1 .2 放送とNBMAについて説明するのは連結します… 130 12.4 .1 .3 仮想のリンクについて説明します… 131 12.4 .1 .4 PointからMultiPointについて説明するのは連結します… 131
Moy Standards Track [Page 3] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[3ページ]RFC2328OSPFバージョン1998年4月2日
12.4.1.5 Examples of router-LSAs .............................. 132
12.4.2 Network-LSAs ......................................... 133
12.4.2.1 Examples of network-LSAs ............................. 134
12.4.3 Summary-LSAs ......................................... 135
12.4.3.1 Originating summary-LSAs into stub areas ............. 137
12.4.3.2 Examples of summary-LSAs ............................. 138
12.4.4 AS-external-LSAs ..................................... 139
12.4.4.1 Examples of AS-external-LSAs ......................... 140
13 The Flooding Procedure ............................... 143
13.1 Determining which LSA is newer ....................... 146
13.2 Installing LSAs in the database ...................... 147
13.3 Next step in the flooding procedure .................. 148
13.4 Receiving self-originated LSAs ....................... 151
13.5 Sending Link State Acknowledgment packets ............ 152
13.6 Retransmitting LSAs .................................. 154
13.7 Receiving link state acknowledgments ................. 155
14 Aging The Link State Database ........................ 156
14.1 Premature aging of LSAs .............................. 157
15 Virtual Links ........................................ 158
16 Calculation of the routing table ..................... 160
16.1 Calculating the shortest-path tree for an area ....... 161
16.1.1 The next hop calculation ............................. 167
16.2 Calculating the inter-area routes .................... 178
16.3 Examining transit areas' summary-LSAs ................ 170
16.4 Calculating AS external routes ....................... 173
16.4.1 External path preferences ............................ 175
16.5 Incremental updates -- summary-LSAs .................. 175
16.6 Incremental updates -- AS-external-LSAs .............. 177
16.7 Events generated as a result of routing table changes 177
16.8 Equal-cost multipath ................................. 178
Footnotes ............................................ 179
References ........................................... 183
A OSPF data formats .................................... 185
A.1 Encapsulation of OSPF packets ........................ 185
A.2 The Options field .................................... 187
A.3 OSPF Packet Formats .................................. 189
A.3.1 The OSPF packet header ............................... 190
A.3.2 The Hello packet ..................................... 193
A.3.3 The Database Description packet ...................... 195
A.3.4 The Link State Request packet ........................ 197
A.3.5 The Link State Update packet ......................... 199
A.3.6 The Link State Acknowledgment packet ................. 201
12.4.1.5 ルータ-LSAsに関する例… 132 12.4 .2ネットワーク-LSAs… 133 12.4 .2 ネットワーク-LSAsに関する.1の例… 134 12.4 .3概要-LSAs… 135 12.4 .3 .1 概要-LSAsをスタッブ領域に溯源します… 137 12.4 .3 概要-LSAsに関する.2の例… 138 12.4 .4 外部のLSAsとして… 139 12.4 .4の.1の例、外部のLSAsとして… 140 13 氾濫手順… 143 どのLSAを決定する13.1は、より新しいです… 146 13.2 LSAsをデータベースにインストールします… 147 13.3 次に、氾濫手順で踏んでください… 148 13.4 受信は自己にLSAsを溯源しました… 151 13.5 州AcknowledgmentパケットをLinkに送ります… 152 13.6 LSAsを再送します… 154 13.7 リンクを受けて、承認を述べてください… 155 14 リンクの年をとって、データベースを述べてください… 156 14.1 LSAsの時期尚早な年をとること… 157 15 仮想のリンク… 158 16 経路指定テーブルの計算… 160 16.1 最短パス木について領域に計算します… 161 16.1 .1 次のホップ計算… 167 16.2 相互領域ルートを計算します… 178 16.3 トランジット領域の概要-LSAsを調べます… 170 16.4 計算のAS外部経路… 173 16.4 .1 外部の経路好み… 175 16.5 増加のアップデート(概要-LSAs)… 175 16.6 増加のアップデート--ASの外部のLSAs… 177 16.7回の出来事が経路指定テーブル変化177の結果、16.8Equal-費用多重通路を発生させました… 178 脚注をつけます。 179の参照箇所… 183 OSPFデータ形式… 185 OSPFパケットのA.1カプセル化… A.2Optionsがさばく185… 187 A.3 OSPFパケット・フォーマット… 189 OSPFパケットのヘッダーのA.3.1… 190A.3.2、Helloパケット… 193A.3.3、Database記述パケット… 195A.3.4、Link州Requestパケット… 197A.3.5、Link州Updateパケット… 199A.3.6、Link州Acknowledgmentパケット… 201
Moy Standards Track [Page 4] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[4ページ]RFC2328OSPFバージョン1998年4月2日
A.4 LSA formats .......................................... 203
A.4.1 The LSA header ....................................... 204
A.4.2 Router-LSAs .......................................... 206
A.4.3 Network-LSAs ......................................... 210
A.4.4 Summary-LSAs ......................................... 212
A.4.5 AS-external-LSAs ..................................... 214
B Architectural Constants .............................. 217
C Configurable Constants ............................... 219
C.1 Global parameters .................................... 219
C.2 Area parameters ...................................... 220
C.3 Router interface parameters .......................... 221
C.4 Virtual link parameters .............................. 224
C.5 NBMA network parameters .............................. 224
C.6 Point-to-MultiPoint network parameters ............... 225
C.7 Host route parameters ................................ 226
D Authentication ....................................... 227
D.1 Null authentication .................................. 227
D.2 Simple password authentication ....................... 228
D.3 Cryptographic authentication ......................... 228
D.4 Message generation ................................... 231
D.4.1 Generating Null authentication ....................... 231
D.4.2 Generating Simple password authentication ............ 232
D.4.3 Generating Cryptographic authentication .............. 232
D.5 Message verification ................................. 234
D.5.1 Verifying Null authentication ........................ 234
D.5.2 Verifying Simple password authentication ............. 234
D.5.3 Verifying Cryptographic authentication ............... 235
E An algorithm for assigning Link State IDs ............ 236
F Multiple interfaces to the same network/subnet ....... 239
G Differences from RFC 2178 ............................ 240
G.1 Flooding modifications ............................... 240
G.2 Changes to external path preferences ................. 241
G.3 Incomplete resolution of virtual next hops ........... 241
G.4 Routing table lookup ................................. 241
Security Considerations .............................. 243
Author's Address ..................................... 243
Full Copyright Statement ............................. 244
A.4 LSA形式… 203 LSAヘッダーのA.4.1… 204 A.4.2ルータ-LSAs… 206 A.4.3ネットワーク-LSAs… 210 A.4.4概要-LSAs… 212A.4.5、外部のLSAsとして… 214 B建築定数… 217 Cの構成可能な定数… 219 C.1のグローバルなパラメタ… 219 C.2領域パラメタ… 220 C.3ルータインタフェース・パラメータ… 221 C.4の仮想のリンクパラメータ… 224 C.5 NBMAはパラメタをネットワークでつなぎます… 224 C.6のポイントからMultiPointはパラメタをネットワークでつなぎます… 225 C.7はルートパラメタをホスティングします… 226 D認証… 227 D.1のヌル認証… 227 D.2の簡単なパスワード認証… 228 D.3の暗号の認証… 228D.4メッセージ世代… Null認証を発生させる231D.4.1… Simpleパスワード認証を発生させる231D.4.2… Cryptographic認証を発生させる232D.4.3… 232 D.5メッセージ検証… Null認証について確かめる234D.5.1… Simpleパスワード認証について確かめる234D.5.2… Cryptographic認証について確かめる234D.5.3… 州IDをLinkに割り当てるための1アルゴリズムあたり235E… 236F倍数は同じネットワーク/サブネットに連結します… 239 RFC2178からのG差… 240 G.1氾濫変更… 240 G.2は外部の経路好みに変化します… 次の仮想のホップの241のG.3の不完全な解決… 241G.4経路指定テーブルルックアップ… 241 セキュリティ問題… 243作者のアドレス… 243 完全な著作権宣言文… 244
Moy Standards Track [Page 5] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[5ページ]RFC2328OSPFバージョン1998年4月2日
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 6] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[6ページ]RFC2328OSPFバージョン1998年4月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を境としてルータの間の追加情報の通過を可能にして。
Moy Standards Track [Page 7] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[7ページ]RFC2328OSPFバージョン1998年4月2日
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]。
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.
IPの範囲を示すネットワークのマスクのAの32ビットの番号が単一のIPネットワーク/サブネット/supernetの住んでいることを扱います。 この仕様は16進数としてネットワークマスクを表示します。
Moy Standards Track [Page 8] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[8ページ]RFC2328OSPFバージョン1998年4月2日
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.
例えば、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のシリアル・ラインは二地点間ネットワークに関する例です。
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へのネットワークと呼ばれます。
Moy Standards Track [Page 9] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[9ページ]RFC2328OSPFバージョン1998年4月2日
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関係はルーティング情報を交換する目的のために選択された隣接しているルータの間で形成されました。 すべての組のどんな隣接しているルータも隣接するようになりません。
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 Eachは放送します、そして、少なくとも2つの付属ルータを持っているNBMAネットワークがDesignated Routerを持っています。 指定
Moy Standards Track [Page 10] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[10ページ]RFC2328OSPFバージョン1998年4月2日
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.
ルータは、ネットワークのために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 packet switches connected by
synchronous serial lines, simplified the design and
implementation of the original protocol.
最初のLinkState方式プロトコルはアルパネットパケット交換網における使用のために開発されました。 このプロトコルは[Ref3]で説明されます。 それは他のすべてのリンク州のプロトコルのための出発点を形成しました。 均質のアルパネット環境(すなわち、同期シリアル・ラインによって接続された単一のベンダーパケット交換機)はオリジナルのプロトコルの設計と実装を簡素化しました。
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桁増強されるのを可能にしたメカニズムを紹介することによって、達成されました。
Moy Standards Track [Page 11] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[11ページ]RFC2328OSPFバージョン1998年4月2日
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.
プロトコルの仕様詳細はデータ構造で提示されます。 説明をより正確にするようにこれをします。 プロトコルの実装は、機能性が説明したサポートに必要ですが、このメモに現れる正確な資料構造を使用する必要はありません。
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
作者はRanアトキンソン、フレッド・ベイカー、ジェフリー・ブルガンに感謝したがっています、ロブColtun、ディーノ・ファリナッチ、ビンス・フラー、Phanindra Jujjavarapu、ミロ・メディン、トムPusateri、Kannan Varadhan、Zhaohui
Moy Standards Track [Page 12] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[12ページ]RFC2328OSPFバージョン1998年4月2日
Zhang and the rest of the OSPF Working Group for the ideas and
support they have given to this project.
チャンとそれらがこれに与えた考えとサポートのための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 13] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[13ページ]RFC2328OSPFバージョン1998年4月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
スタッブネットワーク
**FROM**
+---+ +---+
|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: ネットワーク地図の部品
Moy Standards Track [Page 14] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[14ページ]RFC2328OSPFバージョン1998年4月2日
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 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.
図1aの先端は、ポイントからポイント接続された2つのルータがリンクされるのを示します。 結果として起こるリンク州のデータベースグラフでは、2つのルータ頭頂が1組の縁によって直接接続されて、あるコネが各方向です。 IPアドレスは二地点間ネットワークへのインタフェースに割り当てられる必要はありません。 インターフェース・アドレスが割り当てられるとき、スタッブがもう片方のルータのインターフェース・アドレスとのスタッブ接続をそれぞれのルータ広告にリンクするとき、それらはモデル化されます。 任意に、ポイントへのポイントネットワークにIPサブネットを配属できます。 この場合、両方のルータは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
既述のとおり、OSPFは2つのモードの1つで非放送網をひくことができます: NBMAかポイントツーマルチポイント。 モードの選択が道を測定する、それ、Hello
Moy Standards Track [Page 15] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[15ページ]RFC2328OSPFバージョン1998年4月2日
protocol and flooding work over the non-broadcast network,
and the way that the network is represented in the link-
state database.
プロトコルと氾濫は非放送網、およびネットワークがリンク州のデータベースで代表される方法の上働いています。
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から多点へのモードでそのような非放送網を経営しているのはたぶんより良いです。
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'
図1bはPointからMultiPointへのネットワークのリンク州のデータベース代理を例証します。 図の左側では、PointからMultiPointへのネットワークが描写されています。 ルータのRT4とRT5を除いて、すべてのルータが直接伝達できると思われます。 I6ですが、I3はルータのものを示します。
Moy Standards Track [Page 16] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[16ページ]RFC2328OSPFバージョン1998年4月2日
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).
PointからMultiPointへのネットワークに関するIPインターフェース・アドレス。 リンク州のデータベースのグラフ表示に、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を許容するでしょう。
**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 17] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[17ページ]RFC2328OSPFバージョン1998年4月2日
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接続がいます。BGPの1セットは、ルートがこれらのルータの両方のために表示されたことを学びました。
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かかったことに注意してください。 それらはそれにもかかわらず、重要です。 また、外部的に派生しているルーティングデータがスタッブとしてグラフで現れることに注意してください。
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. 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.
リンク州のデータベースはルータによって生成されたLSAsから継ぎを当てられます。 関連グラフ表示で、それぞれのルータかトランジットネットワークの近所は単一の、そして、別々のLSAで代表されます。 図4はグラフィカルにこれらのLSAsを示しています。 ルータRT12は2つの放送網へのインタフェースとSLIP系列をホストに持っています。 ネットワークN6は3つの付属ルータがある放送網です。 Network N6から付属ルータへのすべてのリンクの費用は0です。 Network N6のためのLSAが実際にネットワークの付属ルータの1つによって生成されることに注意してください: ネットワークのためにDesignated Routerに選出されたルータ。
Moy Standards Track [Page 18] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[18ページ]RFC2328OSPFバージョン1998年4月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
Moy Standards Track [Page 19] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[19ページ]RFC2328OSPFバージョン1998年4月2日
Figure 2: A sample Autonomous System
図2: サンプルAutonomous System
**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と共に示されます。
Moy Standards Track [Page 20] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[20ページ]RFC2328OSPFバージョン1998年4月2日
**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と共に示されます。
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の間のシリアル・ライン)の各端の間あることに注意してください。
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
他のAS'es(N12などの)に属すネットワークへのルートは投げつけられた線として図5の最短パス木の上に現れます。 使用
Moy Standards Track [Page 21] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[21ページ]RFC2328OSPFバージョン1998年4月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 22] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[22ページ]RFC2328OSPFバージョン1998年4月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の経路指定テーブルの一部。
this externally derived routing information is considered in the
next section.
この外部的に派生しているルーティング情報は次のセクションで考えられます。
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
OSPFは2つのタイプの外部の測定基準をサポートします。 タイプ1の外部の測定基準はOSPFインタフェース費用と同じユニットに表されます。
Moy Standards Track [Page 23] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[23ページ]RFC2328OSPFバージョン1998年4月2日
(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.
(すなわち、リンク状態メートル法の。) タイプ2の外部の測定基準は1桁より大きいです。 Type2メートル法であることは、いくらか、ASへの内部の考えられたいずれの費用より大きい経路です。 Typeの2の外部の測定基準の使用は、AS'esの間のルーティングがパケットを発送する主要な費用であると仮定して、外部のコストの変換の必要性を内部のリンク州の測定基準に排除します。
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
Type2の外部の測定基準の処理は、より簡単です。 広告を出す中で外部最も小さいAS境界ルータ、メートル法
Moy Standards Track [Page 24] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[24ページ]RFC2328OSPFバージョン1998年4月2日
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.
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 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境界ルータを通していつも発送されると仮定しました。 これはいつも望ましいというわけではありません。 例えば、図2でRouter RTXと呼ばれるNetwork N6に付けられた追加ルータがあると仮定してください。 RTXがOSPFルーティングに参加しませんが、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エキジットポイントを指定するでしょう。
Moy Standards Track [Page 25] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[25ページ]RFC2328OSPFバージョン1998年4月2日
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
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
Autonomous Systemのルート設定は2つのレベルで行われます、パケットのソースと目的地が同じ領域(イントラ領域ルーティングは使用されている)か異なった領域にあるかどうかに(相互領域ルーティングは使用されています)よって。 イントラ領域ルーティングで、パケットは唯一領域の中で得られた情報で発送されます。 掘らないこと
Moy Standards Track [Page 26] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[26ページ]RFC2328OSPFバージョン1998年4月2日
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.
領域の外から得られた情報は使用できます。 これは悪いルーティング情報の注射からイントラ領域ルーティングを保護します。 私たちはセクション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つの隣接の断片に終えることができます: ソースから境界ルータまでのイントラ領域経路、ソースと目的地の地域の間の背骨経路、およびそして、目的地への別のイントラ領域経路。 アルゴリズムは最も少ない費用を持っているそのような経路のセットを見つけます。
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に押しつけるとして相互領域ルーティングについて描写できます、スポークとしてのハブとしての背骨とそれぞれの非背骨領域で。
Moy Standards Track [Page 27] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[27ページ]RFC2328OSPFバージョン1998年4月2日
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 28] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[28ページ]RFC2328OSPFバージョン1998年4月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.
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.
図7はArea1のための結果として起こるリンク州のデータベースを示しています。 図は、掘りながら、その領域のイントラ領域について完全に説明します。 また、それは2の内部のルータRT1とRT2のためにインターネットの完全な視点を示しています。 それは、その領域への外部のすべての目的地への距離のArea1に広告を出すためには境界ルータ、RT3、およびRT4の仕事です。 これらは図7で投げつけられたスタッブルートで示されます。 また、RT3とRT4はASルータRT5境界とRT7の位置のArea1に広告を出さなければなりません。 最終的に、RT5とRT7からのASの外部のLSAsは全体のAS中と、そして、特にArea1中で水につかっています。 これらのLSAsはArea1のデータベースで含められていて、Networks N12-N15にルートを譲ります。
Routers RT3 and RT4 must also summarize Area 1's topology for
またRT3とRT4がArea1のトポロジーをまとめなければならないルータ
Moy Standards Track [Page 29] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[29ページ]RFC2328OSPFバージョン1998年4月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 .
. | . . | .
. +---------+ . . +--------+ .
........................... . + . . | 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 . . | . . | . . +---------+ . . +--------+ .
Moy Standards Track [Page 30] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[30ページ]RFC2328OSPFバージョン1998年4月2日
. N10 . . N7 .
. . .Area 2 .
.Area 3 . ................................
..........................
. N10N7 . . . .Area2. .Area3。 ..........................
Figure 6: A sample OSPF area configuration
図6: サンプルOSPF領域構成
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.
背骨への分配。 彼らの背骨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 31] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[31ページ]RFC2328OSPFバージョン1998年4月2日
**FROM**
****から
|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 32] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[32ページ]RFC2328OSPFバージョン1998年4月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を調べて、背骨距離を加えるのによる領域の外。
Moy Standards Track [Page 33] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[33ページ]RFC2328OSPFバージョン1998年4月2日
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に示されます。
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
Routers RT3とRT4によってArea1に輸入された情報は、内部のルータ、RT1としてのそのようなものが知的に境界ルータを選ぶのを可能にします。 そしてであるだろうルータRT1がNetwork N10への交通にNetwork N6、RT3への交通へのRT4を使用するだろう。
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によって計算された背骨距離。
Moy Standards Track [Page 34] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[34ページ]RFC2328OSPFバージョン1998年4月2日
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に広告に掲載された目的地。
load share between the two for traffic to Network N8.
2つの間のシェアをNetwork N8への交通にロードしてください。
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のマスクでホストルートの広告を出します。
Moy Standards Track [Page 35] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[35ページ]RFC2328OSPFバージョン1998年4月2日
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 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.
可変大きさで分けられたサブネットにはクラスA、B、およびCネットワークに分割する多くの可能な方法があります。 そうするための正確な手順はこの仕様の範囲を超えています。 しかしながら、この仕様は以下のガイドラインを確立します: IPパケットを進めるとき、いつもパケットの目的地への最も良いマッチであるネットワークにそれを送ります。 ここで、最も良いマッチは最も長いか最も特定のマッチと同義です。 例えば、いつも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]を見てください)。
Moy Standards Track [Page 36] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[36ページ]RFC2328OSPFバージョン1998年4月2日
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 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
OSPFスタッブ領域サポートを利用するために、スタッブ領域でデフォルトルーティングを使用しなければなりません。 これは以下の通り達成されます。 スタッブ領域の境界ルータのより多くのひとりは概要-LSAsを通してスタッブ領域にデフォルトルートの広告を出さなければなりません。 これらの概要デフォルトはスタッブ領域、しかし、これ以上あふれません。 (これらのデフォルトが特定のスタッブ領域だけに関係するこの理由による。) これらの概要デフォルトルートはそうしないどんな目的地にも使用されるでしょう。
Moy Standards Track [Page 37] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[37ページ]RFC2328OSPFバージョン1998年4月2日
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
領域パーティションについて考える別の方法はセクション2で導入されたAutonomous Systemグラフを見ることです。 グラフの縁の.[1]のための色がそれぞれ斜めに進むとき、領域IDを見ることができます。
Moy Standards Track [Page 38] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[38ページ]RFC2328OSPFバージョン1998年4月2日
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.
グラフは、ネットワークに接続するか、またはそれ自体でポイントからポイントへのネットワークです。 どちらの場合ではも、縁はネットワークの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である各色)のいくつかの領域があるでしょう。
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でのルーティングは、同じ色のこれらの領域がただ一つのバックボーン領域によってつなげられる限り、機能し続けるでしょう。
Moy Standards Track [Page 39] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[39ページ]RFC2328OSPFバージョン1998年4月2日
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 40] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[40ページ]RFC2328OSPFバージョン1998年4月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境界ルータの位置は(非スタッブの)境界ルータによってまとめられます。
Moy Standards Track [Page 41] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[41ページ]RFC2328OSPFバージョン1998年4月2日
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 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]).
いつもIP TOS分野セットでルーティング・プロトコルパケットを0に送るべきです。 できれば、ともに、送って、受け取ると、定期的なIPデータ通信量の上の優先をルーティング・プロトコルパケットに与えるべきです。 これを達成することへの援助として、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パケットによって実装されます。
Moy Standards Track [Page 42] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[42ページ]RFC2328OSPFバージョン1998年4月2日
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マルチキャストアドレスです。
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.
インタバルタイマは、ドリフトを避けるために実装されるべきです。 いくつかのルータ実装では、パケット処理はタイマ実行に影響できます。 すべて放送して、複数のルータがただ一つのネットワークに付けられているとき、これはルーティングパケット(避けられるべきである)の同期に通じることができます。 ドリフトを避けるためにタイマを実装することができないなら、少無作為の量は、各発火のときにインタバルタイマから加えられるべきであるか、または引き算されるべきです。
Moy Standards Track [Page 43] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[43ページ]RFC2328OSPFバージョン1998年4月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のためのデフォルトルートを説明できます。
Moy Standards Track [Page 44] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[44ページ]RFC2328OSPFバージョン1998年4月2日
Table 9: OSPF link state advertisements (LSAs).
テーブル9: OSPFは州の広告(LSAs)をリンクします。
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]を見てください。
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
非放送低レベルプロトコルサポートOn放送の非ネットワーク、死んでいるか実在しないルータにパケットを送るのを試みをするとき指示を提供することによって、OSPF Helloプロトコルを支援できます。 例えば、X.25 PDNに関して、死んでいる隣接しているルータはそうです。
Moy Standards Track [Page 45] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[45ページ]RFC2328OSPFバージョン1998年4月2日
indicated by the reception of a X.25 clear with an
appropriate cause and diagnostic, and this information would
be passed to OSPF.
X.25のレセプションによって示されて、適切な原因と病気の特徴でクリアしてください。そうすれば、この情報はOSPFに通過されるでしょう。
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(以下を見る)です。
Other capabilities can be negotiated during the Database
Exchange process. This is accomplished by specifying the
optional capabilities in Database Description packets. A
Database Exchangeの過程の間、他の能力を交渉できます。 これは、Database記述パケットで任意の能力を指定することによって、達成されます。 A
Moy Standards Track [Page 46] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[46ページ]RFC2328OSPFバージョン1998年4月2日
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.
この場合、隣人がいる能力ミスマッチは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まで分間固執するでしょう。
Moy Standards Track [Page 47] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[47ページ]RFC2328OSPFバージョン1998年4月2日
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アルゴリズムの別々のコピーを動かすのを覚えていてください。
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境界ルータであるなら自己に溯源されたことに注意してください。
Moy Standards Track [Page 48] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[48ページ]RFC2328OSPFバージョン1998年4月2日
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を見てください。
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に表現されるのを見てください)。
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ルーティング・アルゴリズムを走らせるのに使用されるすべての情報を含んでいます。 各領域はそれ自身のリンク州のデータベースを維持します。 ネットワークはただ一つの領域に属します、そして、ルータインタフェースはただ一つの領域に接続します。 また、それぞれのルータ隣接番組はただ一つの領域に属します。
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を見ます)。
Moy Standards Track [Page 49] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[49ページ]RFC2328OSPFバージョン1998年4月2日
+----+
|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構造
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領域を通る最も短いイントラ領域経路の費用です。
Moy Standards Track [Page 50] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[50ページ]RFC2328OSPFバージョン1998年4月2日
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を見る)で、派生します。
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を見てください。
Moy Standards Track [Page 51] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[51ページ]RFC2328OSPFバージョン1998年4月2日
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を選出します。
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
NBMAネットワークでは、何らかの設定情報がHelloプロトコルの操作に必要であるかもしれません。 潜在的にDesignated Routerになるかもしれない各ルータで、すべてのリストは他になります。
Moy Standards Track [Page 52] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[52ページ]RFC2328OSPFバージョン1998年4月2日
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.
ルータはネットワークに付きました。 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 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
Database記述パケットのこの送受信は「データベース交換プロセス」と呼ばれます。 このプロセスの間、2つのルータがマスター/奴隷関係を形成します。 それぞれのDatabase記述Packetには、一連番号があります。 マスター(投票)によって送られたデータベース記述Packetsは、一連番号を反響することで奴隷によって承認されます。 そして、両方の投票、それら
Moy Standards Track [Page 53] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[53ページ]RFC2328OSPFバージョン1998年4月2日
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.
応答はリンク州のデータの合計を含んでいます。 マスターは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ネットワーク・ナンバーを得ることができます。
Moy Standards Track [Page 54] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[54ページ]RFC2328OSPFバージョン1998年4月2日
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は同期プロセスで中央の役割を果たします。
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になります。
Moy Standards Track [Page 55] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[55ページ]RFC2328OSPFバージョン1998年4月2日
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 traffic
lasts only as long as it takes to flood the new LSAs (which
announce the new Designated Router).
新しいDesignated Routerへの変遷をより滑らかにするように、それぞれの放送とNBMAネットワークのためのBackup Designated Routerがあります。 Backup Designated Routerはネットワークのすべてのルータに隣接してもいて、前のDesignated Routerが失敗すると、Designated Routerになります。 Backup Designated Routerが全くなければ、新しいDesignated Routerがいつ必要で、新しい隣接番組になったかはネットワークに取り付けられた新しいDesignated Routerと他のすべてのルータの間で形成されなければならないでしょうに。 隣接番組形成プロセスの一部はリンク州のデータベースの連動です。(潜在的に、データベースはかなり長い時間がかかるかもしれません)。 この間に、ネットワークはトランジットデータ通信量に利用可能でないでしょう。 Backup Designatedは、既に存在しているので、これらの隣接番組を形成する必要性を取り除きます。 これは、単に新しい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つのルータが複数のネットワークが共通であるなら、それらの間には、複数の隣接番組があるかもしれません。
Moy Standards Track [Page 56] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[56ページ]RFC2328OSPFバージョン1998年4月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はネットワークに付けられた他のすべてのルータに隣接してなります。
+---+ +---+
|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: 隣接番組のグラフ
Moy Standards Track [Page 57] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[57ページ]RFC2328OSPFバージョン1998年4月2日
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を接続する投げつけられた系列の理由です。
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に相談してください:
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パケットのタイプをタイプします。
Moy Standards Track [Page 58] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[58ページ]RFC2328OSPFバージョン1998年4月2日
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を見てください。
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
パケットのための受信者IPアドレスは以下の通り選択されます。 物理的な二地点間ネットワークでは、IPの目的地はいつもアドレスAllSPFRoutersに設定されます。 他のすべてのネットワークタイプ(仮想のリンクを含んでいる)で、すなわち、ユニキャストとして直接隣接番組のもう一方の端に送った状態でOSPFパケットの大部分を送ります。 この場合、IPの目的地はただ隣接番組のもう一方の端に関連しているNeighbor IPアドレス(セクション10を見る)です。 ユニキャストが放送網にあるので、唯一のパケットは発信しませんでした。 これらのネットワークでは、マルチキャストの目的地AllSPFRouters、Designated RouterにHelloパケットを送ります、そして、BackupはLink州Updateを両方に送ります。
Moy Standards Track [Page 59] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[59ページ]RFC2328OSPFバージョン1998年4月2日
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.
マルチキャストへのパケットとLink州Acknowledgment PacketsはAllSPFRoutersを扱います、それらのLink州UpdateとLink州Acknowledgment Packetsの両方が他のすべてのルータでマルチキャストアドレスAllDRoutersに行きますが。
Retransmissions of Link State Update packets are ALWAYS sent
directly to the neighbor. On multi-access networks, this means
that retransmissions should be sent to the neighbor's IP
address.
Link州UpdateパケットのRetransmissionsは直接隣人に送られたALWAYSです。 マルチアクセスネットワークでは、これは、「再-トランスミッション」が隣人のIPアドレスに送られるべきであることを意味します。
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について説明するセクションがパケット伝送を議定書の中で述べます。
Moy Standards Track [Page 60] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[60ページ]RFC2328OSPFバージョン1998年4月2日
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 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はそうしなければなりません:
Moy Standards Track [Page 61] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[61ページ]RFC2328OSPFバージョン1998年4月2日
(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アドレスにたとえることによって、これについて確かめることができます、インタフェースマスクで両方のアドレスにマスクをかけた後に。 二地点間ネットワークにこの比較を実行するべきではありません。 二地点間ネットワークに、リンクのそれぞれの端のインターフェース・アドレスは独自に配属されます、それらが少しでも割り当てられるなら。
(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の補数チェックサムへのセットである)のチェックサム分野について確かめるかもしれません。 認証手順が失敗するなら、パケットは捨てられるべきです。
Moy Standards Track [Page 62] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[62ページ]RFC2328OSPFバージョン1998年4月2日
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に記載されたセクションに相談してください。
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インターフェース・アドレスを持っています。
Moy Standards Track [Page 63] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[63ページ]RFC2328OSPFバージョン1998年4月2日
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. 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ネットワーク・ナンバーがリンク自体に割り当てられないので、リンクのそれぞれの側面のアドレスは独自に割り当てられます、それらが少しでも割り当てられるなら。
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でラベルされます。
Moy Standards Track [Page 64] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[64ページ]RFC2328OSPFバージョン1998年4月2日
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秒です。
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
他のルータがこのネットワークに付けた隣接しているルータのリスト。 このリストはHelloプロトコルによって形成されます。 隣接番組はいくつかに形成されるでしょう。
Moy Standards Track [Page 65] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[65ページ]RFC2328OSPFバージョン1998年4月2日
these neighbors. The set of adjacent neighbors can be
determined by an examination of all of the neighbors' states.
これらの隣人。 隣接している隣人のセットは隣人の州のすべての試験で決定できます。
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 66] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[66ページ]RFC2328OSPFバージョン1998年4月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. All
interface timers should be disabled, and there should be no
adjacencies associated with the interface.
下にThisは初期の界面準位です。 この状態では、低レベルプロトコルは、インタフェースが使用不可能であることを示しました。 そのようなインタフェースに全くいいえプロトコルトラフィックを送るか、または受け取るでしょう。 この状態では、インタフェース・パラメータはそれらの初期の値に設定されるべきです。 すべてのインタフェースタイマが損傷されるべきです、そして、インタフェースに関連しているどんな隣接番組もあるべきではありません。
Loopback
In this state, the router's interface to the network is
ループバックIn、この状態、ネットワークへのルータのインタフェースはそうです。
Moy Standards Track [Page 67] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[67ページ]RFC2328OSPFバージョン1998年4月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州を強制します。
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
輪にし返されます。 インタフェースはハードウェアかソフトウェアで輪にされるかもしれません。 インタフェースは定期的なデータ通信量を入手できなくなるでしょう。 しかしながら、送付ICMPピングを通どちらかだってこのインタフェースの品質でインタフェースに情報を得るか、または誤りテストが何かを通して少し好きであるのがまだ望ましいかもしれません。 この理由で、IPパケットはまだLoopback状態のインタフェースに扱われているかもしれません。 to
Moy Standards Track [Page 68] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[68ページ]RFC2328OSPFバージョン1998年4月2日
facilitate this, such interfaces are advertised in router-
LSAs as single host routes, whose destination is the IP
interface address.[4]
これを容易にしてください、そして、ただ一つのホストルートとしての目的地がIPインターフェース・アドレスであるルータLSAsにそのようなインタフェースの広告を出します。[4]
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
DR In、この状態、このルータ自体は付属ネットワークのDesignated Routerです。 隣接番組はネットワークに付けられた他のすべてのルータに確立されます。 また、ルータはそうしなければなりません。
Moy Standards Track [Page 69] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[69ページ]RFC2328OSPFバージョン1998年4月2日
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.
ネットワーク・ノードのためにネットワーク-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に相談してください。
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状態の端を示します。
Moy Standards Track [Page 70] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[70ページ]RFC2328OSPFバージョン1998年4月2日
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の試験で検出されます。
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
インタフェースがもう輪にし返されないというUnloopInd An指示を受けました。 LoopIndイベントのようにこれ
Moy Standards Track [Page 71] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[71ページ]RFC2328OSPFバージョン1998年4月2日
indication can be received either from network management or
from the lower level protocols.
ネットワークマネージメントか下のレベルプロトコルから指示を受けることができます。
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を見てください。
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に移行します。
Moy Standards Track [Page 72] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[72ページ]RFC2328OSPFバージョン1998年4月2日
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.
新しい州: アクションルーチンによります。
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
Moy Standards Track [Page 73] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[73ページ]RFC2328OSPFバージョン1998年4月2日
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
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
動作: どんな動作も必要ではありません。 例えば、インタフェース変数はLoopback状態に入るとき既にリセットされました。 そのレセプションに注意します。
Moy Standards Track [Page 74] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[74ページ]RFC2328OSPFバージョン1998年4月2日
an InterfaceUp event is necessary before the
interface again becomes fully functional.
インタフェースが再び完全に機能的になる前に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 75] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[75ページ]RFC2328OSPFバージョン1998年4月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を呼び出すことによって、これをします。
Moy Standards Track [Page 76] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[76ページ]RFC2328OSPFバージョン1998年4月2日
(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
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).
(7) Designated RouterかBackup Designated Routerのどちらかのアイデンティティが上の計算で変化したなら、このインタフェースに関連している隣接番組のセットは、変更される必要があるでしょう。 いくつかの隣接番組が、形成される必要があるかもしれません、そして、他のものは壊れる必要があるかもしれません。 これを達成するには、少なくとも状態が2方法であるすべての隣人の上にイベントAdjOKを呼び出してください。 これは再検討されるべき隣接番組のためにそれらの適任を引き起こすでしょう(セクション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を選出するのに使用されます。
Moy Standards Track [Page 77] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[77ページ]RFC2328OSPFバージョン1998年4月2日
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-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パケットのOptions分野はルータの任意のOSPF能力について説明します。 1つの任意の能力がこの仕様に基づき定義されます(セクション4.5とA.2を見てください)。 そして、Options分野のE-ビットが設定されるべきである、付属領域は処理のASの外部のLSAsができる場合にだけ(すなわち、それはスタッブ領域ではありません)。 E-ビットが不当に設定されると、隣接しているルータは、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パケットを送ります。 MultiPointへのPointネットワークでは、あらゆるHelloIntervalが後援するそれぞれの付属隣人に別々のHelloパケットを送ります。 NBMAネットワークでのHelloパケットの発信は次のセクションでカバーされています。
Moy Standards Track [Page 78] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[78ページ]RFC2328OSPFバージョン1998年4月2日
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ネットワークの適任のルータの数は小さく保たれるべきです。
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
いつまでに、定期的に隣人、いずれへのHello Packetsの間隔をHelloパケットに送るのは決定しているか。
Moy Standards Track [Page 79] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[79ページ]RFC2328OSPFバージョン1998年4月2日
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.
隣人の状態。 州の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 80] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[80ページ]RFC2328OSPFバージョン1998年4月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に記録されます。
Moy Standards Track [Page 81] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[81ページ]RFC2328OSPFバージョン1998年4月2日
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ネットワークだけでは、定義されます。
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パケットが受け取られているとき、リストを使い果たします。
Moy Standards Track [Page 82] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[82ページ]RFC2328OSPFバージョン1998年4月2日
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に記録されます。
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 83] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[83ページ]RFC2328OSPFバージョン1998年4月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 InactivityTimer always forces Down State,
Event LLDown always forces Down State
変遷が描写した状態に加えて、Event KillNbrはいつもDown州を強制して、Event InactivityTimerはいつもDown州を強制して、Event LLDownはいつもDown州を強制します。
Moy Standards Track [Page 84] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[84ページ]RFC2328OSPFバージョン1998年4月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--変遷が描写した状態に加えて、隣接番組の形成/壊すのに通じます。
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
イニットIn、この状態であり、Helloパケットは最近、隣人から見られました。 しかしながら、双方向のコミュニケーションは隣人と共にまだ確立されていません(すなわち、ルータ自体は隣人のHelloパケットに現れませんでした)。 すべて
Moy Standards Track [Page 85] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[85ページ]RFC2328OSPFバージョン1998年4月2日
neighbors in this state (or higher) are listed in the Hello
packets sent from the associated interface.
この状態(より高い)の隣人は関連インタフェースから送られた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パケットを送ります。
Full
In this state, the neighboring routers are fully adjacent.
These adjacencies will now appear in router-LSAs and
network-LSAs.
Inを洗い張りしてください。この状態、隣接しているルータは完全に隣接しています。 これらの隣接番組は今、ルータ-LSAsとネットワーク-LSAsに現れるでしょう。
Moy Standards Track [Page 86] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[86ページ]RFC2328OSPFバージョン1998年4月2日
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
Done Linkを積み込むこと州Updatesが日付のすべて外で受け取られている。
Moy Standards Track [Page 87] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[87ページ]RFC2328OSPFバージョン1998年4月2日
portions of the database. This is indicated by the Link
state request list becoming empty after the Database
Exchange process has completed.
データベースの部分。 これは過程が完成したDatabase Exchangeの後に空になるLink州の要求リストによって示されます。
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
LLDown Thisは下のレベルプロトコルからの隣人が現在手が届かないという指示です。 例えば、X.25ネットワークでは、X.25の明確な指示でこれを示すことができるでしょう。
Moy Standards Track [Page 88] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[88ページ]RFC2328OSPFバージョン1998年4月2日
with appropriate cause and diagnostic fields. This event
forces the neighbor into Down state.
適切な原因と診断分野で。 この出来事は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)によってそれぞれの州の変化は呼び出されます。 隣人の現状のときによって、この出来事は異なった効果を生むかもしれません。 この理由で、以下の州のマシンは現在の隣人国と容認された出来事によって組織化されます。 州のマシンの各エントリーは結果として起こる新しい隣人州と必要なセットの追加機能について説明します。
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
州: 試み
Moy Standards Track [Page 89] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[89ページ]RFC2328OSPFバージョン1998年4月2日
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を始動してください。 タイマの後の発火は、隣人が死んでいるのを示すでしょう。
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
さもなければ(隣接番組は確立されるべきである)、隣人はExStartへの変遷を述べます。 この状態に入ると、ルータはDDを増加します。
Moy Standards Track [Page 90] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[90ページ]RFC2328OSPFバージョン1998年4月2日
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).
隣人データ構造における一連番号。 これが隣接番組を試みてある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-
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.
動作: ルータは隣人Database概要リストの全体の領域リンク州のデータベースのコンテンツを記載しなければなりません。 領域リンク州のデータベースは領域構造に含まれたルータ-LSAs、ネットワーク-LSAs、および概要-LSAsから成ります、グローバル構造に含まれたAS外部のLSAsと共に。 ASの外部のLSAsは仮想の隣人のDatabase概要リストから省略されます。 領域がスタッブとして構成されたなら(セクション3.6を見てください)、ASの外部のLSAsはDatabase概要リストから省略されます。 年令がMaxAgeと等しいLSAsは代わりに隣人のLink州の「再-トランスミッション」リストに追加されます。 Database概要リストの概要をDatabase記述パケットの隣人に送るでしょう。 それぞれのDatabase記述PacketはDD一連番号を持って、明らかに承認されます。 1Database記述Packetだけがいかなる時も、傑出していた状態で許容されています。 Database記述パケットの送受信に関するその他の詳細に関しては、セクション10.8と10.6を見てください。
Moy Standards Track [Page 91] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[91ページ]RFC2328OSPFバージョン1998年4月2日
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.
動作: どんな動作も必要ではありません。 これは隣接番組の最終的な状態です。
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を述べます。
Moy Standards Track [Page 92] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[92ページ]RFC2328OSPFバージョン1998年4月2日
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.
This Database Description Packet should be otherwise
empty (see Section 10.8).
動作: (ことによると部分的に形成されています)の隣接番組を取りこわします、そして、次に、再建で試みをします。 隣人は前縁をExStartに述べます。 Link州の「再-トランスミッション」リスト、Database概要リスト、およびLink州の要求リストはLSAsをきれいにされます。 次に、ルータが隣人データ構造におけるDD一連番号を増加して、それ自体がマスター(マスター/奴隷ビットをマスターに設定する)であると宣言して、Database記述Packetsを送り始める、(I)、より多くの(M)、およびビットが設定するマスター(MS)を初期化してください。 そうでなければ、このDatabase記述Packetは空であるべきです(セクション10.8を見てください)。
State(s): Exchange or greater
州: 交換か、よりすばらしいです。
Event: BadLSReq
出来事: BadLSReq
Moy Standards Track [Page 93] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[93ページ]RFC2328OSPFバージョン1998年4月2日
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も障害があります。
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をきれいにされます。
Moy Standards Track [Page 94] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[94ページ]RFC2328OSPFバージョン1998年4月2日
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の両方に隣接してなります。
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
隣接番組を形成する決定は隣人州のマシンの2つの場所で起こります。 付属ネットワークのアイデンティティが初めは指定されるとき(バックアップをとります)、双方向のコミュニケーションが第二に隣人と共に確立されるときの1番目
Moy Standards Track [Page 95] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[95ページ]RFC2328OSPFバージョン1998年4月2日
Router changes. If the decision is made to not attempt an
adjacency, the state of the neighbor communication stops at 2-
Way.
ルータは変化します。 隣接番組を試みないのを決定をするなら、隣人コミュニケーションの状態は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
受信インタフェースはただ一つのOSPF領域に付きます(これは背骨であるかもしれません)。 Hello PacketのOptions野原で発見されるE-ビットの設定は領域のこのものに合わなければなりません。
Moy Standards Track [Page 96] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[96ページ]RFC2328OSPFバージョン1998年4月2日
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.
ExternalRoutingCapability。 ASの外部のLSAsが領域中に/へあふれないなら(i.e、領域は「スタッブ」です)E-ビットが容認されたHello Packetsで明確であるに違いない、さもなければ、E-ビットを設定しなければなりません。 ミスマッチは止める処理とパケットを落とされます。 Hello PacketのOptions分野のビットの残りの設定は無視されるべきです。
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. For these network types, the neighbor
structure's Router Priority field, Neighbor's Designated Router
field, and Neighbor's Backup Designated Router field are also
set equal to the corresponding fields found in the received
Hello Packet; changes in these fields should be noted for
possible use in the steps below. 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を設定してください。 これらのネットワークタイプにおいて、また、隣人構造のRouter Priority分野、NeighborのDesignated Router分野、およびNeighborのBackup Designated Router分野は容認されたHello Packetで見つけられた対応する分野と等しいセットです。 これらの分野の変化は下でのステップにおける活用可能性で有名であるべきです。 二地点間ネットワーク(しかし、どんな仮想のリンクの上にもそうしない)で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が作用されるかもしれません:
Moy Standards Track [Page 97] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[97ページ]RFC2328OSPFバージョン1998年4月2日
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, if a change in the neighbor's Router Priority field
was noted, the receiving interface's state machine is
scheduled with the event NeighborChange.
o 次に、隣人のRouter Priority分野の変化が注意されたなら、受信インタフェースの州のマシンはイベントNeighborChangeと共に予定されています。
o If the neighbor is both declaring itself to be Designated
Router (Hello Packet's Designated Router field = Neighbor IP
address) and the Backup Designated Router field in the
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.
o 隣人が、それ自体がDesignated Routerであるとともに宣言していて(こんにちは、PacketのDesignated Router分野は隣人IPアドレスと等しいです)、パケットのBackup Designated Router分野が0.0と等しいなら、.0と受信インタフェースがある.0はWaitingを述べて、受信インタフェースの州のマシンはイベントBackupSeenと共に予定されています。 さもなければ、以前に、そうしていなかったか、隣人が、それ自体がDesignated Routerであると宣言していて、または隣人が、それ自体がそれが以前にそうしたDesignated Routerであると宣言していないなら、受信インタフェースの州のマシンはイベントNeighborChangeと共に予定されています。
o If the neighbor is declaring itself to be Backup Designated
Router (Hello Packet's 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.
o 隣人が、それ自体がBackup Designated Routerであると宣言していて(こんにちは、PacketのBackup Designated Router分野は隣人IPアドレスと等しいです)、受信インタフェースが州のWaitingにあるなら、受信インタフェースの州のマシンはイベントBackupSeenと共に予定されています。 さもなければ、以前に、そうしていなかったか、隣人が、それ自体がBackup Designated Routerであると宣言していて、または隣人が、それ自体がそれが以前にそうしたBackup Designated Routerであると宣言していないなら、受信インタフェースの州のマシンはイベントNeighborChangeと共に予定されています。
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を見てください。
Moy Standards Track [Page 98] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[98ページ]RFC2328OSPFバージョン1998年4月2日
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記述パケットは以下で説明された処理における「写し」であると考えられます。
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.
隣人州が機械加工するイニットはイベント2-WayReceivedと共に実行されるべきです。 これは、即座の州の変化が2方法を述べるか、またはExStartを述べることを引き起こします。 そして、新しい状態がExStartであるなら、現在のパケットの処理は、通り抜けて落ちるのによるこの新しい状態で以下のExStartをケースに入れ続けるべきです。
Moy Standards Track [Page 99] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[99ページ]RFC2328OSPFバージョン1998年4月2日
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です。
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を発生させて、パケットを処理するのを止めることです。
Moy Standards Track [Page 100] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[100ページ]RFC2328OSPFバージョン1998年4月2日
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分野が以前に隣人(隣人構造のNeighbor Options分野に記録される)から受け取ったより任意の異なったOSPF能力を示すなら、隣人イベント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記述パケットを繰り返すのによる写しに応答しなければなりません。
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
ルータが次として容認されたDatabase記述Packetを認めるとき、連続してパケット含有量は以下の通り処理されます。 LSAが記載したそれぞれに関しては、LSAのLSタイプは正当性がないかどうかチェックされます。 LSタイプが未知(例えば、LSのどんなひとりもこの仕様で定義された1-5をタイプしない)かこれがASの外部のLSA(LSは=5をタイプする)であり、隣人がaに関連しているかどうかということであるなら
Moy Standards Track [Page 101] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[101ページ]RFC2328OSPFバージョン1998年4月2日
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.
領域を引き抜いてください、そして、隣人イベント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 102] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[102ページ]RFC2328OSPFバージョン1998年4月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.
ルータの任意のOSPF能力(セクション4.5を見る)はDatabase記述パケットのOptions分野の隣人に伝えられます。 ルータはDatabase Exchangeと氾濫手順中で同じセットの任意の能力を維持するべきです。 ある理由でルータの任意の能力が変化するなら、Database Exchange手順は、隣人州のExStartに戻ることによって、再開されるべきです。 1つの任意の能力がこの仕様に基づき定義されます(セクション4.5とA.2を見てください)。 そして、E-ビットが設定されるべきである、付属ネットワークが非スタッブ領域に属す場合にだけ。 Options分野の認識されていないビットはゼロに設定されるべきです。
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.
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
州のExchangeでは、Database記述Packetsは実際にルータのデータベースに含まれたリンク州の情報の概要を含んでいます。 領域のリンク州のデータベース(Exchangeへの隣人変遷が述べる時間の)の各LSAは隣人Database概要リストに記載されています。 それぞれの新しいDatabase
Moy Standards Track [Page 103] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[103ページ]RFC2328OSPFバージョン1998年4月2日
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.
記述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記述パケットを送るかに関する決断をルータがマスターかそれとも奴隷であるかに頼っています:
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州の要求リストの始まりを隣人に送ります。
Moy Standards Track [Page 104] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[104ページ]RFC2328OSPFバージョン1998年4月2日
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. LSAs on the Link state request list that have been
requested, but not yet received, are packaged into Link State
Request packets for retransmission 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州の要求リストの上の要求されていますが、まだ受け取られていないLSAsはRxmtIntervalごとに「再-トランスミッション」のためにLink州Requestパケットにパッケージされます。 いかなる時も未払いの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隣人出来事は発生します。
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
RT1は、マスターとしてそれ自体について断言することによって、始まります。 本当に、RT2がマスター(RT2の、より高いRouter IDによる)であることが見るとき、RT1は奴隷制度の州に移行して、隣人のDD一連番号を採用します。 そして、投票がマスター(RT2)と応答から奴隷(RT1)から来ていて、データベース記述パケットを交換します。 Database記述のこの系列
Moy Standards Track [Page 105] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[105ページ]RFC2328OSPFバージョン1998年4月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)は身を粉にして働きます)。------------------------------>の忌わしい(Seq=y+1、M、マスター)交換<。------------------------------ 忌わしいです(Seq=y+1(M)は身を粉にして働きます)。------------------------------>… ... ... 忌わしい(Seq=y+n、マスター)<。------------------------------ 忌わしい(Seq=y+n、奴隷)ローディング------------------------------LSがいっぱいに要求する>。------------------------------>LSアップデート<。------------------------------ LS要求------------------------------>LSアップデート<。------------------------------ 完全
Moy Standards Track [Page 106] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[106ページ]RFC2328OSPFバージョン1998年4月2日
Figure 14: An adjacency bring-up example
図14: 隣接番組は例を持って来ます。
Packets ends when both the poll and associated response has the
M-bit off.
投票と関連応答には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の発信をはさみ込んだかもしれません。
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で経路指定テーブルのビルについて議論します。
Moy Standards Track [Page 107] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[107ページ]RFC2328OSPFバージョン1998年4月2日
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]
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.
任意のCapabilities When、目的地はこの分野が、任意のOSPF能力が目的地のルータでサポートしたのを示すルータです。 この仕様で定義された唯一の任意の能力がASの外部のLSAsを処理する能力です。 OSPFの任意の能力のさらなる議論に関しては、セクション4.5を見てください。
Moy Standards Track [Page 108] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[108ページ]RFC2328OSPFバージョン1998年4月2日
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.
目的地に使用する経路のセットは経路が属するOSPF領域に基づいて異なるかもしれません。 これは、同じ目的地のための複数の経路指定テーブルエントリーがあるかもしれないことを意味します、次の分野の値によって。
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.
Thisがさばく領域はリンク州の情報が経路指定テーブルエントリーの経路の収集につながった領域を示します。 これはエントリーの関連領域と呼ばれます。 ASの外部の経路のセットにおいて、この分野は定義されません。 タイプ「ルータ」の目的地には、それぞれのいくつかの領域に関連している経路(したがって、経路指定テーブルエントリーを切り離す)の別々のセットがあるかもしれません。 2つの境界ルータが一般的に複数の領域を分担するとき、例えば、これは起こるでしょう。 タイプ「ネットワーク」の目的地に関しては、最も良い領域(都合のよいルートを提供するもの)に関連している経路のセットだけが維持されます。
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 decreasing 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.
経路タイプThereはトラフィックを目的地に発送するのに使用される、4つの可能なタイプの経路です、ここ、減少しているよく使われる順では、記載されています: イントラ領域、相互領域は外部であることの形で1つの外部のタイプかタイプ2をタイプします。 イントラ領域経路はルータの付属領域の1つに属す目的地を示します。 相互領域経路は他のOSPF領域の目的地への経路です。 これらは容認された概要-LSAsの試験で発見されます。 ASの外部の経路はASへの外部の目的地への経路です。 これらは容認されたAS外部のLSAsの試験で検出されます。
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
経路のリンク州の費用目的地にかかってください。 タイプ2の外部の道以外のすべての経路に、これは全体の経路の費用について説明します。 Typeの2の外部の経路に、この分野はASへの内部の経路の部分の費用について説明します。 これ
Moy Standards Track [Page 109] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[109ページ]RFC2328OSPFバージョン1998年4月2日
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.
タイプ2はタイプ2の外部の道に、有効なOnlyかかります。 これらの経路に、この分野は経路の外部の部分の費用を示します。 この費用は、AS境界ルータで広告を出して、総経路費用の最もかなりの部分です。 例えば、タイプ2がある2の外部の経路がかかる5人のタイプが2がかかる10人のタイプがある経路よりいつも好まれます、2つの経路の内部のコンポーネントの費用にかかわらず。
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).
イントラ領域経路だけへのリンク州Origin Valid、この分野は直接目的地に参照をつけるLSA(ルータ-LSAかネットワーク-LSA)を示します。 例えば、目的地がトランジットネットワークであるなら、これはトランジットネットワークのネットワーク-LSAです。 目的地がスタッブネットワークであるなら、これは付属ルータのためのルータ-LSAです。 LSAは最短パス木の計算の間、発見されます(セクション16.1を見てください)。 複数のLSAsが目的地に参照をつけるかもしれなくて、しかしながら、繋がりを壊す体系はいつも選択を独身のLSAに変えます。 Link州Origin分野はOSPFプロトコルによって使用されませんが、それはOSPFのMulticastルーティング拡張子(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:
等しい経路タイプと費用の複数の経路が目的地(ほかの場所では、「等しい費用」を経路と呼ぶ)に存在するとき、それらは単一の経路指定テーブルエントリーに保存されます。 「等しい費用」経路の各々は以下の分野によって区別されます:
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.
次に、トラフィックを目的地に送るとき使用する外向的なルータインタフェースは跳びます。 また、放送、PointからMultiPoint、およびNBMAネットワークでは、次のホップは経路で次のルータ(もしあれば)のIPアドレスを目的地に向かって含めます。
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.
相互領域とASの外部の経路だけにルータValidの広告を出します。 この分野はこの経路に通じたルータ広告の概要LSAかASの外部のLSAのRouter IDを示します。
Moy Standards Track [Page 110] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[110ページ]RFC2328OSPFバージョン1998年4月2日
11.1. Routing table lookup
11.1. 索表を発送します。
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.
IPデータ・パケットが受け取られているとき、OSPFルータによって、ルーティングがパケットの目的地に最もよく合っているテーブル項目であることがわかります。 そして、この経路指定テーブルエントリーはパケットを進める際に使用する外向的なインタフェースと次のホップルータを提供します。 このセクションは最も良い合っているルーティングがテーブル項目であることがわかるプロセスについて説明します。
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]
ルックアップが始まる前に、テーブル項目を発送する「破棄」はそれぞれのルータの活動領域アドレスの範囲のために経路指定テーブルに挿入されるべきです(セクション3.5を見てください)。 (範囲がイントラ領域経路のそばで届いている1つ以上のネットワークを含んでいるなら、領域の範囲は「アクティブである」と考えられます。) 「捨ててください」というエントリーの目的地は関連活動領域アドレスの範囲によって説明されたアドレスのセットです、そして、「捨ててください」というそれぞれのエントリーの経路タイプは「相互領域」に用意ができています。[10]
Several routing table entries may match the destination address.
In this case, the "best match" is the routing table entry that
provides the most specific (longest) match. Another way of
saying this is to choose the 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 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. (Note that for any single routing table entry,
multiple paths may be possible. In these cases, the calculations
in Sections 16.1, 16.2, and 16.4 always yield the paths having
the most preferential path-type, as described in Section 11).
いくつかの経路指定テーブルエントリーが送付先アドレスに合うかもしれません。 この場合、「最も良いマッチ」は最も特定(最も長い)のマッチを提供する経路指定テーブルエントリーです。 IPの最も狭い範囲を指定するエントリーを選ぶと言うこれがものである別の方法が例えばアドレス/マスクのためのエントリーが対にする.[11]を扱う、(128.185、.1、.0、0xffffff00)、エントリーより組には特定である、(128.185、.0、.0、0xffff0000) すべての目的地を合わせるので、デフォルトルートは最も特定でないマッチです。 (どんな単一の経路指定テーブルエントリーにも、複数の経路が可能であるかもしれないことに注意してください。 これらの場合では、セクション16.1、16.2、および16.4における計算は持っている中で最も優先の経路タイプ経路をいつももたらします、セクション11で説明されるように).
If there is no matching routing table entry, or the best match
routing table entry is one of the above "discard" routing table
entries, then the packet's IP destination is considered
unreachable. Instead of being forwarded, the packet should then
be discarded and an ICMP destination unreachable message should
be returned to the packet's source.
合っている経路指定テーブルエントリーが全くないか、最も良いマッチ経路指定テーブルエントリーがテーブル項目を発送する上の「破棄」の1つであるなら、パケットのIPの目的地は手が届かないと考えられます。 進めることの代わりに、次に、パケットを捨てるべきです、そして、ICMP送信不可能メッセージをパケットのソースに返すべきです。
11.2. Sample routing table, without areas
11.2. 領域のないサンプル経路指定テーブル
Consider the Autonomous System pictured in Figure 2. No OSPF
areas have been configured. A single metric is shown per
図2に描写されたAutonomous Systemを考えてください。 OSPF領域は全く構成されていません。 Aシングルメートル法、示されます。
Moy Standards Track [Page 111] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[111ページ]RFC2328OSPFバージョン1998年4月2日
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".
外国行きのインタフェース。 Router RT6の経路指定テーブルの計算はセクション2.2で説明されるように続きます。 結果として起こる経路指定テーブルはTable12で見せられます。 目的地タイプは簡略化されています: 「N」、「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.
この例には複数の等しい費用最短パスのインスタンスが全くありません。 また、領域が全くないので、相互領域経路が全くありません。
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.
ルータのRT5とRT7はAS境界ルータです。 イントラ領域ルートをRouters RT5とRT7に計算してあります。 これは、外部経路がRT5とRT7(すなわち、Networks N12、N13、N14、およびN15)によって広告に掲載された目的地に計算されるのを許容します。 RT5によって溯源されたASの外部のLSAsとRT7が広告を出しているすべてが1の外部の測定基準をタイプすると思われます。 これは目的地N12-N15に計算されるタイプ1の外部の道をもたらします。
11.3. Sample routing table, with areas
11.3. 領域があるサンプル経路指定テーブル
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.
前の例、OSPF領域に分けられたこの時間を考えてください。 OSPF領域構成は図6に描写されます。 ルータRT4の経路指定テーブルはこの領域構成のために説明されるでしょう。 Area1とバックボーン接続にはルータRT4が接続がいます。 これで、Router RT4は図7と8に示された2つのグラフの連結であるとASをみなします。 Table13に結果として起こる経路指定テーブルを表示します。
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).
一方、Routers RT5とRT7はAS境界ルータです。 ルータのRT3、RT4、RT7、RT10、およびRT11は境界ルータです。 境界ルータRT3のための2つのルーティングエントリーがあることに注意してください、RT4(領域1とバックボーン)と共用してそれには2つの領域があるので。
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
すべての境界ルータにバックボーン経路について計算してあります。 相互領域ルートを決定するとき、これらは使用されています。 相互領域ルートのすべてがバックボーンに関連していることに注意してください。 計算のルータがそれ自体で境界ルータであるときに、いつもこれはそうです。 ルート設定情報はエリアの境界で凝縮します。 この例では、Area3が定義されたのでそれがN9-N11とホストルートをH1にネットワークでつなぐと、私たちは、思います。
Moy Standards Track [Page 112] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[112ページ]RFC2328OSPFバージョン1998年4月2日
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
タイプDest領域経路タイプは次の副詞かかります。 ホップルータ____________________________________________________________ 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*は1extをタイプします。 10 RT10 RT7N N13*は1extをタイプします。 14 RT5 RT5N N14*は1extをタイプします。 14 RT5 RT5N N15*は1extをタイプします。 17 RT10 RT7
Table 12: The routing table for Router RT6
(no configured areas).
テーブル12: Router RT6(構成された領域がない)のための経路指定テーブル。
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.
背骨(Router RT11による)に広告を出すと、ただ一つのルートにすべて凝縮します。 このルートの費用が個々のコンポーネントへのコストのセットの最大であることに注意してください。
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.
Routers RT10とRT11の間で構成された仮想のリンクがあります。 この構成された仮想のリンクがなければ、RT11はネットワークのN9-N11とHost H1のために背骨にルートの広告を出すことができないでしょう、そして、Router RT4の経路指定テーブルのこれらのネットワークのためのエントリーがないでしょう。
In this example there are two equal-cost paths to Network N12.
However, they both use the same next hop (Router RT5).
この例には、Network N12への2つの等しい費用経路があります。 しかしながら、それらの両方が同じ次のホップ(ルータRT5)を使用します。
Moy Standards Track [Page 113] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[113ページ]RFC2328OSPFバージョン1998年4月2日
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 link are shown
追加仮想のリンクがRouter RT4とRouter RT3の間で構成されるなら、ルータRT4の経路指定テーブルは向上するでしょうに(すなわち、経路指定テーブルの経路のいくつかが、より短くなるでしょう)。 新しい仮想のリンクがそうするだろう、それ自体、Table13(Area1を通したイントラ領域経路)の領域境界ルータRT3のための初記入に関連してください。 これは仮想のリンクへの1の費用をもたらすでしょう。 この仮想のリンクの添加で引き起こされる経路指定テーブルエントリー変化は見せられます。
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
タイプDest領域経路タイプは次の副詞かかります。 ホップス(s)ルータ__________________________________________________________________ N N1 1イントラ領域4RT1*N N2 1イントラ領域4RT2*N N3 1イントラ領域1**N N4 1イントラ領域3RT3*R RT3 1イントラ領域1**__________________________________________________________________ Nイブ0イントラ領域22RT5*N Ia0イントラ領域27RT5*R RT3 0イントラ領域21RT5*R RT5 0イントラ領域8**R RT7 0イントラ領域14RT5*R RT10 0イントラ領域22RT5*R RT11 0イントラ領域25RT5*__________________________________________________________________ N N6 0相互領域15RT5 RT7N N7 0相互領域19RT5 RT7N N8 0相互領域18RT5 RT7N N9-N11、H1 0相互領域36RT5 RT11__________________________________________________________________ N N12*は1extをタイプします。 16 RT5 RT5、RT7N N13*が1extをタイプします。 16 RT5 RT5N N14*は1extをタイプします。 16 RT5 RT5N N15*は1extをタイプします。 23 RT5 RT7
Table 13: Router RT4's routing table
in the presence of areas.
テーブル13: ルータRT4は領域があるときテーブルを発送しています。
Moy Standards Track [Page 114] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[114ページ]RFC2328OSPFバージョン1998年4月2日
in Table 14.
テーブル14で。
12. Link State Advertisements (LSAs)
12. リンク州の広告(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.
Autonomous Systemの各ルータは1つ以上のリンク州の広告(LSAs)を溯源します。 このメモはLSAsの5つの異なったタイプを定義します。(LSAsはセクション4.3で説明されます)。 LSAsの収集はリンク州のデータベースを形成します。 LSAのそれぞれの別々のタイプには、別々の機能があります。 ルータ-LSAsとネットワーク-LSAsは領域のルータとネットワークにどうインタコネクトされるかを説明します。 概要-LSAsは領域のルーティング情報を凝縮する方法を提供します。 ASの外部のLSAsはAutonomous System中に透明に外部的に派生しているルーティング情報の広告を出す方法を提供します。
Each LSA begins with a standard 20-byte header. This LSA header is
discussed below.
各LSAは標準の20バイトのヘッダーと共に始まります。 以下でこのLSAヘッダーについて議論します。
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
タイプDest領域経路タイプは次の副詞かかります。 ホップルータ________________________________________________________________ Nイブ0イントラ領域16RT3*N Ia0イントラ領域21RT3*R RT3 0イントラ領域1**R RT10 0イントラ領域16RT3*R RT11 0イントラ領域19RT3*________________________________________________________________ N N9-N11、H1 0相互領域30RT3 RT11
Table 14: Changes resulting from an
additional virtual link.
テーブル14: 追加仮想のリンクから生じる変化。
Moy Standards Track [Page 115] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[115ページ]RFC2328OSPFバージョン1998年4月2日
12.1. The LSA Header
12.1. 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.
LSAヘッダーはLSタイプ、Link州ID、およびAdvertising Router分野を含んでいます。 これらの3つの分野の組み合わせは唯一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.
Autonomous Systemと、すべて同時の現在のLSAのいくつかの例があるかもしれません。 どちらの例が、より最近かは、その時、断固としているに違いありません。 LS系列、LSチェックサム、およびLS時代分野を調べることによって、この決断をします。 また、これらの分野は20バイトのLSAヘッダーに含まれています。
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 referenced.
OSPFパケットの数個がリストLSAsをタイプします。 例が重要でないときに、LSAはLink州のLSタイプ、ID、およびAdvertising Routerによって言及されます(Link州Request Packetsを見てください)。 さもなければ、また、LS一連番号、LS時代、およびLSチェックサム分野に参照をつけなければなりません。
A detailed explanation of the fields contained in the LSA header
follows.
LSAヘッダーに含まれた分野の詳説は続きます。
12.1.1. LS age
12.1.1. LS時代
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.
この分野は秒のLSAの時代です。 それは無記名の16ビットの整数として処理されるべきです。 LSAが溯源されるとき、それは0に設定されます。 InfTransDelayは氾濫手順のあらゆるホップでそれを増加しなければなりません。 また、彼らが各ルータのデータベースに保持されるとき、LSAsは熟成します。
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.
LSAの時代は決して増加している過去MaxAgeではありません。 時代MaxAgeを持っているLSAsが経路指定テーブル計算に使用されません。 LSAの時代が最初にMaxAgeに達するとき、それは「再-あふれ」ます。 それはデータベース同期を確実にするのにもう必要でないときに、時代MaxAgeのLSAがデータベースから最終的に洗い流されます。 LSAsの年をとることの詳しい情報に関しては、セクション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
ルータがLSAの2つの例を受けるとき、LS時代分野は調べられます、その時ともに同じLS一連番号とLSチェックサムMaxAgeがある時代の例を持っていて
Moy Standards Track [Page 116] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[116ページ]RFC2328OSPFバージョン1998年4月2日
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.
最新であるとしていつも認められます。 これは、古いLSAsが経路ドメインからすぐに洗い流されるのを許容します。 時代がMaxAgeDiff以上で異なるなら、さもなければ、よりわずかな時代を過す例は最新の.[12]として認められます。その他の詳細に関してセクション13.1を見てください。
12.1.2. Options
12.1.2. オプション
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.
LSAヘッダーのOptions分野は、どの任意の能力がLSAに関連しているかを示します。 OSPFの任意の能力はセクション4.5で説明されます。 1つの任意の能力がOptions野原で発見されるE-ビットによって表されたこの仕様で定義されます。 Options分野の認識されていないビットはゼロに設定されるべきです。
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.
E-ビットはOSPFのExternalRoutingCapabilityを表します。 このビットは背骨に関連しているすべてのLSAs、および非スタッブ領域に関連しているすべてのLSAsに設定されるべきです(セクション3.6を見てください)。 また、それはすべてのASの外部のLSAsに設定されるべきです。 それはすべてのルータ-LSAs、ネットワーク-LSAs、およびスタッブ領域に関連している概要-LSAsにリセットされるべきです。 すべてのLSAsに関しては、E-ビットの設定は情報の目的だけのためのものです。 それは経路指定テーブル計算に影響しません。
12.1.3. LS type
12.1.3. LSはタイプします。
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.
LSタイプ分野はLSAの書式と機能を決めます。 異なったタイプのLSAsには、異なった名前(例えば、ルータ-LSAsかネットワーク-LSAs)があります。 ASの外部のLSAs(LSは=5をタイプする)を除いて、このメモで定義されたすべてのLSAタイプがただ一つの領域だけ中で水につかっています。 スタッブ領域を除いて、ASの外部のLSAsは全体のAutonomous System中で水につかっています(セクション3.6を見てください)。 それぞれの別々のLSAタイプはTable15で以下で簡潔に説明されます。
12.1.4. Link State ID
12.1.4. 州の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
この分野はLSAによって説明されている経路ドメインの断片を特定します。 LSAのLSタイプに頼っていて、Link州IDはTableに記載された値を呈します。
Moy Standards Track [Page 117] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[117ページ]RFC2328OSPFバージョン1998年4月2日
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記述________________________________________________ 1 これらはルータ-LSAsです。 彼らはルータのインタフェースの集まっている州について説明します。 詳しくは、セクション12.4.1に相談してください。 ________________________________________________ 2 これらはLSAsをネットワークでつなぎます。 彼らはネットワークに付けられたルータのセットについて説明します。 詳しくは、セクション12.4.2に相談してください。 ________________________________________________ 3か4Theseは概要-LSAsです。 彼らは、相互領域ルートを説明して、領域の境界でルーティング情報の凝縮を可能にします。 境界ルータによって溯源されて、Type4概要-LSAsがAS境界ルータにルートを説明している間、Type3概要-LSAsはルートをネットワークに説明します。 ________________________________________________ 5 これらはASの外部のLSAsです。 AS境界ルータによって溯源されて、それらはAutonomous Systemへの外部の目的地にルートを説明します。 また、ASの外部のLSAはAutonomous Systemのためのデフォルトルートを説明できます。
Table 15: OSPF link state advertisements (LSAs).
テーブル15: OSPFは州の広告(LSAs)をリンクします。
16.
16.
Actually, for Type 3 summary-LSAs (LS type = 3) and AS-
external-LSAs (LS type = 5), the Link State ID may
実際に、Type3概要-LSAs(LSは=3をタイプする)とASの外部のLSAs(LSは=5をタイプする)に関して、Link州IDはそうするかもしれません。
Moy Standards Track [Page 118] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[118ページ]RFC2328OSPFバージョン1998年4月2日
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はリンク州のIDをタイプします。_______________________________________________ 1 由来しているルータのRouter ID。 2 ネットワークのDesignated RouterのIPインターフェース・アドレス。 3 送信先ネットワークのIPアドレス。 4 説明されたAS境界ルータのRouter ID。 5 送信先ネットワークのIPアドレス。
Table 16: The LSA's Link State ID.
テーブル16: LSAのリンク州のID。
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.
さらに、ものか一層の送信先ネットワークの「ホスト」ビットに設定させます。 ネットワークのために例えばASの外部のLSAを溯源する、10.0、.0、.0、255.0のマスクで、.0、.0Link州IDが範囲に何にでも位置できる、10.0、.0、.0、10.255、.255、.255、包括的である、(10.0である、.0、可能であるときはいつも、.0が使用されるべきである、) あるホストビットを設定する自由で、ルータは同じアドレスにもかかわらず、異なったマスクを持っている2つのネットワークのために別々のLSAsを溯源できます。 詳細に関してAppendix Eを見てください。
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.
LSAがネットワークについて説明しているとき(LSは=2、3または5をタイプします)、ネットワークのIPアドレスは、ネットワーク/サブネットマスクがLSAのボディーに含まれている状態でLink州IDにマスクをかけることによって、容易に引き出されます。 LSAがルータについて説明しているとき(LSは=1か4をタイプします)、Link州IDはいつも説明されたルータの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).
ASの外部のLSA(LS Type=5)がデフォルトルートを説明しているとき、Link州IDがDefaultDestinationに設定される、(0.0 .0 .0)。
12.1.5. Advertising Router
12.1.5. 広告ルータ
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
この分野はLSAの創始者のOSPF Router IDを指定します。 ルータ-LSAsに関しては、この分野はLink州ID分野と同じです。 ネットワーク-LSAsは溯源されます。
Moy Standards Track [Page 119] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[119ページ]RFC2328OSPFバージョン1998年4月2日
network's Designated Router. Summary-LSAs originated by
area border routers. AS-external-LSAs are originated by AS
boundary routers.
ネットワークのDesignated Router。 概要-LSAsは境界ルータで由来しました。 ASの外部のLSAsはAS境界ルータによって溯源されます。
12.1.6. LS sequence number
12.1.6. LS一連番号
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.
一連番号分野はサインされた32ビットの整数です。 それは、古い、そして、写しLSAsを検出するのに使用されます。 一連番号のスペースは直線的に命令されます。 一連番号が大きければ(サインされた32ビットの整数として比べると)大きいほど、LSAは、より最近です。 一連番号スペースに以上について説明するには、正確に、Nに定数への以下の議論で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.
一連番号-N(0×80000000)は、予約されるのと(未使用。)です。 これは最も小さくて(したがって、最も古い)の一連番号として-n+1(0×80000001)を残します。 この一連番号は一定のInitialSequenceNumberと呼ばれます。 初めてどんなLSAも溯源するとき、ルータはInitialSequenceNumberを使用します。 その後、ルータがLSAの新しい例を溯源するたびにLSAの一連番号は増加されています。 N--1(0x7fffffff; また、MaxSequenceNumberと呼ばれる)の最大値を超えて一連番号を増加するのを試みをするとき、最初に、経路ドメインからLSAの現在の例を洗い流さなければなりません。 早まってまでにLSA(セクション14.1を見る)の年をとって、それを「再-あふれ」させながら、これをします。 この洪水がすべての隣接している隣人によって承認されるとすぐに、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.
氾濫の過程の間不意にLSAの、より最近の例を受け取るとき、ルータはやむを得ずLSAsの1つの一連番号を促進するかもしれません。 これはめったにない事件であるべきです。 これがそれを示すかもしれない、アウト、-日付では、最後の再開/再ロードの前にルータ自体によって溯源されたLSAはAutonomous Systemにまだ存在しています。 詳しい情報に関しては、セクション13.4を見てください。
Moy Standards Track [Page 120] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[120ページ]RFC2328OSPFバージョン1998年4月2日
12.1.7. LS checksum
12.1.7. LSチェックサム
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.
LS時代分野を除いて、この分野はLSAの完全なコンテンツのチェックサムです。 LS時代分野は、チェックサムをアップデートしないでLSAの時代を増加できるように除外されています。 使用されるチェックサムはISOのコネクションレスなデータグラムにおいて、使用された同じくらいです。 それは一般的にフレッチャーチェックサムと呼ばれます。 それは[Ref6]のAnnex Bに記録されます。 また、LSAヘッダーはバイトで表現されるLSAの長さを含んでいます。 LS時代分野(2バイト)のサイズを引き算すると、データ量はチェックサムに譲られます。
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.
チェックサムは、LSAのデータの汚染を検出するのに使用されます。 LSAが水につかっている状態である、またはそれがルータのメモリに保持されている間、この不正は起こることができます。 LSチェックサム分野はゼロの値を呈することができません。 そのような価値の発生はチェックサム失敗であると考えられるべきです。 言い換えれば、チェックサムの計算は任意ではありません。
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.
LSAのチェックサムは2つの場合で確かめられます: a) 時にはリンク州のデータベースの年をとる間Link州Update Packetとb)にそれを受け取るとき。 チェックサム失敗の検出はその都度別々の動きにつながります。 その他の詳細に関してセクション13と14を見てください。
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.
LS一連番号分野が、LSAの2つの例が同じであることを示すときはいつも、LSチェックサム分野は調べられます。 違いがあれば、より大きいLSチェックサムがある例は最新の.[13]であると考えられます。その他の詳細に関してセクション13.1を考えてください。
12.2. The link state database
12.2. リンク州のデータベース
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
それぞれの個々の領域のためのデータベースは別々にいつも対処されています。 最短パス計算は別々に各領域に実行されます(セクション16を見てください)。 コンポーネント
Moy Standards Track [Page 121] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[121ページ]RFC2328OSPFバージョン1998年4月2日
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.
領域リンク州のデータベースは領域だけ中で水につかっています。 隣接番組(Area Aに属す)が持って来られているとき、最終的に、Area Aのためのデータベースだけが2つのルータの間で同期します。
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).
領域データベースはルータ-LSAs、ネットワーク-LSAs、および概要-LSAsで構成されます(すべてが領域データ構造で記載しました)。 さらに、外部経路(ASの外部のLSAs)はすべての非スタッブ領域データベースに含まれています(セクション3.6を見てください)。
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.
OSPFの実現は領域データベースの個体にアクセスできなければなりません。 このルックアップ機能はLSAのLSタイプに基づいていて、Link州IDとそこのAdvertising Router.[14]はデータベースのそれぞれのLSAのただ一つの例になるでしょう(最も最新の)。 データベースルックアップ機能はLSA氾濫手順(セクション13)と経路指定テーブル計算(セクション16)の間、呼び出されます。 さらに、それにそれ自体がいるか否かに関係なく、ルータが決定できるこのルックアップ機能を使用するのは、特定のLSAを溯源して、そうだとすれば、どんなLS一連番号でそうしたか。
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).
氾濫の過程(セクション13)の間、a) それを受け取るか、またはルータ(セクション12.4)自体でb) それを溯源するとき、ルータのデータベースにLSAを追加します。 LSAはa) それが氾濫の過程(セクション13)の間、より新しい例によって上書きされるか、またはb) ルータが外でc) 自己によって溯源されたLSAs(セクション12.4)かLSA時代の1つの、より新しい例を溯源するとき、ルータのデータベースから削除されて、経路ドメイン(セクション14)から洗い流されます。 また、LSAがデータベースから削除されるときはいつも、すべての隣人のLink州の「再-トランスミッション」リストからそれを取り除かなければなりません(セクション10を見てください)。
12.3. Representation of TOS
12.3. 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
OSPF仕様([Ref9])の旧バージョンとの後方の互換性において、ルータ-LSAs、概要-LSAs、およびASの外部のLSAsにTOS-特殊情報を含むことができます。 OSPF LSAsでのTOSのコード化はTable17で指定されます。 そのテーブルはパケットのヘッダーのTOS分野([Ref12]では、定義される)をIPにコード化するOSPFを関係づけます。 OSPFコード化は小数として言い表されます。
Moy Standards Track [Page 122] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[122ページ]RFC2328OSPFバージョン1998年4月2日
integer, and the IP packet header's TOS field is expressed in
the binary TOS values used in [Ref12].
整数、および分野が言い表される2進のTOS値が[Ref12]で使用したIPパケットのヘッダーのTOS。
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
RFC1349TOS値をコード化するOSPF___________________________________________ 0000年の0の通常のサービス、2、0001、貨幣原価を最小にしてください、4、0010、信頼性6の0011を最大にしてください、0100が最大にする8、スループット10 0101 12 0110 14 0111 16 1000は遅れ18 1001 20 1010 22 1011 24 1100 26 1101 28 1110 30 1111を最小にします。
Table 17: Representing TOS in OSPF.
テーブル17: OSPFにTOSを表します。
12.4. Originating LSAs
12.4. 由来している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.
どんな与えられたOSPF領域にも、ルータは数個のLSAsを溯源するでしょう。 各ルータはルータ-LSAを溯源します。 また、ルータが領域のネットワークのどれかのDesignated Routerであるなら、それはそれらのネットワークのためにネットワーク-LSAsを溯源するでしょう。
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.
境界ルータはそれぞれの知られている相互領域の目的地に独身の概要-LSAを溯源します。 AS境界ルータはそれぞれの知られているAS外部の目的地に独身のAS外部のLSAを溯源します。 一度に一つ、ルートの全体の収集を「再-あふれ」させないでどんなただ一つのルートの変化もあふれさせることができるように目的地の広告を出します。 氾濫手順の間、単一のLink州Updateパケットは多くのLSAsを運ぶことができます。
Moy Standards Track [Page 123] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[123ページ]RFC2328OSPFバージョン1998年4月2日
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.
例と、図6でRouter RT4を考えてください。 Area1と接続の背骨を持っていて、それは境界ルータです。 ルータRT4は背骨(1ルータ-LSA、およびそれぞれのネットワークのための1概要-LSA N1-N4)に5異なったLSAsを溯源します。 また、ルータRT4はArea1(図7の描写されるとしての1ルータ-LSAと7概要-LSAs)に8異なったLSAsを溯源するでしょう。 また、RT4がNetwork N3のためのDesignated Routerとして選定されたなら、それはN3のためにネットワーク-LSAをArea1に溯源するでしょう。
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 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.
この同じ図では、Router RT5は3由来している異なったAS外部のLSAsになるでしょう(それぞれのネットワークN12-N14のためのもの)。 領域のいずれもスタッブとして構成されていないと仮定すると、これらは全体のAS中で水につかるでしょう。 しかしながら、領域3がスタッブ領域として構成されたなら、ネットワークのためのASの外部のLSAs N12-N14は領域3へあふれないでしょう(セクション3.6を見てください)。 代わりに、Router RT11は領域3中で水につかっているデフォルト概要LSAを溯源するでしょう(セクション12.4.3を見てください)。 これは、それらのAS域外交通をRT11に送るよう領域3の内部のルータのすべてに命令します。
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.
LSAの新しい例が溯源されるときはいつも、LS一連番号が増加されていて、LS時代が0に設定されて、LSチェックサムが計算されていて、LSAはリンク州のデータベースに追加されて、適切なインタフェースを水浸しにしました。 詳細に関してLSAのインストールに関してリンク州のデータベースにセクション13.2を見てください。 詳細に関して新たに溯源されたLSAsの氾濫に関してセクション13.3を見てください。
The ten events that can cause a new instance of an LSA to be
originated are:
LSAの新しい例を溯源できる10回の出来事は以下の通りです。
(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) ルータの自己によって溯源されたLSAsの1つのLS時代分野は値のLSRefreshTimeに達します。 この場合、LSAの新しい例は溯源されます、LSA(LSAヘッダーは別として)のコンテンツが同じになるでしょうが。 これはすべてのLSAsの周期的な創作を保証します。 LSAsのこの周期的なアップデートはリンク州のアルゴリズムに丈夫さを追加します。 唯一手の届かない目的地について説明するLSAsをリフレッシュするべきではありませんが、代わりに経路ドメインから洗い流すべきです(セクション14.1を見てください)。
Moy Standards Track [Page 124] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[124ページ]RFC2328OSPFバージョン1998年4月2日
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:
説明されていることなら何でもLSAで変化するとき、新しいLSAは溯源されます。 しかしながら、同じLSAの2つの例は期間のMinLSInterval中に溯源されないかもしれません。 これは、次の例の世代がMinLSIntervalまで延着するのを必要とするかもしれません。 以下の出来事で、LSAのコンテンツは変化するかもしれません。 そして、これらの出来事が新しい創作を引き起こすべきである、新しい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.
(2) インタフェースの状態は変化します(セクション9.1を見てください)。 これは、ルータ-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) 付属ネットワークのDesignated Routerは変化します。 新しいルータ-LSAは溯源されるべきです。 また、現在ルータ自体がDesignated Routerであるなら、新しいネットワーク-LSAは生産されるべきです。 ルータ自体がもうDesignated Routerでないなら、それがネットワークのために溯源したどんなネットワーク-LSAも経路ドメインから洗い流されるべきです(セクション14.1を見てください)。
(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) 隣接しているルータの1つはFULL状態からの/に変化します。 これは、ルータ-LSAの新しい例を生産するのが必要であることを意味するかもしれません。 また、ルータがそれ自体で付属ネットワークのためのDesignated Routerであるなら、新しいネットワーク-LSAは生産されるべきです。
The next four events concern area border routers only:
次の4回の出来事が境界ルータだけに関係があります:
(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) イントラ領域ルートは、経路指定テーブルで加えられるか、削除される、または変更されました。 これで、それぞれの付属領域で概要LSA(このルートへの)の新しい例を溯源するかもしれません(ことによると背骨を含んでいて)。
(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) 相互領域ルートは、経路指定テーブルで加えられるか、削除される、または変更されました。 これで、それぞれの付属領域(しかし、決していずれの背骨のためにも、そうしない)で概要LSA(このルートへの)の新しい例を溯源するかもしれません。
Moy Standards Track [Page 125] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[125ページ]RFC2328OSPFバージョン1998年4月2日
(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) ルータは新たに領域に付けられるようになります。 ルータは溯源しなければならなくて、次に、ルータの経路指定テーブルのすべての適切なイントラ領域と相互領域ルートのために新たに添付の領域に概要-LSAsを溯源してください。 その他の詳細に関してセクション12.4.3を見てください。
(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) ルータの構成された仮想のリンクの1つの状態が変化するとき、新しいルータ-LSAを背骨に溯源することと同様に仮想のリンクのTransit領域に新しいルータ-LSAを溯源するのが必要であるかもしれません(セクション12.4.1における、ルータ-LSAビットVの議論を見てください)。
The last two events concern AS boundary routers (and former AS
boundary routers) only:
最後の2回の出来事がAS境界ルータ(そして、前のAS境界ルータ)だけに関係があります:
(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) 外部のルーティング・プロトコル(BGPのような)の直接の経験で獲得された外部経路は変化します。 これで、AS境界ルータはASの外部の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) ルータは、恐らく再開した後に、AS境界ルータであることをやめます。 この状況で、ルータはそれが以前に溯源したすべてのASの外部のLSAsを洗い流すべきです。 セクション14.1で指定された時期尚早な古い手順でこれらのLSAsを洗い流すことができます。
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.
LSAのそれぞれのタイプの工事は以下で詳細に説明されます。 一般に、これらのセクションはLSAボディー(すなわち、20バイトのLSAヘッダーに続く部分)のコンテンツについて説明します。 LSAヘッダーのビルの情報に関しては、セクション12.1を見てください。
12.4.1. Router-LSAs
12.4.1. ルータ-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.
ルータはそれが属す各領域にルータ-LSAを溯源します。 そのようなLSAはその領域へのルータのリンクの集まっている州について説明します。 LSAは特定の領域に、これ以上水につかっています。
Moy Standards Track [Page 126] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[126ページ]RFC2328OSPFバージョン1998年4月2日
....................................
. 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 領域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
図15: 示されるIPアドレスでの領域1
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.
ルータ-LSAの書式はAppendix A(セクションA.4.2)に示されます。 LSAの最初の20バイトはセクション12.1で議論したジェネリックLSAヘッダーから成ります。ルータ-LSAsはLSに=1をタイプさせます。
A router also indicates whether it is an area border router,
or an AS boundary router, by setting the appropriate bits
(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 area. Bit E
should never be set in a router-LSA for a stub area (stub
areas cannot contain AS boundary routers).
また、ルータは、それが境界ルータ、またはAS境界ルータであるかを示します、ルータ-LSAsに適切なビット(それぞれビットBとビットE)を設定することによって。 これは、ルータのそういったタイプの人への経路が経路指定テーブルで保存されるのを可能にします、概要-LSAsとASの外部のLSAsの後の処理のために。 ルータが活発に2つ以上の領域に付けられているときはいつも、ビットBは設定されるべきです、ルータが現在OSPFバックボーン領域に付けられないでも。 ビットEはスタッブ領域へのルータ-LSAに決して設定されるべきではありません(スタッブ領域はAS境界ルータを含むことができません)。
Moy Standards Track [Page 127] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[127ページ]RFC2328OSPFバージョン1998年4月2日
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).
さらに、ルータがArea Aのためにルータ-LSAにビットVをはめ込む、ルータである場合にだけ、それらのTransit領域としてArea Aを持っている1個以上の完全に隣接している仮想のリンクの終点はそうです。 ビットVの設定は、Area Aの他のルータが、領域が、トランジットがトラフィックであるとサポートするかどうか(セクション6でTransitCapabilityを見てください)発見するのを可能にします。
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.
そして、ルータ-LSAはルータの働く接続(すなわち、インタフェースかリンク)についてその領域に説明します。 付属ネットワークの種類に従って、各リンクはタイプされます。 また、各リンクはLink IDでラベルされます。 このLink IDはリンクのもう一方の端にある実体に名前を付けます。 テーブル18はTypeとLink 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
リンク型記述Link ID__________________________________________________ 1 二地点間Neighbor Router IDは3LinkがInterfaceがIPネットワーク・ナンバーネットワーク4VirtualリンクNeighbor Router IDを引き抜くためにネットワークDesignated Routerを扱うトランジットに2Linkをリンクします。
Table 18: Link descriptions in the
router-LSA.
テーブル18: ルータ-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.
さらに、Link Data分野は各リンクに指定されます。 この分野はリンクのための32ビットのその他の情報を与えます。 輸送網へのリンク、番号付のポイントツーポイント接続、および仮想のリンクとして、この分野は関連ルータインタフェースのIPインターフェース・アドレスを指定します(これが経路指定テーブル計算で必要です、とセクション16.1.1は見ます)。 リンクがネットワークを引き抜くように、この分野はスタッブネットワークのIPアドレスマスクを指定します。 無数のポイントツーポイント接続において、Link Data分野は無数のインタフェースのMIB-II[Ref8]ifIndex価値に設定されるべきです。
Moy Standards Track [Page 128] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[128ページ]RFC2328OSPFバージョン1998年4月2日
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:
さらにルータであるならリンク記述のリストを造るプロセスについて説明するために、ルータが収集を調べるArea A.のためにルータ-LSAを造るという願望はデータ構造を連結します。 各インタフェースにおいて、以下の方法を取ります:
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 付属ネットワークがArea Aに属さないなら、リンクは全くLSAに加えられません、そして、次のインタフェースは調べられるべきです。
o If the state of the interface is Down, no links are
added.
o インタフェースの状態がDownであるなら、リンクは全く加えられません。
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 インタフェースの状態がLoopbackであるなら、これが無数の二地点間ネットワークへのインタフェースでない限り、Type3リンク(スタッブネットワーク)を加えてください。 Link IDはIPインターフェース・アドレスに設定されるべきでした、そして、Link Dataはマスク0xffffffffにセットしました、そして、(ホストルートを示して)費用は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 さもなければ、ルータ-LSAに加えられたリンク記述はOSPFインターフェース型に頼っています。 記述をリンクしてください、二地点間インタフェースに使用されて、放送してください。そうすれば、NBMAが中のように連結するので指定されたコネセクション12.4.1が仮想のリンクコネセクション12.4.1.2のための.1である、12.4、.1、.3、中のPointからMultiPointへのインタフェース、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).
すべてのルータの考慮が連結した後にホストリンクは、Area A.に属す付属ホストのリストを調べることによって、ルータ-LSAに加えられます。Type3がLink IDがホストのIPアドレス、Link Dataがすべてのもの(0xffffffff)のマスクであるということである(スタッブネットワーク)をリンクして、ホストの構成された費用かかるとき(セクションC.7を見てください)、Aホストルートは表されます。
Moy Standards Track [Page 129] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[129ページ]RFC2328OSPFバージョン1998年4月2日
12.4.1.1. Describing point-to-point interfaces
12.4.1.1. 二地点間インタフェースについて説明します。
For point-to-point interfaces, one or more link
descriptions are added to the router-LSA as follows:
二地点間インタフェースに関しては、1つ以上のリンク記述が以下のルータ-LSAに加えられます:
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 隣接しているルータが完全に隣接しているなら、Type1リンク(ポイントツーポイント)を加えてください。 Link IDは隣接しているルータのRouter IDに設定されるべきです。 番号付の二地点間ネットワークとして、Link DataはIPインターフェース・アドレスを指定するはずです。 無数の二地点間ネットワークとして、Link Data分野はインタフェースのMIB-II[Ref8]ifIndex価値を指定するべきです。 費用は二地点間インタフェースの製作費に設定されるべきです。
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 さらに、インタフェースの状態が「二地点間である」(そして隣接しているルータ状態にかかわらず)限り、Type3リンク(スタッブネットワーク)は加えられるべきです。 このスタッブリンクが取ることができる2つの形があります:
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]
隣接しているルータのIPアドレスがそうであるオプション1Assumingが知られていて、隣人のIPアドレス、マスク0xffffffff(ホストルートを示す)へのLink Data、およびインタフェースの構成された製作費への費用にType3リンクのLink IDを設定してください。[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]
サブネットが割り当てられたオプション2Ifはポイントからポイントまでリンクして、セットはサブネットのIPアドレスへのType3リンクのLink IDです、サブネットのマスクへのLink Data、そして、費用が製作費をインタフェースのものまで構成しました。[16]
12.4.1.2. Describing broadcast and NBMA interfaces
12.4.1.2. 放送とNBMAインタフェースについて説明します。
For operational broadcast and NBMA interfaces, a single
link description is added to the router-LSA as follows:
操作上の放送とNBMAインタフェースに関しては、ただ一つのリンク記述は以下のルータ-LSAに加えられます:
Moy Standards Track [Page 130] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[130ページ]RFC2328OSPFバージョン1998年4月2日
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 インタフェースの状態がWaitingであるなら、Link IDとのType3リンク(スタッブネットワーク)が付属ネットワーク、付属ネットワークのアドレスマスクに用意ができているLink Data、およびインタフェースの構成された製作費と等しい費用のIPネットワーク・ナンバーにセットしたと言い足してください。
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 ほかに、付属ネットワークのために選出されたDesignated Routerがありました。 Designated Router、ルータ自体がDesignated Routerに隣接した完全にDesignated Routerであるならルータが他の少なくとも1つのルータに隣接して完全にそうなら、Link IDとの独身のType2リンク(トランジットネットワーク)が付属ネットワークのDesignated Router(ルータ自体であるかもしれない)、ルータの自己のIPインターフェース・アドレスに用意ができているLink Data、およびインタフェースの構成された製作費と等しい費用のIPインターフェース・アドレスにセットしたと言い足してください。 さもなければ、まるで界面準位がWaitingであるかのようにリンクを加えてください(上を見てください)。
12.4.1.3. Describing virtual links
12.4.1.3. 仮想のリンクについて説明します。
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).
仮想の隣人が完全に隣接しているときだけ、仮想のリンクに関しては、リンク記述はルータ-LSAに加えられます。 この場合、仮想の隣人のRouter IDに設定されたLink ID、仮想のリンクに関連しているIPインターフェース・アドレスに用意ができているLink Data、および経路指定テーブル計算の間に仮想のリンクに計算された費用に設定された費用とのType4リンク(仮想のリンク)を加えてください(セクション15を見てください)。
12.4.1.4. Describing Point-to-MultiPoint interfaces
12.4.1.4. PointからMultiPointへのインタフェースについて説明します。
For operational Point-to-MultiPoint interfaces, one or
more link descriptions are added to the router-LSA as
follows:
PointからMultiPointへの操作上のインタフェースに関しては、1つ以上のリンク記述が以下のルータ-LSAに加えられます:
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 独身のType3リンク(スタッブネットワーク)はルータの自己のIPインターフェース・アドレスに設定されたLink IDと共に加えられました、そして、Link Dataはマスク0xffffffffにセットしました、そして、(ホストルートを示して)費用は0にセットしました。
Moy Standards Track [Page 131] RFC 2328 OSPF Version 2 April 1998
Moy標準化過程[131ページ]RFC2328OSPFバージョン1998年4月2日
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 インタフェースに関連しているそれぞれの完全に隣接している隣人に関しては、Link IDとの追加Type1リンク(ポイントからポイント)が隣接しているルータ(インタフェースの構成された製作費と等しいIPインターフェース・アドレスと費用に用意ができているLink Data)のRouter IDにセットしたと言い足してください。
12.4.1.5. Examples of router-LSAs
12.4.1.5. ルータ-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.
図に描写されるようにRouter RT3によって生成されたルータ-LSAs6を考えてください。 Router RT3(領域1)を含む領域は実際のネットワーク・アドレスが図15にあるredrawnです。 RT3のインターフェース・アドレスのすべての最後のバイトが3であると仮定してください、インタフェースアドレス192.1.1.3と192.1をそれに与えて。.4 .3 そして、もう片方のルータには、同様のアドレシング体系があります。 さらに、すべてのリンクが機能的であり、Router IDが最も小さいIPインターフェース・アドレスとして割り当てられると仮定してください。
一覧
スポンサーリンク
