[要約] RFC 2328はOSPF Version 2の仕様を定義しており、OSPFはリンクステートルーティングプロトコルであり、大規模なネットワークでの経路選択を効率的に行うために使用されます。
Network Working Group J. Moy
Request for Comments: 2328 Ascend Communications, Inc.
STD: 54 April 1998
Obsoletes: 2178
Category: Standards Track
OSPF Version 2
OSPFバージョン2
Status of this 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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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はリンクステートルーティングプロトコルです。単一の自律システムの内部で実行されるように設計されています。各OSPFルーターは、自律システムのトポロジーを記述する同一のデータベースを維持します。このデータベースから、最短経路ツリーを構築することによってルーティングテーブルが計算されます。
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は、最小限のルーティングプロトコルトラフィックを使用して、トポロジの変更に直面してルートをすばやく再計算します。 OSPFは、等コストマルチパスをサポートします。エリアルーティング機能が提供され、追加レベルのルーティング保護とルーティングプロトコルトラフィックの削減が可能になります。さらに、すべてのOSPFルーティングプロトコル交換が認証されます。
The differences between this memo and RFC 2178 are explained in Appendix G. All differences are backward-compatible in nature.
このメモとRFC 2178の違いについては、付録Gで説明しています。すべての違いは、本質的に下位互換性があります。
Implementations of this memo and of RFCs 2178, 1583, and 1247 will interoperate.
このメモとRFC 2178、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
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
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
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
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.
このドキュメントは、Open Shortest Path First（OSPF）TCP / IPインターネットルーティングプロトコルの仕様です。 OSPFは、Interior Gateway Protocol（IGP）として分類されます。つまり、単一の自律システムに属するルーター間でルーティング情報を配信します。 OSPFプロトコルは、リンクステートまたはSPFテクノロジーに基づいています。これは、従来のTCP / IPインターネットルーティングプロトコルで使用されているBellman-Fordベースからの脱却です。
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ワーキンググループによって開発されました。 CIDRの明示的なサポートや外部から取得したルーティング情報のタグ付けなど、TCP / IPインターネット環境向けに特別に設計されています。 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パケットは「現状のまま」ルーティングされます-自律システムを通過するため、以降のプロトコルヘッダーにはカプセル化されません。 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.
リンクステートルーティングプロトコルでは、各ルーターは自律システムのトポロジを説明するデータベースを維持します。このデータベースは、リンク状態データベースと呼ばれます。参加している各ルーターは同一のデータベースを持っています。このデータベースの個々の部分は、特定のルーターのローカル状態（ルーターの使用可能なインターフェイスや到達可能なネイバーなど）です。ルーターは、フラッディングによって自律システム全体にローカル状態を分散します。
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.
すべてのルーターは、まったく同じアルゴリズムを並行して実行します。リンクステートデータベースから、各ルータは自身をルートとして最短パスのツリーを構築します。この最短パスツリーは、自律システム内の各宛先へのルートを提供します。外部から導出されたルーティング情報は、ツリー上に葉として表示されます。
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.
宛先への等コストルートが複数存在する場合、トラフィックはそれらの間で均等に分散されます。ルートのコストは、単一の無次元メトリックによって記述されます。
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では、ネットワークのセットをグループ化できます。このようなグループ化は、エリアと呼ばれます。エリアのトポロジは、自律システムの他の部分から隠されています。この情報の非表示により、ルーティングトラフィックを大幅に削減できます。また、エリア内のルーティングは、エリア自体のトポロジによってのみ決定されるため、不正なルーティングデータからエリアを保護できます。エリアは、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つの異なるサブネットは、異なるサイズ（つまり、異なるマスク）を持つ場合があります。これは一般に、可変長サブネット化と呼ばれます。パケットは、最適な（つまり、最長または最も具体的な）一致にルーティングされます。ホストルートは、マスクが「すべて1」（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プロトコル交換が認証されます。これは、自律システムのルーティングに参加できるのは信頼できるルーターのみであることを意味します。さまざまな認証方式を使用できます。実際、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.
外部で導出されたルーティングデータ（たとえば、BGPなどの外部ゲートウェイプロトコルから学習したルート。[Ref23]を参照）は、自律システム全体でアドバタイズされます。この外部から導出されたデータは、OSPFプロトコルのリンク状態データとは別に保持されます。各外部ルートは、アドバタイズルーターによってタグ付けすることもでき、自律システムの境界にあるルーター間で追加情報を渡すことができます。
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プロトコルに特定の意味を持ち、本文中で使用される用語の定義を提供します。 IPの概要については、インターネットプロトコルスイートに慣れていない読者を[Ref13]で紹介しています。
Router A level three Internet Protocol packet switch. Formerly called a gateway in much of the IP literature.
ルーターAレベル3インターネットプロトコルパケットスイッチ。以前は多くのIP文献でゲートウェイと呼ばれていました。
Autonomous System A group of routers exchanging routing information via a common routing protocol. Abbreviated as AS.
自律システム共通のルーティングプロトコルを介してルーティング情報を交換するルーターのグループ。 ASと略されます。
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.
内部ゲートウェイプロトコル自律システムに属するルーターが話すルーティングプロトコル。 IGPと略されます。各自律システムには1つのIGPがあります。独立した自律システムが異なるIGPを実行している可能性があります。
Router ID A 32-bit number assigned to each router running the OSPF protocol. This number uniquely identifies the router within an Autonomous System.
ルーターID OSPFプロトコルを実行している各ルーターに割り当てられた32ビットの番号。この番号は、自律システム内のルーターを一意に識別します。
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.
ネットワークこのメモでは、IPネットワーク/サブネット/スーパーネット。 1つの物理ネットワークに複数のIPネットワーク/サブネット番号を割り当てることができます。これらは別個のネットワークと見なされます。ポイントツーポイントの物理ネットワークは例外です。割り当てられている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ネットワーク/サブネット/スーパーネット上に存在するIPアドレスの範囲を示す32ビットの数値。この仕様では、ネットワークマスクを16進数で表示します。
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.
たとえば、クラスC IPネットワークのネットワークマスクは0xffffff00と表示されます。このようなマスクは、文献の他の場所で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組のルーターに参加するネットワーク。 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.
ブロードキャストネットワーク多くの（3つ以上の）接続されたルーターをサポートするネットワークと、接続されたすべてのルーター（ブロードキャスト）に単一の物理メッセージを送信する機能。 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.
非ブロードキャストネットワーク多くの（3つ以上の）ルーターをサポートするが、ブロードキャスト機能を持たないネットワーク。隣接ルーターは、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つのモードのいずれかで実行されます。非ブロードキャストマルチアクセスまたはNBMAと呼ばれる最初のモードは、ブロードキャストネットワークでのOSPFの動作をシミュレートします。 2番目のモードはポイントツーマルチポイントと呼ばれ、非ブロードキャストネットワークをポイントツーポイントリンクのコレクションとして扱います。非ブロードキャストネットワークは、ネットワーク上でのOSPFの動作モードに応じて、NBMAネットワークまたはポイントツーマルチポイントネットワークと呼ばれます。
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.
隣接ルーター共通ネットワークへのインターフェースを持つ2つのルーター。隣接関係は、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.
隣接関係ルーティング情報を交換する目的で選択された隣接ルーター間で形成される関係。隣接するルーターのすべてのペアが隣接するわけではありません。
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.
リンク状態アドバタイズメントルータまたはネットワークのローカル状態を表すデータの単位。ルーターの場合、これにはルーターのインターフェースと隣接の状態が含まれます。各リンクステートアドバタイズメントは、ルーティングドメイン全体にフラッディングされます。すべてのルーターとネットワークの収集されたリンク状態アドバタイズは、プロトコルのリンク状態データベースを形成します。このメモ全体を通して、リンクステートアドバタイズメントは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.
Helloプロトコル近隣関係の確立と維持に使用されるOSPFプロトコルの一部。ブロードキャストネットワークでは、Helloプロトコルは隣接ルーターを動的に検出することもできます。
Flooding The part of the OSPF protocol that distributes and synchronizes the link-state database between OSPF routers.
フラッディングOSPFルーター間でリンク状態データベースを配布および同期するOSPFプロトコルの一部。
Designated Router Each broadcast and NBMA network that has at least two attached routers has a Designated Router. The Designated Router generates an LSA for the network and has other special responsibilities in the running of the protocol. The Designated Router is elected by the Hello Protocol.
指定ルーター少なくとも2つのルーターが接続されている各ブロードキャストおよびNBMAネットワークには、指定ルーターがあります。指定ルーターは、ネットワークのLSAを生成し、プロトコルの実行において他の特別な責任を負います。指定ルーターは、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.
指定ルーターの概念により、ブロードキャストまたは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 PDNのX.25パケットとフレームレベル、およびイーサネットのイーサネットデータリンク層です。
1.3. Brief history of link-state routing technology
1.3. リンクステートルーティングテクノロジーの簡単な歴史
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.
最初のリンクステートルーティングプロトコルは、ARPANETパケットスイッチングネットワークで使用するために開発されました。このプロトコルは[Ref3]で説明されています。他のすべてのリンクステートプロトコルの開始点を形成しています。同種のARPANET環境、つまり同期シリアル回線で接続された単一ベンダーのパケットスイッチにより、元のプロトコルの設計と実装が簡素化されました。
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]で提案されました。これらの変更は、とりわけLSAにチェックサムを追加することでルーティングプロトコルのフォールトトレランスを向上させることで対処しました（これにより、データベースの破損が検出されました）。また、リンクステートプロトコルでルーティングトラフィックのオーバーヘッドを削減する手段も含まれています。これは、LSA発信の間隔を1桁増やすことができるメカニズムを導入することによって達成されました。
A link-state algorithm has also been proposed for use as an ISO IS-IS routing protocol. This protocol is described in [Ref2]. The protocol includes methods for data and routing traffic reduction when operating over broadcast networks. This is accomplished by election of a Designated Router for each broadcast network, which then originates an LSA for the network.
リンクステートアルゴリズムも、ISO IS-ISルーティングプロトコルとして使用するために提案されています。このプロトコルは[Ref2]で説明されています。このプロトコルには、ブロードキャストネットワーク上で動作する場合のデータおよびルーティングトラフィックの削減方法が含まれています。これは、ブロードキャストネットワークごとに指定ルーターを選択することで実現され、その後、ネットワークのLSAが発信されます。
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プロトコルの開発においてこの作業を拡張しました。指定ルーターの概念が大幅に強化され、必要なルーティングトラフィックの量がさらに削減されました。マルチキャスト機能は、ルーティング帯域幅をさらに削減するために利用されます。エリアルーティングスキームが開発され、情報の非表示/保護/削減が可能になりました。最後に、アルゴリズムは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などのラベルは、プロトコル定数を参照しています。それらは構成可能かもしれませんし、できないかもしれません。アーキテクチャ定数は付録Bにまとめられています。構成可能な定数は付録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 Zhang and the rest of the OSPF Working Group for the ideas and support they have given to this project.
著者は、Ran Atkinson、Fred Baker、Jeffrey Burgan、Rob Coltun、Dino Farinacci、Vince Fuller、Phanindra Jujjavarapu、Milo Medin、Tom Pusateri、Kannan Varadhan、Zhaohui Zhang、およびその他のOSPFワーキンググループに感謝します。彼らがこのプロジェクトに与えたサポート。
The OSPF Point-to-MultiPoint interface is based on work done by Fred Baker.
OSPFポイントツーマルチポイントインターフェイスは、フレッドベイカーによって行われた作業に基づいています。
The OSPF Cryptographic Authentication option was developed by Fred Baker and Ran Atkinson.
OSPF暗号認証オプションは、Fred BakerとRan Atkinsonによって開発されました。
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.
自律システムのリンク状態データベースは、有向グラフを記述します。グラフの頂点は、ルーターとネットワークで構成されます。グラフのエッジは、物理的なポイントツーポイントネットワークを介して接続されている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、またはポイントツーマルチポイント）と、ネットワークへのインターフェースを持つルーターの数によって異なります。図1aには3つのケースが描かれています。四角形はルーターを示します。円と長方形はネットワークを示します。ルーター名には接頭辞RTが、ネットワーク名には接頭辞Nが付けられます。ルーターインターフェイス名には接頭辞Iが付けられます。ルーター間の線はポイントツーポイントネットワークを示します。図の左側は、ルーターが接続されているネットワークを示し、結果のグラフは右側に表示されます。
**FROM**
* |RT1|RT2|
+---+Ia +---+ * ------------
|RT1|------|RT2| T RT1| | X |
+---+ Ib+---+ O RT2| X | |
* Ia| | X |
* Ib| X | |
Physical point-to-point networks
物理的なポイントツーポイントネットワーク
**FROM**
+---+ *
|RT7| * |RT7| N3|
+---+ T ------------
| O 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 | |
+---+ +---+
Broadcast or NBMA networks
ブロードキャストまたはNBMAネットワーク
Figure 1a: Network map components
図1a：ネットワークマップコンポーネント
Networks and routers are represented by vertices. An edge connects Vertex A to Vertex B iff the intersection of Column A and Row B is marked with an X.
ネットワークとルーターは頂点で表されます。列Aと行Bの交点がXでマークされている場合、エッジは頂点Aを頂点Bに接続します。
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であり、これは単一ノードの存在を示します。
2.1.1. Representation of non-broadcast networks
2.1.1. 非ブロードキャストネットワークの表現
As mentioned previously, OSPF can run over non-broadcast networks in one of two modes: NBMA or Point-to-MultiPoint. The choice of mode determines the way that the Hello protocol and flooding work over the non-broadcast network, and the way that the network is represented in the link-state database.
前述のように、OSPFは非ブロードキャストネットワーク上で、NBMAまたはポイントツーマルチポイントの2つのモードのいずれかで実行できます。モードの選択により、Helloプロトコルとフラッディングが非ブロードキャストネットワーク上で機能する方法と、ネットワークがリンク状態データベースで表される方法が決まります。
In NBMA mode, OSPF emulates operation over a broadcast network: a Designated Router is elected for the NBMA network, and the Designated Router originates an LSA for the network. The graph representation for broadcast networks and NBMA networks is identical. This representation is pictured in the middle of Figure 1a.
NBMAモードでは、OSPFはブロードキャストネットワーク上で動作をエミュレートします。指定ルーターがNBMAネットワーク用に選択され、指定ルーターがネットワークの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ネットワークに接続されているすべてのルーターが直接通信できる必要があります。この制限は、SVCを利用するATMサブネットなど、一部の非ブロードキャストネットワークで満たされる場合があります。ただし、PVCのみのフレームリレーネットワークなど、他の非ブロードキャストネットワークでは満たされないことがよくあります。すべてのルーターが直接通信できるわけではない非ブロードキャストネットワークでは、非ブロードキャストネットワークを論理サブネットに分割し、各サブネットのルーターが直接通信できるようにして、NBMAネットワークとして各個別のサブネットを実行することができます（[Ref15 ]）。ただし、これにはかなりの管理オーバーヘッドが必要であり、設定ミスが発生しやすくなります。このような非ブロードキャストネットワークは、ポイントツーマルチポイントモードで実行することをお勧めします。
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.
ポイントツーマルチポイントモードでは、OSPFは非ブロードキャストネットワーク上のすべてのルーター間接続をポイントツーポイントリンクであるかのように扱います。ネットワークに指定ルーターは選出されず、ネットワークにLSAが生成されません。実際、ポイントツーマルチポイントネットワークの頂点は、リンクステートデータベースのグラフには表示されません。
Figure 1b illustrates the link-state database representation of a Point-to-MultiPoint network. On the left side of the figure, a Point-to-MultiPoint network is pictured. It is assumed that all routers can communicate directly, except for routers RT4 and RT5. I3 though I6 indicate the routers' IP interface addresses on the Point-to-MultiPoint network. In the graphical representation of the link-state database, routers that can communicate directly over the Point-to-MultiPoint network are joined by bidirectional edges, and each router also has a stub connection to its own IP interface address (which is in contrast to the representation of real point-to-point links; see Figure 1a).
図1bは、ポイントツーマルチポイントネットワークのリンク状態データベース表現を示しています。図の左側に、ポイントツーマルチポイントネットワークが示されています。ルーターRT4とRT5を除いて、すべてのルーターが直接通信できると想定されています。 I3からI6は、ポイントツーマルチポイントネットワーク上のルーターのIPインターフェイスアドレスを示します。リンクステートデータベースのグラフィック表現では、ポイントツーマルチポイントネットワークを介して直接通信できるルーターが双方向エッジで結合され、各ルーターは独自の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]を参照）などのデータリンクプロトコルを使用すると、ブロードキャストサポートが利用できない場合でも、OSPFネイバーの自動検出が可能になります。
**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 |
Figure 1b: Network map components Point-to-MultiPoint networks
図1b：ネットワークマップコンポーネントポイントツーマルチポイントネットワーク
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インターフェース・アドレスを示します
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は、自律システムのサンプルマップを示しています。 H1というラベルの長方形は、ルーターRT12へのSLIP接続を持つホストを示します。したがって、ルーターRT12はホストルートをアドバタイズしています。ルーター間の線は、物理的なポイントツーポイントネットワークを示します。インターフェイスアドレスが割り当てられている唯一のポイントツーポイントネットワークは、ルータRT6およびRT10に参加しているネットワークです。ルータRT5およびRT7は、他の自律システムへのBGP接続を備えています。これらのルーターの両方について、BGPで学習されたルートのセットが表示されています。
A cost is associated with the output side of each router interface. This cost is configurable by the system administrator. The lower the cost, the more likely the interface is to be used to forward data traffic. Costs are also associated with the externally derived routing data (e.g., the BGP-learned routes).
コストは、各ルータインターフェイスの出力側に関連付けられています。このコストは、システム管理者が構成できます。コストが低いほど、データトラフィックの転送にインターフェイスが使用される可能性が高くなります。コストは、外部から取得されたルーティングデータ（BGPで学習されたルートなど）にも関連付けられています。
The directed graph resulting from the map in Figure 2 is depicted in Figure 3. Arcs are labelled with the cost of the corresponding router output interface. Arcs having no labelled cost have a cost of 0. Note that arcs leading from networks to routers always have cost 0; they are significant nonetheless. Note also that the externally derived routing data appears on the graph as stubs.
図2のマップから得られる有向グラフを図3に示します。アークには、対応するルーター出力インターフェイスのコストがラベル付けされています。ラベル付きコストのないアークのコストは0です。ネットワークからルーターにつながるアークのコストは常に0であることに注意してください。それでも重要です。また、外部から導出されたルーティングデータがスタブとしてグラフに表示されることにも注意してください。
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.
リンク状態データベースは、ルーターによって生成されたLSAから結合されます。関連するグラフィック表現では、各ルーターまたはトランジットネットワークの近傍が単一の個別のLSAで表されます。図4は、これらのLSAを図で示しています。ルータRT12には、2つのブロードキャストネットワークへのインターフェイスと、ホストへのSLIPラインがあります。ネットワークN6は、3つのルーターが接続されたブロードキャストネットワークです。ネットワークN6から接続されたルーターへのすべてのリンクのコストは0です。ネットワークN6のLSAは、ネットワークの接続されたルーターの1つ、つまりネットワークの指定ルーターとして選択されたルーターによって実際に生成されることに注意してください。
+
| 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
Figure 2: A sample Autonomous System
図2：サンプル自律システム
**FROM**
|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|
|1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9|
----- ---------------------------------------------
RT1| | | | | | | | | | | | |0 | | | |
RT2| | | | | | | | | | | | |0 | | | |
RT3| | | | | |6 | | | | | | |0 | | | |
RT4| | | | |8 | | | | | | | |0 | | | |
RT5| | | |8 | |6 |6 | | | | | | | | | |
RT6| | |8 | |7 | | | | |5 | | | | | | |
RT7| | | | |6 | | | | | | | | |0 | | |
* RT8| | | | | | | | | | | | | |0 | | |
* RT9| | | | | | | | | | | | | | | |0 |
T RT10| | | | | |7 | | | | | | | |0 |0 | |
O RT11| | | | | | | | | | | | | | |0 |0 |
* RT12| | | | | | | | | | | | | | | |0 |
* N1|3 | | | | | | | | | | | | | | | |
N2| |3 | | | | | | | | | | | | | | |
N3|1 |1 |1 |1 | | | | | | | | | | | | |
N4| | |2 | | | | | | | | | | | | | |
N6| | | | | | |1 |1 | |1 | | | | | | |
N7| | | | | | | |4 | | | | | | | | |
N8| | | | | | | | | |3 |2 | | | | | |
N9| | | | | | | | |1 | |1 |1 | | | | |
N10| | | | | | | | | | | |2 | | | | |
N11| | | | | | | | |3 | | | | | | | |
N12| | | | |8 | |2 | | | | | | | | | |
N13| | | | |8 | | | | | | | | | | | |
N14| | | | |8 | | | | | | | | | | | |
N15| | | | | | |9 | | | | | | | | | |
H1| | | | | | | | | | | |10| | | | |
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のエッジは、列Aと行Bの交点がXでマークされている場合、頂点Aを頂点Bに接続します。
**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
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のエッジは、列Aと行Bの交点がXでマークされている場合、頂点Aを頂点Bに接続します。
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エリアが構成されていない場合、自律システム内の各ルーターは同一のリンク状態データベースを持ち、同一のグラフィック表現になります。ルーターは、ルーター自体をルートとして最短パスのツリーを計算することにより、このグラフからルーティングテーブルを生成します。明らかに、最短パスツリーは、計算を行うルーターに依存します。この例のルーター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).
ツリーは、宛先ネットワークまたはホストへの完全なパスを提供します。ただし、転送プロセスでは、宛先へのネクストホップのみが使用されます。また、ルーターへの最適なルートも計算されていることに注意してください。外部データの処理については、外部ルートをアドバタイズするルーターへのネクストホップと距離に注意します。結果として得られるルーターRT6のルーティングテーブルを表2に示します。番号付きポイントツーポイントネットワーク（この場合は、ルーター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（N12など）に属するネットワークへのルートは、図5の最短パスツリーに破線で表示されます。
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
Figure 5: The SPF tree for Router RT6
図5：ルーター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
コストのマークが付いていないエッジのコストはゼロです（これらはネットワークからルーターへのリンクです）。ネットワークN12〜N15へのルートは、セクション2.3で検討される外部情報です。
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
Table 2: The portion of Router RT6's routing table listing local destinations.
表2：ルーター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などの別のルーティングプロトコルから発信されたり、静的に構成されたりする可能性があります（静的ルート）。デフォルトルートは、自律システムの外部ルーティング情報の一部として含めることもできます。
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全体にフラッディングされます。この例では、自律システム内のすべてのルーターは、ルーターRT7にメトリック2および9の2つの外部ルートがあることを認識しています。
OSPF supports two types of external metrics. Type 1 external metrics are expressed in the same units as OSPF interface cost (i.e., in terms of the link state metric). Type 2 external metrics are an order of magnitude larger; any Type 2 metric is considered greater than the cost of any path internal to the AS. Use of Type 2 external metrics assumes that routing between AS'es is the major cost of routing a packet, and eliminates the need for conversion of external costs to internal link state metrics.
OSPFは2種類の外部メトリックをサポートしています。タイプ1の外部メトリックは、OSPFインターフェースコストと同じ単位で表されます（つまり、リンク状態メトリックに関して）。タイプ2の外部メトリックは桁違いに大きくなります。タイプ2メトリックは、AS内部のパスのコストよりも大きいと見なされます。タイプ2の外部メトリックの使用は、AS間のルーティングがパケットのルーティングの主要なコストであると想定し、外部コストを内部リンク状態メトリックに変換する必要をなくします。
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.
タイプ1の外部メトリック処理の例として、図2のルーターRT7とRT5がタイプ1の外部メトリックをアドバタイズしているとします。アドバタイズされた外部ルートごとに、ルーターRT6からの合計コストは、外部ルートのアドバタイズされたコストとルーター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では、ルーターRT5とRT7の両方が、宛先ネットワークN12への外部ルートを通知しています。ルーターRT7は、ルーターRT6から10（8 + 2）の距離でN12をアドバタイズしているため、ルーターRT5の14（6 + 8）よりも優れています。表3は、外部ルートが検査されるときにルーティングテーブルに追加されるエントリを示しています。
Destination Next Hop Distance
__________________________________
N12 RT10 10
N13 RT5 14
N14 RT5 14
N15 RT10 17
Table 3: The portion of Router RT6's routing table listing external destinations.
表3：外部宛先をリストするルーターRT6のルーティングテーブルの部分。
Processing of Type 2 external metrics is simpler. The AS boundary router advertising the smallest external metric is chosen, regardless of the internal distance to the AS boundary router. Suppose in our example both Router RT5 and Router RT7 were advertising Type 2 external routes. Then all traffic destined for Network N12 would be forwarded to Router RT7, since 2 < 8. When several equal-cost Type 2 routes exist, the internal distance to the advertising routers is used to break the tie.
タイプ2の外部メトリックの処理はより簡単です。 AS境界ルーターまでの内部距離に関係なく、最小の外部メトリックをアドバタイズするAS境界ルーターが選択されます。この例では、ルーターRT5とルーターRT7の両方がタイプ2外部ルートをアドバタイズしていると仮定します。次に、ネットワークN12宛てのすべてのトラフィックは、2 <8であるため、ルーターRT7に転送されます。複数の等コストタイプ2ルートが存在する場合、アドバタイズルーターまでの内部距離を使用して、タイを破ります。
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.
タイプ1とタイプ2の両方の外部メトリックをASに同時に存在させることができます。その場合、タイプ1の外部メトリックが常に優先されます。
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に、ルーターRTXと呼ばれる追加のルーターがネットワークN6に接続されているとします。さらに、RTXがOSPFルーティングに参加していないが、AS境界ルーターRT7とBGP情報を交換しているとします。次に、ルーターRT7は、RTXにルーティングされるすべての宛先のOSPF外部ルートをアドバタイズします。これらの宛先のパケットを常に最初にルーター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外部LSAで「転送アドレス」を指定できるようになっています。上記の例では、ルーターRT7はRTXのIPアドレスを、パケットを直接RTXにルーティングする必要のあるすべての宛先の「転送アドレス」として指定します。
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つのアプリケーションがあります。自律システム内部のルーターが「ルートサーバー」として機能できるようにします。たとえば、図2では、ルーターRT6がルートサーバーになり、静的構成と外部ルーティングプロトコルを組み合わせて外部ルーティング情報を取得できます。次に、RT6は自身をAS境界ルーターとしてアドバタイズし始め、OSPF AS外部LSAのコレクションを発信します。各AS-external-LSAで、ルーターRT6は、LSAの「転送アドレス」フィールドの適切な設定を通じて、宛先に使用する正しい自律システム出口点を指定します。
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.
等コストマルチパスを使用すると、ルーターは、特定の宛先に向かういくつかの利用可能なネクストホップを潜在的に持っています。
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では、隣接するネットワークとホストのコレクションをグループ化できます。このようなグループは、含まれているネットワークのいずれか1つへのインターフェースを持つルーターと合わせて、エリアと呼ばれます。各エリアは、基本的なリンクステートルーティングアルゴリズムの個別のコピーを実行します。つまり、前のセクションで説明したように、各エリアには独自のリンクステートデータベースと対応するグラフがあります。
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.
エリアのトポロジは、エリアの外側からは見えません。逆に、特定のエリアの内部にあるルーターは、そのエリアの外部にある詳細なトポロジについては何も知りません。この知識の分離により、自律システム全体を単一のリンクステートドメインとして扱う場合と比較して、プロトコルはルーティングトラフィックを大幅に削減できます。
With the introduction of areas, it is no longer true that all routers in the AS have an identical link-state database. A router actually has a separate link-state database for each area it is connected to. (Routers connected to multiple areas are called area border routers). Two routers belonging to the same area have, for that area, identical area link-state databases.
エリアの導入により、AS内のすべてのルーターが同一のリンク状態データベースを持つことはもはや真実ではありません。ルーターは実際には、接続しているエリアごとに個別のリンクステートデータベースを持っています。 （複数のエリアに接続されているルーターは、エリア境界ルーターと呼ばれます）。同じエリアに属する2つのルーターは、そのエリアについて、同一のエリアリンク状態データベースを持っています。
Routing in the Autonomous System takes place on two levels, depending on whether the source and destination of a packet reside in the same area (intra-area routing is used) or different areas (inter-area routing is used). In intra-area routing, the packet is routed solely on information obtained within the area; no routing information obtained from outside the area can be used. This protects intra-area routing from the injection of bad routing information. We discuss inter-area routing in Section 3.2.
自律システムでのルーティングは、パケットの送信元と宛先が同じエリア（エリア内ルーティングが使用される）にあるか、異なるエリア（エリア間ルーティングが使用される）にあるかに応じて、2つのレベルで行われます。エリア内ルーティングでは、パケットはエリア内で取得された情報のみに基づいてルーティングされます。エリア外から取得した経路情報は使用できません。これにより、エリア内ルーティングが不正なルーティング情報の挿入から保護されます。セクション3.2でエリア間ルーティングについて説明します。
3.1. The backbone of the Autonomous System
3.1. 自律システムのバックボーン
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エリア0です（OSPFエリアIDは通常IPアドレスとしてフォーマットされているため、多くの場合、エリア0.0.0.0と表記されます）。 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.
この別の見方をすると、エリア間ルーティングは、自律システム上でバックボーンをハブとして、非バックボーンエリアのそれぞれをスポークとして、スター構成を強制するものと考えることができます。
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:
エリアを導入する前は、図2のルーターRT5など、専用の機能を持つOSPFルーターのみが外部ルーティング情報をアドバタイズしたルーターでした。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.
内部ルーターすべての直接接続されたネットワークが同じエリアに属するルーター。これらのルーターは、基本的なルーティングアルゴリズムの単一のコピーを実行します。
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.
エリア境界ルーター複数のエリアに接続するルーター。エリア境界ルーターは、基本アルゴリズムの複数のコピーを実行します（接続されたエリアごとに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.
バックボーンルーターバックボーンエリアへのインターフェイスを持つルーター。これには、複数のエリアにインターフェースするすべてのルーターが含まれます（エリア境界ルーターなど）。ただし、バックボーンルーターはエリア境界ルーターである必要はありません。すべてのインターフェイスがバックボーンエリアに接続されているルーターがサポートされています。
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.
AS境界ルーター他の自律システムに属するルーターとルーティング情報を交換するルーター。このようなルーターは、自律システム全体で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は、エリア構成の例を示しています。最初のエリアは、ネットワークN1-N4と、それらに接続されたルーターRT1-RT4で構成されています。 2番目の領域は、ネットワークN6-N8と、それらに接続されたルーターRT7、RT8、RT10およびRT11で構成されます。 3番目の領域は、ネットワークN9-N11とホストH1、およびそれらに接続されたルーターRT9、RT11、RT12で構成されます。 3番目のエリアは、ネットワークN9-N11とホストH1がエリアの外部でアドバタイズされると、すべて1つのルートにグループ化されるように構成されています（詳細については、セクション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では、ルーターRT1、RT2、RT5、RT6、RT8、RT9、RT12が内部ルーターです。ルーターRT3、RT4、RT7、RT10、RT11はエリア境界ルーターです。最後に、以前と同様に、ルーター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は、エリア1の結果のリンク状態データベースを示しています。この図は、そのエリアのエリア内ルーティングを完全に示しています。また、2つの内部ルーターRT1とRT2のインターネットの全体像も示しています。エリア外部のすべての宛先までの距離をエリア1にアドバタイズするのは、エリア境界ルーターRT3およびRT4の仕事です。これらは、図7に破線のスタブルートで示されています。また、RT3とRT4は、AS境界ルーターRT5とRT7の場所をエリア1に通知する必要があります。最後に、RT5とRT7からのAS外部LSAは、AS全体、特にエリア1全体にフラッディングされます。これらのLSAはエリア1のデータベースに含まれており、ネットワークN12-N15へのルートを生成します。
Routers RT3 and RT4 must also summarize Area 1's topology for
ルータRT3とRT4は、エリア1のトポロジも要約する必要があります。
...........................
. + .
. | 3+---+ . N12 N14
. N1|--|RT1|\ 1 . \ N13 /
. | +---+ \ . 8\ |8/8
. + \ ____ . \|/
. / \ 1+---+8 8+---+6
. * N3 *---|RT4|------|RT5|--------+
. \____/ +---+ +---+ |
. + / \ . |7 |
. | 3+---+ / \ . | |
. N2|--|RT2|/1 1\ . |6 |
. | +---+ +---+8 6+---+ |
. + |RT3|------|RT6| |
. +---+ +---+ |
. 2/ . Ia|7 |
. / . | |
. +---------+ . | |
.Area 1 N4 . | |
........................... | |
.......................... | |
. N11 . | |
. +---------+ . | |
. | . | | N12
. |3 . Ib|5 |6 2/
. +---+ . +----+ +---+/
. |RT9| . .........|RT10|.....|RT7|---N15.
. +---+ . . +----+ +---+ 9 .
. |1 . . + /3 1\ |1 .
. _|__ . . | / \ __|_ .
. / \ 1+----+2 |/ \ / \ .
. * N9 *------|RT11|----| * N6 * .
. \____/ +----+ | \____/ .
. | . . | | .
. |1 . . + |1 .
. +--+ 10+----+ . . N8 +---+ .
. |H1|-----|RT12| . . |RT8| .
. +--+SLIP +----+ . . +---+ .
. |2 . . |4 .
. | . . | .
. +---------+ . . +--------+ .
. N10 . . N7 .
. . .Area 2 .
.Area 3 . ................................
..........................
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.
バックボーンへの配布。それらのバックボーンLSAを表4に示します。これらの要約は、エリア1に含まれているネットワーク（つまり、ネットワークN1-N4）と、ルーターRT3およびRT4からこれらのネットワークまでの距離をそれぞれ示しています。
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に示します。図に示されている一連のルーターは、バックボーンルーターです。ルーターRT11は2つのエリアに属しているため、バックボーンルーターです。バックボーンを接続するために、ルータ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番目の領域は、ネットワークN9-N11とホストH1を1つのルートに凝縮するように構成されています。これにより、図8のネットワークN9〜N11およびホストH1に単一の破線が生成されます。ルーターRT5およびRT7はAS境界ルーターです。それらの外部から導出された情報も、図8のグラフにスタブとして表示されます。
Network RT3 adv. RT4 adv.
_____________________________
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：ルーターRT3およびRT4によってバックボーンにアドバタイズされるネットワーク。
**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 | |
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のエッジは、列Aと行Bの交点がXでマークされている場合、頂点Aを頂点Bに接続します。
**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 | | |
Figure 8: The backbone's database.
図8：バックボーンのデータベース。
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のエッジは、列Aと行Bの交点がXでマークされている場合、頂点Aを頂点Bに接続します。
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.
バックボーンにより、エリア境界ルーター間で要約情報を交換できます。すべてのエリア境界ルーターは、他のすべてのエリア境界ルーターからのエリア概要を聞きます。次に、収集されたLSAを調べ、各アドバタイジングルーターまでのバックボーン距離を追加することにより、そのエリア外のすべてのネットワークまでの距離の画像を形成します。
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.
再び例としてルーターRT3とRT4を使用すると、手順は次のようになります。まず、バックボーンのSPFツリーを計算します。これにより、他のすべてのエリア境界ルーターまでの距離がわかります。また、バックボーンに属するネットワーク（IaおよびIb）およびAS境界ルーター（RT5およびRT7）までの距離も示されています。この計算を表5に示します。
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によって内部的にエリアにアドバタイズされます。ルータRT3およびRT4がエリア1に行うアドバタイズを表6に示します。表6では、IaとIbを1つの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
ルーターRT3およびRT4によってエリア1にインポートされた情報により、RT1などの内部ルーターがエリア境界ルーターをインテリジェントに選択できるようになります。ルータRT1はネットワークN6へのトラフィックにRT4を使用し、ネットワークN10へのトラフィックにRT3を使用し、
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
Table 5: Backbone distances calculated by Routers RT3 and RT4.
表5：ルーターRT3およびRT4によって計算されたバックボーン距離。
Destination RT3 adv. RT4 adv.
_________________________________
Ia,Ib 20 27
N6 16 15
N7 20 19
N8 18 18
N9-N11,H1 29 36
_________________________________
RT5 14 8
RT7 20 14
Table 6: Destinations advertised into Area 1 by Routers RT3 and RT4.
表6：ルータRT3およびRT4によってエリア1にアドバタイズされる宛先。
load share between the two for traffic to Network N8.
ネットワークN8へのトラフィックの2つの間の負荷分散。
Router RT1 can also determine in this manner the shortest path to the AS boundary routers RT5 and RT7. Then, by looking at RT5 and RT7's AS-external-LSAs, Router RT1 can decide between RT5 or RT7 when sending to a destination in another Autonomous System (one of the networks N12-N15).
ルーターRT1は、この方法でAS境界ルーターRT5とRT7への最短パスを決定することもできます。次に、RT5とRT7のAS外部LSAを調べることにより、ルーターRT1は、別の自律システム（ネットワークN12〜N15の1つ）の宛先に送信するときに、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.
ルータRT6とRT10の間の回線に障害が発生すると、バックボーンが切断されることに注意してください。ルーター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アドレスマスクを付加します。マスクは、特定のルートによって記述されているアドレスの範囲を示します。たとえば、マスクが0xffff0000の宛先128.185.0.0のサマリーLSAは、実際には、宛先128.185.0.0-128.185.255.255のコレクションへの単一ルートを記述しています。同様に、ホストルートは常に0xffffffffのマスクでアドバタイズされ、単一の宛先のみが存在することを示します。
Including the mask with each advertised destination enables the implementation of what is commonly referred to as variable-length subnetting. This means that a single IP class A, B, or C network number can be broken up into many subnets of various sizes. For example, the network 128.185.0.0 could be broken up into 62 variable-sized subnets: 15 subnets of size 4K, 15 subnets of size 256, and 32 subnets of size 8. Table 7 shows some of the resulting network addresses together with their masks.
アドバタイズされた各宛先にマスクを含めることで、一般に可変長サブネットと呼ばれるものを実装できます。これは、単一のIPクラスA、B、またはCのネットワーク番号をさまざまなサイズの多くのサブネットに分割できることを意味します。たとえば、ネットワーク128.185.0.0は62の可変サイズサブネットに分割できます。サイズ4Kの15サブネット、サイズ256の15サブネット、およびサイズ8の32サブネットです。表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
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スーパーネットのサポートも有効になります。たとえば、単一の物理ネットワークセグメントに[address、mask]ペア[192.9.4.0,0xfffffc00]を割り当てることができます。セグメントは、4つの連続するクラスCネットワーク番号192.9.4.0から192.9.7.0までのアドレスを含む単一のIPネットワークになります。このようなアドレス指定は、CIDRの登場とともに一般的になりつつあります（[Ref10]を参照）。
In order to get better aggregation at area boundaries, area address ranges can be employed (see Section C.2 for more details). Each address range is defined as an [address,mask] pair. Many separate networks may then be contained in a single address range, just as a subnetted network is composed of many separate subnets. Area border routers then summarize the area contents (for distribution to the backbone) by advertising a single route for each address range. The cost of the route is the maximum cost to any of the networks falling in the specified range.
エリア境界でより良い集計を行うために、エリアアドレス範囲を使用できます（詳細については、セクションC.2を参照してください）。各アドレス範囲は、[address、mask]ペアとして定義されます。サブネット化されたネットワークが多くの個別のサブネットで構成されるのと同じように、多くの個別のネットワークが単一のアドレス範囲に含まれる可能性があります。次に、エリア境界ルーターは、各アドレス範囲に対して単一のルートをアドバタイズすることにより、（バックボーンへの配布のために）エリアの内容を要約します。ルートのコストは、指定された範囲に含まれるネットワークへの最大コストです。
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マスクです。エリア内では、可変サイズのサブネットをいくつでも定義できます。ただし、エリアの外部では、サブネット化されたネットワーク全体の単一のルートが配布され、ネットワークがまったくサブネット化されているという事実さえ隠されます。このルートのコストは、コンポーネントサブネットへのコストのセットの最大値です。
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.
一部の自律システムでは、リンク状態データベースの大部分がAS外部LSAで構成されている場合があります。 OSPF AS-external-LSAは通常、AS全体にフラッディングされます。ただし、OSPFでは特定のエリアを「スタブエリア」として構成できます。 AS外部LSAは、スタブエリア内またはスタブエリア全体にはフラッディングされません。これらのエリアの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 explicitly reachable by an intra-area or inter-area path (i.e., AS external destinations).
OSPFスタブエリアサポートを利用するには、スタブエリアでデフォルトルーティングを使用する必要があります。これは次のように行われます。 1つ以上のスタブエリアのエリア境界ルーターは、サマリーLSAを介してデフォルトルートをスタブエリアにアドバタイズする必要があります。これらのサマリーデフォルトは、スタブエリア全体にフラッディングされますが、それ以上はフラッディングされません。 （このため、これらのデフォルトは特定のスタブエリアにのみ関係します）。これらのサマリーデフォルトルートは、エリア内パスまたはエリア間パス（つまり、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.
エリアからの出口が1つしかない場合、または外部宛先ごとに出口ポイントを選択する必要がない場合は、エリアをスタブとして構成できます。たとえば、図6のエリア3は、すべての外部トラフィックがその単一のエリア境界ルーターRT11を通過する必要があるため、スタブエリアとして構成できます。エリア3がスタブとして構成されている場合、ルーターRT11は、ネットワークN12-N15のAS外部LSAをエリアに/エリア全体にフラッディングするのではなく、エリア3内（サマリーLSA内）に配信するデフォルトルートをアドバタイズします。
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外部LSAのフラッディングで混乱が発生しないことが保証されます。
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.
スタブエリアの使用には、いくつかの制限があります。仮想リンクはスタブエリアを介して設定できません。さらに、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).
ただし、パーティション後も完全なルーティングを維持するには、アドレス範囲をエリアパーティションの複数のコンポーネントに分割しないでください。また、バックボーン自体が分割されてはなりません。その場合、自律システムの一部に到達できなくなります。バックボーンパーティションは、仮想リンクを構成することで修復できます（セクション15を参照）。
Another way to think about area partitions is to look at the Autonomous System graph that was introduced in Section 2. Area IDs can be viewed as colors for the graph's edges.[1] Each edge of the graph connects to a network, or is itself a point-to-point network. In either case, the edge is colored with the network's Area ID.
エリアパーティションについて考えるもう1つの方法は、セクション2で導入された自律システムグラフを調べることです。エリアIDは、グラフのエッジの色として表示できます。[1]グラフの各エッジはネットワークに接続するか、それ自体がポイントツーポイントネットワークです。どちらの場合も、エッジはネットワークのエリア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.
エッジのグループは、すべて同じ色を持ち、頂点によって相互接続されており、エリアを表します。自律システムのトポロジーが損なわれていない場合、グラフにはいくつかの色の領域があり、各色は異なるエリア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のグラフには、同じ色（領域ID）の複数の領域があります。自律システムのルーティングは、同じ色のこれらの領域が単一のバックボーン領域によって接続されている限り機能し続けます。
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パケットを受信します。ブロードキャストおよびポイントツーポイントネットワークでは、ルーターはHelloパケットをマルチキャストアドレスAllSPFRoutersに送信することにより、隣接ルーターを動的に検出します。非ブロードキャストネットワークでは、ネイバーを検出するためにいくつかの設定情報が必要になる場合があります。ブロードキャストおよびNBMAネットワークでは、Helloプロトコルはネットワークの指定ルーターも選択します。
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ネットワークでは、指定ルーターが隣接するルーターを決定します。
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.
ルーターは定期的にその状態を通知します。これはリンク状態とも呼ばれます。リンク状態は、ルーターの状態が変化したときにも通知されます。ルータの隣接関係は、LSAの内容に反映されます。隣接関係とリンク状態の間のこの関係により、プロトコルはデッドルータをタイムリーに検出できます。
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.
LSAは地域全体に氾濫しています。フラッディングアルゴリズムは信頼性が高く、エリア内のすべてのルータがまったく同じリンク状態データベースを持つことを保証します。このデータベースは、エリアに属する各ルーターから発信されたLSAのコレクションで構成されています。このデータベースから、各ルーターは自身をルートとして最短パスツリーを計算します。この最短パスツリーにより、プロトコルのルーティングテーブルが生成されます。
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.
前のセクションでは、単一の領域内でのプロトコルの操作について説明しました。エリア内ルーティングの場合、他のルーティング情報は適切ではありません。エリア外の宛先にルーティングできるようにするために、エリア境界ルーターは追加のルーティング情報をエリアに注入します。この追加情報は、自律システムのトポロジの残りの部分を要約したものです。
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).
他の自律システムに関する情報を持つルーターは、この情報をAS全体にフラッディングできます。この外部ルーティング情報は、参加しているすべてのルーターに逐語的に配信されます。 1つの例外があります。外部ルーティング情報は「スタブ」エリアにフラッディングされません（セクション3.6を参照）。
To utilize external routing information, the path to all routers advertising external information must be known throughout the AS (excepting the stub areas). For that reason, the locations of these AS boundary routers are summarized by the (non-stub) area border routers.
外部ルーティング情報を利用するには、外部情報をアドバタイズするすべてのルーターへのパスがAS全体で認識されている必要があります（スタブエリアを除く）。そのため、これらのAS境界ルーターの場所は、（非スタブ）エリア境界ルーターによって要約されます。
4.3. Routing protocol packets
4.3. ルーティングプロトコルパケット
The OSPF protocol runs directly over IP, using IP protocol 89. OSPF does not provide any explicit fragmentation/reassembly support. When fragmentation is necessary, IP fragmentation/reassembly is used. OSPF protocol packets have been designed so that large protocol packets can generally be split into several smaller protocol packets. This practice is recommended; IP fragmentation should be avoided whenever possible.
OSPFプロトコルは、IPプロトコル89を使用して、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 precedenceフィールドを値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プロトコルパケットは、付録Aで説明されている共通のプロトコルヘッダーを共有します。OSPFパケットの種類を表8に示します。それらの形式も付録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
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パケットを使用してネイバー関係を検出および維持します。データベース記述およびリンク状態要求パケットは、隣接関係の形成に使用されます。 OSPFの信頼性の高い更新メカニズムは、リンク状態更新パケットとリンク状態確認パケットによって実装されます。
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.
各リンク状態更新パケットは、発信元から1ホップ離れた一連の新しいリンク状態通知（LSA）を伝送します。 1つのリンク状態更新パケットには、複数のルーターのLSAが含まれる場合があります。各LSAには、発信元ルーターのIDとそのリンク状態コンテンツのチェックサムがタグ付けされています。各LSAにはタイプフィールドもあります。さまざまなタイプのOSPF LSAを以下の表9に示します。
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ルーティングパケット（Helloを除く）は、隣接を介してのみ送信されます。これは、仮想隣接を介して送信されるものを除いて、すべてのOSPFプロトコルパケットが単一のIPホップを移動することを意味します。 OSPFプロトコルパケットのIP送信元アドレスはルーター隣接の一方の端であり、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.
タイマー2つの異なる種類のタイマーが必要です。 「シングルショットタイマー」と呼ばれる最初の種類は、一度起動すると、プロトコルイベントが処理されます。 「インターバルタイマー」と呼ばれる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.
ドリフトを回避するために、インターバルタイマーを実装する必要があります。一部のルーター実装では、パケット処理がタイマーの実行に影響を与える可能性があります。複数のルーターが単一のネットワークに接続されていて、すべてがブロードキャストを行っている場合、ルーティングパケットの同期が発生する可能性があります（回避する必要があります）。ドリフトを回避するためにタイマーを実装できない場合は、小さなランダムな量を各発火のインターバルタイマーに追加/インターバルタイマーから差し引く必要があります。
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.
Table 9: OSPF link state advertisements (LSAs).
表9：OSPFリンク状態通知（LSA）。
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マルチキャスト特定のOSPFパケットは、IPマルチキャストデータグラムの形式をとります。 IPマルチキャストデータグラムの送受信のサポートと、適切な下位レベルのプロトコルサポートが必要です。 OSPFで使用されるIPマルチキャストデータグラムは、複数のホップを移動することはありません。このため、IPマルチキャストデータグラムを転送する機能は必要ありません。 IPマルチキャストについては、[参照7]を参照してください。
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ルーティングのスケーリングを改善する1つの方法として提案されています。 IPスーパーネットの詳細については、[参照10]を参照してください。
Lower-level protocol support The lower level protocols referred to here are the network access protocols, such as the Ethernet data link layer. Indications must be passed from these protocols to OSPF as the network interface goes up and down. For example, on an ethernet it would be valuable to know when the ethernet transceiver cable becomes unplugged.
下位レベルのプロトコルのサポートここで参照される下位レベルのプロトコルは、イーサネットデータリンク層などのネットワークアクセスプロトコルです。ネットワークインターフェイスが上下するときに、これらのプロトコルからOSPFに指示を渡す必要があります。たとえば、イーサネットでは、イーサネットトランシーバーケーブルがいつ外れるかを知ることは重要です。
Non-broadcast lower-level protocol support On non-broadcast networks, the OSPF Hello Protocol can be aided by providing an indication when an attempt is made to send a packet to a dead or non-existent router. For example, on an X.25 PDN a dead neighboring router may be indicated by the reception of a X.25 clear with an appropriate cause and diagnostic, and this information would be passed to OSPF.
非ブロードキャストの下位レベルプロトコルのサポート非ブロードキャストネットワークでは、OSPF Helloプロトコルは、デッドまたは存在しないルーターにパケットを送信する試みが行われたときに指示を提供することで支援できます。たとえば、X.25 PDNでは、適切な原因と診断を伴う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機能の多くは、LSAのリストでの操作に関して説明されています。たとえば、確認されるまで隣接ルータに再送信されるLSAのコレクションは、リストとして記述されます。特定のLSAがそのようなリストの多くにある場合があります。 OSPFの実装では、これらのリストを操作し、必要に応じて構成要素のLSAを追加および削除できる必要があります。
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.
タスクのサポートこの仕様で説明されている特定の手順は、他の手順を呼び出します。これらの他のプロシージャは、インラインで、つまり現在のプロシージャが完了する前に実行する必要がある場合があります。これは、手順を実行するための指示によってテキストに示されています。それ以外の場合、他のプロシージャは、現在のプロシージャが終了したときにのみ実行されます。これは、タスクをスケジュールするための指示によって示されます。
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パケット、データベース記述パケット、およびLSAでサポートするオプション機能を示します。これにより、オプション機能の組み合わせをサポートするルーターが単一の自律システムに共存できるようになります。
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パケットを受け入れません（つまり、機能の不一致により、ネイバー関係の形成が妨げられます）。この例は、ExternalRoutingCapabilityです（以下を参照）。
Other capabilities can be negotiated during the Database Exchange process. This is accomplished by specifying the optional capabilities in Database Description packets. A capability mismatch with a neighbor in this case will result in only a subset of the link state database being exchanged between the two neighbors.
その他の機能は、データベース交換プロセス中にネゴシエートできます。これは、データベース記述パケットでオプション機能を指定することによって実現されます。この場合、ネイバーと機能が一致しないと、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.
ルーティングテーブルの構築プロセスは、オプション機能の有無によっても影響を受ける可能性があります。たとえば、オプション機能はLSAで報告されるため、最短パスツリーを構築するときに、特定の機能を実行できないルーターを回避できます。
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 OSPFエリア全体を「スタブ」として構成できます（セクション3.6を参照）。 AS外部LSAはスタブエリアにフラッディングされません。この機能は、OSPFオプションフィールドのEビットで表されます（セクションA.2を参照）。スタブエリアの一貫した構成を保証するために、そのようなエリアに接続するすべてのルーターは、HelloパケットでEビットをクリアする必要があります（セクション9.5および10.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.
ルーターID ASでこのルーターを一意に識別する32ビットの番号。 1つの可能な実装戦略は、ルーターに属する最小のIPインターフェイスアドレスを使用することです。ルーターのOSPFルーターIDが変更された場合、新しいルーターIDが有効になる前に、ルーターのOSPFソフトウェアを再起動する必要があります。この場合、ルーターは再起動する前にルーティングドメイン（セクション14.1を参照）から自己発信LSAをフラッシュする必要があります。そうしないと、最大MaxAge分間存続します。
Area structures Each one of the areas to which the router is connected has its own data structure. This data structure describes the working of the basic OSPF algorithm. Remember that each area runs a separate copy of the basic OSPF algorithm.
エリア構造ルータが接続されている各エリアには、独自のデータ構造があります。このデータ構造は、基本的な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つのエンドポイントとして構成された仮想リンク。仮想リンクを構成するには、ルーター自体がエリア境界ルーターである必要があります。仮想リンクは、他のエンドポイントのルーターIDによって識別されます。これは、別のエリア境界ルーターです。これらの2つのエンドポイントルーターは、仮想リンクの通過領域と呼ばれる共通領域に接続する必要があります。仮想リンクはバックボーンの一部であり、2つのルーター間の非番号ポイントツーポイントネットワークであるかのように動作します。仮想リンクは、トランジットエリアのエリア内ルーティングを使用してパケットを転送します。トランジットエリアの最短パスツリーの構築を通じて、仮想リンクがアップおよびダウンされます。
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.
外部ルートのリストこれらは、自律システムの外部の宛先へのルートであり、別のルーティングプロトコル（BGPなど）の直接的な経験、または構成情報、または2つの組み合わせ（たとえば、動的外部メトリックが設定されたOSPFによってアドバタイズされる情報）。これらの外部ルートを持つルーターは、AS境界ルーターと呼ばれます。これらのルートは、AS-external-LSAを介して、ルーターによって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-external-LSAのリストリンク状態データベースの一部。これらは、AS境界ルーターから発信されたものです。これらは、自律システムの外部の宛先へのルートを構成します。ルーター自体がAS境界ルーターである場合、これらのAS外部LSAの一部は自己発信型であることに注意してください。
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.
リンク状態データベースから派生したルーティングテーブル。ルーティングテーブルの各エントリには、宛先によってインデックスが付けられ、宛先のコストと、パケットを宛先に転送するときに使用する一連のパスが含まれています。パスは、タイプとネクストホップによって記述されます。詳細については、セクション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です。ルーターRT10には、ルーターRT11に構成された仮想リンクがあり、エリア2がリンクのトランジットエリアとして設定されています。これは、図9の破線で示されています。仮想リンクがアクティブになると、エリア2の最短パスツリーが構築され、バックボーンへのインターフェイスになります（図9に示す2つのバックボーンインターフェイスを参照）。
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ルーティングアルゴリズムの実行に使用されるすべての情報が含まれています。各エリアは、独自のリンク状態データベースを維持しています。ネットワークは単一のエリアに属し、ルーターインターフェイスは単一のエリアに接続します。各ルータの隣接関係も1つのエリアに属しています。
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.
エリアのリンク状態データベースは、エリアのルーターから発信されたルーターLSA、ネットワークLSA、サマリーLSAのコレクションで構成されています。この情報は、単一の領域にのみフラッディングされます。 AS-external-LSA（セクション5を参照）のリストも、各エリアのリンク状態データベースの一部と見なされます。
Area ID A 32-bit number identifying the area. The Area ID of 0.0.0.0 is reserved for the backbone.
エリアIDエリアを識別する32ビットの数値。エリア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).
エリアアドレス範囲のリストエリア境界でルーティング情報を集約するために、エリアアドレス範囲を使用できます。各アドレス範囲は、[address、mask]ペアと、AdvertiseまたはDoNotAdvertiseのステータス表示によって指定されます（セクション12.4.3を参照）。
+----+
|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|
+-------------+
Figure 9: Router RT10's Data structures
図9：ルーターRT10のデータ構造
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.
関連するルーターインターフェースこのルーターの、エリアに接続するインターフェース。ルーターインターフェイスは、1つのエリア（またはバックボーン）にのみ属します。バックボーンエリアの場合、このリストにはすべての仮想リンクが含まれます。仮想リンクは、他のエンドポイントのルーターIDによって識別されます。そのコストは、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.
ルーターLSAのリストルーター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.
ネットワークLSAのリストエリア内のトランジットブロードキャストとNBMAネットワークごとに1つのネットワークLSAが生成されます。ネットワーク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).
サマリーLSAのリストサマリーLSAは、エリアのエリア境界ルーターから発信されます。これらは、自律システムの内部であるがエリアの外部にある宛先へのルートを記述します（つまり、エリア間宛先）。
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).
最短パスツリーこのルーター自体をルートとする、エリアの最短パスツリー。ダイクストラアルゴリズムによって収集されたルーターLSAおよびネットワークLSAから派生（セクション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このパラメーターは、エリアがエリア自体で発生も終了もしないデータトラフィックをエリアが伝送できるかどうかを示します。このパラメーターは、エリアの最短パスツリーが構築されるときに計算され（セクション16.1を参照）、エリアをトランジットエリアとして使用している完全に隣接する仮想リンクが1つ以上存在する場合にのみ、TransitCapabilityがTRUEに設定されます。ルーティングテーブル作成プロセスの後続のステップへの入力（セクション16.3を参照）。エリアの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 AS外部LSAがエリアにフラッディングされるか、エリア全体にフラッディングされるかどうか。これは設定可能なパラメータです。 AS-external-LSAがエリアから除外されている場合、そのエリアは「スタブ」と呼ばれます。スタブエリア内では、AS外部宛先へのルーティングは、デフォルトのサマリールートのみに基づいて行われます。バックボーンはスタブエリアとして設定できません。また、仮想リンクはスタブエリアを介して構成できません。詳細は、3.6項を参照してください。
StubDefaultCost If the area has been configured as a stub area, and the router itself is an area border router, then the StubDefaultCost indicates the cost of the default summary-LSA that the router should advertise into the area. See Section 12.4.3 for more information.
StubDefaultCostエリアがスタブエリアとして構成されていて、ルーター自体がエリア境界ルーターである場合、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プロトコルの動作について説明します。
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. Helloプロトコル
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パケットは、すべてのルーターインターフェイスから定期的に送信されます。ルータがネイバーのHelloパケットにリストされていることを確認すると、双方向通信が示されます。ブロードキャストネットワークとNBMAネットワークでは、Helloプロトコルはネットワークの指定ルーターを選出します。
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ネットワーク、およびポイントツーマルチポイントネットワークでは動作が異なります。ブロードキャストネットワークでは、各ルーターは定期的にHelloパケットをマルチキャストすることにより、自身をアドバタイズします。これにより、ネイバーを動的に検出できます。これらのHelloパケットには、代表ルーターのIDに関するルーターのビューと、Helloパケットが最近見られたルーターのリストが含まれています。
On NBMA networks some configuration information may be necessary for the operation of the Hello Protocol. Each router that may potentially become Designated Router has a list of all other routers attached to the network. A router, having Designated Router potential, sends Hello Packets to all other potential Designated Routers when its interface to the NBMA network first becomes operational. This is an attempt to find the Designated Router for the network. If the router itself is elected Designated Router, it begins sending Hello Packets to all other routers attached to the network.
NBMAネットワークでは、Helloプロトコルの操作にいくつかの構成情報が必要になる場合があります。指定ルーターになる可能性のある各ルーターには、ネットワークに接続されている他のすべてのルーターのリストがあります。指定ルーターの可能性があるルーターは、NBMAネットワークへのインターフェースが最初に動作可能になったときに、他のすべての指定ルーターにHelloパケットを送信します。これは、ネットワークの指定ルーターを見つける試みです。ルーター自体が指定ルーターとして選択された場合、ネットワークに接続されている他のすべてのルーターにHelloパケットの送信を開始します。
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.
ポイントツーマルチポイントネットワークでは、ルーターはHelloパケットを、直接通信できるすべてのネイバーに送信します。これらのネイバーは、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ネットワーク上で）指定ルーターが選択された後、ネイバーと隣接関係を形成するかどうかが決定されます（セクション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.
リンクステートルーティングアルゴリズムでは、すべてのルーターのリンクステートデータベースの同期を保つことが非常に重要です。 OSPFは、隣接するルーターのみが同期を維持することを要求することにより、これを簡素化します。同期プロセスは、ルータが隣接関係を確立しようとするとすぐに開始されます。各ルーターは、一連のデータベース記述パケットを隣接ルーターに送信することにより、データベースを記述します。各データベース記述パケットは、ルーターのデータベースに属する一連のLSAを記述します。ネイバーは、自身のデータベースコピーよりも新しい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 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.
このデータベース記述パケットの送受信は、「データベース交換プロセス」と呼ばれます。このプロセス中に、2つのルーターはマスター/スレーブ関係を形成します。各データベース記述パケットにはシーケンス番号があります。データベースの説明マスター（ポーリング）によって送信されたパケットは、シーケンス番号のエコーを通じてスレーブによって確認されます。ポーリングとその応答の両方に、リンク状態データの要約が含まれています。マスターは、データベース記述パケットを再送信できる唯一のマスターです。これは一定の間隔でのみ行われ、その長さは構成されたインターフェイスごとの定数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.
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.
データベース交換プロセス中およびその後に、各ルーターには、ネイバーがより最新のインスタンスを持つLSAのリストがあります。これらのLSAは、リンク状態要求パケットで要求されます。満たされていないリンク状態要求パケットは、一定の時間間隔RxmtIntervalで再送信されます。データベース記述プロセスが完了し、すべてのリンク状態要求が満たされると、データベースは同期していると見なされ、ルーターは完全に隣接しているとマークされます。この時点で、隣接関係は完全に機能しており、2つのルーターのルーターLSAでアドバタイズされます。
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.
隣接関係は、データベース交換プロセスが開始するとすぐに、フラッディング手順で使用されます。これにより、データベースの同期が簡素化され、予測可能な時間内に完了することが保証されます。
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ネットワークには指定ルーターがあります。指定ルーターは、ルーティングプロトコルの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 指定ルーターは、ネットワークに代わってネットワークLSAを発信します。このLSAは、現在ネットワークに接続されているルーターのセット（指定ルーター自体を含む）をリストします。このLSAのリンク状態ID（セクション12.1.4を参照）は、代表ルーターのIPインターフェースアドレスです。 IPネットワーク番号は、ネットワークのサブネット/ネットワークマスクを使用して取得できます。
o The Designated Router becomes adjacent to all other routers on the network. Since the link state databases are synchronized across adjacencies (through adjacency bring-up and then the flooding procedure), the Designated Router plays a central part in the synchronization process.
o 指定ルーターは、ネットワーク上の他のすべてのルーターに隣接します。リンク状態データベースは隣接間で同期されているため（隣接ブリングアップ、次にフラッディング手順によって）、指定ルーターは同期プロセスの中心的な役割を果たします。
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.
指定ルーターは、Helloプロトコルによって選出されます。ルーターのHelloパケットには、ルータープライオリティが含まれています。これは、インターフェイスごとに構成できます。一般に、ネットワークへのルーターのインターフェースが最初に機能するようになると、ネットワークに現在指定ルーターがあるかどうかを確認します。ある場合は、ルーターの優先順位に関係なく、その指定ルーターを受け入れます。 （これにより、指定ルーターのIDを予測することが難しくなりますが、指定ルーターの変更頻度が少なくなります。以下を参照してください。）それ以外の場合、ネットワーク自体で最高のルーター優先度を持つルーター自体が指定ルーターになります。指定ルーターの選択に関するより詳細な（そしてより正確な）説明はセクション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.
指定ルーターは、多くの隣接関係のエンドポイントです。ブロードキャストネットワークでのフラッディング手順を最適化するために、指定ルータは、各隣接を介して個別のパケットを送信するのではなく、リンク状態更新パケットをアドレスAllSPFRoutersにマルチキャストします。
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では、エリアの有向グラフ表現について説明します。ルーターノードには、ルーターIDが付いています。トランジットネットワークノードは、実際には指定ルーターのIPアドレスでラベル付けされています。つまり、指定ルーターが変更されると、グラフ上のネットワークノードがまったく新しいノードに置き換えられたように見えます。これにより、ネットワークとそれに接続されているすべてのルーターが新しいLSAを発信します。リンクステートデータベースが再び収束するまで、接続が一時的に失われる可能性があります。これにより、データトラフィックに応答してICMP到達不能メッセージが送信される可能性があります。そのため、指定ルーターはまれにしか変更されません。ルーターの優先順位は、ネットワーク上の最も信頼できるルーターが最終的に指定ルーターになるように構成する必要があります。
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).
新しい指定ルーターへの移行をよりスムーズにするために、各ブロードキャストおよびNBMAネットワークにバックアップ指定ルーターがあります。バックアップ指定ルーターは、ネットワーク上のすべてのルーターにも隣接しており、前の指定ルーターに障害が発生すると指定ルーターになります。バックアップ指定ルーターがなかった場合、新しい指定ルーターが必要になったときに、新しい指定ルーターとネットワークに接続されている他のすべてのルーターとの間に新しい隣接関係を形成する必要があります。隣接関係形成プロセスの一部は、リンク状態データベースの同期です。これには、かなり時間がかかる可能性があります。この間、ネットワークはトランジットデータトラフィックに使用できません。指定バックアップは、すでに存在しているため、これらの隣接関係を形成する必要をなくします。つまり、トランジットトラフィックの中断期間は、新しいLSA（新しい指定ルーターをアナウンスする）をフラッディングするのにかかる時間だけ続きます。
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.)
バックアップ指定ルーターは、ネットワークのネットワークLSAを生成しません。 （そうした場合、新しい指定ルーターへの移行はさらに速くなります。ただし、これは指定ルーターが消えたときのデータベースサイズと収束速度のトレードオフです。）
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.
バックアップ指定ルーターも、Helloプロトコルによって選択されます。各Helloパケットには、ネットワークのバックアップ指定ルーターを指定するフィールドがあります。
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.
フラッディング手順の一部のステップでは、バックアップ代表ルーターが受動的な役割を果たし、代表ルーターがより多くの作業を実行できるようにします。これにより、ローカルルーティングトラフィックの量が削減されます。詳細については、セクション13.3を参照してください。
7.5. The graph of adjacencies
7.5. 隣接のグラフ
An adjacency is bound to the network that the two routers have in common. If two routers have multiple networks in common, they may have multiple adjacencies between them.
隣接関係は、2つのルーターが共有するネットワークにバインドされます。 2つのルーターに共通の複数のネットワークがある場合、それらのルーター間に複数の隣接関係がある場合があります。
One can picture the collection of adjacencies on a network as forming an undirected graph. The vertices consist of routers, with an edge joining two routers if they are adjacent. The graph of adjacencies describes the flow of routing protocol packets, and in particular Link State Update Packets, through the Autonomous System.
ネットワーク上の隣接関係の集合を無向グラフを形成するものとして描くことができます。頂点はルーターで構成され、隣接している場合はエッジが2つのルーターを結合します。隣接関係のグラフは、自律システムを介したルーティングプロトコルパケット、特にリンク状態更新パケットのフローを示しています。
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.
ネットワークで指定ルーターが選択されているかどうかに応じて、2つのグラフが表示されます。物理的なポイントツーポイントネットワーク、ポイントツーマルチポイントネットワーク、および仮想リンクでは、隣接するルーターは、直接通信できる場合は常に隣接します。対照的に、ブロードキャストおよびNBMAネットワークでは、指定ルーターとバックアップ指定ルーターのみが、ネットワークに接続されている他のすべてのルーターに隣接します。
+---+ +---+
|RT1|------------|RT2| o---------------o
+---+ N1 +---+ RT1 RT2
RT7
o---------+
+---+ +---+ +---+ /|\ |
|RT7| |RT3| |RT4| / | \ |
+---+ +---+ +---+ / | \ |
| | | / | \ |
+-----------------------+ RT5o RT6o oRT4 |
| | N2 * * * |
+---+ +---+ * * * |
|RT5| |RT6| * * * |
+---+ +---+ *** |
o---------+
RT3
Figure 10: The graph of adjacencies
図10：隣接関係のグラフ
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に示します。ネットワークN2のルーターRT7が指定ルーターになり、ルーターRT3がバックアップ指定ルーターになったと想定しています。バックアップ指定ルーターは、フラッディング手順中に指定ルーターよりも機能が少なくなります（セクション13.3を参照）。これが、バックアップ指定ルーターRT3を接続する破線の理由です。
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.
ルーティングプロトコルパケットは、隣接のみを介して送信されます（隣接を検出するために使用されるHelloパケットを除く）。これは、仮想リンク経由で送信されたものを除いて、すべてのルーティングプロトコルパケットが単一の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に設定。この仕様に記載されているプロトコルのバージョン番号。
Packet type The type of OSPF packet, such as Link state Update or Hello Packet.
パケットタイプリンクステートアップデートやハローパケットなどのOSPFパケットのタイプ。
Packet length The length of the entire OSPF packet in bytes, including the standard OSPF packet header.
パケット長標準のOSPFパケットヘッダーを含む、OSPFパケット全体の長さ（バイト単位）。
Router ID The identity of the router itself (who is originating the packet).
ルーターID（パケットを発信している）ルーター自体のID。
Area ID The OSPF area that the packet is being sent into.
Area OFパケットの送信先の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パケット全体の標準IP 16ビットの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と認証各OSPFパケット交換が認証されます。認証タイプはプロトコルによって割り当てられ、付録Dに記載されています。IPネットワーク/サブネットごとに異なる認証手順を使用できます。 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 Packets and Link State Acknowledgment Packets to the multicast address AllSPFRouters, while all other routers send both their Link State Update and Link State Acknowledgment Packets to the multicast address AllDRouters.
パケットのIP宛先アドレスは、次のように選択されます。物理的なポイントツーポイントネットワークでは、IP宛先は常にアドレスAllSPFRoutersに設定されます。他のすべてのネットワークタイプ（仮想リンクを含む）では、OSPFパケットの大部分はユニキャストとして送信されます。つまり、隣接関係のもう一方の端に直接送信されます。この場合、IP宛先は、隣接のもう一方の端に関連付けられたネイバーIPアドレスだけです（セクション10を参照）。ユニキャストとして送信されない唯一のパケットは、ブロードキャストネットワーク上にあります。これらのネットワークでは、helloパケットがマルチキャスト宛先AllSPFRoutersに送信され、指定ルーターとそのバックアップがリンク状態更新パケットとリンク状態確認パケットの両方をマルチキャストアドレスAllSPFRoutersに送信し、他のすべてのルーターはリンク状態更新とリンク状態確認の両方を送信しますマルチキャストアドレス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.
リンク状態更新パケットの再送信は、常にネイバーに直接送信されます。マルチアクセスネットワークでは、これは再送信がネイバーの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アドレスのいずれかに設定する必要があります。このため、ルーターには少なくとも1つのIPアドレスが割り当てられている必要があります。[2]ほとんどの目的で、仮想リンクは番号なしのポイントツーポイントネットワークとまったく同じように動作することに注意してください。ただし、各仮想リンクにはIPインターフェースアドレス（ルーティングテーブルの構築プロセス中に検出された）があり、仮想リンクを介してパケットを送信するときにIPソースとして使用されます。
For more information on the format of specific OSPF packet types, consult the sections listed in Table 10.
特定のOSPFパケットタイプの形式の詳細については、表10にリストされているセクションを参照してください。
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
Table 10: Sections describing OSPF protocol packet transmission.
表10：OSPFプロトコルのパケット送信を説明するセクション。
8.2. Receiving protocol packets
8.2. プロトコルパケットの受信
Whenever a protocol packet is received by the router it is marked with the interface it was received on. For routers that have virtual links configured, it may not be immediately obvious which interface 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に示すルーターRT11について考えてみます。RT11がネットワークN8へのインターフェースでOSPFプロトコルパケットを受信した場合、エリア2へのインターフェースまたはルーター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マルチキャストアドレス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: (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.
o OSPFヘッダーにあるエリアIDを確認する必要があります。次の両方のケースが失敗した場合、パケットは破棄されます。ヘッダーで指定されたエリアIDは、次のいずれかである必要があります。（1）受信インターフェイスのエリア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）バックボーンを示します。この場合、パケットは仮想リンクを介して送信されています。受信ルーターはエリア境界ルーターである必要があり、パケットで指定されたルーターID（ソースルーター）は、構成された仮想リンクのもう一方の端である必要があります。受信インターフェイスは、仮想リンクの設定されたトランジットエリアにも接続する必要があります。これらすべてのチェックが成功した場合、パケットは受け入れられ、今後は仮想リンク（およびバックボーンエリア）に関連付けられます。
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 IP宛先がAllDRoutersであるパケットは、受信インターフェースの状態がDRまたはバックアップの場合にのみ受け入れられる必要があります（セクション9.1を参照）。
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の設定で示されます（付録Dを参照）。認証手順では、1つ以上の認証キーを使用できます。認証キーは、インターフェイスごとに構成できます。認証手順では、OSPFパケットヘッダーのチェックサムフィールドを確認することもできます（これを使用すると、64ビット認証フィールドを除外した後、OSPFパケットの内容の標準IP 16ビットの1の補数チェックサムに設定されます）。認証手順が失敗した場合、パケットは破棄されます。
If the packet type is Hello, it should then be further processed by the Hello Protocol (see Section 10.5). All other packet types are sent/received only on adjacencies. This means that the packet must have been sent by one of the router's active neighbors. If the receiving interface connects to a broadcast network, Point-to-MultiPoint network or NBMA network the sender is identified by the IP source address found in the packet's IP header. If the receiving interface connects to a point-to-point network or a virtual link, the sender is identified by the Router ID (source router) found in the packet's OSPF header. The data structure associated with the receiving interface contains the list of active neighbors. Packets not matching any active neighbor are discarded.
パケットタイプがHelloの場合は、Helloプロトコルでさらに処理する必要があります（セクション10.5を参照）。他のすべてのパケットタイプは、隣接でのみ送受信されます。つまり、パケットはルーターのアクティブなネイバーのいずれかから送信されたものでなければなりません。受信インターフェイスがブロードキャストネットワーク、ポイントツーマルチポイントネットワーク、またはNBMAネットワークに接続する場合、送信者はパケットのIPヘッダーにあるIPソースアドレスによって識別されます。受信インターフェイスがポイントツーポイントネットワークまたは仮想リンクに接続する場合、送信者はパケットのOSPFヘッダーにあるルーター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.
この時点で、受信したすべてのプロトコルパケットはアクティブなネイバーに関連付けられています。特定のパケットタイプの詳細な入力処理については、表11にリストされているセクションを参照してください。
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
Table 11: Sections describing OSPF protocol packet reception.
表11：OSPFプロトコルのパケット受信を説明するセクション。
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インターフェースは、ルーターとネットワーク間の接続です。付録Fでは、単一のネットワークで複数のインターフェースをサポートすることを検討していますが、接続されている各ネットワーク/サブネットへの単一のOSPFインターフェースを想定しています。各インターフェース構造には、最大で1つのIPインターフェースアドレスがあります。
An OSPF interface can be considered to belong to the area that contains the attached network. All routing protocol packets originated by the router over this interface are labelled with the interface's Area ID. One or more router adjacencies may develop over an interface. A router's LSAs reflect the state of its interfaces and their associated adjacencies.
OSPFインターフェースは、接続されたネットワークを含むエリアに属していると見なすことができます。このインターフェイスを介してルータから発信されたすべてのルーティングプロトコルパケットには、インターフェイスのエリアIDのラベルが付けられています。 1つまたは複数のルーター隣接関係がインターフェース上で発生する場合があります。ルーターのLSAは、そのインターフェースの状態と関連する隣接関係を反映しています。
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、ポイントツーマルチポイント、または仮想リンクです。
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.
状態インターフェースの機能レベル。状態は、完全な隣接関係がインターフェースを介して形成できるかどうかを決定します。状態はルーターのLSAにも反映されます。
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インターフェースマスクサブネットマスクとも呼ばれ、接続されたネットワークを識別する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.
Area ID接続されたネットワークが属するエリアのエリアID。インターフェイスから発信されたすべてのルーティングプロトコルパケットには、このエリアIDのラベルが付けられています。
HelloInterval The length of time, in seconds, between the Hello packets that the router sends on the interface. Advertised in Hello packets sent out this interface.
HelloIntervalルーターがインターフェイスで送信するHelloパケット間の時間の長さ（秒単位）。このインターフェイスから送信された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パケットの受信を停止したときに、ルーターのネイバーがダウンを宣言するまでの秒数。このインターフェイスから送信された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このインターフェースを介してリンク状態更新パケットを送信するのにかかる推定秒数。リンク状態更新パケットに含まれているLSAは、送信前にこの量だけ経過時間を増加させます。この値は、送信と伝搬の遅延を考慮に入れる必要があります。ゼロより大きくなければなりません。
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.
ルーター優先順位8ビットの符号なし整数。ネットワークに接続されている2つのルーターが両方とも指定ルーターになろうとする場合、最も高いルーター優先度を持つルーターが優先されます。ルーター優先度が0に設定されているルーターは、接続されたネットワークで指定ルーターになる資格がありません。このインターフェイスから送信された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.
Helloタイマーインターフェイスに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.
待機タイマーインターフェースを待機状態から抜けさせるシングルショットタイマー。結果として、ネットワーク上の指定ルーターを選択します。タイマーの長さは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 these neighbors. The set of adjacent neighbors can be determined by an examination of all of the neighbors' states.
近隣ルーターのリストこのネットワークに接続されている他のルーター。このリストは、Helloプロトコルによって形成されます。これらのネイバーの一部に対して隣接関係が形成されます。隣接する近傍のセットは、近傍のすべての状態を調べることによって決定できます。
Designated Router The Designated Router selected for the attached network. The Designated Router is selected on all broadcast and NBMA networks by the Hello Protocol. Two pieces of identification are kept for the Designated Router: its Router ID and its IP interface address on the network. The Designated Router advertises link state for the network; this network-LSA is labelled with the Designated Router's IP address. The Designated Router is initialized to 0.0.0.0, which indicates the lack of a Designated Router.
指定ルーター接続ネットワーク用に選択された指定ルーター。指定ルーターは、Helloプロトコルにより、すべてのブロードキャストおよびNBMAネットワークで選択されます。指定ルーターには、ルーターIDとネットワーク上のIPインターフェースアドレスの2つの識別情報が保持されます。指定ルーターは、ネットワークのリンク状態を通知します。このネットワークLSAは、代表ルーターのIPアドレスでラベル付けされています。指定ルーターは0.0.0.0に初期化されますが、これは指定ルーターがないことを示しています。
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.
バックアップ指定ルーターバックアップ指定ルーターは、HelloプロトコルによってすべてのブロードキャストおよびNBMAネットワークでも選択されます。接続されたネットワーク上のすべてのルーターは、指定ルーターとバックアップ指定ルーターの両方に隣接します。バックアップ指定ルーターは、現在の指定ルーターに障害が発生すると指定ルーターになります。バックアップ指定ルーターは0.0.0.0に初期化され、バックアップ指定ルーターがないことを示します。
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.
Interface output cost（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再送信間の秒数。データベース記述およびリンク状態要求パケットを再送信するときにも使用されます。
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接続されたネットワーク/サブネットで使用される認証のタイプ。認証タイプは付録Dで定義されています。すべてのOSPFパケット交換が認証されます。異なるネットワーク/サブネットで異なる認証スキームを使用できます。
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).
認証キーこの構成されたデータにより、認証手順でOSPFプロトコルパケットを生成または検証できます。認証キーは、インターフェイスごとに構成できます。たとえば、AuTypeが単純なパスワードを示している場合、認証キーは、OSPFパケットヘッダーに挿入される64ビットのクリアパスワードになります。代わりに、Autypeが暗号化認証を示している場合、認証キーは、OSPFプロトコルパケットに追加されるメッセージダイジェストの生成/検証を可能にする共有秘密です。暗号化認証を使用する場合、スムーズなキー移行を実現するために、複数の同時キーがサポートされます（セクション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.
このセクションでは、ルーターインターフェイスが取得するさまざまな状態について説明します。状態は、機能の進行順にリストされています。たとえば、動作不能状態が最初にリストされ、その後、最終的な完全に機能する状態が達成される前に中間状態のリストが続きます。仕様では、「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.
Downこれは、初期インターフェース状態です。この状態では、下位レベルのプロトコルは、インターフェイスが使用できないことを示しています。このようなインターフェイスでは、プロトコルトラフィックはまったく送受信されません。この状態では、インターフェイスパラメータを初期値に設定する必要があります。すべてのインターフェイスタイマーを無効にし、インターフェイスに隣接関係を関連付けないようにする必要があります。
Loopback In this state, the router's interface to the network is
ループバックこの状態では、ネットワークへのルーターのインターフェースは
+----+ UnloopInd +--------+
|Down|<--------------|Loopback|
+----+ +--------+
|
|InterfaceUp
+-------+ | +--------------+
|Waiting|<-+-------------->|Point-to-point|
+-------+ +--------------+
|
WaitTimer|BackupSeen
|
|
| NeighborChange
+------+ +-+<---------------- +-------+
|Backup|<----------|?|----------------->|DROther|
+------+---------->+-+<-----+ +-------+
Neighbor | |
Change | |Neighbor
| |Change
| +--+
+---->|DR|
+--+
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は常にダウン状態を強制し、Event LoopIndは常にループバック状態を強制します
looped back. The interface may be looped back in hardware or software. The interface will be unavailable for regular data traffic. However, it may still be desirable to gain information on the quality of this interface, either through sending ICMP pings to the interface or through something like a bit error test. For this reason, IP packets may still be addressed to an interface in Loopback state. To facilitate this, such interfaces are advertised in router-LSAs as single host routes, whose destination is the IP interface address.[4]
ループバック。インターフェイスは、ハードウェアまたはソフトウェアでループバックできます。このインターフェースは、通常のデータトラフィックには使用できません。ただし、ICMP pingをインターフェイスに送信するか、ビットエラーテストなどを使用して、このインターフェイスの品質に関する情報を取得することが望ましい場合があります。このため、ループバック状態のインターフェイスにIPパケットが送信される場合があります。これを容易にするために、このようなインターフェイスは、宛先がIPインターフェイスアドレスである単一のホストルートとしてルーターLSAでアドバタイズされます。[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.
待機この状態では、ルーターはネットワークの（バックアップ）指定ルーターのIDを判別しようとしています。これを行うために、ルーターは受信したHelloパケットを監視します。ルーターは、待機状態から移行するまで、バックアップ指定ルーターまたは指定ルーターを選出することはできません。これにより、（バックアップ）指定ルーターの不要な変更が防止されます。
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.
ポイントツーポイントこの状態では、インターフェイスは動作しており、物理的なポイントツーポイントネットワークまたは仮想リンクに接続しています。この状態になると、ルーターは隣接ルーターとの隣接関係を形成しようとします。 Helloパケットは、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その他インターフェイスは、別のルーターが指定ルーターとして選択されているブロードキャストまたはNBMAネットワークへのインターフェースです。この状態では、ルーター自体もバックアップ指定ルーターとして選択されていません。ルーターは、指定ルーターとバックアップ指定ルーター（存在する場合）の両方に隣接関係を形成します。
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.
バックアップこの状態では、ルーター自体が接続されたネットワーク上のバックアップ指定ルーターです。現在の指定ルーターに障害が発生すると、指定ルーターに昇格します。ルーターは、ネットワークに接続されている他のすべてのルーターとの隣接関係を確立します。バックアップ指定ルーターは、指定ルーターと比較して、フラッディング手順中にわずかに異なる機能を実行します（セクション13.3を参照）。バックアップ指定ルーターによって実行される機能の詳細については、セクション7.4を参照してください。
DR In this state, this router itself is the Designated Router on the attached network. Adjacencies are established to all other routers attached to the network. The router must also originate a network-LSA for the network node. The network-LSA will contain links to all routers (including the Designated Router itself) attached to the network. See Section 7.3 for more details on the functions performed by the Designated Router.
DRこの状態では、このルーター自体が、接続されたネットワーク上の指定ルーターです。隣接関係は、ネットワークに接続されている他のすべてのルーターに対して確立されます。ルーターは、ネットワークノードのネットワークLSAも発信する必要があります。ネットワークLSAには、ネットワークに接続されているすべてのルーター（指定ルーター自体を含む）へのリンクが含まれます。指定ルーターによって実行される機能の詳細については、セクション7.3を参照してください。
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下位レベルのプロトコルは、ネットワークインターフェイスが機能していることを示しています。これにより、インターフェイスはダウン状態から移行できます。仮想リンクでは、インターフェースの動作表示は実際には最短経路計算の結果です（セクション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待機タイマーが作動し、（バックアップ）指定ルーターを選択する前に必要な待機期間の終了を示しています。
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ルーターは、ネットワークのバックアップ指定ルーターの存在または非存在を検出しました。これは、2つの方法のいずれかで行われます。最初に、Helloパケットは、それ自体がバックアップ代表ルータであると主張するネイバーから受信されます。または、自分自身が指定ルーターであることを主張し、バックアップ指定ルーターがないことを示すHelloパケットをネイバーから受信することもできます。どちらの場合も、ネイバーとの双方向通信が必要です。つまり、ルーターもネイバーのHelloパケットに含まれている必要があります。このイベントは、待機状態の終了を通知します。
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インターフェイスに関連付けられた双方向ネイバーのセットに変更がありました。 （バックアップ）指定ルーターを再計算する必要があります。次のネイバーの変更により、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-Way以上に遷移しています。
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 双方向ネイバーの1つが、指定ルータまたはバックアップ指定ルータとして自分自身を新たに宣言しています。これは、そのネイバーのHelloパケットを調べることで検出されます。
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 双方向ネイバーの1つが指定ルーターとして宣言されなくなったか、バックアップ指定ルーターとして宣言されなくなりました。これは、そのネイバーのHelloパケットを調べることによって再び検出されます。
o The advertised Router Priority for a bidirectional neighbor has changed. This is again detected through examination of that neighbor's Hello Packets.
o 双方向ネイバーのアドバタイズされたルータプライオリティが変更されました。これは、そのネイバーのHelloパケットを調べることによって再び検出されます。
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インターフェイスがループバックされたことを示す通知が受信されました。この表示は、ネットワーク管理または下位レベルのプロトコルのいずれかから受信できます。
UnloopInd An indication has been received that the interface is no longer looped back. As with the LoopInd event, this indication can be received either from network management or from the lower level protocols.
UnloopIndインターフェイスがループバックされなくなったという通知を受け取りました。 LoopIndイベントと同様に、この指標はネットワーク管理または低レベルのプロトコルから受信できます。
InterfaceDown Lower-level protocols indicate that this interface is no longer functional. No matter what the current interface state is, the new interface state will be Down.
InterfaceDown低レベルのプロトコルは、このインターフェイスが機能しなくなったことを示します。現在のインターフェイスの状態が何であっても、新しいインターフェイスの状態はダウンになります。
9.3. The Interface state machine
9.3. インターフェイスステートマシン
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パケットを定期的にインターフェイスから送信できるようにします。接続されているネットワークが物理的なポイントツーポイントネットワーク、ポイントツーマルチポイントネットワーク、または仮想リンクの場合、インターフェイスの状態はポイントツーポイントに移行します。そうでない場合、ルーターが指定ルーターになる資格がない場合、インターフェースの状態はDRその他に遷移します。
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ネットワークであり、ルーターは指定ルーターになる資格があります。この場合、接続されているネットワークの指定ルーターを検出するために、インターフェイスの状態が待機中に設定され、シングルショットの待機タイマーが開始されます。さらに、ネットワークがNBMAネットワークの場合は、このインターフェースに構成されたネイバーのリストを調べ、指定ルーターになる資格がある各ネイバーのネイバーイベント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に示すように、接続されているネットワークのバックアップ指定ルーターと指定ルーターを計算します。この計算の結果、インターフェースの新しい状態は、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に示すように、接続されているネットワークのバックアップ指定ルーターと指定ルーターを計算します。この計算の結果、インターフェースの新しい状態は、DR Other、Backup、またはDRになります。
State(s): DR Other, Backup or DR
状態：DRその他、バックアップまたはDR
Event: NeighborChange
イベント：NeighborChange
New state: Depends upon action routine.
新しい状態：アクションルーチンによって異なります。
Action: Recalculate the attached network's Backup Designated Router and Designated Router, as shown in Section 9.4. As a result of this calculation, the new state of the interface will be either DR Other, Backup or DR.
アクション：セクション9.4に示すように、接続されているネットワークのバックアップ指定ルーターと指定ルーターを再計算します。この計算の結果、インターフェースの新しい状態は、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 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.
このセクションでは、ネットワークの指定ルーターとバックアップ指定ルーターの計算に使用されるアルゴリズムについて説明します。このアルゴリズムは、インターフェイスステートマシンによって呼び出されます。ルーターがネットワークの選択アルゴリズムを最初に実行するとき、ネットワークの指定ルーターとバックアップ指定ルーターは0.0.0.0に初期化されます。これは、指定ルーターとバックアップ指定ルーターの両方が不足していることを示しています。
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:
指定ルーター選定アルゴリズムは次のように進行します。ルーターXを計算するルーターを呼び出します。ネットワークに接続され、ルーターXとの双方向通信を確立したネイバーのリストが検査されます。このリストは、状態が2ウェイ以上の（このネットワーク上の）ルーターXのネイバーのコレクションです（セクション10.1を参照）。ルーターX自体もリストに含まれていると見なされます。指定ルーターになる資格がないすべてのルーターをリストから破棄します。 （ルーター優先度が0のルーターは、指定ルーターになる資格がありません。）次に、リストに残っているルーターのみを考慮して、次の手順が実行されます。
(1) Note the current values for the network's Designated Router and Backup Designated Router. This is used later for comparison purposes.
（1）ネットワークの指定ルーターとバックアップ指定ルーターの現在の値をメモします。これは後で比較の目的で使用されます。
(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, 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.
（2）ネットワークの新しいバックアップ指定ルーターを次のように計算します。指定ルーターであると宣言されていないリスト上のルーターのみが、バックアップ指定ルーターになる資格があります。これらのルーターの1つまたは複数が自分自身をバックアップ指定ルーターとして宣言している場合（つまり、それらのルーターがHelloパケットでバックアップ指定ルーターとしてリストされているが、指定ルーターとしてリストされていない場合）、ルーター優先度が最も高いルーターがバックアップ指定ルーターとして宣言されます。 。同数の場合、最も高いルーターIDを持つものが選択されます。ルーターが自分自身をバックアップ指定ルーターとして宣言していない場合は、最も高いルーター優先度を持つルーターを選択し（ここでも、自分自身が指定ルーターを宣言しているルーターを除外する）、再度ルーター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）ネットワークの新しい指定ルーターを次のように計算します。 1つ以上のルーターが指定ルーターを宣言している場合（つまり、現在、それらのルーターがHelloパケットで指定ルーターとしてリストされている場合）、ルーター優先度が最も高いルーターが指定ルーターとして宣言されます。同数の場合、最も高いルーターIDを持つものが選択されます。指定ルーターを宣言したルーターがない場合は、指定ルーターを新しく選択されたバックアップ指定ルーターと同じになるように割り当てます。
(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）ルーターXが新しく指定ルーターまたはバックアップ指定ルーターになった場合、または指定ルーターまたはバックアップ指定ルーターでなくなった場合は、手順2と3を繰り返し、手順5に進みます。たとえば、 、ルーターXが指定ルーターになった場合、ステップ2を繰り返すと、Xはバックアップ指定ルーターの選択に適格ではなくなります。特に、これにより、ルーターがバックアップ指定ルーターと指定ルーターの両方を宣言しないことが保証されます。[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）これらの計算の結果、ルーター自体が指定ルーターまたはバックアップ指定ルーターになる可能性があります。これに伴う追加の義務については、セクション7.3および7.4を参照してください。ルータのインターフェース状態はそれに応じて設定する必要があります。ルーター自体が指定ルーターになった場合、新しいインターフェース状態はDRです。ルータ自体がバックアップ指定ルータになった場合、新しいインターフェイスの状態はバックアップです。それ以外の場合、新しいインターフェースの状態は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ネットワークであり、ルーター自体が指定ルーターまたはバックアップ指定ルーターになったばかりの場合、指定ルーターになる資格のないネイバーへのHelloパケットの送信を開始する必要があります（セクション9.5.1を参照）。 ）。これは、ルータプライオリティが0の各ネイバーに対してネイバーイベントの開始を呼び出すことによって行われます。
(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）上記の計算により指定ルーターまたはバックアップ指定ルーターのIDが変更された場合、このインターフェースに関連付けられた一連の隣接関係を変更する必要があります。隣接関係を形成する必要がある場合もあれば、破壊する必要がある場合もあります。これを行うには、イベントAdjOK？状態が少なくとも2-Wayであるすべてのネイバー。これにより、隣接関係の適格性が再調査されます（セクション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.
選挙アルゴリズムの複雑さの背後にある理由は、現在の指定ルーターに障害が発生したときに、バックアップ指定ルーターから指定ルーターに整然と移行したいという要望です。この整然とした移行は、ヒステリシスの導入によって保証されます。古いバックアップが新しい指定ルーターの責任を受け入れるまで、新しいバックアップ指定ルーターを選択することはできません。
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.
上記の手順では、同じルーターを指定ルーターとバックアップ指定ルーターの両方として選択できますが、そのルーター自体が計算ルーター（ルーターX）になることはありません。選出された指定ルーターは、最も高いルーター優先度を持つルーターであるとは限りません。また、バックアップ指定ルーターが2番目に高いルーター優先度を持つ必要はありません。ルーターX自体が指定ルーターになる資格がない場合、上記の手順でバックアップ指定ルーターも指定ルーターも選択されない可能性があります。また、ルーターXが指定ルーターになる資格のある唯一の接続ルーターである場合は、それ自体が指定ルーターとして選択され、ネットワークのバックアップ指定ルーターが存在しないことにも注意してください。
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.
Helloパケットは、機能している各ルーターインターフェイスから送信されます。それらは隣人関係を発見し維持するために使用されます。[6]ブロードキャストネットワークとNBMAネットワークでは、Helloパケットは指定ルーターとバックアップ指定ルーターの選択にも使用されます。
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パケットには、ルーターのルーター優先度（指定ルーターの選択に使用）と、インターフェイスから送信されるHelloパケットの間隔（HelloInterval）が含まれています。 Helloパケットは、アクティブな状態を維持するためにネイバーからの応答が必要な頻度も示します（RouterDeadInterval）。 HelloIntervalとRouterDeadIntervalは、共通のネットワークに接続されているすべてのルーターで同じでなければなりません。 Helloパケットには、接続されているネットワークの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パケットの[オプション]フィールドには、ルーターのオプションのOSPF機能が記述されています。この仕様では、1つのオプション機能が定義されています（セクション4.5およびA.2を参照）。接続されたエリアがAS-external-LSAを処理できる場合（つまり、スタブエリアではない場合）に限り、オプションフィールドのEビットを設定する必要があります。 Eビットが正しく設定されていない場合、隣接するルーターはHelloパケットの受け入れを拒否します（セクション10.5を参照）。 Helloパケットのオプションフィールドの認識されないビットはゼロに設定する必要があります。
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パケットが最近確認されたネットワーク上のすべてのルーターのリストが含まれています。 Helloパケットには、ルーターの現在の指定ルーターとバックアップ指定ルーターの選択肢も含まれています。これらのフィールドの値が0.0.0.0の場合、まだ選択されていません。
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.
ブロードキャストネットワークと物理的なポイントツーポイントネットワークでは、HelloパケットがHelloInterval秒ごとにIPマルチキャストアドレスAllSPFRoutersに送信されます。仮想リンクでは、HelloパケットはHelloInterval秒ごとにユニキャストとして送信されます（仮想リンクのもう一方の端に直接アドレス指定されます）。ポイントツーマルチポイントネットワークでは、HelloInterval秒ごとに、接続されている各ネイバーに個別のHelloパケットが送信されます。 NBMAネットワークでのHelloパケットの送信については、次のセクションで説明します。
9.5.1. Sending Hello packets on NBMA networks
9.5.1. NBMAネットワークでのHelloパケットの送信
Static configuration information may be necessary in order for the Hello Protocol to function on non-broadcast networks (see Sections C.5 and C.6). On NBMA networks, every attached router which is eligible to become Designated Router becomes aware of all of its neighbors on the network (either through configuration or by some unspecified mechanism). Each neighbor is labelled with the neighbor's Designated Router eligibility.
Helloプロトコルが非ブロードキャストネットワークで機能するためには、静的構成情報が必要な場合があります（セクションC.5およびC.6を参照）。 NBMAネットワークでは、指定ルーターになる資格のあるすべての接続ルーターが、ネットワーク上のすべての隣接ルーターを認識します（構成または特定されていないメカニズムによって）。各ネイバーには、ネイバーの代表ルータの適格性がラベル付けされています。
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パケットがNBMAインターフェイスから送信されるのを待機している必要があります。 Helloパケットは、ルーターのネイバーのサブセットに直接（ユニキャストとして）送信されます。 Helloパケットがタイマーで定期的に送信されることがあります。それ以外の場合は、受信したHelloパケットへの応答として送信されます。ルーターのhello送信動作は、ルーター自体が代表ルーターになる資格があるかどうかによって異なります。
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.
ルーターが指定ルーターになる資格がある場合、適格であるすべてのネイバーに定期的にHelloパケットを送信する必要があります。さらに、ルータ自体が指定ルータまたはバックアップ指定ルータである場合、他のすべてのネイバーに定期的にHelloパケットを送信する必要もあります。これは、2つの適格なルーターが常にHelloパケットを交換していることを意味します。これは、代表ルーター選定アルゴリズムが正しく動作するために必要です。送信されるHelloパケットの数を最小限に抑えるには、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.
ルーターが指定ルーターになる資格がない場合、指定ルーターとバックアップ指定ルーター（存在する場合）の両方に定期的にHelloパケットを送信する必要があります。また、適格なネイバー（現在の指定ルーターとバックアップ指定ルーター以外）から受信したHelloパケットに応答して、Helloパケットを送信する必要もあります。これは、潜在的な指定ルーターとの初期の双方向関係を確立するために必要です。
When sending Hello packets periodically to any neighbor, the interval between Hello Packets is determined by the neighbor's state. If the neighbor is in state Down, Hello Packets are sent every PollInterval seconds. Otherwise, Hello Packets are sent every HelloInterval seconds.
Helloパケットを定期的にネイバーに送信する場合、Helloパケットの間隔はネイバーの状態によって決まります。ネイバーがダウン状態の場合、HelloパケットはPollInterval秒ごとに送信されます。それ以外の場合、HelloパケットはHelloInterval秒ごとに送信されます。
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ルーターIDまたはその隣接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.
非アクティブタイマーシングルショットタイマー。その発火により、最近このネイバーからHelloパケットが検出されていないことが示されます。タイマーの長さは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つのネイバーがデータベースを交換しているとき、それらはマスター/スレーブ関係を形成します。マスターは最初のデータベース記述パケットを送信し、再送信を許可される唯一の部分です。スレーブは、マスターのデータベース記述パケットにのみ応答できます。マスターとスレーブの関係は、ExStart状態でネゴシエートされます。
DD Sequence Number The DD Sequence number of the Database Description packet that is currently being sent to the neighbor.
DDシーケンス番号現在ネイバーに送信されているデータベース記述パケットのDDシーケンス番号。
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.
最後に受信したデータベース記述パケット初期化（I）、追加（M）およびマスター（MS）ビット、オプションフィールド、およびネイバーから受信した最後のデータベース記述パケットに含まれるDDシーケンス番号。ネイバーから受信した次のデータベース記述パケットが重複しているかどうかを判断するために使用されます。
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ルーターID。ネイバー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.
Neighbor Priority隣接ルーターのルーター優先度。ネイバーの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アドレス。プロトコルパケットがこの隣接に沿ってユニキャストとして送信されるときに、宛先IPアドレスとして使用されます。ルーターLSAでは、隣接ルーターが指定ルーターとして選択されている場合に、接続されたネットワークのリンクIDとしても使用されます（セクション12.4.1を参照）。ネイバーIPアドレスは、Helloパケットがネイバーから受信されたときに学習されます。仮想リンクの場合、ネイバー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機能。データベース交換プロセス中に学習した（10.6項を参照）。ネイバーのオプションのOSPF機能も、Helloパケットにリストされています。これにより、特定の重要なOSPF機能に不一致がある場合（セクション10.5を参照）、受信したHelloパケットを拒否できます（つまり、ネイバー関係が形成されなくなることもあります）。オプションのOSPF機能については、セクション4.5で説明しています。
Neighbor's Designated Router The neighbor's idea of the Designated Router. If this is the neighbor itself, this is important in the local calculation of the Designated Router. Defined only on broadcast and NBMA networks.
ネイバーの代表ルーターネイバーの代表ルーターのアイデア。これがネイバー自体である場合、これは指定ルーターのローカル計算で重要です。ブロードキャストおよび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.
ネイバーのバックアップ指定ルーターネイバーのバックアップ指定ルーターのアイデア。これがネイバー自体である場合、これはバックアップ代表ルータのローカル計算で重要です。ブロードキャストおよび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).
次の変数セットはLSAのリストです。これらのリストは、エリアリンク状態データベースのサブセットについて説明しています。このメモは、5つの異なるタイプのLSAを定義します。これらはすべてエリアリンク状態データベースに存在する可能性があります。ルーターLSA、ネットワークLSA、タイプ3および4サマリーLSA（すべてエリアデータ構造に格納）、およびAS外部LSA（グローバルデータ構造に格納されます）。
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.
リンク状態再送信リストフラッディングされたが、この隣接で確認されていないLSAのリスト。これらは、確認されるまで、または隣接が破棄されるまで、一定の間隔で再送信されます。
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.
データベースサマリリストネイバーがデータベース交換状態になった時点で、エリアリンク状態データベースを構成するLSAの完全なリスト。このリストは、データベース記述パケットでネイバーに送信されます。
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つのネイバーのリンク状態データベースを同期するために、このネイバーから受信する必要があるLSAのリスト。このリストは、データベース記述パケットが受信されると作成され、リンク状態要求パケットでネイバーに送信されます。適切なリンク状態更新パケットが受信されると、リストは空になります。
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.
ネイバーの状態（実際には、ネイバールータとの会話の状態）については、次のセクションで説明します。状態は、機能の進行順にリストされています。たとえば、動作不能状態が最初にリストされ、その後、最終的な完全に機能する状態が達成される前に中間状態のリストが続きます。仕様では、「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つのルータは完全に隣接していると言います。この時点で、隣接関係はLSAにリストされています。
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).
Downこれは、ネイバーカンバセーションの初期状態です。これは、ネイバーから受信した最近の情報がないことを示しています。 NBMAネットワークでは、頻度は低くなりますが、「ダウン」ネイバーにHelloパケットが送信される場合があります（セクション9.5.1を参照）。
+----+
|Down|
+----+
|\
| \Start
| \ +-------+
Hello | +---->|Attempt|
Received | +-------+
| |
+----+<-+ |HelloReceived
|Init|<---------------+
+----+<--------+
| |
|2-Way |1-Way
|Received |Received
| |
+-------+ | +-----+
|ExStart|<--------+------->|2-Way|
+-------+ +-----+
Figure 12: Neighbor state changes (Hello Protocol)
図12：ネイバーの状態変化（Helloプロトコル）
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
写真の状態遷移に加えて、イベントKillNbrは常にダウン状態を強制し、イベントInactivityTimerは常にダウン状態を強制し、イベントLLDownは常にダウン状態を強制します
+-------+
|ExStart|
+-------+
|
NegotiationDone|
+->+--------+
|Exchange|
+--+--------+
|
Exchange|
Done |
+----+ | +-------+
|Full|<---------+----->|Loading|
+----+<-+ +-------+
| 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
写真の状態遷移に加えて、イベントSeqNumberMismatchはExStart状態を強制し、イベントBadLSReqはExStart状態を強制し、イベント1方向はInit状態を強制し、イベントKillNbrは常にダウン状態を強制し、イベントInactivityTimerは常にダウン状態を強制し、イベントLLDownは常にダウン状態を強制し、イベント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ネットワークに接続されているネイバーにのみ有効です。これは、最近の情報が近隣から受信されていないことを示していますが、近隣と連絡を取るためにより多くの努力が必要です。これは、HelloIntervalの間隔で近隣のHelloパケットを送信することによって行われます（セクション9.5.1を参照）。
Init In this state, an Hello packet has recently been seen from the neighbor. However, bidirectional communication has not yet been established with the neighbor (i.e., the router itself did not appear in the neighbor's Hello packet). All neighbors in this state (or higher) are listed in the Hello packets sent from the associated interface.
Initこの状態では、Helloパケットが最近ネイバーから見られました。ただし、ネイバーとの双方向通信はまだ確立されていません（つまり、ルーター自体がネイバーのHelloパケットに含まれていませんでした）。この状態（またはそれ以上）のネイバーはすべて、関連するインターフェースから送信されるHelloパケットにリストされます。
2-Way In this state, communication between the two routers is bidirectional. This has been assured by the operation of the Hello Protocol. This is the most advanced state short of beginning adjacency establishment. The (Backup) Designated Router is selected from the set of neighbors in state 2-Way or greater.
双方向この状態では、2つのルーター間の通信は双方向です。これは、Helloプロトコルの動作によって保証されています。これは、隣接関係の確立を開始する前の最も進んだ状態です。 （バックアップ）指定ルーターは、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これは、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.
Exchangeこの状態では、ルータはデータベース記述パケットをネイバーに送信することにより、リンク状態データベース全体を記述しています。各データベース記述パケットにはDDシーケンス番号があり、明示的に確認されます。一度に未処理のままにできるデータベース記述パケットは1つだけです。この状態では、リンク状態要求パケットも送信され、ネイバーの最新のLSAを要求します。 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状態で検出された（まだ受信されていない）より新しいLSAを要求します。
Full In this state, the neighboring routers are fully adjacent. These adjacencies will now appear in router-LSAs and network-LSAs.
完全この状態では、隣接するルーターは完全に隣接しています。これらの隣接関係は、ルーターLSAとネットワークLSAに表示されます。
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 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.
開始これは、HelloパケットがHelloInterval秒間隔でネイバーに送信されるようになったことを示します。このイベントは、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 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.
NegotiationDoneマスター/スレーブ関係が交渉され、DDシーケンス番号が交換されました。これは、データベース記述パケットの送受信の開始を示します。このイベントの生成の詳細については、セクション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両方のルーターが、一連のデータベース記述パケットを正常に送信しました。各ルーターは、リンク状態データベースのどの部分が古くなっているのかを認識しています。このイベントの生成の詳細については、セクション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.
BadLSReqデータベースに含まれていないLSAに対するリンク状態要求が受信されました。これは、データベース交換プロセスのエラーを示しています。
Loading Done Link State Updates have been received for all out-of-date portions of the database. This is indicated by the Link state request list becoming empty after the Database Exchange process has completed.
データベースのすべての古くなった部分について、リンク状態の更新が読み込まれました。これは、データベース交換プロセスの完了後にリンク状態要求リストが空になることで示されます。
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）予期しないDDシーケンス番号が含まれている、b）予期せずInitビットが設定されている、またはc）データベース記述パケットで受信した最後のオプションフィールドとは異なるオプションフィールドが含まれています。これらの条件のいずれかは、隣接関係の確立中に何らかのエラーが発生したことを示しています。
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ウェイHelloパケットがネイバーから受信されましたが、ルータには言及されていません。これは、ネイバーとの通信が双方向ではないことを示しています。
KillNbr This is an indication that all communication with the neighbor is now impossible, forcing the neighbor to revert to Down state.
KillNbrこれは、ネイバーとのすべての通信が不可能になり、ネイバーが強制的にダウン状態に戻ることを示しています。
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非アクティブタイマーが発生しました。これは、helloパケットが最近ネイバーから見られていないことを意味します。ネイバーはダウン状態に戻ります。
LLDown This is an indication from the lower level protocols that the neighbor is now unreachable. For example, on an X.25 network this could be indicated by an X.25 clear indication with appropriate cause and diagnostic fields. This event forces the neighbor into Down state.
LLDownこれは、ネイバーが現在到達不能であることを低レベルのプロトコルから示しています。たとえば、X.25ネットワークでは、これは適切な原因と診断フィールドを備えたX.25クリア表示によって示される可能性があります。このイベントは、ネイバーを強制的にダウン状態にします。
10.3. The Neighbor state machine
10.3. ネイバーステートマシン
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).
ネイバーの状態が変化した場合、代表ルータ選定アルゴリズムを再実行する必要があるかもしれません。これは、インターフェースNeighborChangeイベントが生成されるかどうかによって決定されます（セクション9.2を参照）。また、インターフェースがDR状態（ルーター自体が指定ルーター）の場合、ネイバー状態の変更により、新しいネットワーク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パケットをネイバーに送信し（このネイバーは常にNBMAネットワークに関連付けられています）、ネイバーの非アクティブタイマーを開始します。タイマーの後での発火は、ネイバーとの通信が達成されなかったことを示します。
State(s): Attempt
状態：試み
Event: HelloReceived
イベント：HelloReceived
New state: Init
新しい状態：Init
Action: Restart the Inactivity Timer for the neighbor, since the neighbor has now been heard from.
アクション：ネイバーからの応答があったため、ネイバーの非アクティブタイマーを再起動します。
State(s): Down
状態：ダウン
Event: HelloReceived
イベント：HelloReceived
New state: Init
新しい状態：Init
Action: Start the Inactivity Timer for the neighbor. The timer's later firing would indicate that the neighbor is dead.
アクション：ネイバーの非アクティブタイマーを開始します。タイマーが後で発火した場合は、ネイバーが死んでいることを示します。
State(s): Init or greater
州：Init以上
Event: HelloReceived
イベント：HelloReceived
New state: No state change.
新しい状態：状態は変化しません。
Action: Restart the Inactivity Timer for the neighbor, since the neighbor has again been heard from.
アクション：ネイバーからの応答があったため、ネイバーの非アクティブタイマーを再起動します。
State(s): Init
州：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項を参照）。そうでない場合、新しいネイバー状態は双方向です。
Otherwise (an adjacency should be established) the neighbor state transitions to ExStart. Upon entering this state, the router increments the DD sequence number in the neighbor data structure. If this is the first time that an adjacency has been attempted, the DD sequence number should be assigned some unique value (like the time of day clock). It then declares itself master (sets the master/slave bit to master), and starts sending Database Description Packets, with the initialize (I), more (M) and master (MS) bits set. This Database Description Packet should be otherwise empty. This Database Description Packet should be retransmitted at intervals of RxmtInterval until the next state is entered (see Section 10.8).
それ以外の場合（隣接関係を確立する必要があります）、ネイバーの状態はExStartに移行します。この状態になると、ルータはネイバーデータ構造のDDシーケンス番号を増分します。隣接が初めて試行された場合は、DDシーケンス番号に一意の値（時刻など）を割り当てる必要があります。次に、自身をマスターとして宣言し（マスター/スレーブビットをマスターに設定）、データベース記述パケットの送信を開始し、初期化（I）、追加（M）、マスター（MS）ビットを設定します。それ以外の場合、このデータベース記述パケットは空でなければなりません。このデータベース記述パケットは、次の状態に入るまで、RxmtIntervalの間隔で再送信する必要があります（セクション10.8を参照）。
State(s): ExStart
状態（s）：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.
処置：ルーターは、エリアリンク状態データベース全体の内容をネイバーデータベースのサマリーリストにリストする必要があります。エリアリンク状態データベースは、エリア構造に含まれるルーターLSA、ネットワークLSA、サマリーLSA、およびグローバル構造に含まれるAS外部LSAで構成されます。 ASの外部LSAは、仮想ネイバーのデータベースサマリーリストから省略されます。エリアがスタブとして構成されている場合（セクション3.6を参照）、AS-external-LSAはDatabase summaryリストから省略されます。エージがMaxAgeと等しいLSAは、代わりにネイバーのリンク状態再送信リストに追加されます。データベースサマリーリストのサマリーは、データベース記述パケットでネイバーに送信されます。各データベース記述パケットにはDDシーケンス番号があり、明示的に確認されます。一度に未処理のままにできるデータベース記述パケットは1つだけです。データベース記述パケットの送受信の詳細については、セクション10.8および10.6を参照してください。
State(s): Exchange
州：交換
Event: ExchangeDone
イベント：ExchangeDone
New state: Depends upon action routine.
新しい状態：アクションルーチンによって異なります。
Action: If the neighbor Link state request list is empty, the new neighbor state is Full. No other action is required. This is an adjacency's final state.
アクション：ネイバーリンク状態要求リストが空の場合、新しいネイバー状態はフルです。他のアクションは必要ありません。これが隣接の最終状態です。
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.
それ以外の場合、新しいネイバーの状態はロード中です。リンク状態要求パケットのネイバーへの送信を開始（または続行）します（セクション10.9を参照）。これらは、ネイバーの最新のLSA（検出されたが、まだExchange状態で受信されていない）に対する要求です。これらのLSAは、ネイバーに関連付けられたリンク状態要求リストにリストされています。
State(s): Loading
状態：読み込み中
Event: Loading Done
イベント：読み込み完了
New state: Full
新しい状態：フル
Action: No action required. This is an adjacency's final state.
アクション：アクションは不要です。これが隣接の最終状態です。
State(s): 2-Way
州：双方向
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項を参照）。そうでない場合、隣接状態は双方向のままです。それ以外の場合は、ネイバー状態をExStartに移行し、状態Initおよびイベント2-WayReceivedに対して上記の状態マシンエントリに関連付けられているアクションを実行します。
State(s): ExStart or greater
状態：ExStart以上
Event: AdjOK?
イベント：AdjOK？
New state: Depends upon action routine.
新しい状態：アクションルーチンによって異なります。
Action: Determine whether the neighboring router should still be adjacent. If yes, there is no state change and no further action is necessary.
処置：隣接ルーターを引き続き隣接させる必要があるかどうかを確認してください。はいの場合、状態は変化せず、それ以上のアクションは必要ありません。
Otherwise, the (possibly partially formed) adjacency must be destroyed. The neighbor state transitions to 2-Way. The Link state retransmission list, Database summary list and Link state request list are cleared of LSAs.
それ以外の場合は、（おそらく部分的に形成された）隣接関係を破棄する必要があります。ネイバーステートは2-Wayに移行します。リンク状態再送信リスト、データベースサマリリスト、リンク状態要求リストからLSAがクリアされます。
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に移行します。リンク状態再送信リスト、データベースサマリリスト、リンク状態要求リストからLSAがクリアされます。次に、ルーターはネイバーデータ構造のDDシーケンス番号をインクリメントし、自身をマスターとして宣言し（マスター/スレーブビットをマスターに設定）、データベース記述パケットの送信を初期化（I）、追加（M）、マスター（MS）で開始します。 ）ビットセット。それ以外の場合、このデータベース記述パケットは空である必要があります（セクション10.8を参照）。
State(s): Exchange or greater
州：交換以上
Event: BadLSReq
イベント：BadLSReq
New state: ExStart
新しい状態：ExStart
Action: The action for event BadLSReq is exactly the same as for the neighbor event SeqNumberMismatch. The (possibly partially formed) adjacency is torn down, and then an attempt is made at reestablishment. For more information, see the neighbor state machine entry that is invoked when event SeqNumberMismatch is generated in state Exchange or greater.
アクション：イベントBadLSReqのアクションは、隣接イベントSeqNumberMismatchのアクションとまったく同じです。 （おそらく部分的に形成された）隣接関係が切断され、再確立が試行されます。詳細については、状態Exchange以上でイベントSeqNumberMismatchが生成されたときに呼び出されるネイバーステートマシンのエントリを参照してください。
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.
アクション：リンク状態再送信リスト、データベース要約リスト、リンク状態要求リストからLSAがクリアされます。また、非アクティブタイマーは無効になります。
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.
アクション：リンク状態再送信リスト、データベース要約リスト、リンク状態要求リストからLSAがクリアされます。また、非アクティブタイマーは無効になります。
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.
アクション：リンク状態再送信リスト、データベース要約リスト、リンク状態要求リストからLSAがクリアされます。
State(s): 2-Way or greater
州：2ウェイ以上
Event: 1-WayReceived
イベント：1-WayReceived
New state: Init
新しい状態：Init
Action: The Link state retransmission list, Database summary list and Link state request list are cleared of LSAs.
アクション：リンク状態再送信リスト、データベース要約リスト、リンク状態要求リストからLSAがクリアされます。
State(s): 2-Way or greater
州：2ウェイ以上
Event: 2-WayReceived
イベント：2-WayReceived
New state: No state change.
新しい状態：状態は変化しません。
Action: No action required.
アクション：アクションは不要です。
State(s): Init
州：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.
隣接関係は、ルーターのネイバーのサブセットで確立されます。ポイントツーポイントネットワーク、ポイントツーマルチポイントネットワーク、および仮想リンクで接続されたルーターは常に隣接します。ブロードキャストおよびNBMAネットワークでは、すべてのルーターが指定ルーターとバックアップ指定ルーターの両方に隣接します。
The adjacency-forming decision occurs in two places in the neighbor state machine. First, when bidirectional communication is initially established with the neighbor, and secondly, when the identity of the attached network's (Backup) Designated Router changes. If the decision is made to not attempt an adjacency, the state of the neighbor communication stops at 2- Way.
隣接関係形成の決定は、ネイバーステートマシンの2つの場所で行われます。最初に、双方向通信が最初にネイバーと確立されたとき、次に、接続されたネットワークの（バックアップ）指定ルーターのIDが変更されたとき。隣接を試みないと決定した場合、ネイバー通信の状態は双方向で停止します。
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 基になるネットワークタイプはポイントツーマルチポイントです
o The underlying network type is virtual link
o 基本的なネットワークタイプは仮想リンクです
o The router itself is the Designated Router
o ルーター自体が指定ルーターです
o The router itself is the Backup Designated Router
o ルーター自体がバックアップ指定ルーターです
o The neighboring router is the Designated Router
o 隣接ルーターは指定ルーターです
o The neighboring router is the Backup Designated Router
o 隣接ルータはバックアップ指定ルータです
10.5. Receiving Hello Packets
10.5. Helloパケットの受信
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パケットの詳細な処理について説明します。 （Helloパケットの形式については、セクションA.3.2を参照してください。）OSPFパケットの汎用入力処理により、IPヘッダーとOSPFパケットヘッダーの有効性がチェックされます。次に、受信したHelloパケットのNetwork Mask、HelloInterval、RouterDeadIntervalの各フィールドの値を、受信インターフェイスに構成されている値と照合する必要があります。不一致があると、処理が停止し、パケットがドロップされます。つまり、上記のフィールドは、接続されたネットワークの構成を実際に説明しています。ただし、上記のルールには1つの例外があります。ポイントツーポイントネットワークおよび仮想リンクでは、受信したHelloパケットのネットワークマスクは無視する必要があります。
The receiving interface attaches to a single OSPF area (this could be the backbone). The setting of the E-bit found in the Hello Packet's Options field must match this area's ExternalRoutingCapability. If AS-external-LSAs are not flooded into/throughout the area (i.e, the area is a "stub") the E-bit must be clear in received Hello Packets, otherwise the E-bit must be set. A mismatch causes processing to stop and the packet to be dropped. The setting of the rest of the bits in the Hello Packet's Options field should be ignored.
受信インターフェイスは単一のOSPFエリアに接続します（これはバックボーンである可能性があります）。 HelloパケットのオプションフィールドにあるEビットの設定は、この領域のExternalRoutingCapabilityと一致する必要があります。 AS外部LSAがエリアにフラッディングされない（エリアが「スタブ」である）場合、受信されたHelloパケットでEビットがクリアされている必要があります。そうでない場合は、Eビットが設定されている必要があります。不一致があると、処理が停止し、パケットがドロップされます。 Helloパケットのオプションフィールドの残りのビットの設定は無視する必要があります。
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パケットのソースを受信インターフェイスのネイバーの1つと照合する試みが行われます。受信インターフェイスがブロードキャスト、ポイントツーマルチポイント、またはNBMAネットワークに接続する場合、ソースはHelloのIPヘッダーにあるIPソースアドレスで識別されます。受信インターフェイスがポイントツーポイントリンクまたは仮想リンクに接続する場合、ソースはHelloのOSPFパケットヘッダーにあるルーターIDによって識別されます。インターフェースの現在のネイバーのリストは、インターフェースのデータ構造に含まれています。一致するネイバー構造が見つからない場合（つまり、ネイバーが初めて検出された場合）は作成されます。新しく作成されたネイバーの初期状態はダウンに設定されています。
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.
ブロードキャスト、ポイントツーマルチポイント、またはNBMAネットワーク上のネイバーからHelloパケットを受信する場合は、ネイバー構造のネイバーIDを、パケットのOSPFヘッダーにあるルーターIDと同じに設定します。これらのネットワークタイプの場合、ネイバー構造のルータープライオリティフィールド、ネイバーの指定ルーターフィールド、およびネイバーのバックアップ指定ルーターフィールドも、受信したHelloパケットにある対応するフィールドに等しく設定されます。これらのフィールドの変更は、以下の手順で使用できるように注意する必要があります。ポイントツーポイントネットワークで（仮想リンクではなく）Helloを受信する場合は、ネイバー構造のネイバー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: o Each Hello Packet causes the neighbor state machine to be executed with the event HelloReceived.
これで、Helloパケットの残りの部分が検査され、ネイバーおよびインターフェイスステートマシンに渡されるイベントが生成されます。これらのステートマシンは、実行またはスケジュールするように指定されています（セクション4.4を参照）。たとえば、ネイバーステートマシンをインラインで実行するように以下を指定すると、単一の受信されたHelloによっていくつかのネイバーステート遷移が影響を受ける可能性があります。
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パケットに含まれるネイバーのリストが検査されます。ルーター自体がこのリストに表示される場合、ネイバーステートマシンはイベント2-WayReceivedで実行される必要があります。それ以外の場合は、ネイバーステートマシンをイベント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 次に、ネイバーのルータープライオリティフィールドの変更が記録された場合、受信インターフェイスのステートマシンは、イベント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 ネイバーが両方とも指定ルーター（Helloパケットの指定ルーターフィールド=ネイバーIPアドレス）であると宣言し、パケットのバックアップ指定ルーターフィールドが0.0.0.0に等しく、受信インターフェイスが待機中の状態の場合、受信インターフェイスの状態マシンは、BackupSeenイベントでスケジュールされます。それ以外の場合、ネイバーが自分自身を代表ルーターとして宣言していて、以前に宣言していない場合、またはネイバーが自分自身を指定ルーターとして宣言していない場合、受信インターフェースの状態マシンは、イベント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 ネイバーが自分自身をバックアップ指定ルーター（Helloパケットのバックアップ指定ルーターフィールド=ネイバーIPアドレス）であると宣言し、受信インターフェイスが待機状態にある場合、受信インターフェイスの状態マシンは、イベントBackupSeenでスケジュールされます。それ以外の場合、ネイバーが自分自身をバックアップ指定ルーターとして宣言していて、以前に宣言していなかった場合、またはネイバーが以前に自分自身をバックアップ指定ルーターとして宣言していない場合、受信側インターフェイスの状態マシンはイベント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パケットを受信すると、応答としてHelloパケットがネイバーに返送される場合もあります。詳細については、9.5.1項を参照してください。
10.6. Receiving Database Description Packets
10.6. データベース記述パケットの受信
This section explains the detailed processing of a received Database Description Packet. The incoming Database Description Packet has already been associated with a neighbor and receiving interface by the generic input packet processing (Section 8.2). Whether the Database Description packet should be accepted, and if so, how it should be further processed depends upon the neighbor state.
このセクションでは、受信したデータベース記述パケットの詳細な処理について説明します。着信データベース記述パケットは、一般的な入力パケット処理（セクション8.2）によってすでにネイバーと受信インターフェイスに関連付けられています。データベース記述パケットを受け入れる必要があるかどうか、また受け入れる場合、それをさらに処理する方法は、ネイバーの状態によって異なります。
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.
データベース記述パケットが受け入れられる場合、次のパケットフィールドは、「最後に受信したデータベース記述パケット」の下の対応するネイバーデータ構造に保存する必要があります。パケットの初期化（I）、追加（M）およびマスター（MS）ビット、オプションフィールド、およびDDシーケンス番号。これらのフィールドが、ネイバーから受信した2つの連続するデータベース記述パケットで同一に設定されている場合、2番目のデータベース記述パケットは、以下で説明する処理で「重複」していると見なされます。
If the Interface MTU field in the Database Description packet indicates an IP datagram size that is larger than the router can accept on the receiving interface without fragmentation, the Database Description packet is rejected. Otherwise, if the neighbor state is:
Database DescriptionパケットのInterface MTUフィールドが、ルータがフラグメント化せずに受信インターフェイスで受け入れることができるよりも大きいIPデータグラムサイズを示している場合、Database Descriptionパケットは拒否されます。それ以外の場合、隣接状態は次のとおりです。
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.
Initネイバーステートマシンは、イベント2-WayReceivedで実行される必要があります。これにより、状態2-Wayまたは状態ExStartに即座に状態が変化します。新しい状態がExStartの場合、現在のパケットの処理は、以下のExStartのケースにフォールスルーすることにより、この新しい状態で続行する必要があります。
2-Way The packet should be ignored. Database Description Packets are used only for the purpose of bringing up adjacencies.[7]
双方向パケットは無視する必要があります。データベース記述パケットは、隣接関係を育てる目的でのみ使用されます。[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.
ExStart受信したパケットが次のいずれかのケースに一致する場合、ネイバーステートマシンをイベントNegotiationDone（状態をExchangeに遷移させる）で実行する必要があります。パケットのオプションフィールドは、ネイバー構造のネイバーオプションフィールドとパケットは次のシーケンスとして受け入れられ、さらに処理されます（以下を参照）。それ以外の場合、パケットは無視されます。
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）ビットが設定され、パケットの内容が空で、ネイバーのルーターIDがルーターのルーターIDよりも大きい。この場合、ルーターはスレーブになります。マスター/スレーブビットをスレーブに設定し、ネイバーデータ構造の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シーケンス番号（確認を示す）と等しく、ネイバーのルーターIDがルーターのものよりも小さい。この場合、ルーターはマスターです。
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):
Exchange Duplicate Database Descriptionパケットはマスターによって破棄され、スレーブは送信した最後のDatabase Descriptionパケットを再送信します。それ以外の場合（パケットは重複していません）：
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 initialize（I）ビットが設定されている場合は、ネイバーイベントSeqNumberMismatchを生成し、パケットの処理を停止します。
o If the packet's Options field indicates a different set of optional OSPF capabilities than were previously received from the neighbor (recorded in the Neighbor Options field of the neighbor structure), generate the neighbor event SeqNumberMismatch and stop processing the packet.
o パケットの[オプション]フィールドに、以前にネイバーから受信したオプションの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シーケンス番号は、ネイバーデータ構造に格納されているDDシーケンス番号よりも1大きい必要があります。いずれの場合も、パケットが次のパケットである場合、パケットは受け入れられ、その内容は以下に指定されているように処理されます。
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.
ローディングまたはフルこの状態では、ルータは一連のデータベース記述パケット全体を送受信しています。受信されるパケットは重複しているだけです（上記を参照）。特に、パケットのオプションフィールドは、以前にネイバーによって指定されたオプションのOSPF機能のセットと一致する必要があります（ネイバー構造のネイバーオプションフィールドに格納されています）。 Initialize（I）ビットが設定されたパケットの受信を含む、その他の受信パケットは、ネイバーイベントSeqNumberMismatchを生成する必要があります。[8]重複はマスターによって破棄されるべきです。スレーブは、送信した最後のデータベース記述パケットを繰り返すことにより、重複に応答する必要があります。
When the router accepts a received Database Description Packet as the next in sequence the packet contents are processed as follows. For each LSA listed, the LSA's LS type is checked for validity. If the LS type is unknown (e.g., not one of the LS types 1-5 defined by this specification), or if this is an AS-external-LSA (LS type = 5) and the neighbor is associated with a stub area, generate the neighbor event SeqNumberMismatch and stop processing the packet. Otherwise, the router looks up the LSA in its database to see whether it also has an instance of the LSA. If it does not, or if the database copy is less recent (see Section 13.1), the LSA is put on the Link state request list so that it can be requested (immediately or at some later time) in Link State Request Packets.
ルータが受信したデータベース記述パケットを次のシーケンスとして受け入れると、パケットの内容は次のように処理されます。リストされたLSAごとに、LSAのLSタイプの妥当性がチェックされます。 LSタイプが不明な場合（たとえば、この仕様で定義されているLSタイプ1〜5のいずれでもない場合）、またはこれがAS-external-LSA（LSタイプ= 5）であり、ネイバーがスタブエリアに関連付けられている場合、ネイバーイベントSeqNumberMismatchを生成し、パケットの処理を停止します。それ以外の場合、ルーターはデータベースでLSAを検索して、LSAのインスタンスもあるかどうかを確認します。そうでない場合、またはデータベースコピーの方が新しい場合（セクション13.1を参照）、LSAはリンク状態要求リストに追加され、リンク状態要求パケットで（すぐにまたは後で）要求できるようになります。
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:
ルーターは、受信したデータベース記述パケットを次のパケットとして順番に受け入れると、マスターであるかスレーブであるかに応じて、次のアクションも実行します。
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.
マスター隣接データ構造のDDシーケンス番号を増分します。ルーターがデータベース記述パケットのシーケンス全体をすでに送信していて、受け入れられたばかりのパケットのビット（M）が0に設定されている場合、ネイバーイベントExchangeDoneが生成されます。それ以外の場合は、新しいデータベースの説明をスレーブに送信する必要があります。
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.
スレーブネイバーデータ構造のDDシーケンス番号を、受信したパケットに表示されるDDシーケンス番号に設定します。スレーブは、応答としてデータベース記述パケットを送信する必要があります。受信パケットのmoreビット（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.
このセクションでは、受信したリンク状態要求パケットの詳細な処理について説明します。 Received Link State Request Packetsは、ネイバーが受信したいLSAのリストを指定します。リンク状態要求パケットは、ネイバーがExchange、Loading、またはFullの状態のときに受け入れられる必要があります。他のすべての状態では、リンク状態要求パケットは無視する必要があります。
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.
リンク状態要求パケットで指定された各LSAは、ルーターのデータベースに配置され、リンク状態更新パケットにコピーされて、ネイバーに送信されます。これらのLSAは、ネイバーのリンク状態再送信リストに配置しないでください。 LSAがデータベースで見つからない場合は、データベース交換プロセスで何か問題が発生しており、ネイバーイベント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.
このセクションでは、データベース記述パケットがネイバーに送信される方法について説明します。データベース記述パケットのインターフェースMTUフィールドは、断片化せずに送信インターフェースから送信できる最大のIPデータグラムのサイズに設定されます。インターネットで使用されている一般的なMTUは、[Ref22]の表7-1にあります。仮想リンクを介して送信されるデータベース記述パケットでは、インターフェースMTUを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を参照）は、データベース記述パケットのオプションフィールドでネイバーに送信されます。ルータは、データベース交換およびフラッディング手順全体を通じて、同じオプション機能のセットを維持する必要があります。なんらかの理由でルーターのオプション機能が変更された場合は、ネイバー状態のExStartに戻して、データベース交換手順を再開する必要があります。この仕様では、1つのオプション機能が定義されています（セクション4.5およびA.2を参照）。接続されているネットワークが非スタブエリアに属している場合にのみ、Eビットを設定する必要があります。オプションフィールドの認識されないビットはゼロに設定する必要があります。
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.
データベース記述パケットの送信は、ネイバーの状態によって異なります。 ExStart状態では、ルーターは初期化（I）、追加（M）、およびマスター（MS）ビットが設定された空のデータベース記述パケットを送信します。これらのパケットは、RxmtInterval秒ごとに再送信されます。
In state Exchange the Database Description Packets actually contain summaries of the link state information contained in the router's database. Each LSA in the area's link-state database (at the time the neighbor transitions into Exchange state) is listed in the neighbor Database summary list. Each new Database Description Packet copies its DD sequence number from the neighbor data structure and then describes the current top of the Database summary list. Items are removed from the Database summary list when the previous packet is acknowledged.
状態交換では、データベース記述パケットは実際にはルーターのデータベースに含まれるリンク状態情報の要約を含んでいます。エリアのリンク状態データベース内の各LSA（ネイバーがExchange状態に移行したとき）は、ネイバーデータベースの要約リストにリストされます。新しいデータベース記述パケットはそれぞれ、隣接データ構造からそのDDシーケンス番号をコピーし、次にデータベース要約リストの現在の先頭を記述します。前のパケットが確認されると、アイテムはデータベースサマリリストから削除されます。
In state Exchange, the determination of when to send a Database Description packet depends on whether the router is master or slave:
Exchange状態では、データベース記述パケットを送信するタイミングの決定は、ルーターがマスターかスレーブかによって異なります。
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）確認応答なしでRxmtInterval秒が経過したときに送信されます。この場合、前のデータベース記述パケットは再送信されます。
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.
スレーブデータベース記述パケットは、マスターから受信したデータベース記述パケットに応答してのみ送信されます。マスターから受信したデータベース記述パケットが新しい場合は、新しいデータベース記述パケットが送信されます。そうでない場合は、以前のデータベース記述パケットが再送信されます。
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の状態では、マスターから受信した重複するデータベース記述パケットに応答して、スレーブは最後のデータベース記述パケットを再送信する必要があります。このため、スレーブは最後のデータベース記述パケットを解放する前にRouterDeadInterval秒待機する必要があります。この間隔の後にマスターからデータベース記述パケットを受信すると、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の場合、リンク状態要求リストには、ネイバーから取得する必要があるLSAのリストが含まれています。これらのLSAを要求するために、ルーターはリンク状態要求パケットにパッケージ化されたリンク状態要求リストの先頭をネイバーに送信します。
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.
ネイバーがこれらの要求に適切なリンク状態更新パケットで応答すると、リンク状態要求リストが切り捨てられ、新しいリンク状態要求パケットが送信されます。このプロセスは、リンク状態要求リストが空になるまで続きます。要求されたがまだ受信されていないリンク状態要求リストのLSAは、リンク状態要求パケットにパッケージ化され、RxmtIntervalの間隔で再送信されます。一度に最大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.
リンク状態要求リストが空になり、ネイバー状態が読み込み中（つまり、データベース記述パケットの完全なシーケンスがネイバーとの間で送受信された）になると、読み込み完了ネイバーイベントが生成されます。
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はネットワークの指定ルーターであり、RT2はルーターRT1よりも高いルーター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の初めに、ネットワークへのルーターRT1のインターフェースが作動可能になります。指定ルーターまたは他の隣接ルーターのIDを認識していませんが、Helloパケットの送信を開始します。ルーターRT2はこのhelloを受信し（ネイバーをInit状態に移動）、次のHelloパケットでそれ自体が指定ルーターであり、RT1からのHelloパケットを受信したことを示します。これにより、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のルーターIDが大きいため）、RT1はスレーブ状態に移行し、ネイバーのDDシーケンス番号を採用します。次に、データベース記述パケットが交換され、ポーリングはマスター（RT2）から送信され、応答はスレーブ（RT1）から送信されます。この一連のデータベース記述
+---+ +---+
|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
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はすぐにフル状態になります。 RT1は、データベースの必要な部分を更新した後、フル状態になります。これは、リンク状態要求パケットを送信し、応答としてリンク状態更新パケットを受信することによって行われます。リンク状態要求パケットを送信する前に、データベース記述パケットの完全なセットが（RT2から）受信されるまでRT1が待機していたことに注意してください。 RT1は、リンク状態要求パケットの送信とデータベース記述パケットの受信をインターリーブした可能性があります。
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は、デフォルトルートの存在も提供します（宛先ID = DefaultDestination、アドレスマスク= 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.
各ルーターには1つのルーティングテーブルがあります。 2つのサンプルルーティングテーブルについては、セクション11.2および11.3で説明しています。ルーティングテーブルの作成については、セクション16で説明します。
The rest of this section defines the fields found in a routing table entry. The first set of fields describes the routing table entry's destination.
このセクションの残りの部分では、ルーティングテーブルエントリにあるフィールドを定義します。最初のフィールドセットは、ルーティングテーブルエントリの宛先を示します。
Destination Type Destination type is either "network" or "router". Only network entries are actually used when forwarding IP data traffic. Router routing table entries are used solely as intermediate steps in the routing table build process.
宛先タイプ宛先タイプは、「ネットワーク」または「ルーター」のいずれかです。 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宛先のIDまたは名前。これは宛先タイプによって異なります。ネットワークの場合、識別子は関連するIPアドレスです。ルーターの場合、識別子はOSPFルーター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).
アドレスマスクネットワークに対してのみ定義されます。ネットワークのIPアドレスとそのアドレスマスクは、IPアドレスの範囲を定義します。 IPサブネットの場合、アドレスマスクはサブネットマスクと呼ばれます。ホストルートの場合、マスクは「すべて1」（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.
オプション機能宛先がルーターの場合、このフィールドは宛先ルーターがサポートするオプションのOSPF機能を示します。この仕様で定義されている唯一のオプション機能は、AS外部LSAを処理する機能です。 OSPFのオプション機能の詳細については、セクション4.5を参照してください。
The set of paths to use for a destination may vary based on the OSPF area to which the paths belong. This means that there may be multiple routing table entries for the same destination, depending on the values of the next field.
宛先に使用するパスのセットは、パスが属する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.
Areaこのフィールドは、リンク状態情報がルーティングテーブルエントリのパスのコレクションにつながったエリアを示します。これは、エントリの関連領域と呼ばれます。 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.
パスタイプトラフィックを宛先にルーティングするために使用されるパスには、4つのタイプがあります。ここでは、優先度の高い順にリストされています：エリア内、エリア間、タイプ1外部またはタイプ2外部。エリア内パスは、ルーターの接続エリアの1つに属する宛先を示します。エリア間パスは、他のOSPFエリアの宛先へのパスです。これらは、受け取ったサマリーLSAの調査を通じて発見されます。 AS外部パスは、ASの外部の宛先へのパスです。これらは、受信したAS外部LSAの検査を通じて検出されます。
Cost The link state cost of the path to the destination. For all paths except type 2 external paths this describes the entire path's cost. For Type 2 external paths, this field describes the cost of the portion of the path internal to the AS. This cost is calculated as the sum of the costs of the path's constituent links.
コスト宛先へのパスのリンク状態コスト。タイプ2の外部パスを除くすべてのパスの場合、これはパス全体のコストを表します。タイプ2の外部パスの場合、このフィールドは、パスのAS内部の部分のコストを示します。このコストは、パスの構成リンクのコストの合計として計算されます。
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の外部パスに対してのみ有効です。これらのパスの場合、このフィールドはパスの外部部分のコストを示します。このコストはAS境界ルーターによって通知されており、総パスコストの最も重要な部分です。たとえば、2つのパスの内部コンポーネントのコストに関係なく、タイプ2のコストが5のタイプ2の外部パスは、タイプ2のコストが10のパスよりも常に優先されます。
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).
リンク状態の起点エリア内パスにのみ有効です。このフィールドは、宛先を直接参照するLSA（ルーターLSAまたはネットワークLSA）を示します。たとえば、宛先がトランジットネットワークの場合、これはトランジットネットワークのネットワークLSAです。宛先がスタブネットワークの場合、これは接続されたルーターのルーターLSAです。 LSAは最短パスツリーの計算中に検出されます（セクション16.1を参照）。複数のLSAが宛先を参照する場合がありますが、タイブレイキングスキームは常に単一のLSAへの選択を減らします。 Link State OriginフィールドはOSPFプロトコルでは使用されませんが、OSPFのマルチキャストルーティング拡張機能（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.
ネクストホップトラフィックを宛先に転送するときに使用する発信ルーターインターフェイス。ブロードキャスト、ポイントツーマルチポイント、および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外部パスに対してのみ有効です。このフィールドは、このパスにつながったサマリーLSAまたはAS外部LSAをアドバタイズするルーターのルーターIDを示します。
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）のエントリよりも具体的です。デフォルトルートは、すべての宛先に一致するため、最も限定的な一致ではありません。 （1つのルーティングテーブルエントリに対して、複数のパスが存在する可能性があることに注意してください。これらの場合、セクション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 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".
図2に示す自律システムについて考えてみます。OSPFエリアは構成されていません。送信インターフェースごとに1つのメトリックが表示されます。ルータRT6のルーティングテーブルの計算は、セクション2.2で説明されているように進行します。結果のルーティングテーブルを表12に示します。宛先タイプは省略されています。ネットワークは「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境界ルーターです。エリア内ルートは、ルーターRT5およびRT7まで計算されています。これにより、RT5とRT7によってアドバタイズされた宛先（つまり、ネットワークN12、N13、N14、N15）への外部ルートを計算できます。 RT5およびRT7から発信されたすべてのAS外部LSAがタイプ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のルーティングテーブルについて、このエリア構成について説明します。ルータRT4には、エリア1への接続とバックボーン接続があります。これにより、ルーターRT4は、ASを図7および8に示す2つのグラフの連結として表示します。結果のルーティングテーブルが表13に表示されます。
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).
ここでも、ルーターRT5とRT7はAS境界ルーターです。ルーターRT3、RT4、RT7、RT10、RT11はエリア境界ルーターです。エリア境界ルーターRT3には、RT4と共通の2つのエリア（エリア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
すべてのエリア境界ルーターへのバックボーンパスが計算されました。これらは、エリア間ルートを決定するときに使用されます。すべてのエリア間ルートはバックボーンに関連付けられていることに注意してください。これは、計算ルーター自体がエリア境界ルーターの場合に常に当てはまります。ルーティング情報はエリア境界で圧縮されます。この例では、ネットワークN9〜N11とホストがH1にルーティングするようにエリア3が定義されていると想定しています。
Type Dest Area Path Type Cost Next Adv.
Hop(s) Router(s)
____________________________________________________________
N N1 0 intra-area 10 RT3 *
N N2 0 intra-area 10 RT3 *
N N3 0 intra-area 7 RT3 *
N N4 0 intra-area 8 RT3 *
N Ib 0 intra-area 7 * *
N Ia 0 intra-area 12 RT10 *
N N6 0 intra-area 8 RT10 *
N N7 0 intra-area 12 RT10 *
N N8 0 intra-area 10 RT10 *
N N9 0 intra-area 11 RT10 *
N N10 0 intra-area 13 RT10 *
N N11 0 intra-area 14 RT10 *
N H1 0 intra-area 21 RT10 *
R RT5 0 intra-area 6 RT5 *
R RT7 0 intra-area 8 RT10 *
____________________________________________________________
N N12 * type 1 ext. 10 RT10 RT7
N N13 * type 1 ext. 14 RT5 RT5
N N14 * type 1 ext. 14 RT5 RT5
N N15 * type 1 ext. 17 RT10 RT7
Table 12: The routing table for Router RT6 (no configured areas).
表12：ルーター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.
（ルータRT11によって）バックボーンにアドバタイズされると、すべて1つのルートに圧縮されます。このルートのコストは、個々のコンポーネントへのコストのセットの最大であることに注意してください。
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.
ルータRT10とRT11の間に仮想リンクが設定されています。この構成された仮想リンクがないと、RT11はネットワークN9-N11およびホストH1のルートをバックボーンにアドバタイズできず、ルーターRT4のルーティングテーブルにこれらのネットワークのエントリがありません。
In this example there are two equal-cost paths to Network N12. However, they both use the same next hop (Router RT5).
この例では、ネットワークN12への2つの等コストパスがあります。ただし、どちらも同じネクストホップ（ルーターRT5）を使用します。
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
ルーターRT4とルーターRT3の間に追加の仮想リンクが構成されている場合、ルーターRT4のルーティングテーブルは改善されます（つまり、ルーティングテーブルの一部のパスが短くなります）。新しい仮想リンク自体は、表13のエリア境界ルーターRT3の最初のエントリ（エリア1を通るエリア内パス）に関連付けられます。これにより、仮想リンクのコストは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
Table 13: Router RT4's routing table in the presence of areas.
表13：エリアが存在する場合のルーターRT4のルーティングテーブル。
in Table 14.
表14。
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.
自律システム内の各ルーターは、1つ以上のリンク状態アドバタイズメント（LSA）を発信します。このメモは、セクション4.3で説明されている5つの異なるタイプのLSAを定義しています。 LSAのコレクションはリンク状態データベースを形成します。 LSAの各タイプには、個別の機能があります。ルーターLSAとネットワークLSAは、エリアのルーターとネットワークがどのように相互接続されるかを記述します。概要LSAは、エリアのルーティング情報を要約する方法を提供します。 AS-external-LSAは、自律システム全体で外部から導出されたルーティング情報を透過的にアドバタイズする方法を提供します。
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
Table 14: Changes resulting from an additional virtual link.
表14：追加の仮想リンクによる変更。
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タイプ、リンク状態ID、および広告ルーターフィールドが含まれています。これら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.
自律システムには、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パケットタイプのいくつかはLSAをリストします。インスタンスが重要でない場合、LSAはそのLSタイプ、リンク状態ID、およびアドバタイジングルーターによって参照されます（リンク状態要求パケットを参照）。それ以外の場合は、LSシーケンス番号、LS経過時間、およびLSチェックサムフィールドも参照する必要があります。
A detailed explanation of the fields contained in the LSA header follows.
LSAヘッダーに含まれるフィールドの詳細な説明は次のとおりです。
12.1.1. LS age
12.1.1. ＬＳ あげ
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によって増分される必要があります。 LSAは、各ルーターのデータベースに保持されているため、古くなります。
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の経過時間を持つLSAは、ルーティングテーブルの計算に使用されません。 LSAの年齢が最初にMaxAgeに達すると、再フラッディングされます。 MaxAgeのLSAは、データベースの同期を保証する必要がなくなったときに、最終的にデータベースからフラッシュされます。 LSAのエージングの詳細については、セクション14を参照してください。
The LS age field is examined when a router receives two instances of an LSA, both having identical LS sequence numbers and LS checksums. An instance of age MaxAge is then always accepted as most recent; this allows old LSAs to be flushed quickly from the routing domain. Otherwise, if the ages differ by more than MaxAgeDiff, the instance having the smaller age is accepted as most recent.[12] See Section 13.1 for more details.
LSエージフィールドは、LSAの2つのインスタンスを受信したときに検査されます。LSAのインスタンスは両方とも、LSシーケンス番号とLSチェックサムが同じです。 MaxAgeのインスタンスは、常に最新のものとして受け入れられます。これにより、古いLSAをルーティングドメインからすばやくフラッシュできます。それ以外の場合、年齢の差が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ヘッダーのオプションフィールドは、LSAに関連付けられているオプション機能を示します。 OSPFのオプション機能については、セクション4.5で説明しています。この仕様では、オプションフィールドにあるEビットで表されるオプション機能が1つ定義されています。オプションフィールドの認識されないビットはゼロに設定する必要があります。
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を表します。このビットは、バックボーンに関連付けられているすべてのLSA、および非スタブエリアに関連付けられているすべてのLSAに設定する必要があります（セクション3.6を参照）。また、すべてのAS外部LSAで設定する必要があります。スタブエリアに関連付けられているすべてのルーターLSA、ネットワークLSA、サマリーLSAでリセットする必要があります。すべてのLSAで、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の形式と機能を決定します。タイプが異なるLSAは、名前が異なります（ルーターLSAやネットワークLSAなど）。 AS-external-LSA（LSタイプ= 5）を除いて、このメモで定義されているすべてのLSAタイプは、単一の領域のみにフラッディングされます。 AS外部LSAは、スタブエリアを除いて自律システム全体にフラッディングされます（セクション3.6を参照）。それぞれの個別のLSAタイプについて、以下の表15で簡単に説明します。
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 LS Type LSA description
________________________________________________
1 These are the router-LSAs.
They describe the collected
states of the router's
interfaces. For more information,
consult Section 12.4.1.
________________________________________________
2 These are the network-LSAs.
They describe the set of routers
attached to the network. For
more information, consult
Section 12.4.2.
________________________________________________
3 or 4 These are the summary-LSAs.
They describe inter-area routes,
and enable the condensation of
routing information at area
borders. Originated by area border
routers, the Type 3 summary-LSAs
describe routes to networks while the
Type 4 summary-LSAs describe routes to
AS boundary routers.
________________________________________________
5 These are the AS-external-LSAs.
Originated by AS boundary routers,
they describe routes
to destinations external to the
Autonomous System. A default route for
the Autonomous System can also be
described by an AS-external-LSA.
Table 15: OSPF link state advertisements (LSAs).
表15：OSPFリンク状態通知（LSA）。
16.
１６。
Actually, for Type 3 summary-LSAs (LS type = 3) and AS-
external-LSAs (LS type = 5), the Link State ID may LS Type Link State ID
_______________________________________________
1 The originating router's Router ID.
2 The IP interface address of the
network's Designated Router.
3 The destination network's IP address.
4 The Router ID of the described AS
boundary router.
5 The destination network's IP address.
Table 16: The LSA's Link State ID.
表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.
さらに、宛先ネットワークの「ホスト」ビットセットを1つ以上設定します。たとえば、255.0.0.0のマスクを使用してネットワーク10.0.0.0のAS-external-LSAを発信する場合、リンク状態IDは10.0.0.0から10.255.255.255までの範囲の任意の値に設定できます（ただし、10.0.0.0は可能な限り使用してください）。特定のホストビットを自由に設定できるため、ルーターは、アドレスが同じでマスクが異なる2つのネットワークに対して別々のLSAを発信できます。詳細については、付録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の本体に含まれているネットワーク/サブネットマスクでリンク状態IDをマスクすることで簡単に取得できます。 LSAがルーター（LSタイプ= 1または4）を記述している場合、リンク状態IDは常に記述されたルーターのOSPFルーター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-external-LSA（LS Type = 5）がデフォルトルートを記述している場合、そのリンク状態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 network's Designated Router. Summary-LSAs originated by area border routers. AS-external-LSAs are originated by AS boundary routers.
このフィールドは、LSAの発信元のOSPFルーターIDを指定します。ルータLSAの場合、このフィールドはリンク状態IDフィールドと同じです。ネットワークLSAは、ネットワークの指定ルーターによって発信されます。エリア境界ルーターによって発信されたサマリーLSA。 AS外部LSAは、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ビット整数です。古いLSAと重複するLSAを検出するために使用されます。シーケンス番号のスペースは線形に並べられます。シーケンス番号が大きいほど（符号付き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（0x80000000）は予約されています（未使用）。これにより、最小（したがって最も古い）シーケンス番号として-N + 1（0x80000001）が残ります。このシーケンス番号は、定数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のより新しいインスタンスが予期せず受信された場合、ルーターはLSAの1つのシーケンス番号を昇格するように強制される場合があります。これはまれなイベントです。これは、最後の再起動/リロードの前にルーター自体によって発信された古いLSAが自律システムにまだ存在していることを示している可能性があります。詳細については、セクション13.4を参照してください。
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の完全な内容のチェックサムです。チェックサムを更新せずにLSAの経過時間を増分できるように、LS経過時間フィールドは除外されています。使用されるチェックサムは、ISOコネクションレス型データグラムに使用されるものと同じです。これは一般にフレッチャーチェックサムと呼ばれます。 [Ref6]の付録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がフラッディングされている間、または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のチェックサムは、a）リンク状態更新パケットで受信されたとき、および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を参照）。のコンポーネント
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.
エリアリンクステートデータベースは、エリア全体にのみフラッディングされます。最後に、隣接関係（エリアAに属する）が起動されると、エリア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).
エリアデータベースは、ルーターLSA、ネットワークLSA、サマリーLSA（すべてエリアデータ構造にリストされています）で構成されています。さらに、外部ルート（AS-external-LSA）はすべての非スタブエリアデータベースに含まれています（セクション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タイプ、リンク状態ID、およびアドバタイジングルーターに基づいています。[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).
LSAは、a）フラッディングプロセス中に受信された場合（セクション13）、またはb）ルーター自体によって送信された場合（セクション12.4）に、ルーターのデータベースに追加されます。 LSAがルーターのデータベースから削除されるのは、a）フラッディングプロセス中に新しいインスタンスによって上書きされた場合（セクション13）、またはb）ルーターが自己生成したLSAの新しいインスタンスを作成した場合（セクション12.4）またはc）LSAが期限切れになり、ルーティングドメインからフラッシュされます（セクション14）。 LSAがデータベースから削除されるときは常に、すべてのネイバーのリンク状態再送信リストからも削除する必要があります（セクション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]）との下位互換性のために、TOS固有の情報をルーターLSA、サマリーLSA、およびAS外部LSAに含めることができます。 OSPF LSAでのTOSのエンコードは、表17で指定されています。このテーブルは、OSPFエンコードをIPパケットヘッダーのTOSフィールド（[Ref12]で定義）に関連付けます。 OSPFエンコードは10進数として表されます
integer, and the IP packet header's TOS field is expressed in the binary TOS values used in [Ref12].
整数。IPパケットヘッダーのTOSフィールドは、[Ref12]で使用されているバイナリ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
Table 17: Representing TOS in OSPF.
表17：OSPFでのTOSの表現。
12.4. Originating LSAs
12.4. 元のLSA
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エリアに、ルーターがいくつかのLSAを発信します。各ルーターは、ルーターLSAを発信します。ルーターがエリアのいずれかのネットワークの指定ルーターでもある場合は、それらのネットワークのネットワークLSAを発信します。
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.
エリア境界ルーターは、既知のエリア間宛先ごとに1つのサマリーLSAを発信します。 AS境界ルーターは、既知のAS外部宛先ごとに1つのAS外部LSAを発信します。宛先は一度に1つずつアドバタイズされるため、ルートのコレクション全体を再フラッディングすることなく、任意の単一ルートの変更をフラッディングできます。フラッディング手順の間、多くのLSAが単一のリンク状態更新パケットによって運ばれることができます。
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のルーターRT4を考えます。これはエリア境界ルーターであり、エリア1とバックボーンに接続されています。ルーターRT4は、5つの異なるLSAをバックボーンに発信します（ネットワークN1-N4のそれぞれに1つのルーターLSA、および1つのサマリーLSA）。ルーターRT4は、8つの異なるLSAをエリア1に発信します（図7に示すように、1つのルーターLSAと7つのサマリーLSA）。 RT4がネットワークN3の指定ルーターとして選択されている場合は、N3のネットワークLSAをエリア1に発信します。
In this same figure, Router RT5 will be originating 3 distinct AS-external-LSAs (one for each of the networks N12-N14). These will be flooded throughout the entire AS, assuming that none of the areas 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.
この同じ図では、ルーターRT5が3つの異なるAS-外部LSA（ネットワークN12〜N14のそれぞれに1つ）を発信しています。これらのエリアはスタブとして構成されていないものと想定して、AS全体にフラッディングされます。ただし、エリア3がスタブエリアとして構成されている場合、ネットワークN12〜N14のAS外部LSAはエリア3にフラッディングされません（セクション3.6を参照）。代わりに、ルーターRT11は、エリア3全体にフラッディングされるデフォルトのサマリーLSAを発信します（セクション12.4.3を参照）。これは、エリア3のすべての内部ルーターに、それらのAS外部トラフィックをRT11に送信するように指示します。
Whenever a new instance of an LSA is originated, its LS sequence number is incremented, its LS age is set to 0, its LS checksum is calculated, and the LSA is added to the link state database and flooded out the appropriate interfaces. See Section 13.2 for details concerning the installation of the LSA into the link state database. See Section 13.3 for details concerning the flooding of newly originated LSAs.
LSAの新しいインスタンスが作成されるたびに、LSシーケンス番号がインクリメントされ、LSエージが0に設定され、LSチェックサムが計算され、LSAがリンク状態データベースに追加され、適切なインターフェイスにフラッディングされます。 LSAのリンク状態データベースへのインストールの詳細については、セクション13.2を参照してください。新しく発生したLSAのフラッディングに関する詳細については、セクション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）ルーターの自己発信LSAのLSエージフィールドが値LSRefreshTimeに到達します。この場合、LSAの内容（LSAヘッダーは除く）が同じであっても、LSAの新しいインスタンスが生成されます。これにより、すべてのLSAの定期的な発信が保証されます。 LSAのこの定期的な更新により、リンク状態アルゴリズムに堅牢性が追加されます。到達不能な宛先のみを記述するLSAは更新しないでください。代わりにルーティングドメインからフラッシュする必要があります（セクション14.1を参照）。
When whatever is being described by an LSA changes, a new LSA is originated. However, two instances of the same LSA may not be originated within the time period MinLSInterval. This may require that the generation of the next instance be delayed by up to MinLSInterval. The following events may cause the contents of an LSA to change. These events should cause new originations if and only if the contents of the new LSA would be different:
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）接続されたネットワークの指定ルーターが変更されます。新しいルーターLSAを作成する必要があります。また、ルーター自体が指定ルーターになった場合は、新しいネットワークLSAを作成する必要があります。ルーター自体が指定ルーターではなくなった場合、ネットワークに対して発信された可能性があるすべてのネットワーク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状態へ、またはFULL状態から変化します。これは、ルーターLSAの新しいインスタンスを作成する必要があることを意味します。また、ルーター自体が接続ネットワークの指定ルーターである場合は、新しいネットワーク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の新しいインスタンスが、接続されている各エリアで発生します（ただし、バックボーンの場合は絶対に発生しません）。
(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）ルーターがエリアに新しく接続されます。次に、ルーターは、ルーターのルーティングテーブル内の関連するすべてのエリア内およびエリア間ルートについて、新しく接続されたエリアにサマリーLSAを発信する必要があります。詳細については、セクション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）ルーターの構成済み仮想リンクのいずれかの状態が変化した場合、新しいルーターLSAを仮想リンクの通過領域に発信する必要がある場合があります（セクション12.4.1のルーターLSAのビットVの説明を参照） 、および新しいルーターLSAをバックボーンに発信します。
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-external-LSAの新しいインスタンスを開始します。
(10) A router ceases to be an AS boundary router, perhaps after restarting. In this situation the router should flush all AS-external-LSAs that it had previously originated. These LSAs can be flushed via the premature aging procedure specified in Section 14.1.
（10）おそらく再起動後、ルーターはAS境界ルーターでなくなります。この状況では、ルーターは以前に発生したすべてのAS外部LSAをフラッシュする必要があります。これらのLSAは、セクション14.1で指定された早期エージング手順を介してフラッシュできます。
The construction of each type of LSA is explained in detail below. In general, these sections describe the contents of the LSA body (i.e., the part coming after the 20-byte LSA header). For information concerning the building of the LSA header, see Section 12.1.
各タイプのLSAの構成について、以下で詳しく説明します。一般に、これらのセクションでは、LSA本体の内容（つまり、20バイトのLSAヘッダーの後に続く部分）について説明します。 LSAヘッダーの構築に関する情報については、セクション12.1を参照してください。
12.4.1. Router-LSAs
12.4.1. ルーターLSA
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は特定のエリア全体に氾濫し、それ以上は氾濫しません。
....................................
. 192.1.2 Area 1 .
. + .
. | .
. | 3+---+1 .
. N1 |--|RT1|-----+ .
. | +---+ \ .
. | \ _______N3 .
. + \/ \ . 1+---+
. * 192.1.1 *------|RT4|
. + /\_______/ . +---+
. | / | .
. | 3+---+1 / | .
. N2 |--|RT2|-----+ 1| .
. | +---+ +---+8 . 6+---+
. | |RT3|----------------|RT6|
. + +---+ . +---+
. 192.1.3 |2 . 18.10.0.6|7
. | . |
. +------------+ .
. 192.1.4 (N4) .
....................................
Figure 15: Area 1 with IP addresses shown
図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.
router-LSAのフォーマットは、付録A（セクションA.4.2）に示されています。 LSAの最初の20バイトは、セクション12.1で説明した汎用LSAヘッダーで構成されています。 router-LSAには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).
ルーターは、ルーターLSAで適切なビット（それぞれビットBとビットE）を設定することにより、エリアボーダールーターかAS境界ルーターかを示します。これにより、これらのタイプのルーターへのパスをルーティングテーブルに保存して、後でサマリーLSAとAS外部LSAを処理できるようになります。ルータが現在OSPFバックボーンエリアに接続されていない場合でも、ルータが2つ以上のエリアにアクティブに接続されている場合は常にビットBを設定する必要があります。ルーターLSAでスタブエリアのビットEを設定しないでください（スタブエリアにAS境界ルーターを含めることはできません）。
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).
さらに、ルーターがルーターAを通過エリアとして持つ1つ以上の完全に隣接する仮想リンクのエンドポイントである場合にのみ、ルーターはルーターAのルーターLSAにビットVを設定します。ビットVを設定すると、エリア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は、エリアへのルーターの動作中の接続（つまり、インターフェースまたはリンク）を記述します。各リンクは、接続されているネットワークの種類に応じて入力されます。各リンクには、そのリンクIDのラベルも付いています。このリンクIDは、リンクの反対側にあるエンティティに名前を付けます。表18は、「タイプ」および「リンクID」フィールドに使用される値を要約しています。
Link type Description Link ID
__________________________________________________
1 Point-to-point Neighbor Router ID
link
2 Link to transit Interface address of
network Designated Router
3 Link to stub IP network number
network
4 Virtual link Neighbor Router ID
Table 18: Link descriptions in the router-LSA.
表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.
さらに、リンクデータフィールドはリンクごとに指定されます。このフィールドは、リンクの32ビットの追加情報を提供します。トランジットネットワークへのリンク、番号付きポイントツーポイントリンク、および仮想リンクの場合、このフィールドは関連するルーターインターフェイスのIPインターフェイスアドレスを指定します（これはルーティングテーブルの計算に必要です。セクション16.1.1を参照してください）。スタブネットワークへのリンクの場合、このフィールドはスタブネットワークのIPアドレスマスクを指定します。アンナンバードポイントツーポイントリンクの場合、リンクデータフィールドをアンナンバードインターフェイスのMIB-II [Ref8] ifIndex値に設定する必要があります。
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:
リンク記述のリストを作成するプロセスをさらに説明するために、ルーターがエリア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 接続されているネットワークがエリア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 インターフェースの状態がループバックの場合、タイプ3リンク（スタブネットワーク）を追加します。これが、番号付けされていないポイントツーポイントネットワークへのインターフェースでない限り、リンクIDはIPインターフェイスアドレスに設定され、リンクデータはマスク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インターフェイスタイプによって異なります。ポイントツーポイントインターフェイスに使用されるリンクの説明は、セクション12.4.1.1、仮想リンクのセクション12.4.1.2、ブロードキャストおよびNBMAインターフェイスの12.4.1.3、およびポイントツーマルチポイントインターフェイスの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).
すべてのルーターインターフェイスを検討した後、エリアAに属する接続ホストのリストを調べて、ホストリンクをルーターLSAに追加します。ホストルートは、リンクIDがホストのIPであるタイプ3リンク（スタブネットワーク）として表されますアドレス、リンクデータはすべて1のマスク（0xffffffff）であり、ホストの構成済みコスト（セクションC.7を参照）。
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 隣接ルーターが完全に隣接している場合は、タイプ1リンク（ポイントツーポイント）を追加します。リンクIDは、隣接ルーターのルーターIDに設定する必要があります。番号付きのポイントツーポイントネットワークの場合、リンクデータはIPインターフェイスアドレスを指定する必要があります。番号付けされていないポイントツーポイントネットワークの場合、リンクデータフィールドは、インターフェイスの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 さらに、インターフェースの状態が「ポイントツーポイント」である限り（および隣接ルーターの状態に関係なく）、タイプ3リンク（スタブネットワーク）を追加する必要があります。このスタブリンクには、次の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]
オプション1隣接ルーターのIPアドレスがわかっていると仮定して、タイプ3リンクのリンクIDを隣接ルーターのIPアドレスに設定し、リンクデータをマスク0xffffffff（ホストルートを示す）に設定し、コストをインターフェースの構成済み出力コストに設定します。 。[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]
オプション2ポイントツーポイントリンクにサブネットが割り当てられている場合、タイプ3リンクのリンクIDをサブネットのIPアドレスに設定し、リンクデータをサブネットのマスクに設定し、コストをインターフェースの構成済み出力コストに設定します。 [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: 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.
運用ブロードキャストおよびNBMAインターフェイスの場合、次のように単一のリンクの説明がルーターLSAに追加されます。oインターフェイスの状態が待機中の場合は、リンクIDが次のIPネットワーク番号に設定されたタイプ3リンク（スタブネットワーク）を追加します。接続されたネットワーク、接続されたネットワークのアドレスマスクに設定されたリンクデータ、およびインターフェイスの構成された出力コストに等しいコスト。
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 それ以外の場合、接続されたネットワーク用に選ばれた指定ルーターがありました。ルーターが指定ルーターに完全に隣接している場合、またはルーター自体が指定ルーターであり、他の少なくとも1つのルーターに完全に隣接している場合は、リンクIDを1つのタイプ2リンク（中継ネットワーク）に追加し、リンクIDを接続されているネットワークの指定ルーター（ルーター自体の場合もあります）、ルーターの独自のIPインターフェイスアドレスに設定されたリンクデータ、およびインターフェイスの構成済み出力コストと等しいコスト。それ以外の場合は、インターフェースの状態が待機中（上記を参照）であるかのようにリンクを追加します。
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に追加されます。この場合、タイプ4リンク（仮想リンク）を追加し、リンクIDを仮想ネイバーのルーターIDに設定し、リンクデータを仮想リンクに関連付けられたIPインターフェイスアドレスに設定し、コストを仮想リンクに対して計算されたコストに設定します。ルーティングテーブルの計算中（セクション15を参照）。
12.4.1.4. Describing Point-to-MultiPoint interfaces
12.4.1.4. ポイントツーマルチポイントインターフェイスの説明
For operational Point-to-MultiPoint interfaces, one or more link descriptions are added to the router-LSA as follows:
動作するポイントツーマルチポイントインターフェイスの場合、次のように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 1つのタイプ3リンク（スタブネットワーク）が追加され、リンクIDがルーター自体のIPインターフェイスアドレスに設定され、リンクデータがマスク0xffffffff（ホストルートを示す）に設定され、コストが0に設定されます。
o For each fully adjacent neighbor associated with the interface, add an additional Type 1 link (point-to-point) with Link ID set to the Router ID of the neighboring router, Link Data set to the IP interface address and cost equal to the interface's configured output cost.
o インターフェースに関連付けられた完全に隣接する各ネイバーについて、リンクIDを隣接ルーターのルーターIDに設定し、リンクデータをIPインターフェースアドレスに設定し、インターフェースのコストと等しいコストで、追加のタイプ1リンク（ポイントツーポイント）を追加します。構成された出力コスト。
12.4.1.5. Examples of router-LSAs
12.4.1.5. ルーターLSAの例
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.
図6に示すように、ルーターRT3によって生成されたルーターLSAについて考えてみます。ルーターRT3（エリア1）を含む領域は、図15に実際のネットワークアドレスで再描画されています。すべてのRT3のインターフェースアドレスの最後のバイトが3、それにインターフェイスアドレス192.1.1.3と192.1.4.3を与え、他のルーターは同様のアドレッシングスキームを持っています。さらに、すべてのリンクが機能しており、ルーターIDが最小のIPインターフェイスアドレスとして割り当てられていると想定します。
RT3 originates two router-LSAs, one for Area 1 and one for the backbone. Assume that Router RT4 has been selected as the Designated router for network 192.1.1.0. RT3's router-LSA for Area 1 is then shown below. It indicates that RT3 has two connections to Area 1, the first a link to the transit network 192.1.1.0 and the second a link to the stub network 192.1.4.0. Note that the transit network is identified by the IP interface of its Designated Router (i.e., the Link ID = 192.1.1.4 which is the Designated Router RT4's IP interface to 192.1.1.0). Note also that RT3 has indicated that it is an area border router.
RT3は、エリア1用とバックボーン用の2つのルーターLSAを発信します。ルーターRT4がネットワーク192.1.1.0の指定ルーターとして選択されていると想定します。次に、エリア1のRT3のルーターLSAを以下に示します。これは、RT3がエリア1への2つの接続を持っていることを示しています。1つ目はトランジットネットワーク192.1.1.0へのリンク、2つ目はスタブネットワーク192.1.4.0へのリンクです。トランジットネットワークは、指定ルーターのIPインターフェースによって識別されることに注意してください（つまり、指定ルーターRT4の192.1.1.0へのIPインターフェースであるリンクID = 192.1.1.4）。 RT3はエリア境界ルーターであることを示していることにも注意してください。
; RT3's router-LSA for Area 1
;エリア1のRT3のルーターLSA
LS age = 0 ;always true on origination
Options = (E-bit) ;
LS type = 1 ;indicates router-LSA
Link State ID = 192.1.1.3 ;RT3's Router ID
Advertising Router = 192.1.1.3 ;RT3's Router ID
bit E = 0 ;not an AS boundary router bit B = 1 ;area border router
#links = 2
Link ID = 192.1.1.4 ;IP address of Desig. Rtr.
Link Data = 192.1.1.3 ;RT3's IP interface to net
Type = 2 ;connects to transit network
# TOS metrics = 0
metric = 1
Link ID = 192.1.4.0 ;IP Network number
Link Data = 0xffffff00 ;Network mask
Type = 3 ;connects to stub network
# TOS metrics = 0
metric = 2
Next RT3's router-LSA for the backbone is shown. It indicates that RT3 has a single attachment to the backbone. This attachment is via an unnumbered point-to-point link to Router RT6. RT3 has again indicated that it is an area border router.
次のRT3のバックボーン用のルーターLSAを示します。これは、RT3がバックボーンに単一のアタッチメントを持っていることを示しています。この接続は、ルーターRT6への番号なしポイントツーポイントリンクを介して行われます。 RT3は、これがエリア境界ルーターであることを再度示しています。
; RT3's router-LSA for the backbone
;バックボーン用のRT3のルーターLSA
LS age = 0 ;always true on origination
Options = (E-bit) ;
LS type = 1 ;indicates router-LSA
Link State ID = 192.1.1.3 ;RT3's router ID
Advertising Router = 192.1.1.3 ;RT3's router ID
bit E = 0 ;not an AS boundary router
bit B = 1 ;area border router
#links = 1
Link ID = 18.10.0.6 ;Neighbor's Router ID
Link Data = 0.0.0.3 ;MIB-II ifIndex of P-P link
Type = 1 ;connects to router
# TOS metrics = 0
metric = 8
12.4.2. Network-LSAs
12.4.2. ネットワークLSA
A network-LSA is generated for every transit broadcast or NBMA network. (A transit network is a network having two or more attached routers). The network-LSA describes all the routers that are attached to the network.
ネットワークLSAは、トランジットブロードキャストまたはNBMAネットワークごとに生成されます。 （トランジットネットワークは、2つ以上のルーターが接続されているネットワークです）。 network-LSAは、ネットワークに接続されているすべてのルーターを表します。
The Designated Router for the network originates the LSA. The Designated Router originates the LSA only if it is fully adjacent to at least one other router on the network. The network-LSA is flooded throughout the area that contains the transit network, and no further. The network-LSA lists those routers that are fully adjacent to the Designated Router; each fully adjacent router is identified by its OSPF Router ID. The Designated Router includes itself in this list.
ネットワークの指定ルーターがLSAを発信します。指定ルーターは、ネットワーク上の他の少なくとも1つのルーターに完全に隣接している場合にのみ、LSAを発信します。ネットワークLSAは、トランジットネットワークを含むエリア全体にフラッディングされ、それ以上はフラッディングされません。ネットワークLSAは、指定ルーターに完全に隣接しているルーターをリストします。完全に隣接する各ルーターは、そのOSPFルーターIDによって識別されます。指定ルーターはこのリストに含まれています。
The Link State ID for a network-LSA is the IP interface address of the Designated Router. This value, masked by the network's address mask (which is also contained in the network-LSA) yields the network's IP address.
ネットワークLSAのリンク状態IDは、代表ルーターのIPインターフェイスアドレスです。この値は、ネットワークのアドレスマスク（ネットワークLSAにも含まれています）によってマスクされ、ネットワークのIPアドレスを生成します。
A router that has formerly been the Designated Router for a network, but is no longer, should flush the network-LSA that it had previously originated. This LSA is no longer used in the routing table calculation. It is flushed by prematurely incrementing the LSA's age to MaxAge and reflooding (see Section 14.1). In addition, in those rare cases where a router's Router ID has changed, any network-LSAs that were originated with the router's previous Router ID must be flushed. Since the router may have no idea what it's previous Router ID might have been, these network-LSAs are indicated by having their Link State ID equal to one of the router's IP interface addresses and their Advertising Router equal to some value other than the router's current Router ID (see Section 13.4 for more details).
以前はネットワークの指定ルーターであったが、現在は指定されていないルーターは、以前に発生したネットワークLSAをフラッシュする必要があります。このLSAは、ルーティングテーブルの計算で使用されなくなりました。 LSAの年齢をMaxAgeに早めにインクリメントして再フラッディングすることでフラッシュされます（セクション14.1を参照）。さらに、ルーターのルーターIDが変更されたまれなケースでは、ルーターの以前のルーターIDで作成されたネットワークLSAをフラッシュする必要があります。ルーターは以前のルーターIDが何であったかわからない場合があるため、これらのネットワークLSAは、リンク状態IDがルーターのIPインターフェイスアドレスの1つと等しく、アドバタイジングルーターがルーターの現在の値以外の値に等しいことで示されます。ルーターID（詳細はセクション13.4を参照）。
12.4.2.1. Examples of network-LSAs
12.4.2.1. ネットワークLSAの例
Again consider the area configuration in Figure 6. Network-LSAs are originated for Network N3 in Area 1, Networks N6 and N8 in Area 2, and Network N9 in Area 3. Assuming that Router RT4 has been selected as the Designated Router for Network N3, the following network-LSA is generated by RT4 on behalf of Network N3 (see Figure 15 for the address assignments):
再び図6のエリア構成を検討してください。ネットワークLSAは、エリア1のネットワークN3、エリア2のネットワークN6およびN8、およびエリア3のネットワークN9から発信されています。ルーターRT4がネットワークN3の指定ルーターとして選択されているとします。 、次のネットワークLSAは、ネットワークN3に代わってRT4によって生成されます（アドレス割り当てについては、図15を参照してください）。
; Network-LSA for Network N3 LS age = 0 ;always true on origination
Options = (E-bit) ;
LS type = 2 ;indicates network-LSA
Link State ID = 192.1.1.4 ;IP address of Desig. Rtr.
Advertising Router = 192.1.1.4 ;RT4's Router ID
Network Mask = 0xffffff00
Attached Router = 192.1.1.4 ;Router ID
Attached Router = 192.1.1.1 ;Router ID
Attached Router = 192.1.1.2 ;Router ID
Attached Router = 192.1.1.3 ;Router ID
12.4.3. Summary-LSAs
12.4.3. 概要-LSA
The destination described by a summary-LSA is either an IP network, an AS boundary router or a range of IP addresses. Summary-LSAs are flooded throughout a single area only. The destination described is one that is external to the area, yet still belongs to the Autonomous System.
サマリーLSAで記述される宛先は、IPネットワーク、AS境界ルーター、またはIPアドレスの範囲のいずれかです。サマリーLSAは、単一の領域のみにフラッディングされます。説明されている宛先は、エリアの外部にあるものですが、まだ自律システムに属しています。
Summary-LSAs are originated by area border routers. The precise summary routes to advertise into an area are determined by examining the routing table structure (see Section 11) in accordance with the algorithm described below. Note that only intra-area routes are advertised into the backbone, while both intra-area and inter-area routes are advertised into the other areas.
サマリーLSAは、エリア境界ルーターによって発信されます。エリアにアドバタイズする正確なサマリールートは、以下で説明するアルゴリズムに従ってルーティングテーブルの構造（セクション11を参照）を調べることによって決定されます。エリア内ルートのみがバックボーンにアドバタイズされ、エリア内ルートとエリア間ルートの両方が他のエリアにアドバタイズされることに注意してください。
To determine which routes to advertise into an attached Area A, each routing table entry is processed as follows. Remember that each routing table entry describes a set of equal-cost best paths to a particular destination:
接続されているエリアAにアドバタイズするルートを決定するために、各ルーティングテーブルエントリは次のように処理されます。各ルーティングテーブルエントリは、特定の宛先への等コストの最良パスのセットを記述していることに注意してください。
o Only Destination Types of network and AS boundary router are advertised in summary-LSAs. If the routing table entry's Destination Type is area border router, examine the next routing table entry.
o サマリーLSAでは、ネットワークの宛先タイプとAS境界ルーターのみがアドバタイズされます。ルーティングテーブルエントリの宛先タイプがエリア境界ルーターの場合は、次のルーティングテーブルエントリを調べます。
o AS external routes are never advertised in summary-LSAs. If the routing table entry has Path-type of type 1 external or type 2 external, examine the next routing table entry.
o AS外部ルートは、サマリーLSAでは決してアドバタイズされません。ルーティングテーブルエントリにタイプ1外部またはタイプ2外部のパスタイプがある場合は、次のルーティングテーブルエントリを調べます。
o Else, if the area associated with this set of paths is the Area A itself, do not generate a summary-LSA for the route.[17]
o それ以外の場合、このパスのセットに関連付けられているエリアがエリアA自体である場合は、ルートのサマリーLSAを生成しないでください。[17]
o Else, if the next hops associated with this set of paths belong to Area A itself, do not generate a summary-LSA for the route.[18] This is the logical equivalent of a Distance Vector protocol's split horizon logic.
o それ以外の場合、このパスのセットに関連付けられているネクストホップがエリアA自体に属している場合は、ルートのサマリーLSAを生成しません。これは、Distance Vectorプロトコルのスプリットホライズンロジックと論理的に同等です。
o Else, if the routing table cost equals or exceeds the value LSInfinity, a summary-LSA cannot be generated for this route.
o それ以外の場合、ルーティングテーブルのコストがLSInfinityの値以上の場合、このルートのサマリーLSAを生成できません。
o Else, if the destination of this route is an AS boundary router, a summary-LSA should be originated if and only if the routing table entry describes the preferred path to the AS boundary router (see Step 3 of Section 16.4). If so, a Type 4 summary-LSA is originated for the destination, with Link State ID equal to the AS boundary router's Router ID and metric equal to the routing table entry's cost. Note: these LSAs should not be generated if Area A has been configured as a stub area.
o そうでない場合、このルートの宛先がAS境界ルーターである場合、ルーティングテーブルエントリがAS境界ルーターへの優先パスを記述している場合にのみ、サマリーLSAを発信する必要があります（セクション16.4のステップ3を参照）。その場合、リンク状態IDがAS境界ルーターのルーターIDに等しく、メトリックがルーティングテーブルエントリのコストに等しい、タイプ4のサマリーLSAが宛先に対して作成されます。注：これらのLSAは、エリアAがスタブエリアとして構成されている場合は生成しないでください。
o Else, the Destination type is network. If this is an inter-area route, generate a Type 3 summary-LSA for the destination, with Link State ID equal to the network's address (if necessary, the Link State ID can also have one or more of the network's host bits set; see Appendix E for details) and metric equal to the routing table cost.
o それ以外の場合、宛先タイプはネットワークです。これがエリア間ルートの場合は、リンクステートIDがネットワークのアドレスと同じになるように、宛先のタイプ3サマリーLSAを生成します（必要に応じて、リンクステートIDは1つ以上のネットワークのホストビットセットを持つこともできます。詳細については、付録Eを参照）およびルーティングテーブルのコストに等しいメトリック。
o The one remaining case is an intra-area route to a network. This means that the network is contained in one of the router's directly attached areas. In general, this information must be condensed before appearing in summary-LSAs. Remember that an area has a configured list of address ranges, each range consisting of an [address,mask] pair and a status indication of either Advertise or DoNotAdvertise. At most a single Type 3 summary-LSA is originated for each range. When the range's status indicates Advertise, a Type 3 summary-LSA is generated with Link State ID equal to the range's address (if necessary, the Link State ID can also have one or more of the range's "host" bits set; see Appendix E for details) and cost equal to the largest cost of any of the component networks. When the range's status indicates DoNotAdvertise, the Type 3 summary-LSA is suppressed and the component networks remain hidden from other areas.
o 残りの1つのケースは、ネットワークへのエリア内ルートです。これは、ネットワークがルーターの直接接続された領域の1つに含まれていることを意味します。一般に、この情報はサマリーLSAに表示する前に要約する必要があります。エリアには構成済みのアドレス範囲のリストがあり、各範囲は[address、mask]ペアとAdvertiseまたはDoNotAdvertiseのステータス表示で構成されていることに注意してください。各範囲に対して最大で1つのタイプ3サマリーLSAが作成されます。範囲のステータスがAdvertiseを示す場合、リンクステートIDが範囲のアドレスと等しいタイプ3サマリーLSAが生成されます（必要に応じて、リンクステートIDは範囲の「ホスト」ビットを1つ以上設定することもできます。付録Eを参照してください）詳細については）、コンポーネントネットワークの最大コストに等しいコスト。範囲のステータスがDoNotAdvertiseを示す場合、タイプ3サマリーLSAは抑制され、コンポーネントネットワークは他のエリアから隠されたままになります。
By default, if a network is not contained in any explicitly configured address range, a Type 3 summary-LSA is generated with Link State ID equal to the network's address (if necessary, the Link State ID can also have one or more of the network's "host" bits set; see Appendix E for details) and metric equal to the network's routing table cost.
デフォルトでは、明示的に構成されたアドレス範囲にネットワークが含まれていない場合、リンクステートIDがネットワークのアドレスと等しいタイプ3サマリーLSAが生成されます（必要に応じて、リンクステートIDは1つ以上のネットワークの「ホスト」ビットセット。詳細については付録Eを参照してください）、ネットワークのルーティングテーブルコストに等しいメトリック。
If an area is capable of carrying transit traffic (i.e., its TransitCapability is set to TRUE), routing information concerning backbone networks should not be condensed before being summarized into the area. Nor should the advertisement of backbone networks into transit areas be suppressed. In other words, the backbone's configured ranges should be ignored when originating summary-LSAs into transit areas.
エリアがトランジットトラフィックを伝送できる場合（つまり、そのTransitCapabilityがTRUEに設定されている場合）、バックボーンネットワークに関するルーティング情報は、エリアに集約する前に圧縮しないでください。トランジットエリアへのバックボーンネットワークのアドバタイズも抑制されるべきではありません。言い換えると、サマリーLSAをトランジットエリアに発信する場合は、バックボーンの設定範囲を無視する必要があります。
If a router advertises a summary-LSA for a destination which then becomes unreachable, the router must then flush the LSA from the routing domain by setting its age to MaxAge and reflooding (see Section 14.1). Also, if the destination is still reachable, yet can no longer be advertised according to the above procedure (e.g., it is now an inter-area route, when it used to be an intra-area route associated with some non-backbone area; it would thus no longer be advertisable to the backbone), the LSA should also be flushed from the routing domain.
ルーターが宛先のサマリーLSAをアドバタイズし、到達不能になった場合、ルーターは、エージをMaxAgeに設定して再フラッディングすることにより、ルーティングドメインからLSAをフラッシュする必要があります（セクション14.1を参照）。また、宛先がまだ到達可能であるにもかかわらず、上記の手順に従ってアドバタイズできなくなった場合（たとえば、以前は一部の非バックボーンエリアに関連付けられたエリア内ルートだった場合、エリア間ルートになります）。したがって、バックボーンにアドバタイズできなくなります）、LSAもルーティングドメインからフラッシュする必要があります。
12.4.3.1. Originating summary-LSAs into stub areas
12.4.3.1. サマリーLSAをスタブエリアに発信
The algorithm in Section 12.4.3 is optional when Area A is an OSPF stub area. Area border routers connecting to a stub area can originate summary-LSAs into the area according to the Section 12.4.3's algorithm, or can choose to originate only a subset of the summary-LSAs, possibly under configuration control. The fewer LSAs originated, the smaller the stub area's link state database, further reducing the demands on its routers' resources. However, omitting LSAs may also lead to sub-optimal inter-area routing, although routing will continue to function.
セクションAがOSPFスタブエリアの場合、セクション12.4.3のアルゴリズムはオプションです。スタブエリアに接続するエリアボーダールーターは、セクション12.4.3のアルゴリズムに従ってサマリーLSAをエリアに発信するか、または構成制御下でサマリーLSAのサブセットのみを発信することを選択できます。発信されるLSAが少ないほど、スタブエリアのリンク状態データベースが小さくなり、ルーターのリソースに対する要求がさらに減少します。ただし、LSAを省略すると、エリア間ルーティングが最適でなくなる可能性がありますが、ルーティングは機能し続けます。
As specified in Section 12.4.3, Type 4 summary-LSAs (ASBR-summary-LSAs) are never originated into stub areas.
セクション12.4.3で指定されているように、タイプ4サマリーLSA（ASBRサマリーLSA）がスタブエリアに発信されることはありません。
In a stub area, instead of importing external routes each area border router originates a "default summary-LSA" into the area. The Link State ID for the default summary-LSA is set to DefaultDestination, and the metric set to the (per-area) configurable parameter StubDefaultCost. Note that StubDefaultCost need not be configured identically in all of the stub area's area border routers.
スタブエリアでは、外部ルートをインポートする代わりに、各エリア境界ルーターが「デフォルトのサマリーLSA」をエリアに発信します。デフォルトのサマリーLSAのリンク状態IDはDefaultDestinationに設定され、メトリックは（エリアごとの）構成可能パラメーターStubDefaultCostに設定されます。 StubDefaultCostは、すべてのスタブエリアのエリア境界ルーターで同じように構成する必要がないことに注意してください。
12.4.3.2. Examples of summary-LSAs
12.4.3.2. 要約LSAの例
Consider again the area configuration in Figure 6. Routers RT3, RT4, RT7, RT10 and RT11 are all area border routers, and therefore are originating summary-LSAs. Consider in particular Router RT4. Its routing table was calculated as the example in Section 11.3. RT4 originates summary-LSAs into both the backbone and Area 1. Into the backbone, Router RT4 originates separate LSAs for each of the networks N1-N4. Into Area 1, Router RT4 originates separate LSAs for networks N6-N8 and the AS boundary routers RT5,RT7. It also condenses host routes Ia and Ib into a single summary-LSA. Finally, the routes to networks N9,N10,N11 and Host H1 are advertised by a single summary-LSA. This condensation was originally performed by the router RT11.
もう一度、図6のエリア構成を検討してください。ルーターRT3、RT4、RT7、RT10、およびRT11はすべてエリア境界ルーターであるため、サマリーLSAを発信しています。特にルーターRT4を検討してください。そのルーティングテーブルは、セクション11.3の例として計算されました。 RT4は、サマリーLSAをバックボーンとエリア1の両方に発信します。バックボーンへのルーターRT4は、ネットワークN1〜N4ごとに個別のLSAを発信します。エリア1には、ルーターRT4がネットワークN6-N8およびAS境界ルーターRT5、RT7の個別のLSAを発信します。また、ホストルートIaとIbを1つのサマリーLSAに集約します。最後に、ネットワークN9、N10、N11およびホストH1へのルートは、単一のサマリーLSAによってアドバタイズされます。この結露は、もともとルーターRT11によって実行されました。
These LSAs are illustrated graphically in Figures 7 and 8. Two of the summary-LSAs originated by Router RT4 follow. The actual IP addresses for the networks and routers in question have been assigned in Figure 15.
これらのLSAは、図7および8にグラフで示されています。ルーターRT4によって生成された2つのサマリーLSAが続きます。問題のネットワークとルーターの実際のIPアドレスは、図15で割り当てられています。
; Summary-LSA for Network N1, ; originated by Router RT4 into the backbone
;ネットワークN1のサマリーLSA 、;ルーターRT4からバックボーンに発信
LS age = 0 ;always true on origination
Options = (E-bit) ;
LS type = 3 ;Type 3 summary-LSA
Link State ID = 192.1.2.0 ;N1's IP network number
Advertising Router = 192.1.1.4 ;RT4's ID
metric = 4
; Summary-LSA for AS boundary router RT7 ; originated by Router RT4 into Area 1
; AS境界ルーターRT7の概要LSA。ルーターRT4からエリア1に発信
LS age = 0 ;always true on origination
Options = (E-bit) ;
LS type = 4 ;Type 4 summary-LSA
Link State ID = Router RT7's ID
Advertising Router = 192.1.1.4 ;RT4's ID
metric = 14
12.4.4. AS-external-LSAs
12.4.4. AS外部LSA
AS-external-LSAs describe routes to destinations external to the Autonomous System. Most AS-external-LSAs describe routes to specific external destinations; in these cases the LSA's Link State ID is set to the destination network's IP address (if necessary, the Link State ID can also have one or more of the network's "host" bits set; see Appendix E for details). However, a default route for the Autonomous System can be described in an AS-external-LSA by setting the LSA's Link State ID to DefaultDestination (0.0.0.0). AS-external-LSAs are originated by AS boundary routers. An AS boundary router originates a single AS-external-LSA for each external route that it has learned, either through another routing protocol (such as BGP), or through configuration information.
AS外部LSAは、自律システムの外部の宛先へのルートを記述します。ほとんどのAS外部LSAは、特定の外部宛先へのルートを記述します。これらの場合、LSAのリンク状態IDは宛先ネットワークのIPアドレスに設定されます（必要に応じて、リンク状態IDは1つ以上のネットワークの「ホスト」ビットセットを持つこともできます。詳細は付録Eを参照してください）。ただし、自律システムのデフォルトルートは、LSAのリンク状態IDをDefaultDestination（0.0.0.0）に設定することにより、AS-external-LSAで説明できます。 AS外部LSAは、AS境界ルーターによって発信されます。 AS境界ルーターは、別のルーティングプロトコル（BGPなど）を介して、または構成情報を介して、学習した外部ルートごとに単一のAS外部LSAを発信します。
AS-external-LSAs are the only type of LSAs that are flooded throughout the entire Autonomous System; all other types of LSAs are specific to a single area. However, AS-external-LSAs are not flooded into/throughout stub areas (see Section 3.6). This enables a reduction in link state database size for routers internal to stub areas.
AS外部LSAは、自律システム全体にフラッディングされる唯一のタイプのLSAです。他のすべてのタイプのLSAは、単一のエリアに固有です。ただし、AS外部LSAはスタブエリアにフラッディングまたはスルーされません（セクション3.6を参照）。これにより、スタブエリアの内部にあるルーターのリンク状態データベースのサイズを縮小できます。
The metric that is advertised for an external route can be one of two types. Type 1 metrics are comparable to the link state metric. Type 2 metrics are assumed to be larger than the cost of any intra-AS path.
外部ルートにアドバタイズされるメトリックは、2つのタイプのいずれかになります。タイプ1メトリックは、リンク状態メトリックに相当します。タイプ2メトリックは、AS内パスのコストよりも大きいと想定されています。
If a router advertises an AS-external-LSA for a destination which then becomes unreachable, the router must then flush the LSA from the routing domain by setting its age to MaxAge and reflooding (see Section 14.1).
ルーターが宛先にAS-external-LSAをアドバタイズし、その宛先が到達不能になった場合、ルーターは、エージをMaxAgeに設定して再フラッディングすることにより、ルーティングドメインからLSAをフラッシュする必要があります（セクション14.1を参照）。
12.4.4.1. Examples of AS-external-LSAs
12.4.4.1. AS-external-LSAの例
Consider once again the AS pictured in Figure 6. There are two AS boundary routers: RT5 and RT7. Router RT5 originates three AS-external-LSAs, for networks N12-N14. Router RT7 originates two AS-external-LSAs, for networks N12 and N15. Assume that RT7 has learned its route to N12 via BGP, and that it wishes to advertise a Type 2 metric to the AS. RT7 would then originate the following LSA for N12:
もう一度、図6に示されているASを考えてみます。RT5とRT7の2つのAS境界ルーターがあります。ルーターRT5は、ネットワークN12〜N14の3つのAS外部LSAを発信します。ルーターRT7は、ネットワークN12とN15の2つのAS外部LSAを発信します。 RT7がBGPを介してN12へのルートを学習し、タイプ2メトリックをASにアドバタイズしたいとします。 RT7は、N12の次のLSAを発信します。
; AS-external-LSA for Network N12, ; originated by Router RT7
; AS-external-LSA for Network N12、ルーターRT7から発信
LS age = 0 ;always true on origination
Options = (E-bit) ;
LS type = 5 ;AS-external-LSA
Link State ID = N12's IP network number
Advertising Router = Router RT7's ID
bit E = 1 ;Type 2 metric
metric = 2
Forwarding address = 0.0.0.0
In the above example, the forwarding address field has been set to 0.0.0.0, indicating that packets for the external destination should be forwarded to the advertising OSPF router (RT7). This is not always desirable. Consider the example pictured in Figure 16. There are three OSPF routers (RTA, RTB and RTC) connected to a common network. Only one of these routers, RTA, is exchanging BGP information with the non-OSPF router RTX. RTA must then originate AS-external-LSAs for those destinations it has learned from RTX. By using the AS-external-LSA's forwarding address field, RTA can specify that packets for these destinations be forwarded directly to RTX. Without this feature, Routers RTB and RTC would take an extra hop to get to these destinations.
上記の例では、転送アドレスフィールドが0.0.0.0に設定されています。これは、外部宛先のパケットがアドバタイズOSPFルーター（RT7）に転送されることを示しています。これは常に望ましいとは限りません。図16の例を検討してください。共通ネットワークに接続されている3つのOSPFルーター（RTA、RTB、RTC）があります。これらのルーターの1つであるRTAのみが、OSPF以外のルーターRTXとBGP情報を交換しています。 RTAは、RTXから学習した宛先に対して、AS外部LSAを発信する必要があります。 AS-external-LSAの転送アドレスフィールドを使用することにより、RTAはこれらの宛先へのパケットが直接RTXに転送されるように指定できます。この機能がなければ、ルーターRTBとRTCはこれらの宛先に到達するために余分なホップを必要とします。
Note that when the forwarding address field is non-zero, it should point to a router belonging to another Autonomous System.
転送アドレスフィールドがゼロ以外の場合は、別の自律システムに属するルーターを指す必要があることに注意してください。
A forwarding address can also be specified for the default route. For example, in figure 16 RTA may want to specify that all externally-destined packets should by default be forwarded to its BGP peer RTX. The resulting AS-external-LSA is pictured below. Note that the Link State ID is set to DefaultDestination.
転送先アドレスは、デフォルトルートに指定することもできます。たとえば、図16で、RTAは、すべての外部宛てのパケットがデフォルトでBGPピアRTXに転送されるように指定する場合があります。結果のAS-external-LSAを以下に示します。リンク状態IDがDefaultDestinationに設定されていることに注意してください。
; Default route, originated by Router RTA ; Packets forwarded through RTX
;ルーターRTAから発信されたデフォルトルート。 RTXを介して転送されたパケット
LS age = 0 ;always true on origination
Options = (E-bit) ;
LS type = 5 ;AS-external-LSA
Link State ID = DefaultDestination ; default route
Advertising Router = Router RTA's ID
bit E = 1 ;Type 2 metric
metric = 1
Forwarding address = RTX's IP address
In figure 16, suppose instead that both RTA and RTB exchange BGP information with RTX. In this case, RTA and RTB would originate the same set of AS-external-LSAs. These LSAs, if they specify the same metric, would be functionally equivalent since they would specify the same destination and forwarding address (RTX). This leads to a clear duplication of effort. If only one of RTA or RTB originated the set of AS-external-LSAs, the routing would remain the same, and the size of the link state database would decrease. However, it must be unambiguously defined as to which router originates the LSAs (otherwise neither may, or the identity of the originator may oscillate). The following rule is thereby established: if two routers, both reachable from one another, originate functionally equivalent AS-external-LSAs (i.e., same destination, cost and non-zero forwarding address), then the LSA originated by the router having the highest OSPF Router ID is used. The router having the lower OSPF Router ID can then flush its LSA. Flushing an LSA is discussed in Section 14.1.
図16では、RTAとRTBの両方がBGP情報をRTXと交換するとします。この場合、RTAとRTBは同じセットのAS外部LSAを発信します。これらのLSAは、同じメトリックを指定する場合、同じ宛先および転送アドレス（RTX）を指定するため、機能的に同等です。これは明らかに努力の重複につながります。 RTAまたはRTBのいずれか1つだけがAS-external-LSAのセットを発信した場合、ルーティングは同じままで、リンク状態データベースのサイズは減少します。ただし、LSAを発信するルーターを明確に定義する必要があります（そうしないと、LSAが発信されないか、発信者のIDが振動する場合があります）。これにより、次のルールが確立されます。どちらも互いに到達可能な2つのルーターが機能的に同等のAS外部LSA（つまり、同じ宛先、コスト、ゼロ以外の転送アドレス）を発信する場合、LSAは最高のルーターによって発信されます。 OSPFルーターIDが使用されます。 OSPFルーターIDが小さいルーターは、LSAをフラッシュできます。 LSAのフラッシュについては、セクション14.1で説明します。
+
|
+---+.....|.BGP
|RTA|-----|.....+---+
+---+ |-----|RTX|
| +---+
+---+ |
|RTB|-----|
+---+ |
|
+---+ |
|RTC|-----|
+---+ |
|
+
Figure 16: Forwarding address example
図16：転送アドレスの例
Link State Update packets provide the mechanism for flooding LSAs. A Link State Update packet may contain several distinct LSAs, and floods each LSA one hop further from its point of origination. To make the flooding procedure reliable, each LSA must be acknowledged separately. Acknowledgments are transmitted in Link State Acknowledgment packets. Many separate acknowledgments can also be grouped together into a single packet.
リンク状態更新パケットは、LSAをフラッディングするメカニズムを提供します。リンク状態更新パケットには複数の異なるLSAが含まれている場合があり、各LSAはその発信点からさらに1ホップあふれます。フラッディング手順の信頼性を高めるには、各LSAを個別に確認する必要があります。確認応答は、リンク状態確認応答パケットで送信されます。多くの個別の確認応答を1つのパケットにまとめることもできます。
The flooding procedure starts when a Link State Update packet has been received. Many consistency checks have been made on the received packet before being handed to the flooding procedure (see Section 8.2). In particular, the Link State Update packet has been associated with a particular neighbor, and a particular area. If the neighbor is in a lesser state than Exchange, the packet should be dropped without further processing.
フラッディング手順は、リンク状態更新パケットが受信されたときに開始されます。フラッディング手順に渡される前に、受信したパケットに対して多くの整合性チェックが行われました（セクション8.2を参照）。特に、リンク状態更新パケットは特定のネイバーと特定のエリアに関連付けられています。ネイバーの状態がExchangeより低い場合、パケットはそれ以上処理されずにドロップされるはずです。
All types of LSAs, other than AS-external-LSAs, are associated with a specific area. However, LSAs do not contain an area field. An LSA's area must be deduced from the Link State Update packet header.
AS外部LSA以外のすべてのタイプのLSAは、特定のエリアに関連付けられています。ただし、LSAにはエリアフィールドが含まれていません。 LSAの領域は、リンク状態更新パケットヘッダーから推定する必要があります。
For each LSA contained in a Link State Update packet, the following steps are taken:
リンク状態更新パケットに含まれるLSAごとに、次の手順が実行されます。
(1) Validate the LSA's LS checksum. If the checksum turns out to be invalid, discard the LSA and get the next one from the Link State Update packet.
（1）LSAのLSチェックサムを検証します。チェックサムが無効であることが判明した場合は、LSAを破棄し、リンク状態更新パケットから次のLSAを取得します。
(2) Examine the LSA's LS type. If the LS type is unknown, discard the LSA and get the next one from the Link State Update Packet. This specification defines LS types 1-5 (see Section 4.3).
（2）LSAのLSタイプを調べます。 LSタイプが不明な場合は、LSAを破棄し、リンク状態更新パケットから次のものを取得します。この仕様では、LSタイプ1〜5を定義しています（セクション4.3を参照）。
(3) Else if this is an AS-external-LSA (LS type = 5), and the area has been configured as a stub area, discard the LSA and get the next one from the Link State Update Packet. AS-external-LSAs are not flooded into/throughout stub areas (see Section 3.6).
（3）これがAS-external-LSA（LSタイプ= 5）で、エリアがスタブエリアとして構成されている場合は、LSAを破棄し、リンク状態更新パケットから次のLSAを取得します。 AS-external-LSAは、スタブエリア内またはスタブエリア全体にフラッディングされません（セクション3.6を参照）。
(4) Else if the LSA's LS age is equal to MaxAge, and there is currently no instance of the LSA in the router's link state database, and none of router's neighbors are in states Exchange or Loading, then take the following actions: a) Acknowledge the receipt of the LSA by sending a Link State Acknowledgment packet back to the sending neighbor (see Section 13.5), and b) Discard the LSA and examine the next LSA (if any) listed in the Link State Update packet.
（4）LSAのLSエージがMaxAgeと等しく、現在ルーターのリンク状態データベースにLSAのインスタンスがなく、ルーターのネイバーのいずれも状態がExchangeまたはLoadingでない場合は、次のアクションを実行します。 Link State Acknowledgementパケットを送信側ネイバーに送信することにより（セクション13.5を参照）、LSAの受信を確認し、b）LSAを破棄し、Link State Updateパケットにリストされている次のLSA（存在する場合）を調べます。
(5) Otherwise, find the instance of this LSA that is currently contained in the router's link state database. If there is no database copy, or the received LSA is more recent than the database copy (see Section 13.1 below for the determination of which LSA is more recent) the following steps must be performed:
（5）それ以外の場合は、現在ルーターのリンク状態データベースに含まれているこのLSAのインスタンスを見つけます。データベースコピーがない場合、または受信したLSAがデータベースコピーよりも新しい場合（どのLSAがより新しいかについては、以下のセクション13.1を参照）、次の手順を実行する必要があります。
(a) If there is already a database copy, and if the database copy was received via flooding and installed less than MinLSArrival seconds ago, discard the new LSA (without acknowledging it) and examine the next LSA (if any) listed in the Link State Update packet.
（a）すでにデータベースコピーがあり、データベースコピーがフラッディング経由で受信され、MinLSArrival秒前にインストールされた場合、新しいLSAを破棄し（確認応答なし）、リンクにリストされている次のLSA（存在する場合）を調べます状態更新パケット。
(b) Otherwise immediately flood the new LSA out some subset of the router's interfaces (see Section 13.3). In some cases (e.g., the state of the receiving interface is DR and the LSA was received from a router other than the Backup DR) the LSA will be flooded back out the receiving interface. This occurrence should be noted for later use by the acknowledgment process (Section 13.5).
（b）そうでない場合は、新しいLSAをすぐにルーターのインターフェースのサブセットにフラッディングします（セクション13.3を参照）。場合によっては（たとえば、受信インターフェイスの状態がDRであり、LSAがバックアップDR以外のルーターから受信された場合）、LSAは受信インターフェイスからフラッディングされます。この発生は、後で確認プロセスで使用するために記録する必要があります（セクション13.5）。
(c) Remove the current database copy from all neighbors' Link state retransmission lists.
（c）すべてのネイバーのリンク状態再送信リストから現在のデータベースコピーを削除します。
(d) Install the new LSA in the link state database (replacing the current database copy). This may cause the routing table calculation to be scheduled. In addition, timestamp the new LSA with the current time (i.e., the time it was received). The flooding procedure cannot overwrite the newly installed LSA until MinLSArrival seconds have elapsed. The LSA installation process is discussed further in Section 13.2.
（d）新しいLSAをリンク状態データベースにインストールします（現在のデータベースコピーを置き換えます）。これにより、ルーティングテーブルの計算がスケジュールされる可能性があります。さらに、新しいLSAに現在の時刻（つまり、受信した時刻）のタイムスタンプを付けます。フラッディング手順では、MinLSArrival秒が経過するまで、新しくインストールされたLSAを上書きできません。 LSAインストールプロセスについては、セクション13.2で詳しく説明します。
(e) Possibly acknowledge the receipt of the LSA by sending a Link State Acknowledgment packet back out the receiving interface. This is explained below in Section 13.5.
（e）リンク状態確認パケットを受信インターフェイスに送り返すことにより、LSAの受信を確認する可能性があります。これについては、セクション13.5で説明します。
(f) If this new LSA indicates that it was originated by the receiving router itself (i.e., is considered a self-originated LSA), the router must take special action, either updating the LSA or in some cases flushing it from the routing domain. For a description of how self-originated LSAs are detected and subsequently handled, see Section 13.4.
（f）この新しいLSAが、それが受信側ルーター自体によって発信されたことを示す場合（つまり、自己発信LSAと見なされる）、ルーターはLSAを更新するか、場合によってはルーティングドメインからフラッシュするという特別なアクションを実行する必要があります。自己発信LSAが検出され、その後処理される方法については、セクション13.4を参照してください。
(6) Else, if there is an instance of the LSA on the sending neighbor's Link state request list, an error has occurred in the Database Exchange process. In this case, restart the Database Exchange process by generating the neighbor event BadLSReq for the sending neighbor and stop processing the Link State Update packet.
（6）それ以外の場合、送信側ネイバーのリンク状態要求リストにLSAのインスタンスがある場合、データベース交換プロセスでエラーが発生しています。この場合、送信側ネイバーのネイバーイベントBadLSReqを生成してデータベース交換プロセスを再開し、リンク状態更新パケットの処理を停止します。
(7) Else, if the received LSA is the same instance as the database copy (i.e., neither one is more recent) the following two steps should be performed:
（7）それ以外の場合、受信したLSAがデータベースコピーと同じインスタンスである場合（つまり、どちらも最近のものではない場合）、次の2つの手順を実行する必要があります。
(a) If the LSA is listed in the Link state retransmission list for the receiving adjacency, the router itself is expecting an acknowledgment for this LSA. The router should treat the received LSA as an acknowledgment by removing the LSA from the Link state retransmission list. This is termed an "implied acknowledgment". Its occurrence should be noted for later use by the acknowledgment process (Section 13.5).
（a）LSAが受信隣接のリンク状態再送信リストにリストされている場合、ルーター自体がこのLSAの確認応答を期待しています。ルーターは、リンク状態の再送信リストからLSAを削除することにより、受信したLSAを確認応答として扱う必要があります。これは「暗黙の確認応答」と呼ばれます。その発生は、確認プロセスで後で使用するために記録する必要があります（セクション13.5）。
(b) Possibly acknowledge the receipt of the LSA by sending a Link State Acknowledgment packet back out the receiving interface. This is explained below in Section 13.5.
（b）おそらく、Link State Acknowledgementパケットを受信インターフェイスに送り返すことにより、LSAの受信を確認します。これについては、セクション13.5で説明します。
(8) Else, the database copy is more recent. If the database copy has LS age equal to MaxAge and LS sequence number equal to MaxSequenceNumber, simply discard the received LSA without acknowledging it. (In this case, the LSA's LS sequence number is wrapping, and the MaxSequenceNumber LSA must be completely flushed before any new LSA instance can be introduced). Otherwise, as long as the database copy has not been sent in a Link State Update within the last MinLSArrival seconds, send the database copy back to the sending neighbor, encapsulated within a Link State Update Packet. The Link State Update Packet should be sent directly to the neighbor. In so doing, do not put the database copy of the LSA on the neighbor's link state retransmission list, and do not acknowledge the received (less recent) LSA instance.
（8）そうでない場合、データベースのコピーはより新しいものです。データベースコピーのLSエージがMaxAgeに等しく、LSシーケンス番号がMaxSequenceNumberに等しい場合、受信したLSAを確認応答せずに破棄します。 （この場合、LSAのLSシーケンス番号はラップしており、新しいLSAインスタンスを導入する前に、MaxSequenceNumber LSAを完全にフラッシュする必要があります）。それ以外の場合、データベースコピーが最後のMinLSArrival秒以内にリンク状態更新で送信されない限り、リンク状態更新パケット内にカプセル化された送信側ネイバーにデータベースコピーを送り返します。リンク状態更新パケットは、ネイバーに直接送信する必要があります。その際、LSAのデータベースコピーをネイバーのリンク状態再送信リストに配置しないでください。また、受信した（最近ではない）LSAインスタンスを確認しないでください。
13.1. Determining which LSA is newer
13.1. 新しいLSAの判別
When a router encounters two instances of an LSA, it must determine which is more recent. This occurred above when comparing a received LSA to its database copy. This comparison must also be done during the Database Exchange procedure which occurs during adjacency bring-up.
ルーターがLSAの2つのインスタンスを検出すると、どちらがより新しいかを判断する必要があります。これは、受信したLSAをデータベースコピーと比較する際に発生しました。この比較は、隣接関係の立ち上げ時に発生するデータベース交換手順中にも実行する必要があります。
An LSA is identified by its LS type, Link State ID and Advertising Router. For two instances of the same LSA, the LS sequence number, LS age, and LS checksum fields are used to determine which instance is more recent:
LSAは、そのLSタイプ、リンク状態ID、および広告ルーターによって識別されます。同じLSAの2つのインスタンスの場合、LSシーケンス番号、LS経過時間、およびLSチェックサムフィールドを使用して、より新しいインスタンスを判別します。
o The LSA having the newer LS sequence number is more recent. See Section 12.1.6 for an explanation of the LS sequence number space. If both instances have the same LS sequence number, then:
o 新しいLSシーケンス番号を持つLSAはより新しいものです。 LSシーケンス番号スペースの説明については、セクション12.1.6を参照してください。両方のインスタンスのLSシーケンス番号が同じ場合、次のようになります。
o If the two instances have different LS checksums, then the instance having the larger LS checksum (when considered as a 16-bit unsigned integer) is considered more recent.
o 2つのインスタンスのLSチェックサムが異なる場合、LSチェックサムが大きいインスタンス（16ビットの符号なし整数と見なされた場合）の方が新しいと見なされます。
o Else, if only one of the instances has its LS age field set to MaxAge, the instance of age MaxAge is considered to be more recent.
o そうでない場合、インスタンスの1つだけのLSエージフィールドがMaxAgeに設定されている場合、エージMaxAgeのインスタンスはより新しいと見なされます。
o Else, if the LS age fields of the two instances differ by more than MaxAgeDiff, the instance having the smaller (younger) LS age is considered to be more recent.
o それ以外の場合、2つのインスタンスのLS年齢フィールドがMaxAgeDiffよりも大きく異なる場合、LS年齢が小さい（若い）インスタンスがより新しいと見なされます。
o Else, the two instances are considered to be identical.
o そうでない場合、2つのインスタンスは同一であると見なされます。
13.2. Installing LSAs in the database
13.2. データベースへのLSAのインストール
Installing a new LSA in the database, either as the result of flooding or a newly self-originated LSA, may cause the OSPF routing table structure to be recalculated. The contents of the new LSA should be compared to the old instance, if present. If there is no difference, there is no need to recalculate the routing table. When comparing an LSA to its previous instance, the following are all considered to be differences in contents:
フラッディングの結果として、または新しく自己生成されたLSAの結果として、データベースに新しいLSAをインストールすると、OSPFルーティングテーブルの構造が再計算される場合があります。新しいLSAの内容は、古いインスタンス（存在する場合）と比較する必要があります。差異がない場合、ルーティングテーブルを再計算する必要はありません。 LSAを以前のインスタンスと比較する場合、以下はすべて内容の違いと見なされます。
o The LSA's Options field has changed.
o LSAのオプションフィールドが変更されました。
o One of the LSA instances has LS age set to MaxAge, and the other does not.
o LSAインスタンスの1つはLSエージがMaxAgeに設定されており、もう1つはそうではありません。
o The length field in the LSA header has changed.
o LSAヘッダーの長さフィールドが変更されました。
o The body of the LSA (i.e., anything outside the 20-byte LSA header) has changed. Note that this excludes changes in LS Sequence Number and LS Checksum.
o LSAの本体（つまり、20バイトのLSAヘッダー以外のもの）が変更されました。これには、LSシーケンス番号とLSチェックサムの変更が含まれないことに注意してください。
If the contents are different, the following pieces of the routing table must be recalculated, depending on the new LSA's LS type field:
内容が異なる場合、新しいLSAのLSタイプフィールドに応じて、ルーティングテーブルの次の部分を再計算する必要があります。
Router-LSAs and network-LSAs The entire routing table must be recalculated, starting with the shortest path calculations for each area (not just the area whose link-state database has changed). The reason that the shortest path calculation cannot be restricted to the single changed area has to do with the fact that AS boundary routers may belong to multiple areas. A change in the area currently providing the best route may force the router to use an intra-area route provided by a different area.[19]
ルーターLSAとネットワークLSAルーティングテーブル全体を再計算する必要があります。リンク状態データベースが変更されたエリアだけでなく、各エリアの最短パス計算から始めます。最短経路の計算を単一の変更されたエリアに制限できない理由は、AS境界ルーターが複数のエリアに属している可能性があるという事実に関係しています。現在最適なルートを提供しているエリアが変更されると、ルーターが別のエリアによって提供されるエリア内ルートを使用するように強制される場合があります。
Summary-LSAs The best route to the destination described by the summary-LSA must be recalculated (see Section 16.5). If this destination is an AS boundary router, it may also be necessary to re-examine all the AS-external-LSAs.
サマリーLSAサマリーLSAで記述された宛先への最適なルートを再計算する必要があります（セクション16.5を参照）。この宛先がAS境界ルーターである場合は、すべてのAS外部LSAを再調査する必要がある場合もあります。
AS-external-LSAs The best route to the destination described by the AS-external-LSA must be recalculated (see Section 16.6).
AS-external-LSA AS-external-LSAによって記述された宛先への最適なルートを再計算する必要があります（セクション16.6を参照）。
Also, any old instance of the LSA must be removed from the database when the new LSA is installed. This old instance must also be removed from all neighbors' Link state retransmission lists (see Section 10).
また、新しいLSAをインストールするときに、LSAの古いインスタンスをデータベースから削除する必要があります。この古いインスタンスは、すべてのネイバーのリンク状態再送信リストからも削除する必要があります（セクション10を参照）。
13.3. Next step in the flooding procedure
13.3. フラッディング手順の次のステップ
When a new (and more recent) LSA has been received, it must be flooded out some set of the router's interfaces. This section describes the second part of flooding procedure (the first part being the processing that occurred in Section 13), namely, selecting the outgoing interfaces and adding the LSA to the appropriate neighbors' Link state retransmission lists. Also included in this part of the flooding procedure is the maintenance of the neighbors' Link state request lists.
新しい（そしてより最近の）LSAが受信されると、ルーターのインターフェースのいくつかのセットをフラッディングする必要があります。このセクションでは、フラッディング手順の2番目の部分（セクション13で発生した処理）について説明します。つまり、発信インターフェイスを選択し、LSAを適切なネイバーのリンク状態再送信リストに追加します。フラッディング手順のこの部分には、ネイバーのリンク状態要求リストのメンテナンスも含まれています。
This section is equally applicable to the flooding of an LSA that the router itself has just originated (see Section 12.4). For these LSAs, this section provides the entirety of the flooding procedure (i.e., the processing of Section 13 is not performed, since, for example, the LSA has not been received from a neighbor and therefore does not need to be acknowledged).
このセクションは、ルータ自体が発信したLSAのフラッディングにも同様に適用されます（セクション12.4を参照）。これらのLSAの場合、このセクションはフラッディング手順全体を提供します（つまり、LSAはネイバーから受信されていないため、確認する必要がないため、セクション13の処理は実行されません）。
Depending upon the LSA's LS type, the LSA can be flooded out only certain interfaces. These interfaces, defined by the following, are called the eligible interfaces:
LSAのLSタイプに応じて、LSAは特定のインターフェイスのみにフラッディングできます。以下で定義されるこれらのインターフェースは、適格インターフェースと呼ばれます。
AS-external-LSAs (LS Type = 5) AS-external-LSAs are flooded throughout the entire AS, with the exception of stub areas (see Section 3.6). The eligible interfaces are all the router's interfaces, excluding virtual links and those interfaces attaching to stub areas.
AS-external-LSA（LS Type = 5）AS-external-LSAは、スタブエリアを除いて、AS全体にフラッディングされます（セクション3.6を参照）。適格なインターフェースは、仮想リンクとスタブエリアに接続しているインターフェースを除く、すべてのルーターのインターフェースです。
All other LS types All other types are specific to a single area (Area A). The eligible interfaces are all those interfaces attaching to the Area A. If Area A is the backbone, this includes all the virtual links.
他のすべてのLSタイプ他のすべてのタイプは、単一のエリア（エリアA）に固有です。適格なインターフェースは、エリアAに接続しているすべてのインターフェースです。エリアAがバックボーンである場合、これにはすべての仮想リンクが含まれます。
Link state databases must remain synchronized over all adjacencies associated with the above eligible interfaces. This is accomplished by executing the following steps on each eligible interface. It should be noted that this procedure may decide not to flood an LSA out a particular interface, if there is a high probability that the attached neighbors have already received the LSA. However, in these cases the flooding procedure must be absolutely sure that the neighbors eventually do receive the LSA, so the LSA is still added to each adjacency's Link state retransmission list. For each eligible interface:
リンク状態データベースは、上記の適格なインターフェースに関連付けられたすべての隣接で同期を維持する必要があります。これは、適格な各インターフェースで以下のステップを実行することによって実現されます。接続されたネイバーがすでにLSAを受信している可能性が高い場合、この手順では、特定のインターフェイスからLSAをフラッディングしないように決定する場合があることに注意してください。ただし、これらの場合、フラッディング手順では、ネイバーが最終的にLSAを確実に受信するようにする必要があるため、LSAは各隣接のリンク状態再送信リストに追加されます。適格なインターフェースごとに：
(1) Each of the neighbors attached to this interface are examined, to determine whether they must receive the new LSA. The following steps are executed for each neighbor:
（1）このインターフェイスに接続されている各ネイバーが検査され、新しいLSAを受信する必要があるかどうかが判断されます。次の手順は、各ネイバーに対して実行されます。
(a) If the neighbor is in a lesser state than Exchange, it does not participate in flooding, and the next neighbor should be examined.
（a）ネイバーがExchangeよりも状態が悪い場合は、フラッディングに参加していないため、次のネイバーを調べる必要があります。
(b) Else, if the adjacency is not yet full (neighbor state is Exchange or Loading), examine the Link state request list associated with this adjacency. If there is an instance of the new LSA on the list, it indicates that the neighboring router has an instance of the LSA already. Compare the new LSA to the neighbor's copy:
（b）それ以外の場合、隣接関係がまだいっぱいでない（隣接状態がExchangeまたはLoading）場合は、この隣接関係に関連付けられているリンク状態要求リストを調べます。リストに新しいLSAのインスタンスがある場合、それは隣接ルーターが既にLSAのインスタンスを持っていることを示しています。新しいLSAをネイバーのコピーと比較します。
o If the new LSA is less recent, then examine the next neighbor.
o 新しいLSAの方が新しい場合は、次のネイバーを調べます。
o If the two copies are the same instance, then delete the LSA from the Link state request list, and examine the next neighbor.[20]
o 2つのコピーが同じインスタンスである場合は、リンク状態要求リストからLSAを削除し、次のネイバーを調べます。[20]
o Else, the new LSA is more recent. Delete the LSA from the Link state request list.
o そうでなければ、新しいLSAはより新しいものです。リンク状態要求リストからLSAを削除します。
(c) If the new LSA was received from this neighbor, examine the next neighbor.
（c）このネイバーから新しいLSAを受信した場合は、次のネイバーを調べます。
(d) At this point we are not positive that the neighbor has an up-to-date instance of this new LSA. Add the new LSA to the Link state retransmission list for the adjacency. This ensures that the flooding procedure is reliable; the LSA will be retransmitted at intervals until an acknowledgment is seen from the neighbor.
（d）この時点では、ネイバーがこの新しいLSAの最新のインスタンスを持っているとは言えません。新しいLSAを隣接のリンク状態再送信リストに追加します。これにより、フラッディング手順の信頼性が保証されます。 LSAは、確認応答がネイバーから確認されるまで、一定の間隔で再送信されます。
(2) The router must now decide whether to flood the new LSA out this interface. If in the previous step, the LSA was NOT added to any of the Link state retransmission lists, there is no need to flood the LSA out the interface and the next interface should be examined.
（2）ここで、ルーターは新しいLSAをこのインターフェースからあふれ出すかどうかを決定する必要があります。前の手順で、LSAがリンク状態再送信リストのいずれにも追加されなかった場合は、LSAをインターフェースからあふれさせる必要はなく、次のインターフェースを調べる必要があります。
(3) If the new LSA was received on this interface, and it was received from either the Designated Router or the Backup Designated Router, chances are that all the neighbors have received the LSA already. Therefore, examine the next interface.
（3）新しいLSAがこのインターフェイスで受信され、指定ルーターまたはバックアップ指定ルーターから受信された場合、すべてのネイバーがすでにLSAを受信している可能性があります。したがって、次のインターフェイスを調べます。
(4) If the new LSA was received on this interface, and the interface state is Backup (i.e., the router itself is the Backup Designated Router), examine the next interface. The Designated Router will do the flooding on this interface. However, if the Designated Router fails the router (i.e., the Backup Designated Router) will end up retransmitting the updates.
（4）このインターフェイスで新しいLSAが受信され、インターフェイスの状態がバックアップである（つまり、ルーター自体がバックアップ指定ルーターである）場合は、次のインターフェイスを調べます。指定ルーターは、このインターフェースでフラッディングを行います。ただし、指定ルーターに障害が発生すると、ルーター（つまり、バックアップ指定ルーター）は更新を再送信します。
(5) If this step is reached, the LSA must be flooded out the interface. Send a Link State Update packet (including the new LSA as contents) out the interface. The LSA's LS age must be incremented by InfTransDelay (which must be > 0) when it is copied into the outgoing Link State Update packet (until the LS age field reaches the maximum value of MaxAge).
（5）このステップに達した場合、LSAはインターフェースからフラッディングする必要があります。リンク状態更新パケット（新しいLSAをコンテンツとして含む）をインターフェイスから送信します。 LSAのLSエージは、（LSエージフィールドがMaxAgeの最大値に達するまで）発信リンク状態更新パケットにコピーされるときに、InfTransDelay（> 0でなければなりません）だけインクリメントする必要があります。
On broadcast networks, the Link State Update packets are multicast. The destination IP address specified for the Link State Update Packet depends on the state of the interface. If the interface state is DR or Backup, the address AllSPFRouters should be used. Otherwise, the address AllDRouters should be used.
ブロードキャストネットワークでは、リンク状態更新パケットはマルチキャストです。リンク状態更新パケットに指定される宛先IPアドレスは、インターフェースの状態によって異なります。インターフェイスの状態がDRまたはバックアップの場合は、アドレスAllSPFRoutersを使用する必要があります。それ以外の場合は、アドレスAllDRoutersを使用する必要があります。
On non-broadcast networks, separate Link State Update packets must be sent, as unicasts, to each adjacent neighbor (i.e., those in state Exchange or greater). The destination IP addresses for these packets are the neighbors' IP addresses.
非ブロードキャストネットワークでは、個別のリンク状態更新パケットをユニキャストとして、隣接する各ネイバー（Exchange状態以上のもの）に送信する必要があります。これらのパケットの宛先IPアドレスは、ネイバーのIPアドレスです。
13.4. Receiving self-originated LSAs
13.4. 自己発信LSAの受信
It is a common occurrence for a router to receive self-originated LSAs via the flooding procedure. A self-originated LSA is detected when either 1) the LSA's Advertising Router is equal to the router's own Router ID or 2) the LSA is a network-LSA and its Link State ID is equal to one of the router's own IP interface addresses.
ルータがフラッディング手順を介して自己発信LSAを受信することはよくあることです。自己発信LSAは、1）LSAのアドバタイジングルーターがルーター自身のルーターIDと等しいか、2）LSAがネットワークLSAであり、そのリンク状態IDがルーター自身のIPインターフェイスアドレスの1つと等しい場合に検出されます。
However, if the received self-originated LSA is newer than the last instance that the router actually originated, the router must take special action. The reception of such an LSA indicates that there are LSAs in the routing domain that were originated by the router before the last time it was restarted. In most cases, the router must then advance the LSA's LS sequence number one past the received LS sequence number, and originate a new instance of the LSA.
ただし、受信した自己発信LSAが、ルーターが実際に発信した最後のインスタンスより新しい場合、ルーターは特別なアクションを実行する必要があります。このようなLSAの受信は、最後に再起動される前にルーターによって発信されたLSAがルーティングドメインにあることを示します。ほとんどの場合、ルーターは次に、LSAのLSシーケンス番号を受信したLSシーケンス番号を1つ進め、LSAの新しいインスタンスを生成する必要があります。
It may be the case the router no longer wishes to originate the received LSA. Possible examples include: 1) the LSA is a summary-LSA or AS-external-LSA and the router no longer has an (advertisable) route to the destination, 2) the LSA is a network-LSA but the router is no longer Designated Router for the network or 3) the LSA is a network-LSA whose Link State ID is one of the router's own IP interface addresses but whose Advertising Router is not equal to the router's own Router ID (this latter case should be rare, and it indicates that the router's Router ID has changed since originating the LSA). In all these cases, instead of updating the LSA, the LSA should be flushed from the routing domain by incrementing the received LSA's LS age to MaxAge and reflooding (see Section 14.1).
これは、ルータが受信したLSAを発信することをもはや望まない場合である可能性があります。可能性のある例は次のとおりです。1）LSAはサマリーLSAまたはAS外部LSAであり、ルーターには宛先への（広告可能な）ルートがありません。2）LSAはネットワークLSAですが、ルーターは指定されていませんネットワークのルーターまたは3）LSAは、リンク状態IDがルーター自身のIPインターフェイスアドレスの1つであるが、アドバタイジングルーターがルーター自身のルーターIDと等しくないネットワークLSAです（後者のケースはまれであるはずです。ルーターのルーターIDがLSAの作成後に変更されたことを示します）。これらすべてのケースで、LSAを更新する代わりに、LSAをルーティングドメインからフラッシュして、受信したLSAのLSエージをMaxAgeにインクリメントし、再フラッディングする必要があります（セクション14.1を参照）。
13.5. Sending Link State Acknowledgment packets
13.5. リンク状態確認パケットの送信
Each newly received LSA must be acknowledged. This is usually done by sending Link State Acknowledgment packets. However, acknowledgments can also be accomplished implicitly by sending Link State Update packets (see step 7a of Section 13).
新しく受信したLSAはそれぞれ確認する必要があります。これは通常、リンク状態確認パケットを送信することで行われます。ただし、確認応答は、リンク状態更新パケットを送信することによって暗黙的に実行することもできます（セクション13のステップ7aを参照）。
Many acknowledgments may be grouped together into a single Link State Acknowledgment packet. Such a packet is sent back out the interface which received the LSAs. The packet can be sent in one of two ways: delayed and sent on an interval timer, or sent directly to a particular neighbor. The particular acknowledgment strategy used depends on the circumstances surrounding the receipt of the LSA.
多くの確認応答は、単一のリンク状態確認応答パケットにまとめることができます。このようなパケットは、LSAを受信したインターフェイスに送り返されます。パケットは、遅延してインターバルタイマーで送信するか、特定のネイバーに直接送信するという2つの方法のいずれかで送信できます。使用される特定の確認応答戦略は、LSAの受信を取り巻く状況によって異なります。
Sending delayed acknowledgments accomplishes several things: 1) it facilitates the packaging of multiple acknowledgments in a single Link State Acknowledgment packet, 2) it enables a single Link State Acknowledgment packet to indicate acknowledgments to several neighbors at once (through multicasting) and 3) it randomizes the Link State Acknowledgment packets sent by the various routers attached to a common network. The fixed interval between a router's delayed transmissions must be short (less than RxmtInterval) or needless retransmissions will ensue.
遅延確認応答を送信すると、いくつかのことを実行できます。1）単一のリンク状態確認応答パケットへの複数の確認応答のパッケージ化が容易になります。2）単一のリンク状態確認応答パケットが、複数のネイバーへの確認応答を同時に（マルチキャストを介して）表示できるようになります。共通ネットワークに接続されたさまざまなルーターによって送信されたリンク状態確認パケットをランダム化します。ルーターの遅延送信の固定間隔は短く（RxmtInterval未満）する必要があります。そうしないと、不必要な再送信が発生します。
Direct acknowledgments are sent directly to a particular neighbor in response to the receipt of duplicate LSAs. Direct acknowledgments are sent immediately when the duplicate is received. On multi-access networks, these acknowledgments are sent directly to the neighbor's IP address.
直接の確認応答は、重複したLSAの受信に応答して、特定のネイバーに直接送信されます。直接受信確認は、重複を受信するとすぐに送信されます。マルチアクセスネットワークでは、これらの確認応答はネイバーのIPアドレスに直接送信されます。
The precise procedure for sending Link State Acknowledgment packets is described in Table 19. The circumstances surrounding the receipt of the LSA are listed in the left column. The acknowledgment action then taken is listed in one of the two right columns. This action depends on the state of the concerned interface; interfaces in state Backup behave differently from interfaces in all other states. Delayed acknowledgments must be delivered to all adjacent routers associated with the interface. On broadcast networks, this is accomplished by sending the delayed Link State Acknowledgment packets as multicasts. The Destination IP address used depends
リンク状態確認パケットを送信するための正確な手順を表19に示します。LSAの受信を取り巻く状況は、左の列にリストされています。次に実行される確認応答アクションは、右側の2つの列のいずれかにリストされます。このアクションは、関係するインターフェースの状態に依存します。バックアップ状態のインターフェースは、他のすべての状態のインターフェースとは異なる動作をします。遅延確認応答は、インターフェイスに関連付けられているすべての隣接ルーターに配信する必要があります。ブロードキャストネットワークでは、これはマルチキャストとして遅延リンク状態確認パケットを送信することで実現されます。使用される宛先IPアドレスは、
Action taken in state
Circumstances Backup All other states
_________________________________________________________________
LSA has No acknowledgment No acknowledgment
been flooded back sent. sent.
out receiving in-
terface (see Sec-
tion 13, step 5b).
_________________________________________________________________
LSA is Delayed acknowledg- Delayed ack-
more recent than ment sent if adver- nowledgment sent.
database copy, but tisement received
was not flooded from Designated
back out receiving Router, otherwise
interface do nothing
_________________________________________________________________
LSA is a Delayed acknowledg- No acknowledgment
duplicate, and was ment sent if adver- sent.
treated as an im- tisement received
plied acknowledg- from Designated
ment (see Section Router, otherwise
13, step 7a). do nothing
_________________________________________________________________
LSA is a Direct acknowledg- Direct acknowledg-
duplicate, and was ment sent. ment sent.
not treated as an
implied ack-
nowledgment.
_________________________________________________________________
LSA's LS Direct acknowledg- Direct acknowledg-
age is equal to ment sent. ment sent.
MaxAge, and there is
no current instance
of the LSA
in the link state
database, and none
of router's neighbors
are in states Exchange or Loading (see
Section 13, step 4).
Table 19: Sending link state acknowledgements.
表19：リンク状態の確認の送信。
on the state of the interface. If the interface state is DR or Backup, the destination AllSPFRouters is used. In all other states, the destination AllDRouters is used. On non-broadcast networks, delayed Link State Acknowledgment packets must be unicast separately over each adjacency (i.e., neighbor whose state is >= Exchange).
インターフェースの状態。インターフェイスの状態がDRまたはバックアップの場合、宛先AllSPFRoutersが使用されます。他のすべての状態では、宛先AllDRoutersが使用されます。非ブロードキャストネットワークでは、遅延したリンク状態確認パケットは、各隣接（つまり、状態が> =交換であるネイバー）上で個別にユニキャストする必要があります。
The reasoning behind sending the above packets as multicasts is best explained by an example. Consider the network configuration depicted in Figure 15. Suppose RT4 has been elected as Designated Router, and RT3 as Backup Designated Router for the network N3. When Router RT4 floods a new LSA to Network N3, it is received by routers RT1, RT2, and RT3. These routers will not flood the LSA back onto net N3, but they still must ensure that their link-state databases remain synchronized with their adjacent neighbors. So RT1, RT2, and RT4 are waiting to see an acknowledgment from RT3. Likewise, RT4 and RT3 are both waiting to see acknowledgments from RT1 and RT2. This is best achieved by sending the acknowledgments as multicasts.
上記のパケットをマルチキャストとして送信する理由は、例で最もよく説明されています。図15に示すネットワーク構成を考えてみます。ネットワークN3のRT4が指定ルーターとして、RT3がバックアップ指定ルーターとして選択されているとします。ルータRT4が新しいLSAをネットワークN3にフラッディングすると、それはルータRT1、RT2、およびRT3によって受信されます。これらのルーターはLSAをネットN3にフラッディングしませんが、リンク状態データベースが隣接するネイバーと同期されたままであることを確認する必要があります。したがって、RT1、RT2、およびRT4は、RT3からの確認応答を待機しています。同様に、RT4とRT3はどちらも、RT1とRT2からの確認応答を待機しています。これは、確認応答をマルチキャストとして送信することで最もよく達成されます。
The reason that the acknowledgment logic for Backup DRs is slightly different is because they perform differently during the flooding of LSAs (see Section 13.3, step 4).
バックアップDRの確認応答ロジックがわずかに異なるのは、LSAのフラッディング中に動作が異なるためです（セクション13.3、ステップ4を参照）。
13.6. Retransmitting LSAs
13.6. LSAの再送信
LSAs flooded out an adjacency are placed on the adjacency's Link state retransmission list. In order to ensure that flooding is reliable, these LSAs are retransmitted until they are acknowledged. The length of time between retransmissions is a configurable per-interface value, RxmtInterval. If this is set too low for an interface, needless retransmissions will ensue. If the value is set too high, the speed of the flooding, in the face of lost packets, may be affected.
隣接から溢れたLSAは、隣接のリンク状態再送信リストに配置されます。フラッディングの信頼性を確保するために、これらのLSAは確認されるまで再送信されます。再送信間の時間の長さは、インターフェイスごとに構成可能な値、RxmtIntervalです。これがインターフェースに対して低すぎると、不必要な再送信が発生します。値の設定が高すぎると、パケットが失われた場合のフラッディングの速度が影響を受ける可能性があります。
Several retransmitted LSAs may fit into a single Link State Update packet. When LSAs are to be retransmitted, only the number fitting in a single Link State Update packet should be sent. Another packet of retransmissions can be sent whenever some of the LSAs are acknowledged, or on the next firing of the retransmission timer.
いくつかの再送信されたLSAが1つのリンク状態更新パケットに収まる場合があります。 LSAを再送信する場合は、1つのリンク状態更新パケットに収まる数だけを送信する必要があります。 LSAの一部が確認されるたびに、または再送信タイマーの次の起動時に、再送信の別のパケットを送信できます。
Link State Update Packets carrying retransmissions are always sent directly to the neighbor. On multi-access networks, this means that retransmissions are sent directly to the neighbor's IP address. Each LSA's LS age must be incremented by InfTransDelay (which must be > 0) when it is copied into the outgoing Link State Update packet (until the LS age field reaches the maximum value of MaxAge).
再送信を伝送するリンク状態更新パケットは、常にネイバーに直接送信されます。マルチアクセスネットワークでは、これは再送信がネイバーのIPアドレスに直接送信されることを意味します。各LSAのLSエージは、（LSエージフィールドがMaxAgeの最大値に達するまで）送信リンク状態更新パケットにコピーされるときに、InfTransDelay（> 0でなければなりません）だけインクリメントする必要があります。
If an adjacent router goes down, retransmissions may occur until the adjacency is destroyed by OSPF's Hello Protocol. When the adjacency is destroyed, the Link state retransmission list is cleared.
隣接ルータがダウンすると、隣接関係がOSPFのHelloプロトコルによって破壊されるまで、再送信が発生する可能性があります。隣接関係が破棄されると、リンク状態再送信リストがクリアされます。
13.7. Receiving link state acknowledgments
13.7. リンク状態の確認応答を受信する
Many consistency checks have been made on a received Link State Acknowledgment packet before it is handed to the flooding procedure. In particular, it has been associated with a particular neighbor. If this neighbor is in a lesser state than Exchange, the Link State Acknowledgment packet is discarded.
受信したリンク状態確認パケットがフラッディング手順に渡される前に、多くの整合性チェックが行われました。特に、特定のネイバーに関連付けられています。このネイバーの状態がExchangeより低い場合、リンク状態確認パケットは破棄されます。
Otherwise, for each acknowledgment in the Link State Acknowledgment packet, the following steps are performed:
それ以外の場合は、リンク状態確認応答パケット内の確認応答ごとに、次の手順が実行されます。
o Does the LSA acknowledged have an instance on the Link state retransmission list for the neighbor? If not, examine the next acknowledgment. Otherwise:
o 確認されたLSAには、ネイバーのリンク状態再送信リストにインスタンスがありますか？そうでない場合は、次の確認を調べます。さもないと：
o If the acknowledgment is for the same instance that is contained on the list, remove the item from the list and examine the next acknowledgment. Otherwise:
o 確認がリストに含まれているのと同じインスタンスに対するものである場合は、リストから項目を削除して、次の確認を調べます。さもないと：
o Log the questionable acknowledgment, and examine the next one.
o 疑わしい確認を記録し、次の確認を調べます。
Each LSA has an LS age field. The LS age is expressed in seconds. An LSA's LS age field is incremented while it is contained in a router's database. Also, when copied into a Link State Update Packet for flooding out a particular interface, the LSA's LS age is incremented by InfTransDelay.
各LSAにはLSエージフィールドがあります。 LS経過時間は秒単位で表されます。 LSAのLSエージフィールドは、ルータのデータベースに含まれている間、増加します。また、特定のインターフェイスをフラッディングするためにリンク状態更新パケットにコピーされると、LSAのLSエージはInfTransDelayによって増分されます。
An LSA's LS age is never incremented past the value MaxAge. LSAs having age MaxAge are not used in the routing table calculation. As a router ages its link state database, an LSA's LS age may reach MaxAge.[21] At this time, the router must attempt to flush the LSA from the routing domain. This is done simply by reflooding the MaxAge LSA just as if it was a newly originated LSA (see Section 13.3).
LSAのLS経過時間は、MaxAgeの値を超えて増分されることはありません。 MaxAgeの経過時間を持つLSAは、ルーティングテーブルの計算に使用されません。ルーターがリンク状態データベースを古くすると、LSAのLS古さはMaxAgeに達する可能性があります。[21]このとき、ルーターはルーティングドメインからLSAをフラッシュする必要があります。これは、MaxAge LSAをあたかも新たに生成されたLSAであるかのように再フラッディングすることによって行われます（セクション13.3を参照）。
When creating a Database summary list for a newly forming adjacency, any MaxAge LSAs present in the link state database are added to the neighbor's Link state retransmission list instead of the neighbor's Database summary list. See Section 10.3 for more details.
新しく形成する隣接のデータベースサマリーリストを作成すると、リンク状態データベースに存在するすべてのMaxAge LSAが、ネイバーのデータベースサマリーリストではなく、ネイバーのリンク状態再送信リストに追加されます。詳細については、セクション10.3を参照してください。
A MaxAge LSA must be removed immediately from the router's link state database as soon as both a) it is no longer contained on any neighbor Link state retransmission lists and b) none of the router's neighbors are in states Exchange or Loading.
MaxAge LSAは、a）ネイバーリンクステート再送信リストに含まれなくなった場合、およびb）ルーターのネイバーがExchangeまたはLoadingの状態になっていない場合は、すぐにルーターのリンクステートデータベースから削除する必要があります。
When, in the process of aging the link state database, an LSA's LS age hits a multiple of CheckAge, its LS checksum should be verified. If the LS checksum is incorrect, a program or memory error has been detected, and at the very least the router itself should be restarted.
リンクステートデータベースのエージングプロセスで、LSAのLSエージがCheckAgeの倍数に達した場合、そのLSチェックサムを確認する必要があります。 LSチェックサムが正しくない場合は、プログラムまたはメモリのエラーが検出されています。少なくともルーター自体を再起動する必要があります。
14.1. Premature aging of LSAs
14.1. LSAの早期老化
An LSA can be flushed from the routing domain by setting its LS age to MaxAge, while leaving its LS sequence number alone, and then reflooding the LSA. This procedure follows the same course as flushing an LSA whose LS age has naturally reached the value MaxAge (see Section 14). In particular, the MaxAge LSA is removed from the router's link state database as soon as a) it is no longer contained on any neighbor Link state retransmission lists and b) none of the router's neighbors are in states Exchange or Loading. We call the setting of an LSA's LS age to MaxAge "premature aging".
LSシーケンス番号をそのままにして、LSAをMaxAgeに設定し、LSAを再フラッディングすることにより、LSAをルーティングドメインからフラッシュできます。この手順は、LSエージがMaxAgeの値に自然に達したLSAをフラッシュするのと同じコースに従います（セクション14を参照）。特に、MaxAge LSAは、a）ネイバーのリンクステート再送信リストに含まれなくなって、b）ルーターのネイバーがExchangeまたはLoadingの状態にならないとすぐに、ルーターのリンクステートデータベースから削除されます。 LSAのLSエージをMaxAgeに設定することを「早期エージング」と呼びます。
Premature aging is used when it is time for a self-originated LSA's sequence number field to wrap. At this point, the current LSA instance (having LS sequence number MaxSequenceNumber) must be prematurely aged and flushed from the routing domain before a new instance with sequence number equal to InitialSequenceNumber can be originated. See Section 12.1.6 for more information.
自己エージングLSAのシーケンス番号フィールドがラップする時期になったら、早期エージングが使用されます。この時点で、現在のLSAインスタンス（LSシーケンス番号MaxSequenceNumberを持つ）を早期にエージングし、シーケンス番号がInitialSequenceNumberと等しい新しいインスタンスを生成する前に、ルーティングドメインからフラッシュする必要があります。詳細については、セクション12.1.6を参照してください。
Premature aging can also be used when, for example, one of the router's previously advertised external routes is no longer reachable. In this circumstance, the router can flush its AS-external-LSA from the routing domain via premature aging. This procedure is preferable to the alternative, which is to originate a new LSA for the destination specifying a metric of LSInfinity. Premature aging is also be used when unexpectedly receiving self-originated LSAs during the flooding procedure (see Section 13.4).
たとえば、ルーターの以前にアドバタイズされた外部ルートの1つに到達できなくなった場合にも、早期エージングを使用できます。この状況では、ルーターは、早期エージングによってルーティングドメインからAS外部LSAをフラッシュできます。この手順は、LSInfinityのメトリックを指定する宛先の新しいLSAを発信するという代替手段よりも望ましい方法です。早期エージングは、フラッディング手順中に予期せずに自己発信LSAを受信した場合にも使用されます（セクション13.4を参照）。
A router may only prematurely age its own self-originated LSAs. The router may not prematurely age LSAs that have been originated by other routers. An LSA is considered self-originated when either 1) the LSA's Advertising Router is equal to the router's own Router ID or 2) the LSA is a network-LSA and its Link State ID is equal to one of the router's own IP interface addresses.
ルーターは、自分自身で作成したLSAを早期にエージングするだけです。ルーターは、他のルーターから発信されたLSAを早期にエージングしない場合があります。 LSAは、1）LSAのアドバタイジングルーターがルーター自身のルーターIDと等しいか、2）LSAがネットワークLSAであり、そのリンク状態IDがルーター自身のIPインターフェイスアドレスの1つと等しい場合、自己発信と見なされます。
The single backbone area (Area ID = 0.0.0.0) cannot be disconnected, or some areas of the Autonomous System will become unreachable. To establish/maintain connectivity of the backbone, virtual links can be configured through non-backbone areas. Virtual links serve to connect physically separate components of the backbone. The two endpoints of a virtual link are area border routers. The virtual link must be configured in both routers. The configuration information in each router consists of the other virtual endpoint (the other area border router), and the non-backbone area the two routers have in common (called the Transit area). Virtual links cannot be configured through stub areas (see Section 3.6).
単一のバックボーンエリア（エリアID = 0.0.0.0）を切断できないか、自律システムの一部のエリアに到達できなくなります。バックボーンの接続を確立/維持するために、非バックボーンエリアを介して仮想リンクを構成できます。仮想リンクは、バックボーンの物理的に分離されたコンポーネントを接続するのに役立ちます。仮想リンクの2つのエンドポイントはエリア境界ルーターです。仮想リンクは、両方のルーターで構成する必要があります。各ルーターの構成情報は、他の仮想エンドポイント（他のエリア境界ルーター）と、2つのルーターが共通して持つ非バックボーンエリア（トランジットエリアと呼ばれます）で構成されています。仮想リンクはスタブエリアを介して構成できません（セクション3.6を参照）。
The virtual link is treated as if it were an unnumbered point-to-point network belonging to the backbone and joining the two area border routers. An attempt is made to establish an adjacency over the virtual link. When this adjacency is established, the virtual link will be included in backbone router-LSAs, and OSPF packets pertaining to the backbone area will flow over the adjacency. Such an adjacency has been referred to in this document as a "virtual adjacency".
仮想リンクは、バックボーンに属し、2つのエリア境界ルーターに参加する、番号付けされていないポイントツーポイントネットワークであるかのように扱われます。仮想リンクを介して隣接関係を確立する試みが行われます。この隣接関係が確立されると、仮想リンクがバックボーンルーターLSAに含まれ、バックボーンエリアに関連するOSPFパケットが隣接関係を流れます。このような隣接関係は、このドキュメントでは「仮想隣接関係」と呼ばれています。
In each endpoint router, the cost and viability of the virtual link is discovered by examining the routing table entry for the other endpoint router. (The entry's associated area must be the configured Transit area). This is called the virtual link's corresponding routing table entry. The InterfaceUp event occurs for a virtual link when its corresponding routing table entry becomes reachable. Conversely, the InterfaceDown event occurs when its routing table entry becomes unreachable. In other words, the virtual link's viability is determined by the existence of an intra-area path, through the Transit area, between the two endpoints. Note that a virtual link whose underlying path has cost greater than hexadecimal 0xffff (the maximum size of an interface cost in a router-LSA) should be considered inoperational (i.e., treated the same as if the path did not exist).
各エンドポイントルーターでは、仮想リンクのコストと実行可能性は、他のエンドポイントルーターのルーティングテーブルエントリを調べることによって発見されます。 （エントリの関連エリアは、設定された通過エリアでなければなりません）。これは、仮想リンクの対応するルーティングテーブルエントリと呼ばれます。 InterfaceUpイベントは、対応するルーティングテーブルエントリが到達可能になったときに、仮想リンクに対して発生します。逆に、InterfaceDownイベントは、ルーティングテーブルのエントリが到達不能になったときに発生します。言い換えると、仮想リンクの実行可能性は、2つのエンドポイント間のトランジットエリアを通るエリア内パスの存在によって決まります。基になるパスのコストが16進数の0xffff（ルーターLSAのインターフェイスコストの最大サイズ）より大きい仮想リンクは、動作していないと見なす必要があります（つまり、パスが存在しない場合と同じように処理します）。
The other details concerning virtual links are as follows:
仮想リンクに関するその他の詳細は次のとおりです。
o AS-external-LSAs are NEVER flooded over virtual adjacencies. This would be duplication of effort, since the same AS- external-LSAs are already flooded throughout the virtual link's Transit area. For this same reason, AS-external-LSAs are not summarized over virtual adjacencies during the Database Exchange process.
o AS外部LSAが仮想隣接にフラッディングされることはありません。同じAS外部LSAが仮想リンクのトランジットエリア全体にすでにあふれているため、これは作業の重複になります。これと同じ理由で、AS-external-LSAは、データベース交換プロセス中の仮想隣接では要約されません。
o The cost of a virtual link is NOT configured. It is defined to be the cost of the intra-area path between the two defining area border routers. This cost appears in the virtual link's corresponding routing table entry. When the cost of a virtual link changes, a new router-LSA should be originated for the backbone area.
o 仮想リンクのコストは設定されていません。これは、2つの定義エリア境界ルーター間のエリア内パスのコストと定義されています。このコストは、仮想リンクの対応するルーティングテーブルエントリに表示されます。仮想リンクのコストが変化した場合、新しいルーターLSAがバックボーンエリア用に作成されます。
o Just as the virtual link's cost and viability are determined by the routing table build process (through construction of the routing table entry for the other endpoint), so are the IP interface address for the virtual interface and the virtual neighbor's IP address. These are used when sending OSPF protocol packets over the virtual link. Note that when one (or both) of the virtual link endpoints connect to the Transit area via an unnumbered point-to-point link, it may be impossible to calculate either the virtual interface's IP address and/or the virtual neighbor's IP address, thereby causing the virtual link to fail.
o 仮想リンクのコストと実行可能性がルーティングテーブルビルドプロセス（他のエンドポイントのルーティングテーブルエントリの構築を介して）によって決定されるのと同様に、仮想インターフェイスのIPインターフェイスアドレスと仮想ネイバーのIPアドレスも決定されます。これらは、仮想リンクを介してOSPFプロトコルパケットを送信するときに使用されます。仮想リンクエンドポイントの1つ（または両方）が番号なしポイントツーポイントリンクを介してトランジットエリアに接続する場合、仮想インターフェイスのIPアドレスまたは仮想ネイバーのIPアドレス、あるいはその両方を計算できない場合があることに注意してください。仮想リンクが失敗します。
o In each endpoint's router-LSA for the backbone, the virtual link is represented as a Type 4 link whose Link ID is set to the virtual neighbor's OSPF Router ID and whose Link Data is set to the virtual interface's IP address. See Section 12.4.1 for more information.
o バックボーンの各エンドポイントのルーターLSAでは、仮想リンクは、リンクIDが仮想ネイバーのOSPFルーターIDに設定され、リンクデータが仮想インターフェイスのIPアドレスに設定されたタイプ4リンクとして表されます。詳細については、セクション12.4.1を参照してください。
o A non-backbone area can carry transit data traffic (i.e., is considered a "transit area") if and only if it serves as the Transit area for one or more fully adjacent virtual links (see TransitCapability in Sections 6 and 16.1). Such an area requires special treatment when summarizing backbone networks into it (see Section 12.4.3), and during the routing calculation (see Section 16.3).
o 非バックボーンエリアは、1つ以上の完全に隣接する仮想リンクのトランジットエリアとして機能する場合に限り、トランジットデータトラフィックを伝送できます（つまり、「トランジットエリア」と見なされます）（セクション6および16.1のTransitCapabilityを参照）。そのようなエリアは、バックボーンネットワークをそのエリアに集約するとき（セクション12.4.3を参照）、およびルーティングの計算中に（セクション16.3を参照）、特別な処理が必要です。
o The time between link state retransmissions, RxmtInterval, is configured for a virtual link. This should be well over the expected round-trip delay between the two routers. This may be hard to estimate for a virtual link; it is better to err on the side of making it too large.
o リンク状態の再送信間の時間RxmtIntervalは、仮想リンク用に構成されます。これは、2つのルーター間で予想される往復遅延を十分に超えているはずです。これは、仮想リンクに対して推定するのが難しい場合があります。大きくしすぎると、エラーが発生しやすくなります。
This section details the OSPF routing table calculation. Using its attached areas' link state databases as input, a router runs the following algorithm, building its routing table step by step. At each step, the router must access individual pieces of the link state databases (e.g., a router-LSA originated by a certain router). This access is performed by the lookup function discussed in Section 12.2. The lookup process may return an LSA whose LS age is equal to MaxAge. Such an LSA should not be used in the routing table calculation, and is treated just as if the lookup process had failed.
このセクションでは、OSPFルーティングテーブルの計算について詳しく説明します。接続されたエリアのリンク状態データベースを入力として使用して、ルーターは次のアルゴリズムを実行し、ルーティングテーブルを段階的に構築します。各ステップで、ルーターはリンク状態データベースの個々の部分（たとえば、特定のルーターから発信されたルーターLSA）にアクセスする必要があります。このアクセスは、12.2項で説明する検索機能によって実行されます。ルックアッププロセスは、LSエージがMaxAgeと等しいLSAを返す場合があります。このようなLSAはルーティングテーブルの計算に使用するべきではなく、ルックアッププロセスが失敗したかのように扱われます。
The OSPF routing table's organization is explained in Section 11. Two examples of the routing table build process are presented in Sections 11.2 and 11.3. This process can be broken into the following steps:
OSPFルーティングテーブルの構成については、セクション11で説明します。ルーティングテーブル作成プロセスの2つの例を、セクション11.2および11.3に示します。このプロセスは、次のステップに分けることができます。
(1) The present routing table is invalidated. The routing table is built again from scratch. The old routing table is saved so that changes in routing table entries can be identified.
（1）現在のルーティングテーブルが無効になります。ルーティングテーブルは、ゼロから再構築されます。古いルーティングテーブルが保存されるので、ルーティングテーブルエントリの変更を識別できます。
(2) The intra-area routes are calculated by building the shortest-path tree for each attached area. In particular, all routing table entries whose Destination Type is "area border router" are calculated in this step. This step is described in two parts. At first the tree is constructed by only considering those links between routers and transit networks. Then the stub networks are incorporated into the tree. During the area's shortest-path tree calculation, the area's TransitCapability is also calculated for later use in Step 4.
（2）エリア内ルートは、アタッチされたエリアごとに最短経路ツリーを構築することによって計算されます。特に、宛先タイプが「エリア境界ルーター」であるすべてのルーティングテーブルエントリは、この手順で計算されます。このステップは2つのパートで説明されています。最初に、ルータと中継ネットワーク間のリンクのみを考慮してツリーが構築されます。次に、スタブネットワークがツリーに組み込まれます。エリアの最短パスツリーの計算中に、エリアのTransitCapabilityも計算され、後でステップ4で使用されます。
(3) The inter-area routes are calculated, through examination of summary-LSAs. If the router is attached to multiple areas (i.e., it is an area border router), only backbone summary-LSAs are examined.
（3）エリア間ルートは、サマリーLSAの調査を通じて計算されます。ルーターが複数のエリアに接続されている場合（エリアボーダールーターなど）、バックボーンサマリーLSAのみが検査されます。
(4) In area border routers connecting to one or more transit areas (i.e, non-backbone areas whose TransitCapability is found to be TRUE), the transit areas' summary-LSAs are examined to see whether better paths exist using the transit areas than were found in Steps 2-3 above.
（4）1つ以上のトランジットエリア（つまり、TransitCapabilityがTRUEであることが判明した非バックボーンエリア）に接続するエリアボーダールーターでは、トランジットエリアのサマリーLSAが調べられ、トランジットエリアを使用してより良いパスが存在するかどうかが確認されます上記のステップ2〜3で見つかりました。
(5) Routes to external destinations are calculated, through examination of AS-external-LSAs. The locations of the AS boundary routers (which originate the AS-external-LSAs) have been determined in steps 2-4.
（5）AS-external-LSAの調査を通じて、外部宛先へのルートが計算されます。 AS境界ルーター（AS-external-LSAの発信元）の場所は、手順2〜4で決定されています。
Steps 2-5 are explained in further detail below.
ステップ2〜5については、以下で詳しく説明します。
Changes made to routing table entries as a result of these calculations can cause the OSPF protocol to take further actions. For example, a change to an intra-area route will cause an area border router to originate new summary-LSAs (see Section 12.4). See Section 16.7 for a complete list of the OSPF protocol actions resulting from routing table changes.
これらの計算の結果としてルーティングテーブルエントリに加えられた変更により、OSPFプロトコルはさらにアクションを実行する可能性があります。たとえば、エリア内ルートを変更すると、エリア境界ルーターが新しいサマリーLSAを生成します（セクション12.4を参照）。ルーティングテーブルの変更に起因するOSPFプロトコルアクションの完全なリストについては、セクション16.7を参照してください。
16.1. Calculating the shortest-path tree for an area
16.1. エリアの最短経路ツリーの計算
This calculation yields the set of intra-area routes associated with an area (called hereafter Area A). A router calculates the shortest-path tree using itself as the root.[22] The formation of the shortest path tree is done here in two stages. In the first stage, only links between routers and transit networks are considered. Using the Dijkstra algorithm, a tree is formed from this subset of the link state database. In the second stage, leaves are added to the tree by considering the links to stub networks.
この計算により、エリア（以下、エリアAと呼びます）に関連付けられたエリア内ルートのセットが生成されます。ルーターは自身をルートとして使用して最短経路ツリーを計算します。ここでは、最短パスツリーの形成は2つの段階で行われます。最初の段階では、ルーターとトランジットネットワーク間のリンクのみが考慮されます。ダイクストラアルゴリズムを使用して、リンク状態データベースのこのサブセットからツリーが形成されます。 2番目の段階では、スタブネットワークへのリンクを考慮して、葉がツリーに追加されます。
The procedure will be explained using the graph terminology that was introduced in Section 2. The area's link state database is represented as a directed graph. The graph's vertices are routers, transit networks and stub networks. The first stage of the procedure concerns only the transit vertices (routers and transit networks) and their connecting links. Throughout the shortest path calculation, the following data is also associated with each transit vertex: Vertex (node) ID A 32-bit number which together with the vertex type (router or network) uniquely identifies the vertex. For router vertices the Vertex ID is the router's OSPF Router ID. For network vertices, it is the IP address of the network's Designated Router.
手順は、セクション2で導入されたグラフの用語を使用して説明されます。エリアのリンク状態データベースは、有向グラフとして表されます。グラフの頂点は、ルーター、トランジットネットワーク、およびスタブネットワークです。手順の最初の段階は、トランジット頂点（ルーターとトランジットネットワーク）とそれらの接続リンクのみに関係します。最短経路の計算全体を通じて、次のデータも各通過頂点に関連付けられています。頂点（ノード）ID 32ビットの数値で、頂点タイプ（ルーターまたはネットワーク）とともに頂点を一意に識別します。ルーター頂点の場合、頂点IDはルーターのOSPFルーターIDです。ネットワーク頂点の場合、これはネットワークの指定ルーターのIPアドレスです。
An LSA Each transit vertex has an associated LSA. For router vertices, this is a router-LSA. For transit networks, this is a network-LSA (which is actually originated by the network's Designated Router). In any case, the LSA's Link State ID is always equal to the above Vertex ID.
LSA各通過頂点には、LSAが関連付けられています。ルーター頂点の場合、これはルーターLSAです。トランジットネットワークの場合、これはネットワークLSAです（これは実際にはネットワークの指定ルーターによって発信されます）。いずれの場合も、LSAのリンク状態IDは常に上記の頂点IDと同じです。
List of next hops The list of next hops for the current set of shortest paths from the root to this vertex. There can be multiple shortest paths due to the equal-cost multipath capability. Each next hop indicates the outgoing router interface to use when forwarding traffic to the destination. On broadcast, Point-to-MultiPoint and NBMA networks, the next hop also includes the IP address of the next router (if any) in the path towards the destination.
ネクストホップのリストルートからこの頂点への現在の最短パスのセットのネクストホップのリスト。等コストマルチパス機能により、複数の最短パスが存在する可能性があります。各ネクストホップは、宛先にトラフィックを転送するときに使用する発信ルーターインターフェイスを示します。ブロードキャスト、ポイントツーマルチポイント、およびNBMAネットワークでは、ネクストホップには、宛先へのパスにある次のルーター（存在する場合）のIPアドレスも含まれます。
Distance from root The link state cost of the current set of shortest paths from the root to the vertex. The link state cost of a path is calculated as the sum of the costs of the path's constituent links (as advertised in router-LSAs and network-LSAs). One path is said to be "shorter" than another if it has a smaller link state cost.
ルートからの距離ルートから頂点までの最短パスの現在のセットのリンク状態コスト。パスのリンク状態コストは、パスの構成リンクのコストの合計として計算されます（ルーターLSAおよびネットワークLSAでアドバタイズされます）。リンク状態コストが小さいパスは、別のパスよりも「短い」と言います。
The first stage of the procedure (i.e., the Dijkstra algorithm) can now be summarized as follows. At each iteration of the algorithm, there is a list of candidate vertices. Paths from the root to these vertices have been found, but not necessarily the shortest ones. However, the paths to the candidate vertex that is closest to the root are guaranteed to be shortest; this vertex is added to the shortest-path tree, removed from the candidate list, and its adjacent vertices are examined for possible addition to/modification of the candidate list. The algorithm then iterates again. It terminates when the candidate list becomes empty.
手順の最初の段階（つまり、ダイクストラアルゴリズム）は次のように要約できます。アルゴリズムの各反復で、候補の頂点のリストがあります。ルートからこれらの頂点へのパスが見つかりましたが、必ずしも最短のパスではありません。ただし、ルートに最も近い候補頂点へのパスは最短であることが保証されています。この頂点は最短パスツリーに追加され、候補リストから削除されます。隣接する頂点は、候補リストへの追加/変更の可能性について検査されます。その後、アルゴリズムは再度反復します。候補リストが空になると終了します。
The following steps describe the algorithm in detail. Remember that we are computing the shortest path tree for Area A. All references to link state database lookup below are from Area A's database.
次の手順では、アルゴリズムについて詳しく説明します。エリアAの最短パスツリーを計算していることを思い出してください。以下のリンク状態データベースルックアップへの参照はすべてエリアAのデータベースからのものです。
(1) Initialize the algorithm's data structures. Clear the list of candidate vertices. Initialize the shortest-path tree to only the root (which is the router doing the calculation). Set Area A's TransitCapability to FALSE.
（1）アルゴリズムのデータ構造を初期化します。候補頂点のリストをクリアします。ルート（計算を行うルーター）のみに最短パスツリーを初期化します。エリアAのTransitCapabilityをFALSEに設定します。
(2) Call the vertex just added to the tree vertex V. Examine the LSA associated with vertex V. This is a lookup in the Area A's link state database based on the Vertex ID. If this is a router-LSA, and bit V of the router-LSA (see Section A.4.2) is set, set Area A's TransitCapability to TRUE. In any case, each link described by the LSA gives the cost to an adjacent vertex. For each described link, (say it joins vertex V to vertex W):
（2）ツリー頂点Vに追加されたばかりの頂点を呼び出します。頂点Vに関連付けられたLSAを調べます。これは、頂点IDに基づくエリアAのリンク状態データベースのルックアップです。これがルーターLSAであり、ルーターLSAのビットV（セクションA.4.2を参照）が設定されている場合は、エリアAのTransitCapabilityをTRUEに設定します。いずれの場合でも、LSAによって記述される各リンクは、隣接する頂点にコストを与えます。記述されたリンクごとに（頂点Vを頂点Wに結合するとします）：
(a) If this is a link to a stub network, examine the next link in V's LSA. Links to stub networks will be considered in the second stage of the shortest path calculation.
（a）これがスタブネットワークへのリンクである場合は、VのLSAの次のリンクを調べます。スタブネットワークへのリンクは、最短パス計算の第2段階で考慮されます。
(b) Otherwise, W is a transit vertex (router or transit network). Look up the vertex W's LSA (router-LSA or network-LSA) in Area A's link state database. If the LSA does not exist, or its LS age is equal to MaxAge, or it does not have a link back to vertex V, examine the next link in V's LSA.[23]
（b）それ以外の場合、Wは通過頂点（ルーターまたは通過ネットワーク）です。エリアAのリンク状態データベースで頂点WのLSA（ルーターLSAまたはネットワークLSA）を検索します。 LSAが存在しない場合、またはそのLSエージがMaxAgeに等しい場合、または頂点Vに戻るリンクがない場合は、VのLSAの次のリンクを調べます。[23]
(c) If vertex W is already on the shortest-path tree, examine the next link in the LSA.
（c）頂点Wがすでに最短パスツリー上にある場合は、LSAの次のリンクを調べます。
(d) Calculate the link state cost D of the resulting path from the root to vertex W. D is equal to the sum of the link state cost of the (already calculated) shortest path to vertex V and the advertised cost of the link between vertices V and W. If D is: o Greater than the value that already appears for vertex W on the candidate list, then examine the next link.
（d）ルートから頂点Wまでの結果のパスのリンク状態コストDを計算します。Dは、頂点Vへの（既に計算された）最短パスのリンク状態コストと、その間のリンクの公示コストの合計に等しくなります。頂点VおよびW。Dが次の場合：o候補リストの頂点Wにすでに表示されている値より大きい場合、次のリンクを調べます。
o Equal to the value that appears for vertex W on the candidate list, calculate the set of next hops that result from using the advertised link. Input to this calculation is the destination (W), and its parent (V). This calculation is shown in Section 16.1.1. This set of hops should be added to the next hop values that appear for W on the candidate list.
o 候補リストの頂点Wに表示される値と同じ値で、アドバタイズされたリンクを使用した結果生じる次のホップのセットを計算します。この計算への入力は、宛先（W）とその親（V）です。この計算は、セクション16.1.1に示されています。このホップのセットは、候補リストのWに表示される次のホップ値に追加する必要があります。
o Less than the value that appears for vertex W on the candidate list, or if W does not yet appear on the candidate list, then set the entry for W on the candidate list to indicate a distance of D from the root. Also calculate the list of next hops that result from using the advertised link, setting the next hop values for W accordingly. The next hop calculation is described in Section 16.1.1; it takes as input the destination (W) and its parent (V).
o 候補リストの頂点Wに表示される値よりも小さい場合、またはWが候補リストにまだ表示されていない場合は、候補リストのWのエントリを設定して、ルートからのDの距離を示します。また、アドバタイズされたリンクの使用から生じるネクストホップのリストを計算し、それに応じてWのネクストホップ値を設定します。ネクストホップの計算については、セクション16.1.1で説明します。入力として宛先（W）とその親（V）を受け取ります。
(3) If at this step the candidate list is empty, the shortest-path tree (of transit vertices) has been completely built and this stage of the procedure terminates. Otherwise, choose the vertex belonging to the candidate list that is closest to the root, and add it to the shortest-path tree (removing it from the candidate list in the process). Note that when there is a choice of vertices closest to the root, network vertices must be chosen before router vertices in order to necessarily find all equal-cost paths. This is consistent with the tie-breakers that were introduced in the modified Dijkstra algorithm used by OSPF's Multicast routing extensions (MOSPF).
（3）このステップで候補リストが空の場合、（通過頂点の）最短経路ツリーが完全に構築され、手順のこの段階が終了します。それ以外の場合は、ルートに最も近い候補リストに属する頂点を選択し、最短パスツリーに追加します（プロセスで候補リストから削除します）。ルートに最も近い頂点の選択がある場合、すべての等コストパスを必ず見つけるために、ルーター頂点の前にネットワーク頂点を選択する必要があることに注意してください。これは、OSPFのマルチキャストルーティング拡張機能（MOSPF）で使用される変更されたダイクストラアルゴリズムで導入されたタイブレーカーと一致しています。
(4) Possibly modify the routing table. For those routing table entries modified, the associated area will be set to Area A, the path type will be set to intra-area, and the cost will be set to the newly discovered shortest path's calculated distance.
（4）ルーティングテーブルを変更する可能性があります。変更されたルーティングテーブルエントリの場合、関連するエリアはエリアAに設定され、パスタイプはエリア内に設定され、コストは新しく検出された最短パスの計算距離に設定されます。
If the newly added vertex is an area border router or AS boundary router, a routing table entry is added whose destination type is "router". The Options field found in the associated router-LSA is copied into the routing table entry's Optional capabilities field. Call the newly added vertex Router X. If Router X is the endpoint of one of the calculating router's virtual links, and the virtual link uses Area A as Transit area: the virtual link is declared up, the IP address of the virtual interface is set to the IP address of the outgoing interface calculated above for Router X, and the virtual neighbor's IP address is set to Router X's interface address (contained in Router X's router-LSA) that points back to the root of the shortest-path tree; equivalently, this is the interface that points back to Router X's parent vertex on the shortest-path tree (similar to the calculation in Section 16.1.1).
新しく追加された頂点がエリア境界ルーターまたはAS境界ルーターである場合、宛先タイプが「ルーター」であるルーティングテーブルエントリが追加されます。関連するルーターLSAにあるオプションフィールドは、ルーティングテーブルエントリのオプション機能フィールドにコピーされます。新しく追加された頂点ルーターXを呼び出します。ルーターXが計算ルーターの仮想リンクのいずれかのエンドポイントであり、仮想リンクがエリアAをトランジットエリアとして使用している場合：仮想リンクが宣言されている場合、仮想インターフェースのIPアドレスが設定されます。上記で計算されたルーターXの発信インターフェイスのIPアドレスに、仮想ネイバーのIPアドレスは、最短パスツリーのルートを指すルーターXのインターフェイスアドレス（ルーターXのrouter-LSAに含まれる）に設定されます。同様に、これは最短パスツリー上のルーターXの親頂点を指すインターフェイスです（セクション16.1.1の計算と同様）。
If the newly added vertex is a transit network, the routing table entry for the network is located. The entry's Destination ID is the IP network number, which can be obtained by masking the Vertex ID (Link State ID) with its associated subnet mask (found in the body of the associated network-LSA). If the routing table entry already exists (i.e., there is already an intra-area route to the destination installed in the routing table), multiple vertices have mapped to the same IP network. For example, this can occur when a new Designated Router is being established. In this case, the current routing table entry should be overwritten if and only if the newly found path is just as short and the current routing table entry's Link State Origin has a smaller Link State ID than the newly added vertex' LSA.
新しく追加された頂点がトランジットネットワークの場合、ネットワークのルーティングテーブルエントリが見つかります。エントリの宛先IDはIPネットワーク番号です。これは、関連するサブネットマスク（関連するネットワークLSAの本体にあります）で頂点ID（リンク状態ID）をマスキングすることによって取得できます。ルーティングテーブルエントリが既に存在する（つまり、ルーティングテーブルにインストールされている宛先へのエリア内ルートが既に存在する）場合、複数の頂点が同じIPネットワークにマッピングされています。たとえば、これは新しい代表ルーターが確立されているときに発生する可能性があります。この場合、新しく見つかったパスが同じくらい短く、現在のルーティングテーブルエントリのリンク状態原点が、新しく追加された頂点のLSAよりも小さいリンク状態IDを持っている場合にのみ、現在のルーティングテーブルエントリを上書きする必要があります。
If there is no routing table entry for the network (the usual case), a routing table entry for the IP network should be added. The routing table entry's Link State Origin should be set to the newly added vertex' LSA.
ネットワークのルーティングテーブルエントリがない場合（通常の場合）、IPネットワークのルーティングテーブルエントリを追加する必要があります。ルーティングテーブルエントリのリンク状態の原点は、新しく追加された頂点のLSAに設定する必要があります。
(5) Iterate the algorithm by returning to Step 2.
（5）ステップ2に戻ってアルゴリズムを反復します。
The stub networks are added to the tree in the procedure's second stage. In this stage, all router vertices are again examined. Those that have been determined to be unreachable in the above first phase are discarded. For each reachable router vertex (call it V), the associated router-LSA is found in the link state database. Each stub network link appearing in the LSA is then examined, and the following steps are executed:
手順の2番目の段階で、スタブネットワークがツリーに追加されます。この段階では、すべてのルーターの頂点が再度検査されます。上記の最初のフェーズで到達不能と判断されたものは破棄されます。到達可能なルーター頂点（Vと呼ぶ）ごとに、関連付けられたルーターLSAがリンク状態データベースで見つかります。次に、LSAに表示される各スタブネットワークリンクが検査され、次の手順が実行されます。
(1) Calculate the distance D of stub network from the root. D is equal to the distance from the root to the router vertex (calculated in stage 1), plus the stub network link's advertised cost. Compare this distance to the current best cost to the stub network. This is done by looking up the stub network's current routing table entry. If the calculated distance D is larger, go on to examine the next stub network link in the LSA.
（1）スタブネットワークのルートからの距離Dを計算します。 Dは、ルートからルーター頂点までの距離（ステージ1で計算）に、スタブネットワークリンクのアドバタイズされたコストを加えたものです。この距離をスタブネットワークの現在の最適コストと比較します。これは、スタブネットワークの現在のルーティングテーブルエントリを調べることによって行われます。計算された距離Dが大きい場合は、LSAの次のスタブネットワークリンクを調べます。
(2) If this step is reached, the stub network's routing table entry must be updated. Calculate the set of next hops that would result from using the stub network link. This calculation is shown in Section 16.1.1; input to this calculation is the destination (the stub network) and the parent vertex (the router vertex). If the distance D is the same as the current routing table cost, simply add this set of next hops to the routing table entry's list of next hops. In this case, the routing table already has a Link State Origin. If this Link State Origin is a router-LSA whose Link State ID is smaller than V's Router ID, reset the Link State Origin to V's router-LSA.
（2）このステップに達した場合、スタブネットワークのルーティングテーブルエントリを更新する必要があります。スタブネットワークリンクを使用した結果生じるネクストホップのセットを計算します。この計算はセクション16.1.1に示されています。この計算への入力は、宛先（スタブネットワーク）と親の頂点（ルーターの頂点）です。距離Dが現在のルーティングテーブルのコストと同じ場合は、このネクストホップのセットをルーティングテーブルエントリのネクストホップのリストに追加するだけです。この場合、ルーティングテーブルにはすでにリンクステートオリジンがあります。このリンク状態オリジンが、リンク状態IDがVのルーターIDより小さいルーターLSAである場合、リンク状態オリジンをVのルーターLSAにリセットします。
Otherwise D is smaller than the routing table cost. Overwrite the current routing table entry by setting the routing table entry's cost to D, and by setting the entry's list of next hops to the newly calculated set. Set the routing table entry's Link State Origin to V's router-LSA. Then go on to examine the next stub network link.
それ以外の場合、Dはルーティングテーブルのコストよりも小さくなります。ルーティングテーブルエントリのコストをDに設定し、エントリのネクストホップのリストを新しく計算されたセットに設定することにより、現在のルーティングテーブルエントリを上書きします。ルーティングテーブルエントリのリンク状態の起点をVのrouter-LSAに設定します。次に、次のスタブネットワークリンクを調べます。
For all routing table entries added/modified in the second stage, the associated area will be set to Area A and the path type will be set to intra-area. When the list of reachable router-LSAs is exhausted, the second stage is completed. At this time, all intra-area routes associated with Area A have been determined.
2番目のステージで追加/変更されたすべてのルーティングテーブルエントリについて、関連するエリアはエリアAに設定され、パスタイプはエリア内に設定されます。到達可能なルーターLSAのリストがなくなると、第2段階が完了します。この時点で、エリアAに関連付けられているすべてのエリア内ルートが決定されています。
The specification does not require that the above two stage method be used to calculate the shortest path tree. However, if another algorithm is used, an identical tree must be produced. For this reason, it is important to note that links between transit vertices must be bidirectional in order to be included in the above tree. It should also be mentioned that more efficient algorithms exist for calculating the tree; for example, the incremental SPF algorithm described in [Ref1].
仕様では、上記の2段階の方法を使用して最短パスツリーを計算する必要はありません。ただし、別のアルゴリズムを使用する場合は、同じツリーを作成する必要があります。このため、トランジット頂点間のリンクが上記のツリーに含まれるためには双方向である必要があることに注意することが重要です。ツリーを計算するためのより効率的なアルゴリズムが存在することにも言及する必要があります。たとえば、[Ref1]で説明されているインクリメンタルSPFアルゴリズム。
16.1.1. The next hop calculation
16.1.1. ネクストホップの計算
This section explains how to calculate the current set of next hops to use for a destination. Each next hop consists of the outgoing interface to use in forwarding packets to the destination together with the IP address of the next hop router (if any). The next hop calculation is invoked each time a shorter path to the destination is discovered. This can happen in either stage of the shortest-path tree calculation (see Section 16.1). In stage 1 of the shortest-path tree calculation a shorter path is found as the destination is added to the candidate list, or when the destination's entry on the candidate list is modified (Step 2d of Stage 1). In stage 2 a shorter path is discovered each time the destination's routing table entry is modified (Step 2 of Stage 2).
このセクションでは、宛先に使用するネクストホップの現在のセットを計算する方法について説明します。各ネクストホップは、ネクストホップルーター（存在する場合）のIPアドレスと共に宛先にパケットを転送する際に使用する発信インターフェイスで構成されます。ネクストホップ計算は、宛先へのより短いパスが検出されるたびに呼び出されます。これは、最短パスツリー計算のいずれかの段階で発生する可能性があります（セクション16.1を参照）。最短パスツリー計算のステージ1では、宛先が候補リストに追加されたとき、または候補リスト上の宛先のエントリが変更されたときに、より短いパスが見つかります（ステージ1のステップ2d）。ステージ2では、宛先のルーティングテーブルエントリが変更されるたびに、短いパスが検出されます（ステージ2のステップ2）。
The set of next hops to use for the destination may be recalculated several times during the shortest-path tree calculation, as shorter and shorter paths are discovered. In the end, the destination's routing table entry will always reflect the next hops resulting from the absolute shortest path(s).
宛先に使用するネクストホップのセットは、最短パスツリーの計算中に数回再計算される場合があります。最後に、宛先のルーティングテーブルエントリは、絶対最短パスから生じるネクストホップを常に反映します。
Input to the next hop calculation is a) the destination and b) its parent in the current shortest path between the root (the calculating router) and the destination. The parent is always a transit vertex (i.e., always a router or a transit network).
ネクストホップ計算への入力は、a）宛先であり、b）ルート（計算ルーター）と宛先の間の現在の最短パスにおけるその親です。親は常に通過頂点です（つまり、常にルーターまたは通過ネットワーク）。
If there is at least one intervening router in the current shortest path between the destination and the root, the destination simply inherits the set of next hops from the parent. Otherwise, there are two cases. In the first case, the parent vertex is the root (the calculating router itself). This means that the destination is either a directly connected network or directly connected router. The outgoing interface in this case is simply the OSPF interface connecting to the destination network/router. If the destination is a router which connects to the calculating router via a Point-to-MultiPoint network, the destination's next hop IP address(es) can be determined by examining the destination's router-LSA: each link pointing back to the calculating router and having a Link Data field belonging to the Point-to-MultiPoint network provides an IP address of the next hop router. If the destination is a directly connected network, or a router which connects to the calculating router via a point-to-point interface, no next hop IP address is required. If the destination is a router connected to the calculating router via a virtual link, the setting of the next hop should be deferred until the calculation in Section 16.3.
宛先とルート間の現在の最短パスに少なくとも1つの介在ルーターがある場合、宛先は単に親からネクストホップのセットを継承します。それ以外の場合は2つのケースがあります。最初のケースでは、親頂点がルート（計算ルーター自体）です。つまり、宛先は直接接続されたネットワークまたは直接接続されたルーターです。この場合の発信インターフェースは、宛先ネットワーク/ルーターに接続するOSPFインターフェースです。宛先がポイントツーマルチポイントネットワークを介して計算ルーターに接続するルーターである場合、宛先のネクストホップIPアドレスは、宛先のルーターLSAを調べることで決定できます。各リンクは計算ルーターを指し示し、ポイントツーマルチポイントネットワークに属するリンクデータフィールドがあると、ネクストホップルーターのIPアドレスが提供されます。宛先が直接接続されたネットワーク、またはポイントツーポイントインターフェイスを介して計算ルーターに接続するルーターの場合、ネクストホップIPアドレスは必要ありません。宛先が仮想リンクを介して計算ルーターに接続されているルーターである場合、ネクストホップの設定は、セクション16.3の計算まで延期する必要があります。
In the second case, the parent vertex is a network that directly connects the calculating router to the destination router. The list of next hops is then determined by examining the destination's router-LSA. For each link in the router-LSA that points back to the parent network, the link's Link Data field provides the IP address of a next hop router. The outgoing interface to use can then be derived from the next hop IP address (or it can be inherited from the parent network).
2番目のケースでは、親頂点は、計算ルーターを宛先ルーターに直接接続するネットワークです。次に、宛先のルーターLSAを調べて、ネクストホップのリストを決定します。親ネットワークを指すルーターLSA内の各リンクについて、リンクの[リンクデータ]フィールドは、ネクストホップルーターのIPアドレスを提供します。使用する発信インターフェイスは、ネクストホップIPアドレスから取得できます（または、親ネットワークから継承できます）。
16.2. Calculating the inter-area routes
16.2. エリア間ルートの計算
The inter-area routes are calculated by examining summary-LSAs. If the router has active attachments to multiple areas, only backbone summary-LSAs are examined. Routers attached to a single area examine that area's summary-LSAs. In either case, the summary-LSAs examined below are all part of a single area's link state database (call it Area A).
エリア間ルートは、サマリーLSAを調べることによって計算されます。ルータに複数のエリアへのアクティブなアタッチメントがある場合、バックボーンサマリーLSAのみが検査されます。単一のエリアに接続されたルーターは、そのエリアのサマリーLSAを調べます。どちらの場合でも、以下で調べたサマリーLSAはすべて、単一のエリアのリンク状態データベース（エリアAと呼びます）の一部です。
Summary-LSAs are originated by the area border routers. Each summary-LSA in Area A is considered in turn. Remember that the destination described by a summary-LSA is either a network (Type 3 summary-LSAs) or an AS boundary router (Type 4 summary-LSAs). For each summary-LSA:
サマリーLSAは、エリア境界ルーターによって発信されます。エリアAの各サマリーLSAが順番に検討されます。要約LSAによって記述される宛先は、ネットワーク（タイプ3要約LSA）またはAS境界ルーター（タイプ4要約LSA）のいずれかであることを忘れないでください。各サマリーLSAについて：
(1) If the cost specified by the LSA is LSInfinity, or if the LSA's LS age is equal to MaxAge, then examine the the next LSA.
（1）LSAによって指定されたコストがLSInfinityである場合、またはLSAのLSエージがMaxAgeと等しい場合は、次のLSAを調べます。
(2) If the LSA was originated by the calculating router itself, examine the next LSA.
（2）LSAが計算ルーター自体によって発信された場合は、次のLSAを調べます。
(3) If it is a Type 3 summary-LSA, and the collection of destinations described by the summary-LSA equals one of the router's configured area address ranges (see Section 3.5), and the particular area address range is active, then the summary-LSA should be ignored. "Active" means that there are one or more reachable (by intra-area paths) networks contained in the area range.
（3）タイプ3サマリーLSAであり、サマリーLSAによって記述された宛先のコレクションがルーターの構成済みエリアアドレス範囲の1つに等しく（セクション3.5を参照）、特定のエリアアドレス範囲がアクティブである場合、 summary-LSAは無視する必要があります。 「アクティブ」とは、エリア範囲に含まれる（エリア内パスによって）到達可能な1つ以上のネットワークがあることを意味します。
(4) Else, call the destination described by the LSA N (for Type 3 summary-LSAs, N's address is obtained by masking the LSA's Link State ID with the network/subnet mask contained in the body of the LSA), and the area border originating the LSA BR. Look up the routing table entry for BR having Area A as its associated area. If no such entry exists for router BR (i.e., BR is unreachable in Area A), do nothing with this LSA and consider the next in the list. Else, this LSA describes an inter-area path to destination N, whose cost is the distance to BR plus the cost specified in the LSA. Call the cost of this inter-area path IAC.
（4）それ以外の場合は、LSA N（タイプ3サマリーLSAの場合、LSAのリンク状態IDをLSAの本体に含まれているネットワーク/サブネットマスクでマスキングすることによってNのアドレスが取得されます）、およびエリアによって記述された宛先を呼び出します。 LSA BRを発信する境界。関連するエリアとしてエリアAを持つBRのルーティングテーブルエントリを検索します。ルータBRにそのようなエントリが存在しない場合（つまり、エリアAでBRに到達できない場合）、このLSAで何もせず、リストの次のものを検討します。そうでない場合、このLSAは宛先Nへのエリア間パスを記述します。そのコストは、BRまでの距離にLSAで指定されたコストを加えたものです。このエリア間パスのコストをIACと呼びます。
(5) Next, look up the routing table entry for the destination N. (If N is an AS boundary router, look up the "router" routing table entry associated with Area A). If no entry exists for N or if the entry's path type is "type 1 external" or "type 2 external", then install the inter-area path to N, with associated area Area A, cost IAC, next hop equal to the list of next hops to router BR, and Advertising router equal to BR.
（5）次に、宛先Nのルーティングテーブルエントリを検索します（NがAS境界ルーターの場合、エリアAに関連付けられた "ルーター"ルーティングテーブルエントリを検索します）。 Nのエントリが存在しない場合、またはエントリのパスタイプが「タイプ1外部」または「タイプ2外部」である場合は、Nへのエリア間パスをインストールし、エリアAに関連付けられ、IACのコストがかかり、次のホップがリストと等しいルーターBRへのネクストホップ、およびBRに等しいアドバタイズルーター。
(6) Else, if the paths present in the table are intra-area paths, do nothing with the LSA (intra-area paths are always preferred).
（6）それ以外の場合、表にあるパスがエリア内パスの場合、LSAで何もしません（エリア内パスが常に優先されます）。
(7) Else, the paths present in the routing table are also inter-area paths. Install the new path through BR if it is cheaper, overriding the paths in the routing table. Otherwise, if the new path is the same cost, add it to the list of paths that appear in the routing table entry.
（7）それ以外の場合、ルーティングテーブルに存在するパスもエリア間パスです。安価な場合はBRを介して新しいパスをインストールし、ルーティングテーブルのパスを上書きします。それ以外の場合、新しいパスが同じコストである場合は、ルーティングテーブルエントリに表示されるパスのリストに追加します。
16.3. Examining transit areas' summary-LSAs
16.3. トランジットエリアのサマリーLSAの調査
This step is only performed by area border routers attached to one or more non-backbone areas that are capable of carrying transit traffic (i.e., "transit areas", or those areas whose TransitCapability parameter has been set to TRUE in Step 2 of the Dijkstra algorithm (see Section 16.1).
このステップは、トランジットトラフィックを伝送できる1つ以上の非バックボーンエリアに接続されたエリア境界ルーター（つまり、「トランジットエリア」、またはダイクストラのステップ2でTransitCapabilityパラメーターがTRUEに設定されているエリアによってのみ実行されます。アルゴリズム（セクション16.1を参照）。
The purpose of the calculation below is to examine the transit areas to see whether they provide any better (shorter) paths than the paths previously calculated in Sections 16.1 and 16.2. Any paths found that are better than or equal to previously discovered paths are installed in the routing table.
以下の計算の目的は、トランジットエリアを調べて、セクション16.1および16.2で以前に計算されたパスよりも良い（短い）パスが提供されているかどうかを確認することです。以前に検出されたパス以上のパスが見つかった場合は、ルーティングテーブルにインストールされます。
The calculation also determines the actual next hop(s) for those destinations whose next hop was calculated as a virtual link in Sections 16.1 and 16.2. After completion of the calculation below, any paths calculated in Sections 16.1 and 16.2 that still have unresolved virtual next hops should be discarded.
この計算では、セクション16.1および16.2で仮想リンクとして計算されたネクストホップの宛先の実際のネクストホップも決定されます。以下の計算の完了後、セクション16.1および16.2で計算された未解決の仮想ネクストホップがまだあるパスはすべて破棄する必要があります。
The calculation proceeds as follows. All the transit areas' summary-LSAs are examined in turn. Each such summary-LSA describes a route through a transit area Area A to a Network N (N's address is obtained by masking the LSA's Link State ID with the network/subnet mask contained in the body of the LSA) or in the case of a Type 4 summary-LSA, to an AS boundary router N. Suppose also that the summary-LSA was originated by an area border router BR.
計算は次のように行われます。すべてのトランジットエリアのサマリーLSAが順に検査されます。このような各サマリーLSAは、トランジットエリアArea Aを経由してネットワークNへのルートを記述します（Nのアドレスは、LSAのリンク状態IDをLSAの本体に含まれるネットワーク/サブネットマスクでマスクすることによって取得されます）タイプ4サマリーLSA、AS境界ルーターNへ。サマリーLSAがエリア境界ルーターBRによって発信されたと仮定します。
(1) If the cost advertised by the summary-LSA is LSInfinity, or if the LSA's LS age is equal to MaxAge, then examine the next LSA.
（1）サマリーLSAによってアドバタイズされたコストがLSInfinityである場合、またはLSAのLSエージがMaxAgeと等しい場合は、次のLSAを調べます。
(2) If the summary-LSA was originated by the calculating router itself, examine the next LSA.
（2）サマリーLSAが計算ルーター自体によって発信された場合は、次のLSAを調べます。
(3) Look up the routing table entry for N. (If N is an AS boundary router, look up the "router" routing table entry associated with the backbone area). If it does not exist, or if the route type is other than intra-area or inter-area, or if the area associated with the routing table entry is not the backbone area, then examine the next LSA. In other words, this calculation only updates backbone intra-area routes found in Section 16.1 and inter-area routes found in Section 16.2.
（3）Nのルーティングテーブルエントリを検索します（NがAS境界ルーターの場合は、バックボーンエリアに関連付けられた "ルーター"ルーティングテーブルエントリを検索します）。存在しない場合、またはルートタイプがエリア内またはエリア間以外の場合、またはルーティングテーブルエントリに関連付けられているエリアがバックボーンエリアでない場合は、次のLSAを調べます。つまり、この計算では、セクション16.1にあるバックボーンエリア内ルートとセクション16.2にあるエリア間ルートのみが更新されます。
(4) Look up the routing table entry for the advertising router BR associated with the Area A. If it is unreachable, examine the next LSA. Otherwise, the cost to destination N is the sum of the cost in BR's Area A routing table entry and the cost advertised in the LSA. Call this cost IAC.
（4）エリアAに関連付けられているアドバタイズルーターBRのルーティングテーブルエントリを検索します。到達できない場合は、次のLSAを調べます。それ以外の場合、宛先Nへのコストは、BRのエリアAルーティングテーブルエントリのコストとLSAでアドバタイズされたコストの合計です。これをIACと呼びます。
(5) If this cost is less than the cost occurring in N's routing table entry, overwrite N's list of next hops with those used for BR, and set N's routing table cost to IAC. Else, if IAC is the same as N's current cost, add BR's list of next hops to N's list of next hops. In any case, the area associated with N's routing table entry must remain the backbone area, and the path type (either intra-area or inter-area) must also remain the same.
（5）このコストがNのルーティングテーブルエントリで発生するコストよりも小さい場合は、NのネクストホップのリストをBRに使用されるもので上書きし、NのルーティングテーブルコストをIACに設定します。そうでない場合、IACがNの現在のコストと同じである場合、BRのネクストホップのリストをNのネクストホップのリストに追加します。いずれの場合も、Nのルーティングテーブルエントリに関連付けられたエリアはバックボーンエリアのままである必要があり、パスタイプ（エリア内またはエリア間）も同じままである必要があります。
It is important to note that the above calculation never makes unreachable destinations reachable, but instead just potentially finds better paths to already reachable destinations. The calculation installs any better cost found into the routing table entry, from which it may be readvertised in summary-LSAs to other areas.
上記の計算では、到達不能な宛先が到達可能になることはなく、すでに到達可能な宛先へのより良いパスが見つかる可能性があることに注意してください。計算により、ルーティングテーブルエントリに見つかったより良いコストがインストールされ、そこからサマリーLSAで他のエリアに再アドバタイズされる可能性があります。
As an example of the calculation, consider the Autonomous System pictured in Figure 17. There is a single non-backbone area (Area 1) that physically divides the backbone into two separate pieces. To maintain connectivity of the backbone, a virtual link has been configured between routers RT1 and RT4. On the right side of the figure, Network N1 belongs to the backbone. The dotted lines indicate that there is a much shorter intra-area
計算の例として、図17に示す自律システムを考えます。バックボーンを2つの個別の部分に物理的に分割する単一の非バックボーンエリア（エリア1）があります。バックボーンの接続を維持するために、ルータRT1とRT4の間に仮想リンクが構成されています。図の右側では、ネットワークN1がバックボーンに属しています。点線は、はるかに短いエリア内があることを示しています
........................
. Area 1 (transit) . +
. . |
. +---+1 1+---+100 |
. |RT2|----------|RT4|=========|
. 1/+---+********* +---+ |
. /******* . |
. 1/*Virtual . |
1+---+/* Link . Net|work
=======|RT1|* . | N1
+---+\ . |
. \ . |
. \ . |
. 1\+---+1 1+---+20 |
. |RT3|----------|RT5|=========|
. +---+ +---+ |
. . |
........................ +
Figure 17: Routing through transit areas
図17：トランジットエリアを通るルーティング
backbone path between router RT5 and Network N1 (cost 20) than there is between Router RT4 and Network N1 (cost 100). Both Router RT4 and Router RT5 will inject summary-LSAs for Network N1 into Area 1.
ルーターRT4とネットワークN1の間（コスト100）よりも、ルーターRT5とネットワークN1の間（コスト20）のバックボーンパス。ルーターRT4とルーターRT5の両方が、ネットワークN1のサマリーLSAをエリア1に挿入します。
After the shortest-path tree has been calculated for the backbone in Section 16.1, Router RT1 (left end of the virtual link) will have calculated a path through Router RT4 for all data traffic destined for Network N1. However, since Router RT5 is so much closer to Network N1, all routers internal to Area 1 (e.g., Routers RT2 and RT3) will forward their Network N1 traffic towards Router RT5, instead of RT4. And indeed, after examining Area 1's summary-LSAs by the above calculation, Router RT1 will also forward Network N1 traffic towards RT5. Note that in this example the virtual link enables transit data traffic to be forwarded through Area 1, but the actual path the transit data traffic takes does not follow the virtual link. In other words, virtual links allow transit traffic to be forwarded through an area, but do not dictate the precise path that the traffic will take.
セクション16.1でバックボーンの最短パスツリーが計算された後、ルーターRT1（仮想リンクの左端）は、ネットワークN1宛てのすべてのデータトラフィックについてルーターRT4を経由するパスを計算します。ただし、ルーターRT5はネットワークN1に非常に近いため、エリア1の内部にあるすべてのルーター（ルーターRT2やRT3など）は、ネットワークN1トラフィックをRT4ではなくルーターRT5に転送します。実際、上記の計算でエリア1のサマリーLSAを調べた後、ルーターRT1はネットワークN1トラフィックもRT5に転送します。この例では、仮想リンクにより、通過データトラフィックをエリア1経由で転送できるようになりますが、通過データトラフィックが通る実際のパスは仮想リンクをたどらないことに注意してください。言い換えると、仮想リンクは通過トラフィックがエリアを介して転送されることを許可しますが、トラフィックが通過する正確なパスを指示しません。
16.4. Calculating AS external routes
16.4. AS外部ルートの計算
AS external routes are calculated by examining AS-external-LSAs. Each of the AS-external-LSAs is considered in turn. Most AS-external-LSAs describe routes to specific IP destinations. An AS-external-LSA can also describe a default route for the Autonomous System (Destination ID = DefaultDestination, network/subnet mask = 0x00000000). For each AS-external-LSA:
AS外部ルートは、AS外部LSAを調べることによって計算されます。 AS外部LSAのそれぞれが順番に検討されます。ほとんどのAS外部LSAは、特定のIP宛先へのルートを記述します。 AS-external-LSAは、自律システムのデフォルトルートを記述することもできます（宛先ID = DefaultDestination、ネットワーク/サブネットマスク= 0x00000000）。各AS-external-LSAについて：
(1) If the cost specified by the LSA is LSInfinity, or if the LSA's LS age is equal to MaxAge, then examine the next LSA.
（1）LSAによって指定されたコストがLSInfinityである場合、またはLSAのLSエージがMaxAgeと等しい場合は、次のLSAを調べます。
(2) If the LSA was originated by the calculating router itself, examine the next LSA.
（2）LSAが計算ルーター自体によって発信された場合は、次のLSAを調べます。
(3) Call the destination described by the LSA N. N's address is obtained by masking the LSA's Link State ID with the network/subnet mask contained in the body of the LSA. Look up the routing table entries (potentially one per attached area) for the AS boundary router (ASBR) that originated the LSA. If no entries exist for router ASBR (i.e., ASBR is unreachable), do nothing with this LSA and consider the next in the list.
（3）LSA Nによって記述された宛先を呼び出します。Nのアドレスは、LSAの本文に含まれているネットワーク/サブネットマスクでLSAのリンク状態IDをマスクすることによって取得されます。 LSAを発信したAS境界ルーター（ASBR）のルーティングテーブルエントリ（接続された領域ごとに1つである可能性があります）を検索します。ルーターASBRのエントリが存在しない（つまり、ASBRに到達できない）場合は、このLSAで何もせず、リストの次のものを検討します。
Else, this LSA describes an AS external path to destination N. Examine the forwarding address specified in the AS-external-LSA. This indicates the IP address to which packets for the destination should be forwarded.
そうでない場合、このLSAは宛先NへのAS外部パスを記述します。AS-external-LSAで指定された転送アドレスを調べます。これは、宛先へのパケットの転送先となるIPアドレスを示します。
If the forwarding address is set to 0.0.0.0, packets should be sent to the ASBR itself. Among the multiple routing table entries for the ASBR, select the preferred entry as follows. If RFC1583Compatibility is set to "disabled", prune the set of routing table entries for the ASBR as described in Section 16.4.1. In any case, among the remaining routing table entries, select the routing table entry with the least cost; when there are multiple least cost routing table entries the entry whose associated area has the largest OSPF Area ID (when considered as an unsigned 32-bit integer) is chosen.
転送アドレスが0.0.0.0に設定されている場合、パケットはASBR自体に送信されます。 ASBRの複数のルーティングテーブルエントリの中から、次のように優先エントリを選択します。 RFC1583Compatibilityが「無効」に設定されている場合、セクション16.4.1で説明されているように、ASBRのルーティングテーブルエントリのセットをプルーニングします。いずれの場合も、残りのルーティングテーブルエントリの中から、コストが最小のルーティングテーブルエントリを選択します。複数の最小コストのルーティングテーブルエントリがある場合、関連付けられたエリアが最大のOSPFエリアID（符号なし32ビット整数と見なされる場合）を持つエントリーが選択されます。
If the forwarding address is non-zero, look up the forwarding address in the routing table.[24] The matching routing table entry must specify an intra-area or inter-area path; if no such path exists, do nothing with the LSA and consider the next in the list.
転送アドレスがゼロ以外の場合は、ルーティングテーブルで転送アドレスを検索します。[24]一致するルーティングテーブルエントリは、エリア内パスまたはエリア間パスを指定する必要があります。そのようなパスが存在しない場合は、LSAで何もせず、リストの次を検討します。
(4) Let X be the cost specified by the preferred routing table entry for the ASBR/forwarding address, and Y the cost specified in the LSA. X is in terms of the link state metric, and Y is a type 1 or 2 external metric.
（4）XをASBR /転送アドレスの優先ルーティングテーブルエントリで指定されたコストとし、YをLSAで指定されたコストとします。 Xはリンク状態メトリックで、Yはタイプ1または2の外部メトリックです。
(5) Look up the routing table entry for the destination N. If no entry exists for N, install the AS external path to N, with next hop equal to the list of next hops to the forwarding address, and advertising router equal to ASBR. If the external metric type is 1, then the path-type is set to type 1 external and the cost is equal to X+Y. If the external metric type is 2, the path-type is set to type 2 external, the link state component of the route's cost is X, and the type 2 cost is Y.
（5）宛先Nのルーティングテーブルエントリを検索します。Nのエントリが存在しない場合は、NへのAS外部パスをインストールします。ネクストホップは転送アドレスへのネクストホップのリストに等しく、アドバタイズルータはASBRに等しくなります。 。外部メトリックタイプが1の場合、パスタイプはタイプ1外部に設定され、コストはX + Yに等しくなります。外部メトリックタイプが2の場合、パスタイプはタイプ2外部に設定され、ルートのコストのリンク状態コンポーネントはX、タイプ2コストはYです。
(6) Compare the AS external path described by the LSA with the existing paths in N's routing table entry, as follows. If the new path is preferred, it replaces the present paths in N's routing table entry. If the new path is of equal preference, it is added to N's routing table entry's list of paths.
（6）次のように、LSAによって記述されたAS外部パスをNのルーティングテーブルエントリ内の既存のパスと比較します。新しいパスが優先される場合、Nのルーティングテーブルエントリの現在のパスが置き換えられます。新しいパスの優先順位が等しい場合は、Nのルーティングテーブルエントリのパスのリストに追加されます。
(a) Intra-area and inter-area paths are always preferred over AS external paths.
（a）エリア内パスおよびエリア間パスは、AS外部パスよりも常に優先されます。
(b) Type 1 external paths are always preferred over type 2 external paths. When all paths are type 2 external paths, the paths with the smallest advertised type 2 metric are always preferred.
（b）タイプ1の外部パスは、タイプ2の外部パスよりも常に優先されます。すべてのパスがタイプ2外部パスである場合、アドバタイズされたタイプ2メトリックが最小のパスが常に優先されます。
(c) If the new AS external path is still indistinguishable from the current paths in the N's routing table entry, and RFC1583Compatibility is set to "disabled", select the preferred paths based on the intra-AS paths to the ASBR/forwarding addresses, as specified in Section 16.4.1.
（c）新しいAS外部パスがNのルーティングテーブルエントリの現在のパスと区別がつかず、RFC1583Compatibilityが「無効」に設定されている場合は、ASBR /転送アドレスへのAS内パスに基づいて優先パスを選択します。セクション16.4.1で指定されているとおり。
(d) If the new AS external path is still indistinguishable from the current paths in the N's routing table entry, select the preferred path based on a least cost comparison. Type 1 external paths are compared by looking at the sum of the distance to the forwarding address and the advertised type 1 metric (X+Y). Type 2 external paths advertising equal type 2 metrics are compared by looking at the distance to the forwarding addresses.
（d）新しいAS外部パスがNのルーティングテーブルエントリの現在のパスと区別できない場合は、最小コストの比較に基づいて優先パスを選択します。タイプ1の外部パスは、転送アドレスまでの距離とアドバタイズされたタイプ1メトリック（X + Y）の合計を調べることによって比較されます。同じタイプ2メトリックをアドバタイズするタイプ2外部パスは、転送アドレスまでの距離を調べることによって比較されます。
16.4.1. External path preferences
16.4.1. 外部パス設定
When multiple intra-AS paths are available to ASBRs/forwarding addresses, the following rules indicate which paths are preferred. These rules apply when the same ASBR is reachable through multiple areas, or when trying to decide which of several AS-external-LSAs should be preferred. In the former case the paths all terminate at the same ASBR, while in the latter the paths terminate at separate ASBRs/forwarding addresses. In either case, each path is represented by a separate routing table entry as defined in Section 11.
ASBR /転送アドレスが複数のAS内パスを使用できる場合、次のルールはどのパスが優先されるかを示します。これらのルールは、同じASBRが複数のエリアから到達可能である場合、または複数のAS外部LSAのうちどれを優先するかを決定しようとする場合に適用されます。前者の場合、パスはすべて同じASBRで終了しますが、後者の場合、パスは個別のASBR /転送アドレスで終了します。どちらの場合も、セクション11で定義されているように、各パスは個別のルーティングテーブルエントリで表されます。
This section only applies when RFC1583Compatibility is set to "disabled".
このセクションは、RFC1583Compatibilityが「無効」に設定されている場合にのみ適用されます。
The path preference rules, stated from highest to lowest preference, are as follows. Note that as a result of these rules, there may still be multiple paths of the highest preference. In this case, the path to use must be determined based on cost, as described in Section 16.4.
優先順位の高いものから順に、パスの優先順位の規則は次のとおりです。これらのルールの結果として、最も優先度の高い複数のパスが存在する可能性があることに注意してください。この場合、セクション16.4で説明されているように、使用するパスはコストに基づいて決定する必要があります。
o Intra-area paths using non-backbone areas are always the most preferred.
o 非バックボーンエリアを使用するエリア内パスが常に最も優先されます。
o The other paths, intra-area backbone paths and inter-area paths, are of equal preference.
o その他のパス、エリア内バックボーンパスとエリア間パスは、優先度が同じです。
16.5. Incremental updates -- summary-LSAs
16.5. 増分更新-サマリーLSA
When a new summary-LSA is received, it is not necessary to recalculate the entire routing table. Call the destination described by the summary-LSA N (N's address is obtained by masking the LSA's Link State ID with the network/subnet mask contained in the body of the LSA), and let Area A be the area to which the LSA belongs. There are then two separate cases:
新しいサマリーLSAを受信した場合、ルーティングテーブル全体を再計算する必要はありません。概要LSA Nで記述された宛先を呼び出し（Nのアドレスは、LSAのリンク状態IDを、LSAの本体に含まれているネットワーク/サブネットマスクでマスクすることによって取得されます）、エリアAをLSAが属するエリアとします。次に、2つの個別のケースがあります。
Case 1: Area A is the backbone and/or the router is not an area border router. In this case, the following calculations must be performed. First, if there is presently an inter-area route to the destination N, N's routing table entry is invalidated, saving the entry's values for later comparisons. Then the calculation in Section 16.2 is run again for the single destination N. In this calculation, all of Area A's summary-LSAs that describe a route to N are examined. In addition, if the router is an area border router attached to one or more transit areas, the calculation in Section 16.3 must be run again for the single destination. If the results of these calculations have changed the cost/path to an AS boundary router (as would be the case for a Type 4 summary-LSA) or to any forwarding addresses, all AS-external-LSAs will have to be reexamined by rerunning the calculation in Section 16.4. Otherwise, if N is now newly unreachable, the calculation in Section 16.4 must be rerun for the single destination N, in case an alternate external route to N exists.
ケース1：エリアAがバックボーンであるか、ルーターがエリア境界ルーターではありません。この場合、以下の計算を行う必要があります。まず、宛先Nへのエリア間ルートが現在存在する場合、Nのルーティングテーブルエントリは無効になり、後で比較するためにエントリの値が保存されます。次に、セクション16.2の計算が単一の宛先Nに対して再度実行されます。この計算では、Nへのルートを説明するエリアAのすべてのサマリーLSAが調べられます。さらに、ルーターが1つ以上のトランジットエリアに接続されたエリア境界ルーターである場合は、16.3項の計算を単一の宛先に対して再度実行する必要があります。これらの計算の結果により、コスト/パスがAS境界ルーター（タイプ4サマリーLSAの場合と同様）または転送アドレスに変更された場合、すべてのAS外部LSAを再実行して再検討する必要があります。セクション16.4の計算。そうでない場合、Nが新しく到達不能になった場合、Nへの代替外部ルートが存在する場合に備えて、16.4項の計算を単一の宛先Nに対して再実行する必要があります。
Case 2: Area A is a transit area and the router is an area border router. In this case, the following calculations must be performed. First, if N's routing table entry presently contains one or more inter-area paths that utilize the transit area Area A, these paths should be removed. If this removes all paths from the routing table entry, the entry should be invalidated. The entry's old values should be saved for later comparisons. Next the calculation in Section 16.3 must be run again for the single destination N. If the results of this calculation have caused the cost to N to increase, the complete routing table calculation must be rerun starting with the Dijkstra algorithm specified in Section 16.1. Otherwise, if the cost/path to an AS boundary router (as would be the case for a Type 4 summary-LSA) or to any forwarding addresses has changed, all AS-external-LSAs will have to be reexamined by rerunning the calculation in Section 16.4. Otherwise, if N is now newly unreachable, the calculation in Section 16.4 must be rerun for the single destination N, in case an alternate external route to N exists.
ケース2：エリアAはトランジットエリアであり、ルーターはエリア境界ルーターです。この場合、以下の計算を行う必要があります。まず、Nのルーティングテーブルエントリに現在トランジットエリアArea Aを利用する1つ以上のエリア間パスが含まれている場合、これらのパスを削除する必要があります。これにより、ルーティングテーブルエントリからすべてのパスが削除される場合は、エントリを無効にする必要があります。エントリの古い値は、後で比較するために保存する必要があります。次に、セクション16.3の計算を1つの宛先Nに対して再度実行する必要があります。この計算の結果によりコストがNに増加した場合は、セクション16.1で指定したダイクストラアルゴリズムから、完全なルーティングテーブル計算を再実行する必要があります。それ以外の場合、（タイプ4サマリーLSAの場合のように）AS境界ルーターへのコスト/パスまたは転送アドレスが変更された場合、すべてのAS外部LSAは、次のように計算を再実行することによって再検討する必要があります。セクション16.4。そうでない場合、Nが新しく到達不能になった場合、Nへの代替外部ルートが存在する場合に備えて、16.4項の計算を単一の宛先Nに対して再実行する必要があります。
16.6. Incremental updates -- AS-external-LSAs
16.6. 増分更新-AS-external-LSA
When a new AS-external-LSA is received, it is not necessary to recalculate the entire routing table. Call the destination described by the AS-external-LSA N. N's address is obtained by masking the LSA's Link State ID with the network/subnet mask contained in the body of the LSA. If there is already an intra-area or inter-area route to the destination, no recalculation is necessary (internal routes take precedence).
新しいAS-external-LSAを受信した場合、ルーティングテーブル全体を再計算する必要はありません。 AS-external-LSA Nによって記述された宛先を呼び出します。Nのアドレスは、LSAの本文に含まれているネットワーク/サブネットマスクでLSAのリンク状態IDをマスキングすることによって取得されます。宛先へのエリア内またはエリア間ルートがすでに存在する場合、再計算は不要です（内部ルートが優先されます）。
Otherwise, the procedure in Section 16.4 will have to be performed, but only for those AS-external-LSAs whose destination is N. Before this procedure is performed, the present routing table entry for N should be invalidated.
それ以外の場合は、16.4節の手順を実行する必要がありますが、宛先がNであるAS外部LSAに対してのみ実行します。この手順を実行する前に、Nの現在のルーティングテーブルエントリを無効にする必要があります。
16.7. Events generated as a result of routing table changes
16.7. ルーティングテーブルの変更の結果として生成されたイベント
Changes to routing table entries sometimes cause the OSPF area border routers to take additional actions. These routers need to act on the following routing table changes:
ルーティングテーブルエントリを変更すると、OSPFエリア境界ルータが追加のアクションを実行することがあります。これらのルーターは、ルーティングテーブルの次の変更に対応する必要があります。
o The cost or path type of a routing table entry has changed. If the destination described by this entry is a Network or AS boundary router, and this is not simply a change of AS external routes, new summary-LSAs may have to be generated (potentially one for each attached area, including the backbone). See Section 12.4.3 for more information. If a previously advertised entry has been deleted, or is no longer advertisable to a particular area, the LSA must be flushed from the routing domain by setting its LS age to MaxAge and reflooding (see Section 14.1).
o ルーティングテーブルエントリのコストまたはパスの種類が変更されました。このエントリで記述された宛先がネットワークまたはAS境界ルーターであり、これが単にAS外部ルートの変更ではない場合、新しいサマリーLSAを生成する必要がある場合があります（バックボーンを含む、接続されたエリアごとに1つ）。詳細については、セクション12.4.3を参照してください。以前にアドバタイズされたエントリが削除されているか、特定のエリアにアドバタイズできなくなった場合、LSAをLSエージをMaxAgeに設定して再フラッディングすることにより、LSAをルーティングドメインからフラッシュする必要があります（セクション14.1を参照）。
o A routing table entry associated with a configured virtual link has changed. The destination of such a routing table entry is an area border router. The change indicates a modification to the virtual link's cost or viability.
o 設定された仮想リンクに関連付けられているルーティングテーブルエントリが変更されました。このようなルーティングテーブルエントリの宛先は、エリア境界ルーターです。変更は、仮想リンクのコストまたは実行可能性の変更を示します。
If the entry indicates that the area border router is newly reachable, the corresponding virtual link is now operational. An InterfaceUp event should be generated for the virtual link, which will cause a virtual adjacency to begin to form (see Section 10.3). At this time the virtual link's IP interface address and the virtual neighbor's Neighbor IP address are also calculated.
エントリがエリア境界ルーターに新たに到達可能であることを示している場合、対応する仮想リンクが動作しています。仮想リンクに対してInterfaceUpイベントを生成する必要があります。これにより、仮想隣接が形成され始めます（セクション10.3を参照）。このとき、仮想リンクのIPインターフェイスアドレスと仮想ネイバーのネイバーIPアドレスも計算されます。
If the entry indicates that the area border router is no longer reachable, the virtual link and its associated adjacency should be destroyed. This means an InterfaceDown event should be generated for the associated virtual link.
エントリがエリア境界ルーターに到達できなくなったことを示している場合は、仮想リンクとそれに関連付けられた隣接関係を破棄する必要があります。これは、関連付けられた仮想リンクに対してInterfaceDownイベントを生成する必要があることを意味します。
If the cost of the entry has changed, and there is a fully established virtual adjacency, a new router-LSA for the backbone must be originated. This in turn may cause further routing table changes.
エントリのコストが変更され、完全に確立された仮想隣接がある場合、バックボーンの新しいルーターLSAを発信する必要があります。これにより、ルーティングテーブルがさらに変更される可能性があります。
16.8. Equal-cost multipath
16.8. 等コストマルチパス
The OSPF protocol maintains multiple equal-cost routes to all destinations. This can be seen in the steps used above to calculate the routing table, and in the definition of the routing table structure.
OSPFプロトコルは、すべての宛先への複数の等価コストルートを維持します。これは、ルーティングテーブルを計算するために上記で使用した手順と、ルーティングテーブル構造の定義で確認できます。
Each one of the multiple routes will be of the same type (intra-area, inter-area, type 1 external or type 2 external), cost, and will have the same associated area. However, each route may specify a separate next hop and Advertising router.
複数のルートのそれぞれは、同じタイプ（エリア内、エリア間、タイプ1外部またはタイプ2外部）、コストであり、同じ関連エリアがあります。ただし、各ルートは別々のネクストホップとアドバタイズルーターを指定できます。
There is no requirement that a router running OSPF keep track of all possible equal-cost routes to a destination. An implementation may choose to keep only a fixed number of routes to any given destination. This does not affect any of the algorithms presented in this specification.
OSPFを実行しているルータが、宛先へのすべての可能な等価コストルートを追跡する必要はありません。実装では、特定の宛先へのルートを一定数だけ保持することを選択できます。これは、この仕様で提示されているアルゴリズムには影響しません。
Footnotes
脚注
[1]The graph's vertices represent either routers, transit networks, or stub networks. Since routers may belong to multiple areas, it is not possible to color the graph's vertices.
[1]グラフの頂点は、ルーター、トランジットネットワーク、またはスタブネットワークのいずれかを表します。ルーターは複数の領域に属している可能性があるため、グラフの頂点に色を付けることはできません。
[2]It is possible for all of a router's interfaces to be unnumbered point-to-point links. In this case, an IP address must be assigned to the router. This address will then be advertised in the router's router-LSA as a host route.
[2]ルーターのすべてのインターフェイスを、番号なしのポイントツーポイントリンクにすることができます。この場合、IPアドレスをルーターに割り当てる必要があります。このアドレスは、ルーターのルーターLSAでホストルートとしてアドバタイズされます。
[3]Note that in these cases both interfaces, the non-virtual and the virtual, would have the same IP address.
[3]これらの場合、非仮想と仮想の両方のインターフェイスが同じIPアドレスを持つことに注意してください。
[4]Note that no host route is generated for, and no IP packets can be addressed to, interfaces to unnumbered point-to-point networks. This is regardless of such an interface's state.
[4]番号付けされていないポイントツーポイントネットワークへのインターフェイスには、ホストルートが生成されず、IPパケットをアドレス指定できないことに注意してください。これは、そのようなインターフェースの状態に関係ありません。
[5]It is instructive to see what happens when the Designated Router for the network crashes. Call the Designated Router for the network RT1, and the Backup Designated Router RT2. If Router RT1 crashes (or maybe its interface to the network dies), the other routers on the network will detect RT1's absence within RouterDeadInterval seconds. All routers may not detect this at precisely the same time; the routers that detect RT1's absence before RT2 does will, for a time, select RT2 to be both Designated Router and Backup Designated Router. When RT2 detects that RT1 is gone it will move itself to Designated Router. At this time, the remaining router having highest Router Priority will be selected as Backup Designated Router.
[5]ネットワークの指定ルーターがクラッシュしたときに何が起こるかを確認することは有益です。ネットワークRT1の指定ルーターとバックアップ指定ルーターRT2を呼び出します。ルーターRT1がクラッシュした場合（またはネットワークへのインターフェースが停止した場合）、ネットワーク上の他のルーターがRouterDeadInterval秒以内にRT1の不在を検出します。すべてのルーターがこれを正確に同時に検出するわけではありません。 RT2の前にRT1の不在を検出するルーターは、しばらくの間、RT2を指定ルーターとバックアップ指定ルーターの両方として選択します。 RT2は、RT1がなくなったことを検出すると、指定ルーターに移動します。このとき、ルータプライオリティが最も高い残りのルータがバックアップ指定ルータとして選択されます。
[6]On point-to-point networks, the lower level protocols indicate whether the neighbor is up and running. Likewise, existence of the neighbor on virtual links is indicated by the routing table calculation. However, in both these cases, the Hello Protocol is still used. This ensures that communication between the neighbors is bidirectional, and that each of the neighbors has a functioning routing protocol layer.
[6]ポイントツーポイントネットワークでは、下位レベルのプロトコルは、ネイバーが稼働しているかどうかを示します。同様に、仮想リンク上のネイバーの存在は、ルーティングテーブルの計算によって示されます。ただし、どちらの場合も、Helloプロトコルが引き続き使用されます。これにより、ネイバー間の通信が双方向であり、ネイバーのそれぞれに機能するルーティングプロトコルレイヤがあることが保証されます。
[7]When the identity of the Designated Router is changing, it may be quite common for a neighbor in this state to send the router a Database Description packet; this means that there is some momentary disagreement on the Designated Router's identity.
[7]代表ルータのアイデンティティが変化しているとき、この状態のネイバーがルータにデータベース記述パケットを送信することは非常に一般的かもしれません。これは、代表ルーターのIDに一時的な不一致があることを意味します。
[8]Note that it is possible for a router to resynchronize any of its fully established adjacencies by setting the adjacency's state back to ExStart. This will cause the other end of the adjacency to process a SeqNumberMismatch event, and therefore to also go back to ExStart state.
[8]隣接の状態をExStartに戻すことにより、ルーターが完全に確立された隣接のいずれかを再同期できることに注意してください。これにより、隣接のもう一方の端でSeqNumberMismatchイベントが処理されるため、ExStart状態にも戻ります。
[9]The address space of IP networks and the address space of OSPF Router IDs may overlap. That is, a network may have an IP address which is identical (when considered as a 32-bit number) to some router's Router ID.
[9] IPネットワークのアドレススペースとOSPFルーターIDのアドレススペースは重複する場合があります。つまり、ネットワークには、一部のルーターのルーターIDと（32ビットの数値と見なした場合）同一のIPアドレスがある場合があります。
[10]"Discard" entries are necessary to ensure that route summarization at area boundaries will not cause packet looping.
[10]「破棄」エントリは、エリア境界でのルート集約によってパケットループが発生しないようにするために必要です。
[11]It is assumed that, for two different address ranges matching the destination, one range is more specific than the other. Non-contiguous subnet masks can be configured to violate this assumption. Such subnet mask configurations cannot be handled by the OSPF protocol.
[11]宛先に一致する2つの異なるアドレス範囲について、一方の範囲が他方よりも具体的であると想定されます。不連続なサブネットマスクは、この仮定に違反するように構成できます。このようなサブネットマスク構成は、OSPFプロトコルでは処理できません。
[12]MaxAgeDiff is an architectural constant. It indicates the maximum dispersion of ages, in seconds, that can occur for a single LSA instance as it is flooded throughout the routing domain. If two LSAs differ by more than this, they are assumed to be different instances of the same LSA. This can occur when a router restarts and loses track of the LSA's previous LS sequence number. See Section 13.4 for more details.
[12] MaxAgeDiffは、アーキテクチャ上の定数です。これは、ルーティングドメイン全体にフラッディングされるときに、単一のLSAインスタンスで発生する可能性のある経過時間の最大分散を秒単位で示します。 2つのLSAがこれ以上異なる場合、それらは同じLSAの異なるインスタンスであると想定されます。これは、ルーターが再起動し、LSAの以前のLSシーケンス番号を追跡できなくなった場合に発生する可能性があります。詳細については、セクション13.4を参照してください。
[13]When two LSAs have different LS checksums, they are assumed to be separate instances. This can occur when a router restarts, and loses track of the LSA's previous LS sequence number. In the case where the two LSAs have the same LS sequence number, it is not possible to determine which LSA is actually newer. However, if the wrong LSA is accepted as newer, the originating router will simply originate another instance. See Section 13.4 for further details.
[13] 2つのLSAに異なるLSチェックサムがある場合、それらは別個のインスタンスであると見なされます。これは、ルーターが再起動したときに発生し、LSAの以前のLSシーケンス番号を追跡できなくなります。 2つのLSAが同じLSシーケンス番号を持つ場合、どのLSAが実際に新しいかを判別することはできません。ただし、間違ったLSAが新しいものとして受け入れられる場合、発信元ルーターは単に別のインスタンスを発信します。詳細については、セクション13.4を参照してください。
[14]There is one instance where a lookup must be done based on partial information. This is during the routing table calculation, when a network-LSA must be found based solely on its Link State ID.
[14]部分的な情報に基づいてルックアップを実行しなければならない場合があります。これは、ルーティングテーブルの計算中です。ネットワークLSAは、リンク状態IDのみに基づいて検索する必要があります。
The lookup in this case is still well defined, since no two network-LSAs can have the same Link State ID.
この場合の検索は、2つのネットワークLSAが同じリンク状態IDを持つことができないため、適切に定義されています。
[15]This is the way RFC 1583 specified point-to-point representation. It has three advantages: a) it does not require allocating a subnet to the point-to-point link, b) it tends to bias the routing so that packets destined for the point-to-point interface will actually be received over the interface (which is useful for diagnostic purposes) and c) it allows network bootstrapping of a neighbor, without requiring that the bootstrap program contain an OSPF implementation.
[15]これは、RFC 1583がポイントツーポイント表現を指定した方法です。これには3つの利点があります。a）ポイントツーポイントリンクにサブネットを割り当てる必要がない、b）ルーティングにバイアスがかかる傾向があるため、ポイントツーポイントインターフェイス宛てのパケットが実際にインターフェイス経由で受信される（診断に役立ちます）およびc）ブートストラッププログラムにOSPF実装が含まれていることを必要とせずに、ネイバーのネットワークブートストラップを可能にします。
[16]This is the more traditional point-to-point representation used by protocols such as RIP.
[16]これは、RIPなどのプロトコルで使用される、より伝統的なポイントツーポイント表現です。
[17]This clause covers the case: Inter-area routes are not summarized to the backbone. This is because inter-area routes are always associated with the backbone area.
[17]この条項はケースをカバーします：エリア間ルートはバックボーンに要約されません。これは、エリア間ルートが常にバックボーンエリアに関連付けられているためです。
[18]This clause is only invoked when a non-backbone Area A supports transit data traffic (i.e., has TransitCapability set to TRUE). For example, in the area configuration of Figure 6, Area 2 can support transit traffic due to the configured virtual link between Routers RT10 and RT11. As a result, Router RT11 need only originate a single summary-LSA into Area 2 (having the collapsed destination N9- N11,H1), since all of Router RT11's other eligible routes have next hops belonging to Area 2 itself (and as such only need be advertised by other area border routers; in this case, Routers RT10 and RT7).
[18]この句は、非バックボーンエリアAがトランジットデータトラフィックをサポートしている（つまり、TransitCapabilityがTRUEに設定されている）場合にのみ呼び出されます。たとえば、図6のエリア構成では、エリア2は、ルーターRT10とRT11の間に構成された仮想リンクにより、通過トラフィックをサポートできます。その結果、ルーターRT11の他の適格なルートのすべてにエリア2自体に属するネクストホップがあるため、ルーターRT11はエリア2（折りたたまれた宛先N9- N11、H1を持つ）に単一のサマリーLSAを発信するだけで済みます他のエリア境界ルーター（この場合、ルーターRT10およびRT7）によって通知する必要があります。
[19]By keeping more information in the routing table, it is possible for an implementation to recalculate the shortest path tree for only a single area. In fact, there are incremental algorithms that allow an implementation to recalculate only a portion of a single area's shortest path tree [Ref1]. However, these algorithms are beyond the scope of this specification.
[19]ルーティングテーブルにより多くの情報を保持することにより、実装は単一エリアのみの最短パスツリーを再計算することが可能です。実際、インプリメンテーションで単一エリアの最短パスツリーの一部のみを再計算できるようにするインクリメンタルアルゴリズムがあります[参照1]。ただし、これらのアルゴリズムはこの仕様の範囲を超えています。
[20]This is how the Link state request list is emptied, which eventually causes the neighbor state to transition to Full. See Section 10.9 for more details.
[20]これは、リンク状態要求リストが空になる方法で、最終的にネイバー状態がフルに移行します。詳細については、セクション10.9を参照してください。
[21]It should be a relatively rare occurrence for an LSA's LS age to reach MaxAge in this fashion. Usually, the LSA will be replaced by a more recent instance before it ages out.
[21] LSAのLS年齢がこのようにMaxAgeに達するのは、比較的まれなことです。通常、LSAは、期限切れになる前に、より新しいインスタンスに置き換えられます。
[22]Strictly speaking, because of equal-cost multipath, the algorithm does not create a tree. We continue to use the "tree" terminology because that is what occurs most often in the existing literature.
[22]厳密に言うと、等コストマルチパスのため、アルゴリズムはツリーを作成しません。 「ツリー」という用語は、既存の文献で最も頻繁に使用されるため、引き続き使用します。
[23]Note that the presence of any link back to V is sufficient; it need not be the matching half of the link under consideration from V to W. This is enough to ensure that, before data traffic flows between a pair of neighboring routers, their link state databases will be synchronized.
[23] Vに戻るリンクがあれば十分であることに注意してください。これは、VからWへの考慮中のリンクの一致する半分である必要はありません。これは、隣接するルーターのペア間でデータトラフィックが流れる前に、リンク状態データベースが同期されることを保証するのに十分です。
[24]When the forwarding address is non-zero, it should point to a router belonging to another Autonomous System. See Section 12.4.4 for more details.
[24]転送アドレスがゼロ以外の場合、別の自律システムに属するルーターを指す必要があります。詳細については、セクション12.4.4を参照してください。
References
参考文献
[Ref1] McQuillan, J., I. Richer and E. Rosen, "ARPANET Routing Algorithm Improvements", BBN Technical Report 3803, April 1978.
[参照1] McQuillan、J.、I。RicherおよびE. Rosen、「ARPANET Routing Algorithm Improvements」、BBN Technical Report 3803、1978年4月。
[Ref2] Digital Equipment Corporation, "Information processing systems -- Data communications -- Intermediate System to Intermediate System Intra-Domain Routing Protocol", October 1987.
[参照2] Digital Equipment Corporation、「情報処理システム-データ通信-中間システムから中間システムドメイン内ルーティングプロトコル」、1987年10月。
[Ref3] McQuillan, J., et.al., "The New Routing Algorithm for the ARPANET", IEEE Transactions on Communications, May 1980.
[参照3] McQuillan、J。、他、「ARPANETの新しいルーティングアルゴリズム」、IEEE Transactions on Communications、1980年5月。
[Ref4] Perlman, R., "Fault-Tolerant Broadcast of Routing Information", Computer Networks, December 1983.
[参照4] Perlman、R。、「ルーティング情報のフォールトトレラントブロードキャスト」、コンピュータネットワーク、1983年12月。
[Ref5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[参照5] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[Ref6] McKenzie, A., "ISO Transport Protocol specification ISO DP 8073", RFC 905, April 1984.
[参照6]マッケンジーA。、「ISOトランスポートプロトコル仕様ISO DP 8073」、RFC 905、1984年4月。
[Ref7] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, May 1988.
[参照7] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1988年5月。
[Ref8] McCloghrie, K., and M. Rose, "Management Information Base for network management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991.
[参照8] McCloghrie、K。、およびM. Rose、「TCP / IPベースのインターネットのネットワーク管理のための管理情報ベース：MIB-II」、STD 17、RFC 1213、1991年3月。
[Ref9] Moy, J., "OSPF Version 2", RFC 1583, March 1994.
[参照9] Moy、J。、「OSPFバージョン2」、RFC 1583、1994年3月。
[Ref10] Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC1519, September 1993.
[Ref10] Fuller、V.、T。Li、J。Yu、およびK. Varadhan、「Classless Inter-Domain Routing（CIDR）：a Address Assignment and Aggregation Strategy」、RFC1519、1993年9月。
[Ref11] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[参照11] Reynolds、J。、およびJ. Postel、「Assigned Numbers」、STD 2、RFC 1700、1994年10月。
[Ref12] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, July 1992.
[参照12] Almquist、P。、「インターネットプロトコルスイートのサービスの種類」、RFC 1349、1992年7月。
[Ref13] Leiner, B., et.al., "The DARPA Internet Protocol Suite", DDN Protocol Handbook, April 1985.
[Ref13] Leiner、B.、et.al.、 "The DARPA Internet Protocol Suite"、DDN Protocol Handbook、April 1985。
[Ref14] Bradley, T., and C. Brown, "Inverse Address Resolution Protocol", RFC 1293, January 1992.
[参照14] Bradley、T。、およびC. Brown、「Inverse Address Resolution Protocol」、RFC 1293、1992年1月。
[Ref15] deSouza, O., and M. Rodrigues, "Guidelines for Running OSPF Over Frame Relay Networks", RFC 1586, March 1994.
[参照15] deSouza、O。、およびM. Rodrigues、「OSPF Over Frame Relay Networksを実行するためのガイドライン」、RFC 1586、1994年3月。
[Ref16] Bellovin, S., "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Volume 19, Number 2, pp. 32-38, April 1989.
[Ref16] Bellovin、S。、「TCP / IPプロトコルスイートのセキュリティ問題」、ACM Computer Communications Review、Volume 19、Number 2、32-38ページ、1989年4月。
[Ref17] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[参照17] Rivest、R。、「The MD5 Message-Digest Algorithm」、RFC 1321、1992年4月。
[Ref18] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
[参照18] Moy、J。、「OSPFへのマルチキャスト拡張」、RFC 1584、1994年3月。
[Ref19] Coltun, R., and V. Fuller, "The OSPF NSSA Option", RFC 1587, March 1994.
[Ref19] Coltun、R。、およびV. Fuller、「OSPF NSSAオプション」、RFC 1587、1994年3月。
[Ref20] Ferguson, D., "The OSPF External Attributes LSA", work in progress.
[参照20]ファーガソンD。、「OSPF外部属性LSA」は進行中です。
[Ref21] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995.
[Ref21] Moy、J。、「Extending OSPF to Support Demand Circuits」、RFC 1793、1995年4月。
[Ref22] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[参照22] Mogul、J。、およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[Ref23] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[参照23] Rekhter、Y。、およびT. Li、「A Border Gateway Protocol 4（BGP-4）」、RFC 1771、1995年3月。
[Ref24] Hinden, R., "Internet Routing Protocol Standardization Criteria", BBN, October 1991.
[参照24] Hinden、R.、「インターネットルーティングプロトコル標準化基準」、BBN、1991年10月。
[Ref25] Moy, J., "OSPF Version 2", RFC 2178, July 1997.
[参照25] Moy、J。、「OSPFバージョン2」、RFC 2178、1997年7月。
[Ref26] Rosen, E., "Vulnerabilities of Network Control Protocols: An Example", Computer Communication Review, July 1981.
[参照26]ローゼン、E。、「ネットワーク制御プロトコルの脆弱性：例」、コンピュータ通信レビュー、1981年7月。
A. OSPF data formats
A. OSPFデータ形式
This appendix describes the format of OSPF protocol packets and OSPF LSAs. The OSPF protocol runs directly over the IP network layer. Before any data formats are described, the details of the OSPF encapsulation are explained.
この付録では、OSPFプロトコルパケットとOSPF LSAの形式について説明します。 OSPFプロトコルは、IPネットワーク層で直接実行されます。データ形式について説明する前に、OSPFカプセル化の詳細について説明します。
Next the OSPF Options field is described. This field describes various capabilities that may or may not be supported by pieces of the OSPF routing domain. The OSPF Options field is contained in OSPF Hello packets, Database Description packets and in OSPF LSAs.
次に、OSPFオプションフィールドについて説明します。このフィールドは、OSPFルーティングドメインの一部によってサポートされる場合とサポートされない場合があるさまざまな機能について説明します。 OSPFオプションフィールドは、OSPF Helloパケット、データベース記述パケット、およびOSPF LSAに含まれています。
OSPF packet formats are detailed in Section A.3. A description of OSPF LSAs appears in Section A.4.
OSPFパケット形式の詳細は、セクションA.3を参照してください。 OSPF LSAの説明は、セクションA.4にあります。
A.1 Encapsulation of OSPF packets
A.1 OSPFパケットのカプセル化
OSPF runs directly over the Internet Protocol's network layer. OSPF packets are therefore encapsulated solely by IP and local data-link headers.
OSPFは、インターネットプロトコルのネットワーク層で直接実行されます。したがって、OSPFパケットは、IPおよびローカルデータリンクヘッダーによってのみカプセル化されます。
OSPF does not define a way to fragment its protocol packets, and depends on IP fragmentation when transmitting packets larger than the network MTU. If necessary, the length of OSPF packets can be up to 65,535 bytes (including the IP header). The OSPF packet types that are likely to be large (Database Description Packets, Link State Request, Link State Update, and Link State Acknowledgment packets) can usually be split into several separate protocol packets, without loss of functionality. This is recommended; IP fragmentation should be avoided whenever possible. Using this reasoning, an attempt should be made to limit the sizes of OSPF packets sent over virtual links to 576 bytes unless Path MTU Discovery is being performed (see [Ref22]).
OSPFは、プロトコルパケットをフラグメント化する方法を定義せず、ネットワークMTUよりも大きいパケットを送信する場合、IPフラグメンテーションに依存します。必要に応じて、OSPFパケットの長さは65,535バイトまで可能です（IPヘッダーを含む）。大きくなる可能性が高いOSPFパケットタイプ（データベース記述パケット、リンク状態要求、リンク状態更新、およびリンク状態確認パケット）は、通常、機能を失うことなく、いくつかの個別のプロトコルパケットに分割できます。これが推奨されます。 IPフラグメンテーションは、可能な限り回避する必要があります。この推論を使用して、Path MTU Discoveryが実行されていない限り、仮想リンクを介して送信されるOSPFパケットのサイズを576バイトに制限する試みを行う必要があります（[Ref22]を参照）。
The other important features of OSPF's IP encapsulation are:
OSPFのIPカプセル化の他の重要な機能は次のとおりです。
o Use of IP multicast. Some OSPF messages are multicast, when sent over broadcast networks. Two distinct IP multicast addresses are used. Packets sent to these multicast addresses should never be forwarded; they are meant to travel a single hop only. To ensure that these packets will not travel multiple hops, their IP TTL must be set to 1.
o IPマルチキャストの使用。一部のOSPFメッセージは、ブロードキャストネットワーク経由で送信されるとマルチキャストされます。 2つの異なるIPマルチキャストアドレスが使用されます。これらのマルチキャストアドレスに送信されたパケットは転送しないでください。彼らはシングルホップだけを旅行することを意図しています。これらのパケットが複数のホップを通過しないようにするには、IP TTLを1に設定する必要があります。
AllSPFRouters This multicast address has been assigned the value 224.0.0.5. All routers running OSPF should be prepared to receive packets sent to this address. Hello packets are always sent to this destination. Also, certain OSPF protocol packets are sent to this address during the flooding procedure.
AllSPFRoutersこのマルチキャストアドレスには、値224.0.0.5が割り当てられています。 OSPFを実行しているすべてのルーターは、このアドレスに送信されたパケットを受信できるように準備する必要があります。 Helloパケットは常にこの宛先に送信されます。また、フラッディング手順中に、特定のOSPFプロトコルパケットがこのアドレスに送信されます。
AllDRouters This multicast address has been assigned the value 224.0.0.6. Both the Designated Router and Backup Designated Router must be prepared to receive packets destined to this address. Certain OSPF protocol packets are sent to this address during the flooding procedure.
AllDRoutersこのマルチキャストアドレスには、値224.0.0.6が割り当てられています。指定ルーターとバックアップ指定ルーターの両方で、このアドレス宛のパケットを受信できるように準備する必要があります。フラッディング手順中に、特定のOSPFプロトコルパケットがこのアドレスに送信されます。
o OSPF is IP protocol number 89. This number has been registered with the Network Information Center. IP protocol number assignments are documented in [Ref11].
o OSPFはIPプロトコル番号89です。この番号はネットワークインフォメーションセンターに登録されています。 IPプロトコル番号の割り当ては[Ref11]に記載されています。
o All OSPF routing protocol packets are sent using the normal service TOS value of binary 0000 defined in [Ref12].
o すべてのOSPFルーティングプロトコルパケットは、[Ref12]で定義されているバイナリ0000の通常のサービスTOS値を使用して送信されます。
o Routing protocol packets are sent with IP precedence set to Internetwork Control. OSPF protocol packets should be given precedence over regular IP data traffic, in both sending and receiving. Setting the IP precedence field in the IP header to Internetwork Control [Ref5] may help implement this objective.
o ルーティングプロトコルパケットは、IP precedenceをInternetwork Controlに設定して送信されます。 OSPFプロトコルパケットは、送信と受信の両方で、通常のIPデータトラフィックよりも優先される必要があります。 IPヘッダーのIP precedenceフィールドをInternetwork Control [Ref5]に設定すると、この目的の実装に役立つ場合があります。
A.2 The Options field
A.2オプションフィールド
The OSPF Options field is present in OSPF Hello packets, Database Description packets and all LSAs. The Options field enables OSPF routers to support (or not support) optional capabilities, and to communicate their capability level to other OSPF routers. Through this mechanism routers of differing capabilities can be mixed within an OSPF routing domain.
OSPFオプションフィールドは、OSPF Helloパケット、データベース記述パケット、およびすべてのLSAにあります。 [オプション]フィールドを使用すると、OSPFルーターはオプション機能をサポートする（またはサポートしない）ことができ、その機能レベルを他のOSPFルーターと通信できます。このメカニズムにより、機能の異なるルーターをOSPFルーティングドメイン内で混在させることができます。
When used in Hello packets, the Options field allows a router to reject a neighbor because of a capability mismatch. Alternatively, when capabilities are exchanged in Database Description packets a router can choose not to forward certain LSAs to a neighbor because of its reduced functionality. Lastly, listing capabilities in LSAs allows routers to forward traffic around reduced functionality routers, by excluding them from parts of the routing table calculation.
オプションフィールドをHelloパケットで使用すると、ルータは機能の不一致のためにネイバーを拒否できます。または、データベース記述パケットで機能が交換されると、機能が低下するため、ルーターは特定のLSAをネイバーに転送しないことを選択できます。最後に、LSAの機能を一覧表示すると、ルーターはルーティングテーブルの計算の一部から除外することにより、機能が低下したルーターの周囲にトラフィックを転送できます。
Five bits of the OSPF Options field have been assigned, although only one (the E-bit) is described completely by this memo. Each bit is described briefly below. Routers should reset (i.e. clear) unrecognized bits in the Options field when sending Hello packets or Database Description packets and when originating LSAs. Conversely, routers encountering unrecognized Option bits in received Hello Packets, Database Description packets or LSAs should ignore the capability and process the packet/LSA normally.
OSPFオプションフィールドの5ビットが割り当てられていますが、このメモでは1ビット（Eビット）だけが完全に説明されています。以下に、各ビットについて簡単に説明します。ルータは、Helloパケットまたはデータベース記述パケットを送信するとき、およびLSAを発信するときに、オプションフィールドの認識されないビットをリセット（つまり、クリア）する必要があります。逆に、受信したHelloパケット、データベース記述パケット、またはLSAで認識されないオプションビットに遭遇したルーターは、機能を無視して、パケット/ LSAを通常どおり処理する必要があります。
+------------------------------------+
| * | * | DC | EA | N/P | MC | E | * |
+------------------------------------+
The Options field
オプションフィールド
E-bit This bit describes the way AS-external-LSAs are flooded, as described in Sections 3.6, 9.5, 10.8 and 12.1.2 of this memo.
Eビットこのビットは、このメモのセクション3.6、9.5、10.8、および12.1.2で説明されているように、AS外部LSAがフラッディングされる方法を説明します。
MC-bit This bit describes whether IP multicast datagrams are forwarded according to the specifications in [Ref18].
MCビットこのビットは、[Ref18]の仕様に従ってIPマルチキャストデータグラムを転送するかどうかを示します。
N/P-bit This bit describes the handling of Type-7 LSAs, as specified in [Ref19].
N / Pビットこのビットは、[Ref19]で指定されているType-7 LSAの処理を記述します。
EA-bit This bit describes the router's willingness to receive and forward External-Attributes-LSAs, as specified in [Ref20].
EAビットこのビットは、[Ref20]で指定されているように、External-Attributes-LSAを受信して転送するルーターの意思を示します。
DC-bit This bit describes the router's handling of demand circuits, as specified in [Ref21].
DCビットこのビットは、[Ref21]で指定されている、ルーターによるデマンド回線の処理を記述します。
A.3 OSPF Packet Formats
A.3 OSPFパケット形式
There are five distinct OSPF packet types. All OSPF packet types begin with a standard 24 byte header. This header is described first. Each packet type is then described in a succeeding section. In these sections each packet's division into fields is displayed, and then the field definitions are enumerated.
5つの異なるOSPFパケットタイプがあります。すべてのOSPFパケットタイプは、標準の24バイトヘッダーで始まります。このヘッダーを最初に説明します。次に、各パケットタイプについて、次のセクションで説明します。これらのセクションでは、各パケットのフィールドへの分割が表示され、次にフィールド定義が列挙されます。
All OSPF packet types (other than the OSPF Hello packets) deal with lists of LSAs. For example, Link State Update packets implement the flooding of LSAs throughout the OSPF routing domain. Because of this, OSPF protocol packets cannot be parsed unless the format of LSAs is also understood. The format of LSAs is described in Section A.4.
（OSPF Helloパケット以外の）すべてのOSPFパケットタイプは、LSAのリストを処理します。たとえば、リンク状態更新パケットは、OSPFルーティングドメイン全体にLSAのフラッディングを実装します。このため、LSAの形式も理解していないと、OSPFプロトコルパケットを解析できません。 LSAのフォーマットについては、セクションA.4で説明します。
The receive processing of OSPF packets is detailed in Section 8.2. The sending of OSPF packets is explained in Section 8.1.
OSPFパケットの受信処理については、セクション8.2で詳しく説明しています。 OSPFパケットの送信については、セクション8.1で説明しています。
A.3.1 The OSPF packet header
A.3.1 OSPFパケットヘッダー
Every OSPF packet starts with a standard 24 byte header. This header contains all the information necessary to determine whether the packet should be accepted for further processing. This determination is described in Section 8.2 of the specification.
すべてのOSPFパケットは、標準の24バイトのヘッダーで始まります。このヘッダーには、パケットをさらに処理するために受け入れる必要があるかどうかを判断するために必要なすべての情報が含まれています。この決定は、仕様のセクション8.2で説明されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | Type | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version # The OSPF version number. This specification documents version 2 of the protocol.
バージョン＃OSPFバージョン番号。この仕様には、プロトコルのバージョン2が記載されています。
Type The OSPF packet types are as follows. See Sections A.3.2 through A.3.6 for details.
タイプOSPFパケットのタイプは次のとおりです。詳細については、セクションA.3.2からA.3.6を参照してください。
Type Description
________________________________
1 Hello
2 Database Description
3 Link State Request
4 Link State Update
5 Link State Acknowledgment
Packet length The length of the OSPF protocol packet in bytes. This length includes the standard OSPF header.
パケット長OSPFプロトコルパケットの長さ（バイト単位）。この長さには、標準のOSPFヘッダーが含まれます。
Router ID The Router ID of the packet's source.
ルーターIDパケットの送信元のルーターID。
Area ID A 32 bit number identifying the area that this packet belongs to. All OSPF packets are associated with a single area. Most travel a single hop only. Packets travelling over a virtual link are labelled with the backbone Area ID of 0.0.0.0.
Area IDこのパケットが属するエリアを識別する32ビットの番号。すべてのOSPFパケットは単一のエリアに関連付けられています。ほとんどの場合、1つのホップのみを移動します。仮想リンク上を移動するパケットは、0.0.0.0のバックボーンエリアIDでラベル付けされます。
Checksum The standard IP checksum of the entire contents of the packet, starting with the OSPF packet header but excluding the 64-bit authentication field. This checksum is calculated as the 16-bit one's complement of the one's complement sum of all the 16-bit words in the packet, excepting the authentication field. If the packet's length is not an integral number of 16-bit words, the packet is padded with a byte of zero before checksumming. The checksum is considered to be part of the packet authentication procedure; for some authentication types the checksum calculation is omitted.
チェックサムパケットの内容全体の標準IPチェックサム。OSPFパケットヘッダーから始まり、64ビット認証フィールドを除きます。このチェックサムは、認証フィールドを除く、パケット内のすべての16ビットワードの1の補数の合計の16ビットの1の補数として計算されます。パケットの長さが16ビットワードの整数でない場合、チェックサムの前にパケットにゼロのバイトが埋め込まれます。チェックサムは、パケット認証手順の一部と見なされます。一部の認証タイプでは、チェックサム計算が省略されます。
AuType Identifies the authentication procedure to be used for the packet. Authentication is discussed in Appendix D of the specification. Consult Appendix D for a list of the currently defined authentication types.
AuTypeパケットに使用される認証手順を識別します。認証については、仕様の付録Dで説明しています。現在定義されている認証タイプのリストについては、付録Dを参照してください。
Authentication A 64-bit field for use by the authentication scheme. See Appendix D for details.
認証認証方式で使用する64ビットのフィールド。詳細については、付録Dを参照してください。
A.3.2 The Hello packet
A.3.2 Helloパケット
Hello packets are OSPF packet type 1. These packets are sent periodically on all interfaces (including virtual links) in order to establish and maintain neighbor relationships. In addition, Hello Packets are multicast on those physical networks having a multicast or broadcast capability, enabling dynamic discovery of neighboring routers.
HelloパケットはOSPFパケットタイプ1です。これらのパケットは、ネイバー関係を確立および維持するために、すべてのインターフェイス（仮想リンクを含む）で定期的に送信されます。さらに、Helloパケットは、マルチキャストまたはブロードキャスト機能を備えた物理ネットワーク上でマルチキャストされ、近隣ルーターの動的な発見を可能にします。
All routers connected to a common network must agree on certain parameters (Network mask, HelloInterval and RouterDeadInterval). These parameters are included in Hello packets, so that differences can inhibit the forming of neighbor relationships. A detailed explanation of the receive processing for Hello packets is presented in Section 10.5. The sending of Hello packets is covered in Section 9.5.
共通ネットワークに接続されているすべてのルーターは、特定のパラメーター（ネットワークマスク、HelloInterval、RouterDeadInterval）について合意する必要があります。これらのパラメータはhelloパケットに含まれているため、違いが近隣関係の形成を阻害する可能性があります。 Helloパケットの受信処理の詳細な説明はセクション10.5にあります。 Helloパケットの送信については、セクション9.5で説明しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 1 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | Options | Rtr Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RouterDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Designated Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Designated Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Network mask The network mask associated with this interface. For example, if the interface is to a class B network whose third byte is used for subnetting, the network mask is 0xffffff00.
ネットワークマスクこのインターフェイスに関連付けられているネットワークマスク。たとえば、インターフェースが3番目のバイトがサブネット化に使用されるクラスBネットワークに対するものである場合、ネットワークマスクは0xffffff00です。
Options The optional capabilities supported by the router, as documented in Section A.2.
オプションセクションA.2で説明されている、ルーターがサポートするオプション機能。
HelloInterval The number of seconds between this router's Hello packets.
HelloIntervalこのルーターのHelloパケット間の秒数。
Rtr Pri This router's Router Priority. Used in (Backup) Designated Router election. If set to 0, the router will be ineligible to become (Backup) Designated Router.
Rtr Priこのルーターのルーター優先度。 （バックアップ）指定ルーターの選択で使用されます。 0に設定した場合、ルーターは（バックアップ）指定ルーターになる資格がなくなります。
RouterDeadInterval The number of seconds before declaring a silent router down.
RouterDeadIntervalサイレントルーターのダウンを宣言するまでの秒数。
Designated Router The identity of the Designated Router for this network, in the view of the sending router. The Designated Router is identified here by its IP interface address on the network. Set to 0.0.0.0 if there is no Designated Router.
代表ルーター送信ルーターから見た、このネットワークの代表ルーターのID。ここでは、代表ルータはネットワーク上のIPインターフェースアドレスによって識別されます。指定ルーターがない場合は、0.0.0.0に設定します。
Backup Designated Router The identity of the Backup Designated Router for this network, in the view of the sending router. The Backup Designated Router is identified here by its IP interface address on the network. Set to 0.0.0.0 if there is no Backup Designated Router.
バックアップ指定ルーター送信ルーターから見た、このネットワークのバックアップ指定ルーターのID。バックアップ指定ルーターは、ここではネットワーク上のIPインターフェースアドレスによって識別されます。バックアップ指定ルーターがない場合は、0.0.0.0に設定します。
Neighbor The Router IDs of each router from whom valid Hello packets have been seen recently on the network. Recently means in the last RouterDeadInterval seconds.
Neighbor有効なHelloパケットがネットワーク上で最近見られた各ルーターのルーターID。最近の最後のRouterDeadInterval秒を意味します。
A.3.3 The Database Description packet
A.3.3データベース記述パケット
Database Description packets are OSPF packet type 2. These packets are exchanged when an adjacency is being initialized. They describe the contents of the link-state database. Multiple packets may be used to describe the database. For this purpose a poll-response procedure is used. One of the routers is designated to be the master, the other the slave. The master sends Database Description packets (polls) which are acknowledged by Database Description packets sent by the slave (responses). The responses are linked to the polls via the packets' DD sequence numbers.
データベース記述パケットはOSPFパケットタイプ2です。これらのパケットは、隣接が初期化されているときに交換されます。リンクステートデータベースの内容を記述します。データベースを記述するために複数のパケットが使用される場合があります。この目的のために、ポーリング応答手順が使用されます。ルーターの1つはマスターに指定され、もう1つはスレーブに指定されます。マスターは、スレーブによって送信されたデータベース記述パケット（応答）によって確認応答されるデータベース記述パケット（ポーリング）を送信します。応答は、パケットのDDシーケンス番号を介してポーリングにリンクされます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 2 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface MTU | Options |0|0|0|0|0|I|M|MS
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DD sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
The format of the Database Description packet is very similar to both the Link State Request and Link State Acknowledgment packets. The main part of all three is a list of items, each item describing a piece of the link-state database. The sending of Database Description Packets is documented in Section 10.8. The reception of Database Description packets is documented in Section 10.6.
データベース記述パケットのフォーマットは、リンク状態要求パケットとリンク状態確認パケットの両方に非常に似ています。 3つすべての主要部分はアイテムのリストであり、各アイテムはリンク状態データベースの一部を記述しています。データベース記述パケットの送信については、セクション10.8で説明されています。データベース記述パケットの受信については、セクション10.6に記載されています。
Interface MTU The size in bytes of the largest IP datagram that can be sent out the associated interface, without fragmentation. The MTUs of common Internet link types can be found in Table 7-1 of [Ref22]. Interface MTU should be set to 0 in Database Description packets sent over virtual links.
インターフェイスMTU断片化せずに、関連するインターフェイスから送信できる最大のIPデータグラムのバイト単位のサイズ。一般的なインターネットリンクタイプのMTUは、[Ref22]の表7-1にあります。仮想リンクを介して送信されるデータベース記述パケットでは、インターフェースMTUを0に設定する必要があります。
Options The optional capabilities supported by the router, as documented in Section A.2.
オプションセクションA.2で説明されている、ルーターがサポートするオプション機能。
I-bit The Init bit. When set to 1, this packet is the first in the sequence of Database Description Packets.
IビットInitビット。 1に設定すると、このパケットは一連のデータベース記述パケットの最初になります。
M-bit The More bit. When set to 1, it indicates that more Database Description Packets are to follow.
MビットThe Moreビット。 1に設定されている場合、より多くのデータベース記述パケットが続くことを示します。
MS-bit The Master/Slave bit. When set to 1, it indicates that the router is the master during the Database Exchange process. Otherwise, the router is the slave.
MS-bitマスター/スレーブビット。 1に設定されている場合、データベース交換プロセス中にルーターがマスターであることを示します。それ以外の場合、ルーターはスレーブです。
DD sequence number Used to sequence the collection of Database Description Packets. The initial value (indicated by the Init bit being set) should be unique. The DD sequence number then increments until the complete database description has been sent.
DDシーケンス番号データベース記述パケットのコレクションのシーケンスに使用されます。初期値（設定されているInitビットで示される）は一意である必要があります。その後、DDシーケンス番号は、完全なデータベース記述が送信されるまで増加します。
The rest of the packet consists of a (possibly partial) list of the link-state database's pieces. Each LSA in the database is described by its LSA header. The LSA header is documented in Section A.4.1. It contains all the information required to uniquely identify both the LSA and the LSA's current instance.
パケットの残りの部分は、リンク状態データベースの断片の（おそらく部分的な）リストで構成されています。データベース内の各LSAは、そのLSAヘッダーによって記述されます。 LSAヘッダーについては、セクションA.4.1で説明しています。 LSAとLSAの現在のインスタンスの両方を一意に識別するために必要なすべての情報が含まれています。
A.3.4 The Link State Request packet
A.3.4リンク状態要求パケット
Link State Request packets are OSPF packet type 3. After exchanging Database Description packets with a neighboring router, a router may find that parts of its link-state database are out-of-date. The Link State Request packet is used to request the pieces of the neighbor's database that are more up-to-date. Multiple Link State Request packets may need to be used.
リンク状態要求パケットはOSPFパケットタイプ3です。隣接ルーターとデータベース記述パケットを交換した後、ルーターはリンク状態データベースの一部が古くなっていることに気付く場合があります。 Link State Requestパケットは、ネイバーのデータベースの中でより最新の部分を要求するために使用されます。複数のリンク状態要求パケットを使用する必要がある場合があります。
A router that sends a Link State Request packet has in mind the precise instance of the database pieces it is requesting. Each instance is defined by its LS sequence number, LS checksum, and LS age, although these fields are not specified in the Link State Request Packet itself. The router may receive even more recent instances in response.
リンク状態要求パケットを送信するルーターは、要求しているデータベース部分の正確なインスタンスを念頭に置いています。各インスタンスは、LSシーケンス番号、LSチェックサム、およびLS経過時間によって定義されますが、これらのフィールドはリンク状態要求パケット自体では指定されていません。ルーターは、応答としてさらに最近のインスタンスを受信する場合があります。
The sending of Link State Request packets is documented in Section 10.9. The reception of Link State Request packets is documented in Section 10.7.
リンク状態要求パケットの送信については、セクション10.9で説明されています。リンク状態要求パケットの受信については、セクション10.7で説明されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 3 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Each LSA requested is specified by its LS type, Link State ID, and Advertising Router. This uniquely identifies the LSA, but not its instance. Link State Request packets are understood to be requests for the most recent instance (whatever that might be).
要求される各LSAは、そのLSタイプ、リンク状態ID、およびアドバタイジングルーターによって指定されます。これはLSAを一意に識別しますが、そのインスタンスは識別しません。リンク状態要求パケットは、最新のインスタンス（それが何であれ）の要求であると理解されます。
A.3.5 The Link State Update packet
A.3.5リンク状態更新パケット
Link State Update packets are OSPF packet type 4. These packets implement the flooding of LSAs. Each Link State Update packet carries a collection of LSAs one hop further from their origin. Several LSAs may be included in a single packet.
リンク状態更新パケットは、OSPFパケットタイプ4です。これらのパケットは、LSAのフラッディングを実装しています。各リンク状態更新パケットは、発信元から1ホップ離れたLSAのコレクションを伝送します。 1つのパケットに複数のLSAが含まれる場合があります。
Link State Update packets are multicast on those physical networks that support multicast/broadcast. In order to make the flooding procedure reliable, flooded LSAs are acknowledged in Link State Acknowledgment packets. If retransmission of certain LSAs is necessary, the retransmitted LSAs are always sent directly to the neighbor. For more information on the reliable flooding of LSAs, consult Section 13.
リンク状態更新パケットは、マルチキャスト/ブロードキャストをサポートする物理ネットワーク上でマルチキャストされます。フラッディング手順を信頼できるものにするために、フラッディングされたLSAは、リンク状態確認パケットで確認されます。特定のLSAの再送信が必要な場合、再送信されたLSAは常にネイバーに直接送信されます。 LSAの信頼できるフラッディングの詳細については、セクション13を参照してください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 4 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # LSAs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- +-+
| LSAs |
+- +-+
| ... |
# LSAs The number of LSAs included in this update.
＃LSAsこのアップデートに含まれるLSAの数。
The body of the Link State Update packet consists of a list of LSAs. Each LSA begins with a common 20 byte header, described in Section A.4.1. Detailed formats of the different types of LSAs are described in Section A.4.
リンク状態更新パケットの本体は、LSAのリストで構成されています。各LSAは、セクションA.4.1で説明されている共通の20バイトのヘッダーで始まります。さまざまなタイプのLSAの詳細なフォーマットについては、セクションA.4で説明します。
A.3.6 The Link State Acknowledgment packet
A.3.6リンク状態確認パケット
Link State Acknowledgment Packets are OSPF packet type 5. To make the flooding of LSAs reliable, flooded LSAs are explicitly acknowledged. This acknowledgment is accomplished through the sending and receiving of Link State Acknowledgment packets. Multiple LSAs can be acknowledged in a single Link State Acknowledgment packet.
リンク状態確認パケットはOSPFパケットタイプ5です。LSAのフラッディングを信頼できるものにするために、フラッディングLSAは明示的に確認されます。この確認応答は、リンク状態確認応答パケットの送受信を通じて行われます。複数のLSAは、単一のリンク状態確認パケットで確認できます。
Depending on the state of the sending interface and the sender of the corresponding Link State Update packet, a Link State Acknowledgment packet is sent either to the multicast address AllSPFRouters, to the multicast address AllDRouters, or as a unicast. The sending of Link State Acknowledgement packets is documented in Section 13.5. The reception of Link State Acknowledgement packets is documented in Section 13.7.
送信インターフェイスの状態と対応するリンク状態更新パケットの送信者に応じて、リンク状態確認パケットはマルチキャストアドレスAllSPFRouters、マルチキャストアドレスAllDRouters、またはユニキャストとして送信されます。 Link State Acknowledgementパケットの送信については、セクション13.5で説明されています。 Link State Acknowledgementパケットの受信については、セクション13.7で説明されています。
The format of this packet is similar to that of the Data Description packet. The body of both packets is simply a list of LSA headers.
このパケットのフォーマットは、データ記述パケットのフォーマットに似ています。両方のパケットの本体は、LSAヘッダーのリストです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 5 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Each acknowledged LSA is described by its LSA header. The LSA header is documented in Section A.4.1. It contains all the information required to uniquely identify both the LSA and the LSA's current instance.
確認済みの各LSAは、そのLSAヘッダーによって記述されます。 LSAヘッダーについては、セクションA.4.1で説明しています。 LSAとLSAの現在のインスタンスの両方を一意に識別するために必要なすべての情報が含まれています。
A.4 LSA formats
A.4 LSAフォーマット
This memo defines five distinct types of LSAs. Each LSA begins with a standard 20 byte LSA header. This header is explained in Section A.4.1. Succeeding sections then diagram the separate LSA types.
このメモは、5つの異なるタイプのLSAを定義しています。各LSAは、標準の20バイトのLSAヘッダーで始まります。このヘッダーについては、セクションA.4.1で説明します。その後のセクションでは、個別のLSAタイプを図で示します。
Each LSA describes a piece of the OSPF routing domain. Every router originates a router-LSA. In addition, whenever the router is elected Designated Router, it originates a network-LSA. Other types of LSAs may also be originated (see Section 12.4). All LSAs are then flooded throughout the OSPF routing domain. The flooding algorithm is reliable, ensuring that all routers have the same collection of LSAs. (See Section 13 for more information concerning the flooding algorithm). This collection of LSAs is called the link-state database.
各LSAは、OSPFルーティングドメインの一部を記述します。すべてのルーターはルーターLSAを発信します。さらに、ルーターが指定ルーターとして選出されるたびに、ネットワークLSAが発信されます。他のタイプのLSAも発生する可能性があります（セクション12.4を参照）。その後、すべてのLSAがOSPFルーティングドメイン全体にフラッディングされます。フラッディングアルゴリズムは信頼性が高く、すべてのルーターが同じLSAのコレクションを持っていることが保証されます。 （フラッディングアルゴリズムの詳細については、セクション13を参照してください）。このLSAのコレクションは、リンク状態データベースと呼ばれます。
From the link state database, each router constructs a shortest path tree with itself as root. This yields a routing table (see Section 11). For the details of the routing table build process, see Section 16.
リンク状態データベースから、各ルーターは自身をルートとして最短パスツリーを構築します。これにより、ルーティングテーブルが生成されます（セクション11を参照）。ルーティングテーブル作成プロセスの詳細については、セクション16を参照してください。
A.4.1 The LSA header
A.4.1 LSAヘッダー
All LSAs begin with a common 20 byte header. This header contains enough information to uniquely identify the LSA (LS type, Link State ID, and Advertising Router). Multiple instances of the LSA may exist in the routing domain at the same time. It is then necessary to determine which instance is more recent. This is accomplished by examining the LS age, LS sequence number and LS checksum fields that are also contained in the LSA header.
すべてのLSAは、共通の20バイトのヘッダーで始まります。このヘッダーには、LSA（LSタイプ、リンク状態ID、および広告ルーター）を一意に識別するのに十分な情報が含まれています。 LSAの複数のインスタンスがルーティングドメインに同時に存在する場合があります。次に、どのインスタンスがより新しいかを判別する必要があります。これは、LSAヘッダーにも含まれているLS経過時間、LSシーケンス番号、およびLSチェックサムフィールドを調べることによって行われます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | LS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LS age The time in seconds since the LSA was originated.
LSエージLSAが発信されてからの秒数。
Options The optional capabilities supported by the described portion of the routing domain. OSPF's optional capabilities are documented in Section A.2.
オプションルーティングドメインの説明部分でサポートされているオプション機能。 OSPFのオプション機能については、セクションA.2で説明しています。
LS type The type of the LSA. Each LSA type has a separate advertisement format. The LSA types defined in this memo are as follows (see Section 12.1.3 for further explanation):
LSタイプLSAのタイプ。各LSAタイプには個別のアドバタイズメント形式があります。このメモで定義されているLSAタイプは次のとおりです（詳細については、セクション12.1.3を参照してください）。
LS Type Description
___________________________________
1 Router-LSAs
2 Network-LSAs
3 Summary-LSAs (IP network)
4 Summary-LSAs (ASBR)
5 AS-external-LSAs
Link State ID This field identifies the portion of the internet environment that is being described by the LSA. The contents of this field depend on the LSA's LS type. For example, in network-LSAs the Link State ID is set to the IP interface address of the network's Designated Router (from which the network's IP address can be derived). The Link State ID is further discussed in Section 12.1.4.
リンク状態IDこのフィールドは、LSAによって記述されているインターネット環境の部分を識別します。このフィールドの内容は、LSAのLSタイプによって異なります。たとえば、ネットワークLSAでは、リンク状態IDは、ネットワークの指定ルーター（ネットワークのIPアドレスを取得できる）のIPインターフェースアドレスに設定されます。リンク状態IDについては、セクション12.1.4で詳しく説明します。
Advertising Router The Router ID of the router that originated the LSA. For example, in network-LSAs this field is equal to the Router ID of the network's Designated Router.
広告ルーターLSAを発信したルーターのルーターID。たとえば、ネットワークLSAでは、このフィールドはネットワークの指定ルーターのルーターIDと同じです。
LS sequence number Detects old or duplicate LSAs. Successive instances of an LSA are given successive LS sequence numbers. See Section 12.1.6 for more details.
LSシーケンス番号古いまたは重複したLSAを検出します。 LSAの連続するインスタンスには、連続したLSシーケンス番号が与えられます。詳細については、セクション12.1.6を参照してください。
LS checksum The Fletcher checksum of the complete contents of the LSA, including the LSA header but excluding the LS age field. See Section 12.1.7 for more details.
LSチェックサムLSAヘッダーを含み、LSエージフィールドを除いた、LSAの完全な内容のフレッチャーチェックサム。詳細については、セクション12.1.7を参照してください。
length The length in bytes of the LSA. This includes the 20 byte LSA header.
LSAのバイト単位の長さ。これには、20バイトのLSAヘッダーが含まれます。
A.4.2 Router-LSAs
A.4.2ルーターLSA
Router-LSAs are the Type 1 LSAs. Each router in an area originates a router-LSA. The LSA describes the state and cost of the router's links (i.e., interfaces) to the area. All of the router's links to the area must be described in a single router-LSA. For details concerning the construction of router-LSAs, see Section 12.4.1.
ルーターLSAはタイプ1 LSAです。エリア内の各ルーターは、ルーターLSAを発信します。 LSAは、エリアへのルーターのリンク（つまり、インターフェース）の状態とコストを記述します。エリアへのルーターのすべてのリンクは、単一のルーターLSAで記述する必要があります。ルータLSAの構築の詳細については、セクション12.4.1を参照してください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |V|E|B| 0 | # links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | # TOS | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOS | 0 | TOS metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
In router-LSAs, the Link State ID field is set to the router's OSPF Router ID. Router-LSAs are flooded throughout a single area only.
ルーターLSAでは、リンク状態IDフィールドはルーターのOSPFルーターIDに設定されます。ルーターLSAは、単一の領域のみにフラッディングされます。
bit V When set, the router is an endpoint of one or more fully adjacent virtual links having the described area as Transit area (V is for virtual link endpoint).
ビットVが設定されている場合、ルーターは1つ以上の完全に隣接する仮想リンクのエンドポイントであり、記述されたエリアは通過エリアです（Vは仮想リンクのエンドポイントを示します）。
bit E When set, the router is an AS boundary router (E is for external).
ビットEセットされている場合、ルーターはAS境界ルーターです（Eは外部用）。
bit B When set, the router is an area border router (B is for border).
ビットBセットされている場合、ルーターはエリア境界ルーターです（Bは境界用です）。
# links The number of router links described in this LSA. This must be the total collection of router links (i.e., interfaces) to the area.
＃linksこのLSAに記述されているルーターリンクの数。これは、エリアへのルーターリンク（つまり、インターフェース）の総コレクションでなければなりません。
The following fields are used to describe each router link (i.e., interface). Each router link is typed (see the below Type field). The Type field indicates the kind of link being described. It may be a link to a transit network, to another router or to a stub network. The values of all the other fields describing a router link depend on the link's Type. For example, each link has an associated 32-bit Link Data field. For links to stub networks this field specifies the network's IP address mask. For other link types the Link Data field specifies the router interface's IP address.
次のフィールドは、各ルーターリンク（つまり、インターフェース）を説明するために使用されます。各ルーターリンクが入力されます（以下の[種類]フィールドを参照）。 Typeフィールドは、記述されているリンクの種類を示します。これは、トランジットネットワーク、別のルーター、またはスタブネットワークへのリンクである場合があります。ルータリンクを表す他のすべてのフィールドの値は、リンクのタイプによって異なります。たとえば、各リンクには32ビットのリンクデータフィールドが関連付けられています。スタブネットワークへのリンクの場合、このフィールドはネットワークのIPアドレスマスクを指定します。他のリンクタイプの場合、[リンクデータ]フィールドはルーターインターフェイスのIPアドレスを指定します。
Type A quick description of the router link. One of the following. Note that host routes are classified as links to stub networks with network mask of 0xffffffff.
タイプルータリンクの簡単な説明。次のいずれか。ホストルートは、ネットワークマスクが0xffffffffのスタブネットワークへのリンクとして分類されることに注意してください。
Type Description
__________________________________________________
1 Point-to-point connection to another router
2 Connection to a transit network
3 Connection to a stub network
4 Virtual link
Link ID Identifies the object that this router link connects to. Value depends on the link's Type. When connecting to an object that also originates an LSA (i.e., another router or a transit network) the Link ID is equal to the neighboring LSA's Link State ID. This provides the key for looking up the neighboring LSA in the link state database during the routing table calculation. See Section 12.2 for more details.
リンクIDこのルーターリンクが接続するオブジェクトを識別します。値はリンクのタイプによって異なります。 LSAを生成するオブジェクト（つまり、別のルーターまたはトランジットネットワーク）に接続する場合、リンクIDは隣接するLSAのリンク状態IDと同じです。これは、ルーティングテーブルの計算中にリンク状態データベースで隣接LSAを検索するためのキーを提供します。詳細については、セクション12.2を参照してください。
Type Link ID
______________________________________
1 Neighboring router's Router ID
2 IP address of Designated Router
3 IP network/subnet number
4 Neighboring router's Router ID
Link Data Value again depends on the link's Type field. For connections to stub networks, Link Data specifies the network's IP address mask. For unnumbered point-to-point connections, it specifies the interface's MIB-II [Ref8] ifIndex value. For the other link types it specifies the router interface's IP address. This latter piece of information is needed during the routing table build process, when calculating the IP address of the next hop. See Section 16.1.1 for more details.
Link Data Valueは、リンクのTypeフィールドに依存します。スタブネットワークへの接続の場合、リンクデータはネットワークのIPアドレスマスクを指定します。アンナンバードポイントツーポイント接続の場合、インターフェイスのMIB-II [Ref8] ifIndex値を指定します。他のリンクタイプの場合は、ルーターインターフェイスのIPアドレスを指定します。この後者の情報は、ネクストホップのIPアドレスを計算するときに、ルーティングテーブルの構築プロセス中に必要です。詳細については、セクション16.1.1を参照してください。
# TOS The number of different TOS metrics given for this link, not counting the required link metric (referred to as the TOS 0 metric in [Ref9]). For example, if no additional TOS metrics are given, this field is set to 0.
＃TOSこのリンクに指定されたさまざまなTOSメトリックの数。必要なリンクメトリックはカウントしません（[Ref9]ではTOS 0メトリックと呼ばれます）。たとえば、追加のTOSメトリックが指定されていない場合、このフィールドは0に設定されます。
metric The cost of using this router link.
メトリックこのルーターリンクを使用するコスト。
Additional TOS-specific information may also be included, for backward compatibility with previous versions of the OSPF specification ([Ref9]). Within each link, and for each desired TOS, TOS TOS-specific link information may be encoded as follows:
OSPF仕様の以前のバージョンとの下位互換性のために、追加のTOS固有の情報も含まれる場合があります（[Ref9]）。各リンク内、および必要なTOSごとに、TOS TOS固有のリンク情報を次のようにエンコードできます。
TOS IP Type of Service that this metric refers to. The encoding of TOS in OSPF LSAs is described in Section 12.3.
このメトリックが参照するTOS IP Type of Service。 OSPF LSAでのTOSのエンコーディングについては、セクション12.3で説明しています。
TOS metric TOS-specific metric information.
TOSメトリックTOS固有のメトリック情報。
A.4.3 Network-LSAs
A.4.3ネットワークLSA
Network-LSAs are the Type 2 LSAs. A network-LSA is originated for each broadcast and NBMA network in the area which supports two or more routers. The network-LSA is originated by the network's Designated Router. The LSA describes all routers attached to the network, including the Designated Router itself. The LSA's Link State ID field lists the IP interface address of the Designated Router.
ネットワークLSAはタイプ2 LSAです。ネットワークLSAは、2つ以上のルーターをサポートするエリア内のブロードキャストおよびNBMAネットワークごとに作成されます。ネットワークLSAは、ネットワークの指定ルーターによって発信されます。 LSAは、代表ルーター自体を含む、ネットワークに接続されているすべてのルーターを記述します。 LSAのリンク状態IDフィールドには、代表ルーターのIPインターフェイスアドレスが一覧表示されます。
The distance from the network to all attached routers is zero. This is why metric fields need not be specified in the network-LSA. For details concerning the construction of network-LSAs, see Section 12.4.2.
ネットワークから接続されているすべてのルーターまでの距離はゼロです。これが、ネットワークLSAでメトリックフィールドを指定する必要がない理由です。ネットワークLSAの構築に関する詳細については、セクション12.4.2を参照してください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attached Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Network Mask The IP address mask for the network. For example, a class A network would have the mask 0xff000000.
ネットワークマスクネットワークのIPアドレスマスク。たとえば、クラスAネットワークのマスクは0xff000000です。
Attached Router The Router IDs of each of the routers attached to the network. Actually, only those routers that are fully adjacent to the Designated Router are listed. The Designated Router includes itself in this list. The number of routers included can be deduced from the LSA header's length field.
接続されているルーターネットワークに接続されている各ルーターのルーターID。実際には、指定ルーターに完全に隣接しているルーターのみが表示されます。指定ルーターはこのリストに含まれています。含まれるルーターの数は、LSAヘッダーの長さフィールドから推定できます。
A.4.4 Summary-LSAs
A.4.4サマリー-LSA
Summary-LSAs are the Type 3 and 4 LSAs. These LSAs are originated by area border routers. Summary-LSAs describe inter-area destinations. For details concerning the construction of summary-LSAs, see Section 12.4.3.
サマリーLSAはタイプ3および4のLSAです。これらのLSAは、エリア境界ルーターによって発信されます。概要LSAは、エリア間宛先を記述します。サマリーLSAの作成の詳細については、セクション12.4.3を参照してください。
Type 3 summary-LSAs are used when the destination is an IP network. In this case the LSA's Link State ID field is an IP network number (if necessary, the Link State ID can also have one or more of the network's "host" bits set; see Appendix E for details). When the destination is an AS boundary router, a Type 4 summary-LSA is used, and the Link State ID field is the AS boundary router's OSPF Router ID. (To see why it is necessary to advertise the location of each ASBR, consult Section 16.4.) Other than the difference in the Link State ID field, the format of Type 3 and 4 summary-LSAs is identical.
タイプ3サマリーLSAは、宛先がIPネットワークの場合に使用されます。この場合、LSAのリンク状態IDフィールドはIPネットワーク番号です（必要に応じて、リンク状態IDは1つ以上のネットワークの「ホスト」ビットセットを持つこともできます。詳細については、付録Eを参照してください）。宛先がAS境界ルーターの場合、タイプ4サマリーLSAが使用され、リンク状態IDフィールドはAS境界ルーターのOSPFルーターIDです。 （各ASBRの場所をアドバタイズする必要がある理由については、セクション16.4を参照してください。）リンク状態IDフィールドの違い以外は、タイプ3とタイプ4のサマリーLSAの形式は同じです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 3 or 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOS | TOS metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
For stub areas, Type 3 summary-LSAs can also be used to describe a (per-area) default route. Default summary routes are used in stub areas instead of flooding a complete set of external routes. When describing a default summary route, the summary-LSA's Link State ID is always set to DefaultDestination (0.0.0.0) and the Network Mask is set to 0.0.0.0.
スタブエリアの場合、タイプ3サマリーLSAを使用して、（エリアごとの）デフォルトルートを説明することもできます。外部ルートの完全なセットをフラッディングする代わりに、デフォルトのサマリールートがスタブエリアで使用されます。デフォルトのサマリールートを記述する場合、サマリーLSAのリンク状態IDは常にDefaultDestination（0.0.0.0）に設定され、ネットワークマスクは0.0.0.0に設定されます。
Network Mask For Type 3 summary-LSAs, this indicates the destination network's IP address mask. For example, when advertising the location of a class A network the value 0xff000000 would be used. This field is not meaningful and must be zero for Type 4 summary-LSAs.
タイプ3サマリーLSAのネットワークマスク。これは、宛先ネットワークのIPアドレスマスクを示します。たとえば、クラスAネットワークの場所をアドバタイズする場合、値0xff000000が使用されます。このフィールドは意味がなく、タイプ4サマリーLSAの場合はゼロでなければなりません。
metric The cost of this route. Expressed in the same units as the interface costs in the router-LSAs.
メトリックこのルートのコスト。ルータLSAのインターフェイスコストと同じ単位で表されます。
Additional TOS-specific information may also be included, for backward compatibility with previous versions of the OSPF specification ([Ref9]). For each desired TOS, TOS-specific information is encoded as follows:
OSPF仕様の以前のバージョンとの下位互換性のために、追加のTOS固有の情報も含まれる場合があります（[Ref9]）。必要なTOSごとに、TOS固有の情報は次のようにエンコードされます。
TOS IP Type of Service that this metric refers to. The encoding of TOS in OSPF LSAs is described in Section 12.3.
このメトリックが参照するTOS IP Type of Service。 OSPF LSAでのTOSのエンコーディングについては、セクション12.3で説明しています。
TOS metric TOS-specific metric information.
TOSメトリックTOS固有のメトリック情報。
A.4.5 AS-external-LSAs
A.4.5 AS-external-LSA
AS-external-LSAs are the Type 5 LSAs. These LSAs are originated by AS boundary routers, and describe destinations external to the AS. For details concerning the construction of AS-external-LSAs, see Section 12.4.3.
AS-external-LSAはタイプ5 LSAです。これらのLSAは、AS境界ルーターによって発信され、ASの外部の宛先を記述します。 AS-external-LSAの構築に関する詳細については、セクション12.4.3を参照してください。
AS-external-LSAs usually describe a particular external destination. For these LSAs the Link State ID field specifies an IP network number (if necessary, the Link State ID can also have one or more of the network's "host" bits set; see Appendix E for details). AS-external-LSAs are also used to describe a default route. Default routes are used when no specific route exists to the destination. When describing a default route, the Link State ID is always set to DefaultDestination (0.0.0.0) and the Network Mask is set to 0.0.0.0.
AS-external-LSAは通常、特定の外部宛先を記述します。これらのLSAの場合、リンク状態IDフィールドはIPネットワーク番号を指定します（必要に応じて、リンク状態IDは1つ以上のネットワークの「ホスト」ビットセットを持つこともできます。詳細については、付録Eを参照してください）。 AS-external-LSAは、デフォルトルートを説明するためにも使用されます。デフォルトルートは、宛先への特定のルートが存在しない場合に使用されます。デフォルトルートを記述する場合、リンク状態IDは常にDefaultDestination（0.0.0.0）に設定され、ネットワークマスクは0.0.0.0に設定されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| 0 | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forwarding address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Route Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| TOS | TOS metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forwarding address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Route Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Network Mask The IP address mask for the advertised destination. For example, when advertising a class A network the mask 0xff000000 would be used.
ネットワークマスクアドバタイズされた宛先のIPアドレスマスク。たとえば、クラスAネットワークをアドバタイズする場合、マスク0xff000000が使用されます。
bit E The type of external metric. If bit E is set, the metric specified is a Type 2 external metric. This means the metric is considered larger than any link state path. If bit E is zero, the specified metric is a Type 1 external metric. This means that it is expressed in the same units as the link state metric (i.e., the same units as interface cost).
ビットE外部メトリックのタイプ。ビットEが設定されている場合、指定されるメトリックはタイプ2の外部メトリックです。つまり、メトリックはどのリンク状態パスよりも大きいと見なされます。ビットEがゼロの場合、指定されたメトリックはタイプ1の外部メトリックです。つまり、リンク状態メトリックと同じ単位（つまり、インターフェースコストと同じ単位）で表されます。
metric The cost of this route. Interpretation depends on the external type indication (bit E above).
メトリックこのルートのコスト。解釈は、外部タイプの表示（上記のビットE）によって異なります。
Forwarding address Data traffic for the advertised destination will be forwarded to this address. If the Forwarding address is set to 0.0.0.0, data traffic will be forwarded instead to the LSA's originator (i.e., the responsible AS boundary router).
Forwarding addressアドバタイズされた宛先のデータトラフィックは、このアドレスに転送されます。転送アドレスが0.0.0.0に設定されている場合、データトラフィックは代わりにLSAの発信元（つまり、責任のあるAS境界ルーター）に転送されます。
External Route Tag A 32-bit field attached to each external route. This is not used by the OSPF protocol itself. It may be used to communicate information between AS boundary routers; the precise nature of such information is outside the scope of this specification.
外部ルートタグ各外部ルートに添付された32ビットのフィールド。これは、OSPFプロトコル自体では使用されません。 AS境界ルーター間で情報を通信するために使用できます。そのような情報の正確な性質は、この仕様の範囲外です。
Additional TOS-specific information may also be included, for backward compatibility with previous versions of the OSPF specification ([Ref9]). For each desired TOS, TOS-specific information is encoded as follows:
OSPF仕様の以前のバージョンとの下位互換性のために、追加のTOS固有の情報も含まれる場合があります（[Ref9]）。必要なTOSごとに、TOS固有の情報は次のようにエンコードされます。
TOS The Type of Service that the following fields concern. The encoding of TOS in OSPF LSAs is described in Section 12.3.
TOS以下のフィールドが関係するサービスのタイプ。 OSPF LSAでのTOSのエンコーディングについては、セクション12.3で説明しています。
bit E For backward-compatibility with [Ref9].
ビットE [Ref9]との下位互換性のため。
TOS metric TOS-specific metric information.
TOSメトリックTOS固有のメトリック情報。
Forwarding address For backward-compatibility with [Ref9].
転送アドレス[Ref9]との後方互換性のため。
External Route Tag For backward-compatibility with [Ref9].
[Ref9]との下位互換性のための外部ルートタグ。
B. Architectural Constants
B.アーキテクチャの定数
Several OSPF protocol parameters have fixed architectural values. These parameters have been referred to in the text by names such as LSRefreshTime. The same naming convention is used for the configurable protocol parameters. They are defined in Appendix C.
いくつかのOSPFプロトコルパラメータには、固定されたアーキテクチャ値があります。これらのパラメーターは、本文ではLSRefreshTimeなどの名前で参照されています。構成可能なプロトコルパラメータには、同じ命名規則が使用されます。これらは付録Cで定義されています。
The name of each architectural constant follows, together with its value and a short description of its function.
それぞれのアーキテクチャ定数の名前は、その値とその機能の簡単な説明とともに以下に続きます。
LSRefreshTime The maximum time between distinct originations of any particular LSA. If the LS age field of one of the router's self-originated LSAs reaches the value LSRefreshTime, a new instance of the LSA is originated, even though the contents of the LSA (apart from the LSA header) will be the same. The value of LSRefreshTime is set to 30 minutes.
LSRefreshTime特定のLSAの異なる発信元間の最大時間。ルーターの自己生成LSAのLSエージフィールドがLSRefreshTimeの値に達すると、LSAの内容（LSAヘッダーは除く）が同じであっても、LSAの新しいインスタンスが生成されます。 LSRefreshTimeの値は30分に設定されています。
MinLSInterval The minimum time between distinct originations of any particular LSA. The value of MinLSInterval is set to 5 seconds.
MinLSInterval特定のLSAの異なる発信元間の最小時間。 MinLSIntervalの値は5秒に設定されています。
MinLSArrival For any particular LSA, the minimum time that must elapse between reception of new LSA instances during flooding. LSA instances received at higher frequencies are discarded. The value of MinLSArrival is set to 1 second.
MinLSArrival特定のLSAについて、フラッディング中に新しいLSAインスタンスを受信する間に経過する必要がある最小時間。より高い周波数で受信されたLSAインスタンスは破棄されます。 MinLSArrivalの値は1秒に設定されています。
MaxAge The maximum age that an LSA can attain. When an LSA's LS age field reaches MaxAge, it is reflooded in an attempt to flush the LSA from the routing domain (See Section 14). LSAs of age MaxAge are not used in the routing table calculation. The value of MaxAge is set to 1 hour.
MaxAge LSAが達成できる最大経過時間。 LSAのLSエージフィールドがMaxAgeに達すると、ルーティングドメインからLSAをフラッシュするために再フラッディングされます（セクション14を参照）。 MaxAgeのLSAは、ルーティングテーブルの計算には使用されません。 MaxAgeの値は1時間に設定されています。
CheckAge When the age of an LSA in the link state database hits a multiple of CheckAge, the LSA's checksum is verified. An incorrect checksum at this time indicates a serious error. The value of CheckAge is set to 5 minutes.
CheckAgeリンク状態データベースのLSAの経過時間がCheckAgeの倍数に達すると、LSAのチェックサムが検証されます。このときのチェックサムが正しくない場合は、重大なエラーが発生しています。 CheckAgeの値は5分に設定されています。
MaxAgeDiff The maximum time dispersion that can occur, as an LSA is flooded throughout the AS. Most of this time is accounted for by the LSAs sitting on router output queues (and therefore not aging) during the flooding process. The value of MaxAgeDiff is set to 15 minutes.
MaxAgeDiff LSAがAS全体にフラッディングされるときに発生する可能性のある最大時間分散。この時間の大部分は、フラッディングプロセス中にルーターの出力キューにあるLSAによって説明されます（したがって、エージングではありません）。 MaxAgeDiffの値は15分に設定されています。
LSInfinity The metric value indicating that the destination described by an LSA is unreachable. Used in summary-LSAs and AS-external-LSAs as an alternative to premature aging (see Section 14.1). It is defined to be the 24-bit binary value of all ones: 0xffffff.
LSInfinity LSAによって記述された宛先に到達できないことを示すメトリック値。早期LSAおよびAS外部LSAで、早期エージングの代わりとして使用されます（セクション14.1を参照）。これは、すべて1の24ビットのバイナリ値0xffffffとして定義されています。
DefaultDestination The Destination ID that indicates the default route. This route is used when no other matching routing table entry can be found. The default destination can only be advertised in AS-external-LSAs and in stub areas' type 3 summary-LSAs. Its value is the IP address 0.0.0.0. Its associated Network Mask is also always 0.0.0.0.
DefaultDestinationデフォルトルートを示す宛先ID。このルートは、一致する他のルーティングテーブルエントリが見つからない場合に使用されます。デフォルトの宛先は、AS外部LSAおよびスタブエリアのタイプ3サマリーLSAでのみアドバタイズできます。その値はIPアドレス0.0.0.0です。関連するネットワークマスクも常に0.0.0.0です。
InitialSequenceNumber The value used for LS Sequence Number when originating the first instance of any LSA. Its value is the signed 32-bit integer 0x80000001.
InitialSequenceNumber任意のLSAの最初のインスタンスを生成するときにLSシーケンス番号に使用される値。その値は、符号付き32ビット整数0x80000001です。
MaxSequenceNumber The maximum value that LS Sequence Number can attain. Its value is the signed 32-bit integer 0x7fffffff.
MaxSequenceNumber LSシーケンス番号が取得できる最大値。その値は、符号付き32ビット整数0x7fffffffです。
C. Configurable Constants
C.構成可能な定数
The OSPF protocol has quite a few configurable parameters. These parameters are listed below. They are grouped into general functional categories (area parameters, interface parameters, etc.). Sample values are given for some of the parameters.
OSPFプロトコルには、かなり多くの設定可能なパラメータがあります。これらのパラメーターを以下にリストします。それらは、一般的な機能カテゴリ（エリアパラメータ、インタフェースパラメータなど）にグループ化されています。一部のパラメーターのサンプル値が示されています。
Some parameter settings need to be consistent among groups of routers. For example, all routers in an area must agree on that area's parameters, and all routers attached to a network must agree on that network's IP network number and mask.
一部のパラメーター設定は、ルーターのグループ間で一貫している必要があります。たとえば、エリア内のすべてのルーターはそのエリアのパラメーターに同意する必要があり、ネットワークに接続されているすべてのルーターはそのネットワークのIPネットワーク番号とマスクに同意する必要があります。
Some parameters may be determined by router algorithms outside of this specification (e.g., the address of a host connected to the router via a SLIP line). From OSPF's point of view, these items are still configurable.
一部のパラメータは、この仕様外のルーターアルゴリズムによって決定される場合があります（SLIP回線を介してルーターに接続されているホストのアドレスなど）。 OSPFの観点からは、これらの項目は引き続き構成可能です。
C.1 Global parameters
C.1グローバルパラメータ
In general, a separate copy of the OSPF protocol is run for each area. Because of this, most configuration parameters are defined on a per-area basis. The few global configuration parameters are listed below.
一般に、OSPFプロトコルの個別のコピーがエリアごとに実行されます。このため、ほとんどの構成パラメーターはエリアごとに定義されます。いくつかのグローバル構成パラメーターを以下にリストします。
Router ID This is a 32-bit number that uniquely identifies the router in the Autonomous System. One algorithm for Router ID assignment is to choose the largest or smallest IP address assigned to the router. If a router's OSPF Router ID is changed, the router's OSPF software should be restarted before the new Router ID takes effect. Before restarting in order to change its Router ID, the router should flush its self-originated LSAs from the routing domain (see Section 14.1), or they will persist for up to MaxAge minutes.
ルーターIDこれは、自律システム内のルーターを一意に識別する32ビットの番号です。ルーターID割り当てのアルゴリズムの1つは、ルーターに割り当てられた最大または最小のIPアドレスを選択することです。ルーターのOSPFルーターIDが変更された場合、新しいルーターIDが有効になる前に、ルーターのOSPFソフトウェアを再起動する必要があります。ルーターIDを変更するために再起動する前に、ルーターは自己発信LSAをルーティングドメインからフラッシュする必要があります（セクション14.1を参照）。そうしないと、最大MaxAge分間存続します。
RFC1583Compatibility Controls the preference rules used in Section 16.4 when choosing among multiple AS-external-LSAs advertising the same destination. When set to "enabled", the preference rules remain those specified by RFC 1583 ([Ref9]). When set to "disabled", the preference rules are those stated in
RFC1583Compatibility同じ宛先をアドバタイズする複数のAS外部LSAから選択するときに、セクション16.4で使用される優先ルールを制御します。 「有効」に設定すると、設定ルールはRFC 1583（[Ref9]）で指定されたままになります。 「無効」に設定されている場合、優先ルールは、
Section 16.4.1, which prevent routing loops when AS-external-LSAs for the same destination have been originated from different areas. Set to "enabled" by default.
セクション16.4.1。同じ宛先のAS外部LSAが異なるエリアから発信された場合のルーティングループを防止します。デフォルトでは「有効」に設定されています。
In order to minimize the chance of routing loops, all OSPF routers in an OSPF routing domain should have RFC1583Compatibility set identically. When there are routers present that have not been updated with the functionality specified in Section 16.4.1 of this memo, all routers should have RFC1583Compatibility set to "enabled". Otherwise, all routers should have RFC1583Compatibility set to "disabled", preventing all routing loops.
ルーティングループの可能性を最小限に抑えるには、OSPFルーティングドメイン内のすべてのOSPFルーターにRFC1583Compatibilityを同じように設定する必要があります。このメモのセクション16.4.1で指定された機能で更新されていないルーターが存在する場合、すべてのルーターでRFC1583Compatibilityを "有効"に設定する必要があります。それ以外の場合は、すべてのルーターでRFC1583Compatibilityを「無効」に設定して、すべてのルーティングループを防止する必要があります。
C.2 Area parameters
C.2エリアパラメータ
All routers belonging to an area must agree on that area's configuration. Disagreements between two routers will lead to an inability for adjacencies to form between them, with a resulting hindrance to the flow of routing protocol and data traffic. The following items must be configured for an area:
エリアに属するすべてのルーターは、そのエリアの構成に同意する必要があります。 2つのルーター間で不一致があると、ルーター間で隣接関係を形成できなくなり、ルーティングプロトコルとデータトラフィックのフローが妨げられます。エリアには次の項目を設定する必要があります。
Area ID This is a 32-bit number that identifies the area. The Area ID of 0.0.0.0 is reserved for the backbone. If the area represents a subnetted network, the IP network number of the subnetted network may be used for the Area ID.
エリアIDこれは、エリアを識別する32ビットの番号です。エリアID 0.0.0.0はバックボーン用に予約されています。エリアがサブネット化されたネットワークを表す場合、サブネット化されたネットワークのIPネットワーク番号をエリアIDに使用できます。
List of address ranges An OSPF area is defined as a list of address ranges. Each address range consists of the following items:
アドレス範囲のリストOSPF領域は、アドレス範囲のリストとして定義されます。各アドレス範囲は、次の項目で構成されています。
[IP address, mask] Describes the collection of IP addresses contained in the address range. Networks and hosts are assigned to an area depending on whether their addresses fall into one of the area's defining address ranges. Routers are viewed as belonging to multiple areas, depending on their attached networks' area membership.
[IPアドレス、マスク]アドレス範囲に含まれるIPアドレスのコレクションを記述します。ネットワークとホストは、それらのアドレスがエリアの定義アドレス範囲の1つに該当するかどうかに応じて、エリアに割り当てられます。ルーターは、接続されているネットワークのエリアメンバーシップに応じて、複数のエリアに属していると見なされます。
Status Set to either Advertise or DoNotAdvertise. Routing information is condensed at area boundaries. External to the area, at most a single route is advertised (via a summary-LSA) for each address range. The route is advertised if and only if the address range's Status is set to Advertise. Unadvertised ranges allow the existence of certain networks to be intentionally hidden from other areas. Status is set to Advertise by default.
ステータスはAdvertiseまたはDoNotAdvertiseに設定されます。ルーティング情報はエリア境界で圧縮されます。エリアの外部では、アドレス範囲ごとに最大で1つのルートが（サマリーLSAを介して）アドバタイズされます。ルートは、アドレス範囲のステータスがAdvertiseに設定されている場合にのみアドバタイズされます。アドバタイズされていない範囲により、特定のネットワークの存在を他の領域から意図的に隠すことができます。ステータスはデフォルトでAdvertiseに設定されています。
As an example, suppose an IP subnetted network is to be its own OSPF area. The area would be configured as a single address range, whose IP address is the address of the subnetted network, and whose mask is the natural class A, B, or C address mask. A single route would be advertised external to the area, describing the entire subnetted network.
例として、IPサブネット化ネットワークが独自のOSPFエリアになると仮定します。エリアは単一のアドレス範囲として構成され、そのIPアドレスはサブネット化されたネットワークのアドレスであり、マスクはナチュラルクラスA、B、またはCのアドレスマスクです。サブネット化されたネットワーク全体を表す単一のルートがエリアの外部でアドバタイズされます。
ExternalRoutingCapability Whether AS-external-LSAs will be flooded into/throughout the area. If AS-external-LSAs are excluded from the area, the area is called a "stub". Internal to stub areas, routing to external destinations will be based solely on a default summary route. The backbone cannot be configured as a stub area. Also, virtual links cannot be configured through stub areas. For more information, see Section 3.6.
ExternalRoutingCapability AS外部LSAがエリアにフラッディングされるか、エリア全体にフラッディングされるかどうか。 AS-external-LSAがエリアから除外されている場合、そのエリアは「スタブ」と呼ばれます。内部からスタブエリアへの外部宛先へのルーティングは、デフォルトのサマリールートのみに基づいて行われます。バックボーンはスタブエリアとして設定できません。また、仮想リンクはスタブエリアを介して構成できません。詳細は、3.6項を参照してください。
StubDefaultCost If the area has been configured as a stub area, and the router itself is an area border router, then the StubDefaultCost indicates the cost of the default summary-LSA that the router should advertise into the area.
StubDefaultCostエリアがスタブエリアとして構成されていて、ルーター自体がエリア境界ルーターである場合、StubDefaultCostは、ルーターがエリアにアドバタイズする必要があるデフォルトのサマリーLSAのコストを示します。
C.3 Router interface parameters
C.3ルーターインターフェースパラメーター
Some of the configurable router interface parameters (such as IP interface address and subnet mask) actually imply properties of the attached networks, and therefore must be consistent across all the routers attached to that network. The parameters that must be configured for a router interface are: IP interface address The IP protocol address for this interface. This uniquely identifies the router over the entire internet. An IP address is not required on point-to-point networks. Such a point-to-point network is called "unnumbered".
一部の構成可能なルーターインターフェイスパラメーター（IPインターフェイスアドレスやサブネットマスクなど）は、実際には接続されたネットワークのプロパティを意味するため、そのネットワークに接続されたすべてのルーター間で一貫している必要があります。ルータインターフェイスに設定する必要があるパラメータは次のとおりです。IPインターフェイスアドレスこのインターフェイスのIPプロトコルアドレス。これにより、インターネット全体でルーターが一意に識別されます。ポイントツーポイントネットワークではIPアドレスは必要ありません。このようなポイントツーポイントネットワークは「番号なし」と呼ばれます。
IP interface mask Also referred to as the subnet/network mask, this indicates the portion of the IP interface address that identifies the attached network. Masking the IP interface address with the IP interface mask yields the IP network number of the attached network. On point-to-point networks and virtual links, the IP interface mask is not defined. On these networks, the link itself is not assigned an IP network number, and so the addresses of each side of the link are assigned independently, if they are assigned at all.
IPインターフェースマスクサブネット/ネットワークマスクとも呼ばれ、接続されているネットワークを識別するIPインターフェースアドレスの部分を示します。 IPインターフェイスアドレスをIPインターフェイスマスクでマスクすると、接続されているネットワークのIPネットワーク番号がわかります。ポイントツーポイントネットワークおよび仮想リンクでは、IPインターフェイスマスクは定義されていません。これらのネットワークでは、リンク自体にIPネットワーク番号が割り当てられていないため、リンクの両端のアドレスは、割り当てられている場合は個別に割り当てられます。
Area ID The OSPF area to which the attached network belongs.
Area OF接続されたネットワークが属するOSPFエリア。
Interface output cost The cost of sending a packet on the interface, expressed in the link state metric. This is advertised as the link cost for this interface in the router's router-LSA. The interface output cost must always be greater than 0.
インターフェース出力コストリンク状態メトリックで表される、インターフェースでのパケット送信のコスト。これは、ルーターのルーターLSA内のこのインターフェイスのリンクコストとしてアドバタイズされます。インターフェイスの出力コストは常に0より大きい必要があります。
RxmtInterval The number of seconds between LSA retransmissions, for adjacencies belonging to this interface. Also used when retransmitting Database Description and Link State Request Packets. This should be well over the expected round-trip delay between any two routers on the attached network. The setting of this value should be conservative or needless retransmissions will result. Sample value for a local area network: 5 seconds.
RxmtIntervalこのインターフェイスに属する隣接関係の、LSA再送信間の秒数。データベース記述およびリンク状態要求パケットを再送信するときにも使用されます。これは、接続されたネットワーク上の任意の2つのルーター間で予想される往復遅延を十分に超えるはずです。この値の設定は控えめにする必要があります。そうしないと、不必要な再送信が発生します。ローカルエリアネットワークのサンプル値：5秒。
InfTransDelay The estimated number of seconds it takes to transmit a Link State Update Packet over this interface. LSAs contained in the update packet must have their age incremented by this amount before transmission. This value should take into account the transmission and propagation delays of the interface. It must be greater than 0. Sample value for a local area network: 1 second.
InfTransDelayこのインターフェースを介してリンク状態更新パケットを送信するのにかかる推定秒数。更新パケットに含まれるLSAは、送信する前に、この期間だけエージを増加させる必要があります。この値は、インターフェースの送信および伝搬遅延を考慮に入れる必要があります。 0より大きい必要があります。ローカルエリアネットワークのサンプル値：1秒。
Router Priority An 8-bit unsigned integer. When two routers attached to a network both attempt to become Designated Router, the one with the highest Router Priority takes precedence. If there is still a tie, the router with the highest Router ID takes precedence. A router whose Router Priority is set to 0 is ineligible to become Designated Router on the attached network. Router Priority is only configured for interfaces to broadcast and NBMA networks.
ルーター優先順位8ビットの符号なし整数。ネットワークに接続されている2つのルーターが両方とも指定ルーターになろうとする場合、最も高いルーター優先度を持つルーターが優先されます。それでも同数の場合は、最も高いルーターIDを持つルーターが優先されます。ルーター優先度が0に設定されているルーターは、接続されたネットワークで指定ルーターになる資格がありません。ルータプライオリティは、ブロードキャストおよびNBMAネットワークへのインターフェイスに対してのみ設定されます。
HelloInterval The length of time, in seconds, between the Hello Packets that the router sends on the interface. This value is advertised in the router's Hello Packets. It must be the same for all routers attached to a common network. The smaller the HelloInterval, the faster topological changes will be detected; however, more OSPF routing protocol traffic will ensue. Sample value for a X.25 PDN network: 30 seconds. Sample value for a local area network: 10 seconds.
HelloIntervalルーターがインターフェイス上で送信するHelloパケット間の時間の長さ（秒単位）。この値は、ルーターのHelloパケットでアドバタイズされます。共通ネットワークに接続されているすべてのルーターで同じでなければなりません。 HelloIntervalが小さいほど、トポロジーの変化が速く検出されます。ただし、より多くのOSPFルーティングプロトコルトラフィックが発生します。 X.25 PDNネットワークのサンプル値：30秒。ローカルエリアネットワークのサンプル値：10秒。
RouterDeadInterval After ceasing to hear a router's Hello Packets, the number of seconds before its neighbors declare the router down. This is also advertised in the router's Hello Packets in their RouterDeadInterval field. This should be some multiple of the HelloInterval (say 4). This value again must be the same for all routers attached to a common network.
RouterDeadIntervalルーターのHelloパケットが聞こえなくなった後、ネイバーがルーターのダウンを宣言するまでの秒数。これは、RouterDeadIntervalフィールドのルーターのHelloパケットでもアドバタイズされます。これは、HelloInterval（たとえば4）の倍数である必要があります。この値も、共通ネットワークに接続されているすべてのルーターで同じでなければなりません。
AuType Identifies the authentication procedure to be used on the attached network. This value must be the same for all routers attached to the network. See Appendix D for a discussion of the defined authentication types.
AuType接続されたネットワークで使用される認証手順を識別します。この値は、ネットワークに接続されているすべてのルーターで同じでなければなりません。定義されている認証タイプの説明については、付録Dを参照してください。
Authentication key This configured data allows the authentication procedure to verify OSPF protocol packets received over the interface. For example, if the AuType indicates simple password, the Authentication key would be a clear 64-bit password. Authentication keys associated with the other OSPF authentication types are discussed in Appendix D.
認証キーこの構成されたデータにより、認証手順で、インターフェースを介して受信したOSPFプロトコルパケットを確認できます。たとえば、AuTypeが単純なパスワードを示している場合、認証キーは64ビットのクリアパスワードになります。他のOSPF認証タイプに関連付けられている認証キーについては、付録Dで説明します。
C.4 Virtual link parameters
C.4仮想リンクパラメータ
Virtual links are used to restore/increase connectivity of the backbone. Virtual links may be configured between any pair of area border routers having interfaces to a common (non-backbone) area. The virtual link appears as an unnumbered point-to-point link in the graph for the backbone. The virtual link must be configured in both of the area border routers.
仮想リンクは、バックボーンの接続を復元/増加するために使用されます。仮想リンクは、共通の（非バックボーン）エリアへのインターフェイスを持つエリアボーダールーターのペア間に構成できます。仮想リンクは、バックボーンのグラフに番号なしのポイントツーポイントリンクとして表示されます。仮想リンクは、両方のエリア境界ルーターで構成する必要があります。
A virtual link appears in router-LSAs (for the backbone) as if it were a separate router interface to the backbone. As such, it has all of the parameters associated with a router interface (see Section C.3). Although a virtual link acts like an unnumbered point-to-point link, it does have an associated IP interface address. This address is used as the IP source in OSPF protocol packets it sends along the virtual link, and is set dynamically during the routing table build process. Interface output cost is also set dynamically on virtual links to be the cost of the intra-area path between the two routers. The parameter RxmtInterval must be configured, and should be well over the expected round-trip delay between the two routers. This may be hard to estimate for a virtual link; it is better to err on the side of making it too large. Router Priority is not used on virtual links.
仮想リンクは、バックボーンへの別個のルーターインターフェイスであるかのように、ルーターLSA（バックボーン用）に表示されます。そのため、ルータインターフェイスに関連するすべてのパラメータがあります（セクションC.3を参照）。仮想リンクは、番号なしのポイントツーポイントリンクのように機能しますが、関連付けられたIPインターフェイスアドレスを持っています。このアドレスは、仮想リンクに沿って送信するOSPFプロトコルパケットのIPソースとして使用され、ルーティングテーブルの構築プロセス中に動的に設定されます。インターフェイスの出力コストも、2つのルータ間のエリア内パスのコストになるように仮想リンクで動的に設定されます。パラメータRxmtIntervalを設定する必要があり、2つのルータ間の予想される往復遅延を十分に超えている必要があります。これは、仮想リンクに対して推定するのが難しい場合があります。大きくしすぎると、エラーが発生しやすくなります。ルータプライオリティは仮想リンクでは使用されません。
A virtual link is defined by the following two configurable parameters: the Router ID of the virtual link's other endpoint, and the (non-backbone) area through which the virtual link runs (referred to as the virtual link's Transit area). Virtual links cannot be configured through stub areas.
仮想リンクは、次の2つの構成可能なパラメーターによって定義されます。仮想リンクの他のエンドポイントのルーターID、および仮想リンクが実行される（非バックボーン）エリア（仮想リンクのトランジットエリアと呼ばれます）。仮想リンクはスタブエリアを介して設定できません。
C.5 NBMA network parameters
C.5 NBMAネットワークパラメータ
OSPF treats an NBMA network much like it treats a broadcast network. Since there may be many routers attached to the network, a Designated Router is selected for the network. This Designated Router then originates a network-LSA, which lists all routers attached to the NBMA network.
OSPFは、NBMAネットワークをブロードキャストネットワークと同様に扱います。ネットワークには多くのルーターが接続されている可能性があるため、ネットワークには指定ルーターが選択されています。次に、この指定ルーターは、NBMAネットワークに接続されているすべてのルーターをリストするネットワークLSAを発信します。
However, due to the lack of broadcast capabilities, it may be necessary to use configuration parameters in the Designated Router selection. These parameters will only need to be configured in those routers that are themselves eligible to become Designated Router (i.e., those router's whose Router Priority for the network is non-zero), and then only if no automatic procedure for discovering neighbors exists:
ただし、ブロードキャスト機能がないため、指定ルーターの選択で構成パラメーターを使用する必要がある場合があります。これらのパラメーターは、それ自体が指定ルーターになる資格のあるルーター（つまり、ネットワークのルーター優先度がゼロ以外のルーター）でのみ構成する必要があり、ネイバーを検出するための自動手順が存在しない場合に限ります。
List of all other attached routers The list of all other routers attached to the NBMA network. Each router is listed by its IP interface address on the network. Also, for each router listed, that router's eligibility to become Designated Router must be defined. When an interface to a NBMA network comes up, the router sends Hello Packets only to those neighbors eligible to become Designated Router, until the identity of the Designated Router is discovered.
他のすべての接続されたルーターのリストNBMAネットワークに接続された他のすべてのルーターのリスト。各ルーターは、ネットワーク上のIPインターフェイスアドレスごとに一覧表示されます。また、リストされた各ルーターについて、そのルーターが指定ルーターになる資格を定義する必要があります。 NBMAネットワークへのインターフェースがアップすると、ルーターは、指定ルーターのIDが検出されるまで、指定ルーターになる資格があるネイバーにのみHelloパケットを送信します。
PollInterval If a neighboring router has become inactive (Hello Packets have not been seen for RouterDeadInterval seconds), it may still be necessary to send Hello Packets to the dead neighbor. These Hello Packets will be sent at the reduced rate PollInterval, which should be much larger than HelloInterval. Sample value for a PDN X.25 network: 2 minutes.
PollInterval隣接ルーターが非アクティブになった場合（RouterDeadInterval秒の間、Helloパケットが検出されなかった場合）、引き続き、死んだ隣接ルーターにHelloパケットを送信する必要があります。これらのHelloパケットは、HelloIntervalよりも大幅に大きくなるはずのPollIntervalレートで送信されます。 PDN X.25ネットワークのサンプル値：2分。
C.6 Point-to-MultiPoint network parameters
C.6ポイントツーマルチポイントネットワークパラメーター
On Point-to-MultiPoint networks, it may be necessary to configure the set of neighbors that are directly reachable over the Point-to-MultiPoint network. Each neighbor is identified by its IP address on the Point-to-MultiPoint network. Designated Routers are not elected on Point-to-MultiPoint networks, so the Designated Router eligibility of configured neighbors is undefined.
ポイントツーマルチポイントネットワークでは、ポイントツーマルチポイントネットワークを介して直接到達可能な一連のネイバーを構成する必要がある場合があります。各ネイバーは、ポイントツーマルチポイントネットワーク上のIPアドレスによって識別されます。指定ルーターはポイントツーマルチポイントネットワークでは選出されないため、構成されたネイバーの指定ルーターの適格性は定義されていません。
Alternatively, neighbors on Point-to-MultiPoint networks may be dynamically discovered by lower-level protocols such as Inverse ARP ([Ref14]).
または、ポイントツーマルチポイントネットワーク上のネイバーは、Inverse ARP（[Ref14]）などの低レベルのプロトコルによって動的に発見される場合があります。
C.7 Host route parameters
C.7ホストルートパラメータ
Host routes are advertised in router-LSAs as stub networks with mask 0xffffffff. They indicate either router interfaces to point-to-point networks, looped router interfaces, or IP hosts that are directly connected to the router (e.g., via a SLIP line). For each host directly connected to the router, the following items must be configured:
ホストルートは、ルーターLSAでマスク0xffffffffを持つスタブネットワークとしてアドバタイズされます。これらは、ポイントツーポイントネットワークへのルーターインターフェイス、ループルーターインターフェイス、またはルーターに直接接続されている（SLIP回線などを介して）IPホストのいずれかを示します。ルーターに直接接続されている各ホストに対して、次の項目を構成する必要があります。
Host IP address The IP address of the host.
ホストIPアドレスホストのIPアドレス。
Cost of link to host The cost of sending a packet to the host, in terms of the link state metric. However, since the host probably has only a single connection to the internet, the actual configured cost in many cases is unimportant (i.e., will have no effect on routing).
ホストへのリンクのコストリンク状態メトリックの観点から、ホストにパケットを送信するコスト。ただし、ホストはおそらくインターネットへの接続が1つしかないため、実際に構成されたコストは多くの場合重要ではありません（つまり、ルーティングには影響しません）。
Area ID The OSPF area to which the host belongs.
Area OFホストが属するOSPFエリア。
D. Authentication
D.認証
All OSPF protocol exchanges are authenticated. The OSPF packet header (see Section A.3.1) includes an authentication type field, and 64-bits of data for use by the appropriate authentication scheme (determined by the type field).
すべてのOSPFプロトコル交換が認証されます。 OSPFパケットヘッダー（セクションA.3.1を参照）には、認証タイプフィールドと、適切な認証スキーム（タイプフィールドによって決定される）で使用する64ビットのデータが含まれています。
The authentication type is configurable on a per-interface (or equivalently, on a per-network/subnet) basis. Additional authentication data is also configurable on a per-interface basis.
認証タイプは、インターフェースごとに（または同等に、ネットワーク/サブネットごとに）構成できます。追加の認証データもインターフェイスごとに設定できます。
Authentication types 0, 1 and 2 are defined by this specification. All other authentication types are reserved for definition by the IANA (iana@ISI.EDU). The current list of authentication types is described below in Table 20.
認証タイプ0、1、および2は、この仕様で定義されています。他のすべての認証タイプは、IANA（iana@ISI.EDU）による定義用に予約されています。認証タイプの現在のリストを以下の表20で説明します。
AuType Description
___________________________________________
0 Null authentication
1 Simple password
2 Cryptographic authentication
All others Reserved for assignment by the
IANA (iana@ISI.EDU)
Table 20: OSPF authentication types.
表20：OSPF認証タイプ。
D.1 Null authentication
D.1ヌル認証
Use of this authentication type means that routing exchanges over the network/subnet are not authenticated. The 64-bit authentication field in the OSPF header can contain anything; it is not examined on packet reception. When employing Null authentication, the entire contents of each OSPF packet (other than the 64-bit authentication field) are checksummed in order to detect data corruption.
この認証タイプを使用すると、ネットワーク/サブネット上のルーティング交換は認証されません。 OSPFヘッダーの64ビット認証フィールドには何でも含めることができます。パケット受信時には検査されません。ヌル認証を採用する場合、データ破損を検出するために、各OSPFパケットの内容全体（64ビット認証フィールドを除く）がチェックサムされます。
D.2 Simple password authentication
D.2単純なパスワード認証
Using this authentication type, a 64-bit field is configured on a per-network basis. All packets sent on a particular network must have this configured value in their OSPF header 64-bit authentication field. This essentially serves as a "clear" 64- bit password. In addition, the entire contents of each OSPF packet (other than the 64-bit authentication field) are checksummed in order to detect data corruption.
この認証タイプを使用して、64ビットのフィールドがネットワークごとに構成されます。特定のネットワークで送信されるすべてのパケットは、OSPFヘッダーの64ビット認証フィールドにこの値を設定する必要があります。これは基本的に、「クリア」な64ビットパスワードとして機能します。さらに、データ破損を検出するために、各OSPFパケットの内容全体（64ビット認証フィールドを除く）がチェックサムされます。
Simple password authentication guards against routers inadvertently joining the routing domain; each router must first be configured with its attached networks' passwords before it can participate in routing. However, simple password authentication is vulnerable to passive attacks currently widespread in the Internet (see [Ref16]). Anyone with physical access to the network can learn the password and compromise the security of the OSPF routing domain.
単純なパスワード認証は、ルーターが誤ってルーティングドメインに参加するのを防ぎます。各ルーターは、ルーティングに参加する前に、まず接続されているネットワークのパスワードを使用して構成する必要があります。ただし、単純なパスワード認証は、現在インターネットで広まっているパッシブ攻撃に対して脆弱です（[Ref16]を参照）。ネットワークに物理的にアクセスできる人は誰でもパスワードを知ることができ、OSPFルーティングドメインのセキュリティを危険にさらすことができます。
D.3 Cryptographic authentication
D.3暗号認証
Using this authentication type, a shared secret key is configured in all routers attached to a common network/subnet. For each OSPF protocol packet, the key is used to generate/verify a "message digest" that is appended to the end of the OSPF packet. The message digest is a one-way function of the OSPF protocol packet and the secret key. Since the secret key is never sent over the network in the clear, protection is provided against passive attacks.
この認証タイプを使用すると、共通のネットワーク/サブネットに接続されているすべてのルーターで共有秘密鍵が構成されます。 OSPFプロトコルパケットごとに、キーを使用して、OSPFパケットの末尾に付加される「メッセージダイジェスト」を生成/検証します。メッセージダイジェストは、OSPFプロトコルパケットと秘密鍵の一方向の機能です。秘密鍵は平文でネットワークを介して送信されることはないため、受動的な攻撃に対する保護が提供されます。
The algorithms used to generate and verify the message digest are specified implicitly by the secret key. This specification completely defines the use of OSPF Cryptographic authentication when the MD5 algorithm is used.
メッセージダイジェストの生成と検証に使用されるアルゴリズムは、秘密鍵によって暗黙的に指定されます。この仕様は、MD5アルゴリズムが使用される場合のOSPF暗号化認証の使用を完全に定義しています。
In addition, a non-decreasing sequence number is included in
each OSPF protocol packet to protect against replay attacks.
This provides long term protection; however, it is still
possible to replay an OSPF packet until the sequence number
changes. To implement this feature, each neighbor data structure
contains a new field called the "cryptographic sequence number".
This field is initialized to zero, and is also set to zero 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Key ID | Auth Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Usage of the Authentication field in the OSPF packet header when Cryptographic Authentication is employed
図18：暗号化認証が採用されている場合のOSPFパケットヘッダーの認証フィールドの使用法
whenever the neighbor's state transitions to "Down". Whenever an OSPF packet is accepted as authentic, the cryptographic sequence number is set to the received packet's sequence number.
ネイバーの状態が「ダウン」に遷移するたび。 OSPFパケットが信頼できるものとして受け入れられると、暗号化シーケンス番号は受信したパケットのシーケンス番号に設定されます。
This specification does not provide a rollover procedure for the cryptographic sequence number. When the cryptographic sequence number that the router is sending hits the maximum value, the router should reset the cryptographic sequence number that it is sending back to 0. After this is done, the router's neighbors will reject the router's OSPF packets for a period of RouterDeadInterval, and then the router will be forced to reestablish all adjacencies over the interface. However, it is expected that many implementations will use "seconds since reboot" (or "seconds since 1960", etc.) as the cryptographic sequence number. Such a choice will essentially prevent rollover, since the cryptographic sequence number field is 32 bits in length.
この仕様では、暗号シーケンス番号のロールオーバー手順は提供されていません。ルーターが送信している暗号シーケンス番号が最大値に達した場合、ルーターは、送信している暗号シーケンス番号を0にリセットする必要があります。これが完了すると、ルーターのネイバーは、RouterDeadIntervalの間、ルーターのOSPFパケットを拒否します。 、その後、ルータはインターフェイス上のすべての隣接関係を再確立することを強制されます。ただし、多くの実装では、暗号化シーケンス番号として「再起動からの秒数」（または「1960年からの秒数」など）を使用することが予想されます。暗号化シーケンス番号フィールドは32ビット長であるため、このような選択は基本的にロールオーバーを防ぎます。
The OSPF Cryptographic authentication option does not provide confidentiality.
OSPF暗号化認証オプションは機密性を提供しません。
When cryptographic authentication is used, the 64-bit Authentication field in the standard OSPF packet header is redefined as shown in Figure 18. The new field definitions are as follows: Key ID This field identifies the algorithm and secret key used to create the message digest appended to the OSPF packet. Key Identifiers are unique per-interface (or equivalently, per-subnet).
暗号化認証が使用されると、標準OSPFパケットヘッダーの64ビット認証フィールドが図18に示すように再定義されます。新しいフィールド定義は次のとおりです。キーIDこのフィールドは、メッセージダイジェストの作成に使用されるアルゴリズムと秘密キーを識別しますOSPFパケットに追加されます。キー識別子は、インターフェイスごと（または同等に、サブネットごと）に一意です。
Auth Data Len The length in bytes of the message digest appended to the OSPF packet.
Auth Data Len OSPFパケットに付加されたメッセージダイジェストの長さ（バイト単位）。
Cryptographic sequence number An unsigned 32-bit non-decreasing sequence number. Used to guard against replay attacks.
暗号シーケンス番号符号なし32ビット非減少シーケンス番号。リプレイ攻撃を防ぐために使用されます。
The message digest appended to the OSPF packet is not actually considered part of the OSPF protocol packet: the message digest is not included in the OSPF header's packet length, although it is included in the packet's IP header length field.
OSPFパケットに追加されたメッセージダイジェストは、実際にはOSPFプロトコルパケットの一部とは見なされません。メッセージダイジェストは、パケットのIPヘッダー長フィールドには含まれていますが、OSPFヘッダーのパケット長には含まれていません。
Each key is identified by the combination of interface and Key ID. An interface may have multiple keys active at any one time. This enables smooth transition from one key to another. Each key has four time constants associated with it. These time constants can be expressed in terms of a time-of-day clock, or in terms of a router's local clock (e.g., number of seconds since last reboot):
各キーは、インターフェースとキーIDの組み合わせによって識別されます。インターフェースは同時に複数のキーをアクティブにすることができます。これにより、あるキーから別のキーへのスムーズな移行が可能になります。各キーには、4つの時定数が関連付けられています。これらの時定数は、時刻クロックまたはルーターのローカルクロック（最後の再起動からの秒数など）で表すことができます。
KeyStartAccept The time that the router will start accepting packets that have been created with the given key.
KeyStartAccept指定されたキーで作成されたパケットの受け入れをルーターが開始する時刻。
KeyStartGenerate The time that the router will start using the key for packet generation.
KeyStartGenerateパケット生成のためにルーターがキーの使用を開始する時刻。
KeyStopGenerate The time that the router will stop using the key for packet generation.
KeyStopGenerateパケット生成のためにルーターがキーの使用を停止する時間。
KeyStopAccept The time that the router will stop accepting packets that have been created with the given key.
KeyStopAccept指定されたキーで作成されたパケットの受け入れをルーターが停止する時間。
In order to achieve smooth key transition, KeyStartAccept should be less than KeyStartGenerate and KeyStopGenerate should be less than KeyStopAccept. If KeyStopGenerate and KeyStopAccept are left unspecified, the key's lifetime is infinite. When a new key replaces an old, the KeyStartGenerate time for the new key must be less than or equal to the KeyStopGenerate time of the old key.
スムーズなキー遷移を実現するには、KeyStartAcceptをKeyStartGenerateより小さくし、KeyStopGenerateをKeyStopAcceptより小さくする必要があります。 KeyStopGenerateおよびKeyStopAcceptが指定されていない場合、キーの有効期間は無限です。新しいキーが古いキーを置き換える場合、新しいキーのKeyStartGenerate時間は、古いキーのKeyStopGenerate時間以下でなければなりません。
Key storage should persist across a system restart, warm or cold, to avoid operational issues. In the event that the last key associated with an interface expires, it is unacceptable to revert to an unauthenticated condition, and not advisable to disrupt routing. Therefore, the router should send a "last authentication key expiration" notification to the network manager and treat the key as having an infinite lifetime until the lifetime is extended, the key is deleted by network management, or a new key is configured.
運用上の問題を回避するために、キーストレージは、システムの再起動後、ウォームまたはコールドにわたって保持される必要があります。インターフェイスに関連付けられた最後のキーが期限切れになった場合、認証されていない状態に戻すことは受け入れられず、ルーティングを中断することはお勧めできません。したがって、ルータはネットワークマネージャに「最後の認証キーの有効期限」通知を送信し、ライフタイムが延長されるか、ネットワーク管理によってキーが削除されるか、新しいキーが設定されるまで、キーを無期限のライフタイムとして扱う必要があります。
D.4 Message generation
D.4メッセージの生成
After building the contents of an OSPF packet, the authentication procedure indicated by the sending interface's Autype value is called before the packet is sent. The authentication procedure modifies the OSPF packet as follows.
OSPFパケットの内容を作成した後、パケットが送信される前に、送信インターフェイスのAutype値によって示される認証手順が呼び出されます。認証手順では、次のようにOSPFパケットを変更します。
D.4.1 Generating Null authentication
D.4.1 Null認証の生成
When using Null authentication, the packet is modified as follows:
Null認証を使用する場合、パケットは次のように変更されます。
(1) The Autype field in the standard OSPF header is set to 0.
（1）標準のOSPFヘッダーのAutypeフィールドが0に設定されている。
(2) The checksum field in the standard OSPF header is set to the standard IP checksum of the entire contents of the packet, starting with the OSPF packet header but excluding the 64-bit authentication field. This checksum is calculated as the 16-bit one's complement of the one's complement sum of all the 16-bit words in the packet, excepting the authentication field. If the packet's length is not an integral number of 16-bit words, the packet is padded with a byte of zero before checksumming.
（2）標準OSPFヘッダーのチェックサムフィールドは、パケットの内容全体の標準IPチェックサムに設定されます。OSPFパケットヘッダーから始まり、64ビット認証フィールドは除外されます。このチェックサムは、認証フィールドを除く、パケット内のすべての16ビットワードの1の補数の合計の16ビットの1の補数として計算されます。パケットの長さが16ビットワードの整数でない場合、チェックサムの前にパケットにゼロのバイトが埋め込まれます。
D.4.2 Generating Simple password authentication
D.4.2単純なパスワード認証の生成
When using Simple password authentication, the packet is modified as follows:
簡易パスワード認証を使用する場合、パケットは次のように変更されます。
(1) The Autype field in the standard OSPF header is set to 1.
（1）標準OSPFヘッダーのAutypeフィールドが1に設定されている。
(2) The checksum field in the standard OSPF header is set to the standard IP checksum of the entire contents of the packet, starting with the OSPF packet header but excluding the 64-bit authentication field. This checksum is calculated as the 16-bit one's complement of the one's complement sum of all the 16-bit words in the packet, excepting the authentication field. If the packet's length is not an integral number of 16-bit words, the packet is padded with a byte of zero before checksumming.
（2）標準OSPFヘッダーのチェックサムフィールドは、パケットの内容全体の標準IPチェックサムに設定されます。OSPFパケットヘッダーから始まり、64ビット認証フィールドは除外されます。このチェックサムは、認証フィールドを除く、パケット内のすべての16ビットワードの1の補数の合計の16ビットの1の補数として計算されます。パケットの長さが16ビットワードの整数でない場合、チェックサムの前にパケットにゼロのバイトが埋め込まれます。
(3) The 64-bit authentication field in the OSPF packet header is set to the 64-bit password (i.e., authentication key) that has been configured for the interface.
（3）OSPFパケットヘッダーの64ビット認証フィールドは、インターフェースに構成されている64ビットパスワード（つまり、認証キー）に設定されます。
D.4.3 Generating Cryptographic authentication
D.4.3暗号化認証の生成
When using Cryptographic authentication, there may be multiple keys configured for the interface. In this case, among the keys that are valid for message generation (i.e, that have KeyStartGenerate <= current time < KeyStopGenerate) choose the one with the most recent KeyStartGenerate time. Using this key, modify the packet as follows:
暗号化認証を使用する場合、インターフェースに複数のキーが構成されている可能性があります。この場合、メッセージ生成に有効なキー（つまり、KeyStartGenerate <=現在時刻<KeyStopGenerate）のキーの中から、最新のKeyStartGenerate時間を持つキーを選択します。このキーを使用して、パケットを次のように変更します。
(1) The Autype field in the standard OSPF header is set to 2.
（1）標準OSPFヘッダーのAutypeフィールドが2に設定されている。
(2) The checksum field in the standard OSPF header is not calculated, but is instead set to 0.
（2）標準OSPFヘッダーのチェックサムフィールドは計算されませんが、代わりに0に設定されます。
(3) The Key ID (see Figure 18) is set to the chosen key's Key ID.
（3）キーID（図18を参照）は、選択したキーのキーIDに設定されます。
(4) The Auth Data Len field is set to the length in bytes of the message digest that will be appended to the OSPF packet. When using MD5 as the authentication algorithm, Auth Data Len will be 16.
（4）Auth Data Lenフィールドは、OSPFパケットに付加されるメッセージダイジェストの長さ（バイト単位）に設定されます。認証アルゴリズムとしてMD5を使用する場合、Auth Data Lenは16になります。
(5) The 32-bit Cryptographic sequence number (see Figure 18) is set to a non-decreasing value (i.e., a value at least as large as the last value sent out the interface). The precise values to use in the cryptographic sequence number field are implementation-specific. For example, it may be based on a simple counter, or be based on the system's clock.
（5）32ビット暗号シーケンス番号（図18を参照）は、減少しない値（つまり、少なくともインターフェースから送信された最後の値と同じ大きさの値）に設定されます。暗号化シーケンス番号フィールドで使用する正確な値は、実装によって異なります。たとえば、単純なカウンターに基づいたり、システムのクロックに基づいたりします。
(6) The message digest is then calculated and appended to the OSPF packet. The authentication algorithm to be used in calculating the digest is indicated by the key itself. Input to the authentication algorithm consists of the OSPF packet and the secret key. When using MD5 as the authentication algorithm, the message digest calculation proceeds as follows:
（6）次にメッセージダイジェストが計算され、OSPFパケットに追加されます。ダイジェストの計算に使用される認証アルゴリズムは、キー自体によって示されます。認証アルゴリズムへの入力は、OSPFパケットと秘密鍵で構成されます。認証アルゴリズムとしてMD5を使用する場合、メッセージダイジェストの計算は次のように行われます。
(a) The 16 byte MD5 key is appended to the OSPF packet.
（a）16バイトのMD5キーがOSPFパケットに追加されます。
(b) Trailing pad and length fields are added, as specified in [Ref17].
（b）[Ref17]で指定されているように、末尾パッドと長さフィールドが追加されます。
(c) The MD5 authentication algorithm is run over the concatenation of the OSPF packet, secret key, pad and length fields, producing a 16 byte message digest (see [Ref17]).
（c）MD5認証アルゴリズムは、OSPFパケット、秘密鍵、パッド、および長さフィールドの連結に対して実行され、16バイトのメッセージダイジェストを生成します（[Ref17]を参照）。
(d) The MD5 digest is written over the OSPF key (i.e., appended to the original OSPF packet). The digest is not counted in the OSPF packet's length field, but is included in the packet's IP length field. Any trailing pad or length fields beyond the digest are not counted or transmitted.
（d）MD5ダイジェストはOSPFキーを介して書き込まれます（つまり、元のOSPFパケットに追加されます）。ダイジェストはOSPFパケットの長さフィールドにはカウントされませんが、パケットのIP長フィールドには含まれます。ダイジェストを超える末尾のパッドまたは長さフィールドはカウントまたは送信されません。
D.5 Message verification
D.5メッセージの検証
When an OSPF packet has been received on an interface, it must be authenticated. The authentication procedure is indicated by the setting of Autype in the standard OSPF packet header, which matches the setting of Autype for the receiving OSPF interface.
OSPFパケットがインターフェイスで受信されたとき、それは認証される必要があります。認証手順は、標準OSPFパケットヘッダーのAutypeの設定によって示されます。これは、受信OSPFインターフェイスのAutypeの設定と一致します。
If an OSPF protocol packet is accepted as authentic, processing of the packet continues as specified in Section 8.2. Packets which fail authentication are discarded.
OSPFプロトコルパケットが正規のものとして受け入れられる場合、セクション8.2で指定されているように、パケットの処理が続行されます。認証に失敗したパケットは破棄されます。
D.5.1 Verifying Null authentication
D.5.1 Null認証の確認
When using Null authentication, the checksum field in the OSPF header must be verified. It must be set to the 16-bit one's complement of the one's complement sum of all the 16- bit words in the packet, excepting the authentication field. (If the packet's length is not an integral number of 16-bit words, the packet is padded with a byte of zero before checksumming.)
Null認証を使用する場合、OSPFヘッダーのチェックサムフィールドを確認する必要があります。認証フィールドを除いて、パケット内のすべての16ビットワードの1の補数の合計の16ビットの1の補数に設定する必要があります。 （パケットの長さが16ビットワードの整数でない場合、チェックサムの前にパケットにゼロのバイトが埋め込まれます。）
D.5.2 Verifying Simple password authentication
D.5.2単純なパスワード認証の確認
When using Simple password authentication, the received OSPF packet is authenticated as follows:
簡易パスワード認証を使用する場合、受信したOSPFパケットは次のように認証されます。
(1) The checksum field in the OSPF header must be verified. It must be set to the 16-bit one's complement of the one's complement sum of all the 16-bit words in the packet, excepting the authentication field. (If the packet's length is not an integral number of 16-bit words, the packet is padded with a byte of zero before checksumming.)
（1）OSPFヘッダーのチェックサムフィールドを確認する必要があります。認証フィールドを除く、パケット内のすべての16ビットワードの1の補数の合計の16ビットの1の補数に設定する必要があります。 （パケットの長さが16ビットワードの整数でない場合、チェックサムの前にパケットにゼロのバイトが埋め込まれます。）
(2) The 64-bit authentication field in the OSPF packet header must be equal to the 64-bit password (i.e., authentication key) that has been configured for the interface.
（2）OSPFパケットヘッダーの64ビット認証フィールドは、インターフェイスに構成されている64ビットパスワード（つまり、認証キー）と同じである必要があります。
D.5.3 Verifying Cryptographic authentication
D.5.3暗号化認証の検証
When using Cryptographic authentication, the received OSPF packet is authenticated as follows:
暗号化認証を使用する場合、受信したOSPFパケットは次のように認証されます。
(1) Locate the receiving interface's configured key having Key ID equal to that specified in the received OSPF packet (see Figure 18). If the key is not found, or if the key is not valid for reception (i.e., current time < KeyStartAccept or current time >= KeyStopAccept), the OSPF packet is discarded.
（1）受信したOSPFパケットで指定されたものと同じキーIDを持つ受信インターフェースの構成済みキーを見つけます（図18を参照）。キーが見つからない場合、またはキーが受信に有効でない場合（つまり、現在の時刻<KeyStartAcceptまたは現在の時刻> = KeyStopAccept）の場合、OSPFパケットは破棄されます。
(2) If the cryptographic sequence number found in the OSPF header (see Figure 18) is less than the cryptographic sequence number recorded in the sending neighbor's data structure, the OSPF packet is discarded.
（2）OSPFヘッダーにある暗号化シーケンス番号（図18を参照）が送信側ネイバーのデータ構造に記録されている暗号化シーケンス番号より小さい場合、OSPFパケットは破棄されます。
(3) Verify the appended message digest in the following steps:
（3）以下の手順で、追加されたメッセージダイジェストを確認します。
(a) The received digest is set aside.
（a）受信したダイジェストが確保されます。
(b) A new digest is calculated, as specified in Step 6 of Section D.4.3.
（b）セクションD.4.3のステップ6で指定されているように、新しいダイジェストが計算されます。
(c) The calculated and received digests are compared. If they do not match, the OSPF packet is discarded. If they do match, the OSPF protocol packet is accepted as authentic, and the "cryptographic sequence number" in the neighbor's data structure is set to the sequence number found in the packet's OSPF header.
（c）計算されたダイジェストと受信されたダイジェストが比較されます。それらが一致しない場合、OSPFパケットは廃棄されます。それらが一致する場合、OSPFプロトコルパケットは正規のものとして受け入れられ、ネイバーのデータ構造内の「暗号化シーケンス番号」は、パケットのOSPFヘッダーにあるシーケンス番号に設定されます。
E. An algorithm for assigning Link State IDs
E.リンク状態IDを割り当てるためのアルゴリズム
The Link State ID in AS-external-LSAs and summary-LSAs is usually set to the described network's IP address. However, if necessary one or more of the network's host bits may be set in the Link State ID. This allows the router to originate separate LSAs for networks having the same address, yet different masks. Such networks can occur in the presence of supernetting and subnet 0s (see [Ref10]).
AS-external-LSAおよびsummary-LSAのリンク状態IDは、通常、記述されているネットワークのIPアドレスに設定されます。ただし、必要に応じて、ネットワークのホストビットの1つ以上をリンク状態IDに設定できます。これにより、ルーターは、同じアドレスで異なるマスクを持つネットワークに対して個別のLSAを発信できます。このようなネットワークは、スーパーネットとサブネット0が存在する場合に発生する可能性があります（[Ref10]を参照）。
This appendix gives one possible algorithm for setting the host bits in Link State IDs. The choice of such an algorithm is a local decision. Separate routers are free to use different algorithms, since the only LSAs affected are the ones that the router itself originates. The only requirement on the algorithms used is that the network's IP address should be used as the Link State ID whenever possible; this maximizes interoperability with OSPF implementations predating RFC 1583.
この付録では、リンク状態IDのホストビットを設定するための1つの可能なアルゴリズムを示します。このようなアルゴリズムの選択は、ローカルな決定です。影響を受けるLSAはルーター自体が発信するものだけなので、別々のルーターは自由に異なるアルゴリズムを使用できます。使用されるアルゴリズムの唯一の要件は、ネットワークのIPアドレスを可能な限りリンク状態IDとして使用する必要があることです。これにより、RFC 1583より前のOSPF実装との相互運用性が最大化されます。
The algorithm below is stated for AS-external-LSAs. This is only for clarity; the exact same algorithm can be used for summary-LSAs. Suppose that the router wishes to originate an AS-external-LSA for a network having address NA and mask NM1. The following steps are then used to determine the LSA's Link State ID:
以下のアルゴリズムはAS-external-LSAに対して記述されています。これは明確にするためだけのものです。まったく同じアルゴリズムをサマリーLSAに使用できます。ルータが、アドレスNAとマスクNM1を持つネットワークのAS-external-LSAを発信したいとします。次に、次の手順を使用してLSAのリンク状態IDを決定します。
(1) Determine whether the router is already originating an AS-external-LSA with Link State ID equal to NA (in such an LSA the router itself will be listed as the LSA's Advertising Router). If not, the Link State ID is set equal to NA and the algorithm terminates. Otherwise,
（1）ルーターがリンク状態IDがNAのAS-external-LSAを既に発信しているかどうかを確認します（このようなLSAでは、ルーター自体がLSAのアドバタイジングルーターとしてリストされます）。そうでない場合、リンク状態IDはNAに等しく設定され、アルゴリズムは終了します。さもないと、
(2) Obtain the network mask from the body of the already existing AS-external-LSA. Call this mask NM2. There are then two cases:
（2）既存のAS-external-LSAの本体からネットワークマスクを取得します。このマスクをNM2と呼びます。次に2つのケースがあります。
o NM1 is longer (i.e., more specific) than NM2. In this case, set the Link State ID in the new LSA to be the network [NA,NM1] with all the host bits set (i.e., equal to NA or'ed together with all the bits that are not set in NM1, which is network [NA,NM1]'s broadcast address).
o NM1はNM2より長い（つまり、より具体的）。この場合、新しいLSAのリンク状態IDをネットワーク[NA、NM1]に設定し、すべてのホストビットを設定します（つまり、NAに等しいか、NM1に設定されていないすべてのビットと組み合わせて、ネットワーク[NA、NM1]のブロードキャストアドレス）。
o NM2 is longer than NM1. In this case, change the existing LSA (having Link State ID of NA) to reference the new network [NA,NM1] by incrementing the sequence number, changing the mask in the body to NM1 and inserting the cost of the new network. Then originate a new LSA for the old network [NA,NM2], with Link State ID equal to NA or'ed together with the bits that are not set in NM2 (i.e., network [NA,NM2]'s broadcast address).
o NM2はNM1よりも長い。この場合、シーケンス番号を増分し、本体のマスクをNM1に変更して新しいネットワークのコストを挿入することにより、新しいネットワーク[NA、NM1]を参照するように既存のLSA（リンク状態IDがNA）を変更します。次に、古いネットワーク[NA、NM2]の新しいLSAを作成します。リンク状態IDはNAに等しいか、NM2に設定されていないビット（つまり、ネットワーク[NA、NM2]のブロードキャストアドレス）と組み合わせます。
The above algorithm assumes that all masks are contiguous; this ensures that when two networks have the same address, one mask is more specific than the other. The algorithm also assumes that no network exists having an address equal to another network's broadcast address. Given these two assumptions, the above algorithm always produces unique Link State IDs. The above algorithm can also be reworded as follows: When originating an AS-external-LSA, try to use the network number as the Link State ID. If that produces a conflict, examine the two networks in conflict. One will be a subset of the other. For the less specific network, use the network number as the Link State ID and for the more specific use the network's broadcast address instead (i.e., flip all the "host" bits to 1). If the most specific network was originated first, this will cause you to originate two LSAs at once.
上記のアルゴリズムは、すべてのマスクが隣接していることを前提としています。これにより、2つのネットワークが同じアドレスを持っている場合、一方のマスクが他方よりも明確になります。このアルゴリズムは、別のネットワークのブロードキャストアドレスと等しいアドレスを持つネットワークが存在しないことも前提としています。これらの2つの仮定を前提として、上記のアルゴリズムは常に一意のリンク状態IDを生成します。上記のアルゴリズムは、次のように言い換えることもできます。AS-external-LSAを発信するときは、ネットワーク番号をリンク状態IDとして使用してみてください。競合が発生する場合は、競合している2つのネットワークを調べます。一方は他方のサブセットになります。それほど具体的でないネットワークでは、リンク番号IDとしてネットワーク番号を使用し、より具体的には、代わりにネットワークのブロードキャストアドレスを使用します（つまり、すべての「ホスト」ビットを1にフリップします）。最も具体的なネットワークが最初に発信された場合、これにより2つのLSAが同時に発信されます。
As an example of the algorithm, consider its operation when the following sequence of events occurs in a single router (Router A).
アルゴリズムの例として、単一のルーター（ルーターA）で次の一連のイベントが発生した場合の動作を考えます。
(1) Router A wants to originate an AS-external-LSA for [10.0.0.0,255.255.255.0]:
（1）ルータAが[10.0.0.0,255.255.255.0]のAS-external-LSAを発信したい場合：
(a) A Link State ID of 10.0.0.0 is used.
（a）10.0.0.0のリンク状態IDが使用されます。
(2) Router A then wants to originate an AS-external-LSA for [10.0.0.0,255.255.0.0]:
（2）次に、ルーターAは[10.0.0.0,255.255.0.0]のAS-external-LSAを発信する必要があります。
(a) The LSA for [10.0.0,0,255.255.255.0] is reoriginated using a new Link State ID of 10.0.0.255.
（a）[10.0.0,0,255.255.255.0]のLSAは、新しいリンク状態ID 10.0.0.255を使用して再生成されます。
(b) A Link State ID of 10.0.0.0 is used for [10.0.0.0,255.255.0.0].
（b）[10.0.0.0,255.255.0.0]には、10.0.0.0のリンク状態IDが使用されます。
(3) Router A then wants to originate an AS-external-LSA for [10.0.0.0,255.0.0.0]: (a) The LSA for [10.0.0.0,255.255.0.0] is reoriginated using a new Link State ID of 10.0.255.255.
（3）次に、ルーターAは[10.0.0.0,255.0.0.0]のAS-external-LSAを発信したいと考えています。（a）[10.0.0.0,255.255.0.0]のLSAは、次の新しいリンク状態IDを使用して再生成されます。 10.0.255.255。
(b) A Link State ID of 10.0.0.0 is used for [10.0.0.0,255.0.0.0].
（b）[10.0.0.0,255.0.0.0]には、10.0.0.0のリンク状態IDが使用されます。
(c) The network [10.0.0.0,255.255.255.0] keeps its Link State ID of 10.0.0.255.
（c）ネットワーク[10.0.0.0,255.255.255.0]は、リンク状態IDを10.0.0.255に保ちます。
F. Multiple interfaces to the same network/subnet
F.同じネットワーク/サブネットへの複数のインターフェース
There are at least two ways to support multiple physical interfaces to the same IP subnet. Both methods will interoperate with implementations of RFC 1583 (and of course this memo). The two methods are sketched briefly below. An assumption has been made that each interface has been assigned a separate IP address (otherwise, support for multiple interfaces is more of a link-level or ARP issue than an OSPF issue).
同じIPサブネットへの複数の物理インターフェイスをサポートするには、少なくとも2つの方法があります。どちらの方法も、RFC 1583（もちろんこのメモ）の実装と相互運用します。 2つの方法を以下に簡単に示します。各インターフェースには個別のIPアドレスが割り当てられていると想定されています（そうでない場合、複数のインターフェースのサポートは、OSPFの問題よりもリンクレベルまたはARPの問題の方が多くなります）。
Method 1: Run the entire OSPF functionality over both interfaces, sending and receiving hellos, flooding, supporting separate interface and neighbor FSMs for each interface, etc. When doing this all other routers on the subnet will treat the two interfaces as separate neighbors, since neighbors are identified (on broadcast and NBMA networks) by their IP address.
方法1：OSPF機能全体を両方のインターフェイスで実行します。Helloの送受信、フラッディング、各インターフェイスの個別のインターフェイスとネイバーFSMのサポートなどを行います。これを行うと、サブネット上の他のすべてのルーターは2つのインターフェイスを個別のネイバーとして扱います。ネイバーは（ブロードキャストおよびNBMAネットワーク上で）IPアドレスによって識別されます。
Method 1 has the following disadvantages:
方法1には次の欠点があります。
(1) You increase the total number of neighbors and adjacencies.
（1）ネイバーと隣接の総数を増やします。
(2) You lose the bidirectionality test on both interfaces, since bidirectionality is based on Router ID.
（2）双方向性はルーターIDに基づいているため、両方のインターフェースで双方向性テストを失います。
(3) You have to consider both interfaces together during the Designated Router election, since if you declare both to be DR simultaneously you can confuse the tie-breaker (which is Router ID).
（3）両方が同時にDRであると宣言すると、タイブレーカー（ルーターID）を混乱させる可能性があるため、指定ルーターの選定時に両方のインターフェースを一緒に検討する必要があります。
Method 2: Run OSPF over only one interface (call it the primary interface), but include both the primary and secondary interfaces in your Router-LSA.
方法2：1つのインターフェースのみでOSPFを実行し（プライマリインターフェースと呼びます）、ルーターLSAにプライマリインターフェースとセカンダリインターフェースの両方を含めます。
Method 2 has the following disadvantages:
方法2には、次の欠点があります。
(1) You lose the bidirectionality test on the secondary interface.
（1）セカンダリインターフェイスの双方向性テストを失います。
(2) When the primary interface fails, you need to promote the secondary interface to primary status.
（2）プライマリインターフェースに障害が発生した場合、セカンダリインターフェースをプライマリステータスに昇格させる必要があります。
G. Differences from RFC 2178
G. RFC 2178との違い
This section documents the differences between this memo and RFC 2178. All differences are backward-compatible. Implementations of this memo and of RFCs 2178, 1583, and 1247 will interoperate.
このセクションでは、このメモとRFC 2178の違いについて説明します。すべての違いには下位互換性があります。このメモとRFC 2178、1583、および1247の実装は相互運用します。
G.1 Flooding modifications
G.1フラッディングの変更
Three changes have been made to the flooding procedure in Section 13.
セクション13では、洪水手順に3つの変更が加えられています。
The first change is to step 4 in Section 13. Now MaxAge LSAs are acknowledged and then discarded only when both a) there is no database copy of the LSA and b) none of router's neighbors are in states Exchange or Loading. In all other cases, the MaxAge LSA is processed like any other LSA, installing the LSA in the database and flooding it out the appropriate interfaces when the LSA is more recent than the database copy (Step 5 of Section 13). This change also affects the contents of Table 19.
最初の変更は、セクション13のステップ4です。MaxAgeLSAが確認されて破棄されるのは、a）LSAのデータベースコピーがなく、b）ルーターのネイバーがいずれもExchangeまたはLoadingの状態でない場合のみです。その他の場合はすべて、MaxAge LSAは他のLSAと同様に処理され、LSAがデータベースにインストールされ、LSAがデータベースコピーよりも新しい場合に適切なインターフェイスにフラッディングされます（セクション13のステップ5）。この変更は、表19の内容にも影響します。
The second change is to step 5a in Section 13. The MinLSArrival check is meant only for LSAs received during flooding, and should not be performed on those LSAs that the router itself originates.
2番目の変更は、セクション13のステップ5aへの変更です。MinLSArrivalチェックは、フラッディング中に受信されたLSAのみを対象としており、ルーター自体が発信するLSAに対しては実行しないでください。
The third change is to step 8 in Section 13. Confusion between routers as to which LSA instance is more recent can cause a disastrous amount of flooding in a link-state protocol (see [Ref26]). OSPF guards against this problem in two ways: a) the LS age field is used like a TTL field in flooding, to eventually remove looping LSAs from the network (see Section 13.3), and b) routers refuse to accept LSA updates more frequently than once every MinLSArrival seconds (see Section 13). However, there is still one case in RFC 2178 where disagreements regarding which LSA is more recent can cause a lot of flooding traffic: responding to old LSAs by reflooding the database copy. For this reason, Step 8 of Section 13 has been amended to only respond with the database copy when that copy has not been sent in any Link State Update within the last MinLSArrival seconds.
3番目の変更は、セクション13のステップ8です。どのLSAインスタンスがより新しいかについてのルーター間の混乱は、リンクステートプロトコルで壊滅的な量のフラッディングを引き起こす可能性があります（[Ref26]を参照）。 OSPFは、この問題に対して2つの方法で保護します。a）LSエージフィールドは、フラッディングでTTLフィールドのように使用され、最終的にループLSAをネットワークから削除します（セクション13.3を参照）。b）ルーターは、LSAアップデートの受け入れをより頻繁に拒否します。 MinLSArrival秒ごとに1回（セクション13を参照）。ただし、RFC 2178には、どのLSAがより新しいかに関する不一致によって大量のフラッディングトラフィックが発生する可能性がある1つのケースが残っています。データベースコピーを再フラッディングすることにより、古いLSAに応答します。このため、セクション13のステップ8は、データベースのコピーが最後のMinLSArrival秒以内にリンク状態の更新で送信されなかった場合にのみデータベースコピーで応答するように修正されました。
G.2 Changes to external path preferences
G.2外部パス設定の変更
There is still the possibility of a routing loop in RFC 2178 when both a) virtual links are in use and b) the same external route is being imported by multiple ASBRs, each of which is in a separate area. To fix this problem, Section 16.4.1 has been revised. To choose the correct ASBR/forwarding address, intra-area paths through non-backbone areas are always preferred. However, intra-area paths through the backbone area (Area 0) and inter-area paths are now of equal preference, and must be compared solely based on cost.
RFC 2178では、a）仮想リンクが使用されており、b）同じ外部ルートがそれぞれ別々のエリアにある複数のASBRによってインポートされている場合でも、ルーティングループが発生する可能性があります。この問題を修正するために、セクション16.4.1が改訂されました。正しいASBR /転送アドレスを選択するには、非バックボーンエリアを通るエリア内パスが常に優先されます。ただし、バックボーンエリアを経由するエリア内パス（エリア0）とエリア間パスの優先度は等しくなり、コストのみに基づいて比較する必要があります。
The reasoning behind this change is as follows. When virtual links are in use, an intra-area backbone path for one router can turn into an inter-area path in a router several hops closer to the destination. Hence, intra-area backbone paths and inter-area paths must be of equal preference. We can safely compare their costs, preferring the path with the smallest cost, due to the calculations in Section 16.3.
この変更の理由は次のとおりです。仮想リンクが使用されている場合、1つのルーターのエリア内バックボーンパスは、宛先に数ホップ近いルーター内のエリア間パスに変わります。したがって、エリア内バックボーンパスとエリア間パスの優先順位は等しくなければなりません。セクション16.3の計算により、コストを安全に比較し、コストが最小のパスを優先することができます。
Thanks to Michael Briggs and Jeremy McCooey of the UNH InterOperability Lab for pointing out this problem.
この問題を指摘してくれたUNH InterOperability LabのMichael BriggsとJeremy McCooeyに感謝します。
G.3 Incomplete resolution of virtual next hops
G.3仮想ネクストホップの不完全な解決
One of the functions of the calculation in Section 16.3 is to determine the actual next hop(s) for those destinations whose next hop was calculated as a virtual link in Sections 16.1 and 16.2. After completion of the calculation in Section 16.3, any paths calculated in Sections 16.1 and 16.2 that still have unresolved virtual next hops should be discarded.
セクション16.3の計算の機能の1つは、セクション16.1および16.2で仮想リンクとして計算されたネクストホップの宛先の実際のネクストホップを決定することです。セクション16.3での計算が完了した後、セクション16.1および16.2で計算された未解決の仮想ネクストホップがまだ残っているパスはすべて破棄する必要があります。
G.4 Routing table lookup
G.4ルーティングテーブルのルックアップ
The routing table lookup algorithm in Section 11.1 has been modified to reflect current practice. The "best match" routing table entry is now always selected to be the one providing the most specific (longest) match. Suppose for example a router is forwarding packets to the destination 192.9.1.1. A routing table entry for 192.9.1/24 will always be a better match than the routing table entry for 192.9/16, regardless of the routing table entries' path-types. Note however that when multiple paths are available for a given routing table entry, the calculations in Sections 16.1, 16.2, and 16.4 always yield the paths having the most preferential path-type. (Intra-area paths are the most preferred, followed in order by inter-area, type 1 external and type 2 external paths; see Section 11).
セクション11.1のルーティングテーブルルックアップアルゴリズムは、現在の慣行を反映するように変更されています。 「最も一致する」ルーティングテーブルエントリは、最も具体的な（最も長い）一致を提供するものとして常に選択されるようになりました。たとえば、ルーターが宛先192.9.1.1にパケットを転送しているとします。ルーティングテーブルエントリのパスタイプに関係なく、192.9.1 / 24のルーティングテーブルエントリは、192.9 / 16のルーティングテーブルエントリよりも常に一致します。ただし、特定のルーティングテーブルエントリに複数のパスが使用可能な場合、セクション16.1、16.2、および16.4の計算では、常に最も優先的なパスタイプのパスが生成されることに注意してください。 （エリア内パスが最も優先され、エリア間タイプ1外部パスとタイプ2外部パスが順に続きます。セクション11を参照してください）。
Security Considerations
セキュリティに関する考慮事項
All OSPF protocol exchanges are authenticated. OSPF supports multiple types of authentication; the type of authentication in use can be configured on a per network segment basis. One of OSPF's authentication types, namely the Cryptographic authentication option, is believed to be secure against passive attacks and provide significant protection against active attacks. When using the Cryptographic authentication option, each router appends a "message digest" to its transmitted OSPF packets. Receivers then use the shared secret key and received digest to verify that each received OSPF packet is authentic.
すべてのOSPFプロトコル交換が認証されます。 OSPFは複数のタイプの認証をサポートしています。使用する認証のタイプは、ネットワークセグメントごとに設定できます。 OSPFの認証タイプの1つ、つまり暗号化認証オプションは、パッシブ攻撃に対して安全であり、アクティブ攻撃に対して重要な保護を提供すると考えられています。暗号化認証オプションを使用する場合、各ルーターは送信されたOSPFパケットに「メッセージダイジェスト」を追加します。次に、受信者は共有秘密鍵と受信したダイジェストを使用して、受信した各OSPFパケットが本物であることを確認します。
The quality of the security provided by the Cryptographic authentication option depends completely on the strength of the message digest algorithm (MD5 is currently the only message digest algorithm specified), the strength of the key being used, and the correct implementation of the security mechanism in all communicating OSPF implementations. It also requires that all parties maintain the secrecy of the shared secret key.
暗号化認証オプションによって提供されるセキュリティの品質は、メッセージダイジェストアルゴリズムの強度（MD5は現在指定されている唯一のメッセージダイジェストアルゴリズムです）、使用されるキーの強度、およびセキュリティメカニズムの正しい実装に完全に依存します。すべての通信OSPF実装。また、すべての関係者が共有秘密鍵の秘密を保持することも必要です。
None of the OSPF authentication types provide confidentiality. Nor do they protect against traffic analysis. Key management is also not addressed by this memo.
OSPF認証タイプはどれも機密性を提供しません。また、トラフィック分析に対する保護も行いません。このメモでは、鍵の管理についても触れられていません。
For more information, see Sections 8.1, 8.2, and Appendix D.
詳細については、セクション8.1、8.2、および付録Dを参照してください。
Author's Address
著者のアドレス
John Moy Ascend Communications, Inc. 1 Robbins Road Westford, MA 01886
John Moy Ascend Communications、Inc. 1 Robbins Road Westford、MA 01886
Phone: 978-952-1367 Fax: 978-392-2075 EMail: jmoy@casc.com
電話：978-952-1367ファックス：978-392-2075メール：jmoy@casc.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができます。 、ただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。