RFC1247 日本語訳
1247 OSPF Version 2. J. Moy. July 1991. (Format: TXT=433332, PS=989724, PDF=490300 bytes) (Obsoletes RFC1131) (Obsoleted by RFC1583) (Updated by RFC1349) (Also RFC1246, RFC1245) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Moy Request for Comments: 1247 Proteon, Inc. Obsoletes: RFC 1131 July 1991
Moyがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 1247 Proteon Inc.は以下を時代遅れにします。 RFC1131 1991年7月
OSPF Version 2
OSPFバージョン2
Status of this Memo
このMemoの状態
This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the ``IAB Official Protocol Standards'' for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This memo documents version 2 of the OSPF protocol. OSPF is a link- state based routing protocol. It is designed to be run internal to a single Autonomous System. Each OSPF router maintains an identical database describing the Autonomous System's topology. From this database, a routing table is calculated by constructing a shortest-path tree.
このメモはOSPFプロトコルのバージョン2を記録します。 OSPFは州が基礎づけたリンクルーティング・プロトコルです。 それは、独身のAutonomous Systemに内部で実行されるように設計されています。 それぞれのOSPFルータはAutonomous Systemのトポロジーについて説明する同じデータベースを維持します。 このデータベースから、経路指定テーブルは、最短パス木を組み立てることによって、計算されます。
OSPF recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic. OSPF provides support for equal-cost multipath. Separate routes can be calculated for each IP type of service. An area routing capability is provided, enabling an additional level of routing protection and a reduction in routing protocol traffic. In addition, all OSPF routing protocol exchanges are authenticated.
最小ルーティング・プロトコルトラフィックを利用して、OSPF recalculatesは位相的に直面してすばやく変化を発送します。 OSPFは等価コストマルチパスのサポートを提供します。 それぞれのIPタイプのサービスのために別々のルートを計算できます。 追加レベルのルーティング保護とルーティング・プロトコルトラフィックの減少を可能にして、領域ルーティング能力を提供します。 さらに、すべてのOSPFルーティング・プロトコル交換が認証されます。
Version 1 of the OSPF protocol was documented in RFC 1131. The differences between the two versions are explained in Appendix F.
OSPFプロトコルのバージョン1はRFC1131に記録されました。 2つのバージョンの違いはAppendix Fで説明されます。
Please send comments to ospf@trantor.umd.edu.
コメントを ospf@trantor.umd.edu に送ってください。
1. Introduction
1. 序論
This document is a specification of the Open Shortest Path First (OSPF) internet routing protocol. OSPF is classified as an Internal Gateway Protocol (IGP). This means that it distributes routing information between routers belonging to a single Autonomous System. The OSPF protocol is based on SPF or link-state technology. This is a departure
このドキュメントはオープンShortest Path First(OSPF)インターネットルーティング・プロトコルの仕様です。 OSPFはInternalゲートウェイプロトコル(IGP)として分類されます。 これは、独身のAutonomous Systemに属すルータの間にルーティング情報を分配することを意味します。 OSPFプロトコルはSPFかリンク州の技術に基づいています。 これは出発です。
[Moy] [Page 1] RFC 1247 OSPF Version 2 July 1991
[Moy][1ページ]RFC1247OSPFバージョン1991年7月2日
from the Bellman-Ford base used by traditional internet routing protocols.
伝統的なインターネットルーティング・プロトコルによって使用されるBellman-フォードベースから。
The OSPF protocol was developed by the OSPF working group of the Internet Engineering Task Force. It has been designed expressly for the internet environment, including explicit support for IP subnetting, TOS-based routing 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ワーキンググループによって開発されました。 それはインターネット環境のために明白に設計されています、IPサブネッティングの明白なサポート、TOSベースのルーティング、および外部的に派生しているルーティング情報のタグ付けを含んでいて。 OSPFはまた、ルーティングアップデートの認証に備えて、アップデートを送るか、または受けるとき、IPマルチキャストを利用します。 さらに、すばやくトポロジー変化に応じますが、少量のルーティング・プロトコルトラフィックにかかわるプロトコルを作成するために多くの仕事をしました。
The author would like to thank Rob Coltun, Milo Medin, Mike Petry and the rest of the OSPF working group for the ideas and support they have given to this project.
作者は、このプロジェクトに与えたのをロブColtun、ミロ・メディン、マイクPetry、および考えとサポートのためのOSPFワーキンググループの残りに感謝したがっています。
1.1 Protocol overview
1.1 プロトコル概要
OSPF routes IP packets based solely on the destination IP address and IP Type of Service 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パケットのヘッダーで見つけられたServiceの送付先IPアドレスとIP Typeに基づくIPパケットを発送します。 IPパケットは「そのままで」発送されます--彼らがAutonomous Systemを通過するとき、それらはどんな一層のプロトコルヘッダーでもカプセル化されません。 OSPFはダイナミックルーティングプロトコルです。 それは、AS(ルータインタフェース失敗などの)にすぐに位相的な変化を検出して、集合の一区切りの後に新しい無輪のルートを計算します。 この期間の集合は、短く、最小ルーティングトラフィックにかかわります。
In an SPF-based routing protocol, each router maintains a database describing the Autonomous System's topology. 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.
SPFベースのルーティング・プロトコルでは、各ルータはAutonomous Systemのトポロジーについて説明するデータベースを維持します。 それぞれの参加ルータには、同じデータベースがあります。 このデータベースの各個体は特定のルータの地方の状態(例えば、ルータの使用可能なインタフェースと届いている隣人)です。 ルータは氾濫で地方の状態をAutonomous Systemに分配します。
All routers run the exact same algorithm, in parallel. From the topological database, each router constructs a tree of shortest paths with itself as root. This shortest-path tree gives the route to each destination in the Autonomous System. Externally derived routing information appears on the tree as leaves.
すべてのルータが平行の全く同じアルゴリズムを実行します。 位相的なデータベースから、各ルータは根としてそれ自体で最短パスの木を組み立てます。 この最短パス木はAutonomous Systemの各目的地に進発令を下します。 外部的に派生しているルーティング情報は葉として木の上に現れます。
OSPF calculates separate routes for each Type of Service (TOS). 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はService(TOS)の各Typeのために別々のルートを計算します。 目的地への数個の等しい費用ルートが存在するとき、トラフィックはそれらの中で等しく分配されます。 ルートの費用はaシングル点によってメートル法で説明されます。
OSPF allows sets of networks to be grouped together. Such a grouping is
OSPFは、ネットワークのセットが一緒に分類されるのを許容します。 そのような組分けはそうです。
[Moy] [Page 2] RFC 1247 OSPF Version 2 July 1991
[Moy][2ページ]RFC1247OSPFバージョン1991年7月2日
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.
領域と呼ばれます。 Autonomous Systemの残り領域のトポロジーを隠されます。 この情報隠蔽はルーティングトラフィックのかなりの減少を可能にします。 また、領域の中のルーティングも領域の自己のトポロジーだけのそばで決定しています、悪いルーティングデータから領域保護を貸して。 領域はIPサブネット化したネットワークの一般化です。
OSPF enables the flexible configuration of IP subnets. Each route distributed by OSPF has a destination and mask. Two different subnets of the same IP network number may have different sizes (i.e., different masks). This is commonly referred to as variable length subnets. A packet is routed to the best (i.e., longest or most specific) match. Host routes are considered to be subnets whose masks are "all ones" (0xffffffff).
OSPFはIPサブネットのフレキシブルな構成を可能にします。 OSPFによって分配された各ルートは目的地とマスクを持っています。 同じIPネットワーク・ナンバーの2つの異なったサブネットには、異なったサイズ(すなわち、異なったマスク)があるかもしれません。 これは一般的に可変長サブネットと呼ばれます。 パケットは最も良い(すなわち、最も長いか最も特定の)マッチに発送されます。 ホストルートはマスクが「すべてのもの」(0xffffffff)であるサブネットであると考えられます。
All OSPF protocol exchanges are authenticated. This means that only trusted routers can participate in the Autonomous System's routing. A variety of authentication schemes can be used; a single authentication scheme is configured for each area. This enables some areas to use much stricter authentication than others.
すべてのOSPFプロトコル交換が認証されます。 これは、それが、ルータがAutonomous Systemのルーティングに参加できると信じただけであることを意味します。 さまざまな認証体系を使用できます。 ただ一つの認証体系は各領域に構成されます。 これは、いくつかの領域が他のものよりはるかに厳しい認証を使用するのを可能にします。
Externally derived routing data (e.g., routes learned from the Exterior Gateway Protocol (EGP)) is passed transparently 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 boundaries of the Autonomous System.
外部的に派生しているルーティングデータ(例えばExteriorゲートウェイプロトコル(EGP)から学習されたルート)は透過的にAutonomous System中で通過されます。 この外部的に派生しているデータはOSPFプロトコルのリンク州のデータから別々に保たれます。 また、広告ルータで各外部経路にタグ付けをすることができます、Autonomous Systemの境界でルータの間の追加情報の通過を可能にして。
1.2 Definitions of commonly used terms
1.2 一般的に使用された期間の定義
Here is a collection of definitions for terms that have a specific meaning to the protocol and that are used throughout the text. The reader unfamiliar with the Internet Protocol Suite is referred to [RS- 85-153] for an introduction to IP.
ここに、定義の収集が特定の意味をプロトコルに持って、テキスト中で使用される期間、あります。 インターネットプロトコルSuiteになじみのない読者はIPへの紹介について言及されます[RS85-153]。
Router
A level three Internet Protocol packet switch. Formerly called a
gateway in much of the IP literature.
ルータA級試験threeインターネットプロトコルパケット交換機。 以前、IP文学の多くでゲートウェイと呼ばれます。
Autonomous System
A group of routers exchanging routing information via a common
routing protocol. Abbreviated as AS.
一般的なルーティングでルーティング情報を交換するルータの自治のSystem Aグループは議定書を作ります。 簡略化されています。
Internal Gateway Protocol
The routing protocol spoken by the routers belonging to an
Autonomous system. Abbreviated as IGP. Each Autonomous System has
Autonomousシステムに属すルータによって話されて、ルーティングが議定書の中で述べる内部のゲートウェイプロトコル。 IGPが簡略化されています。 各自律システムはそうしました。
[Moy] [Page 3] RFC 1247 OSPF Version 2 July 1991
[Moy][3ページ]RFC1247OSPFバージョン1991年7月2日
a single IGP. Different Autonomous Systems may be running different
IGPs.
独身のIGP。 異なったAutonomous Systemsは実行している異なったIGPsであるかもしれません。
Router ID
A 32-bit number assigned to each router running the OSPF protocol.
This number uniquely identifies the router within an Autonomous
System.
OSPFを実行しながら各ルータに割り当てられたルータのIDのA32ビットの番号は議定書を作ります。 この数はAutonomous Systemの中で唯一ルータを特定します。
Network
In this paper, an IP network or subnet. It is possible for one
physical network to be assigned multiple IP network/subnet numbers.
We consider these to be separate networks. Point-to-point physical
networks are an exception - they are considered a single network no
matter how many (if any at all) IP network/subnet numbers are
assigned to them.
これほど紙のIn、IPネットワークまたはサブネットをネットワークでつないでください。 複数のIPネットワーク/サブネット番号が1つの物理ネットワークに配属されるのは、可能です。 私たちは、これらが別々のネットワークであると考えます。 二地点間物理ネットワークは例外です--いくつの(全くいずれかであるなら)IPネットワーク/サブネット番号がそれらに割り当てられても、それらはただ一つのネットワークであると考えられます。
Network mask
A 32-bit number indicating the range of IP addresses residing on a
single IP network/subnet. This specification displays network masks
as hexadecimal numbers. For example, the network mask for a class C
IP network is displayed as 0xffffff00. Such a mask is often
displayed elsewhere in the literature as 255.255.255.0.
IPの範囲を示すネットワークのマスクのAの32ビットの番号がただ一つのIPネットワーク/サブネットの住んでいることを扱います。 この仕様は16進数としてネットワークマスクを表示します。 例えば、0xffffff00としてクラスC IPネットワークのためのネットワークマスクを表示します。 255.255として文学のほかの場所に表示して、しばしばそのようなマスクはそうです。.255 .0。
Multi-access networks
Those physical networks that support the attachment of multiple
(more than two) routers. Each pair of routers on such a network is
assumed to be able to communicate directly (e.g., multi-drop
networks are excluded).
マルチアクセスは複数の(2以上)ルータの付属をサポートするThose物理ネットワークをネットワークでつなぎます。 そのようなネットワークのそれぞれの組のルータが直接伝達できると思われます(例えばマルチ低下しているネットワークは除かれます)。
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. On multi-
access networks, neighbors are dynamically discovered by OSPF's
Hello Protocol.
一般的なネットワークにインタフェースを持っているルータTwoルータを近所付き合いさせます。 マルチアクセスネットワークでは、隣人はOSPFのHelloプロトコルによってダイナミックに発見されます。
Adjacency
A relationship formed between selected neighboring routers for the
purpose of exchanging routing information. Not every pair of
neighboring routers become adjacent.
隣接番組A関係はルーティング情報を交換する目的のために選択された隣接しているルータの間で形成されました。 すべての組のどんな隣接しているルータも隣接するようになりません。
[Moy] [Page 4] RFC 1247 OSPF Version 2 July 1991
[Moy][4ページ]RFC1247OSPFバージョン1991年7月2日
Link state advertisement
Describes to the local state of a router or network. 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 topological database.
ルータかネットワークの地方の事情に州の広告Describesをリンクしてください。 これはルータのインタフェースと隣接番組の状態を含んでいます。 それぞれのリンク州の広告は経路ドメイン中で水につかっています。 すべてのルータとネットワークの集まっているリンク州の広告はプロトコルの位相的なデータベースを形成します。
Hello protocol
The part of the OSPF protocol used to establish and maintain
neighbor relationships. On multi-access networks the Hello protocol
can also dynamically discover neighboring routers.
こんにちは、OSPFの部分が議定書の中で述べるプロトコルは以前はよくそうしていました。隣人が関係であることを確証して、支持してください。 また、マルチアクセスネットワークでは、Helloプロトコルはダイナミックに隣接しているルータを発見できます。
Designated Router
Each multi-access network that has at least two attached routers has
a Designated Router. The Designated Router generates a link state
advertisement for the multi-access network and has other special
responsibilities in the running of the protocol. The Designated
Router is elected by the Hello Protocol.
少なくとも2つの付属ルータを持っている指定されたRouter EachマルチアクセスネットワークがDesignated Routerを持っています。 Designated Routerはマルチアクセスネットワークのためにリンク州の広告を作って、プロトコルの稼働で他の特別な責任を持っています。 Designated RouterはHelloプロトコルによって選出されます。
The Designated Router concept enables a reduction in the number of
adjacencies required on a multi-access network. This in turn
reduces the amount of routing protocol traffic and the size of the
topological database.
Designated Router概念はマルチアクセスネットワークで必要である隣接番組の数の減少を可能にします。 これはルーティング・プロトコルトラフィックの量と位相的なデータベースのサイズを順番に減少させます。
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 PDNs, and the ethernet data
link layer for ethernets.
基本的さがネットワークでつなぐ低レベルプロトコルはインターネットプロトコルに対するサービスを提供するプロトコルにアクセスします、そして、順番に、OSPFは議定書を作ります。 これらに関する例は、PDNsのためのX.25パケットとフレーム・レベルと、イーサネットのためのイーサネットデータ・リンク層です。
1.3 Brief history of SPF-based routing technology
1.3 SPFベースのルーティング技術に関する小史
OSPF is an SPF-based routing protocol. Such protocols are also referred to in the literature as link-state or distributed-database protocols. This section gives a brief description of the developments in SPF-based technology that have influenced the OSPF protocol.
OSPFはSPFベースのルーティング・プロトコルです。 また、そのようなプロトコルは文学にリンク状態か分散データベースプロトコルと呼ばれます。 このセクションはSPFベースの技術におけるOSPFプロトコルに影響を及ぼした開発の簡単な説明を与えます。
The first SPF-based routing protocol was developed for use in the ARPANET packet switching network. This protocol is described in [McQuillan]. It has formed the starting point for all other SPF-based 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.
最初のSPFベースのルーティング・プロトコルはアルパネットパケット交換網における使用のために開発されました。 このプロトコルは[マッキラン]で説明されます。 それは他のすべてのSPFベースのプロトコルのための出発点を形成しました。 均質のArpanet環境(すなわち、同期シリアル・ラインによって接続された単一のベンダーパケット交換機)はオリジナルのプロトコルの設計と実装を簡素化しました。
Modifications to this protocol were proposed in [Perlman]. These modifications dealt with increasing the fault tolerance of the routing protocol through, among other things, adding a checksum to the link
このプロトコルへの変更は[パールマン]で提案されました。 リンクにチェックサムを特に加えることでルーティング・プロトコルの耐障害性を増強する対処されたこれらの変更
[Moy] [Page 5] RFC 1247 OSPF Version 2 July 1991
[Moy][5ページ]RFC1247OSPFバージョン1991年7月2日
state advertisements (thereby detecting database corruption). The paper also included means for reducing the routing traffic overhead in an SPF-based protocol. This was accomplished by introducing mechanisms which enabled the interval between link state advertisements to be increased by an order of magnitude.
広告を述べてください(その結果、データベース不正を検出します)。 また、含まれていた紙は、ルーティングトラフィックオーバーヘッドを下げるためにSPFベースのプロトコルを意味します。 これは、リンク州の広告の間隔が1桁増強されるのを可能にしたメカニズムを紹介することによって、達成されました。
An SPF-based algorithm has also been proposed for use as an ISO IS-IS routing protocol. This protocol is described in [DEC]. 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 a link state advertisement for the network.
また、SPFベースのアルゴリズムが使用のために提案された、ISO IS存在、ルーティング・プロトコル このプロトコルは[12月]のときに説明されます。 放送網の上で作動するとき、プロトコルはデータのためのメソッドとルーティング交通量削減を含んでいます。 これはネットワークのためのリンク州の広告がその時起因する各放送網のためにDesignated Routerの選挙で達成されます。
The OSPF subcommittee 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 algorithm has been modified for efficient operation in the internet environment.
IETFのOSPF小委員会はOSPFプロトコルを開発する際にこの仕事を広げました。 Designated Router概念は、トラフィックが必要としたルーティングの量をさらに減少させるために大いに高められました。 マルチキャスト能力は追加ルーティング帯域幅削減に利用されます。 情報隠蔽/保護/減少を可能にしながら、領域ルーティング体系を開発してあります。 最終的に、アルゴリズムはインターネット環境における効率的な操作のために変更されました。
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, configuration items and required management statistics 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. The architectural constants are explained in Appendix B. The configurable constants are explained in Appendix C.
テキストで遭遇するHelloIntervalなどのラベルはプロトコル定数について言及します。 それらは構成可能であるかもしれません。 建築定数はAppendix B.で説明されます。構成可能な定数はAppendix Cで説明されます。
The detailed specification of the protocol is presented in terms of data structures. This is done in order to make the explanation more precise. Implementations of the protocol are required to support the functionality described, but need not use the precise data structures that appear in this paper.
プロトコルの仕様詳細はデータ構造で提示されます。 説明をより正確にするようにこれをします。 プロトコルの実装は、機能性が説明したサポートに必要ですが、この紙に現れる正確な資料構造を使用する必要はありません。
2. The Topological Database
2. 位相的なデータベース
The database of the Autonomous System's topology 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
Autonomous Systemのトポロジーに関するデータベースは有向グラフについて説明します。 グラフの頭頂はルータとネットワークから成ります。 それらが物理的な二地点間ネットワークを通して付けられているとき、グラフ縁は2つのルータを接続します。 ルータをネットワークに関連づける縁
[Moy] [Page 6] RFC 1247 OSPF Version 2 July 1991
[Moy][6ページ]RFC1247OSPFバージョン1991年7月2日
indicates that the router has an interface on the network.
ルータがネットワークにインタフェースを持っているのを示します。
The vertices of the graph can be further typed according to function. Only some of these types carry transit data traffic; that is, traffic that is neither locally originated nor locally destined. Vertices that can carry transit traffic are indicated on the graph by having both incoming and outgoing edges.
機能に従って、グラフの頭頂をさらにタイプできます。 これらの何人かのタイプだけがトランジットデータ通信量を運びます。 すなわち、どちらもでないトラフィックは、局所的に起因して、局所的に運命づけられました。 トランジットトラフィックを運ぶことができる頭頂が、グラフで両方の送受信の強味を持っていることによって、示されます。
Vertex type Vertex name Transit?
_____________________________________
1 Router yes
2 Network yes
3 Stub network no
頂点タイプVertex名前Transit? _____________________________________ 1つのルータはい2Networkはい3のStubネットワークノー
Table 1: OSPF vertex types.
テーブル1: OSPF頂点はタイプされます。
OSPF supports the following types of physical networks:
OSPFは以下のタイプの物理ネットワークをサポートします:
Point-to-point networks
A network that joins a single pair of routers. A 56Kb serial line
is an example of a point-to-point network.
ポイントツーポイントは1組のルータに合流するAネットワークをネットワークでつなぎます。 56KBのシリアル・ラインは二地点間ネットワークに関する例です。
Broadcast networks
Networks supporting many (more than two) attached routers, together
with the capability to address a single physical message to all of
the attached routers (broadcast). Neighboring routers are
discovered dynamically on these nets using OSPF's Hello Protocol.
The Hello Protocol itself takes advantage of the broadcast
capability. The protocol makes further use of multicast
capabilities, if they exist. An ethernet is an example of a
broadcast network.
多く(2以上)をサポートする放送網Networksがルータを付けました、付属ルータ(放送)のすべてにただ一つの物理メッセージを扱う能力と共に。 隣接しているルータは、これらのネットでOSPFのHelloプロトコルを使用することでダイナミックに発見されます。 Helloプロトコル自体は放送能力を利用します。 存在しているなら、プロトコルはさらにマルチキャスト能力を利用します。 イーサネットは放送網に関する例です。
Non-broadcast networks
Networks supporting many (more than two) routers, but having no
broadcast capability. Neighboring routers are also discovered on
these nets using OSPF's Hello Protocol. However, due to the lack of
broadcast capability, some configuration information is necessary
for the correct operation of the Hello Protocol. On these networks,
OSPF protocol packets that are normally multicast need to be sent to
each neighboring router, in turn. An X.25 Public Data Network (PDN)
is an example of a non-broadcast network.
多くの(2以上)ルータをサポートしますが、放送能力が全くない非放送網Networks。 また、隣接しているルータは、これらのネットでOSPFのHelloプロトコルを使用することで発見されます。 しかしながら、放送能力の不足のために、何らかの設定情報がHelloプロトコルの正しい操作に必要です。 これらのネットワークでは、OSPFは通常、順番にそれぞれの隣接しているルータに送られるべきマルチキャストの必要性であるパケットについて議定書の中で述べます。 X.25 Public Data Network(PDN)は非放送網に関する例です。
[Moy] [Page 7] RFC 1247 OSPF Version 2 July 1991
[Moy][7ページ]RFC1247OSPFバージョン1991年7月2日
The neighborhood of each network node in the graph depends on whether the network has multi-access capabilities (either broadcast or non- broadcast) and, if so, the number of routers having an interface to the network. The three cases are depicted in Figure 1. Rectangles indicate routers. Circles and oblongs indicate multi-access networks. Router names are prefixed with the letters RT and network names with N. Router interface names are prefixed by I. Lines between routers indicate point-to-point networks. The left side of the figure shows a network with its connected routers, with the resulting graph shown on the right.
そして、グラフによるそれぞれのネットワーク・ノードの近所がネットワークにはマルチアクセス能力(放送されたか、非放送している)があるかどうかによる、そうだとすれば、ネットワークにインタフェースを持っているルータの数。 3つのケースが図1に表現されます。 長方形はルータを示します。 円と長方形はマルチアクセスネットワークを示します。 ルータ名はN.がある手紙RTとネットワーク名で前に置かれています。Routerインタフェース名はルータの間の線が、ポイントツーポイントがネットワークでつなぐのを示すI.によって前に置かれています。 図の左側は接続ルータでネットワークを見せています、右に示される結果として起こるグラフで。
Two routers joined by a point-to-point network are represented in the directed graph as being directly connected by a pair of edges, one in each direction. Interfaces to physical point-to-point networks need not be assigned IP addresses. Such a point-to-point network is called unnumbered. The graphical representation of point-to-point networks is designed so that unnumbered networks can be supported naturally. When interface addresses exist, they are modelled as stub routes. Note that each router would then have a stub connection to the other router's interface address (see Figure 1).
二地点間ネットワークによって合流された2つのルータが1組の縁によって直接接続されるとして有向グラフで表されて、あるコネが各方向です。 IPアドレスは物理的な二地点間ネットワークへのインタフェースに割り当てられる必要はありません。 そのような二地点間ネットワークは無数であると呼ばれます。 二地点間ネットワークのグラフ表示は、自然に無数のネットワークをサポートできるように設計されています。 インターフェース・アドレスが存在するとき、それらはスタッブルートとしてモデル化されます。 次に、各ルータにはもう片方のルータのインターフェース・アドレスにはスタッブ接続があることに注意してください(図1を見てください)。
When multiple routers are attached to a multi-access network, the directed graph shows all routers bidirectionally connected to the network vertex (again, see Figure 1). If only a single router is attached to a multi-access network, the network will appear in the directed graph as a stub connection.
複数のルータがマルチアクセスネットワークに付けられているとき、有向グラフは、双方向がネットワーク頂点に接続したのを(もう一度、図1を見てください)すべてのルータに示します。 ただ一つのルータだけがマルチアクセスネットワークに付けられると、ネットワークはスタッブ接続として有向グラフに現れるでしょう。
Each network (stub or transit) in the graph has an IP address and associated network mask. The mask indicates the number of nodes on the network. Hosts attached directly to routers (referred to as host routes) appear on the graph as stub networks. The network mask for a host route is always 0xffffffff, which indicates the presence of a single node.
グラフによる各ネットワーク(スタッブかトランジット)には、IPアドレスと関連ネットワークマスクがあります。 マスクはネットワークのノードの数を示します。 ルータ(ホストルートと呼ばれる)への直接添付のホストはスタッブネットワークとしてグラフで現れます。 いつもホストルートへのネットワークマスクは0xffffffffです。(その0xffffffffはただ一つのノードの存在を示します)。
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
図2はAutonomous Systemのサンプル地図を示しています。 H1とラベルされた長方形はホストを示します。(ルータRT12にはそのホストは、SLIP接続がいます)。 したがって、ルータRT12はホストルートの広告を出しています。 間の線
______________________________________
______________________________________
(Figure not included in text version.)
(テキストバージョンに含まれていなかった図。)
Figure 1: Network map components
______________________________________
図1: ネットワーク地図の部品______________________________________
[Moy] [Page 8] RFC 1247 OSPF Version 2 July 1991
[Moy][8ページ]RFC1247OSPFバージョン1991年7月2日
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 EGP connections to other Autonomous Systems. A set of EGP-learned routes have been displayed for both of these routers.
ルータは物理的な二地点間ネットワークを示します。 ポイントからポイントへのインターフェース・アドレスが配属された唯一のネットワークがルータのRT6とRT10を接合するものです。 他のAutonomous SystemsにはルータのRT5とRT7がEGP接続がいます。これらのルータの両方のために1セットのEGPが学術的なルートを表示しました。
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 EGP-learned routes).
費用はそれぞれのルータインタフェースのアウトプット側に関連しています。 この費用はシステム管理者が構成可能です。 費用が低ければ低いほど、インタフェースは、データ通信量を進めるのにより使用されそうです。 また、コストも外部的に派生しているルーティングデータ(例えば、EGPが学術的なルート)に関連しています。
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 topological database (or what has been referred to above as the directed graph) is pieced together from link state advertisements generated by the routers. The neighborhood of each transit vertex is represented in a single, separate link state advertisement. Figure 4 shows graphically the link state representation of the two kinds of transit vertices: routers and multi-access networks. Router RT12 has an
位相的なデータベース(何が有向グラフとして上と呼ばれた)はルータによって作られたリンク州の広告から継ぎを当てられます。 それぞれのトランジット頂点の近所は単一の、そして、別々のリンク州の広告で代表されます。 図4はグラフィカルに2種類のトランジット頭頂のリンク州の表現を示しています: ルータとマルチアクセスネットワーク。 ルータRT12は持っています。
______________________________________
______________________________________
(Figure not included in text version.)
(テキストバージョンに含まれていなかった図。)
Figure 2: A sample Autonomous System
______________________________________
図2: サンプルAutonomous System______________________________________
__________________________________________
__________________________________________
(Figures not included in text version.)
(テキストバージョンに含まれていなかった数字。)
Figure 3: The resulting directed graph
Figure 4: Individual link state components
__________________________________________
図3: 結果として起こる有向グラフ図4: 個々のリンク州の部品__________________________________________
[Moy] [Page 9] RFC 1247 OSPF Version 2 July 1991
[Moy][9ページ]RFC1247OSPFバージョン1991年7月2日
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 link state advertisement for network N6 is actually generated by one of the attached routers: the router that has been elected Designated Router for the network.
2つの放送網とホストへのSLIP系列に連結してください。 ネットワークN6は3つの付属ルータがある放送網です。 ネットワークN6から付属ルータへのすべてのリンクの費用は0です。 ネットワークN6のためのリンク州の広告が実際に付属ルータの1つによって作られることに注意してください: ネットワークのためにDesignated Routerに選出されたルータ。
2.1 The shortest-path tree
2.1 最短パス木
When no OSPF areas are configured, each router in the Autonomous System has an identical topological database, leading to an identical graphical representation. A router generates its routing table from this graph by calculating a tree of shortest paths with the router itself as root. Obviously, the shortest-path tree depends on the router doing the calculation. The shortest-path tree for router RT6 in our example is depicted in Figure 5.
OSPF領域が全く構成されないとき、Autonomous Systemの各ルータには、同じ位相的なデータベースがあります、同じグラフ表示に通じて。 ルータは、根としてルータ自体でこのグラフから最短パスの木について計算することによって、経路指定テーブルを生成します。 明らかに、最短パス木は計算をするルータによります。 私たちの例のルータRT6のための最短パス木は図5に表現されます。
The tree gives the entire route 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 serial line (in this case, the serial line between routers RT6 and RT10).
木はどんな送信先ネットワークやホストにも全体のルートを与えます。 しかしながら、目的地への次のホップだけが推進プロセスで使用されます。 また、また、どんなルータへの最も良いルートも計算してあることに注意してください。 外部のデータの処理のために、私たちは、次のホップに注意して、どんなルータ広告にも外部経路を遠ざけます。 ルータRT6のための結果として起こる経路指定テーブルはTable2に描写されます。 別々のルートが番号付のシリアル・ライン(この場合ルータの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 this externally derived routing information is considered in the next section.
他のAS'es(N12などの)に属すネットワークへのルートは投げつけられた系列として図5の最短パス木の上に現れます。 この外部的に派生しているルーティング情報の使用は次のセクションで考えられます。
______________________________________
______________________________________
(Figure not included in text version.)
(テキストバージョンに含まれていなかった図。)
Figure 5: The SPF tree for router RT6
______________________________________
図5: ルータRT6のためのSPF木______________________________________
[Moy] [Page 10] RFC 1247 OSPF Version 2 July 1991
[Moy][10ページ]RFC1247OSPFバージョン1991年7月2日
Destination Next Hop Distance
__________________________________
N1 RT3 10
N2 RT3 10
N3 RT3 7
N4 RT3 8
Ib * 7
Ia RT10 12
N6 RT10 8
N7 RT10 12
N8 RT10 10
N9 RT10 11
N10 RT10 13
N11 RT10 14
H1 RT10 21
__________________________________
RT5 RT5 6
RT7 RT10 8
次のホップが遠ざける目的地__________________________________ N1 RT3 10N2 RT3 10N3 RT3 7 N4 RT3 8イブ*7Ia RT10 12 N6 RT10 8N7 RT10 12 N8 RT10 10 N9 RT10 11 N10 RT10 13 N11 RT10 14 H1 RT10 21__________________________________ RT5 RT5 6 RT7 RT10 8
Table 2: The portion of router RT6's routing table listing local
destinations.
テーブル2: 地方の目的地を記載するルータRT6の経路指定テーブルの一部。
2.2 Use of external routing information
2.2 外部のルーティング情報の使用
After the tree is created the external routing information is examined. This external routing information may originate from another routing protocol such as EGP, or be statically configured (static routes). Default routes can also be included as part of the Autonomous System's external routing information.
木が作成された後に、外部のルーティング情報は調べられます。 この外部のルーティング情報は、EGPなどの別のルーティング・プロトコルから発するか、または静的に構成されるかもしれません(スタティックルート)。 また、Autonomous Systemの外部のルーティング情報の一部としてデフォルトルートを含むことができます。
External routing information is flooded unaltered throughout the AS. In our example, all the routers in the Autonomous System know that router RT7 has two external routes, with metrics 2 and 9.
外部のルーティング情報はAS中で非変更されていた状態で水につかっています。 私たちの例では、Autonomous Systemのすべてのルータが、ルータRT7には2個の外部経路があるのを知っています、測定基準2と9で。
OSPF supports two types of external metrics. Type 1 external metrics are equivalent to the link state metric. Type 2 external metrics are 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の外部の測定基準はリンク状態にメートル法であることで同等です。 タイプ2の外部の測定基準はASへの内部のどんな経路の費用よりもすばらしいです。 Typeの2の外部の測定基準の使用は、AS'esの間のルーティングがパケットを発送する主要な費用であると仮定して、外部のコストの変換の必要性を内部のリンク州の測定基準に排除します。
Here is 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 external route, the distance from Router RT6 is calculated as the sum of the external route's cost and the distance from
ここに、Type1の外部のメトリック処理に関する例があります。 図2のルータのRT7とRT5が広告Type1の外部の測定基準であると仮定してください。 各外部経路において、Router RT6からの距離は、外部のルートの合計が費用と距離であるので、計算されます。
[Moy] [Page 11] RFC 1247 OSPF Version 2 July 1991
[Moy][11ページ]RFC1247OSPFバージョン1991年7月2日
Router RT6 to the advertising router. For every external destination, the router advertising the shortest route is discovered, and the next hop to the advertising router becomes the next hop to the destination.
広告ルータへのルータRT6。 あらゆる外部の目的地に関しては、広告を出す中でルート最も短いルータは発見されます、そして、広告ルータへの次のホップは目的地への次のホップになります。
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:
Router RT5とRT7の両方が送信先ネットワークN12に外部経路の広告を出しています。 ルータRT7がそれが10の遠方の広告N12であって、好まれる、(8、+2、)、Router RT6に、どちらがルータRT5の14より良いか、(6、+8、) テーブル3は、外部経路がいつ調べられるかを経路指定テーブルに加えられるエントリーに案内します:
Destination Next Hop Distance
__________________________________
N12 RT10 10
N13 RT5 14
N14 RT5 14
N15 RT10 17
次のホップが遠ざける目的地__________________________________ N12 RT10 10 N13 RT5 14N14 RT5 14N15 RT10 17
Table 3: The portion of router RT6's routing table listing external
destinations.
テーブル3: 外部の目的地を記載するルータRT6の経路指定テーブルの一部。
Processing of Type 2 external metrics is simpler. The AS boundary router advertising the smallest external metric is chosen, regardless of the internal distance to the AS boundary router. Suppose in our example both router RT5 and router RT7 were advertising Type 2 external routes. Then all traffic destined for network N12 would be forwarded to router RT7, since 2 < 8. When several equal-cost Type 2 routes exist, the internal distance to the advertising routers is used to break the tie.
Type2の外部の測定基準の処理は、より簡単です。 広告を出す中で外部最も小さいAS境界ルータ、メートル法、AS境界ルータへの内部の距離にかかわらず、選ばれています。 私たちの例でルータRT5とルータRT7の両方が広告Type2外部経路であったと仮定してください。 そして、2<8以来ネットワークN12のために運命づけられたすべての交通をルータRT7に送るでしょう。 数個ときに、等しい費用Type2ルートは存在していて、広告ルータへの内部の距離は、繋がりを壊すのに使用されます。
Both Type 1 and Type 2 external metrics can be present in the AS at the same time. In that event, Type 1 external metrics always take precedence.
Type1とType2の外部の測定基準の両方が同時に、ASに存在している場合があります。 その場合には、Type1の外部の測定基準はいつも優先します。
This section has assumed that packets destined for external destinations are always routed through the advertising AS boundary router. This is not always desirable. For example, suppose in Figure 2 there is an additional router attached to network N6, called Router RTX. Suppose further that RTX does not participate in OSPF routing, but does exchange EGP information with the AS boundary router RT7. Then, router RT7 would end up advertising OSPF external routes for all destinations that should be routed to RTX. An extra hop will sometimes be introduced if packets for these destinations need always be routed first to router RT7 (the advertising router).
このセクションは、外部の目的地に運命づけられたパケットが広告AS境界ルータを通していつも発送されると仮定しました。 これはいつも望ましいというわけではありません。 例えば、ある図2でRouter RTXと呼ばれるネットワークN6に付けられた追加ルータを仮定してください。 RTXがOSPFルーティングに参加しませんが、AS境界ルータRT7と共に交換EGPに情報をするとさらに仮定してください。 そして、ルータRT7は結局、RTXに発送されるべきであるすべての目的地にOSPF外部経路の広告を出すでしょう。 いつも最初に、ルータRT7(広告ルータ)にこれらの目的地へのパケットを発送しなければならないと、時々余分なホップを導入するでしょう。
To deal with this situation, the OSPF protocol allows an AS boundary
この状況に対処するために、OSPFプロトコルはAS境界を許容します。
[Moy] [Page 12] RFC 1247 OSPF Version 2 July 1991
[Moy][12ページ]RFC1247OSPFバージョン1991年7月2日
router to specify a "forwarding address" in its external advertisements. 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.
外部の広告における「フォーワーディング・アドレス」を指定するルータ。 上記の例では、Router RT7はパケットが直接RTXに発送されるべきであるそれらのすべての目的地への「フォーワーディング・アドレス」としてRTXのIPアドレスを指定するでしょう。
The "forwarding address" has one other application. It enables routers in the Autonomous System's interior to function as "route servers". For example, in Figure 2 the router RT6 could become a route server, gaining external routing information through a combination of static configuration and external routing protocols. RT6 would then start advertising itself as an AS boundary router, and would originate a collection of OSPF external advertisements. In each external advertisement, router RT6 would specify the correct Autonomous System exit point to use for the destination through appropriate setting of the advertisement's "forwarding address" field.
「フォーワーディング・アドレス」には、他の1つのアプリケーションがあります。 それは、Autonomous Systemの内部のルータが「ルートサーバ」として機能するのを可能にします。 例えば、図2では、ルータRT6はルートサーバになることができました、静的な構成と外部のルーティング・プロトコルの組み合わせで外部のルーティング情報を獲得して。 RT6は次に、AS境界ルータとして自分を売り込み始めて、OSPFの外部の広告の収集を溯源するでしょう。 それぞれの外部の広告では、ルータRT6は目的地に広告の「フォーワーディング・アドレス」分野の適切な設定を通して使用する正しいAutonomous Systemエキジットポイントを指定するでしょう。
2.3 Equal-cost multipath
2.3 等価コストマルチパス
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.
等しい費用多重通路によって、ルータは潜在的にどんな与えられた目的地に向かっても次のいくつかの利用可能なホップを持っています。
2.4 TOS-based routing
2.4 TOSベースのルーティング
OSPF can calculate a separate set of routes for each IP Type of Service. The IP TOS values are represented in OSPF exactly as they appear in the IP packet header. This means that, for any destination, there can potentially be multiple routing table entries, one for each IP TOS.
OSPFはServiceのそれぞれのIP Typeのために別々のセットのルートを計算できます。 IP TOS値はちょうどIPパケットのヘッダーに現れるようにOSPFに表されます。 これは、どんな目的地にはも複数の経路指定テーブルエントリー、各IP TOSあたり1つが潜在的にあることができることを意味します。
Up to this point, all examples shown have assumed that routes do not vary on TOS. In order to differentiate routes based on TOS, separate interface costs can be configured for each TOS. For example, in Figure 2 there could be multiple costs (one for each TOS) listed for each interface. A cost for TOS 0 must always be specified.
この時点までに、示されたすべての例が、ルートがTOSで異ならないと仮定しました。 TOSに基づくルートを微分して、各TOSのために別々のインタフェースコストを構成できます。 例えば、図2には、各インタフェースに記載された複数のコスト(各TOSあたり1つ)があるかもしれません。 いつもTOS0のための費用を指定しなければなりません。
When interface costs vary based on TOS, a separate shortest path tree is calculated for each TOS (see Section 2.1). In addition, external costs can vary based on TOS. For example, in Figure 2 router RT7 could advertise a separate type 1 external metric for each TOS. Then, when calculating the TOS X distance to network N15 the cost of the shortest TOS X path to RT7 would be added to the TOS X cost advertised by RT7
インタフェースコストがTOSに基づいて異なるとき、別々の最短パス木は各TOSのために計算されます(セクション2.1を見てください)。 さらに、外部のコストはTOSに基づいて異なることができます。 例えば、図2ルータRT7では、各TOSにおける、メートル法の別々のタイプ1外部は広告を出すことができました。 そして、TOS X距離についてネットワークN15に計算するとき、RT7への最も短いTOS X経路の費用はRT7によって広告に掲載されたTOS X費用に加えられるでしょう。
[Moy] [Page 13] RFC 1247 OSPF Version 2 July 1991
[Moy][13ページ]RFC1247OSPFバージョン1991年7月2日
(see Section 2.2).
(セクション2.2を見ます。)
All OSPF implementations must be capable of calculating routes based on TOS. However, OSPF routers can be configured to route all packets on the TOS 0 path (see Appendix C), eliminating the need to calculate non- zero TOS paths. This can be used to conserve routing table space and processing resources in the router. These TOS-0-only routers can be mixed with routers that do route based on TOS. TOS-0-only routers will be avoided as much as possible when forwarding traffic requesting a non-zero TOS.
すべてのOSPF実現がTOSに基づくルートを計算できなければなりません。 しかしながら、OSPFルータはTOS0経路(Appendix Cを見る)ですべてのパケットを発送するために構成されて、非ゼロについて計算する必要性を排除するのが、TOS経路であったならそうすることができます。 ルータにおける経路指定テーブルスペースと処理資源を節約するのにこれを使用できます。 これらのTOS0だけルータはTOSに基づくそうするルータに混ぜられたルートであるかもしれません。 非ゼロTOSを要求する交通を進めるとき、TOS0だけルータはできるだけ避けられるでしょう。
It may be the case that no path exists for some non-zero TOS, even if the router is calculating non-zero TOS paths. In that case, packets requesting that non-zero TOS are routed along the TOS 0 path (see Section 11.1).
経路が全くいくつかの非ゼロTOSのために存在していないのは、事実であるかもしれません、ルータが計算の非ゼロTOS経路であっても。 その場合、その非ゼロTOSを要求するパケットがTOS0経路に沿って発送されます(セクション11.1を見てください)。
3. Splitting the AS into Areas
3. 分かれる、領域
OSPF allows collections of contiguous networks and hosts to be grouped together. Such a group, together with the routers having interfaces to any one of the included networks, is called an area. Each area runs a separate copy of the basic SPF routing algorithm. This means that each area has its own topological database and corresponding graph, as explained in the previous section.
OSPFは、隣接のネットワークとホストの収集が一緒に分類されるのを許容します。 そのようなグループは含まれているネットワークのいずれにもインタフェースを持っているルータと共に領域と呼ばれます。 各領域は基本的なSPFルーティング・アルゴリズムの別々のコピーを動かします。 これは、前項で説明されるように各領域にはそれ自身の位相的なデータベースと対応するグラフがあることを意味します。
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 SPF domain.
領域のトポロジーは領域の外部から目に見えません。 逆に、与えられた領域への内部のルータはその領域への外部の詳細なトポロジーについて何も知りません。 ただ一つのSPFドメインとして全体のAutonomous Systemを扱うと比べて、知識のこの孤立は、プロトコルがルーティング交通の著しい減少に作用するのを可能にします。
With the introduction of areas, it is no longer true that all routers in the AS have an identical topological database. A router actually has a separate topological 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 topological databases.
領域の導入では、ASのすべてのルータには同じ位相的なデータベースがあるのは、もう本当ではありません。 ルータには、それが関連づけられる各領域のための別々の位相的なデータベースが実際にあります。 (複数の領域に関連づけられたルータは境界ルータと呼ばれます。) 同じ領域に属す2つのルータが同じ領域位相的なデータベースをその領域に持っています。
Routing in the Autonomous System takes place on two levels, depending on whether the source and destination of a packet reside in the same area (intra-area routing is used) or different areas (inter-area routing is used). In intra-area routing, the packet is routed solely on information obtained within the area; no routing information obtained from outside the area can be used. This protects intra-area routing from the injection of bad routing information. We discuss inter-area routing in Section 3.2.
Autonomous Systemのルート設定は2つのレベルで行われます、パケットのソースと目的地が同じ領域(イントラ領域ルーティングは使用されている)か異なった領域にあるかどうかに(相互領域ルーティングは使用されています)よって。 イントラ領域ルーティングで、パケットは唯一領域の中で得られた情報で発送されます。 領域の外から得られなかったルーティング情報は全く使用できます。 これは悪いルーティング情報の注射からイントラ領域ルーティングを保護します。 私たちはセクション3.2で相互領域ルーティングについて議論します。
[Moy] [Page 14] RFC 1247 OSPF Version 2 July 1991
[Moy][14ページ]RFC1247OSPFバージョン1991年7月2日
3.1 The backbone of the Autonomous System
3.1 Autonomous Systemの背骨
The backbone consists of those networks not contained in any area, their attached routers, and those routers that belong to multiple areas. The backbone must be contiguous.
背骨はどんな領域、それらの付属ルータ、および複数の領域に属すそれらのルータにも含まれなかったそれらのネットワークから成ります。 背骨は隣接であるに違いありません。
It is possible to define areas in such a way that the backbone is no longer contiguous. In this case the system administrator must restore backbone connectivity by configuring virtual links.
背骨がもう隣接でないように方法で領域を定義するのは可能です。 この場合、システム管理者は、仮想のリンクを構成することによって、背骨の接続性を回復しなければなりません。
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 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つのルータの間のイントラ領域距離であるアークによって接合されます。 仮想のリンクに沿って流れるルーティング・プロトコル交通はイントラ領域ルーティングだけを使用します。
The backbone is responsible for distributing routing information between areas. The backbone itself has all of the properties of an area. The topology of the backbone is invisible to each of the areas, while the backbone itself knows nothing of the topology of the areas.
背骨は領域の間にルーティング情報を分配するのに原因となります。 背骨自体には、領域の特性のすべてがあります。 背骨のトポロジーはそれぞれの領域に目に見えません、背骨自体が領域のトポロジーについて何も知りませんが。
3.2 Inter-area routing
3.2 相互領域ルーティング
When routing a packet between two 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 and each of the areas as spokes.
この別の方法を見て、スポークとしてハブとしての背骨があるAutonomous Systemとそして、それぞれ領域の星の構成を強制するとして相互領域ルーティングについて描写できます。
The topology of the backbone dictates the backbone paths used between areas. The topology of the backbone can be enhanced by adding virtual links. This gives the system administrator some control over the routes taken by inter-area traffic.
背骨のトポロジーは領域の間で使用される背骨経路を書き取ります。 仮想のリンクを加えることによって、背骨のトポロジーを高めることができます。 これは相互領域交通で取られたルートの何らかの支配力をシステム管理者に与えます。
The correct area border router to use as the packet exits the source area is chosen in exactly the same way routers advertising external routes are chosen. Each area border router in an area summarizes for the area its cost to all networks external to the area. After the SPF tree is calculated for the area, routes to all other networks are
パケットがソース部門を出るとき、使用する正しい境界ルータは外部経路の広告を出すルータが選ばれているまさに同じように選ばれています。 領域の各境界ルータはその領域への外部のすべてのネットワークへの費用を領域へまとめます。 SPF木が領域に計算された後に、他のすべてのネットワークへのルートは計算されます。
[Moy] [Page 15] RFC 1247 OSPF Version 2 July 1991
[Moy][15ページ]RFC1247OSPFバージョン1991年7月2日
calculated by examining the summaries of the area border routers.
境界ルータの概要を調べることによって、計算されています。
3.3 Classification of routers
3.3 ルータの分類
Before the introduction of areas, the only OSPF routers having a specialized function were those advertising external routing information, such as router RT5 in Figure 2. When the AS is split into OSPF areas, the routers are further divided according to function into the following four overlapping categories:
領域の導入の前に、専門化している機能を持っていた唯一のOSPFルータが外部のルーティング情報の広告を出すものでした、図2のルータRT5などのように。 ASがOSPF領域に分割されるとき、以下の4へのカテゴリを重ね合わせる機能に応じて、ルータはさらに分割されます:
Internal routers
A router with all directly connected networks belonging to the same
area. Routers with only backbone interfaces also belong to this
category. These routers run a single copy of the basic routing
algorithm.
すべてがある内部のルータAルータは直接同じ領域に属すネットワークを接続しました。 また、背骨インタフェースだけがあるルータはこのカテゴリに属します。 これらのルータは基本的なルーティング・アルゴリズムのただ一つのコピーを動かします。
Area border routers
A router that attaches to multiple areas. Area border routers run
multiple copies of the basic algorithm, one copy for each attached
area and an additional copy for the backbone. Area border routers
condense the topological information of their attached areas for
distribution to the backbone. The backbone in turn distributes the
information to the other areas.
複数の領域に付く境界ルータAルータ。 境界ルータは背骨のために基本的なアルゴリズムの複数のコピー、それぞれの付属領域あたりのコピー1部、および複本を動かします。 境界ルータは分配のためにそれらの付属領域の位相的な情報を背骨に凝縮します。 背骨は順番に他の領域に情報を分配します。
Backbone routers
A router that has an interface to the backbone. 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 connected to the backbone are
considered to be internal routers.
背骨にインタフェースを持っている背骨ルータAルータ。 これは1つ以上の領域(すなわち、境界ルータ)に連結するすべてのルータを含んでいます。 しかしながら、背骨ルータは境界ルータである必要はありません。 すべてのインタフェースが背骨に接続されるルータは内部のルータであると考えられます。
AS boundary routers
A router that exchanges routing information with routers belonging
to other Autonomous Systems. Such a router has AS external routes
that are advertised throughout the Autonomous System. The path to
each AS boundary router is known by every router in the AS. This
classification is completely independent of the previous
classifications: AS boundary routers may be internal or area border
routers, and may or may not participate in the backbone.
他のAutonomous Systemsそのようなルータに属すルータとルーティング情報を交換するAS境界ルータAルータがAutonomous Systemの中に広告に掲載されているAS外部経路を持っています。 それぞれのAS境界ルータへの経路はASであらゆるルータによって知られています。 この分類は前の分類から完全に独立しています: AS境界ルータは、内部か領域境界ルータであるかもしれなく、背骨に参加するかもしれません。
3.4 A sample area configuration
3.4 サンプル領域構成
Figure 6 shows a sample area configuration. The first area consists of networks N1-N4, along with their attached routers RT1-RT4. The second area consists of networks N6-N8, along with their attached routers RT7,
図6はサンプル領域構成を示しています。 最初の領域はそれらの付属ルータRT1-RT4に伴うネットワークN1-N4から成ります。 2番目の領域はそれらの付属ルータRT7に伴うネットワークN6-N8から成ります。
[Moy] [Page 16] RFC 1247 OSPF Version 2 July 1991
[Moy][16ページ]RFC1247OSPFバージョン1991年7月2日
RT8, RT10, RT11. The third area consists of networks N9-N11 and host H1, along with their attached routers RT9, RT11, 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).
RT8、RT10、RT11。 3番目の領域はそれらの付属ルータRT9、RT11、RT12に伴うネットワークのN9-N11とホストH1から成ります。 3番目の領域はネットワークのN9-N11とホストH1がただ一つのルートにすべて分類されるように、構成されました、その領域に外部であることの形で広告を出すと(その他の詳細に関してセクション3.5を見てください)。
In Figure 6, routers RT1, RT2, RT5, RT6, RT8, RT9 and RT12 are internal routers. Routers RT3, RT4, RT7, RT10 and RT11 are area border routers. Finally as before, routers RT5 and RT7 are AS boundary routers.
図6では、ルータのRT1、RT2、RT5、RT6、RT8、RT9、およびRT12は内部のルータです。 ルータのRT3、RT4、RT7、RT10、およびRT11は境界ルータです。 以前ルータのRT5とRT7が最終的にAS境界ルータであるので。
Figure 7 shows the resulting topological 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, external advertisements from RT5 and RT7 are flooded throughout the entire AS, and in particular throughout Area 1. These advertisements are included in Area 1's database, and yield routes to networks N12-N15.
図7はArea1のための結果として起こる位相的なデータベースを示しています。 図は、掘りながら、その領域のイントラ領域について完全に説明します。 また、それは2の内部のルータRT1とRT2のためにインターネットの完全な視点を示しています。 それは、その領域への外部のすべての目的地への距離のArea1に広告を出すためには境界ルータ、RT3、およびRT4の仕事です。 これらは図7で投げつけられたスタッブルートで示されます。 また、RT3とRT4はASルータRT5境界とRT7の位置のArea1に広告を出さなければなりません。 最終的に、RT5とRT7からの外部の広告は全体のAS中と、そして、特にArea1中で水につかっています。 これらの広告はArea1のデータベースに含まれています、そして、利回りはN12-N15をネットワークに発送します。
Routers RT3 and RT4 must also summarize Area 1's topology for distribution to the backbone. Their backbone advertisements are shown in Table 4. These summaries show which networks are contained in Area 1 (i.e., networks N1-N4), and the distance to these networks from the routers RT3 and RT4 respectively.
また、ルータのRT3とRT4は分配のためにArea1のトポロジーを背骨へまとめなければなりません。 彼らの背骨広告はTable4に示されます。 これらの概要は、ルータのRT3とRT4からどのネットワークがArea1(すなわち、N1-N4をネットワークでつなぎます)、および距離にこれらのネットワークに含まれているかをそれぞれ示します。
The topological database for the backbone is shown in Figure 8. The set of routers pictured are the backbone routers. Router RT11 is a backbone router because it belongs to two areas. In order to make the backbone connected, a virtual link has been configured between routers R10 and R11.
背骨のための位相的なデータベースは図8に示されます。 描写されたルータのセットは背骨ルータです。 2つの領域に属すので、ルータRT11は背骨ルータです。 背骨を接続させるために、仮想のリンクはルータのR10とR11の間で構成されました。
__________________________________________
__________________________________________
(Figure not included in text version.)
(テキストバージョンに含まれていなかった図。)
Figure 6: A sample OSPF area configuration
__________________________________________
図6: サンプルOSPF領域構成__________________________________________
[Moy] [Page 17] RFC 1247 OSPF Version 2 July 1991
[Moy][17ページ]RFC1247OSPFバージョン1991年7月2日
Network RT3 adv. RT4 adv.
_____________________________
N1 4 4
N2 4 4
N3 1 1
N4 2 3
ネットワークRT3副詞 RT4副詞 _____________________________ N1 4 4 N2 4 4 N3 1 1 N4 2 3
Table 4: Networks advertised to the backbone by routers RT3 and RT4.
テーブル4: ネットワークはルータのRT3とRT4で背骨に広告を出しました。
______________________________________
______________________________________
(Figure not included in text version.)
(テキストバージョンに含まれていなかった図。)
Figure 7: Area 1's Database
Figure 8: The backbone database
______________________________________
図7: 領域に関する1つのデータベースのエイト環: 背骨データベース______________________________________
Again, routers RT3, RT4, RT7, RT10 and RT11 are area border routers. As routers RT3 and RT4 did above, they have condensed the routing information of their attached 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は境界ルータです。 RT3とRT4が上でしたルータとして、分配のために背骨でそれらの付属領域のルーティング情報を凝縮しました。 これらは図8に載っている投げつけられたスタッブです。 3番目の領域がネットワークのN9-N11とHost H1をただ一つのルートに凝縮するために構成されたのを覚えていてください。 これは図8でネットワークN9のN11とHost H1に、ただ一つの投げつけられた線をもたらします。 ルータのRT5とRT7はAS境界ルータです。 また、それらの外部的に派生している情報はスタッブとして図8のグラフで現れます。
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 advertisements, and adding in the backbone distance to each advertising router.
背骨は境界ルータの間の概要情報の交換を可能にします。 あらゆる境界ルータが他のすべての境界ルータから領域概要を聞きます。 次に、それは距離の絵をすべてのネットワークに形成します。それぞれの広告ルータに集まっている広告を調べて、背骨距離を加えるのによる領域の外。
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とイブ)とAS境界ルータ(RT5とRT7)への距離です。 この計算はTable5に示されます。
Next, by looking at the area summaries from these area border routers, RT3 and RT4 can determine the distance to all networks outside their
これらの境界ルータから領域概要を見ることによって、次です、RT3とRT4がすべてへの距離が外部をネットワークでつなぐことを決定できる、それら
[Moy] [Page 18] RFC 1247 OSPF Version 2 July 1991
[Moy][18ページ]RFC1247OSPFバージョン1991年7月2日
Area border dist from dist from
router RT3 RT4
______________________________________
to RT3 * 21
to RT4 22 *
to RT7 20 14
to RT10 15 22
to RT11 18 25
______________________________________
to Ia 20 27
to Ib 15 22
______________________________________
to RT5 14 8
to RT7 20 14
ルータRT3 RT4からのdistからの領域境界dist______________________________________ RT11 18 25へのRT10 15 22へのRT7 20 14へのRT4 22*へのRT3*21に______________________________________ イブ15 22へのIa20 27に______________________________________ RT7 20 14へのRT5 14 8に
Table 5: Backbone distances calculated by routers RT3 and RT4.
テーブル5: ルータのRT3とRT4によって計算された背骨距離。
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 I5 and I6 into a single advertisement.
領域。 そして、これらの距離はRT3とRT4によって内部的にその領域に広告を出されます。 ルータRT3とRT4がArea1にする広告はTable6に示されます。 Table6が、領域の範囲がI5とI6をただ一つの広告に分類する背骨のために構成されたと仮定することに注意してください。
The information imported into Area 1 by routers RT3 and RT4 enables an internal router, such as RT1, to choose an area border router intelligently. Router RT1 would use RT4 for traffic to network N6, RT3 for traffic to network N10, and would load share between the two for
ルータのRT3とRT4によってArea1に輸入された情報は、内部のルータ、RT1としてのそのようなものが知的に境界ルータを選ぶのを可能にします。 ルータRT1は交通がN10をネットワークでつなぐのにネットワークN6、RT3に交通へのRT4を使用して、2つの間のシェアをロードするでしょう。
Destination RT3 adv. RT4 adv.
_________________________________
Ia,Ib 15 22
N6 16 15
N7 20 19
N8 18 18
N9-N11,H1 19 26
_________________________________
RT5 14 8
RT7 20 14
目的地RT3副詞 RT4副詞 _________________________________ Ia、イブ15 22N6 16 15N7 20 19N8 18 18N9-N11、H1 19 26_________________________________ RT5 14 8RT7 20 14
Table 6: Destinations advertised into Area 1 by routers RT3 and RT4.
テーブル6: ルータのRT3とRT4によってArea1に広告に掲載された目的地。
[Moy] [Page 19] RFC 1247 OSPF Version 2 July 1991
[Moy][19ページ]RFC1247OSPFバージョン1991年7月2日
traffic to network N8.
ネットワークN8への交通。
Router RT1 can also determine in this manner the shortest path to the AS boundary routers RT5 and RT7. Then, by looking at RT5 and RT7's external advertisements, 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の外部の広告を見ることによって、別のAutonomous Systemの目的地に発信するとき(ネットワークN12-N15の1つ)、ルータRT1はRT5かRT7についてどちらかに決めることができます。
Note that a failure of the line between routers RT6 and RT10 will cause the backbone to become disconnected. Configuring another virtual link between routers RT7 and RT10 will give the backbone more connectivity and more resistance to such failures. Also, a virtual link between RT7 and RT10 would allow a much shorter path between the third area (containing N9) and the router RT7, which is advertising a good route to external network N12.
背骨がルータのRT6とRT10の間の線の失敗によって外されるようになることに注意してください。 ルータのRT7とRT10との別の仮想のリンクを構成すると、より多くの接続性とそのような失敗への、より多くの抵抗が背骨に与えられるでしょう。 また、RT7とRT10との仮想のリンクは3番目の領域(N9を含んでいる)とルータRT7の間のはるかに短い経路を許容するでしょう。RT7は外部のネットワークN12に良いルートの広告を出しています。
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 advertisement 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アドレスマスクをそれぞれの広告を出しているルートに取り付けます。 マスクは特定のルートで説明されるアドレスの範囲を示します。 例えば、目的地への概要広告、128.185、.0、.0、実際に0xffff0000のマスクでただ一つのルートを目的地の収集に説明している、128.185、.0、.0、--128.185 .255 .255。 同様に、単一の目的地だけの存在を示して、いつも0xffffffffのマスクでホストルートの広告を出します。
Including the mask with each advertised destination enables the implementation of what is commonly referred to as variable-length subnet masks. 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 64 variable-sized subnets: 16 subnets of size 4K, 16 subnets of size 256, and 32 subnets of size 8. Table 7 shows some of the resulting network addresses together with their masks:
それぞれの広告を出している目的地があるマスクを含んでいると、一般的に可変長のサブネットマスクと呼ばれることに関する実現は可能にされます。 これは、ただ一つのIPのクラスA、B、またはCネットワーク・ナンバーを様々なサイズの多くのサブネットに終えることができることを意味します。 例えば、.0が64の変数サイズのサブネットに壊れるかもしれないネットワーク128.185.0: 4Kのサイズの16サブネット、サイズ8のサイズ256、および32サブネットの16サブネット。 テーブル7はそれらのマスクと共に結果として起こるネットワーク・アドレスのいくつかを示しています:
Network address IP address mask Subnet size
_______________________________________________
128.185.16.0 0xfffff000 4K
128.185.1.0 0xffffff00 256
128.185.0.8 0xfffffff8 8
ネットワーク・アドレスIPアドレスマスクSubnetサイズ_______________________________________________ 128.185.16.0 0 4K128.185.1.0 0のxfffff000xffffff00 256 128.185.0.8 0xfffffff8 8
Table 7: Some sample subnet sizes.
テーブル7: 或るものはサブネットサイズを抽出します。
[Moy] [Page 20] RFC 1247 OSPF Version 2 July 1991
[Moy][20ページ]RFC1247OSPFバージョン1991年7月2日
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. The 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の目的地への最も良いマッチも明白であるように、サブネットマスクを割り当てなければなりません。
The OSPF area concept is modelled after an IP subnetted network. OSPF areas have been loosely defined to be a collection of networks. In actuality, an OSPF area is specified to be a list of address ranges (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 minimum cost to any of the networks falling in the specified range.
OSPF領域概念はIPサブネット化したネットワークに倣われます。 OSPF領域は、集めることであることのようにネットワークについてなるように緩く定義されました。 現実では、OSPF領域は、アドレスの範囲のリストになるように指定されます(その他の詳細に関してセクションC.2を見てください)。 それぞれのアドレスの範囲は[アドレス、マスク]組と定義されます。 次に、多くの別々のネットワークがただ一つのアドレスの範囲に保管されるかもしれません、ちょうどサブネット化したネットワークが多くの別々のサブネットで構成されるように。 そして、境界ルータは、それぞれのアドレスの範囲にただ一つのルートの広告を出すことによって、領域コンテンツ(背骨への分配のための)をまとめます。 ルートの費用は最低費用です指定された範囲で転ぶネットワークのどんなも。
For example, an IP subnetted network can be configured as a single OSPF area. In that case, the area would be defined as a single address range: 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. 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 minimum of the set of costs to the component subnets.
例えば、ただ一つのOSPF領域としてIPサブネット化したネットワークを構成できます。 その場合、領域はただ一つのアドレスの範囲と定義されるでしょう: クラスA、B、またはCは自然なIPマスクに伴う数をネットワークでつなぎます。 領域の中では、いろいろな可変大きさで分けられたサブネットを定義できました。 その領域に外部です、全体のサブネット化したネットワークに、ただ一つのルートは分配されるでしょう、ネットワークが全く「副-網で覆」われるという事実さえ隠して。 このルートの費用はコンポーネントサブネットへのコストのセットの最小限です。
3.6 Supporting stub areas
3.6 スタッブ領域を支持すること。
In some Autonomous Systems, the majority of the topological database may consist of external advertisements. An OSPF external advertisement is usually flooded throughout the entire AS. However, OSPF allows certain areas to be configured as "stub areas". External advertisements 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 topological database size, and therefore the memory requirements, for a stub area's internal routers.
いくつかのAutonomous Systemsでは、位相的なデータベースの大部分が外部の広告から成るかもしれません。 通常、OSPFの外部の広告は全体のAS中で水につかっています。 しかしながら、OSPFは、ある一定の領域が「スタッブ領域」として構成されるのを許容します。 外部の広告はスタッブ領域中に/へあふれません。 これらの領域の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 advertisements. These
OSPFスタッブ領域サポートを利用するために、スタッブ領域でデフォルトルーティングを使用しなければなりません。 これは以下の通り達成されます。 スタッブ領域の境界ルータのより多くのひとりは概要広告でスタッブ領域にデフォルトルートの広告を出さなければなりません。 これら
[Moy] [Page 21] RFC 1247 OSPF Version 2 July 1991
[Moy][21ページ]RFC1247OSPFバージョン1991年7月2日
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 match any destination that is not explicitly reachable by an intra-area or inter-area path (i.e., AS external destinations).
概要デフォルトはスタッブ領域、しかし、これ以上あふれません。 (これらのデフォルトが特定のスタッブ領域だけに関係するこの理由による。) これらの概要デフォルトルートはどんなイントラ領域か相互領域経路(すなわち、ASの外部の目的地)で明らかに届いていない目的地にも合うでしょう。
An area can be configured as 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 advertisement), instead of flooding the external advertisements for networks N12-N15 into/throughout the area.
ただ一つのエキジットポイントが領域から来ているか、またはaでエキジットポイントの選択をする必要はないとき、スタッブとして領域を構成できる、-、外部の目的地基礎。 例えば、スタッブ領域として図6の領域3を構成できました、もっとも、すべての域外交通がただ一つの境界ルータRT11を旅行しなければならないので。 領域3がスタッブとして構成されるなら、ルータRT11は領域3(概要広告における)の中の分配のためのデフォルトルートの広告を出すだろうにて、氾濫の代わりにネットワークのための外部の広告は領域中の/へのN12-N15です。
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 external advertisements.
OSPFプロトコルは、領域に属すすべてのルータが、領域がスタッブとして構成されたかどうか同意するのを確実にします。 これは、混乱が全く外部の広告の氾濫で起こらないのを保証します。
There are a couple of restrictions on the use of stub areas. Virtual links cannot be configured through stub areas. In addition, AS boundary routers cannot be placed internal to stub areas.
スタッブ領域の使用には2、3の制限があります。 スタッブ領域を通って仮想のリンクを構成できません。 さらに、領域を引き抜くために内部でAS境界ルータを置くことができません。
3.7 Partitions of areas
3.7 領域のパーティション
OSPF does not actively attempt to repair area partitions. When an area becomes partitioned, each component simply becomes a separate area. The backbone then performs routing between the new areas. Some destinations reachable via intra-area routing before the partition will now require inter-area routing.
OSPFは、領域パーティションを修理するのを活発に試みません。 領域が仕切られるようになると、各コンポーネントは単に分離した部分になります。 そして、バックボーンは新しい領域の間のルーティングを実行します。 パーティションの前のイントラ領域ルーティングを通して届いているいくつかの目的地が現在、相互領域ルーティングを必要とするでしょう。
In the previous section, an area was described as a list of address ranges. Any particular address range must still be completely contained in a single component of the area partition. This has to do with the way the area contents are summarized to the backbone. Also, the backbone itself must not partition. If it does, parts of the Autonomous System will become unreachable. Backbone partitions can be repaired by configuring virtual links (see Section 15).
前項で、アドレスのリストが及ぶとき、領域は説明されました。 領域パーティションのただ一つのコンポーネントにどんな特定のアドレスの範囲もまだ完全に含まなければなりません。 これは領域内容がバックボーンへまとめられる方法と関係があります。 また、バックボーン自体は仕切ってはいけません。 そうすると、Autonomous Systemの部分は手が届かなくなるでしょう。 仮想のリンクを構成することによって、バックボーンパーティションを修理できます(セクション15を見てください)。
Another way to think about area partitions is to look at the Autonomous System graph that was introduced in Section 2. Area IDs can be viewed as colors for the graph's edges.[1] Each edge of the graph connects to a network, or is itself a point-to-point network. In either case, the edge is colored with the network's Area ID.
領域パーティションについて考える別の方法はセクション2で導入されたAutonomous Systemグラフを見ることです。 グラフのもののために縁を.[1]に着色するとき、領域IDを見ることができます。グラフの各縁は、ネットワークに接続するか、またはそれ自体で二地点間ネットワークです。 どちらの場合ではも、縁はネットワークのArea IDと共に着色されます。
A group of edges, all having the same color, and interconnected by vertices, represents an area. If the topology of the Autonomous System
縁のグループ(頭頂によって同じ色を持って、インタコネクトされたすべて)は領域を表します。 Autonomous Systemのトポロジーです。
[Moy] [Page 22] RFC 1247 OSPF Version 2 July 1991
[Moy][22ページ]RFC1247OSPFバージョン1991年7月2日
is intact, the graph will have several regions of color, each color being a distinct Area ID.
完全であることで、グラフには色のいくつかの領域が各色が異なったArea IDであるならあるでしょう。
When the AS topology changes, one of the areas may become partitioned. The graph of the AS will then have multiple regions of the same color (Area ID). The routing in the Autonomous System will continue to function as long as these regions of same color are connected by the single backbone region.
ASトポロジーが変化すると、領域の1つは仕切られるようになるかもしれません。 そして、ASのグラフには、同じ色(Area ID)の複数の領域があるでしょう。 Autonomous Systemでのルーティングは、同じ色のこれらの領域がただ一つのバックボーン領域によってつなげられる限り、機能し続けるでしょう。
[Moy] [Page 23] RFC 1247 OSPF Version 2 July 1991
[Moy][23ページ]RFC1247OSPFバージョン1991年7月2日
4. Functional Summary
4. 機能的な概要
A separate copy of OSPF's basic routing algorithm runs in each area. Routers having interfaces to multiple areas run multiple copies of the algorithm. A brief summary of the routing algorithm follows.
別々のコピーのOSPFの基本的なルーティング・アルゴリズムは各領域へ駆け込みます。 複数の領域にインタフェースを持っているルータがアルゴリズムの複本を実行します。 ルーティング・アルゴリズムの簡潔な概要は従います。
When a router starts, it first initializes the routing protocol data structures. The router then waits for indications from the lower-level protocols that its interfaces are functional.
ルータが始まるとき、それは最初に、ルーティング・プロトコルデータ構造を初期化します。 そして、ルータは低レベルプロトコルからのインタフェースが機能的であるという指摘を待っています。
A router then uses the OSPF's Hello Protocol to acquire neighbors. The router sends Hello packets to its neighbors, and in turn receives their Hello packets. On broadcast and point-to-point networks, the router dynamically detects its neighboring routers by sending its Hello packets to the multicast address AllSPFRouters. On non-broadcast networks, some configuration information is necessary in order to discover neighbors. On all multi-access networks (broadcast or non-broadcast), the Hello Protocol also elects a Designated router for the network.
そして、ルータは、隣人を取得するのにOSPFのHelloプロトコルを使用します。 ルータは、隣人へのパケットをHelloに送って、順番に彼らのHelloパケットを受けます。 放送と二地点間ネットワークでは、ルータは、マルチキャストアドレスAllSPFRoutersにHelloパケットを送ることによって、ダイナミックに隣接しているルータを検出します。 非放送網では、何らかの設定情報が、隣人を発見するのに必要です。 マルチアクセスネットワーク(放送か非放送)、すべてのHelloプロトコル、もネットワークのためにDesignatedルータに選出します。
The router will attempt to form adjacencies with some of its newly acquired neighbors. Topological databases are synchronized between pairs of adjacent routers. On multi-access networks, the Designated Router determines which routers should become adjacent.
ルータは、何人かの新たに取得された隣人と共に隣接番組を形成するのを試みるでしょう。 位相的なデータベースは組の隣接しているルータの間で同期します。 マルチアクセスネットワークでは、Designated Routerは、どのルータが隣接するようになるべきであるかを決定します。
Adjacencies control the distribution of routing protocol packets. Routing protocol packets are sent and received only on adjacencies. In particular, distribution of topological database updates proceeds along 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 link state advertisements. This relationship between adjacencies and link state allows the protocol to detect dead routers in a timely fashion.
ルータは定期的に状態の広告を出します。(また、それは、リンク状態と呼ばれます)。 また、ルータの状態が変化するとき、リンク状態の広告を出します。 ルータの隣接番組はリンク州の広告のコンテンツに反映されます。 隣接番組とリンク状態とのこの関係は、直ちに死んでいるルータを検出するためにプロトコルを許容します。
Link state advertisements are flooded throughout the area. The flooding algorithm is reliable, ensuring that all routers in an area have exactly the same topological database. This database consists of the collection of link state advertisements received from 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.
リンク州の広告は領域中で水につかっています。 領域のすべてのルータにはまさに同じ位相的なデータベースがあるのを確実にして、氾濫アルゴリズムは信頼できます。 このデータベースは領域に属す各ルータから受け取られたリンク州の広告の収集から成ります。 このデータベースから、各ルータは根としてそれ自体がいる最短パス木について計算します。 この最短パス木は順番にプロトコルのための経路指定テーブルをもたらします。
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
前項はただ一つの領域の中でプロトコルの操作について説明しました。 イントラ領域ルーティングのために、他のどんなルーティング情報もそうではありません。
[Moy] [Page 24] RFC 1247 OSPF Version 2 July 1991
[Moy][24ページ]RFC1247OSPFバージョン1991年7月2日
pertinent. In order to be able to route to destinations outside of the area, the area border routers inject additional routing information into the area. This additional information is a distillation of the rest of the Autonomous System's topology.
適切。 領域の外部を目的地に発送できるように、境界ルータは追加ルーティング情報を領域に注ぎます。 この追加情報はAutonomous Systemのトポロジーの残りの蒸留です。
This distillation is accomplished as follows: Each area border router is by definition connected to the backbone. Each area border router summarizes the topology of its attached areas for transmission on the backbone, and hence to all other area border routers. A 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 destinations not contained in its attached areas. The router then advertises these paths to its attached areas. This enables the area's internal routers to pick the best exit router when forwarding traffic to destinations in other areas.
この蒸留は以下の通り実行されます: 各境界ルータは定義上バックボーンに関連づけられます。 各境界ルータはトランスミッションのためにバックボーンの上と、そして、したがって、他のすべての境界ルータへ付属領域のトポロジーをまとめます。 そして、境界ルータには、バックボーンの完全な位相的な情報、およびそれぞれの他の境界ルータからの領域概要があります。 この情報から、ルータは付属領域に保管されていたというわけではないすべての目的地に経路について計算します。 そして、ルータは付属領域にこれらの経路の広告を出します。 他の領域の目的地にトラフィックを送るとき、これは、領域の内部のルータが最も良い出口ルータを選ぶのを可能にします。
4.2 AS external routes
4.2個のAS外部経路
Routers that have information regarding other Autonomous Systems can flood this information throughout the AS. This external routing information is distributed verbatim to every participating router. There is one exception: external routing information is not flooded into "stub" areas (see Section 3.6).
他のAutonomous Systemsの情報を持っているルータはAS中にこの情報をあふれさせることができます。 この外部のルーティング情報はあらゆる参加ルータに逐語的に分配されます。 1つの例外があります: 外部のルーティング情報は「スタッブ」領域へあふれません(セクション3.6を見てください)。
To utilize external routing information, the path to all routers advertising external information must be known throughout the AS (excepting the stub areas). For that reason, the locations of these AS boundary routers are summarized by the (non-stub) area border routers.
外部のルーティング情報、経路をすべてのルータ広告に利用するために、AS(スタッブ領域を除いた)中で外部の情報を知っていなければなりません。 その理由で、これらのAS境界ルータの位置は(非スタッブの)境界ルータによってまとめられます。
4.3 Routing protocol packets
4.3 ルーティング・プロトコルパケット
The OSPF protocol runs directly over IP, using IP protocol 89. OSPF does not provide any explicit fragmentation/reassembly support. When fragmentation is necessary, IP fragmentation/reassembly is used. OSPF protocol packets have been designed so that large protocol packets can generally be split into several smaller protocol packets. This practice is recommended; IP fragmentation should be avoided whenever possible.
IPプロトコル89を使用して、OSPFプロトコルは直接IPをひきます。 OSPFは少しの明白な断片化/再アセンブリサポートも提供しません。 断片化が必要であるときに、IP断片化/再アセンブリは使用されています。 OSPFプロトコルパケットは、一般に、大きいプロトコルパケットをいくつかの、より小さいプロトコルパケットに分けることができるように設計されています。 この習慣はお勧めです。 可能であるときはいつも、IP断片化は避けられるべきです。
Routing protocol packets should always be sent with the IP TOS field set to 0. If at all possible, routing protocol packets should be given preference over regular IP data traffic, both when being sent and received. As an aid to accomplishing this, OSPF protocol packets should have their IP precedence field set to the value Internetwork Control (see [RFC 791]).
いつもIP TOS分野セットでルーティング・プロトコルパケットを0に送るべきです。 できれば、ともに、送って、受け取ると、定期的なIPデータ通信量の上の優先をルーティング・プロトコルパケットに与えるべきです。 これを達成することへの援助として、OSPFプロトコルパケットで、それらのIP先行分野を値のInternetwork Controlに設定するはずです([RFC791]を見てください)。
[Moy] [Page 25] RFC 1247 OSPF Version 2 July 1991
[Moy][25ページ]RFC1247OSPFバージョン1991年7月2日
All OSPF protocol packets share a common protocol header that is described in Appendix A. The OSPF packet types are listed below in Table 8. Their formats are also described in Appendix A.
すべてのOSPFプロトコルパケットがAppendix A.で説明される一般的なプロトコルヘッダーを共有します。OSPFパケットタイプはTable8に以下に記載されています。 また、それらの形式はAppendix Aで説明されます。
Type Packet name Protocol function
__________________________________________________________
1 Hello Discover/maintain neighbors
2 Database Description Summarize database contents
3 Link State Request Database download
4 Link State Update Database update
5 Link State Ack Flooding acknowledgment
タイプPacket名前プロトコル機能__________________________________________________________ こんにちは、Discover/が隣人2Database記述Summarizeデータベースコンテンツ3Link州Request Databaseダウンロード4Link州Update Database最新版5のLink州Ack Flooding承認であることを支持する1
Table 8: OSPF packet types.
テーブル8: OSPFパケットはタイプされます。
OSPF's Hello protocol uses Hello packets to discover and maintain neighbor relationships. The Database Description and Link State Request packets are used in the forming of adjacencies. OSPF's reliable update mechanism is implemented by the Link State Update and Link State Acknowledgment packets.
OSPFのHelloプロトコルは、隣人関係を発見して、維持するのにHelloパケットを使用します。 Database記述とLink州Requestパケットは隣接番組の形成に使用されます。 OSPFの信頼できるアップデートメカニズムはLink州UpdateとLink州Acknowledgmentパケットによって実装されます。
Each Link State Update packet carries a set of new link state advertisements one hop further away from their point of origination. A single Link State Update packet may contain the link state advertisements of several routers. Each advertisement is tagged with the ID of the originating router and a checksum of its link state contents. The five different types of OSPF link state advertisements are listed below in Table 9.
それぞれのLink州Updateパケットが1セットの新しいリンク州の広告を運ぶ、ワンバウンド、それらの創作のポイントからさらに遠く。 単一のLink州Updateパケットはいくつかのルータのリンク州の広告を含むかもしれません。 各広告は起因するルータのIDとリンク州のコンテンツのチェックサムでタグ付けをされます。 5つの異なったタイプのOSPFリンク州の広告はTable9に以下に記載されています。
LS Advertisement Advertisement description
type name
____________________________________________________________________________
1 Router links advs. Originated by all routers. This
advs. advertisement describes the collected
states of the router's interfaces to an
area. Flooded throughout a single area
only.
____________________________________________________________________________
2 Network links Originated for multi-access networks by
advs. the Designated Router. This
advertisement contains the list of
routers connected to the network.
Flooded throughout a single area only.
LS Advertisement Advertisement記述型名____________________________________________________________________________ 1つのルータがadvsをリンクします。すべてのルータで、溯源されました。 これはadvsされます。広告はルータのインタフェースの集まっている州について領域に説明します。 ただ一つの領域だけ中で水につかります。 ____________________________________________________________________________ 2ネットワークはマルチアクセスネットワークのためにadvs Designated RouterでOriginatedをリンクします。 この広告はネットワークに関連づけられたルータのリストを含んでいます。 ただ一つの領域だけ中で水につかります。
[Moy] [Page 26] RFC 1247 OSPF Version 2 July 1991
[Moy][26ページ]RFC1247OSPFバージョン1991年7月2日
LS Advertisement Advertisement description
type name
____________________________________________________________________________
____________________________________________________________________________
3,4 Summary link Originated by area border routers, and
advs. flooded throughout their associated
area. Each summary link advertisement
describes a route to a destination
outside the area, yet still inside the
AS (i.e., an inter-area route). Type 3
advertisements describe routes to
networks. Type 4 advertisements
describe routes to AS boundary routers.
____________________________________________________________________________
5 AS external Originated by AS boundary routers, and
link advs. flooded throughout the AS. Each external
advertisement describes a route to a
destination in another Autonomous
System. Default routes for the AS can
also be described by AS external advertisements.
LS Advertisement Advertisement記述型名____________________________________________________________________________ ____________________________________________________________________________ 3、4Summaryは領域のそばでOriginatedをリンクします。境界ルータ、およびadvs彼らの関連領域中で水につかります。 それぞれの概要リンク広告は領域の外の目的地にルートを説明します、まだまだAS(すなわち、相互領域ルート)の中で。 タイプ3広告はルートをネットワークに説明します。 タイプ4広告はAS境界ルータにルートを説明します。 ____________________________________________________________________________ 5AS外部のOriginated、AS境界ルータ、およびリンクadvs AS中で水につかります。 それぞれの外部の広告は別のAutonomous Systemの目的地にルートを説明します。 また、ASの外部の広告でASのためのデフォルトルートを説明できます。
Table 9: OSPF link state advertisements.
テーブル9: OSPFは州の広告をリンクします。
As mentioned above, OSPF routing packets (with the exception of Hellos) are sent only over adjacencies. Note that this means that all 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ルーティングパケット(ハローズを除いた)を隣接番組だけの上に送ります。 これが、仮想の隣接番組の上に送られるものを除いて、すべてのプロトコルパケットが単一のIPホップを旅行することを意味することに注意してください。 受信者IPアドレスは、OSPFプロトコルパケットのIPソースアドレスがルータ隣接番組の片端であり、隣接番組のもう一方の端かIPマルチキャストアドレスです。
4.4 Basic implementation requirements
4.4 基本の実装要件
An implementation of OSPF requires the following pieces of system support:
OSPFの実装は以下のシステム支援を必要とします:
Timers
Two different kind of timers are required. The first kind, called
single shot timers, fire once and cause a protocol event to be
processed. The second kind, called interval timers, fire at
continuous intervals. These are used for the sending of packets at
regular intervals. A good example of this is the regular broadcast
of Hello packets (on broadcast networks). The granularity of both
kinds of timers is one second.
タイマTwo異なった種類のタイマが必要です。 単一のショットタイマと呼ばれる最初の種類で、一度発火して、プロトコルイベントを処理します。 インタバルタイマ、連続した間隔で、炎と呼ばれる第2種。 これらはパケットの発信に一定の間隔を置いて使用されます。 この好例はHelloパケット(放送網の)の定期的な放送です。 両方の種類のタイマの粒状は1秒です。
Interval timers should be implemented to avoid drift. In some
インタバルタイマは、ドリフトを避けるために実装されるべきです。 いくつかで
[Moy] [Page 27] RFC 1247 OSPF Version 2 July 1991
[Moy][27ページ]RFC1247OSPFバージョン1991年7月2日
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 timer interval at each firing.
ルータ実装であり、パケット処理はタイマ実行に影響できます。 すべて放送して、複数のルータがただ一つのネットワークに付けられているとき、これはルーティングパケット(避けられるべきである)の同期に通じることができます。 ドリフトを避けるためにタイマを実装することができないなら、少無作為の量は、各発火のときにタイマ間隔から加えられるべきであるか、または引き算されるべきです。
IP multicast
Certain OSPF packets use IP multicast. Support for receiving and
sending IP multicasts, along with the appropriate lower-level
protocol support, is required. These IP multicast packets never
travel more than one hop. For information on IP multicast, see [RFC
1112].
IPマルチキャストCertain OSPFパケットはIPマルチキャストを使用します。 IPマルチキャストを受けて、送るサポートが適切な低レベルプロトコルサポートと共に必要です。 これらのIPマルチキャストパケットはワンバウンドであるより決して移動しません。 IPマルチキャストの情報に関しては、[RFC1112]を見てください。
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 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
Remember that non-broadcast networks are multi-access networks such
as a X.25 PDN. On these networks, the Hello Protocol can be aided
by providing an indication to OSPF when an attempt is made to send a
packet to a dead or non-existent router. For example, on a PDN a
dead 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.
非放送低レベルプロトコルは非放送網があるRememberにX.25 PDNなどのマルチアクセスネットワークをサポートします。 これらのネットワークでは、死んでいるか実在しないルータにパケットを送るのを試みをするとき指示をOSPFに供給することによって、Helloプロトコルを支援できます。 例えば、死んでいるルータはX.25のレセプションによって示されて、適切な原因と病気の特徴でクリアしてください、そして、この情報がOSPFに通過されるだろうというPDNの上では、ことであるかもしれません。
List manipulation primitives
Much of the OSPF functionality is described in terms of its
operation on lists of link state advertisements. For example, the
advertisements that will be retransmitted to an adjacent router
until acknowledged are described as a list. Any particular
advertisement may be on many such lists. An OSPF implementation
needs to be able to manipulate these lists, adding and deleting
constituent advertisements as necessary.
OSPFの機能性のリスト操作基関数Muchはリンク州の広告のリストで操作で説明されます。 例えば、承認されるまで隣接しているルータに再送される広告はリストとして記述されています。 どんな特定の広告もそのような多くのリストにあるかもしれません。 必要に応じて構成している広告を加えて、削除して、OSPF実装は、これらのリストを操ることができる必要があります。
Tasking support
Certain procedures described in this specification invoke other
procedures. At times, these other procedures should be executed
in-line, that is, before the current procedure is finished. This is
indicated in the text by instructions to execute a procedure. At
other times, the other procedures are to be executed only when the
current procedure has finished. This is indicated by instructions
to schedule a task.
この仕様で説明されたサポートCertain手順に仕事を課して、他の手順を呼び出してください。 時には、すなわち、終わる前にこれらの他の手順はインラインで実行されるべきです。 これは、手順を実行するためにテキストで指示で示されます。 他の手順は現在の手順が他の時に終わったときだけ、実行されることです。 これは、タスクの計画をするように指示で示されます。
[Moy] [Page 28] RFC 1247 OSPF Version 2 July 1991
[Moy][28ページ]RFC1247OSPFバージョン1991年7月2日
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 link state advertisements. This enables routers supporting a mix of optional capabilities to coexist in a single Autonomous System.
OSPFプロトコルはいくつかの任意の能力を定義します。 ルータはそれがOSPF Helloパケットでサポートする任意の能力を示します、パケットとそのリンク州の広告におけるDatabase記述。 これは独身のAutonomous Systemに共存する任意の能力のミックスをサポートするルータを可能にします。
Some capabilities must be supported by all routers attached to a specific area. In this case, a router will not accept a neighbor's Hello 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 external routing capability (see below).
特定の領域に付けられたすべてのルータでいくつかの能力をサポートしなければなりません。 この場合、報告された能力にマッチがないと(すなわち、能力ミスマッチは、隣人関係が形成されるのを防ぎます)、ルータは隣人のHelloを受け入れないでしょう。 この例は外部のルーティング能力(以下を見る)です。
Other capabilities can be negotiated during the database synchronization process. This is accomplished by specifying the optional capabilities in Database Description packets. A capability mismatch with a neighbor is this case will result in only a subset of link state advertisements being exchanged between the two neighbors.
データベース同期プロセスの間、他の能力を交渉できます。 これは、Database記述パケットで任意の能力を指定することによって、達成されます。 隣人がいる能力ミスマッチは本件が2人の隣人の間で交換されるリンク州の広告の部分集合だけをもたらすということです。
The routing table build process can also be affected by the presence/absence of optional capabilities. For example, since the optional capabilities are reported in link state advertisements, routers incapable of certain functions can be avoided when building the shortest path tree. An example of this is the TOS routing capability (see below).
また、テーブルがプロセスを建てるルーティングは任意の能力の存在/欠如で影響を受けることができます。 任意の能力がリンク州の広告で報告されるので、最短パス木を建てるとき、例えば、ある機能で不可能なルータを避けることができます。 この例はTOSルーティング能力(以下を見る)です。
The current OSPF optional capabilities are listed below. See Section A.2 for more information.
現在のOSPF任意の能力は以下に記載されています。 詳しい情報に関してセクションA.2を見てください。
External routing capability
Entire OSPF areas can be configured as "stubs" (see Section 3.6).
AS external advertisements 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).
「スタッブ」として外部のルーティング能力Entire OSPF領域を構成できます(セクション3.6を見てください)。 ASの外部の広告はスタッブ領域へあふれないでしょう。 この能力はOSPFオプション分野にE-ビットによって表されます(セクションA.2を見てください)。 スタッブ領域の一貫した構成を確実にするために、そのような領域に連結するすべてのルータで、E-ビットはそれらのHelloパケットで明確にならなければなりません(セクション9.5と10.5を見てください)。
TOS capability
All OSPF implementations must be able to calculate separate routes
based on IP Type of Service. However, to save routing table space
and processing resources, an OSPF router can be configured to ignore
TOS when forwarding packets. In this case, the router calculates
routes for TOS 0 only. This capability is represented by the T-bit
in the OSPF options field (see Section A.2). TOS-capable routers
will attempt to avoid non-TOS-capable routers when calculating non-
TOS能力All OSPF実装はServiceのIP Typeに基づく別々のルートを計算できなければなりません。 しかしながら、経路指定テーブルスペースと処理がリソース、OSPFルータであると保存するのがパケットを進めるとき、TOSを無視するために構成できます。 この場合、ルータはTOS0だけのためのルートを計算します。 この能力はOSPFオプション分野にT-ビットによって表されます(セクションA.2を見てください)。 TOSできるルータが、計算するとき、できる非TOSルータを避けるのを試みる、非
[Moy] [Page 29] RFC 1247 OSPF Version 2 July 1991
[Moy][29ページ]RFC1247OSPFバージョン1991年7月2日
zero TOS paths.
TOS経路のゼロを合わせてください。
5. Protocol Data Structures
5. プロトコルデータ構造
The OSPF protocol is described in this specification 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. Areas, OSPF 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.
ASで唯一このルータを特定するルータのIDのa32ビットの番号。 1つの可能な実装戦略はルータに属す最も小さいIPインターフェース・アドレスを使用するだろうことです。
Pointers to 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 algorithm. Remember that each area runs a separate copy of
the basic algorithm.
ルータが関連している領域の領域構造Each1への指針には、それ自身のデータ構造があります。 このデータ構造は基本的なアルゴリズムの働きについて説明します。 各領域が基本的なアルゴリズムの別々のコピーを動かすのを覚えていてください。
Pointer to the backbone structure
The basic algorithm operates on the backbone as if it were an area.
For this reason the backbone is represented as an area structure.
基本的なアルゴリズムがまるでそれが領域であるかのようにバックボーンで操作するバックボーン構造への指針。 この理由で、バックボーンは領域構造として表されます。
Virtual links configured
The virtual links configured with this router as one endpoint. In
order to have configured virtual links, the router itself must be an
area border router. Virtual links are identified by the Router ID
of the other endpoint -- which is another area border router. These
two endpoint routers must be attached to a common area, called the
virtual link's transit area. Virtual links are part of the
backbone, and behave as if they were unnumbered point-to-point
networks between the two routers. A virtual link uses the intra-
area routing of its transit area to forward packets. Virtual links
are brought up and down through the building of the shortest-path
trees for the transit area.
仮想のリンクは1つの終点としてこのルータによって構成された仮想のリンクを構成しました。 仮想のリンクを構成したために、ルータ自体は境界ルータでなければなりません。 仮想のリンクはもう片方の終点(別の境界ルータである)のRouter IDによって特定されます。 仮想のリンクのトランジット領域と呼ばれる一般的な領域にこれらの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 EGP), or through configuration
information, or through a combination of the two (e.g., dynamic
external info. to be advertised by OSPF with configured metric).
Any router having these external routes is called an AS boundary
外部経路TheseのリストがAutonomous Systemへの外部の目的地へのルートである、別のルーティング・プロトコル(EGPなどの)の直接の経験を通して、または、設定情報を通して、または、2つのものの組み合わせを通してそれを獲得しました。(例えば、ダイナミックな外部のインフォメーション、構成されることでメートル法でOSPFによって広告を出される、) これらの外部経路を持っているどんなルータもAS境界と呼ばれます。
[Moy] [Page 30] RFC 1247 OSPF Version 2 July 1991
[Moy][30ページ]RFC1247OSPFバージョン1991年7月2日
router. These routes are advertised by the router to the entire AS
through AS external link advertisements.
ルータ。 ルータはASの外部のリンク広告で全体のASにこれらのルートの広告を出します。
List of AS external link advertisements
Part of the topological database. These have 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 link
advertisements have been self originated.
位相的なデータベースのASの外部のリンク広告Partのリスト。 これらはAS境界ルータから発しました。 彼らはAutonomous Systemへの外部の目的地にルートを包括します。 これらのASの外部のリンク広告のいくつかがルータがそれ自体でAS境界ルータであるなら自己であるというメモは起因しました。
The routing table
Derived from the topological database. Each destination that the
router can forward to is represented by a cost and a set of paths.
A path is described by its type and next hop. For more information,
see Section 11.
位相的なデータベースからの経路指定テーブルDerived。 ルータが進めることができる各目的地、費用と経路のセットによって表されます。 経路はタイプと次のホップによって説明されます。 詳しくは、セクション11を見てください。
TOS capability
This item indicates whether the router will calculate separate
routes based on TOS. This is a configurable parameter. For more
information, see Sections 4.5 and 16.9.
TOS能力Thisの品目は、ルータがTOSに基づく別々のルートを計算するかどうかを示します。 これは構成可能なパラメタです。 詳しくは、セクション4.5と16.9を見てください。
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がリンクのトランジット領域としてArea2で仮想のリンクをルータRT11に構成させることに注意してください。 これは図9の投げつけられた系列によって示されます。 仮想のリンクが最短パス木のビルを通してArea2にアクティブになると、それはバックボーンへのインタフェースになります(2つのバックボーンインタフェースが図9に表現されるのを見てください)。
6. The Area Data Structure
6. 領域データ構造
The area data structure contains all the information used to run the basic routing algorithm. Remember that each area maintains its own topological database. Router interfaces and adjacencies belong to a
領域データ構造は基本的なルーティング・アルゴリズムを実行するのに使用されるすべての情報を含んでいます。 各領域がそれ自身の位相的なデータベースを維持するのを覚えていてください。 ルータインタフェースと隣接番組はaに属します。
_______________________________________
_______________________________________
(Figure not included in text version.)
(テキストバージョンに含まれていなかった図。)
Figure 9: Router RT10's Data Structures
_______________________________________
図9: ルータRT10のデータ構造_______________________________________
[Moy] [Page 31] RFC 1247 OSPF Version 2 July 1991
[Moy][31ページ]RFC1247OSPFバージョン1991年7月2日
single area.
ただ一つの領域。
The backbone has all the properties of an area. For that reason it is also represented by an area data structure. Note that some items in the structure apply differently to the backbone than to areas.
バックボーンには、領域のすべての特性があります。 その理由で、また、それは領域データ構造によって表されます。 構造の数個の項目が領域よりバックボーンに異なって適用されることに注意してください。
The area topological (or link state) database consists of the collection of router links, network links and summary links advertisements that have originated from the area's routers. This information is flooded throughout a single area only. The list of AS external advertisements is also considered to be part of each area's topological database.
領域の位相的な(状態をリンクする)データベースはルータリンク、領域のルータから発したネットワークリンクと概要リンク広告の収集から成ります。 この情報はただ一つの領域だけ中で水につかっています。 また、ASの外部の広告のリストは各領域の位相的なデータベースの一部であると考えられます。
Area ID
A 32-bit number identifying the area. 0 is reserved for the area ID
of the backbone. If assigning subnetted networks as separate areas,
the IP network number could be used as the Area ID.
領域を特定する領域のIDのA32ビットの番号。 0 バックボーンの領域IDのために、予約されます。 分離した部分としてサブネット化したネットワークを割り当てるなら、IPネットワーク・ナンバーはArea IDとして使用されるかもしれません。
List of component address ranges
The address ranges that define the area. Each address range is
specified by an [address,mask] pair. Each network is then assigned
to an area depending on the address range that it falls into
(specified address ranges are not allowed to overlap). As an
example, if an IP subnetted network is to be its own separate OSPF
area, the area is defined to consist of a single address range - an
IP network number with its natural (class A, B or C) mask.
コンポーネントのリストは、範囲が領域を定義するアドレスの範囲であると扱います。 それぞれのアドレスの範囲は[アドレス、マスク]組によって指定されます。 そして、各ネットワークはそれが落ちるアドレスの範囲による領域に割り当てられます(指定されたアドレスの範囲は重なることができません)。 例と、領域はIPサブネット化したネットワークによるそれ自身の別々のOSPF領域であるつもりであるなら、ただ一つのアドレスの範囲から成るように定義されます--自然な(クラスA、BまたはC)マスクがあるIPネットワーク・ナンバー。
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 structure this list includes all the virtual adjacencies.
A virtual adjacency is identified by the router ID of its other
endpoint; its cost is the cost of the shortest intra-area path that
exists between the two routers.
関連ルータはその領域に接続するThisルータのインタフェースを連結します。 ルータインタフェースは唯一無二の1つの領域(または、バックボーン)に属します。 バックボーン構造に、このリストはすべての仮想の隣接番組を含んでいます。 仮想の隣接番組は他の終点のルータIDによって特定されます。 費用は2つのルータの間に存在する最も短いイントラ領域経路の費用です。
List of router links advertisements
A router links advertisement is generated by each router in the
area. It describes the state of the router's interfaces to the
area.
ルータのリストは広告がその領域の各ルータによって作られる広告Aルータリンクをリンクします。 それはルータのインタフェースの状態についてその領域に説明します。
List of network links advertisements
One network links advertisement is generated for each transit
multi-access network in the area. It describes the set of routers
currently connected to the network.
ネットワークのリストは広告がその領域のそれぞれのトランジットマルチアクセスネットワークのために作られる広告Oneネットワークリンクをリンクします。 それは現在ネットワークに関連づけられているルータのセットについて説明します。
List of summary links advertisements
Summary link advertisements originate from the area's area border
routers. They describe routes to destinations internal to the
概要のリストはSummaryリンク広告が領域の境界ルータから溯源する広告をリンクします。 彼らはルートを目的地に内部で説明します。
[Moy] [Page 32] RFC 1247 OSPF Version 2 July 1991
[Moy][32ページ]RFC1247OSPFバージョン1991年7月2日
Autonomous System, yet external to the area.
まだその領域への外部の自治のSystem。
Shortest-path tree
The shortest-path tree for the area, with this router itself as
root. Derived from the collected router links and network links
advertisements by the Dijkstra algorithm.
最短パスは根としてこのルータ自体で最短パス木を領域に木に追い上げます。 集まっているルータリンクとネットワークリンクから、ダイクストラアルゴリズムで広告を引き出しました。
Authentication type
The type of authentication used for this area. Authentication types
are defined in Appendix E. All OSPF packet exchanges are
authenticated. Different authentication schemes may be used in
different areas.
認証のタイプがこの領域に使用した認証タイプ。 認証タイプはAppendix E.で定義されます。All OSPFパケット交換は認証されます。 異なった認証体系は異なった領域で使用されるかもしれません。
External routing capability
Whether AS external advertisements will be flooded into/throughout
the area. This is a configurable parameter. If AS external
advertisements 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.
外部のルーティング能力Whether AS外部の広告は領域中に/へあふれるでしょう。 これは構成可能なパラメタです。 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 link that the router should
advertise into the area. There can be a separate cost configured
for each IP TOS. See Section 12.4.3 for more information.
StubDefaultCost If、ルータ自体が境界ルータである、領域はスタッブ領域として構成されて、次に、StubDefaultCostはルータが領域に広告を出すべきであるデフォルト概要リンクの費用を示します。 各IP TOSのために構成された別々の費用があることができます。 詳しい情報に関してセクション12.4.3を見てください。
Unless otherwise specified, the remaining sections of this document refer to the operation of the protocol in a single area.
別の方法で指定されない場合、このドキュメントの残っているセクションはただ一つの領域でのプロトコルの操作について言及します。
7. Bringing Up Adjacencies
7. 隣接番組を持って来ます。
OSPF creates adjacencies between neighboring routers for the purpose of exchanging routing information. Not every two neighboring routers will become adjacent. This section covers the generalities involved in creating adjacencies. For further details consult Section 10.
OSPFはルーティング情報を交換する目的のために隣接しているルータの間で隣接番組を作成します。 2つの隣接しているルータ毎は隣接するようにならないでしょう。 このセクションは隣接番組を作成するのにかかわる一般性をカバーします。 さらに詳しい明細についてはセクション10に相談してください。
7.1 The Hello Protocol
7.1、こんにちは、プロトコル
The Hello Protocol is responsible for establishing and maintaining neighbor relationships. It also ensures that communication between neighbors is bidirectional. Hello packets are sent periodically out all
Helloプロトコルは隣人関係を確立して、維持するのに原因となります。 また、それは隣人のコミュニケーションが確実に双方向になるようにします。 こんにちは、すべてからパケットを定期的に送ります。
[Moy] [Page 33] RFC 1247 OSPF Version 2 July 1991
[Moy][33ページ]RFC1247OSPFバージョン1991年7月2日
router interfaces. Bidirectional communication is indicated when the router sees itself listed in the neighbor's Hello Packet.
ルータは連結します。 ルータが、それ自体が隣人のHello Packetに記載されているのを見ると、双方向のコミュニケーションは示されます。
On multi-access networks, the Hello Protocol elects a Designated Router for the network. Among other things, the Designated Router controls what adjacencies will be formed over the network (see below).
マルチアクセスネットワークでは、HelloプロトコルはネットワークのためにDesignated Routerを選出します。 特に、Designated Routerは、どんな隣接番組がネットワークの上に形成されるかを制御します(以下を見てください)。
The Hello Protocol works differently on broadcast networks, as compared to non-broadcast 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 Hellos have been seen recently.
非放送網と比べて、Helloプロトコルは放送網に異なって取り組みます。 放送網では、各ルータ自体は定期的でマルチキャスティングHello Packetsの広告を出します。 これは、隣人がダイナミックに発見されるのを許容します。 これらのHello PacketsはDesignated Routerのアイデンティティに関するルータの意見、およびハローズが最近見られたルータのリストを含んでいます。
On non-broadcast networks some configuration information is 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 hellos to all other potential Designated Routers when its interface to the non-broadcast 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 hellos to all other routers attached to the network.
非放送網では、何らかの設定情報がHelloプロトコルの操作に必要です。 潜在的にDesignated Routerになるかもしれない各ルータで、他のすべてのルータのリストをネットワークに添付します。 Designated Routerを潜在的にして、非放送網へのインタフェースが最初に操作上になると、ルータは他のすべての潜在的Designated Routersにhellosを送ります。 これはネットワークに関してDesignated Routerを見つける試みです。 ルータ自体がDesignated Routerに選出されるなら、それはネットワークに付けられた他のすべてのルータにhellosを送り始めます。
After a neighbor has been discovered, bidirectional communication ensured, and (if on a multi-access 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). An attempt is always made to establish adjacencies over point-to-point networks and virtual links. The first step in bringing up an adjacency is to synchronize the neighbors' topological databases. This is covered in the next section.
隣人が確実にされた、発見されて、双方向のコミュニケーションと、(マルチアクセスネットワークで)Designated Routerに選出されたなった後に、隣接番組が隣人と共に形成されるべきであるかどうかに関して(セクション10.4を見てください)決定をします。 二地点間ネットワークと仮想のリンクの上に隣接番組を確立するのを試みをいつもします。 隣接番組を持って来ることにおける第一歩は隣人の位相的なデータベースを同期させることです。 これは次のセクションでカバーされています。
7.2 The Synchronization of Databases
7.2 データベースの同期
In an SPF-based routing algorithm, it is very important for all routers' topological 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 link state advertisements belonging to the database. When the neighbor sees a link state advertisement that is more recent than its own database copy, it makes a note that this newer advertisement should be requested.
SPFベースのルーティング・アルゴリズムで、すべてのルータの位相的なデータベースが連動していた状態で残っているのは、非常に重要です。 隣接しているルータだけが連動したままで残っているのを必要とすることによって、OSPFはこれを簡素化します。 同期プロセスは隣接番組を持って来るルータ試みの次第始まります。 各ルータは、Database記述パケットの系列を隣人に送ることによって、データベースについて説明します。 それぞれのDatabase記述Packetはデータベースに属す1セットのリンク州の広告について説明します。 隣人がそれ自身のデータベースコピーより最近のリンク州の広告を見るとき、このより新しい広告が要求されているべきであるのはメモを取ります。
This sending and receiving of Database Description packets is called the "Database Exchange Process". During this process, the two routers form
Database記述パケットのこの送受信は「データベース交換プロセス」と呼ばれます。 このプロセスの間、2つのルータが形成されます。
[Moy] [Page 34] RFC 1247 OSPF Version 2 July 1991
[Moy][34ページ]RFC1247OSPFバージョン1991年7月2日
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 constant RxmtInterval.
マスター/奴隷関係。 それぞれのDatabase記述Packetには、一連番号があります。 マスター(投票)によって送られたデータベース記述Packetsは、一連番号を反響することで奴隷によって承認されます。 投票と彼らの応答の両方がリンク州のデータの合計を含んでいます。 マスターはDatabase記述Packetsを再送できた唯一無二です。 それはそう固定間隔だけで、します。その長さは構成された一定のRxmtIntervalです。
Each Database Description contains an indication that there are more packets to follow --- the M-bit. The Database Exchange Process is over when a router has received and sent Database Description Packets with the M-bit off.
それぞれのDatabase記述は続くより多くのパケットがあるという指示を含んでいます。--- M-ビット。 ルータがDatabase記述Packetsを受けて、M-ビットがオフな状態で送ったとき、Database Exchange Processは終わっています。
During and after the Database Exchange Process, each router has a list of those link state advertisements for which the neighbor has more up- to-date instances. These advertisements 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' link state advertisements.
Database Exchange ProcessとDatabase Exchange Processの後に、各ルータで、それらのリストは隣人が、より多くの日付までのインスタンスを持っている州の広告をリンクします。 これらの広告はLink州Request Packetsで要求されています。 満足していないリンク州Requestパケットは時間RxmtIntervalの固定間隔で、再送されます。 記述Processが完成したDatabaseとすべてのLink州Requestsが満足したとき、データベースは連動していると考えられます、そして、ルータは完全に隣接しているとマークされます。 このとき、隣接番組の完全に機能的であり、2つのルータのリンク州の広告に広告を出します。
The adjacency is used by the flooding procedure as soon as the Database Exchange Process begins. This simplifies database synchronization, and guarantees that it finishes in a predictable period of time.
Database Exchange Processが始まるとすぐに、隣接番組は氾濫手順で使用されます。 これは、データベース同期を簡素化して、それが予測できる期間で終わるのを保証します。
7.3 The Designated Router
7.3 代表ルータ
Every multi-access network has a Designated Router. The Designated Router performs two main functions for the routing protocol:
あらゆるマルチアクセスネットワークには、Designated Routerがあります。 Designated Routerはルーティング・プロトコルのために2つの主な機能を実行します:
o The Designated Router originates a network links advertisement on
behalf of the network. This advertisement lists the set of routers
(including the Designated Router itself) currently attached to the
network. The Link State ID for this advertisement (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 subnet/network
mask.
o Designated Routerはネットワークを代表してネットワークリンク広告を溯源します。 この広告は現在ネットワークに付けられているルータ(Designated Router自身を含んでいる)のセットを記載します。 この広告(セクション12.1.4を見る)のためのLink州IDはDesignated RouterのIPインターフェース・アドレスです。 そして、サブネット/ネットワークマスクを使用することによって、IPネットワーク・ナンバーを得ることができます。
o The Designated router becomes adjacent to all other routers on the
network. Since the link state databases are synchronized across
adjacencies (through adjacency bring-up and then the flooding
procedure), the Designated Router plays a central part in the
synchronization process.
o Designatedルータはネットワークの他のすべてのルータに隣接してなります。 そして、以来リンク州のデータベースが隣接番組の向こう側に同期する、(通じて、隣接番組が-上にもたらす、次に、氾濫手順)、Designated Routerは同期プロセスで中央の役割を果たします。
[Moy] [Page 35] RFC 1247 OSPF Version 2 July 1991
[Moy][35ページ]RFC1247OSPFバージョン1991年7月2日
The Designated Router is elected by the Hello Protocol. A router's Hello Packet contains its Router Priority, which is configurable on a per-interface basis. In general, when a router's interface to a network first becomes functional, it checks to see whether there is currently a Designated Router for the network. If there is, it accepts that Designated Router, regardless of its Router Priority. (This makes it harder to predict the identity of the Designated Router, but ensures that the Designated Router changes less often. See below.) Otherwise, the router itself becomes Designated Router if it has the highest Router Priority on the network. A more detailed (and more accurate) description of Designated Router election is presented in Section 9.4.
Designated RouterはHelloプロトコルによって選出されます。 ルータのHello PacketはRouter Priorityを含んでいます。(Router Priorityは1インタフェースあたり1個のベースで構成可能です)。 一般に、ネットワークへのルータのインタフェースが最初に機能的になると、それは、ネットワークに関してDesignated Routerが現在あるかどうか確認するためにチェックします。 あれば、それはRouter PriorityにかかわらずそのDesignated Routerを受け入れます。 (これは、Designated Routerのアイデンティティを予測するのをより困難にしますが、Designated Routerが、よりしばしば変化するのを確実にします。 以下を見てください。) さもなければ、ネットワークで最も高いRouter Priorityを持っているなら、ルータ自体はDesignated Routerになります。 Designated Router選挙の、より詳細で(より正確)の記述はセクション9.4に提示されます。
The Designated Router is the endpoint of many adjacencies. In order to optimize the flooding procedure on broadcast networks, the Designated Router multicasts its Link State Update Packets to the address AllSPFRouters, rather than sending separate packets over each adjacency.
Designated Routerは多くの隣接番組の終点です。 放送網の氾濫手順を最適化するために、発信よりむしろアドレスAllSPFRoutersへのDesignated RouterマルチキャストLink州Update Packetsは各隣接番組の上にパケットを分離します。
Section 2 of this document discusses the directed graph representation of an area. Router nodes are labelled with their Router ID. Broadcast 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 link state advertisements. Until the topological databases again converge, some temporary loss of connectivity may result. This may result in ICMP unreachable messages being sent in response to data traffic. For that reason, the Designated Router should change only infrequently. Router Priorities should be configured so that the most dependable router on a network eventually becomes Designated Router.
このドキュメントのセクション2は領域の有向グラフ表現について論じます。 ルータノードはそれらのRouter IDで分類されます。 放送ネットワーク・ノードは実際にそれらのDesignated RouterのIPアドレスで分類されます。 Designated Routerが変化するとき、まるでグラフのネットワーク・ノードを完全に新しいノードに取り替えるかのように見えるということになります。 これで、ネットワークとそのすべての付属ルータが新しいリンク州の広告を溯源するでしょう。 位相的なデータベースが再び一点に集まるまで、接続性のいくらかの一時的な損失が結果として生じるかもしれません。 これはデータ通信量に対応して送られるICMPの手の届かないメッセージをもたらすかもしれません。 その理由で、Designated Routerはまれにだけ変化するはずです。 ルータPrioritiesが構成されるべきであるので、ネットワークで最も信頼できるルータは結局、Designated Routerになります。
7.4 The Backup Designated Router
7.4 バックアップに指定されたルータ
In order to make the transition to a new Designated Router smoother, there is a Backup Designated Router for each multi-access 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 router and all other routers attached to the network. Part of the adjacency forming process is the synchronizing of topological 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 take to flood the new link state advertisements (which announce the new Designated Router).
新しいDesignated Routerへの変遷をより滑らかにするように、それぞれのマルチアクセスネットワークのためのBackup Designated Routerがあります。 Backup Designated Routerはネットワークのすべてのルータに隣接してもいて、前のDesignated Routerが失敗すると、Designated Routerになります。 Backup Designated Routerが全くなければ、新しいDesignated Routerがいつ必要で、新しい隣接番組になったかはネットワークに付けられたルータと他のすべてのルータの間で形成されなければならないでしょうに。 隣接番組形成プロセスの一部は位相的なデータベースの連動です。(潜在的に、データベースはかなり長い時間がかかるかもしれません)。 この間に、ネットワークはトランジットデータ通信量に利用可能でないでしょう。 Backup Designatedは、既に存在しているので、これらの隣接番組を形成する必要性を取り除きます。 トランジットトラフィックにおける、分裂の一区切りがそれと同じくらい長い間だけ続くこの手段は、新しいリンク州の広告(新しいDesignated Routerを発表する)をあふれさせるように取ります。
[Moy] [Page 36] RFC 1247 OSPF Version 2 July 1991
[Moy][36ページ]RFC1247OSPFバージョン1991年7月2日
The Backup Designated Router does not generate a network links advertisement for the network. (If it did, the transition to a new Designated Router would be even faster. However, this is a tradeoff between database size and speed of convergence when the Designated Router disappears.)
Backup Designated Routerはネットワークのためにネットワークリンクに広告を作りません。 (そうするなら、新しいDesignated Routerへの変遷はさらに速いでしょうに。 しかしながら、Designated Routerが見えなくなるとき、これは集合のデータベースサイズと速度の間の見返りです。)
The Backup Designated Router is also elected by the Hello Protocol. Each Hello Packet has a field that specifies the Backup Designated Router for the network.
また、Backup Designated RouterはHelloプロトコルによって選出されます。 各Hello Packetには、ネットワークにBackup Designated Routerを指定する分野があります。
In some steps of the flooding procedure, the Backup Designated Router plays a passive role, letting the Designated Router do more of the work. This cuts down on the amount of local routing traffic. See Section 13.3 for more information.
氾濫手順の数ステップでは、Backup Designated Routerは受け身の役割を果たします、Designated Routerに一層の仕事をさせて。 これは地方のルーティングトラフィックの量を減らします。 詳しい情報に関してセクション13.3を見てください。
7.5 The graph of adjacencies
7.5 隣接番組のグラフ
An adjacency is bound to the network that the two routers have in common. If two routers have multiple networks in common, they may have multiple adjacencies between them.
隣接番組は2つのルータが共通であるネットワークに縛られます。 2つのルータが複数のネットワークが共通であるなら、それらの間には、複数の隣接番組があるかもしれません。
One can picture the collection of adjacencies on a network as forming an undirected graph. The vertices consist of routers, with an edge joining two routers if they are adjacent. The graph of adjacencies describes the flow of routing protocol packets, and in particular Link State Updates, through the Autonomous System.
人はネットワークにおける非指示されたグラフを形成するとしての隣接番組の収集について描写できます。 頭頂はそれらが隣接しているなら縁が2つのルータを接合しているルータから成ります。 隣接番組のグラフはルーティング・プロトコルパケット、および特にLink州Updatesの流れについて説明します、Autonomous Systemを通して。
Two graphs are possible, depending on whether the common network is multi-access. On physical point-to-point networks (and virtual links), the two routers joined by the network will be adjacent after their databases have been synchronized. On multi-access networks, both the Designated Router and the Backup Designated Router are adjacent to all other routers attached to the network, and these account for all adjacencies.
一般的なネットワークがマルチアクセサリーであるかどうかによって、2つのグラフが可能です。 物理的な二地点間ネットワーク(そして、仮想のリンク)では、それらのデータベースが同期した後にネットワークによって合流された2つのルータが隣接するでしょう。 マルチアクセスネットワークでは、Designated RouterとBackup Designated Routerの両方がすべての隣接番組のためにネットワーク、およびこれらのアカウントに付けられた他のすべてのルータに隣接しています。
These graphs are shown in Figure 10. It is assumed that router RT7 has become the Designated Router, and router RT3 the Backup Designated Router, for the network N2. The Backup Designated Router performs a lesser function during the flooding procedure than the Designated Router (see Section 13.3). This is the reason for the dashed lines connecting the Backup Designated Router RT3.
これらのグラフは図10に示されます。 ルータRT7がDesignated Router、およびルータRT3Backup Designated Routerになったと思われます、ネットワークN2のために。 Backup Designated Routerは氾濫手順の間、Designated Routerより少ない機能を実行します(セクション13.3を見てください)。 これはBackup Designated Router RT3を接続する投げつけられた系列の理由です。
8. Protocol Packet Processing
8. プロトコルパケット処理
This section discusses the general processing of routing protocol packets. It is very important that the router topological databases
このセクションはルーティング・プロトコルパケットの一般的な処理について論じます。 それが非常に重要である、それ、ルータの位相的なデータベース
[Moy] [Page 37] RFC 1247 OSPF Version 2 July 1991
[Moy][37ページ]RFC1247OSPFバージョン1991年7月2日
remain synchronized. For this reason, routing protocol packets should get preferential treatment over ordinary data packets, both in sending and receiving.
連動したままで、残ってください。 この理由で、ルーティング・プロトコルパケットは発信と受信で普通のデータ・パケットの上に優遇を得るはずです。
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 protocol packets travel a single IP hop, except those sent over virtual links.
隣接番組だけに沿ってルーティング・プロトコルパケットを送ります。 これは、仮想のリンクの上に送られたものを除いて、すべてのプロトコルパケットが単一のIPホップを旅行することを意味します。
All routing protocol packets begin with a standard header. The sections below give the details on how to fill in and verify this standard header. Then, for each packet type, the section is listed that gives more details on that particular packet type's processing.
すべてのルーティング・プロトコルパケットが標準のヘッダーと共に始まります。 下のセクションはこの標準のヘッダーに記入して、どう確かめるかに関する詳細を述べます。 そして、それぞれのパケットタイプ、それに関するその他の詳細を特定に与える記載されたセクションにパケットタイプは処理しています。
8.1 Sending protocol packets
8.1 送付プロトコルパケット
When a router sends a routing protocol packet, it fills in the fields of that standard header as follows. For more details on the header format consult Section A.3.1:
ルータがルーティング・プロトコルパケットを送るとき、それは以下のその標準のヘッダーの分野に記入します。 ヘッダー形式に関するその他の詳細に関しては、セクションA.3.1に相談してください:
Version #
Set to 2, the version number of the protocol as documented in this
specification.
2へのバージョン#Set、記録されるとしてのこの仕様によるプロトコルのバージョン番号。
Packet type
The type of OSPF packet, such as Link state Update or Hello Packet.
パケットはLink州のUpdateかHello PacketなどのOSPFパケットのタイプをタイプします。
Packet length
The length of the entire OSPF packet in bytes, including the
standard header.
パケット長は標準のヘッダーを含むバイトで表現される全体のOSPFパケットの長さです。
Router ID
The identity of the router itself (who is originating the packet).
ルータID、ルータ(パケットを溯源している)自体のアイデンティティ。
______________________________________
______________________________________
(Figure not included in text version.)
(テキストバージョンに含まれていなかった図。)
Figure 10: The graph of adjacencies
Figure 11: Interface state changes
______________________________________
図10: 隣接番組図のグラフ、11: 界面準位変化______________________________________
[Moy] [Page 38] RFC 1247 OSPF Version 2 July 1991
[Moy][38ページ]RFC1247OSPFバージョン1991年7月2日
Area ID
The area that the packet is being sent into.
領域ID、パケットが送られる領域。
Checksum
The standard IP 16-bit one's complement checksum of the entire OSPF
packet, excluding the 64-bit authentication field. This checksum
should be calculated before handing the packet to the appropriate
authentication procedure.
チェックサム、64ビットの認証分野を除いた全体のOSPFパケットの標準のIP16ビットの1の補数チェックサム。 適切な認証手順にパケットを手渡す前に、このチェックサムは計算されるべきです。
Autype and Authentication
Each OSPF packet exchange is authenticated. Authentication types
are assigned by the protocol and documented in Appendix E. A
different authentication scheme can be used for each OSPF area. The
64-bit authentication field is set by the appropriate authentication
procedure (determined by Autype). This procedure should be the last
called when forming the packet to be sent. The setting of the
authentication field is determined by the packet contents and the
authentication key (which is configurable on a per-interface basis).
AutypeとAuthentication Each OSPFパケット交換は認証されます。 認証タイプを、プロトコルによって割り当てられて、Appendix E.に記録します。それぞれのOSPF領域にA異なった認証体系を使用できます。 適切な認証手順(Autypeで断固とした)で64ビットの認証分野は設定されます。 この手順は送られるパケットを形成するとき呼ばれる最終であるべきです。 認証分野の設定はパケットコンテンツと認証キーで決定します(1インタフェースあたり1個のベースで構成可能です)。
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 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を見る)です。 ユニキャストが放送網にあるので、唯一のパケットは発信しませんでした。 これらのネットワークでは、マルチキャストの目的地AllSPFRoutersにHelloパケットを送ります、そして、Designated RouterとそのBackupは両方のLink州Update Packetsを送ります、そして、マルチキャストへのLink州Acknowledgment PacketsはAllSPFRoutersを扱います、それらのLink州UpdateとLink州Acknowledgment Packetsの両方が他のすべてのルータでマルチキャストアドレスAllDRoutersに行きますが。
Retransmissions of Link State Update packets are ALWAYS sent as unicasts.
Link州UpdateパケットのRetransmissionsはユニキャストとして送られたALWAYSです。
The IP source address should be set to the IP address of the sending interface. Interfaces to unnumbered point-to-point networks have no associated IP address. On these interfaces, the IP source should be set to any of the other IP addresses belonging to the router. For this reason, there must be at least one IP address assigned to the router.[2] Note that, for most purposes, virtual links act precisely the same as unnumbered point-to-point networks. However, each virtual link does have an interface IP address (discovered during the routing table build process) which is used as the IP source when sending packets over the virtual link.
IPソースアドレスは送付インタフェースのIPアドレスに設定されるべきです。 無数の二地点間ネットワークへのインタフェースには、どんな関連IPアドレスもありません。 これらのインタフェースでは、IPソースはルータに属す他のIPアドレスのいずれへのセットであるべきです。 この理由で、仮想のリンクがほとんどの目的のために無数の二地点間ネットワークと正確に同じに作動するというルータ.[2]メモに割り当てられた少なくとも1つのIPアドレスがあるに違いありません。 しかしながら、それぞれの仮想のリンクには、仮想のリンクの上にパケットを送るときIPソースとして使用されるインタフェースIPアドレス(経路指定テーブルの間、プロセスを建てるように発見する)があります。
[Moy] [Page 39] RFC 1247 OSPF Version 2 July 1991
[Moy][39ページ]RFC1247OSPFバージョン1991年7月2日
For more information on the format of specific packet types, consult the sections listed in Table 10.
特定のパケットタイプの形式の詳しい情報に関しては、Table10に記載されたセクションに相談してください。
Type Packet name detailed section (transmit)
_________________________________________________________
1 Hello Section 9.5
2 Database description Section 10.8
3 Link state request Section 10.9
4 Link state update Section 13.3
5 Link state ack Section 13.5
タイプPacketは詳細なセクションを命名します(伝わってください)。_________________________________________________________ 1 こんにちは、記述セクション10.8 3Linkがセクション10.9 4Link州のアップデートセクション13.3 5Link州のackセクション13.5を要求すると述べるセクション9.5 2Database
Table 10: Sections describing packet transmission.
テーブル10: パケット伝送を説明するセクション。
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がインタフェースでOSPFプロトコルパケットをネットワークN8に受けるなら、それは領域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マルチキャストの1つがAllSPFRoutersかAllDRoutersを扱います。
o The IP protocol specified must be OSPF (89).
o 指定されたIPプロトコルはOSPF(89)であるに違いない。
o Locally originated packets should not be passed on to OSPF. That
is, the source IP address should be examined to make sure this is
not a multicast packet that the router itself generated.
o 局所的に溯源されたパケットをOSPFに通過するべきではありません。 すなわち、ソースIPアドレスは、これがルータ自体が生成したマルチキャストパケットでないことを確実にするために調べられるべきです。
[Moy] [Page 40] RFC 1247 OSPF Version 2 July 1991
[Moy][40ページ]RFC1247OSPFバージョン1991年7月2日
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 16-bit checksum of the OSPF packet's contents must be verified.
Remember that the 64-bit authentication field must be excluded from
the checksum calculation.
o OSPFパケットのコンテンツの16ビットのチェックサムについて確かめなければなりません。 チェックサム計算から64ビットの認証分野を除かなければならなかったのを覚えていてください。
o The Area ID found in the OSPF header must be verified. If both of
the following cases fail, the packet should be discarded. The Area
ID specified in the header must either:
o OSPFヘッダーで見つけられたArea IDについて確かめなければなりません。 以下のケースの両方が失敗するなら、パケットは捨てられるべきです。 ヘッダーで指定されたArea IDはそうしなければなりません:
(1) Match the Area ID of the receiving interface. In this case, the
packet has been sent over a single hop. Therefore, the packet's
IP source address must be on the same network as the receiving
interface. This can be determined by comparing the packet's IP
source address to the interface's IP address, after masking both
addresses with the interface mask.
(1) 受信インタフェースのArea IDを合わせてください。 この場合、単一のホップの上にパケットを送りました。 したがって、パケットのIPソースアドレスが受信インタフェースと同じネットワークにあるに違いありません。 これはパケットのIPソースアドレスをインタフェースのIPアドレスにたとえることによって、決定できます、インタフェースマスクで両方のアドレスにマスクをかけた後に。
(2) Indicate the backbone. In this case, the packet has been sent
over a virtual link. The receiving router must be an area
border router, and the router ID specified in the packet (the
source router) must be the other end of a configured virtual
link. The receiving interface must also attach to the virtual
link's configured transit area. If all of these checks succeed,
the packet is accepted and is from now on associated with the
virtual link (and the backbone area).
(2) バックボーンを示してください。 この場合、仮想のリンクの上にパケットを送りました。 受信ルータは境界ルータであるに違いありません、そして、パケット(ソースルータ)で指定されたルータ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 受信インタフェースの状態がDRかBackup(セクション9.1を見る)である場合にだけIPの目的地がAllDRoutersであるパケットを受け入れるべきです。
o The Authentication type specified must match the authentication type
specified for the associated area.
o タイプが指定したAuthenticationは関連領域に指定された認証タイプに合わなければなりません。
Next, the packet must be authenticated. This depends on the authentication type specified (see Appendix E). The authentication procedure may use an Authentication key, which can be configured on a per-interface basis. If the authentication fails, the packet should be discarded.
次に、パケットを認証しなければなりません。 これはタイプが指定した認証によります(Appendix Eを見てください)。 認証手順はAuthenticationキーを使用するかもしれません。(1インタフェースあたり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
そして、パケットタイプがHelloであるなら、それはHelloプロトコルによってさらに処理されるべきです(セクション10.5を見てください)。 隣接番組だけに他のすべてのパケットタイプを送るか、または受け取ります。 パケットにはなければならないこの手段
[Moy] [Page 41] RFC 1247 OSPF Version 2 July 1991
[Moy][41ページ]RFC1247OSPFバージョン1991年7月2日
been sent by one of the router's active neighbors. If the receiving interface is a multi-access network (either broadcast or non-broadcast) the sender is identified by the IP source address found in the packet's IP header. If the receiving interface is a point-to-point link 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.
ルータの活発な隣人のひとりによって送られます。 受信インタフェースがマルチアクセスネットワーク(放送されたか、非放送している)であるなら、送付者はパケットのIPヘッダーで見つけられたIPソースアドレスによって特定されます。 受信インタフェースがポイントツーポイント接続か仮想のリンクであるなら、送付者はパケットのOSPFヘッダーで見つけられたRouter ID(ソースルータ)によって特定されます。 受信インタフェースに関連しているデータ構造は活発な隣人のリストを含んでいます。 どんな活発な隣人にも合っていないパケットは捨てられます。
At this point all received protocol packets are associated with an active neighbor. For the further input processing of specific packet types, consult the sections listed in Table 11.
ここに、すべての容認されたプロトコルパケットが活発な隣人に関連しています。 特定のパケットタイプのさらなる入力処理には、Table11に記載されたセクションに相談してください。
Type Packet name detailed section (receive)
________________________________________________________
1 Hello Section 10.5
2 Database description Section 10.6
3 Link state request Section 10.7
4 Link state update Section 13
5 Link state ack Section 13.7
タイプPacketは詳細なセクションを命名します(受信してください)。________________________________________________________ 1 こんにちは、記述セクション10.6 3Linkがセクション10.7 4Link州のアップデートセクション13 5Link州のackセクション13.7を要求すると述べるセクション10.5 2Database
Table 11: Sections describing packet reception.
テーブル11: パケットレセプションについて説明するセクション。
9. The Interface Data Structure
9. インタフェースデータ構造
An OSPF interface is the connection between a router and a network. There is a single OSPF interface structure for each attached network; each interface structure has at most one IP interface address (see below). The support for multiple addresses on a single network is a matter for future consideration.
OSPFインタフェースはルータとネットワークとの関係です。 それぞれの付属ネットワークに、ただ一つの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 link state advertisements reflect the state of its interfaces and their associated adjacencies.
OSPFインタフェースが付属ネットワークを含む領域に属すと考えることができます。 このインタフェースの上でルータによって溯源されたすべてのルーティング・プロトコルパケットがインタフェースのArea IDでラベルされます。 1つ以上のルータ隣接番組がインタフェースの上で展開するかもしれません。 ルータのリンク州の広告はインタフェースとそれらの関連隣接番組の状態を反映します。
The following data items are associated with an interface. Note that a number of these items are actually configuration for the attached network; those items must be the same for all routers connected to the network.
以下のデータ項目はインタフェースに関連しています。 これらの多くの項目が実際に付属ネットワークのための構成であることに注意してください。 ネットワークに関連づけられたすべてのルータに、それらの項目は同じであるに違いありません。
[Moy] [Page 42] RFC 1247 OSPF Version 2 July 1991
[Moy][42ページ]RFC1247OSPFバージョン1991年7月2日
Type
The kind of network to which the interface attaches. Its value is
either broadcast, non-broadcast yet still multi-access, point-to-
point or virtual link.
インタフェースが付くネットワークの種類をタイプしてください。 値は、放送されて、非放送ですが、マルチアクセスしているまだポイントからポイントか仮想のリンクです。
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 link state advertisements.
インタフェースの機能的なレベルを述べてください。 州は、完全な隣接番組がインタフェースの上で形成できるかどうか決定します。 また、状態はルータのリンク州の広告に反映されます。
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
This indicates the portion of the IP interface address that
identifies the attached network. This is often referred to as the
subnet mask. Masking the IP interface address with this value
yields the IP network number of the attached network.
IPインタフェースマスクThisは付属ネットワークを特定するIPインターフェース・アドレスの部分を示します。 これはしばしばサブネットマスクと呼ばれます。 この値でIPインターフェース・アドレスにマスクをかけると、付属ネットワークのIPネットワーク・ナンバーはもたらされます。
Area ID
The Area ID to which the attached network belongs. All routing
protocol packets originating from the interface are labelled with
this Area ID.
付属ネットワークが属する領域ID Area ID。 インタフェースから発するすべてのルーティング・プロトコルパケットがこのArea IDでラベルされます。
HelloInterval
The length of time, in seconds, between the Hello packets that the
router sends on the interface. Advertised in Hello packets sent out
this interface.
ルータがインタフェースで送るHelloパケットの間の秒の時間の長さのHelloInterval。 Helloの広告に掲載されていて、パケットはこのインタフェースを出しました。
RouterDeadInterval
The number of seconds before the router's neighbors will declare it
down, when they stop hearing the router's hellos. Advertised in
Hello packets sent out this interface.
彼らが、ルータのhellosを聞くのを止めると、ルータの隣人の前の秒数が望んでいるRouterDeadIntervalは下にそれを宣言します。 Helloの広告に掲載されていて、パケットはこのインタフェースを出しました。
InfTransDelay
The estimated number of seconds it takes to transmit a Link State
Update Packet over this interface. Link state advertisements
contained in the update packet will have their age incremented by
this amount before transmission. This value should take into
account transmission and propagation delays; it must be greater than
zero.
概算のInfTransDelayは、Link州Update Packetをこのインタフェースの上に伝えるのにそれがかかる秒に付番します。 アップデートパケットに含まれたリンク州の広告で、トランスミッションの前にこの量で彼らの時代を増加するでしょう。 この値はトランスミッションと伝播遅延を考慮に入れるべきです。 それはゼロ以上であるに違いありません。
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
ルータPriority An、8ビットの符号のない整数。 ネットワークに付けられた2つのルータが、最も高いことでDesignated Router、ものになるのをともに試みるとき
[Moy] [Page 43] RFC 1247 OSPF Version 2 July 1991
[Moy][43ページ]RFC1247OSPFバージョン1991年7月2日
Router Priority takes precedence. A router whose Router Priority is
set to 0 is ineligible to become Designated Router on the attached
network. Advertised in Hello packets sent out this interface.
ルータPriorityは優先します。 Router Priorityが0に用意ができているルータは付属ネットワークでDesignated Routerになるのにおいて不適格です。 Helloの広告に掲載されていて、パケットはこのインタフェースを出しました。
Hello Timer
An interval timer that causes the interface to send a Hello packet.
This timer fires every HelloInterval seconds. Note that on non-
broadcast networks a separate Hello packet is sent to each qualified
neighbor.
こんにちは、Timer An。インタフェースがHelloパケットを送るインタバルタイマ。 あらゆるHelloIntervalが後援するこのタイマ炎。 非放送網では、別々のHelloパケットがそれぞれの適任の隣人に送られることに注意してください。
Wait Timer
A single shot timer that causes the interface to exit the Waiting
state, and as a consequence select a Designated Router on the
network. The length of the timer is RouterDeadInterval seconds.
待ちTimer AはインタフェースがWaiting状態を出るショットタイマを選抜して、結果としてネットワークでDesignated Routerを選定します。 タイマの長さはRouterDeadInterval秒です。
List of neighboring routers
The other routers attached to this network. On multi-access
networks, 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 multi-access networks by the
Hello Protocol. Two pieces of identification are kept for the
Designated Router: its Router ID and its interface IP address on the
network. The Designated Router advertises link state for the
network. The network link state advertisement is labelled with the
Designated Router's IP address. This item is initialized to 0,
which indicates the lack of a Designated Router.
付属ネットワークのために選択されたDesignated RouterにRouterを指定しました。 Designated RouterはすべてのマルチアクセスネットワークでHelloプロトコルによって選択されます。 識別の2つの断片がDesignated Routerのために保たれます: ネットワークに関するRouter IDとそのインタフェースIPアドレス。 Designated Routerはネットワークのためにリンク状態の広告を出します。 ネットワークリンク州の広告はDesignated RouterのIPアドレスで分類されます。 この項目は0に初期化されます(Designated Routerの不足を示します)。
Backup Designated Router
The Backup Designated Router is also selected on all multi-access
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. Initialized to 0
indicating the lack of a Backup Designated Router.
また、バックアップDesignated Router Backup Designated RouterはすべてのマルチアクセスネットワークでHelloプロトコルによって選択されます。 付属ネットワークのすべてのルータがDesignated RouterとBackup Designated Routerの両方に隣接してなります。 現在のDesignated Routerが失敗すると、Backup Designated RouterはDesignated Routerになります。 Backup Designated Routerの不足を示す0に初期化されます。
Interface output cost(s)
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 links advertisement. There may be a
separate cost for each IP Type of Service. The cost of an interface
must be greater than zero.
インタフェース出力は(s) リンク状態でメートル法で言い表されたインタフェースにパケットを送る費用かかります。 ルータにおけるこのインタフェースへのリンク費用が広告をリンクするとき、これの広告を出します。 ServiceのそれぞれのIP Typeのための別々の費用があるかもしれません。 インタフェースの費用はゼロ以上であるに違いありません。
[Moy] [Page 44] RFC 1247 OSPF Version 2 July 1991
[Moy][44ページ]RFC1247OSPFバージョン1991年7月2日
RxmtInterval
The number of seconds between link state advertisement
retransmissions, for adjacencies belonging to this interface. Also
used when retransmitting Database Description and Link State Request
Packets.
間の秒数がリンクするRxmtIntervalはこのインタフェースに属す隣接番組のために広告「再-トランスミッション」を述べます。 また、Database記述とLink州Request Packetsを再送するとき、使用されます。
Authentication key
This configured data allows the authentication procedure to generate
and/or verify the authentication field in the OSPF header. The
authentication key can be configured on a per-interface basis. For
example, if the authentication type indicates simple password, the
authentication key would be a 64-bit password. This key would be
inserted directly into the OSPF header when originating routing
protocol packets, and there could be a separate password for each
network.
認証の主要なThisは、認証手順がOSPFヘッダーの認証分野について生成する、そして/または、データで確かめることができるのを構成しました。 1インタフェースあたり1個のベースで認証キーを構成できます。 例えば、認証タイプが簡単なパスワードを示すなら、認証キーは64ビットのパスワードでしょう。 ルーティング・プロトコルパケットを溯源するとき、このキーは直接OSPFヘッダーに差し込まれるでしょう、そして、各ネットワークのための別々のパスワードがあるかもしれません。
9.1 Interface states
9.1 インタフェース州
The various states that router interface 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".
ルータインタフェースが達するかもしれない様々な州はこのセクションで記録されます。 機能性を進行することの順に州は記載されています。 例えば、操業していない状態は最終的で、完全に機能的な状態が獲得される前に中間的州のリストがいうことになった記載された1番目です。 仕様は、時々「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.
図11は界面準位変化のグラフを示しています。 グラフのアークは州の変化を引き起こすイベントでラベルされます。 これらのイベントはセクション9.2に記録されます。 界面準位マシンはさらに詳細にセクション9.3で説明されます。
Down
This is the initial interface state. In this state, the lower-level
protocols have indicated that the interface is unusable. No
protocol traffic at all will be sent or received on such a
interface. In this state, interface parameters should be set to
their initial values. All interface timers should be disabled, and
there should be no adjacencies associated with the interface.
下にThisは初期の界面準位です。 この状態では、低レベルプロトコルは、インタフェースが使用不可能であることを示しました。 そのようなインタフェースに全くいいえプロトコルトラフィックを送るか、または受け取るでしょう。 この状態では、インタフェース・パラメータはそれらの初期の値に設定されるべきです。 すべてのインタフェースタイマが損傷されるべきです、そして、インタフェースに関連しているどんな隣接番組もあるべきではありません。
Loopback
In this state, the router's interface to the network is 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
ループバックIn、この状態であり、ネットワークへのルータのインタフェースは輪にし返されます。 インタフェースはハードウェアかソフトウェアで輪にされるかもしれません。 インタフェースは定期的なデータ通信量を入手できなくなるでしょう。 しかしながら、送付ICMPピングを通どちらかだってこのインタフェースの品質でインタフェースに情報を得るか、または誤りテストが何かを通して少し好きであるのがまだ望ましいかもしれません。 この理由、IPのために
[Moy] [Page 45] RFC 1247 OSPF Version 2 July 1991
[Moy][45ページ]RFC1247OSPFバージョン1991年7月2日
packets may still be addressed to an interface in Loopback state.
To facilitate this, such interfaces are advertised in router links
advertisements as single host routes, whose destination is the IP
interface address.[4]
パケットはまだLoopback状態のインタフェースに扱われているかもしれません。 これを容易にするために、目的地がIPインターフェース・アドレスであるただ一つのホストルートとしてルータリンク広告にそのようなインタフェースの広告を出します。[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 Hellos it receives. The router is not allowed to elect
a Backup Designated Router nor Designated Router until it
transitions out of Waiting state. This prevents unnecessary changes
of (Backup) Designated Router.
Inを待つこれが述べるルータがネットワークのためにBackup Designated Routerのアイデンティティを決定しようとしています。 これをするために、ルータはそれが受けるハローズをモニターします。 ルータは、Waiting状態からaをBackup Designated Routerに選出できて、それまでのDesignated Routerは変遷に選出できません。 これはRouterに指定された(バックアップ)の不要な変化を防ぎます。
Point-to-point
In this state, the interface is operational, and connects either to
a physical point-to-point network or to a virtual link. Upon
entering this state, the router attempts to form an adjacency with
the neighboring router. Hellos are sent to the neighbor every
HelloInterval seconds.
ポイントツーポイントIn、この状態、インタフェースは、操作上であり、物理的な二地点間ネットワーク、または、仮想のリンクに接続します。 この状態に入ると、ルータは、隣接しているルータで隣接番組を形成するのを試みます。 あらゆるHelloIntervalが後援する隣人にハローズを送ります。
DR Other
The interface is to a multi-access network on which another router
has been selected to be the Designated Router. In this state, the
router itself has not been selected Backup Designated Router either.
The router forms adjacencies to both the Designated Router and the
Backup Designated Router (if they exist).
DR Other、別のルータがDesignated Routerであることが選択されたマルチアクセスネットワークにはインタフェースがあります。 この状態では、ルータ自体は選択されたBackup Designated Routerではありません。 ルータはDesignated RouterとBackup Designated Routerの両方に隣接番組を形成します(存在しているなら)。
Backup
In this state, the router itself is the Backup Designated Router on
the attached network. It will be promoted to Designated Router when
the present Designated Router fails. The router establishes
adjacencies to all other routers attached to the network. The
Backup Designated Router performs slightly different functions
during the Flooding Procedure, as compared to the Designated Router
(see Section 13.3). See Section 7.4 for more details on the
functions performed by the Backup Designated Router.
Inのバックアップをとってください。この状態、ルータ自体は付属ネットワークのBackup Designated Routerです。 現在のDesignated Routerが失敗すると、それはDesignated Routerに促進されるでしょう。 ルータはネットワークに付けられた他のすべてのルータに隣接番組を確立します。 Backup Designated RouterはFlooding Procedureの間、わずかに異なった機能を実行します、Designated Routerと比べて(セクション13.3を見てください)。 機能に関するその他の詳細のためのセクション7.4がBackup Designated Routerによって実行されるのを見てください。
DR In this state, this router itself is the Designated Router on the
attached network. Adjacencies are established to all other routers
attached to the network. The router must also originate a network
links advertisement for the network node. The advertisement will
contain links to all routers (including the Designated Router
itself) attached to the network. See Section 7.3 for more details
on the functions performed by the Designated Router.
DR In、この状態、このルータ自体は付属ネットワークのDesignated Routerです。 隣接番組はネットワークに付けられた他のすべてのルータに確立されます。 また、ルータはネットワーク・ノードのためにネットワークリンク広告を溯源しなければなりません。 広告はネットワークに付けられたすべてのルータ(Designated Router自身を含んでいる)へのリンクを含むでしょう。 機能に関するその他の詳細のためのセクション7.3がDesignated Routerによって実行されるのを見てください。
[Moy] [Page 46] RFC 1247 OSPF Version 2 July 1991
[Moy][46ページ]RFC1247OSPFバージョン1991年7月2日
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に相談してください。
Interface Up
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).
インタフェースUp Lower-レベルプロトコルは、ネットワーク・インターフェースが操作上であることを示しました。 これはDown状態からインタフェースを変遷に可能にします。 仮想のリンクでは、インタフェースの操作上の指示は実際に最短パス計算の結果(セクション16.7を見る)です。
Wait Timer
The Wait timer has fired, indicating the end of the waiting period
that is required before electing a (Backup) Designated Router.
Waitタイマが首にした待ちTimer、(バックアップ)を選出する前に必要である待ちの期間の終わりを示すと、Routerは指定されました。
Backup seen
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, a Hello Packet may be received from a neighbor claiming to be
itself the Backup Designated Router. Alternatively, a Hello Packet
may be received from a neighbor claiming to be itself the Designated
Router, and indicating that there is no Backup. 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.
バックアップ、ルータがネットワークのためにBackup Designated Routerの存在か非存在を検出したのがわかります。 これは2つの方法の1つで完了しています。 まず最初に、それ自体でBackup Designated Routerであると主張する隣人からHello Packetを受け取るかもしれません。 あるいはまた、それ自体でDesignated Routerであると主張して、Backupが全くないのを示す隣人からHello Packetを受け取るかもしれません。 どちらの場合には、隣人との双方向のコミュニケーションがあるに違いありません、また、すなわち、ルータは隣人のHello Packetに現れなければなりません。 このイベントはWaiting状態の端を示します。
Neighbor Change
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
Neighbor Change event. For an explanation of neighbor states, see
Section 10.1.
隣人Change Thereはインタフェースに関連している双方向の隣人のセットで変化です。 Routerに指定された(バックアップ)は、再計算される必要があります。 以下の隣人変化はNeighbor Changeイベントに通じます。 隣人州の説明に関しては、セクション10.1を見てください。
o Bidirectional communication has been established to a neighbor.
In other words, the state of the neighbor has transitioned to
2-Way or higher.
o 双方向のコミュニケーションは隣人に確立されました。 言い換えれば、隣人の状態は2方法か、より高く移行しました。
o There is no longer bidirectional communication with a neighbor.
In other words, the state of the neighbor has transitioned to
Init or lower.
o もう、隣人との双方向のコミュニケーションがありません。 言い換えれば、隣人の状態はInitか下側に移行しました。
o One of the bidirectional neighbors is newly declaring itself as
either Designated Router or Backup Designated Router. This is
detected through examination of that neighbor's Hello Packets.
o 双方向の隣人のひとりはDesignated RouterかBackup Designated Routerのどちらかとして新たにそれ自体を宣言しています。 これはその隣人のHello Packetsの試験で検出されます。
[Moy] [Page 47] RFC 1247 OSPF Version 2 July 1991
[Moy][47ページ]RFC1247OSPFバージョン1991年7月2日
o One of the bidirectional neighbors is no longer declaring itself
as Designated Router, or is no longer declaring itself as Backup
Designated Router. This is again detected through examination
of that neighbor's Hello Packets.
o 双方向の隣人のひとりは、もうDesignated Routerとしてそれ自体を宣言していないか、またはもうBackup Designated Routerとしてそれ自体を宣言していません。 これは再びその隣人のHello Packetsの試験で検出されます。
o The advertised Router Priority for a bidirectional neighbor has
changed. This is again detected through examination of that
neighbor's Hello Packets.
o 双方向の隣人のための広告を出しているRouter Priorityは変化しました。 これは再びその隣人のHello Packetsの試験で検出されます。
Loop Ind
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.
インタフェースが現在それ自体に輪にして戻されるという輪のインディアン座An指示を受けました。 ネットワークマネージメントか下のレベルプロトコルからこの指示を受けることができます。
Unloop Ind
An indication has been received that the interface is no longer
looped back. As with the Loop Ind event, this indication can be
received either from network management or from the lower level
protocols.
インタフェースがもう輪にし返されないというUnloopインディアン座An指示を受けました。 Loopインディアン座イベントでネットワークマネージメントか下のレベルプロトコルからこの指示を受けることができるように。
Interface Down
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.
インタフェースDown Lower-レベルプロトコルは、このインタフェースがもう機能的でないことを示します。 現在の界面準位が何であっても、新しい界面準位はDownになるでしょう。
9.3 The Interface state machine
9.3 Interface州のマシン
A detailed description of the interface state changes follows. Each state change is invoked by an event (Section 9.2). This event may produce different effects, depending on the current state of the interface. For this reason, the state machine below is organized by current interface state and received event. Each entry in the state machine describes the resulting new interface state and the required set of additional actions.
界面準位変化の詳述は続きます。 イベント(セクション9.2)によってそれぞれの州の変化は呼び出されます。 インタフェースの現状のときによって、このイベントは異なった効果を生むかもしれません。 この理由で、以下の州のマシンは現在の界面準位と容認されたイベントによって組織化されます。 州のマシンの各エントリーは結果として起こる新しい界面準位と必要なセットの追加機能について説明します。
When an interface's state changes, it may be necessary to originate a new router links advertisement. See Section 12.4 for more details.
インタフェースの状態が変化するとき、新しいルータを溯源するのが広告をリンクするのが必要であるかもしれません。 その他の詳細に関してセクション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
州: 下に
[Moy] [Page 48] RFC 1247 OSPF Version 2 July 1991
[Moy][48ページ]RFC1247OSPFバージョン1991年7月2日
Event: Interface Up
イベント: 上に連結してください。
New state: Depends on 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 or virtual
link, the interface state transitions to Point-to-Point.
Else, if the router is not eligible to become Designated
Router the interface state transitions to DR other.
動作: インタフェースからHelloパケットの周期的な発信を可能にして、間隔Hello Timerを始動してください。 付属ネットワークが物理的な二地点間ネットワークか仮想のリンクであるなら、界面準位は指すPointに移行します。 ほかに、ルータがDesignated Routerになるのが適任でないなら、界面準位はDR他に移行します。
Otherwise, the attached network is multi-access 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. If in addition the
attached network is non-broadcast, 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.
さもなければ、付属ネットワークはマルチアクセスです、そして、ルータはDesignated Routerになるのが適任です。 この場合、付属ネットワークのDesignated Routerを発見する試みでは、界面準位はWaitingに設定されます、そして、ただ一つのショットWait Timerは始動されます。 付属ネットワークがさらに、非放送するなら、このインタフェースがないかどうか隣人の構成されたリストを調べてください、そして、それぞれのまた、Designated Routerになるのが適任の隣人のために隣人イベントがStartであると生成してください。
State(s): Waiting
州: 待ち
Event: Backup Seen
イベント: 見られたバックアップ
New state: Depends upon action routine.
新しい州: アクションルーチンによります。
Action: Calculate the attached network's Backup Designated Router
and Designated Router, as shown in Section 9.4. As a result
of this calculation, the new state of the interface will be
either DR other, Backup or DR.
動作: セクション9.4に示されるように付属ネットワークのBackup Designated RouterとDesignated Routerについて計算してください。 この計算の結果、インタフェースの新しい状態がDR他になるので、BackupかDRです。
State(s): Waiting
州: 待ち
Event: Wait Timer
イベント: 待ちタイマ
New state: Depends upon action routine.
新しい州: アクションルーチンによります。
Action: Calculate the attached network's Backup Designated Router
and Designated Router, as shown in Section 9.4. As a result
of this calculation, the new state of the interface will be
either DR other, Backup or DR.
動作: セクション9.4に示されるように付属ネットワークのBackup Designated RouterとDesignated Routerについて計算してください。 この計算の結果、インタフェースの新しい状態がDR他になるので、BackupかDRです。
State(s): DR Other, Backup or DR
州: DRもう一方、バックアップまたはDR
[Moy] [Page 49] RFC 1247 OSPF Version 2 July 1991
[Moy][49ページ]RFC1247OSPFバージョン1991年7月2日
Event: Neighbor Change
イベント: 隣人変化
New state: Depends upon action routine.
新しい州: アクションルーチンによります。
Action: Recalculate the attached network's Backup Designated Router
and Designated Router, as shown in Section 9.4. As a result
of this calculation, the new state of the interface will be
either DR other, Backup or DR.
動作: セクション9.4に示されるように付属ネットワークのBackup Designated RouterとDesignated RouterをRecalculateします。 この計算の結果、インタフェースの新しい状態がDR他になるので、BackupかDRです。
State(s): Any State
州: どんな状態
Event: Interface Down
イベント: インタフェースはダウンします。
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: Loop Ind
イベント: 輪のインディアン座
New state: Loopback
新しい州: ループバック
Action: Since this interface is no longer connected to the attached
network the actions associated with the above Interface Down
event are executed.
動作: このインタフェースがもう付属ネットワークに関連づけられないので、上のInterface Downイベントに関連している動作は実行されます。
State(s): Loopback
州: ループバック
Event: Unloop Ind
イベント: Unloopインディアン座
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 Interface Up event is
necessary before the interface again becomes fully
functional.
動作: どんな動作も必要ではありません。 例えば、インタフェース変数はLoopback状態に入るとき既にリセットされました。 インタフェースが再び完全に機能的になる前にInterface Upイベントのレセプションが必要であることに注意してください。
[Moy] [Page 50] RFC 1247 OSPF Version 2 July 1991
[Moy][50ページ]RFC1247OSPFバージョン1991年7月2日
9.4 Electing the Designated Router
9.4 指定をルータに選出すること。
This section describes the algorithm used for calculating a network's Designated Router and Backup Designated Router. This algorithm is invoked by the Interface state machine. The initial time a router runs the election algorithm for a network, the network's Designated Router and Backup Designated Router are initialized to 0.0.0.0. This indicates the lack of both a Designated Router and a Backup Designated Router.
このセクションはネットワークのDesignated RouterとBackup Designated Routerについて計算するのに使用されるアルゴリズムを説明します。 このアルゴリズムはInterface州のマシンによって呼び出されます。 ネットワークのルータがネットワークのために選挙アルゴリズムを実行する初期の時、Designated Router、およびBackup Designated Routerは0.0に初期化されます。.0 .0。 これはDesignated RouterとBackup Designated Routerの両方の不足を示します。
The Designated Router election algorithm proceeds as follows: Call the router doing the calculation Router X. The list of neighbors attached to the network and having established bidirectional communication with Router X is examined. This list is precisely the collection of Router X's neighbors (on this network) whose state is greater than or equal to 2-Way (see Section 10.1). Router X itself is also considered to be on the list. Discard all routers from the list that are ineligible to become Designated Router. (Routers having Router Priority of 0 are ineligible to become Designated Router.) The following steps are then executed, considering only those routers that remain on the list:
Designated Router選挙アルゴリズムは以下の通り続きます: 計算Router X.をするのにルータに電話をしてください。隣人のリストはネットワークに付きました、そして、Router Xとの双方向のコミュニケーションを確立したのは調べられます。 このリストは正確に状態がこと以上であるRouter Xの隣人(このネットワークの)の収集です。2方法(セクション10.1を見ます)。 また、ルータX自体がリストにあると考えられます。 リストからのすべてのDesignated Routerになるのにおいて不適格なルータを捨ててください。 (0のRouter PriorityがあるルータはDesignated Routerになるのにおいて不適格です。) 次に、リストに残っているそれらのルータだけを考える場合、以下のステップは実行されます:
(1) Note the current values for the network's Designated Router and
Backup Designated Router. This is used later for comparison
purposes.
(1) ネットワークのDesignated RouterとBackup Designated Routerによって現行価値に注意してください。 これは後で比較目的に使用されます。
(2) Calculate the new Backup Designated Router for the network as
follows. Only those routers on the list that have not declared
themselves to be Designated Router are eligible to become Backup
Designated Router. If one or more of these routers have declared
themselves Backup Designated Router (i.e., they are currently
listing themselves as Backup Designated Router, but not as
Designated Router, in their Hello Packets) the one having highest
Router Priority is declared to be Backup Designated Router. In case
of a tie, the one having the highest Router ID is chosen. If no
routers have declared themselves Backup Designated Router, 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) 以下のネットワークのために新しいBackup Designated Routerについて計算してください。 リストの上の自分たちがDesignated Routerであると宣言していないそれらのルータだけがBackup Designated Routerになるのが適任です。 これらのルータのものか以上が、自分たちがBackup Designated Routerであると宣言したなら(現在自分たちについてBackup Designated Routerに記載しますが、Designated Routerとして記載しているというわけではありません、それらのHello Packetsで)、持っている中でRouter Priority最も高いものはBackup Designated Routerであると宣言されます。 繋がりの場合には、持っている中でRouter ID最も高いものは選ばれています。 どんなルータも、自分たちがBackup Designated Routerであると宣言していないなら、持っている中でRouter Priority最も高いルータ、(再び、それらのルータを除きます自分たちがDesignated Routerであると宣言した)と選んでください、そして、もう一度Router IDを使用して、結びつきを壊してください。
(3) Calculate the new Designated Router for the network as follows. If
one or more of the routers have declared themselves Designated
Router (i.e., they are currently listing themselves as Designated
Router in their Hello Packets) the one having highest Router
Priority is declared to be Designated Router. In case of a tie, the
one having the highest Router ID is chosen. If no routers have
declared themselves Designated Router, promote the new Backup
Designated Router to Designated Router.
(3) 以下のネットワークのために新しいDesignated Routerについて計算してください。 ルータのものか以上が、自分たちがDesignated Routerであると宣言したなら(すなわち、彼らは現在、自分達のHello Packetsに自分たちについてDesignated Routerに記載しています)、持っている中でRouter Priority最も高いものはDesignated Routerであると宣言されます。 繋がりの場合には、持っている中でRouter ID最も高いものは選ばれています。 どんなルータも、自分たちがDesignated Routerであると宣言していないなら、新しいBackup Designated RouterをDesignated Routerに促進してください。
[Moy] [Page 51] RFC 1247 OSPF Version 2 July 1991
[Moy][51ページ]RFC1247OSPFバージョン1991年7月2日
(4) If Router X is now newly the Designated Router or newly the Backup
Designated Router, or is now no longer the Designated Router or no
longer the Backup Designated Router, repeat steps 2 and 3, and then
proceed to step 5. For example, if Router X is now the Designated
Router, when step 2 is repeated X will no longer be eligible for
Backup Designated Router election. Among other things, this will
ensure that no router will declare itself both Backup Designated
Router and Designated Router.[5]
(4) Router Xが現在新たにそうである、Designated Router、新たに、Backup Designated Router、現在は、もうDesignated RouterかもうBackup Designated Routerであり、ステップ2と3を繰り返してください、そして、次に、5に踏みかけてください。 ステップ2が繰り返されるとき、例えば、現在Router XがDesignated Routerであるなら、XはもうBackup Designated Router選挙に適任にならないでしょう。 特に、これは、どんなルータも、それ自体がBackup Designated RouterとDesignated Routerの両方であると宣言しないのを確実にするでしょう。[5]
(5) As a result of these calculations, the router itself may now be
Designated Router or Backup Designated Router. See Sections 7.3 and
7.4 for the additional duties this would entail. The router's
interface state should be set accordingly. If the router itself is
now Designated Router, the new interface state is DR. If the router
itself is now Backup Designated Router, the new interface state is
Backup. Otherwise, the new interface state is DR Other.
(5) これらの計算の結果、現在、ルータ自体は、Designated RouterかBackup Designated Routerであるかもしれません。 これが伴う追加関税に関してセクション7.3と7.4を見てください。 ルータの界面準位はそれに従って、設定されるべきです。 現在ルータ自体がDesignated Routerであるなら、新しい界面準位はDRです。現在ルータ自体がBackup Designated Routerであるなら、新しい界面準位はBackupです。 さもなければ、新しい界面準位はDR Otherです。
(6) If the attached network is non-broadcast, and the router itself has
just become either Designated Router or Backup Designated Router, it
must start sending hellos 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) 付属ネットワークが非放送して、ルータ自体がちょうどDesignated RouterかBackup Designated Routerのどちらかになったところであるなら、それは、それらのDesignated Routerになるのが適任でない隣人にhellosを送り始めなければなりません(セクション9.5.1を見てください)。 0のRouter Priorityを持っている各隣人のために隣人イベントStartを呼び出すことによって、これをします。
(7) If the above calculations have caused the identity of either the
Designated Router or Backup Designated Router to change, the set of
adjacencies associated with this interface will need to be modified.
Some adjacencies may need to be formed, and others may need to be
broken. To accomplish this, invoke the event AdjOK? on all
neighbors whose state is at least 2-Way. This will cause their
eligibility for adjacency to be reexamined (see Sections 10.3 and
10.4).
(7) Designated RouterかBackup Designated Routerのどちらかのアイデンティティが上の計算で変化したなら、このインタフェースに関連している隣接番組のセットは、変更される必要があるでしょう。 いくつかの隣接番組が、形成される必要があるかもしれません、そして、他のものは壊れる必要があるかもしれません。 これを達成するには、少なくとも状態が2方法であるすべての隣人の上にイベントAdjOKを呼び出してください。 これは再検討されるべき隣接番組のためにそれらの適任を引き起こすでしょう(セクション10.3と10.4を見てください)。
The reason behind the election algorithm's complexity is the desire for an orderly transition from Backup Designated Router to Designated Router, when the current Designated Router fails. This orderly transition is ensured through the introduction of hysteresis: no new Backup router can be chosen until the old Backup accepts its new Designated Router responsibilities.
選挙アルゴリズムの複雑さの後ろの理由は規則的なBackup Designated RouterからDesignated Routerまでの変遷に関する願望です、現在のDesignated Routerが失敗すると。 この規則的な変遷はヒステリシスの導入で確実にされます: 古いBackupが新しいDesignated Router責任を引き受けるまで、どんな新しいBackupルータも選ぶことができません。
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.
Router XがDesignated Routerになるのがそれ自体で適任でないなら、Backup Designated RouterもDesignated Routerも上の手順で選択されないのは、可能です。 また、Router Xが唯一のDesignated Routerになるのが適任の付属ルータであるなら、Designated Routerとしてそれ自体を選定して、ネットワークのためのBackup Designated Routerが全くないことに注意してください。
[Moy] [Page 52] RFC 1247 OSPF Version 2 July 1991
[Moy][52ページ]RFC1247OSPFバージョン1991年7月2日
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 multi-access networks, hellos are also used to elect the Designated Router and Backup Designated Router, and in that way determine what adjacencies should be formed.
こんにちは、パケットはそうです。それぞれの機能しているルータインタフェースを出しました。 それらはマルチアクセスネットワークで隣人関係.[6]を発見して、維持するのに使用されます、また、hellosは、Designated RouterとBackup Designated Routerを選んで、どんな隣接番組が形成されるべきであるかをそのように決定するのに使用されます。
The format of a 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 broadcasts (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.
Helloパケットの形式はセクションA.3.2で詳細です。 Hello PacketはルータのRouter Priority(Designated Routerを選ぶ際に、使用される)、およびHello放送の間隔(HelloInterval)を含んでいます。 また、Hello Packetは、しばしば隣人からアクティブなままで(RouterDeadInterval)残っているのをどのように聞かなければならないかを示します。 一般的なネットワークに付けられたすべてのルータに、HelloIntervalとRouterDeadIntervalの両方が同じであるに違いありません。 また、Helloパケットは付属ネットワーク(ネットワークMask)のIPアドレスマスクを含んでいます。 無数の二地点間ネットワークの上と、そして、仮想のリンクの上では、この分野は0に設定されるべきです。
The Hello packet's Options field describes the router's optional OSPF capabilities. There are currently two optional capabilities defined (see Sections 4.5 and A.2). The T-bit of the Options field should be set if the router is capable of calculating separate routes for each IP TOS. The E-bit should be set if and only if the attached area is capable of processing AS external advertisements (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). The rest of the Hello Packet's Options field should be set to zero.
HelloパケットのOptions分野はルータの任意のOSPF能力について説明します。 現在、任意の能力が定義した2があります(セクション4.5とA.2を見てください)。 ルータが各IP TOSのために別々のルートを計算できるなら、Options分野のT-ビットは設定されるべきです。 そして、E-ビットが設定されるべきである、付属領域がASの外部の広告を処理できる場合にだけ(すなわち、それはスタッブ領域ではありません)。 E-ビットが不当に設定されると、隣接しているルータは、Hello Packetを受け入れるのを拒否するでしょう(セクション10.5を見てください)。 Hello PacketのOptions分野の残りはゼロに設定されるべきです。
In order to ensure two-way communication between adjacent routers, the Hello packet contains the list of all routers from which hellos 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 in these fields means that one has not yet been selected.
隣接しているルータの双方向通信を確実にするために、Helloパケットはhellosが最近見られたすべてのルータのリストを含んでいます。 また、HelloパケットはDesignated RouterとBackup Designated Routerのためのルータの現在の選択を含んでいます。 これらの分野の0の値は、1つがまだ選択されていないことを意味します。
On broadcast networks and physical point-to-point networks, Hello packets are sent every HelloInterval seconds to the IP multicast address AllSPFRouters. On virtual links, Hello packets are sent as unicasts (addressed directly to the other end of the virtual link) every HelloInterval seconds. On non-broadcast networks, the sending of Hello packets is more complicated. This will be covered in the next section.
HelloパケットによるあらゆるHelloIntervalを送って、秒がIPマルチキャストにAllSPFRoutersを記述するという放送網と物理的な二地点間ネットワークに関する、ことです。 仮想のリンクに、あらゆるHelloIntervalが後援するユニキャスト(直接仮想のリンクのもう一方の端に送る)としてHelloパケットを送ります。 非放送網では、Helloパケットの発信は、より複雑です。 これは次のセクションで覆われているでしょう。
9.5.1 Sending Hello packets on non-broadcast networks
9.5.1 非放送網でパケットをHelloに送ること。
Static configuration information is necessary in order for the Hello Protocol to function on non-broadcast networks (see Section C.5). Every attached router which is eligible to become Designated Router has a
静的な設定情報が、Helloプロトコルが非放送網で機能するのに必要です(セクションC.5を見てください)。 あらゆるDesignated Routerになるのが適任の付属ルータには、aがあります。
[Moy] [Page 53] RFC 1247 OSPF Version 2 July 1991
[Moy][53ページ]RFC1247OSPFバージョン1991年7月2日
configured list of all of its neighbors on the network. Each listed neighbor is labelled with its Designated Router eligibility.
ネットワークの隣人のすべての構成されたリスト。 それぞれの記載された隣人はDesignated Router適任でレッテルを貼られます。
The interface state must be at least Waiting for any hellos to be sent. Hellos are then sent directly (as unicasts) to some subset of a router's neighbors. Sometimes an hello is sent periodically on a timer; at other times it is sent as a response to a received hello. A router's hello- sending behavior varies depending on whether the router itself is eligible to become Designated Router.
界面準位は少なくともどんなhellosも送られるWaitingであるに違いありません。 そして、直接(ユニキャストとして)ルータの隣人の何らかの部分集合にハローズを送ります。 時々、定期的にこんにちはをタイマに送ります。 aへの応答が、こんにちはを受けたので、他の時に、それを送ります。 ルータのもの、こんにちは、-、ルータ自体がDesignated Routerになるのが適任であるかどうかよって、送付の振舞いは異なります。
If the router is eligible to become Designated Router, it must periodically send hellos 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 hellos to all other neighbors. This means that any two eligible routers are always exchanging hellos, which is necessary for the correct operation of the Designated Router election algorithm. To minimize the number of hellos sent, the number of eligible routers on a non-broadcast network should be kept small.
ルータがDesignated Routerになるのが適任であるなら、それは定期的にすべてのまた、適任の隣人にhellosを送らなければなりません。 また、さらに、ルータがそれ自体でDesignated RouterかBackup Designated Routerであるなら、それは他のすべての隣人に周期的なhellosを送らなければなりません。 これは、どんな2つの適任のルータもいつもhellosを交換していることを意味します。(hellosがDesignated Router選挙アルゴリズムの正しい操作に必要です)。 hellosの数を最小にするのは発信して、非放送網の適任のルータの数は小さく保たれるべきです。
If the router is not eligible to become Designated Router, it must periodically send hellos to both the Designated Router and the Backup Designated Router (if they exist). It must also send an hello in reply to an hello received from any eligible neighbor (other than the current Designated Router and Backup Designated Router). This is needed to establish an initial bidirectional relationship with any potential Designated Router.
ルータがDesignated Routerになるのが適任でないなら、それは定期的にDesignated RouterとBackup Designated Routerの両方にhellosを送らなければなりません(存在しているなら)。 また、それはどんな適任の隣人(現在のDesignated RouterとBackup Designated Routerを除いた)からも受け取られたこんにちはに対してこんにちはを送らなければなりません。 これが、どんな潜在的Designated Routerとの初期の双方向の関係も確立するのに必要です。
When sending Hello packets periodically to any neighbor, the interval between hellos is determined by the neighbor's state. If the neighbor is in state Down, hellos are sent every PollInterval seconds. Otherwise, hellos are sent every HelloInterval seconds.
定期的に隣人、いずれへのhellosの間隔をHelloパケットに送るのが隣人の状態のそばで決定しているとき。 州のDownで隣人がそうなら、あらゆるPollIntervalをhellosに送ります。秒。 さもなければ、あらゆるHelloIntervalをhellosに送ります。秒。
10. The Neighbor Data Structure
10. 隣人データ構造
An OSPF router converses with its neighboring routers. Each separate conversation is described by a "neighbor data structure". Each conversation is bound to a particular OSPF router interface, and is identified either by the neighboring router's OSPF router ID or by its Neighbor IP address (see below). Thus if the OSPF router and another router have multiple attached networks in common, multiple conversations ensue, each described by a unique neighbor data structure. Each separate conversation is loosely referred to in the text as being a separate "neighbor".
OSPFルータは隣接しているルータと話します。 それぞれの別々の会話は「隣人データ構造」によって説明されます。 各会話は、特定のOSPFルータインタフェースに縛られて、隣接しているルータのOSPFルータIDかそのNeighbor IPアドレスによって特定されます(以下を見てください)。 したがって、OSPFルータと別のルータが一般的な倍数の会話で複数の付属ネットワークを持っているなら、続いてください、とそれぞれがユニークな隣人データ構造で説明しました。 それぞれの別々の会話はテキストに緩く別々の「隣人」であると呼ばれます。
The neighbor data structure contains all information pertinent to the forming or formed adjacency between the two neighbors. (However,
隣人データ構造は、形成に適切なすべての情報を含んだか、または2人の隣人の間で隣接番組を形成しました。 (しかしながら
[Moy] [Page 54] RFC 1247 OSPF Version 2 July 1991
[Moy][54ページ]RFC1247OSPFバージョン1991年7月2日
remember that not all neighbors become adjacent.) An adjacency can be viewed as a highly developed conversation between two routers.
すべての隣人が隣接するようになるというわけではないのを覚えていてください。) 2つのルータでの高度な会話として隣接番組を見なすことができます。
State
The functional level of the neighbor conversation. This is
described in more detail in Section 10.1.
隣人の会話の機能的なレベルを述べてください。 これはさらに詳細にセクション10.1で説明されます。
Inactivity Timer
A single shot timer whose firing indicates that no Hello Packet has
been seen from this neighbor recently. The length of the timer is
RouterDeadInterval seconds.
不活発Timer Aは発火が、Hello Packetが全く最近この隣人から見られていないのを示すショットタイマを選抜します。 タイマの長さはRouterDeadInterval秒です。
Master/Slave
When the two neighbors are exchanging databases, they form a Master
Slave relationship. The Master sends the first Database Description
Packet, and is the only part that is allowed to retransmit. The
slave can only respond to the master's Database Description Packets.
The master/slave relationship is negotiated in state ExStart.
2人の隣人のマスター/奴隷Whenはデータベースを交換していて、それらはMaster Slave関係を形成します。 Masterは最初のDatabase記述Packetを送って、再送できる唯一の部分です。 奴隷はマスターのDatabase記述Packetsに応じることができるだけです。 マスター/奴隷関係は州のExStartで交渉されます。
Sequence Number
A 32-bit number identifying individual Database Description packets.
When the neighbor state ExStart is entered, the sequence number
should be set to a value not previously seen by the neighboring
router. One possible scheme is to use the machine's time of day
counter. The sequence number is then incremented by the master with
each new Database Description packet sent. The slave's sequence
number indicates the last packet received from the master. Only one
packet is allowed outstanding at a time.
個々のDatabase記述パケットを特定する系列のNumberのA32ビットの番号。 隣人州のExStartが入られるとき、一連番号は以前に隣接しているルータによって見られなかった値に設定されるべきです。 1つの可能な計画はマシンの時刻カウンタを使用することです。 そして、一連番号はそれぞれの新しいDatabase記述パケットを送ってマスターによって増加されます。 奴隷の一連番号は、最後のパケットがマスターから受信されたのを示します。 1つのパケットだけが一度に、傑出していた状態で許容されています。
Neighbor ID
The OSPF Router ID of the neighboring router. The neighbor ID is
learned when Hello packets are received from the neighbor, or is
configured if this is a virtual adjacency (see Section C.4).
隣接しているルータの隣人ID OSPF Router ID。 隣人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.
優先権を近所付き合いさせてください。隣接しているルータのRouter Priority。 付属ネットワークのためにDesignated Routerを選択するとき、隣人のHelloパケットに含まれて、この項目は使用されています。
Neighbor IP address
The IP address of the neighboring router's interface to the attached
network. Used as the Destination IP address when protocol packets
are sent as unicasts along this adjacency. Also used in router
links advertisements 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
隣人IPは隣接しているルータのインタフェースのIPアドレスを付属ネットワークに記述します。 ユニキャストとしてこの隣接番組に沿ってプロトコルパケットを送るとき、Destination IPアドレスとして、使用します。 また、ルータリンクでは、隣接しているルータがDesignated Routerであることが選択されるなら(セクション12.4.1を見てください)、付属ネットワークにLink IDとして広告を使用しました。 隣人からHelloパケットを受け取るとき、隣人IPアドレスは学術的です。 仮想のリンク、隣人IPのために
[Moy] [Page 55] RFC 1247 OSPF Version 2 July 1991
[Moy][55ページ]RFC1247OSPFバージョン1991年7月2日
address is learned during the routing table build process (see
Section 15).
アドレスは経路指定テーブル成型の過程の間、学習されます(セクション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 Hellos to be rejected (i.e.,
neighbor relationships will not even start to form) if there is a
mismatch in certain crucial OSPF capabilities (see Section 10.5).
The optional OSPF capabilities are documented in Section 4.5.
任意のOSPF能力が隣人で支持した隣人Options。 Database Exchangeの過程(セクション10.6を見る)の間、学術的です。 また、隣人の任意のOSPF能力はHelloパケットに記載されています。 ある重要なOSPF能力にミスマッチがあれば(セクション10.5を見てください)、これは、容認されたハローズが拒絶されるのを(すなわち、隣人関係は形成し始めてさえいないでしょう)可能にします。 任意の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 multi-access networks.
隣人の隣人のDesignated RouterのDesignated Routerの考え。 隣人自身であるなら、これはDesignated Routerのローカルな計算で重要です。 マルチアクセスネットワークだけでは、定義されます。
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 multi-access networks.
隣人の隣人のBackup Designated RouterのBackup Designated Routerの考え。 隣人自身であるなら、これはBackup Designated Routerのローカルな計算で重要です。 マルチアクセスネットワークだけでは、定義されます。
The next set of variables are lists of link state advertisements. These lists describe subsets of the area topological database. There can be five distinct types of link state advertisements in an area topological database: router links, network links, and type 3 and 4 summary links (all stored in the area data structure), and AS external links (stored in the global data structure).
変数の次のセットはリンク州の広告のリストです。 これらのリストは領域の位相的なデータベースの部分集合について説明します。 領域の位相的なデータベースには5つの異なったタイプのリンク州の広告があることができます: ルータリンク、ネットワークリンク、およびタイプ3と4概要は(領域データ構造に格納されたすべて)、およびASの外部のリンク(グローバルなデータ構造では、格納される)をリンクします。
Link state retransmission list
The list of link state advertisements 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.
リンク州の「再-トランスミッション」はあふれますが、この隣接番組で承諾されていないリンク州の広告のリストをリストアップします。 それらが承認されるまでの間隔、または隣接番組が破壊されるまで、これらは再送されるでしょう。
Database summary list
The complete list of link state advertisements that make up the area
topological database, at the moment the neighbor goes into Database
Exchange state. This list is sent to the neighbor in Database
Description packets.
データベース概要は領域の位相的なデータベースを作るリンク州の広告に関する全リストをリストアップします、現在、隣人がDatabase Exchange状態に入ります。 Database記述パケットの隣人にこのリストを送ります。
Link state request list
The list of link state advertisements that need to be received from
this neighbor in order to synchronize the two neighbors' topological
databases. This list is created as Database Description packets are
received, and is then sent to the neighbor in Link State Request
リンク州は、2人の隣人の位相的なデータベースを同期させるようにこの隣人から受け取られる必要があるリンク州の広告のリストをリストアップするよう要求します。 このリストは、Database記述パケットが受け取られているので作成されて、Link州Requestの隣人に送って、その時です。
[Moy] [Page 56] RFC 1247 OSPF Version 2 July 1991
[Moy][56ページ]RFC1247OSPFバージョン1991年7月2日
packets. The list is depleted as appropriate Link State Update
packets are received.
パケット。 適切なLink州Updateパケットが受け取られているとき、リストを使い果たします。
10.1 Neighbor states
10.1 隣人州
The state of a neighbor (really, the state of a conversation being held with a neighboring router) is documented in the following sections. The states are listed in order of progressing functionality. For example, the inoperative state is listed first, followed by a list of intermediate states before the final, fully functional state is achieved. The specification makes use of this ordering by sometimes making references such as "those neighbors/adjacencies in state greater than X". Figures 12 and 13 show the graph of neighbor state changes. The arcs of the graphs are labelled with the event causing the state change. The neighbor events are documented in Section 10.2.
隣人(本当に隣接しているルータで保持される会話の状態)の状態は以下のセクションで記録されます。 機能性を進行することの順に州は記載されています。 例えば、操業していない状態は最終的で、完全に機能的な状態が獲得される前に中間的州のリストがいうことになった記載された1番目です。 仕様は、時々「Xより大きい状態のそれらの隣人/隣接番組」などの参照をすることによって、この注文を利用します。 数字12と13は隣人州の変化のグラフを示しています。 グラフのアークは州の変化を引き起こす出来事でラベルされます。 隣人出来事はセクション10.2に記録されます。
The graph in Figure 12 show 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.
州の変化がHelloプロトコルで作用した図12ショーにおけるグラフ。 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 link state advertisements.
図13のグラフは隣接番組の形成を示しています。 2つの隣接しているルータ毎は隣接するようになりません(セクション10.4を見てください)。 隣人が州のExStartにいるとき、隣接番組は形成し始めます。 2つのルータがそれらのマスター/奴隷状態を発見した後に、状態はExchangeに移行します。 ここに、氾濫手順で隣人は使用され始めます、そして、2つの隣接しているルータがそれらのデータベースを同期させ始めます。 この同期が終わっているとき、隣人は州のFullにいます、そして、私たちは2つのルータに完全に隣接していると言います。 ここに、隣接番組はリンク州の広告に記載されます。
For a more detailed description of neighbor state changes, together with the additional actions involved in each change, see Section 10.3.
隣人州の変化の、より詳細な記述に関しては、各変化にかかわる追加動作と共にセクション10.3を見てください。
_____________________________________________________
_____________________________________________________
(Figures not included in text version.)
(テキストバージョンに含まれていなかった数字。)
Figure 12: Neighbor state changes (Hello Protocol)
Figure 13: Neighbor state changes (Database Exchange)
_____________________________________________________
図12: 隣人状態が変化する、(こんにちは、プロトコル) 図13: 隣人州の変化(データベースExchange)_____________________________________________________
[Moy] [Page 57] RFC 1247 OSPF Version 2 July 1991
[Moy][57ページ]RFC1247OSPFバージョン1991年7月2日
Down
This is the initial state of a neighbor conversation. It indicates
that there has been no recent information received from the
neighbor. On non-broadcast networks, Hello packets may still be
sent to "Down" neighbors, although at a reduced frequency (see
Section 9.5.1).
下にThisは隣人の会話の初期状態です。 それは、隣人から受け取られた最近の情報が全くなかったのを示します。 非放送網では、換算周波数で送りますが、まだHelloパケットを“Down"隣人に送るかもしれません(セクション9.5.1を見てください)。
Attempt
This state is only valid for neighbors attached to non-broadcast
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).
非放送網に配属される隣人だけに、試みThis状態は有効です。 それは、隣人から最近の情報を全く受け取っていませんが、隣人に連絡するのをより協定している努力をするべきであるのを示します。 HelloIntervalごとに隣人Helloパケットを送ることによって、これをします(セクション9.5.1を見てください)。
Init
In this state, an Hello packet has recently been seen from the
neighbor. However, bidirectional communication has not yet been
established with the neighbor (i.e., the router itself did not
appear in the neighbor's Hello packet). All neighbors in this state
(or higher) are listed in the Hello packets sent from the associated
interface.
イニットIn、この状態であり、Helloパケットは最近、隣人から見られました。 しかしながら、双方向のコミュニケーションは隣人と共にまだ確立されていません(すなわち、ルータ自体は隣人のHelloパケットに現れませんでした)。 この状態(より高い)のすべての隣人が関連インタフェースから送られたHelloパケットに記載されています。
2-Way
In this state, communication between the two routers is
bidirectional. This has been assured by the operation of the Hello
Protocol. This is the most advanced state short of beginning
adjacency establishment. The (Backup) Designated Router is selected
from the set of neighbors in state 2-Way or greater.
2方法のIn、この状態であり、2つのルータのコミュニケーションは双方向です。 これはHelloプロトコルの操作で保証されました。 これによる大部分が隣接番組設立を始めるのに不足していた状態で状態を進めたということです。 Routerに指定された(バックアップ)は、隣人のセットから2州の方法で選択されているか、または、よりすばらしいです。
ExStart
This is the first step in creating an adjacency between the two
neighboring routers. The goal of this step is to decide which
router is the master, and to decide upon the initial sequence
number. Neighbor conversations in this state or greater are called
adjacencies.
ExStart Thisは2つの隣接しているルータの間で隣接番組を作成することにおいて第一歩です。 このステップの目標は、どのルータがマスターであるかを決めて、初期シーケンス番号について決めることです。 この状態か、よりすばらしいところの隣人の会話は隣接番組と呼ばれます。
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 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 advertisements. All adjacencies in Exchange state or greater
are used by the flooding procedure. In fact, these adjacencies are
fully capable of transmitting and receiving all types of OSPF
routing protocol packets.
Inを交換してください。ルータが隣人への記述パケットをDatabaseに送りながら全体のリンク州のデータベースについて説明しているこの状態。 それぞれのDatabase記述Packetは一連番号を持って、明らかに承認されます。 1Database記述Packetだけがいかなる時も、傑出していた状態で許容されています。 また、この状態では、Link州Request Packetsに隣人の、より最近の広告を求めさせるかもしれません。 Exchange状態か、よりすばらしいところのすべての隣接番組が氾濫手順で使用されます。 事実上、すべてのタイプのOSPFルーティング・プロトコルパケットを送信して、これらの隣接番組は完全に受けることができます。
[Moy] [Page 58] RFC 1247 OSPF Version 2 July 1991
[Moy][58ページ]RFC1247OSPFバージョン1991年7月2日
Loading
In this state, Link State Request packets are sent to the neighbor
asking for the more recent advertisements that have been discovered
(but not yet received) in the Exchange state.
Exchange状態で発見された(しかし、まだ、受信していません)より最近の広告を求める隣人にInを積み込むこれが述べるLink州Requestパケットを送ります。
Full
In this state, the neighboring routers are fully adjacent. These
adjacencies will now appear in router links and network links
advertisements.
Inを洗い張りしてください。この状態、隣接しているルータは完全に隣接しています。 これらの隣接番組は今ルータリンクに現れるでしょう、そして、ネットワークは広告をリンクします。
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のアークのラベルに示されます。 ラベル定義は以下の通りです:
Hello Received
A Hello packet has been received from a neighbor.
こんにちは、Received A。隣人から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 non-broadcast networks.
スタートThisは現在HelloInterval秒ごとにHello Packetsを隣人に送るべきであるという指示です。 この出来事は非放送網に関連している隣人のためだけに発生します。
2-Way Received
Bidirectional communication has been realized between the two
neighboring routers. This is indicated by this router seeing itself
in the other's Hello packet.
2方法のReceived Bidirectionalコミュニケーションは2つの隣接しているルータの間に実現されました。 これはもう片方のHelloパケットでこのルータの見自体で示されます。
NegotiationDone
The Master/Slave relationship has been negotiated, and sequence
numbers have been exchanged. This signals the start of the
sending/receiving of Database Description packets. For more
information on the generation of this event, consult Section 10.8.
Master/奴隷のNegotiationDone関係を交渉しました、そして、一連番号を交換しました。 これはDatabase記述パケットの発信/受信の始まりに合図します。 この出来事の世代の詳しい情報に関しては、セクション10.8に相談してください。
Exchange Done
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.
交換Done Bothルータは首尾よくDatabase記述パケットの完全な系列を伝えました。 各ルータは、今、リンク州のデータベースのどんな部分が時代遅れであるかを知っています。 この出来事の世代の詳しい情報に関しては、セクション10.8に相談してください。
BadLSReq
A Link State Request has been received for a link state
advertisement not contained in the database. This indicates an
error in the synchronization process.
データベースに含まれなかったリンク州の広告のためにBadLSReq A Link州Requestを受け取りました。 これは同期の過程における誤りを示します。
[Moy] [Page 59] RFC 1247 OSPF Version 2 July 1991
[Moy][59ページ]RFC1247OSPFバージョン1991年7月2日
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 Description Process has completed.
ローディングDone Link州Updatesは日付のすべて外のためのデータベースの容認された部分です。 これは記述Processが完成したDatabaseの後に空になるLink州の要求リストによって示されます。
AdjOK?
A decision must be made (again) 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.
以下のイベント原因は、より少ない州に戻るために隣人をよく開発しました。 隣人の会話が多くの州のどれかにあるとき、上の出来事と異なって、これらの出来事は起こるかもしれません。
Seq Number Mismatch
A Database Description packet has been received that either a) has
an unexpected 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.
Seq Number Mismatch A Database記述パケットによる受け取そんなにのどちらかであって、a)には予期していなかった一連番号があるか、b)がInitビットを不意に設定させるか、またはc)にDatabase記述パケットに受け取られた最後のOptions野原と異なっているOptions分野があるということでした。 これらの状態のいずれも、何らかの誤りが隣接番組設立の間発生しているのを示します。
1-Way
An Hello packet has been received from the neighbor, in which this
router is not mentioned. This indicates that communication with the
neighbor is not bidirectional.
隣人から1方法のAn Helloパケットを受け取りました。そこでは、このルータが言及されません。 これは、隣人とのコミュニケーションが双方向でないことを示します。
KillNbr
This is an indication that all communication with the
neighbor is now impossible, forcing the neighbor to revert
to Down state.
KillNbr Thisは隣人とのすべてのコミュニケーションが現在不可能であるという指示です、隣人にDown状態に先祖帰りをさせて。
Inactivity Timer
The inactivity Timer has fired. This means that no Hello packets
have been seen recently from the neighbor. The neighbor reverts to
Down state.
不活発Timer不活発Timerは発火しました。 これは、Helloパケットが全く最近隣人から見られていないことを意味します。 隣人はDown状態に先祖帰りをします。
LLDown
This is an indication from the lower level protocols that the
neighbor is now unreachable. For example, on an X.25 network this
could be indicated by an X.25 clear indication with appropriate
cause and diagnostic fields. This event forces the neighbor into
Down state.
LLDown Thisは下のレベルプロトコルからの隣人が現在手が届かないという指示です。 例えば、X.25ネットワークでは、適切な原因と診断分野でX.25の明確な指示でこれを示すことができるでしょう。 この出来事はDown状態に隣人を力づくで押します。
[Moy] [Page 60] RFC 1247 OSPF Version 2 July 1991
[Moy][60ページ]RFC1247OSPFバージョン1991年7月2日
10.3 The Neighbor state machine
10.3 Neighbor州のマシン
A detailed description of the neighbor state changes follows. Each state change is invoked by an event (Section 10.2). This event may produce different effects, depending on the current state of the neighbor. For this reason, the state machine below is organized by current neighbor state and received event. Each entry in the state machine describes the resulting new neighbor state and the required set of additional actions.
隣人州の変化の詳述は続きます。 出来事(セクション10.2)によってそれぞれの州の変化は呼び出されます。 隣人の現状のときによって、この出来事は異なった効果を生むかもしれません。 この理由で、以下の州のマシンは現在の隣人国と容認された出来事によって組織化されます。 州のマシンの各エントリーは結果として起こる新しい隣人州と必要なセットの追加機能について説明します。
When an neighbor's state changes, it may be necessary to rerun the Designated Router election algorithm. This is determined by whether the interface Neighbor Change 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 links advertisement to be originated (see Section 12.4).
隣人の状態が変化するとき、Designated Router選挙アルゴリズムを再放送するのが必要であるかもしれません。 インタフェースNeighbor Change出来事が発生するかどうかによって(セクション9.2を見てください)これは決定します。 また、Interfaceがそうなら、DR状態(ルータはそれ自体でDesignated Routerである)、州が引き起こすかもしれない隣人における変化では、新しいネットワークは、溯源されるために広告をリンクします(セクション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 to the neighbor (this neighbor is always
associated with a non-broadcast network) and start the
inactivity timer for the neighbor. The timer's later firing
would indicate that communication with the neighbor was not
attained.
動作: こんにちはを隣人に送ってください、そして、(この隣人はいつも非放送網に関連しています)隣人のために不活発タイマを始動してください。 タイマの後の発火は、隣人とのコミュニケーションに達しなかったのを示すでしょう。
State(s): Attempt
州: 試み
Event: Hello Received
出来事: こんにちは、受け取られている。
New state: Init
新しい州: イニット
Action: Restart the inactivity timer for the neighbor, since the
neighbor has now been heard from.
動作: 今隣人から聞かれたので、隣人のために不活発タイマを再開してください。
State(s): Down
州: 下に
[Moy] [Page 61] RFC 1247 OSPF Version 2 July 1991
[Moy][61ページ]RFC1247OSPFバージョン1991年7月2日
Event: Hello Received
出来事: こんにちは、受け取られている。
New state: 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
州: イニットか、よりすばらしいです。
Event: Hello Received
出来事: こんにちは、受け取られている。
New state: No state change.
新しい州: 州の変化がありません。
Action: Restart the inactivity timer for the neighbor, since the
neighbor has again been heard from.
動作: 再び隣人から聞かれたので、隣人のために不活発タイマを再開してください。
State(s): Init
州: イニット
Event: 2-Way Received
出来事: 2ウェイは受信されました。
New state: Depends upon action routine.
新しい州: アクションルーチンによります。
Action: Determine whether an adjacency should be established with
the neighbor (see Section 10.4). If not, the new neighbor
state is 2-Way.
動作: 隣接番組が隣人と共に確立されるべきであるかどうか(セクション10.4を見てください)決定してください。 まして、新しい隣人状態は2方法です。
Otherwise (an adjacency should be established) the neighbor
state transitions to ExStart. Upon entering this state, the
router increments the sequence number for this neighbor. If
this is the first time that an adjacency has been attempted,
the 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への変遷を述べます。 この状態に入ると、ルータはこの隣人のために一連番号を増加します。 これが隣接番組を試みてある1回目であるなら、何らかのユニークな値(時刻時計のような)が一連番号に割り当てられるべきです。 次に、マスター(マスター/奴隷ビットをマスターに設定する)であるとそれ自体で宣言して、Database記述Packetsを送り始める、(I)、より多くの(M)、およびビットが設定するマスター(MS)を初期化してください。 そうでなければ、このDatabase記述Packetは空であるべきです。 次の状態が入られるまで(セクション10.8を見てください)、このDatabase記述PacketはRxmtIntervalごとに再送されるべきです。
State(s): ExStart
州: ExStart
Event: NegDone
出来事: NegDone
[Moy] [Page 62] RFC 1247 OSPF Version 2 July 1991
[Moy][62ページ]RFC1247OSPFバージョン1991年7月2日
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 links,
network links and summary links contained in the area
structure, along with the AS external links contained in the
global structure. AS external link advertisements are
omitted from a virtual neighbor's Database summary list. AS
external advertisements are omitted from the Database
summary list if the area has been configured as a stub (see
Section 3.6). Advertisements 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 sequence
number, and is explicitly acknowledged. Only one Database
Description Packet is allowed outstanding at any one time.
For more detail on the sending and receiving of Database
Description packets, see Sections 10.8 and 10.6.
動作: ルータは隣人Database概要リストの全体の領域リンク州のデータベースのコンテンツを記載しなければなりません。 領域リンク州のデータベースは領域構造に含まれたルータリンク、ネットワークリンク、および概要リンクから成ります、グローバル構造に含まれたASの外部のリンクと共に。 ASの外部のリンク広告は仮想の隣人のDatabase概要リストから省略されます。 領域がスタッブとして構成されたなら(セクション3.6を見てください)、ASの外部の広告はDatabase概要リストから省略されます。 年令がMaxAgeと等しい広告は代わりに隣人のLink州の「再-トランスミッション」リストに追加されます。 Database概要リストの概要をDatabase記述パケットの隣人に送るでしょう。 それぞれのDatabase記述Packetは一連番号を持って、明らかに承認されます。 1Database記述Packetだけがいかなる時も、傑出していた状態で許容されています。 Database記述パケットの送受信に関するその他の詳細に関しては、セクション10.8と10.6を見てください。
State(s): Exchange
州: 交換
Event: Exchange Done
出来事: 行われた交換
New state: Depends upon action routine.
新しい州: アクションルーチンによります。
Action: If the neighbor Link state request list is empty, the new
neighbor state is Full. No other action is required. This
is an adjacency's final state.
動作: 隣人Link州の要求リストが空であるなら、新しい隣人状態はFullです。 他の動作は全く必要ではありません。 これは隣接番組の最終的な状態です。
Otherwise, the new neighbor state is Loading. Start (or
continue) sending Link State Request packets to the neighbor
(see Section 10.9). These are requests for the neighbor's
more recent advertisements (which were discovered but not
yet received in the Exchange state). These advertisements
are listed in the Link state request list associated with
the neighbor.
さもなければ、新しい隣人状態はLoadingです。 隣人への州RequestパケットをLinkに送り始めてください(続いてください)(セクション10.9を見てください)。 隣人の、より最近の広告を求めてこれらは要求(どれが発見されましたが、まだ発見されたというわけではないかはExchange状態で受信された)です。 これらの広告は隣人に関連しているLink州の要求リストに記載されています。
State(s): Loading
州: ローディング
Event: Loading Done
出来事: 行われたローディング
New state: Full
新しい州: 完全
[Moy] [Page 63] RFC 1247 OSPF Version 2 July 1991
[Moy][63ページ]RFC1247OSPFバージョン1991年7月2日
Action: No action required. This is an adjacency's final state.
動作: どんな動作も必要ではありません。 これは隣接番組の最終的な状態です。
State(s): 2-Way
州: 2ウェイ
Event: AdjOK?
出来事: AdjOK?
New state: Depends upon action routine.
新しい州: アクションルーチンによります。
Action: Determine whether an adjacency should be formed with the
neighboring router (see Section 10.4). If not, the neighbor
state remains at 2-Way. Otherwise, transition the neighbor
state to ExStart and perform the actions associated with the
above state machine entry for state Init and event 2-Way
Received.
動作: 隣接番組が隣接しているルータで形成されるべきであるかどうか(セクション10.4を見てください)決定してください。 そうでなければ、隣人州は2方法に残ります。 さもなければ、隣人がExStartに述べて、上の州のマシンエントリーに関連している動作を実行する変遷はInitと出来事の2方法のReceivedを述べます。
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 link state
advertisements.
さもなければ、(ことによると部分的に形成されています)の隣接番組を破壊しなければなりません。 隣人は2方法への変遷を述べます。 Link州の「再-トランスミッション」リスト、Database概要リスト、およびLink州の要求リストはリンク州の広告をクリアされます。
State(s): Exchange or greater
州: 交換か、よりすばらしいです。
Event: Seq Number Mismatch
出来事: Seq数のミスマッチ
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 link state advertisements. Then
the router increments the sequence number for this neighbor,
declares itself master (sets the master/slave bit to
master), and starts sending Database Description Packets,
動作: (ことによると部分的に形成されています)の隣接番組を取りこわします、そして、次に、再建で試みをします。 隣人は前縁をExStartに述べます。 Link州の「再-トランスミッション」リスト、Database概要リスト、およびLink州の要求リストはリンク州の広告をクリアされます。 次に、ルータは、この隣人のために一連番号を増加して、それ自体がマスター(マスター/奴隷ビットをマスターに設定する)であると宣言して、Database記述Packetsを送り始めます。
[Moy] [Page 64] RFC 1247 OSPF Version 2 July 1991
[Moy][64ページ]RFC1247OSPFバージョン1991年7月2日
with the initialize (I), more (M) and master (MS) bits set.
This Database Description Packet should be otherwise empty
(see Section 10.8).
(I)、より多くの(M)、およびビットが設定するマスター(MS)を初期化してください。 そうでなければ、このDatabase記述Packetは空であるべきです(セクション10.8を見てください)。
State(s): Exchange or greater
州: 交換か、よりすばらしいです。
Event: BadLSReq
出来事: BadLSReq
New state: ExStart
新しい州: ExStart
Action: The action for event BadLSReq is exactly the same as for the
neighbor event SeqNumberMismatch. The (possibly partially
formed) adjacency is torn down, and then an attempt is made
at reestablishment. For more information, see the neighbor
state machine entry that is invoked when event
SeqNumberMismatch is generated in state Exchange or greater.
動作: イベントBadLSReqのための動きはまさに隣人イベントSeqNumberMismatchのように同じです。 (ことによると部分的に形成されています)の隣接番組を取りこわします、そして、次に、再建で試みをします。 詳しくは、イベントSeqNumberMismatchが州のExchangeで発生しているか、または、よりすばらしいときに呼び出される隣人州のマシンエントリーを見てください。
State(s): Any state
州: どんな状態
Event: KillNbr
出来事: KillNbr
New state: Down
新しい州: 下に
Action: The Link state retransmission list, Database summary list
and Link state request list are cleared of link state
advertisements. Also, the inactivity timer is disabled.
動作: Link州の「再-トランスミッション」リスト、Database概要リスト、およびLink州の要求リストはリンク州の広告をクリアされます。 また、不活発タイマも障害があります。
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 link state
advertisements. Also, the inactivity timer is disabled.
動作: Link州の「再-トランスミッション」リスト、Database概要リスト、およびLink州の要求リストはリンク州の広告をクリアされます。 また、不活発タイマも障害があります。
State(s): Any state
州: どんな状態
Event: Inactivity Timer
出来事: 不活発タイマ
New state: Down
新しい州: 下に
[Moy] [Page 65] RFC 1247 OSPF Version 2 July 1991
[Moy][65ページ]RFC1247OSPFバージョン1991年7月2日
Action: The Link state retransmission list, Database summary list
and Link state request list are cleared of link state
advertisements.
動作: Link州の「再-トランスミッション」リスト、Database概要リスト、およびLink州の要求リストはリンク州の広告をクリアされます。
State(s): 2-Way or greater
州: 2方法か、よりすばらしいです。
Event: 1-Way Received
出来事: 1ウェイは受信されました。
New state: Init
新しい州: イニット
Action: The Link state retransmission list, Database summary list
and Link state request list are cleared of link state
advertisements.
動作: Link州の「再-トランスミッション」リスト、Database概要リスト、およびLink州の要求リストはリンク州の広告をクリアされます。
State(s): 2-Way or greater
州: 2方法か、よりすばらしいです。
Event: 2-Way received
出来事: 2方法が受信されました。
New state: No state change.
新しい州: 州の変化がありません。
Action: No action required.
動作: どんな動作も必要ではありません。
State(s): Init
州: イニット
Event: 1-Way received
出来事: 1方法が受信されました。
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 and virtual links always become adjacent. On multi-access networks, all routers become adjacent to both the Designated Router and the Backup Designated Router.
隣接番組はルータの隣人の何らかの部分集合で確立されます。 二地点間ネットワークと仮想のリンクによって接続されたルータはいつも隣接するようになります。 マルチアクセスネットワークでは、すべてのルータがDesignated RouterとBackup Designated Routerの両方に隣接してなります。
The adjacency-forming decision occurs in two places in the neighbor state machine. First, when bidirectional communication is initially established with the neighbor, and secondly, when the identity of the attached network's (Backup) Designated Router changes. If the decision is made to not attempt an adjacency, the state of the neighbor communication stops at 2-Way.
隣接番組を形成する決定は隣人州のマシンの2つの場所で起こります。 双方向のコミュニケーションであることの1番目は初めは隣人と共に設立されます、そして、第二に、付属ネットワークの(バックアップ)のアイデンティティがいつRouterを指定したかは変化します。 隣接番組を試みないのを決定をするなら、隣人コミュニケーションの状態は2方法で止まります。
[Moy] [Page 66] RFC 1247 OSPF Version 2 July 1991
[Moy][66ページ]RFC1247OSPFバージョン1991年7月2日
An adjacency should be established with a (bidirectional) neighbor when at least one of the following conditions holds:
少なくとも以下の条件の1つが持ちこたえるとき、隣接番組は(双方向)の隣人と共に確立されるべきです:
o The underlying network type is point-to-point
o 基本的なネットワークタイプは二地点間です。
o The underlying network type is virtual link
o 基本的なネットワークタイプは仮想のリンクです。
o The router itself is the Designated Router
o ルータ自体はDesignated Routerです。
o The router itself is the Backup Designated Router
o ルータ自体はBackup Designated Routerです。
o The neighboring router is the Designated Router
o 隣接しているルータはDesignated Routerです。
o The neighboring router is the Backup Designated Router
o 隣接しているルータはBackup Designated Routerです。
10.5 Receiving Hello packets
10.5 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, HelloInt, and DeadInt 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. Note that the value of the Network Mask field should not be checked in Hellos received on unnumbered serial lines or on virtual links.
このセクションは容認されたHelloパケットの詳細な処理について説明します。 (Helloパケットの形式に関してセクションA.3.2を見てください。) OSPFパケットの一般的な入力処理はIPヘッダーとOSPFパケットのヘッダーの正当性をチェックしてしまうでしょう。 次に、受信インタフェースに構成された値に対して容認されたHelloパケットのNetwork Mask、HelloInt、およびDeadInt分野の値をチェックしなければなりません。 どんなミスマッチも止める処理とパケットを落とされます。 言い換えれば、上の分野は本当に付属ネットワークの構成について説明しています。 Network Mask分野の値が無数のシリアル・ラインの上、または、仮想のリンクの上に受け取られたハローズでチェックされるべきでないことに注意してください。
The receiving interface attaches to a single OSPF area (this could be the backbone). The setting of the E-bit found in the Hello Packet's option field must match this area's external routing capability. If AS external advertisements are not flooded into/throughout the area (i.e, the area is a "stub") the E-bit must be clear in received hellos, 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 option field should be ignored.
受信インタフェースはただ一つのOSPF領域に付きます(これは背骨であるかもしれません)。 Hello Packetのオプション・フィールドで見つけられたE-ビットの設定はこの領域の外部のルーティング能力に合わなければなりません。 ASの外部の広告が領域中に/へあふれないなら(i.e、領域は「スタッブ」です)E-ビットが容認されたhellosで明確であるに違いない、さもなければ、E-ビットを設定しなければなりません。 ミスマッチは止める処理とパケットを落とされます。 Hello Packetのオプション・フィールドのビットの残りの設定は無視されるべきです。
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 is a multi-access network (either broadcast or non-broadcast) the source is identified by the IP source address found in the Hello's IP header. If the receiving interface is 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
ここに、受信インタフェースの隣人のひとりにHello Packetの源を合わせるのを試みをします。 受信インタフェースがマルチアクセスネットワーク(放送されたか、非放送している)であるなら、ソースはHelloのIPヘッダーで見つけられたIPソースアドレスによって特定されます。 受信インタフェースがポイントツーポイント接続か仮想のリンクであるなら、ソースはHelloのOSPFパケットのヘッダーで見つけられたRouter IDによって特定されます。 インタフェースの隣人の現在のリストはインタフェースのデータ構造に含まれています。 合っている隣人です。
[Moy] [Page 67] RFC 1247 OSPF Version 2 July 1991
[Moy][67ページ]RFC1247OSPFバージョン1991年7月2日
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.
構造を見つけることができない、(すなわち、これが隣人が検出されたのは、初めてです)、1つは作成されます。 新たに作成された隣人の初期状態はDownに設定されます。
When receiving an Hello Packet from a neighbor on a multi-access network (broadcast or non-broadcast), set the neighbor structure's Neighbor ID equal to the Router ID found in the packet's OSPF header. When receiving an Hello on a point-to-point network (but not on a virtual link) set the neighbor structure's Neighbor IP address to the packet's IP source address.
マルチアクセスネットワーク(放送か非放送)で隣人からHello Packetを受けるときには、隣人構造のパケットのOSPFヘッダーで見つけられたRouter IDと等しいNeighbor IDを設定してください。 二地点間ネットワーク(しかし、どんな仮想のリンクの上にもそうしない)でHelloを受けるときには、隣人構造のNeighbor IPアドレスをパケットのIPソースアドレスに設定してください。
Now the rest of the Hello Packet is examined, generating events to be given to the neighbor and interface state machines. These state machines are specified either to be executed or scheduled (see Section 4.4). For example, by specifying below that the neighbor state machine be executed in line, several neighbor state transitions may be effected by a single received Hello:
現在、Hello Packetの残りは調べられます、隣人と界面準位マシンに与えられている出来事を発生させて。 これらの州のマシンは、実行されるか、または予定されるために指定されます(セクション4.4を見てください)。 例えば、以下で隣人州のマシンが並んで実行されると指定することによって、いくつかの隣人状態遷移が独身の容認されたHelloが作用されるかもしれません:
o Each Hello Packet causes the neighbor state machine to be executed
with the event Hello Received.
o 各Hello PacketはイベントHello Receivedと共に隣人州のマシンを実行させます。
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-Way Received.
Otherwise, the neighbor state machine should be executed with the
event 1-Way Received, and the processing of the packet stops.
o そして、Hello Packetに含まれた隣人のリストは調べられます。 ルータ自体がこのリストに現れるなら、隣人州のマシンはイベントの2方法のReceivedと共に実行されるべきです。 さもなければ、隣人州のマシンはイベントの1方法のReceivedと共に実行されるべきです、そして、パケットの処理は止まります。
o Next, the Hello packet's Router Priority field is examined. If this
field is different than the one previously received from the
neighbor, the receiving interface's state machine is scheduled with
the event NeighborChange. In any case, the Router Priority field in
the neighbor data structure should be set accordingly.
o 次に、HelloパケットのRouter Priority分野は調べられます。 この分野がものが以前に隣人から受信されたより異なるなら、受信インタフェースの州のマシンはイベントNeighborChangeと共に予定されています。 どのような場合でも、隣人データ構造におけるRouter Priority分野はそれに従って、設定されるべきです。
o Next the Designated Router field in the Hello Packet is examined.
If the neighbor is both declaring itself to be Designated Router
(Designated Router field = neighbor IP address) and the Backup
Designated Router field in the packet is equal to 0.0.0.0 and the
receiving interface is in state Waiting, the receiving interface's
state machine is scheduled with the event BackupSeen. Otherwise, if
the neighbor is declaring itself to be Designated Router and it had
not previously, or the neighbor is not declaring itself Designated
Router where it had previously, the receiving interface's state
machine is scheduled with the event NeighborChange. In any case,
the Designated Router item in the neighbor structure is set
accordingly.
o 次に、Hello PacketのDesignated Router分野は調べられます。 隣人が、それ自体がDesignated Router(隣人IPアドレスにRouter分野=を指定する)であるとともに宣言していて、パケットのBackup Designated Router分野が0.0と等しいなら、.0と受信インタフェースがある.0はWaitingを述べて、受信インタフェースの州のマシンはイベントBackupSeenと共に予定されています。 さもなければ、以前に、そうしていなかったか、隣人が、それ自体がDesignated Routerであると宣言していて、または隣人が、それ自体がそれが以前にそうしたDesignated Routerであると宣言していないなら、受信インタフェースの州のマシンはイベントNeighborChangeと共に予定されています。 どのような場合でも、隣人構造のDesignated Routerの品目はそれに従って、設定されます。
[Moy] [Page 68] RFC 1247 OSPF Version 2 July 1991
[Moy][68ページ]RFC1247OSPFバージョン1991年7月2日
o Finally, the Backup Designated Router field in the Hello Packet is
examined. If the neighbor is declaring itself to be Backup
Designated Router (Backup Designated Router field = neighbor IP
address) and the receiving interface is in state Waiting, the
receiving interface's state machine is scheduled with the event
BackupSeen. Otherwise, if the neighbor is declaring itself to be
Backup Designated Router and it had not previously, or the neighbor
is not declaring itself Backup Designated Router where it had
previously, the receiving interface's state machine is scheduled
with the event NeighborChange. In any case, the Backup Designated
Router item in the neighbor structure is set accordingly.
o 最終的に、Hello PacketのBackup Designated Router分野は調べられます。 隣人が、それ自体がBackup Designated Routerであると宣言していて(Designated Router分野=隣人IPアドレスのバックアップをとってください)、受信インタフェースが州のWaitingにあるなら、受信インタフェースの州のマシンはイベントBackupSeenと共に予定されています。 さもなければ、以前に、そうしていなかったか、隣人が、それ自体がBackup Designated Routerであると宣言していて、または隣人が、それ自体がそれが以前にそうしたBackup Designated Routerであると宣言していないなら、受信インタフェースの州のマシンはイベントNeighborChangeと共に予定されています。 どのような場合でも、隣人構造のBackup Designated Routerの品目はそれに従って、設定されます。
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). The further processing of the Database Description Packet depends on the neighbor state. If the neighbor's state is Down or Attempt the packet should be ignored. Otherwise, if the state is:
このセクションは容認されたDatabase記述パケットの詳細な処理について説明します。 入って来るDatabase記述Packetは既に隣人に関連していて一般的な入力パケット処理でインタフェースを受けました(セクション8.2)。 Database記述Packetのさらなる処理は隣人状態に依存します。 隣人の状態がDownかAttemptであるなら、パケットは無視されるべきです。 状態が別の方法でそうなら:
Init
The neighbor state machine should be executed with the event 2-Way
Received. This causes an immediate state change to either state 2-
Way or state Exstart. The processing of the current packet should
then continue in this new state.
隣人州が機械加工するイニットはイベントの2方法のReceivedと共に実行されるべきです。 これで、即座の州の変化は2道か州のExstartを述べます。 そして、現在のパケットの処理はこの新しい状態で続くべきです。
2-Way
The packet should be ignored. Database description packets are used
only for the purpose of bringing up adjacencies.[7]
パケットが無視されるべき2方法。 データベース記述パケットは隣接番組を持って来る目的にだけ使用されます。[7]
ExStart
If the received packet matches one of the following cases, then the
neighbor state machine should be executed with the event
NegotiationDone (causing the state to transition to Exchange), the
packet's Options field should be recorded in the neighbor
structure's Neighbor Options field and the packet should be accepted
as next in sequence and processed further (see below). Otherwise,
the packet should be ignored.
次に、以下のケースのパケットマッチ1、隣人州のマシンがそうするべきである受け取られていることのExStart IfがイベントNegotiationDone(Exchangeへの変遷に状態を引き起こす)と共に実行されて、パケットのOptions分野が隣人構造のNeighbor Options分野に記録されるべきであり、パケットは、次として連続して認められて、さらに処理されるべきです(以下を見てください)。 さもなければ、パケットは無視されるべきです。
o The initialize(I), more (M) and master(MS) bits are set, the
contents of the packet are empty, and the neighbor's Router ID
is larger than the router's own. In this case the router is now
Slave. Set the master/slave bit to slave, and set the sequence
number to that specified by the master.
o (I)を初期化してください、より多くの(M)とマスター(MS)ビットが設定されて、パケットの内容が空であり、隣人のRouter IDはルータが自己であるより大きいです。 この場合、現在、ルータはSlaveです。 マスター/奴隷ビットに身を粉にして働くように設定してください、そして、マスターによって指定されたそれに一連番号を設定してください。
[Moy] [Page 69] RFC 1247 OSPF Version 2 July 1991
[Moy][69ページ]RFC1247OSPFバージョン1991年7月2日
o The initialize(I) and master(MS) bits are off, the packet's
sequence number equals the router's own 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)を初期化してください、パケットの一連番号がルータの自己の一連番号と等しく(承認を示して)、隣人のRouter IDはルータが自己であるより小さいです。 この場合、ルータはMasterです。
Exchange
If the state of the MS-bit is inconsistent with the master/slave
state of the connection, generate the neighbor event Seq Number
Mismatch and stop processing the packet. Otherwise:
Ifを交換してください。MS-ビットの状態は接続のマスター/奴隷制度の州に反しています、そして、隣人イベントSeq Number Mismatchを発生させてください、そして、パケットを処理するのを止めてください。 そうでなければ:
o If the initialize(I) bit is set, generate the neighbor event Seq
Number Mismatch and stop processing the packet.
o (I)を初期化してください。ビットはセットして、隣人イベントSeq Number Mismatchを発生させて、パケットを処理するのを止めることです。
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 Seq Number
Mismatch and stop processing the packet.
o パケットのOptions分野が以前に隣人(隣人構造のNeighbor Options分野に記録される)から受け取ったより任意の異なったOSPF能力を示すなら、隣人イベントSeq Number Mismatchを発生させてください、そして、パケットを処理するのを止めてください。
o If the router is master, and the packet's sequence number equals
the router's own sequence number (this packet is the next in
sequence) the packet should be accepted and its contents
processed (below).
o ルータがマスター、およびパケットのルータの自己の一連番号の一連番号同輩(このパケットは連続して次です)であるなら、パケットを受け入れるべきでした、そして、コンテンツは(below)を処理しました。
o If the router is master, and the packet's sequence number is one
less than the router's sequence number, the packet is a
duplicate. Duplicates should be discarded by the master.
o ルータがマスターであり、パケットの一連番号がルータの一連番号よりそれほど1であるなら、パケットは写しです。 写しはマスターによって捨てられるべきです。
o If the router is slave, and the packet's sequence number is one
more than the router's own sequence number (this packet is the
next in sequence) the packet should be accepted and its contents
processed (below).
o ルータが奴隷であり、パケットがそうするべきであるルータの自己の一連番号(このパケットは連続して次である)よりパケットの一連番号を1つ受け入れて、コンテンツが(below)を処理したなら。
o If the router is slave, and the packet's sequence number is
equal to the router's sequence number, the packet is a
duplicate. The slave must respond to duplicates by repeating
the last Database Description packet that it sent.
o ルータが奴隷であり、パケットの一連番号がルータの一連番号と等しいなら、パケットは写しです。 奴隷は、それが発信したと最後のDatabase記述パケットを繰り返すのによる写しに応答しなければなりません。
o Else, generate the neighbor event Seq Number Mismatch and stop
processing the packet.
o ほかに、隣人イベントSeq Number Mismatchを発生させてください、そして、パケットを処理するのを止めてください。
Loading or Full
In this state, the router has sent and received an entire sequence
of Database Descriptions. 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
ローディングかFull In、この状態であり、ルータは、Database記述の全体の系列を送って、受け取りました。 受け取られた唯一のパケットが写しであるべきです(上を見てください)。 分野が合うべきであるパケットのOptionsが隣人による任意のOSPF能力のセットが、以前に示した特に、(だった隣人に構造のものを格納する
[Moy] [Page 70] RFC 1247 OSPF Version 2 July 1991
[Moy][70ページ]RFC1247OSPFバージョン1991年7月2日
neighbor Options field). Any other packets received, including the
reception of a packet with the Initialize(I) bit set, should
generate the neighbor event Seq Number Mismatch.[8] Duplicates
should be discarded by the master. The slave must respond to
duplicates by repeating the last Database Description packet that it
sent.
隣人Options分野) Initialize(I)ビットがセットしたことでのパケットのレセプションを含んでいて、受け取られたいかなる他のパケットも隣人イベントSeq Number Mismatch.[8]を発生させるはずです。写しはマスターによって捨てられるべきです。 奴隷は、それが発信したと最後のDatabase記述パケットを繰り返すのによる写しに応答しなければなりません。
When the router accepts a received Database Description Packet as the next in sequence the packet contents are processed as follows. For each link state advertisement listed, the advertisement'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 a AS external advertisement (LS type = 5) and the neighbor is associated with a stub area, generate the neighbor event Seq Number Mismatch and stop processing the packet. Otherwise, the router looks up the advertisement in its database to see whether it also has an instance of the link state advertisement. If it does not, or if the database copy is less recent (see Section 13.1), the link state advertisement is put on the Link state request list so that it can be requested (immediately or at some later time) in Link State Request Packets.
ルータが次として容認されたDatabase記述Packetを認めるとき、連続してパケット含有量は以下の通り処理されます。 広告が記載したそれぞれのリンク状態において、広告のLSタイプは正当性がないかどうかチェックされます。 LSタイプが未知である(例えば、LSのどんなひとりもこの仕様で定義された1-5をタイプしません)、これがASの外部の広告(LSは=5をタイプする)であり、または隣人がスタッブ領域に関連しているなら、隣人イベントSeq Number Mismatchを発生させてください、そして、パケットを処理するのを止めてください。 さもなければ、ルータは、また、それにはリンク州の広告の例があるかどうか確認するためにデータベースにおける広告を見上げます。 そうしないか、またはデータベースコピーがそれほど最近でないなら(セクション13.1を見てください)、リンク州の広告は、Link州Request Packetsでそれを要求できる(すぐにか何らかの後の時間に)ようにLink州の要求リストに載せられます。
When the router accepts a received Database Description Packet as the next in sequence, it also performs the following actions, depending on whether it is master or slave:
また、ルータが次として連続して容認されたDatabase記述Packetを認めるとき、以下の動作を実行します、それがマスターかそれとも奴隷であるかに頼っていて:
Master
Increments the sequence number. If the router has already sent its
entire sequence of Database Descriptions, and the just accepted
packet has the more bit (M) set to 0, the neighbor event Exchange
Done is generated. Otherwise, it should send a new Database
Description to the slave.
Incrementsを習得してください。一連番号。 ルータが既にDatabase記述の全体の系列を送って、ただ受け入れられたパケットで、より多くのビット(M)を0に設定するなら、隣人イベントExchange Doneは発生します。 さもなければ、それは新しいDatabase記述を奴隷に送るべきです。
Slave
Sets the sequence number to the sequence number appearing in the
received packet. The slave must send a Database Description in
reply. If the received packet has the more bit (M) set to 0, and
the packet to be sent by the slave will have the M-bit set to 0
also, the neighbor event Exchange Done is generated. Note that the
slave always generates this event before the master.
奴隷Sets、容認されたパケットに現れる一連番号への一連番号。 奴隷は回答におけるDatabase記述を送らなければなりません。 容認されたパケットで、より多くのビット(M)を0に設定して、奴隷によって送られるパケットでM-ビットを0にも設定するなら、隣人イベントExchange Doneは発生します。 奴隷がマスターの前でこの出来事をいつも発生させることに注意してください。
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 link state advertisements that the neighbor wishes to receive. Link
このセクションは容認されたLink州Requestパケットの詳細な処理について説明します。 容認されたLink州Request Packetsは隣人が受け取りたがっているリンク州の広告のリストを指定します。 リンク
[Moy] [Page 71] RFC 1247 OSPF Version 2 July 1991
[Moy][71ページ]RFC1247OSPFバージョン1991年7月2日
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.
隣人が州のExchange、Loading、またはFullにいるとき、州のRequest Packetsを受け入れるべきです。 全部で、他の州のLink州Request Packetsは無視されるべきです。
Each link state advertisement 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 link state advertisements should NOT be placed on the Link state retransmission list for the neighbor. If a link state advertisement cannot be found in the database, something has gone wrong with the synchronization procedure, and neighbor event BadLSReq should be generated.
Link州Requestパケットで指定されたそれぞれのリンク州の広告は、ルータのデータベースに位置していて、隣人への伝送のためLink州Updateパケットにコピーされるべきです。 隣人のためにこれらのリンク州の広告をLink州の「再-トランスミッション」リストに置くべきではありません。 データベースでリンク州の広告を見つけることができないなら、何かが同期手順で支障をきたしました、そして、隣人イベントBadLSReqは発生するべきです。
10.8 Sending Database Description Packets
10.8 送付データベース記述パケット
This section describes how Database Description Packets are sent to a neighbor. 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. There are currently two optional capabilities defined. The T-bit should be set if and only if the router is capable of calculating separate routes for each IP TOS. The E-bit should be set if and only if the attached network belongs to a non-stub area. The rest of the Options field should be set to zero.
このセクションはどうDatabase記述Packetsを送るかを隣人に説明します。 ルータの任意のOSPF能力(セクション4.5を見る)はDatabase記述パケットのOptions分野の隣人に伝えられます。 ルータはDatabase Exchangeと氾濫手順中で同じセットの任意の能力を維持するべきです。 ある理由でルータの任意の能力が変化するなら、Database Exchange手順は、隣人州のExStartに戻ることによって、再開されるべきです。 現在、任意の能力が定義した2があります。 そして、T-ビットが設定されるべきである、ルータが計算できる場合にだけ、各IP TOSのためにルートを切り離してください。 そして、E-ビットが設定されるべきである、付属ネットワークが非スタッブ領域に属す場合にだけ。 Options分野の残りはゼロに設定されるべきです。
The sending of Database Description packets depends on the neighbor's state. In state ExStart the router sends empty Database Description packets, with the initialize (I), more (M) and master (MS) bits set. These packets are retransmitted every RxmtInterval seconds.
Database記述パケットの発信は隣人の状態に依存します。 州のExStartでは、ルータが空のDatabase記述パケットを送る、(I)、より多くの(M)、およびビットが設定するマスター(MS)を初期化してください。 これらのパケットは再送されます。あらゆるRxmtIntervalが後援します。
In state Exchange the Database Description Packets actually contain summaries of the link state information contained in the router's database. Each link state advertisement in the area's topological database (at the time the neighbor transitions into Exchange state) is listed in the neighbor Database summary list. When a new Database Description Packet is to be sent, the packet's sequence number is incremented, and the (new) top of the Database summary list is described by the packet. Items are removed from the Database summary list when the previous packet is acknowledged.
州のExchangeでは、Database記述Packetsは実際にルータのデータベースに含まれたリンク州の情報の概要を含んでいます。 領域の位相的なデータベース(Exchangeへの隣人変遷が述べる時間の)におけるそれぞれのリンク州の広告は隣人Database概要リストに記載されています。 新しいDatabase記述Packetが送られることになっているとき、パケットの一連番号は増加されています、そして、Database概要リストの(新しい)の上部はパケットによって説明されます。 前のパケットが承認されるとき、商品はDatabase概要リストから取り外されます。
In state Exchange, the determination of when to send a packet depends on whether the router is master or slave:
州のExchangeでは、いつパケットを送るかに関する決断をルータがマスターかそれとも奴隷であるかに頼っています:
[Moy] [Page 72] RFC 1247 OSPF Version 2 July 1991
[Moy][72ページ]RFC1247OSPFバージョン1991年7月2日
Master
Packets are sent when either a) the slave acknowledges the previous
packet by echoing the sequence number or b) RxmtInterval seconds
elapse without an acknowledgment, in which case the previous packet
is retransmitted.
a) 奴隷が一連番号かb)を反響することによって前のパケットを承認すると、マスターPacketsを送ります。 RxmtInterval秒は承認なしで経過します、その場合、前のパケットが再送されます。
Slave
Packets are sent only in response to packets received from the
master. If the packet received from the master is new, a new packet
is sent, otherwise the previous packet is resent.
単にマスターから受け取られたパケットに対応して奴隷Packetsを送ります。 マスターから受け取られたパケットが新しいなら、新しいパケットを送ります。さもなければ、前のパケットを再送します。
In states Loading and Full the slave must resend its last packet in response to duplicate packets received from the master. For this reason the slave must wait RouterDeadInterval seconds before freeing the last packet. Reception of a packet from the master after this interval will generate a Seq Number Mismatch neighbor event.
州のLoadingとFullでは、奴隷はマスターから受け取られた写しパケットに対応して最後のパケットを再送しなければなりません。 この理由で、最後のパケットを解放する前に、奴隷はRouterDeadInterval秒を待たなければなりません。 この間隔の後のマスターからのパケットのレセプションはSeq Number Mismatch隣人出来事を発生させるでしょう。
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 link state advertisements that need to be obtained from the neighbor. To request these advertisements, a router sends the neighbor the beginning of the Link state request list, packaged in a Link State Request packet.
隣人州のExchangeかLoadingでは、Link州の要求リストは隣人から得られる必要があるそれらのリンク州の広告のリストを含んでいます。 これらの広告を要求するために、ルータはLink州RequestパケットでパッケージされたLink州の要求リストの始まりを隣人に送ります。
When the neighbor responds to these requests with the proper Link State Update packet(s), the Link state request list is truncated and a new Link State Request packet is sent. This process continues until the link state request list becomes empty. Unsatisfied Link State Requests are retransmitted at intervals of RxmtInterval. There should be at most one Link State Request packet outstanding at any one time.
隣人が適切なLink州Updateパケットでこれらの要求に応じるとき、Link州の要求リストは端が欠けています、そして、新しいLink州Requestパケットを送ります。 リンク州の要求リストが空になるまで、この過程は持続します。 満たされていないLink州RequestsはRxmtIntervalごとに再送されます。 いかなる時も未払いのLink州Requestパケットが最も1つにあるはずです。
When the Link state request list becomes empty, and the neighbor state is Loading (i.e., a complete sequence of Database Description packets has been received from the neighbor), the Loading Done neighbor event is generated.
Link州の要求リストが空になって、隣人状態がLoading(隣人からすなわち、Database記述パケットの完全な配列を受け取った)であるときに、Loading Done隣人出来事は発生します。
10.10 An Example
10.10 例
Figure 14 shows an example of an adjacency forming. Routers RT1 and RT2 are both connected to a broadcast network. It is assumed that RT2 is the Designated Router for the network, and that RT2 has a higher Router ID that router RT1.
図14は、隣接番組に関する例が形成されるのを示します。 ルータのRT1とRT2はともに放送網に接続されます。 RT2がネットワークのためのDesignated Routerであり、RT2には、より高いRouter IDがあると思われます。そのルータRT1。
The neighbor state changes realized by each router are listed on the
各ルータによって実感された隣人州の変化に記載されています。
[Moy] [Page 73] RFC 1247 OSPF Version 2 July 1991
[Moy][73ページ]RFC1247OSPFバージョン1991年7月2日
sides of the figure.
図の側面。
At the beginning of Figure 14, router RT1's interface to the network becomes operational. It begins sending hellos, 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 indicates that it is itself the Designated Router and that it has heard hellos from RT1. This in turn causes RT1 to go to state ExStart, as it starts to bring up the adjacency.
図14の始めに、ネットワークへのルータRT1のインタフェースは操作上になります。 Designated Routerかいかなる他の隣接しているルータのアイデンティティも知りませんが、それはhellosを送り始めます。 ルータRT2がこれを聞く、こんにちは、(隣人をInit状態に動かします)、コネ、それが次である、こんにちは、それがそれ自体でDesignated Routerであり、RT1からhellosを聞いたのを示します。 これで、隣接番組を持って来始めるとき、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 sequence number. Database Description packets are then exchanged, with polls coming from the master (RT2) and responses from the slave (RT1). This sequence of Database Description Packets ends when both the poll and associated response has the M-bit off.
RT1は、マスターとしてそれ自体について断言することによって、始まります。 本当に、RT2がマスター(RT2の、より高いRouter IDによる)であることが見るとき、RT1は奴隷制度の州に移行して、隣人の一連番号を採用します。 そして、投票がマスター(RT2)と応答から奴隷(RT1)から来ていて、データベース記述パケットを交換します。 投票と関連応答の両方であるときに、Database記述Packetsエンドのこの系列はM-ビットを休みにします。
In this example, it is assumed that RT2 has a completely up to date database. In that case, RT2 goes immediately into Full state. RT1 will go into Full state after updating the necessary parts of its database. This is done by sending Link State Request Packets, and receiving Link State Update Packets in response. Note that, while RT1 has waited until a complete set of Database Description Packets has been received (from RT2) before sending any Link State Request Packets, this need not be the case. RT1 could have interleaved the sending of Link State Request Packets with the reception of Database Description Packets.
この例では、RT2には完全に最新のデータベースがあると思われます。 その場合、RT2はすぐFull状態に入ります。 データベースの必要な部分をアップデートした後に、RT1はFull状態に入るでしょう。 Link州Request Packetsを送って、応答でLink州Update Packetsを受けることによって、これをします。 RT1がどんなLink州Request Packetsも送る前にDatabase記述Packetsの完全なセットを受け取るまで(RT2から)待った間これがそうである必要はないことに注意してください。 RT1はDatabase記述Packetsのレセプションに伴うLink州Request Packetsの発信をはさみ込んだかもしれません。
11. The Routing Table Structure
11. 経路指定テーブル構造
The routing table data structure contains all the information necessary to forward an IP data packet toward its destination. Each routing table entry describes the collection of best paths to a particular destination. When forwarding an IP data packet, the routing table entry providing the best match for the packet's IP destination is located.
経路指定テーブルデータ構造はIPデータ・パケットを目的地に向かって送るのに必要なすべての情報を含んでいます。 それぞれの経路指定テーブルエントリーは最も良い経路の収集について特定の目的地に説明します。 IPデータ・パケットを進めるとき、パケットのIPの目的地に提供する中でマッチ最も良い経路指定テーブルエントリーは見つけられています。
________________________________________
________________________________________
(Figure not included in text version.)
(テキストバージョンに含まれていなかった図。)
Figure 14: An adjacency bring-up example
________________________________________
図14: 隣接番組は例を持って来ます。________________________________________
[Moy] [Page 74] RFC 1247 OSPF Version 2 July 1991
[Moy][74ページ]RFC1247OSPFバージョン1991年7月2日
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). 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.
そして、合っている経路指定テーブルエントリーはパケットの目的地に向かって次のホップを提供します。 また、OSPFはデフォルトルートの存在に備えます(Destination IDはDefaultDestinationと等しいです)。 デフォルトルートが存在するとき、それはすべてのIPの目的地に合っています(いかなる他の合っているエントリーもより良いマッチですが)。 ルーティングがIPの目的地に最もよく合っているテーブル項目であることがわかるのとセクション11.1でさらに説明されます。
There is a single routing table in each router. Two sample routing tables are described in Sections 11.2 and 11.3. The building of the routing table is discussed in Section 16.
各ルータには単一の経路指定テーブルがあります。 2個のサンプル経路指定テーブルがセクション11.2と11.3で説明されます。 セクション16で経路指定テーブルのビルについて議論します。
The rest of this section defines the fields found in a routing table entry. The first set of fields describes the routing table entry's destination.
このセクションの残りは経路指定テーブルエントリーで見つけられた分野を定義します。 分野の第一セットは経路指定テーブルエントリーの目的地について説明します。
Destination Type
The destination can be one of three types. Only the first type,
Network, is actually used when forwarding IP data traffic. The
other destinations are used solely as intermediate steps in the
routing table build process.
目的地Type、目的地は3つのタイプのひとりであることができます。 IPデータ通信量を進めるとき、最初のタイプ(Network)だけが実際に使用されます。 経路指定テーブルの途中経過が過程を築き上げるとき、他の目的地は唯一使用されます。
Network
A range of IP addresses, to which IP data traffic may be
forwarded. This includes IP networks (class A, B, or C), IP
subnets, and single IP hosts. The default route also falls in
this category.
IPアドレスのA範囲をネットワークでつないでください。(IPデータ通信量はアドレスに送られるかもしれません)。 これはIPネットワーク(クラスA、B、またはC)、IPサブネット、および独身のIPホストを含んでいます。 また、デフォルトルートはこのカテゴリで落ちます。
Area border router
Routers that are connected to multiple OSPF areas. Such routers
originate summary link advertisements. These routing table
entries are used when calculating the inter-area routes (see
Section 16.2). These routing table entries may also be
associated with configured virtual links.
複数のOSPF領域に接続される境界ルータRouters。 そのようなルータは概要リンク広告を溯源します。 相互領域ルートを計算するとき、これらの経路指定テーブルエントリーは使用されています(セクション16.2を見てください)。 また、これらの経路指定テーブルエントリーも構成された仮想のリンクに関連しているかもしれません。
AS boundary router
Routers that originate AS external link advertisements. These
routing table entries are used when calculating the AS external
routes (see Section 16.4).
外部であることの形でASを溯源するAS境界ルータRoutersが広告をリンクします。 AS外部経路を計算するとき、これらの経路指定テーブルエントリーは使用されています(セクション16.4を見てください)。
Destination ID
The destination's identifier or name. This depends on the
destination's type. For networks, the identifier is their
associated IP address. For all other types, the identifier is the
OSPF Router ID.[9]
目的地ID、目的地の識別子か名前。 これは目的地のタイプに頼っています。 ネットワークにおいて、識別子はそれらの関連IPアドレスです。 他のすべてのタイプにおいて、識別子はOSPF Router IDです。[9]
Address Mask
Only defined for networks. The network's IP address together with
ネットワークのために定義されたMask Onlyを記述してください。 ネットワークのIPアドレス
[Moy] [Page 75] RFC 1247 OSPF Version 2 July 1991
[Moy][75ページ]RFC1247OSPFバージョン1991年7月2日
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サブネットにおいて、アドレスマスクはサブネットマスクと呼ばれます。 ホストルートに、マスクは「すべてのもの」(0xffffffff)です。
Optional Capabilities
When the destination is a router (either an area border router or an
AS boundary router) this field indicates the optional OSPF
capabilities supported by the destination router. The two optional
capabilities currently defined by this specification are the ability
to route based on IP TOS and the ability to process AS external
advertisements. For a further discussion of OSPF's optional
capabilities, see Section 4.5.
任意のCapabilities When、目的地はこの分野が、任意のOSPF能力が目的地のルータで支持したのを示すルータ(境界ルータかAS境界ルータのどちらか)です。 現在この仕様で定義されている2つの任意の能力が、IP TOSに基づいて発送する能力とASの外部の広告を処理する能力です。 OSPFの任意の能力のさらなる議論に関しては、セクション4.5を見てください。
The set of paths to use for a destination may vary based on IP Type of Service and 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 two fields.
目的地に使用する経路のセットはServiceのIP Typeと経路が属するOSPF領域に基づいて異なるかもしれません。 これは、同じ目的地のための複数の経路指定テーブルエントリーがあるかもしれないことを意味します、次の2つの分野の値によって。
Type of Service
There can be a separate set of routes for each IP Type of Service.
The encoding of TOS in OSPF link state advertisements is described
in Section 12.3.
Service ThereのタイプはServiceのそれぞれのIP Typeのための別々のセットのルートであるかもしれません。 OSPFリンク州の広告における、TOSのコード化はセクション12.3で説明されます。
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 "area border
router", there may be separate sets of paths (and therefore separate
routing table entries) associated with each of several areas. This
will happen when two area border routers share multiple areas in
common. For all other destination types, only the set of paths
associated with the best area (the one providing the shortest route)
is kept.
Thisがさばく領域はリンク州の情報が経路指定テーブルエントリーの経路の収集につながった領域を示します。 これはエントリーの関連領域と呼ばれます。 ASの外部の経路のセットにおいて、この分野は定義されません。 タイプ「領域境界ルータ」の目的地には、それぞれのいくつかの領域に関連している経路(したがって、経路指定テーブルエントリーを切り離す)の別々のセットがあるかもしれません。 2つの境界ルータが一般的に複数の領域を分担するとき、これは起こるでしょう。 他のすべての目的地タイプにおいて、最も良い領域(提供する中でルート最も短いもの)に関連している経路のセットだけが維持されます。
The rest of the routing table entry describes the set of paths to the destination. The following fields pertain to the set of paths as a whole. In other words, each one of the paths contained in a routing table entry is of the same path-type and cost (see below).
経路指定テーブルエントリーの残りは経路のセットについて目的地に説明します。 以下の分野は全体で経路のセットに関係します。 言い換えれば、経路指定テーブルエントリーに保管されていた経路のそれぞれには同じ経路タイプと費用があります(以下を見てください)。
Path-type
There are four possible types of paths used to route traffic to the
destination, listed here in order of preference: intra-area, inter-
area, type 1 external or type 2 external. Intra-area paths indicate
経路タイプThereは交通を目的地に発送するのに使用される、4つの可能なタイプの経路です、ここに、好みの順に、記載されています: イントラ領域、相互領域は外部であることの形で1つの外部のタイプかタイプ2をタイプします。 経路が示すイントラ領域
[Moy] [Page 76] RFC 1247 OSPF Version 2 July 1991
[Moy][76ページ]RFC1247OSPFバージョン1991年7月2日
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
link advertisements. AS external paths are paths to destinations
external to the AS. These are detected through the examination of
received AS external link advertisements.
ルータの付属領域の1つに属す目的地。 相互領域経路は他のOSPF領域の目的地への経路です。 これらは受け取られていている概要リンク広告の試験で発見されます。 ASの外部の経路はASへの外部の目的地への経路です。 これらは受け取られていているAS外部のリンク広告の試験で検出されます。
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の外部の道以外のすべての経路に、これは全体の経路の費用について説明します。 Typeの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, an external
type 2 path with type 2 cost of 5 is always preferred over a path
with type 2 cost of 10, regardless of the cost of the two paths'
internal components.
タイプ2はタイプ2の外部の道に、有効なOnlyかかります。 これらの経路に、この分野は経路の外部の部分の費用を示します。 この費用は、AS境界ルータで広告を出して、総経路費用の最もかなりの部分です。 例えば、2がかかる5人のタイプがある外部のタイプ2道は2がかかる10人のタイプがある経路よりいつも好まれます、2つの経路の内部のコンポーネントの費用にかかわらず。
Link State Origin
Valid only for intra-area paths, this field indicates the link state
advertisement (router links or network links) that directly
references the destination. For example, if the destination is a
transit network, this is the transit network's network links
advertisement. If the destination is a stub network, this is the
router links advertisement for the attached router. The
advertisement is discovered during the shortest-path tree
calculation (see Section 16.1). Multiple advertisements may
reference the destination, however a tie-breaking scheme always
reduces the choice to a single advertisement.
イントラ領域経路だけへのリンク州Origin Valid、この分野は直接目的地に参照をつけるリンク州の広告(ルータリンクかネットワークリンク)を示します。 例えば、目的地がトランジットネットワークであるなら、これはトランジットネットワークのネットワークリンク広告です。 目的地がスタッブネットワークであるなら、これは付属ルータのためのルータリンク広告です。 広告は最短パス木の計算の間、発見されます(セクション16.1を見てください)。 多ページ広告は目的地に参照をつけるかもしれなくて、しかしながら、繋がりを壊す計画はいつもただ一つの広告に選択を抑えます。
This field is for informational purposes only. The advertisement
could be used as a root for an SPF calculation when building a
reverse path forwarding tree. This is beyond the scope of this
specification.
この分野は情報の目的だけのためのものです。 逆の経路推進木を建てるとき、SPF計算に根として広告を使用できました。 これはこの仕様の範囲を超えています。
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:
等しい経路タイプと費用の複数の経路が目的地(ほかの場所では、「等しい費用」を経路と呼ぶ)に存在するとき、それらは単一の経路指定テーブルエントリーに格納されます。 「等しい費用」経路の各々は以下の分野によって区別されます:
[Moy] [Page 77] RFC 1247 OSPF Version 2 July 1991
[Moy][77ページ]RFC1247OSPFバージョン1991年7月2日
Next hop
The outgoing router interface to use when forwarding traffic to the
destination. On multi-access networks, the next hop also includes
the IP address of the next router (if any) in the path towards the
destination. This next router will always be one of the adjacent
neighbors.
次に、交通を目的地に送るとき使用する外向的なルータインタフェースは跳びます。 また、マルチアクセスネットワークでは、次のホップは経路で次のルータ(もしあれば)のIPアドレスを目的地に向かって含めます。 この次のルータはいつも隣接している隣人のひとりになるでしょう。
Advertising router
Valid only for inter-area and AS external paths. This field
indicates the Router ID of the router advertising the summary link
or AS external link that led to this path.
相互領域とASの外部の経路だけにルータValidの広告を出します。 この分野はこの経路に通じた概要リンクかASの外部のリンクの広告を出すルータのRouter 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. The process consists of a number of steps, wherein the collection of routing table entries is progressively pruned. In the end, the single routing table entry remaining is the called best match.
IPデータ・パケットが受け取られているとき、OSPFルータによって、ルーティングがパケットの目的地に最もよく合っているテーブル項目であることがわかります。 そして、この経路指定テーブルエントリーはパケットを進める際に使用する外向的なインタフェースと次のホップルータを提供します。 このセクションは最も良い合っているルーティングがテーブル項目であることがわかる過程について説明します。 過程は多くのステップから成ります。そこでは、経路指定テーブルエントリーの収集が次第に剪定されます。 結局、単一の経路指定テーブルエントリーの残りは呼ばれた最も良いマッチです。
Note that the steps described below may fail to produce a best match routing table entry (i.e., all existing routing table entries are pruned for some reason or another). In this case, the packet's IP destination is considered unreachable. Instead of being forwarded, the packet should be dropped and an ICMP destination unreachable message should be returned to the packet's source.
以下で説明されたステップが最も良いマッチ経路指定テーブルエントリーを起こさないかもしれないことに注意してください(すなわちすべての既存の経路指定テーブルエントリーが何らかの理由か別のもののために剪定されます)。 この場合、パケットのIPの目的地は手が届かないと考えられます。 進めることの代わりに、パケットを落とすべきです、そして、ICMP送信不可能メッセージをパケットのソースに返すべきです。
(1) Select the complete set of "matching" routing table entries from the
routing table. Each routing table entry describes a (set of)
path(s) to a range of IP addresses. If the data packet's IP
destination falls into an entry's range of IP addresses, the routing
table entry is called a match. (It is quite likely that multiple
entries will match the data packet. For example, a default route
will match all packets.)
(1) 経路指定テーブルから「合わせている」完全な経路指定テーブルエントリーを選択してください。 それぞれの経路指定テーブルエントリーは(セットされます)経路についてさまざまなIPアドレスに説明します。 データ・パケットのIPの目的地がエントリーのIPアドレスの範囲に落ちるなら、経路指定テーブルエントリーはマッチと呼ばれます。 (多回入国はデータ・パケットにかなり合いそうでしょう。 例えば、デフォルトルートはすべてのパケットに合うでしょう。)
(2) Suppose that the packet's IP destination falls into one of the
router's configured area address ranges (see Section 3.5), and that
the particular area address range is active. This means that there
are one or more reachable (by intra-area paths) networks contained
in the area address range. The packet's IP destination is then
required to belong to one of these constituent networks. For this
reason, only matching routing table entries with path-type of
intra-area are considered (all others are pruned). If no such
(2) パケットのIPの目的地がルータの構成された領域のアドレスの範囲の1つになって(セクション3.5を見てください)、特定の領域のアドレスの範囲がアクティブであると仮定してください。 これは、領域のアドレスの範囲に保管されていた1つ以上の届いている(イントラ領域経路のそばの)ネットワークがあることを意味します。 そして、パケットのIPの目的地が、これらの構成しているネットワークの1つに属すのに必要です。 この理由で、イントラ領域の経路タイプに経路指定テーブルエントリーに合っているだけが考えられます(すべての他のものが剪定されます)。 そのようなものでない
[Moy] [Page 78] RFC 1247 OSPF Version 2 July 1991
[Moy][78ページ]RFC1247OSPFバージョン1991年7月2日
matching entries exist, the destination is unreachable (see above).
Otherwise, skip to step 4.
合っているエントリーは存在していて、目的地は手が届きません(上を見てください)。 さもなければ、ステップ4までスキップしてください。
(3) Reduce the set of matching entries to those having the most
preferential path-type (see Section 11). OSPF has a four level
hierarchy of paths. Intra-area paths are the most preferred,
followed in order by inter-area, Type 1 external and Type 2 external
paths.
(3) 持っている中で最も優先の経路タイプものに合っているエントリーのセットを減少させてください(セクション11を見てください)。 OSPFには、経路の4の平らな階層構造があります。 イントラ領域経路は、相互領域が、オーダーであとに続いて、最も都合のよい、そして、Type1は2つの外部とTypeの外部の経路です。
(4) Select the remaining routing table entry that provides the longest
(most specific) match. Another way of saying this is to choose the
remaining entry that specifies the narrowest range of IP
addresses.[10] 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.
(4) 最も長い(最も特定の)マッチを提供する残っている経路指定テーブルエントリーを選択してください。 IPの最も狭い範囲を指定する残っているエントリーを選ぶと言うこれがものである別の方法が例えばアドレス/マスクのためのエントリーが対にする.[10]を記述する、(128.185、.1、.0、0xffffff00)、エントリーより組には特定である、(128.185、.0、.0、0xffff0000) すべての目的地を合わせるので、デフォルトルートは最も特定でないマッチです。
(5) At this point, there may still be multiple routing table entries
remaining. Each routing entry will specify the same range of IP
addresses, but a different IP Type of Service. Select the routing
table entry whose TOS value matches the TOS found in the packet
header. If there is no routing table entry for this TOS, select the
routing table entry for TOS 0. In other words, packets requesting
TOS X are routed along the TOS 0 path if a TOS X path does not
exist.
(5) ここに、残っている複数の経路指定テーブルエントリーがまだあるかもしれません。 それぞれのルーティングエントリーは同じ範囲のIPアドレス、しかし、Serviceの異なったIP Typeを指定するでしょう。 TOSがパケットのヘッダーとTOS値の一致であるものを探した経路指定テーブルエントリーを選択してください。 このTOSのための経路指定テーブルエントリーが全くなければ、TOS0のために経路指定テーブルエントリーを選択してください。 言い換えれば、TOS X経路が存在していないなら、TOS Xを要求するパケットがTOS0経路に沿って発送されます。
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, indicating that routes will not vary based on TOS. The calculation router RT6's routing table proceeds as described in Section 2.1. The resulting routing table is shown in Table 12. Destination types are abbreviated: Network as "N", area border router as "BR" and AS boundary router as "ASBR".
図2に描写されたAutonomous Systemを考えてください。 OSPF領域は全く構成されていません。 Aシングルメートル法であることは、外国行きのインタフェース単位で示されて、それを示すことです。ルートはTOSに基づいて異ならないでしょう。 計算ルータRT6の経路指定テーブルはセクション2.1で説明されるように続きます。 結果として起こる経路指定テーブルはTable12で見せられます。 目的地タイプは簡略化されています: 「N」、「Br」とした"ASBR"としての境界ルータとした領域境界ルータとして、ネットワークでつなぎます。
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 advertisements 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が1の外部の測定基準をタイプすると思われます。 これは目的地N12-N15に計算されるタイプ1の外部の道をもたらします。
[Moy] [Page 79] RFC 1247 OSPF Version 2 July 1991
[Moy][79ページ]RFC1247OSPFバージョン1991年7月2日
11.3 Sample routing table, with areas
11.3 領域があるサンプル経路指定テーブル
Consider the previous example, this time split into OSPF areas. An OSPF area configuration is pictured in Figure 6. Router RT4's routing table will be described for this area configuration. Router RT4 has a connection to Area 1 and a backbone connection. This causes Router RT4 to view the AS as the concatenation of the two graphs shown in Figures 7 and 8. The resulting routing table is displayed in Table 13.
前の例、OSPF領域に分けられたこの時間を考えてください。 OSPF領域構成は図6に描写されます。 ルータRT4の経路指定テーブルはこの領域構成のために説明されるでしょう。 Area1と背骨接続にはルータRT4が接続がいます。 これで、Router RT4は図7と8に示された2つのグラフの連結であるとASをみなします。 Table13に結果として起こる経路指定テーブルを表示します。
Again, routers RT5 and RT7 are AS boundary routers. Routers RT3, RT4, RT7, RT10 and RT11 are area border routers. Note that there are two routing entries (in this case having identical paths) for router RT7, in its dual capacities as an area border router and an AS boundary router. Note also 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は境界ルータです。 境界ルータとAS境界ルータとしての二元的な立場で2つのルーティングエントリーがルータRT7のためにあることに(この場合、同じ経路を持っています)注意してください。 また、境界ルータRT3のための2つのルーティングエントリーがあることに注意してください、RT4(領域1と背骨)と共用してそれには2つの領域があるので。
Backbone paths have been calculated to all area border routers (BR). These are used when determining the inter-area routes. Note that all of
すべての境界ルータ(BR)に背骨経路について計算してあります。 相互領域ルートを決定するとき、これらは使用されています。 注意、そんなにすべて。
Type Dest Area Path Type Cost Next Hop(s) Adv. 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 * ASBR RT5 0 intra-area 6 RT5 * ASBR RT7 0 intra-area 8 RT10 * __________________________________________________________________________ N N12 * type 1 external 10 RT10 RT7 N N13 * type 1 external 14 RT5 RT5 N N14 * type 1 external 14 RT5 RT5 N N15 * type 1 external 17 RT10 RT7
タイプDest領域経路タイプは次のホップ副詞かかります。 ルータ__________________________________________________________________________ N N1 0 intra-area 10 RT3 * N N2 0 intra-area 10 RT3 * N N3 0 intra-area 7 RT3 * N N4 0 intra-area 8 RT3 * N Ib 0 intra-area 7 * * N Ia 0 intra-area 12 RT10 * N N6 0 intra-area 8 RT10 * N N7 0 intra-area 12 RT10 * N N8 0 intra-area 10 RT10 * N N9 0 intra-area 11 RT10 * N N10 0 intra-area 13 RT10 * N N11 0 intra-area 14 RT10 * N H1 0 intra-area 21 RT10 * ASBR RT5 0 intra-area 6 RT5 * ASBR RT7 0 intra-area 8 RT10 * __________________________________________________________________________ NのN12*タイプの1外部の10RT10 RT7NのN13*1タイプの外部の14RT5 RT5N N14*は1つの外部の14RT5 RT5N N15*タイプ1の外部の17RT10 RT7をタイプします。
Table 12: The routing table for Router RT6 (no configured areas).
テーブル12: Router RT6(構成された領域がない)のための経路指定テーブル。
[Moy] [Page 80] RFC 1247 OSPF Version 2 July 1991
[Moy][80ページ]RFC1247OSPFバージョン1991年7月2日
the inter-area routes are associated with the backbone; this is always the case when the router is itself an area border router. Routing information is condensed at area boundaries. In this example, we assume that Area 3 has been defined so that networks N9-N11 and the host route to H1 are all condensed to a single route when advertised to the backbone (by router RT11). Note that the cost of this route is the minimum of the set of costs to its individual components.
相互領域ルートは背骨に関連しています。 ルータがそれ自体で境界ルータであるときに、いつもこれはそうです。 ルート設定情報はエリアの境界で凝縮します。 この例では、私たちが、Area3が定義されたと思うので、背骨(ルータRT11による)に広告を出すと、N9-N11とホストがH1に発送するネットワークを皆、ただ一つのルートに凝縮します。 このルートの費用が個々のコンポーネントへのコストのセットの最小限であることに注意してください。
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 in Table 14.
追加仮想のリンクがルータRT4とルータRT3の間で構成されるなら、ルータRT4の経路指定テーブルは向上するでしょうに(すなわち、経路指定テーブルの経路のいくつかが、より短くなるでしょう)。 新しい仮想のリンクがそうするだろう、それ自体、Table13(Area1を通したイントラ領域経路)の領域境界ルータRT3のための初記入に関連してください。 これは仮想のリンクへの1の費用をもたらすでしょう。 この仮想のリンクの添加で引き起こされる経路指定テーブルエントリー変化はTable14で見せられます。
12. Link State Advertisements
12. リンク州の広告
Each router in the Autonomous System originates one or more link state advertisements. There are five distinct types of link state advertisements, which are described in Section 4.3. The collection of link state advertisements forms the link state or topological database. Each separate type of advertisement has a separate function. Router links and network links advertisements describe how an area's routers and networks are interconnected. Summary link advertisements provide a way of condensing an area's routing information. AS external advertisements provide a way of transparently advertising externally- derived routing information throughout the Autonomous System.
Autonomous Systemの各ルータは1つ以上のリンク州の広告を溯源します。 5つの異なったタイプのリンク州の広告があります。(広告はセクション4.3で説明されます)。 リンク州の広告の収集はリンク状態か位相的なデータベースを形成します。 それぞれの別々のタイプの広告には、別々の機能があります。 ルータリンクとネットワークリンク広告は領域のルータとネットワークにどうインタコネクトされるかを説明します。 概要リンク広告は領域のルーティング情報を凝縮する方法を提供します。 ASの外部の広告はAutonomous System中に透明に外部的に派生しているルーティング情報の広告を出す方法を提供します。
Each link state advertisement begins with a standard 20-byte header. This link state header is discussed below.
それぞれのリンク州の広告は標準の20バイトのヘッダーと共に始まります。 以下でこのリンク州のヘッダーについて議論します。
[Moy] [Page 81] RFC 1247 OSPF Version 2 July 1991
[Moy][81ページ]RFC1247OSPFバージョン1991年7月2日
Type Dest Area Path Type Cost Next Hop(s) Adv. 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 * BR RT3 1 intra-area 1 * * _______________________________________________________________________________ N Ib 0 intra-area 22 RT5 * N Ia 0 intra-area 27 RT5 * BR RT3 0 intra-area 21 RT5 * BR RT7 0 intra-area 14 RT5 * BR RT10 0 intra-area 22 RT5 * BR RT11 0 intra-area 25 RT5 * ASBR RT5 0 intra-area 8 * * ASBR RT7 0 intra-area 14 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 26 RT5 RT11 _______________________________________________________________________________ N N12 * type 1 external 16 RT5 RT5,RT7 N N13 * type 1 external 16 RT5 RT5 N N14 * type 1 external 16 RT5 RT5 N N15 * type 1 external 23 RT5 RT7
タイプDest領域経路タイプは次のホップ副詞かかります。 ルータ_______________________________________________________________________________ N N1 1イントラ領域4RT1*N N2 1イントラ領域4RT2*N N3 1イントラ領域1**N N4 1イントラ領域3RT3*BR RT3 1イントラ領域1**_______________________________________________________________________________ Nイブ0イントラ領域22RT5*N Ia0イントラ領域27RT5*BR RT3 0イントラ領域21RT5*BR RT7 0イントラ領域14RT5*BR RT10 0イントラ領域22RT5*BR RT11 0イントラ領域25RT5*ASBR RT5 0イントラ領域8**ASBR RT7 0イントラ領域14RT5*_______________________________________________________________________________ N N6 0相互領域15RT5 RT7N N7 0相互領域19RT5 RT7N N8 0相互領域18RT5 RT7N N9-N11、H1 0相互領域26RT5 RT11_______________________________________________________________________________ N N12*タイプ1の外部の16RT5 RT5、RT7N N13*1タイプの外部の16RT5 RT5N N14*は1つの外部の16RT5 RT5N N15*タイプ1の外部の23RT5 RT7をタイプします。
Table 13: Router RT4's routing table in the presence of areas.
テーブル13: ルータRT4は領域があるときテーブルを発送しています。
Type Dest Area Path Type Cost Next Hop(s) Adv. Router(s) __________________________________________________________________________ N Ib 0 intra-area 16 RT3 * N Ia 0 intra-area 21 RT3 * BR RT3 0 intra-area 1 * * BR RT10 0 intra-area 16 RT3 * BR RT11 0 intra-area 19 RT3 * __________________________________________________________________________ N N9-N11,H1 0 inter-area 20 RT3 RT11
タイプDest領域経路タイプは次のホップ副詞かかります。 ルータ__________________________________________________________________________ Nイブ0イントラ領域16RT3*N Ia0イントラ領域21RT3*BR RT3 0イントラ領域1**BR RT10 0イントラ領域16RT3*BR RT11 0イントラ領域19RT3*__________________________________________________________________________ N N9-N11、H1 0相互領域20RT3 RT11
Table 14: Changes resulting from an additional virtual link.
テーブル14: 追加仮想のリンクから生じる変化。
12.1 The Link State Header
12.1 リンク州のヘッダー
[Moy] [Page 82] RFC 1247 OSPF Version 2 July 1991
[Moy][82ページ]RFC1247OSPFバージョン1991年7月2日
The link state header contains the LS type, Link State ID and Advertising Router fields. The combination of these three fields uniquely identifies the link state advertisement.
リンク州のヘッダーはLSタイプ、Link州ID、およびAdvertising Router分野を含んでいます。 これらの3つの分野の組み合わせは唯一リンク州の広告を特定します。
There may be several instances of an advertisement present in the Autonomous System, all at the same time. It must then be determined which instance is more recent. This determination is made be examining the LS sequence, LS checksum and LS age fields. These fields are also contained in the 20-byte link state header.
Autonomous Systemと、すべて同時の現在の広告のいくつかの例があるかもしれません。 どちらの例が、より最近かは、その時、断固としているに違いありません。 LS系列、LSチェックサム、およびLS時代分野を調べるのであるので、この決断をします。 また、これらの分野は20バイトのリンク州のヘッダーに含まれています。
Several of the OSPF packet types list link state advertisements. When the instance is not important, an advertisement 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パケットの数個がリストリンク州の広告をタイプします。 例が重要でないときに、広告はLink州のLSタイプ、ID、およびAdvertising Routerによって言及されます(Link州Request Packetsを見てください)。 さもなければ、また、LS一連番号、LS時代、およびLSチェックサム分野に参照をつけなければなりません。
A detailed explanation of the fields contained in the link state header follows.
リンク州のヘッダーに含まれた分野の詳説は続きます。
12.1.1 LS age
12.1.1 LS時代
This field is the age of the link state advertisement in seconds. It should be processed as an unsigned 16-bit integer. It is set to 0 when the link state advertisement is originated. It must be incremented by InfTransDelay on every hop of the flooding procedure. Link state advertisements are also aged as they are held in each router's database.
この分野は秒のリンク州の広告の時代です。 それは無記名の16ビットの整数として処理されるべきです。 リンク州の広告が溯源されるとき、それは0に設定されます。 InfTransDelayは氾濫手順のあらゆるホップでそれを増加しなければなりません。 また、それらが各ルータのデータベースに保持されるとき、リンク州の広告は熟成します。
The age of a link state advertisement is never incremented past MaxAge. Advertisements having age MaxAge are not used in the routing table calculation. When an advertisement's age first reaches MaxAge, it is reflooded. A link state advertisement of age MaxAge is finally flushed from the database when it is no longer contained on any neighbor Link state retransmission lists. This indicates that it has been acknowledged by all adjacent neighbors. For more information on the aging of link state advertisements, consult Section 14.
リンク州の広告の時代は決して増加している過去MaxAgeではありません。 時代MaxAgeを持っている広告が経路指定テーブル計算に使用されません。 広告の時代が最初にMaxAgeに達するとき、それは「再-あふれ」ます。 それがもうどんな隣人Link州の「再-トランスミッション」リストにも含まれていないとき、時代MaxAgeのリンク州の広告はデータベースから最終的に洗い流されます。 これは、それがすべての隣接している隣人によって承認されたのを示します。 リンク州の広告の年をとることの詳しい情報に関しては、セクション14に相談してください。
Ages are examined when a router receives two instances of a link state advertisement, both having identical sequence numbers and checksums. An instance of age MaxAge is then always accepted as most recent; this allows old advertisements 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.[11] See Section 13.1 for more details.
ルータがリンク州の広告の2つの例を受けるとき、時代は調べられます、ともに同じ一連番号とチェックサムを持っていて。次に、時代MaxAgeの例は最新であるとしていつも認められます。 これは、古い広告が経路ドメインからすぐに洗い流されるのを許容します。 時代がMaxAgeDiff以上で異なるなら、さもなければ、よりわずかな時代を過す例は最新の.[11]として認められます。その他の詳細に関してセクション13.1を見てください。
[Moy] [Page 83] RFC 1247 OSPF Version 2 July 1991
[Moy][83ページ]RFC1247OSPFバージョン1991年7月2日
12.1.2 Options
12.1.2 オプション
The options field in the link state header indicates which optional capabilities are associated with the advertisement. OSPF's optional capabilities are described in Section 4.5. There are currently two optional capabilities defined; they are represented by the T-bit and E- bit found in the options field. The rest of the options field should be set to zero.
リンク州のヘッダーのオプション分野は、どの任意の能力が広告に関連しているかを示します。 OSPFの任意の能力はセクション4.5で説明されます。 現在、任意の能力が定義した2があります。 それらはオプション野原で発見されるT-ビットとEビットによって表されます。 オプション分野の残りはゼロに設定されるべきです。
The E-bit represents OSPF's external routing capability. This bit should be set in all advertisements associated with the backbone, and all advertisements associated with non-stub areas (see Section 3.6). It should also be set in all AS external advertisements. It should be reset in all router links, network links and summary link advertisements associated with a stub area. For all link state advertisements, the setting of the E-bit is for informational purposes only; it does not affect the routing table calculation.
E-ビットはOSPFの外部のルーティング能力を表します。 このビットは背骨に関連しているすべての広告、および非スタッブ領域に関連しているすべての広告に設定されるべきです(セクション3.6を見てください)。 また、それはすべてのASの外部の広告に設定されるべきです。 それはスタッブ領域に関連しているすべてのルータリンク、ネットワークリンク、および概要リンク広告にリセットされるべきです。 すべてのリンクに関しては、広告を述べてください、そして、E-ビットの設定は情報の目的だけのためのものです。 それは経路指定テーブル計算に影響しません。
The T-bit represents OSPF's TOS routing capability. This bit should be set in a router links advertisement if and only if the router is capable of calculating separate routes for each IP TOS (see Section 2.4). The T-bit should always be set in network links advertisements. It should be set in summary link and AS external link advertisements if and only if the advertisement describes paths for all TOS values, instead of just the TOS 0 path. Note that, with the T-bit set, there may still be only a single metric in the advertisement (the TOS 0 metric). This would mean that paths for non-zero TOS exist, but are equivalent to the TOS 0 path. A link state advertisement's T-bit is examined when calculating the routing table's non-zero TOS paths (see Section 16.9).
T-ビットはOSPFのTOSルーティング能力を表します。 そして、このビットがルータにおけるセットが広告をリンクするということであるべきである、ルータが計算できる場合にだけ、各IP TOSのためにルートを切り離してください(セクション2.4を見てください)。 いつもT-ビットはネットワークにおけるセットが広告をリンクするということであるべきです。 それが概要リンクとASの外部のリンク広告に設定されるべきである、単に、広告はすべてのTOS値(正当の代わりにTOS0経路)のために経路について説明します。 広告のメートル法のシングルしかT-ビットセットでまだないかもしれないことに注意してください、(TOS0メートル法、) これは、非ゼロTOSのための経路が存在していますが、TOS0経路に同等であることを意味するでしょう。 経路指定テーブルの非ゼロTOS経路について計算するとき、リンク州の広告のT-ビットは調べられます(セクション16.9を見てください)。
12.1.3 LS type
12.1.3 LSはタイプします。
The LS type field dictates the format and function of the link state advertisement. Advertisements of different types have different names (e.g., router links or network links). All advertisement types, except the AS external link advertisements (LS type = 5), are flooded throughout a single area only. AS external link advertisements are flooded throughout the entire Autonomous System, excluding stub areas (see Section 3.6). Each separate advertisement type is briefly described below in Table 15.
LSタイプ分野はリンク州の広告の書式と機能を決めます。 異なったタイプの広告には、異なった名前(例えば、ルータリンクかネットワークリンク)があります。 ASの外部のリンク広告以外のすべての広告タイプ(LSは=5をタイプする)がただ一つの領域だけ中で水につかっています。 スタッブ領域を除いて、ASの外部のリンク広告は全体のAutonomous System中で水につかっています(セクション3.6を見てください)。 それぞれの別々の広告タイプはTable15で以下で簡潔に説明されます。
LS Type Advertisement description
__________________________________________________
1 These are the router links
advertisements. They describe the
LS Type Advertisement記述__________________________________________________ 1 これらはルータリンク広告です。 彼らは説明します。
[Moy] [Page 84] RFC 1247 OSPF Version 2 July 1991
[Moy][84ページ]RFC1247OSPFバージョン1991年7月2日
LS Type Advertisement description
__________________________________________________
collected states of the router's
interfaces. For more information,
consult Section 12.4.1.
__________________________________________________
2 These are the network links
advertisements. 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 link
advertisements. They describe
inter-area routes, and enable the
condensation of routing information at
area borders. Originated by area border
routers, the Type 3 advertisements
describe routes to networks while the
Type 4 advertisements describe routes to
AS boundary routers.
__________________________________________________
5 These are the AS external link
advertisements. 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 link
advertisement.
LS Type Advertisement記述__________________________________________________ ルータのインタフェースの集まっている州。 詳しくは、セクション12.4.1に相談してください。 __________________________________________________ 2 これらはネットワークリンク広告です。 彼らはネットワークに付けられたルータのセットについて説明します。 詳しくは、セクション12.4.2に相談してください。 __________________________________________________ 3か4Theseは概要リンク広告です。 彼らは、相互領域ルートを説明して、領域の境界でルーティング情報の凝縮を可能にします。 境界ルータによって溯源されて、4つの広告が説明するTypeがAS境界にルータを発送している間、Type3広告はルートをネットワークに説明します。 __________________________________________________ 5 これらはASの外部のリンク広告です。 AS境界ルータによって溯源されて、それらはAutonomous Systemへの外部の目的地にルートを説明します。 また、ASの外部のリンク広告でAutonomous Systemのためのデフォルトルートを説明できます。
Table 15: OSPF link state advertisements.
テーブル15: OSPFは州の広告をリンクします。
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 advertisement. Depending on the advertisement's LS type, the Link State ID takes on the values listed in Table 16.
この分野は広告で説明されている経路ドメインの断片を特定します。 広告のLSタイプに頼っていて、Link州IDはTable16に記載された値を呈します。
[Moy] [Page 85] RFC 1247 OSPF Version 2 July 1991
[Moy][85ページ]RFC1247OSPFバージョン1991年7月2日
LS Type Link State ID ______________________________________________________________________ 1 The originating router's Router ID. 2 The IP interface address of the network's Designated Router. 3 The destination network's IP address. 4 The Router ID of the described AS boundary router. 5 The destination network's IP address.
LSはリンク州のIDをタイプします。______________________________________________________________________ 1 由来しているルータのRouter ID。 2 ネットワークのDesignated RouterのIPインターフェース・アドレス。 3 送信先ネットワークのIPアドレス。 4 説明されたAS境界ルータのRouter ID。 5 送信先ネットワークのIPアドレス。
Table 16: The advertisement's Link State ID.
テーブル16: 広告のLink州ID。
When the link state advertisement is describing a network, the Link State ID is either the network's IP address (as in type 3 summary link advertisements and in AS external link advertisements) or the network's IP address is easily derivable from the Link State ID (note that masking a network links advertisement's Link State ID with the network's subnet mask yields the network's IP address). When the link state advertisement is describing a router, the Link State ID is always the described router's OSPF Router ID.
リンク州の広告がネットワークについて説明しているとき、Link州IDはネットワークのIPアドレス(タイプ3概要リンク広告とASの外部のリンク広告のように)であるかネットワークのIPアドレスがLink州IDから容易に誘導できます(ネットワークにマスクをかけると広告のLink州IDがネットワークのサブネットマスクにリンクされるというメモはネットワークのIPアドレスをもたらします)。 リンク州の広告がルータについて説明しているとき、Link州IDはいつも説明されたルータのOSPF Router IDです。
When an AS external advertisement (LS Type = 5) is describing a default route, its Link State ID is set to DefaultDestination (0.0.0.0).
ASの外部の広告(LS Type=5)がデフォルトルートを説明しているとき、Link州IDがDefaultDestinationに設定される、(0.0 .0 .0)。
12.1.5 Advertising Router
12.1.5 広告ルータ
This field specifies the OSPF Router ID of the advertisement's originator. For router links advertisements, this field is identical to the Link State ID field. Network link advertisements are originated by the network's Designated Router. Summary link advertisements are originated by area border routers. Finally, AS external link advertisements are originated by AS boundary routers.
この分野は広告の創始者のOSPF Router IDを指定します。 ルータリンクに関しては、広告であり、この分野はLink州ID分野と同じです。 ネットワークリンク広告はネットワークのDesignated Routerによって溯源されます。 概要リンク広告は境界ルータによって溯源されます。 最終的に、ASの外部のリンク広告は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 link state advertisements. The space of sequence numbers is linearly ordered. The larger the sequence number (when compared as signed 32-bit integers) the more recent the advertisement. To describe to sequence number space more precisely, let N refer in the discussion below to the constant 2**31.
一連番号分野はサインされた32ビットの整数です。 それは、古い、そして、写しリンク州の広告を検出するのに使用されます。 一連番号のスペースは直線的に命令されます。 一連番号が大きければ(サインされた32ビットの整数として比べると)大きいほど、広告は、より最近です。 一連番号スペースに以上について説明するには、正確に、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. A router uses this sequence number the first time it
一連番号-N(0×80000000)は、予約されるのと(未使用。)です。 これは最も小さくて(したがって、最も古い)の一連番号として-n+1(0×80000001)を残します。 ルータは1回目の間のこの一連番号にそれを使用します。
[Moy] [Page 86] RFC 1247 OSPF Version 2 July 1991
[Moy][86ページ]RFC1247OSPFバージョン1991年7月2日
originates any link state advertisement. Afterwards, the advertisement's sequence number is incremented each time the router originates a new instance of the advertisement. When an attempt is made to increment the sequence number past the maximum value of of N - 1 (0x7fffffff), the current instance of the advertisement must first be flushed from the routing domain. This is done by prematurely aging the advertisement (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 -N + 1 (0x80000001).
どんなリンク州の広告も溯源します。 その後、ルータが広告の新しい例を溯源するたびに広告の一連番号は増加されています。 試みがそうときに、N--1(0x7fffffff)について最大値の先における一連番号を増加するように人工であり、最初に、経路ドメインから広告の現在の例を洗い流さなければなりません。 早まってまでに広告(セクション14.1を見る)の年をとって、それを「再-あふれ」させながら、これをします。 この洪水がすべての隣接している隣人によって承認されるとすぐに、-n+1(0×80000001)の一連番号で新しい例を溯源できます。
The router may be forced to promote the sequence number of one of its advertisements when a more recent instance of the advertisement is unexpectedly received during the flooding process. This should be a rare event. This may indicate that an out-of-date advertisement, originated by the router itself before its last restart/reload, still exists in the Autonomous System. For more information see Section 13.4.
氾濫の過程の間不意に広告の、より最近の例を受け取るとき、ルータはやむを得ず広告の1つの一連番号を促進するかもしれません。 これはめったにない事件であるべきです。 これは、最後の再開/再ロードの前にルータ自体によって溯源された時代遅れな広告がAutonomous Systemにまだ存在しているのを示すかもしれません。 詳しい情報に関しては、セクション13.4を見てください。
,uh "12.1.7 LS checksum"
えー、「12.1、.7LSチェックサム、」
This field is the checksum of the complete contents of the advertisement, excepting the age field. The age field is excepted so that an advertisement'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 C of [RFC 994]. The link state header also contains the length of the advertisement in bytes; subtracting the size of the age field (two bytes) yields the amount of data to checksum.
時代分野を除いて、この分野は広告の完全なコンテンツのチェックサムです。 時代分野は、チェックサムをアップデートしないで広告の時代を増加できるように除外されています。 使用されるチェックサムはISOのコネクションレスなデータグラムにおいて、使用された同じくらいです。 それは一般的にフレッチャーチェックサムと呼ばれます。 それは[RFC994]のAnnex Cに記録されます。 また、リンク州のヘッダーはバイトで表現される広告の長さを含んでいます。 時代分野(2バイト)のサイズを引き算すると、データ量はチェックサムに譲られます。
The checksum is used to detect data corruption of an advertisement. This corruption can occur while an advertisement 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.
チェックサムは、広告のデータの汚染を検出するのに使用されます。 広告が水につかっている状態である、またはそれがルータのメモリに保持されている間、この不正は起こることができます。 LSチェックサム分野はゼロの値を呈することができません。 そのような価値の発生はチェックサム失敗であると考えられるべきです。 言い換えれば、チェックサムの計算は任意ではありません。
The checksum of a link state advertisement 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.
リンク州の広告のチェックサムは2つの場合で確かめられます: a) 時にはリンク州のデータベースの年をとる間Link州Update Packetとb)にそれを受け取るとき。 チェックサム失敗の検出はその都度別々の動きにつながります。 その他の詳細に関してセクション13と14を見てください。
Whenever the LS sequence number field indicates that two instances of an advertisement are the same, the LS checksum field is examined. If there is a difference, the instance with the larger checksum is considered to be most recent.[12] See Section 13.1 for more details.
LS一連番号分野が、広告の2つの例が同じであることを示すときはいつも、LSチェックサム分野は調べられます。 違いがあれば、より大きいチェックサムがある例は最新の.[12]であると考えられます。その他の詳細に関してセクション13.1を考えてください。
[Moy] [Page 87] RFC 1247 OSPF Version 2 July 1991
[Moy][87ページ]RFC1247OSPFバージョン1991年7月2日
12.2 The link state database
12.2 リンク州のデータベース
A router has a separate link state database for every area to which it belongs. The link state database has been referred to elsewhere in the text as the topological database. All routers belonging to the same area have identical topological databases for the area.
ルータには、それが属するあらゆる領域のための別々のリンク州のデータベースがあります。 リンク州のデータベースは位相的なデータベースとしてテキストのほかの場所と呼ばれました。 同じ領域に属すすべてのルータが領域のための同じ位相的なデータベースを持っています。
The databases for each individual area are always dealt with separately. The shortest path calculation is performed separately for each area (see Section 16). Components of the area topological 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.
それぞれの個々の領域のためのデータベースは別々にいつも対処されています。 最短パス計算は別々に各領域に実行されます(セクション16を見てください)。 領域の位相的なデータベースの成分は領域だけ中で水につかっています。 隣接番組(Area Aに属す)が持って来られているとき、最終的に、Area Aのためのデータベースだけが2つのルータの間で同期します。
The area database is composed of router links advertisements, network links advertisements, and summary link advertisements (all listed in the area data structure). In addition, external routes (AS external advertisements) are included in all non-stub area databases (see Section 3.6).
領域データベースは構成されて、ルータが広告をリンクして、ネットワークが広告、および概要リンク広告をリンクするという(すべてが領域データ構造で記載しました)ことです。 さらに、外部経路(ASの外部の広告)はすべての非スタッブ領域データベースに含まれています(セクション3.6を見てください)。
An implementation of OSPF must be able to access individual pieces of an area database. This lookup function is based on an advertisement's LS type, Link State ID and Advertising Router.[13] There will be a single instance (the most up-to-date) of each link state advertisement in the database. The database lookup function is invoked during the link state 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 link state advertisement, and if so, with what LS sequence number.
OSPFの実現は領域データベースの個体にアクセスできなければなりません。 このルックアップ機能は広告のLSタイプに基づいていて、Link州IDとそこのAdvertising Router.[13]はデータベースにおけるそれぞれのリンク州の広告のただ一つの例になるでしょう(最も最新の)。 データベースルックアップ機能はリンク州の氾濫手順(セクション13)と経路指定テーブル計算(セクション16)の間、呼び出されます。 さらに、それにそれ自体がいるか否かに関係なく、ルータが決定できるこのルックアップ機能を使用するのは、特定のリンク州の広告を溯源して、そうだとすれば、どんなLS一連番号でそうしたか。
A link state advertisement 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). A link state advertisement 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 advertisements (Section 12.4) or c) the advertisement ages out and is flushed from the routing domain (Section 14). Whenever a link state advertisement is deleted from the database it must also be removed from all neighbors' Link state retransmission lists (see Section 10).
氾濫の過程(セクション13)の間、a) それを受け取るか、またはルータ(セクション12.4)自体でb) それを溯源するとき、リンク州の広告をルータのデータベースに追加します。 リンク州の広告は、a) それが氾濫の過程(セクション13)の間、より新しい例によって上書きされるか、またはb) ルータが外でc) 自己によって溯源された広告(セクション12.4)か広告時代の1つの、より新しい例を溯源するとき、ルータのデータベースから削除されて、経路ドメイン(セクション14)から洗い流されます。 また、リンク州の広告がデータベースから削除されるときはいつも、すべての隣人のLink州の「再-トランスミッション」リストからそれを取り除かなければなりません(セクション10を見てください)。
12.3 Representation of TOS
12.3 TOSの表現
All OSPF link state advertisements (with the exception of network links advertisements) specify metrics. In router links advertisements, the metrics indicate the costs of the described interfaces. In summary link
すべてのOSPFリンク州の広告(ネットワークを除いて、広告をリンクする)が測定基準を指定します。 ルータリンクでは、広告であり、測定基準は説明されたインタフェースのコストを示します。 概要リンクで
[Moy] [Page 88] RFC 1247 OSPF Version 2 July 1991
[Moy][88ページ]RFC1247OSPFバージョン1991年7月2日
and AS external link advertisements, the metric indicates the cost of the described path. In all of these advertisements, a separate metric can be specified for each IP TOS. TOS is encoded in an OSPF link state advertisement as the following mapping of the Delay (D), Throughput (T) and Reliability (R) flags found in the IP packet header's TOS field (see [RFC 791]).
そして、ASの外部のリンク広告であり、メートル法は説明された経路の費用を示します。 中に、指定されていて、これら広告、aはすべて、各IP TOSのためにメートル法の缶を切り離します。 Delay(D)、Throughput(T)、およびReliability(R)旗に関する以下のマッピングがIPでパケットのヘッダーのTOS分野を見つけたので([RFC791]を見てください)、TOSはOSPFリンク州の広告でコード化されます。
OSPF encoding D T R
_________________________
0 0 0 0
4 0 0 1
8 0 1 0
12 0 1 1
16 1 0 0
20 1 0 1
24 1 1 0
28 1 1 1
D T Rをコード化するOSPF_________________________ 0 0 0 0 4 0 0 1 8 0 1 0 12 0 1 1 16 1 0 0 20 1 0 1 24 1 1 0 28 1 1 1
Table 17: Representing TOS in OSPF.
テーブル17: OSPFにTOSを表します。
Each OSPF link state advertisement must specify the TOS 0 metric. Other TOS metrics, if they appear, must appear in order of increasing TOS encoding. For example, the TOS 8 (high throughput) metric must always appear before the TOS 16 (low delay) metric when both are specified. If a metric for some non-zero TOS is not specified, its cost defaults to the cost for TOS 0, unless the T-bit is reset in the advertisement's options field (see Section 12.1.2 for more details).
それぞれのOSPFリンク州の広告はメートル法でTOS0を指定しなければなりません。 現れるなら、TOSコード化を増加させることの順に他のTOS測定基準は現れなければなりません。 両方が指定されるとき、例えば、TOS8(高生産性)のメートル法の必須はTOS16(低い遅れ)の前でいつもメートル法に見えます。 いくつかの非ゼロTOSにおける、メートル法のaが指定されないなら、費用はTOS0のために費用をデフォルトとします、T-ビットが広告のオプション分野にリセットされない場合(その他の詳細に関してセクション12.1.2を見てください)。
Note that if more TOS types are defined in a future IP architecture, OSPF's TOS encoding can be extended in a straightforward manner.
より多くのTOSタイプが今後のIP建築で定義されるなら、正直な態度でOSPFのTOSコード化を広げることができることに注意してください。
12.4 Originating link state advertisements
12.4 由来しているリンク州の広告
A router may originate many types of link state advertisements. A router originates a router links advertisement for each area to which it belongs. If the router is also the Designated Router for any of its attached networks, it will originate a network links advertisement for that network.
ルータは多くのタイプのリンク州の広告を溯源するかもしれません。 ルータはそれが属する各領域にルータリンク広告を溯源します。 また、ルータが付属ネットワークのどれかのDesignated Routerであるなら、それはそのネットワークのためにネットワークリンク広告を溯源するでしょう。
Area border routers originate a single summary links advertisement for each known inter-area destination. AS boundary routers originate a single AS external links advertisement for each known AS external destination. Destinations are advertised one at a time so that the
境界ルータはそれぞれの知られている相互領域の目的地にただ一つの概要リンク広告を溯源します。 AS境界ルータはそれぞれの知られているAS外部の目的地にただ一つのAS外部のリンク広告を溯源します。 目的地によるしたがって、aの広告を出している1つがそれを調節するということです。
[Moy] [Page 89] RFC 1247 OSPF Version 2 July 1991
[Moy][89ページ]RFC1247OSPFバージョン1991年7月2日
change in any single route can be flooded without reflooding the entire collection of routes. During the flooding procedure, many link state advertisements can be carried by a single Link State Update packet.
ルートの全体の収集を「再-あふれ」させないで、どんなただ一つのルートの変化もあふれさせることができます。 氾濫手順の間、単一のLink州Updateパケットは多くのリンク州の広告を運ぶことができます。
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 link state advertisements into the backbone (one router links, and one summary link for each of the networks N1-N4). Router RT4 will also originate 8 distinct link state advertisements into Area 1 (one router links and seven summary link advertisements as pictured in Figure 7). If RT4 has been selected as Designated Router for network N3, it will also originate a network links advertisement for N3 into Area 1.
例として、図6でルータがRT4であると考えてください。 Area1と接続の背骨を持っていて、それは境界ルータです。 ルータRT4は背骨(1個のルータリンク、およびそれぞれのネットワークN1-N4のための1個の概要リンク)に5つの異なったリンク州の広告を溯源します。 また、ルータRT4は8つの異なったリンク州の広告をArea1に溯源するでしょう(1個のルータリンクと7概要は図7における描写されるとしての広告をリンクします)。 また、RT4がネットワークN3のためのDesignated Routerとして選定されたなら、それはN3のためにネットワークリンク広告をArea1に溯源するでしょう。
In this same figure, router RT5 will be originating 3 distinct AS external link advertisements (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 external advertisements for networks N12-N14 will not be flooded into area 3 (see Section 3.6). Instead, router RT11 would originate a default summary link advertisement 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外部のリンク広告を溯源するでしょう(それぞれのネットワークN12-N14のためのもの)。 領域のいずれもスタッブとして構成されていないと仮定すると、これらは全体のAS中で水につかるでしょう。 しかしながら、領域3が構成されたなら、スタッブ領域、N12-N14がそうするネットワークのための外部の広告として、領域3へあふれられないでください(セクション3.6を見てください)。 代わりに、ルータRT11は領域3中で水につかっているデフォルト概要リンク広告を溯源するでしょう(セクション12.4.3を見てください)。 これは、それらのAS域外交通をRT11に送るよう領域3の内部のルータのすべてに命令します。
Whenever a new instance of a link state advertisement is originated, its LS sequence number is incremented, its LS age is set to 0, its LS checksum is calculated, and the advertisement is added to the link state database and flooded out the appropriate interfaces. See Section 13.2 for details concerning the installation of the advertisement into the link state database. See Section 13.3 for details concerning the flooding of newly originated advertisements.
リンク州の広告の新しい例が溯源されるときはいつも、LS一連番号が増加されていて、LS時代が0に設定されて、LSチェックサムが計算されていて、広告は、リンク州のデータベースに追加されて、適切なインタフェースを水浸しにしました。 詳細に関して広告のインストールに関してリンク州のデータベースにセクション13.2を見てください。 詳細に関して新たに溯源された広告の氾濫に関してセクション13.3を見てください。
The eight events that cause a new instance of a link state advertisement to be originated are:
リンク州の広告の新しい例を溯源する8回の出来事は以下の通りです。
(1) The LS refresh timer firing. There is a LS refresh timer for each
link state advertisement that the router has originated. The LS
refresh timer is an interval timer, with length LSRefreshTimer. The
LS refresh timer guarantees periodic originations regardless of any
other events that cause new instances. This periodic updating of
link state advertisements adds robustness to the link state
algorithm. Link state advertisements that solely describe
unreachable destinations should not be refreshed, but should instead
be flushed from the routing domain (see Section 14.1).
(1) LSはタイマ発火をリフレッシュします。 LSがあります。ルータが溯源したそれぞれのリンク州の広告のためにタイマをリフレッシュしてください。 LSはリフレッシュします。タイマは長さのLSRefreshTimerがあるインタバルタイマです。 LSはいかなる他の出来事にかかわらず原因そんなに新しい周期的な創作が例証するタイマ保証をリフレッシュします。 リンク州の広告のこの周期的なアップデートはリンク州のアルゴリズムに丈夫さを追加します。 唯一手の届かない目的地について説明するリンク州の広告を、リフレッシュするべきではありませんが、代わりに経路ドメインから洗い流すべきです(セクション14.1を見てください)。
[Moy] [Page 90] RFC 1247 OSPF Version 2 July 1991
[Moy][90ページ]RFC1247OSPFバージョン1991年7月2日
When whatever is being described by a link state advertisement changes, a new advertisement is originated. Two instances of the same link state advertisement may not be originated within the time period MinLSInterval. This may require that the generation of the next instance to be delayed by up to MinLSInterval. The following changes may cause a router to originate a new instance of an advertisement. These changes should cause new originations only if the contents of the new advertisement would be different.
何でも広告が変えるリンク州によって説明されているとき、新しい広告は溯源されます。 同じリンク州の広告の2つの例は期間のMinLSInterval中に溯源されないかもしれません。 これは、次の遅らせるべき例の世代がMinLSIntervalへ上昇するのを必要とするかもしれません。 以下の変化で、ルータは広告の新しい例を溯源するかもしれません。 新しい広告のコンテンツが異なる場合にだけ、これらの変化は新しい創作を引き起こすはずです。
(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 links
advertisement.
(2) インタフェースの状態は変化します(セクション9.1を見てください)。 これは、ルータの新しい例が広告をリンクするのが生産物に必要であることを意味するかもしれません。
(3) An attached network's Designated Router changes. A new router links
advertisement should be originated. Also, if the router itself is
now the Designated Router, a new network links advertisement should
be produced.
(3) 付属ネットワークのDesignated Routerは変化します。 新しいルータリンク広告は溯源されるべきです。 また、ルータ自体が今、Designated Router、新しいネットワークが広告をリンクするということであるなら、生産されるべきです。
(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 links advertisement. Also, if the router is itself the
Designated Router for the attached network, a new network links
advertisement should be produced.
(4) 隣接しているルータの1つはFULL状態からの/に変化します。 これは、ルータの新しい例が広告をリンクするのが生産物に必要であることを意味するかもしれません。 また、ルータがそれ自体であるなら、付属ネットワーク、新しいネットワークが広告をリンクするので、Designated Routerは生産されるべきです。
The next three events concern area border routers only.
次の3回の出来事が境界ルータだけに関係があります。
(5) An intra-area route has been added/deleted/modified in the routing
table. This may cause a new instance of a summary links
advertisement (for this route) to be originated in each attached
area (this includes the backbone).
(5) イントラ領域ルートは、経路指定テーブルで加えられるか、削除される、または変更されました。 これはそれぞれの付属領域で溯源されるべきリンク広告(このルートへの)を概要の新しい例に引き起こすかもしれません(これは背骨を含んでいます)。
(6) An inter-area route has been added/deleted/modified in the routing
table. This may cause a new instance of a summary links
advertisement (for this route) to be originated in each attached
area (but NEVER for the backbone).
(6) 相互領域ルートは、経路指定テーブルで加えられるか、削除される、または変更されました。 これはそれぞれの付属領域(しかし、決していずれの背骨のためにも、そうしない)で溯源されるべきリンク広告(このルートへの)を概要の新しい例に引き起こすかもしれません。
(7) The router becomes newly attached to an area. The router must then
originate summary link advertisements into the newly attached area
for all pertinent intra-area and inter-area routes in its routing
table. See Section 12.4.3 for more details.
(7) ルータは新たに領域に付けられるようになります。 ルータは溯源しなければならなくて、次に、経路指定テーブルのすべての適切なイントラ領域と相互領域ルートのために新たに添付の領域に概要リンク広告を溯源してください。 その他の詳細に関してセクション12.4.3を見てください。
The last event concerns AS boundary routers only.
最後の出来事はAS境界ルータだけに関係があります。
[Moy] [Page 91] RFC 1247 OSPF Version 2 July 1991
[Moy][91ページ]RFC1247OSPFバージョン1991年7月2日
(8) An external route gained through direct experience with an external
routing protocol (like EGP) changes. This will cause the AS
boundary router to originate a new instance of an external links
advertisement.
(8) 外部のルーティング・プロトコル(EGPのような)の直接の経験で獲得された外部経路は変化します。 これで、AS境界ルータは外部のリンク広告の新しい例を溯源するでしょう。
The construction of each type of the link state advertisement is explained below. In general, these sections describe the contents of the advertisement body (i.e., the part coming after the 20-byte advertisement header). For information concerning the building of the link state advertisement header, see Section 12.1.
リンク州の広告のそれぞれのタイプの工事は以下で説明されます。 一般に、これらのセクションは広告本文(すなわち、20バイトの広告ヘッダーに続く部分)のコンテンツについて説明します。 リンク州の広告ヘッダーのビルの情報に関しては、セクション12.1を見てください。
12.4.1 Router links
12.4.1 ルータリンク
A router originates a router links advertisement for each area that it belongs to. Such an advertisement describes the collected states of the router's links to the area. The advertisement is flooded throughout the particular area, and no further.
ルータはそれが属す各領域にルータリンク広告を溯源します。 そのような広告はその領域へのルータのリンクの集まっている州について説明します。 広告は特定の領域に、これ以上水につかっています。
The format of a router links advertisement is shown in Appendix A (Section A.4.2). The first 20 bytes of the advertisement consist of the generic link state header that was discussed in Section 12.1. Router links advertisements have LS type = 1. The router indicates whether it is willing to calculate separate routes for each IP TOS by setting (or resetting) the T-bit of the link state advertisement's Options field.
広告がAppendix A(セクションA.4.2)に示されるルータリンクの形式。 広告の最初の20バイトはセクション12.1で議論した一般的なリンク州のヘッダーから成ります。 LSが広告でタイプするルータリンク=1。 ルータは、それが、リンク州の広告のOptions分野のT-ビットを設定することによって(または、リセット)各IP TOSのために別々のルートを計算しても構わないと思っているかどうかを示します。
A router also indicates whether it is an area border router, or an AS boundary router, by setting the appropriate bits in its router links advertisements. This enables paths to those types of routers to be saved in the routing table, for later processing of summary link advertisements and AS external link advertisements.
また、ルータは、設定のそばでは、ルータにおける適切なビットがそれが境界ルータ、またはAS境界ルータであることにかかわらず広告をリンクするのを示します。 これは、ルータのそういったタイプの人への経路が概要リンク広告とASの外部のリンク広告の後の処理のための経路指定テーブルで救われるのを可能にします。
The router links advertisement then describes the router's working connections (links) to the area. Each link is typed according to the
そして、ルータリンク広告はルータの働く接続(リンク)についてその領域に説明します。 各リンクはタイプされます。
_________________________________________
_________________________________________
(Figure not included in text version.)
(テキストバージョンに含まれていなかった図。)
Figure 15: Area 1 with IP addresses shown
Figure 16: Forwarding address example
_________________________________________
図15: 図16が見せられるIPアドレスでの領域1: フォーワーディング・アドレスの例_________________________________________
[Moy] [Page 92] RFC 1247 OSPF Version 2 July 1991
[Moy][92ページ]RFC1247OSPFバージョン1991年7月2日
kind of attached network. Each link is also labelled with its Link ID. This ID gives a name to the entity that is on the other end of the link. Table 18 summarizes the values used for the type and Link ID fields.
ネットワークをちょっと付けました。 また、各リンクはLink IDでラベルされます。 このIDはリンクのもう一方の端にある実体に名前を付けます。 テーブル18はタイプとLink ID分野に使用される値をまとめます。
Link type Description Link ID ____________________________________________________________________________ 1 Point-to-point link Neighbor Router ID 2 Link to transit network Interface address of Designated Router 3 Link to stub network IP network number 4 Virtual link Neighbor Router ID
リンク型記述Link ID____________________________________________________________________________ 1 引き抜くDesignated Router3LinkのトランジットネットワークInterfaceアドレスへのポイントツーポイント接続Neighbor Router ID2LinkはIPネットワーク・ナンバー4VirtualリンクNeighbor Router IDをネットワークでつなぎます。
Table 18: Link descriptions in the router links advertisement.
テーブル18: ルータリンク広告における記述をリンクしてください。
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 routers and transit networks, this field specifies the IP interface address of the associated router interface (this is needed by the routing table calculation, see Section 16.3). For links to stub networks, this field specifies the network's IP address mask.
さらに、Link Data分野は各リンクに指定されます。 この分野はリンクのための32ビットのその他の情報を与えます。 ルータへのリンクと輸送網として、この分野は関連ルータインタフェースのIPインターフェース・アドレスを指定します(これが経路指定テーブル計算で必要です、とセクション16.3は見ます)。 リンクがネットワークを引き抜くように、この分野はネットワークのIPアドレスマスクを指定します。
Finally, the cost of using the link for output (possibly specifying a different cost for each type of service) is specified. The output cost of a link is configurable. It must always be non-zero.
最終的に、出力(ことによると、それぞれのタイプのサービスに異なった費用を指定する)にリンクを使用する費用は指定されます。 リンクの製作費は構成可能です。 いつもそれは非ゼロであるに違いありません。
To further describe the process of building the list of link records, suppose a router wishes to build router links advertisement for an Area A. The router examines its collection of interface data structures. For each interface, the following steps are taken:
さらにルータであるならリンク・レコードのリストを造る過程について説明するために、ルータが収集を調べるArea A.のために広告をルータリンクに組み込むという願望はデータ構造を連結します。 各インタフェースにおいて、以下の方法を取ります:
o If the attached network does not belong to Area A, no links are
added to the advertisement, and the next interface should be
examined.
o 付属ネットワークがArea Aに属さないなら、リンクは全く広告に加えられません、そして、次のインタフェースは調べられるべきです。
o Else, if the state of the interface is Down, no links are added.
o ほかに、リンクは全くインタフェースの状態がDownであるなら、加えられません。
o Else, if the state of the interface is Point-to-Point, then add
links according to the following:
o ほかに、以下に従って、インタフェースの状態がPointからポイントであるならリンクを加えてください:
- If the neighboring router is fully adjacent, add a Type 1 link
(point-to-point) if this is an interface to a point-to-point
network, or add a type 4 link (virtual link) if this is a
virtual link. The Link ID should be set to the Router ID of the
neighboring router, and the Link Data should specify the
- 隣接しているルータが完全に隣接しているなら、これが二地点間ネットワークへのインタフェースであるならType1リンク(ポイントツーポイント)を加えるか、またはこれが仮想のリンクであるならタイプ4リンク(仮想のリンク)を加えてください。 Link IDは隣接しているルータのRouter IDに設定されるべきです、そして、Link Dataは指定するはずです。
[Moy] [Page 93] RFC 1247 OSPF Version 2 July 1991
[Moy][93ページ]RFC1247OSPFバージョン1991年7月2日
interface IP address.
IPアドレスを連結してください。
- If this is a numbered point-to-point network (i.e, not a virtual
link and not an unnumbered point-to-point network) and the
neighboring router's IP address is known, add a Type 3 link
(stub network) whose Link ID is the neighbor's IP address, whose
Link Data is the mask 0xffffffff indicating a host route, and
whose cost is the interface's configured output cost.
- これが番号付の二地点間ネットワーク(無数の二地点間ネットワークではなく、仮想のリンクではなく、i.e)であり、隣接しているルータのIPアドレスが知られているなら、Link IDが隣人のIPアドレスであり、Link Dataがホストルートを示すマスク0xffffffffであり、費用がインタフェースの構成された製作費であるType3リンク(スタッブネットワーク)を加えてください。
o Else 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
serial line. The Link ID should be set to the IP interface address,
the Link Data set to the mask 0xffffffff (indicating a host route),
and the cost set to 0.
o ほかに、インタフェースの状態がLoopbackであるなら、これが無数のシリアル・ラインへのインタフェースでない限り、Type3リンク(スタッブネットワーク)を加えてください。 Link IDはIPインターフェース・アドレスに設定されるべきでした、そして、Link Dataはマスク0xffffffffにセットしました、そして、(ホストルートを示して)費用は0にセットしました。
o Else if the state of the interface is Waiting, add a Type 3 link
(stub network) whose Link ID is the IP network number of the
attached network and whose Link Data is the attached network's
address mask.
o ほかに、インタフェースの状態がWaitingであるなら、Link IDが付属ネットワークのIPネットワーク・ナンバーであり、Link Dataが付属ネットワークのアドレスマスクであるType3リンク(スタッブネットワーク)を加えてください。
o Else, there has been a Designated Router selected 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) whose whose link ID is the IP interface address of the
attached network's Designated Router (which may be the router
itself) and whose Link Data is the interface IP address. Otherwise,
add a link as if the interface state were Waiting (see above).
o ほかに、付属ネットワークのために選択されたDesignated Routerがありました。 ルータが、Designated Router、ルータ自体がDesignated Routerに隣接した完全にDesignated Routerであるなら他の少なくとも1つのルータに隣接した完全にである独身のType2がだれのものをリンクする(トランジットネットワーク)と言い足すなら、付属ネットワークのDesignated Router(ルータ自体であるかもしれない)のIPインターフェース・アドレスはだれのリンクIDであるか、そして、インタフェースIPアドレスはだれのLink Dataですか? さもなければ、まるで界面準位がWaitingであるかのようにリンクを加えてください(上を見てください)。
Unless otherwise specified, the cost of each link generated by the above procedure is equal to the output cost of the associated interface. Note that in the case of serial lines, multiple links may be generated by a single interface.
別の方法で指定されない場合、上の手順で発生するそれぞれのリンクの費用は関連インタフェースの製作費と等しいです。 シリアル・ラインの場合では、複数のリンクが単一のインタフェースで発生するかもしれないことに注意してください。
After consideration of all the router interfaces, host links are added to the advertisement by examining the list of attached hosts. A host route is represented as a Type 3 link (stub network) whose link ID is the host's IP address and whose Link Data is the mask of all ones (0xffffffff).
すべてのルータの考慮が連結した後に、ホストリンクは、付属ホストのリストを調べることによって、広告に加えられます。 Type3がリンクIDがホストのIPアドレスであり、Link Dataがすべてのもの(0xffffffff)のマスクである(スタッブネットワーク)をリンクするとき、ホストルートは表されます。
As an example, consider the router links advertisements 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
例と、図6に描写されるように広告がルータRT3で発生させたルータリンクを考えてください。 ルータRT3(領域1)を含む領域は実際のネットワーク・アドレスが図15にあるredrawnです。 RT3のインターフェース・アドレスのすべての最後のバイトが3であると仮定してください、インタフェースアドレス192.1.1.3と192.1をそれに与えて。.4 .3 そして、もう片方のルータには、同様のアドレシング計画があります。 さらに、すべてのリンクが機能的であり、Router IDが割り当てられると仮定してください。
[Moy] [Page 94] RFC 1247 OSPF Version 2 July 1991
[Moy][94ページ]RFC1247OSPFバージョン1991年7月2日
smallest IP interface address.
最も小さいIPインターフェース・アドレス。
RT3 originates two router links advertisements, 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 links advertisement 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 capable of calculating separate routes based on IP TOS, through setting the T-bit in the Options field. It has also indicated that it is an area border router.
RT3は背骨のために2つのルータリンク広告、Area1と1のためのものを溯源します。 ルータRT4がネットワーク192.1.1のためのDesignatedルータとして.0に選定されたと仮定してください。 RT3のルータは次に1が以下に示されるAreaのために広告をリンクします。 それが、RT3が2つのArea1、1日接続のためにトランジットネットワークにリンクを持っているのを示す、192.1、.1、.0、スタッブネットワークへの2番目のaリンク、192.1、.4、.0 どれにDesignated Router RT4のIPインタフェースがあるか。トランジットネットワークがDesignated RouterのIPインタフェースによって特定されることに注意してください、(すなわち、Link IDが等しい、192.1、.1、.4、192.1 .1 .0)。 また、RT3が、IP TOSに基づく別々のルートは計算できるのを示したことにT-ビットをOptions分野にはめ込むことで注意してください。 また、それは、境界ルータであることを示しました。
; RT3's router links advertisement for Area 1
; RT3のルータはArea1のために広告をリンクします。
LS age = 0 ;always true on origination
Options = (T-bit|E-bit) ;TOS-capable
LS type = 1 ;indicates router links
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 ;RT3 is an area border router
#links = 2
Link ID = 192.1.1.4 ;IP address of Designated Router
Link Data = 192.1.1.3 ;RT3's IP interface to net
Type = 2 ;connects to transit network
# other metrics = 0
TOS 0 metric = 1
時代..いつも..本当..創作..ビット..ビット..できる..タイプ..示す..ルータ..リンク..州..ID..ID..ID..噛み付く..境界..ルータ..ビット..境界ルータ..リンク..ID..アドレス..インタフェース..ネット..接続..トランジット..ネットワーク..測定基準..メートル法
Link ID = 192.1.4.0 ;IP Network number
Link Data = 0xffffff00 ;Network mask
Type = 3 ;connects to stub network
# other metrics = 0
TOS 0 metric = 2
IP Network番号Link Dataが0xffffff00と等しいという.0がネットワークでつなぐリンクID=192.1.4はType=3にマスクをかけます; 0TOS0のメートル法の他の測定基準==2をスタッブネットワーク#に関連づけます。
Next RT3's router links advertisement 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 TOS-capable, and that it is an area border router.
背骨のための広告が示される次のRT3のルータリンク。 それは、RT3がただ一つの付属を背骨に持っているのを示します。 ルータRT6への無数のポイントツーポイント接続を通してこの付属はあります。 RT3はそれがTOSできて、境界ルータであることを再び示しました。
; RT3's router links advertisement for the backbone
; RT3のルータは背骨のために広告をリンクします。
LS age = 0 ;always true on origination
Options = (T-bit|E-bit) ;TOS-capable
LS type = 1 ;indicates router links
LSは本当に創作Options=(T-ビット| 電子ビット)で=0にいつも年をとらせます; TOSできるLSは=1をタイプします; ルータリンクを示します。
[Moy] [Page 95] RFC 1247 OSPF Version 2 July 1991
[Moy][95ページ]RFC1247OSPFバージョン1991年7月2日
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 ;RT3 is an area border router
#links = 1
Link ID = 18.10.0.6 ;Neighbor's Router ID
Link Data = 0.0.0.0 ;Interface to unnumbered SL
Type = 1 ;connects to router
# other metrics = 0
TOS 0 metric = 8
州ID=192.1.1.3をリンクしてください; RT3の.3; RT3のルータIDビットE=0; AS境界ルータでないのあたりルータID Advertising Router=192.1.1はB=1に噛み付きました; RT3は無数のSL Type=1への18.10.0.6; 隣人のRouter ID Link Data=0.0.0.0;1Linkの#、がリンクする境界ルータ=ID=インタフェースです; 0TOS0のメートル法の他の測定基準==8をルータ#に関連づけます。
Even though router RT3 has indicated that it is TOS-capable in the above examples, only a single metric (the TOS 0 metric) has been specified for each interface. Different metrics can be specified for each TOS. The encoding of TOS in OSPF link state advertisements is described in Section 12.3.
ルータRT3が、それはTOS上記の例、シングルだけがメートル法であることでできるのを示した、(TOS0メートル法、)、各インタフェースに指定されました。 各TOSに異なった測定基準を指定できます。 OSPFリンク州の広告における、TOSのコード化はセクション12.3で説明されます。
As an example, suppose the point-to-point link between routers RT3 and RT6 in Figure 15 is a satellite link. The AS administrator may want to encourage the use of the line for high bandwidth traffic. This would be done by setting the metric artificially low for that TOS. Router RT3 would then originate the following router links advertisement for the backbone (IP TOS 8 = high bandwidth):
例として、図15のルータのRT3とRT6とのポイントツーポイント接続が衛星中継であると仮定してください。 AS管理者は線の高帯域交通の使用を奨励したがっているかもしれません。 人工的に低くそのTOSにメートル法を設定することによって、これをするでしょう。 次に、ルータRT3は背骨のために以下のルータリンク広告を溯源するでしょう(IP TOS8=高帯域):
; RT3's router links advertisement for the backbone
; RT3のルータは背骨のために広告をリンクします。
LS age = 0 ;always true on origination
Options = (T-bit|E-bit) ;TOS-capable
LS type = 1 ;indicates router links
Link State ID = 192.1.1.3 ;RT3's Router ID
Advertising Router = 192.1.1.3
bit E = 0 ;not an AS boundary router
bit B = 1 ;RT3 is an area border router
#links = 1
Link ID = 18.10.0.6 ; Neighbor's Router ID
Link Data = 0.0.0.0 ;Interface to unnumbered SL
Type = 1 ;connects to router
# other metrics = 1
TOS 0 metric = 8
TOS = 8 ;High bandwidth
metric = 1 ;traffic preferred
LSは=0に年をとらせます; TOSできるLSが=1をタイプするというOptions=(t-ビット| 電子ビット)がルータリンクLink州ID=192.1.1.3; RT3のRouter ID Advertising Router=192.1.1.3ビットE示す創作=0; AS境界ルータビットB=1でない; RT3でいつも本当であるのが、境界ルータ#が= 1LinkのID=18.10に.0をリンクするということである、.6。 隣人のRouter ID Link Data=0.0.0.0; 無数のSL Type=1へのインタフェース;は=8 1TOS0のメートル法のルータ#他の測定基準=TOS=8; 高帯域メートル法の=1; 好まれた交通に接続します。
12.4.2 Network links
12.4.2 ネットワークリンク
A network links advertisement is generated for every transit multi- access network. (A transit network is a network having two or more attached routers). The network links advertisement describes all the
ネットワークリンク広告はあらゆるトランジットマルチアクセスネットワークのために作られます。 (トランジットネットワークは2を持っているネットワークであるか以上はルータを付けました。) ネットワークリンク広告はすべてについて説明します。
[Moy] [Page 96] RFC 1247 OSPF Version 2 July 1991
[Moy][96ページ]RFC1247OSPFバージョン1991年7月2日
routers that are attached to the network.
ネットワークに付けられているルータ。
The Designated Router for the network originates the advertisement. The Designated Router originates the advertisement only if it is fully adjacent to at least one other router on the network. The network links advertisement is flooded throughout the area that contains the transit network, and no further. The networks links advertisement lists those routers that are fully adjacent to the Designated Router; each fully adjacent router is identified by its OSPF Router ID. The Designated Router includes itself in this list.
ネットワークのためのDesignated Routerは広告を溯源します。 それが完全に溯源する場合にだけ、Designated Routerはネットワークの他の少なくとも1つのルータに隣接して広告を溯源します。 ネットワークリンク広告はトランジットネットワークを含む領域に、これ以上水につかっています。 ネットワークリンク広告はDesignated Routerに隣接して完全にそうであるそれらのルータを記載します。 それぞれの完全に隣接しているルータはOSPF Router IDによって特定されます。 Designated Routerはこのリストにそれ自体を含んでいます。
The Link State ID for a network links advertisement 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 links advertisement) yields the network's IP address.
ネットワークが広告をリンクするので、Link州IDはDesignated RouterのIPインターフェース・アドレスです。 この値、ネットワークのアドレスによってマスクをかけられて、マスク(また、どれがネットワークに含まれているかが広告をリンクする)はネットワークのIPアドレスをもたらします。
A router that has formerly been the Designated Router for a network, but is no longer, should flush the network links advertisement that it had previously originated. This advertisement is no longer used in the routing table calculation. It is flushed by prematurely incrementing the advertisement's age to MaxAge and reflooding (see Section 14.1).
もうネットワークのための以前Designated Routerであるのではなくあるルータはそれが以前に溯源したネットワークリンク広告を洗い流すべきです。 この広告はもう経路指定テーブル計算に使用されません。 それは、早まってまでに広告の時代を増加しながらMaxAgeに洗い流されて、「再-あふれ」ています(セクション14.1を見てください)。
As an example of a network links advertisement, again consider the area configuration in Figure 6. Network links advertisements 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 links advertisement is generated by RT4 on behalf of network N3 (see Figure 15 for the address assignments):
ネットワークに関する例が広告をリンクするとき、もう一度図6での領域構成を考えてください。 広告が溯源されるネットワークリンクは、Area2のネットワークのArea1、N6、およびN8でN3をネットワークでつないで、Area3でネットワークN9をネットワークでつなぎます。 仮定して、ルータRT4がネットワークN3のためのDesignated Routerとして選定されて、以下のネットワークが広告をリンクするのはRT4によってネットワークN3を代表して発生します(アドレス課題に関して図15を見てください):
; network links advertisement for network N3
; ネットワークはネットワークN3のために広告をリンクします。
LS age = 0 ;always true on origination
Options = (T-bit|E-bit) ;TOS-capable
LS type = 2 ;indicates network links
Link State ID = 192.1.1.4 ;IP address of Designated Router
Advertising Router = 192.1.1.4 ;RT4's Router ID
Network Mask = 0xffffff00
Attached Router = 192.1.1.4 ;Router ID
Attached Router = 192.1.1.1 ;Router ID
Attached Router = 192.1.1.2 ;Router ID
Attached Router = 192.1.1.3 ;Router ID
LSは本当に創作Options=(T-ビット| 電子ビット)で=0にいつも年をとらせます; TOSできるLSは=2をタイプします; ネットワークが0xffffff00 Attached Router=192.1.1Link州ID=192.1.1.4; Designated Router Advertising Router=192.1.1.4のIPアドレス; RT4のRouter ID Network Mask=.4; ルータID Attached Router=192.1.1.1; ルータID Attached Router=192.1.1.2; ルータID Attached Router=192.1.1.3; Router IDをリンクするのを示します。
12.4.3 Summary links
12.4.3 概要リンク
Each summary link advertisement describes a route to a single destination. Summary link advertisements are flooded throughout a
それぞれの概要リンク広告は単一の目的地にルートを説明します。 概要リンク広告はa中で水につかっています。
[Moy] [Page 97] RFC 1247 OSPF Version 2 July 1991
[Moy][97ページ]RFC1247OSPFバージョン1991年7月2日
single area only. The destination described is one that is external to the area, yet still belonging to the Autonomous System.
ただ一つの領域専用。 説明された目的地はまだまだAutonomous Systemに属していて、その領域に外部であることのものです。
The DefaultDestination can also be specified in summary link advertisements. This is used when implementing OSPF's stub area functionality (see Section 3.6). In a stub area, instead of importing external routes each area border router originates a "default summary link" (Link State ID = DefaultDestination) into the area.
また、概要リンク広告でDefaultDestinationを指定できます。 OSPFのスタッブ領域の機能性を実行するとき、これは使用されています(セクション3.6を見てください)。 スタッブ領域では、外部経路を輸入することの代わりに、各境界ルータが「デフォルト概要リンク」(リンク州IDはDefaultDestinationと等しい)を領域に溯源します。
Summary link advertisements 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). Only intra-area routes are advertised into the backbone. Both intra-area and inter-area routes are advertised into the other areas.
概要リンク広告は境界ルータによって溯源されます。 領域に広告を出す正確な概要ルートは、経路指定テーブル構造を調べることによって、決定します(セクション11を見てください)。 イントラ領域ルートだけの背骨に広告を出します。 イントラ領域と相互領域ルートの両方の他の領域に広告を出します。
To determine which routes to advertise into an attached Area A, each routing table entry is processed as follows:
付属Area Aにどのルートの広告を出したらよいかを決定するために、それぞれの経路指定テーブルエントリーは以下の通り処理されます:
o Only Destination types of network and AS boundary router are
advertised in summary link advertisements. If the routing table
entry's Destination type is area border router, examine the next
routing table entry.
o 概要リンク広告にネットワークとAS境界ルータのDestinationタイプだけの広告を出します。 経路指定テーブルエントリーのDestinationタイプが領域境界ルータであるなら、次の経路指定テーブルエントリーを調べてください。
o AS external routes are never advertised in summary link
advertisements. If the routing table entry has Path-type type 1
external or type 2 external, examine the next routing table entry.
o 決して概要リンク広告にAS外部経路の広告を出しません。 経路指定テーブルエントリーがPath-タイプが外部であることの形で1をタイプするか、または2外部をタイプするのをさせるなら、次の経路指定テーブルエントリーを調べてください。
o Else, if the area associated with this set of paths is the Area A
itself, do not generate a summary link advertisement for the
route.[14]
o ほかに、このセットの経路に関連している領域がArea A自身であるなら、概要リンク広告をルートに作らないでください。[14]
o Else, if the destination of this route is an AS boundary router,
generate a Type 4 link state advertisement for the destination, with
Link State ID equal to the AS boundary router's ID and metric equal
to the routing table entry's cost. These advertisements should not
be generated if area A has been configured as a stub area.
o ほかに、このルートの目的地がAS境界ルータであるなら、Type4リンク州の広告を目的地に作ってください、経路指定テーブルエントリーの費用へのAS境界ルータのIDとメートル法の同輩と等しいLink州IDと共に。 スタッブ領域として領域Aを構成したなら、これらの広告を作るべきではありません。
o Else, the Destination type is network. If this is an inter-area
route, generate a Type 3 advertisement for the destination, with
Link State ID equal to the network's address and metric equal to the
routing table cost.
o ほかに、Destinationタイプはネットワークです。 これが相互領域ルートであるなら、Type3広告を目的地に作ってください、経路指定テーブル費用へのネットワークのアドレスとメートル法の同輩と等しいLink州IDと共に。
o The one remaining case is an intra-area route to a network. This
means that the network is contained in one of the router's directly
attached areas. In general, this information must be condensed
before appearing in summary link advertisements. Remember that an
area has been defined as a list of address ranges, each range
o 1つの残っているケースがネットワークへのイントラ領域ルートです。 これは、ネットワークがルータの直接付属している領域の1つに含まれていることを意味します。 一般に、概要リンク広告に載る前に、この情報を凝縮しなければなりません。 領域がアドレスの範囲、それぞれの範囲のリストと定義されたのを覚えていてください。
[Moy] [Page 98] RFC 1247 OSPF Version 2 July 1991
[Moy][98ページ]RFC1247OSPFバージョン1991年7月2日
consisting of an [address,mask] pair. A single Type 3 advertisement
must be made for each range, with Link State ID equal to the range's
address and cost equal to the smallest cost of any of the component
networks.
[アドレス、マスク]組から成ります。 ただ一つのType3広告を各範囲に作らなければなりません、範囲のコンポーネントネットワークのどれかの最も少ない費用と等しいアドレスと費用と等しいLink州IDと共に。
If virtual links are being used to provide/increase connectivity of
the backbone, routing information concerning the backbone networks
should not be condensed before being summarized into the virtual
links' transit areas. In other words, the backbone ranges should be
ignored when originating summary links into these areas. The
existence of virtual links can be determined during the shortest
path calculation for the backbone (see Section 16.1).
背骨の接続性を提供するか、または増加させるのに仮想のリンクを使用しているなら、仮想のリンクのトランジット領域へまとめる前に背骨ネットワークのルーティング情報を凝縮するべきではありません。 言い換えれば、これらの領域に概要リンクを溯源するとき、背骨範囲は無視されるべきです。 仮想のリンクの存在は背骨のための最短パス計算の間、決定できます(セクション16.1を見てください)。
In addition, if area A has been configured as a stub area and the router is an area border router, it should advertise a default summary link into Area A. The Link State ID for the advertisement should be set to DefaultDestination, and the metric set to the (per-area) configurable parameter StubDefaultCost.
さらに、それは領域Aがスタッブ領域として構成されて、ルータが境界ルータであるなら、デフォルト概要リンクのArea A.に広告を出すべきです。広告のためのLink州IDはDefaultDestination、および(領域)構成可能なパラメタStubDefaultCostへのメートル法のセットに設定されるべきです。
If a router advertises a summary advertisement for a destination which then becomes unreachable, the router must then flush the advertisement 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 advertisement should also be flushed from the routing domain.
ルータが次に手が届かなくなる目的地に概要広告の広告を出すなら、ルータは、MaxAgeに時代を設定して、「再-あふれ」ることによって、経路ドメインからの広告を洗い流さなければなりません(セクション14.1を見てください)。 また、また、目的地をまだ届いていますが、上の手順に従ってもう広告に掲載できないなら(現在例えば、それは相互領域ルートです、それが以前、何らかの非背骨領域に関連しているイントラ領域ルートであったときに; その結果、それはもう背骨に「広告を出-可能」でないでしょう)、広告は経路ドメインから洗い流されるべきです。
For an example of summary link advertisements, 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 links advertisements. Consider in particular router RT4. Its routing table was calculated as the example in Section 11.3. RT4 originates summary link advertisements into both the backbone and Area 1. Into the backbone, router RT4 originates separate advertisements for each of the networks N1-N4. Into Area 1, router RT4 originates separate advertisements for networks N6-N8 and the AS boundary routers RT5,RT7. It also condenses host routes Ia and Ib into a single summary advertisement. Finally, the routes to networks N9,N10,N11 and host H9 are advertised by a single summary link. This condensation was originally performed by the router RT11.
概要リンク広告の例に関しては、もう一度図6での領域構成を考えてください。 ルータのRT3、RT4、RT7、RT10、およびRT11は境界ルータであり、したがって、由来している概要が広告をリンクするということです。 ルータがRT4であると特に考えてください。 経路指定テーブルはセクション11.3の例として計算されました。 RT4は背骨とArea1の両方に概要リンク広告を溯源します。 背骨に、ルータRT4はそれぞれのネットワークN1-N4のために別々の広告を溯源します。 Area1に、ルータRT4はネットワークのN6-N8とASルータRT5境界、RT7のために別々の広告を溯源します。 また、それはホストルートのIaとイブをただ一つの概要広告に凝縮します。 最終的に、単一の概要リンクはネットワークのN9、N10、N11、およびホストH9へのルートの広告を出します。 この凝縮は元々、ルータRT11によって実行されました。
These advertisements are illustrated graphically in Figures 7 and 8. Two of the summary link advertisements originated by router RT4 follow. The actual IP addresses for the networks and routers in question have been assigned in Figure 15.
これらの広告は図7と8でグラフィカルに例証されます。 ルータRT4によって溯源された2つの概要リンク広告が続きます。 図15で問題のネットワークとルータのための実際のIPアドレスを割り当ててあります。
[Moy] [Page 99] RFC 1247 OSPF Version 2 July 1991
[Moy][99ページ]RFC1247OSPFバージョン1991年7月2日
; summary link advertisement for network N1,
; originated by router RT4 into the backbone
; ネットワークN1のための概要リンク広告。 ルータRT4で、背骨に由来します。
LS age = 0 ;always true on origination
Options = (T-bit|E-bit) ;TOS-capable
LS type = 3 ;indicates summary link to IP net
Link State ID = 192.1.2.0 ;N1's IP network number
Advertising Router = 192.1.1.4 ;RT4's ID
TOS = 0
metric = 4
LSは本当に創作Options=(T-ビット| 電子ビット)で=0にいつも年をとらせます; TOSできるLSは=3をタイプします; IPのネットのLink州ID=192.1.2.0; N1のIPネットワーク数のAdvertising Router=192.1.1.4; RT4のID TOS=0へのメートル法の概要リンク=4を示します。
; summary link advertisement for AS boundary router RT7
; originated by router RT4 into Area 1
; AS境界ルータRT7のための概要リンク広告。 ルータRT4で、Area1に由来します。
LS age = 0 ;always true on origination
Options = (T-bit|E-bit) ;TOS-capable
LS type = 4 ;indicates summary link to ASBR
Link State ID = router RT7's ID
Advertising Router = 192.1.1.4 ;RT4's ID
TOS = 0
metric = 14
LSは本当に創作Options=(T-ビット| 電子ビット)で=0にいつも年をとらせます; TOSできるLSは=4をタイプします; ASBR Link州ID=ルータRT7のID Advertising Router=192.1.1.4 ; RT4のID TOS=0へのメートル法の概要リンク=14を示します。
Summary link advertisements pertain to a single destination (IP network or AS boundary router). However, for a single destination there may be separate sets of paths, and therefore separate routing table entries, for each Type of Service. All these entries must be considered when building the summary link advertisement for the destination; a single advertisement must specify the separate costs (if they exist) for each TOS. The encoding of TOS in OSPF link state advertisements is described in Section 12.3.
概要リンク広告は単一の目的地(IPネットワークかAS境界ルータ)に関係します。 しかしながら、単一の目的地には、別々のセットの経路、およびしたがって、別々の経路指定テーブルエントリーがあるかもしれません、Serviceの各Typeのために。 概要リンク広告を目的地に組み込むとき、これらのすべてのエントリーを考えなければなりません。 ただ一つの広告は別々のコスト(存在しているなら)を各TOSに指定しなければなりません。 OSPFリンク州の広告における、TOSのコード化はセクション12.3で説明されます。
Clearing the T-bit in the Options field of a summary link advertisement indicates that there is a TOS 0 path to the destination, but no paths for non-zero TOS. This can happen when non-TOS capable routers exist in the routing domain (see Section 2.4).
概要リンク広告のOptions分野でT-ビットをきれいにするのは、目的地へのTOS0経路がありますが、非ゼロTOSのためのどんな経路もないのを示します。 非TOSのできるルータが経路ドメインに存在していると(セクション2.4を見てください)、これは起こることができます。
12.4.4 AS external links
12.4.4 ASの外部のリンク
AS external link advertisements describe routes to destinations external to the Autonomous System. Most AS external link advertisements describe routes to specific external destinations. However, a default route for the Autonomous System can be described in an AS external advertisement by setting the advertisement's Link State ID to DefaultDestination (0.0.0.0). AS external link advertisements are originated by AS boundary routers. An AS boundary router originates a single AS external link advertisement for each external route that it has learned, either through another routing protocol (such as EGP), or through configuration
ASの外部のリンク広告はAutonomous Systemへの外部の目的地にルートを説明します。 ほとんどのASの外部のリンク広告が特定の外部の目的地にルートを説明します。 しかしながら、ASの外部の広告で広告のLink州IDをDefaultDestinationに設定することによってAutonomous Systemのためのデフォルトルートを説明できる、(0.0 .0 .0)。 ASの外部のリンク広告はAS境界ルータによって溯源されます。 AS境界ルータはそれが別のルーティング・プロトコル(EGPなどの)を通して、または、構成を通して学んだ各外部経路にただ一つのAS外部のリンク広告を溯源します。
[Moy] [Page 100] RFC 1247 OSPF Version 2 July 1991
[Moy][100ページ]RFC1247OSPFバージョン1991年7月2日
information.
情報。
In general, AS external link advertisements are the only type of link state advertisements that are flooded throughout the entire Autonomous System; all other types of link state advertisements are specific to a single area. However, AS external advertisements 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の外部のリンク広告は唯一のタイプの全体のAutonomous System中で水につかっているリンク州の広告です。 他のすべてのタイプのリンク州の広告はただ一つの領域に特定です。 しかしながら、ASの外部の広告はスタッブ領域中に/へあふれません(セクション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. As with summary link advertisements, if separate paths exist based on TOS, separate TOS costs can be included in the AS external link advertisement. The encoding of TOS in OSPF link state advertisements is described in Section 12.3. If the T-bit of the advertisement's Options field is clear, no non-zero TOS paths to the destination exist.
外部経路に広告に掲載されているメートル法は2つのタイプのひとりであることができます。 タイプ1測定基準はリンク状態にメートル法で匹敵しています。 タイプ2測定基準がどんなイントラ-AS経路の費用よりも大きいと思われます。 概要リンク広告なら、別々の経路がTOSに基づいて存在しているなら、ASの外部のリンク広告に別々のTOSコストを含むことができます。 OSPFリンク州の広告における、TOSのコード化はセクション12.3で説明されます。 広告のOptions分野のT-ビットが明確であるなら、目的地への非ゼロTOS経路は全く存在していません。
If a router advertises an AS external link advertisement for a destination which then becomes unreachable, the router must then flush the advertisement from the routing domain by setting its age to MaxAge and reflooding (see Section 14.1).
ルータが次に手が届かなくなる目的地にASの外部のリンク広告の広告を出すなら、ルータは、MaxAgeに時代を設定して、「再-あふれ」ることによって、経路ドメインからの広告を洗い流さなければなりません(セクション14.1を見てください)。
For an example of AS external link advertisements, consider once again the AS pictured in Figure 6. There are two AS boundary routers: RT5 and RT7. Router RT5 originates three external link advertisements, for networks N12-N14. Router RT7 originates two external link advertisements, for networks N12 and N15. Assume that RT7 has learned its route to N12 via EGP, and that it wishes to advertise a Type 2 metric to the AS. RT7 would then originate the following advertisement for N12:
ASの外部のリンク広告の例に関しては、もう一度図6に描写されたASを考えてください。 2つのAS境界ルータがあります: RT5とRT7。 ルータRT5はネットワークN12-N14のために3つの外部のリンク広告を溯源します。 ルータRT7はネットワークのN12とN15のために2つの外部のリンク広告を溯源します。 RT7がEGPを通してルートをN12に学んで、ASへのメートル法のType2の広告を出したがっていると仮定してください。 次に、RT7はN12のために以下の広告を溯源するでしょう:
; AS external link advertisement for network N12,
; originated by router RT7
; ネットワークN12のためのASの外部のリンク広告。 ルータRT7で、由来します。
LS age = 0 ;always true on origination
Options = (T-bit|E-bit) ;TOS-capable
LS type = 5 ;indicates AS external link
Link State ID = N12's IP network number
Advertising Router = Router RT7's ID
bit E = 1 ;Type 2 metric
TOS = 0
metric = 2
Forwarding address = 0.0.0.0
LSは本当に創作Options=(T-ビット| 電子ビット)で=0にいつも年をとらせます; TOSできるLSは=5をタイプします; ルータASの外部のリンクLink州ID=N12のIPネットワーク・ナンバーAdvertising Router=RT7のIDはE=1に噛み付きました; 0メートル法の=2Forwardingアドレス=0.0.0 2メートル法のTOS=.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
上記の例では、推進アドレス・フィールドは設定されました。0.0 .0 .0 外部の目的地へのパケットが広告OSPFルータ(RT7)に送られるべきであるのを示します。 これはいつもそうであるというわけではありません。
[Moy] [Page 101] RFC 1247 OSPF Version 2 July 1991
[Moy][101ページ]RFC1247OSPFバージョン1991年7月2日
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 EGP information with the non-OSPF router RTX. RTA must then originate AS external link state advertisements for those destinations it has learned from RTX. By using the AS external advertisement'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.
望ましい。 図16に描写された例を考えてください。 一般的なネットワークに関連づけられた3つのOSPFルータ(RTA、RTB、およびRTC)があります。 これらのルータの1つ(RTA)だけが非OSPFルータRTXとEGP情報を交換しています。 そして、RTAはそれがRTXから学んだそれらの目的地にASの外部のリンク州の広告を溯源しなければなりません。 外部の広告がアドレス・フィールドを送るASを使用することによって、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.
推進アドレス・フィールドが非ゼロであるときに、別の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 EGP peer RTX. The resulting AS external link advertisement is pictured below. Note that the Link State ID is set to DefaultDestination.
また、デフォルトルートにフォーワーディング・アドレスを指定できます。 例えば、図では、16RTAは、すべての外部的に運命づけられたパケットがデフォルトでEGP同輩RTXに送られるべきであると指定したがっているかもしれません。 結果として起こるAS外部のリンク広告は以下に描写されます。 Link州IDがDefaultDestinationに設定されることに注意してください。
; Default route, originated by router RTA
; Packets forwarded through RTX
; ルータRTAによって溯源されたデフォルトルート。 RTXを通して進められたパケット
LS age = 0 ;always true on origination
Options = (T-bit|E-bit) ;TOS-capable
LS type = 5 ;indicates AS external link
Link State ID = DefaultDestination ; default route
Advertising Router = Router RTA's ID
bit E = 1 ;Type 2 metric
TOS = 0
metric = 1
Forwarding address = RTX's IP address
LSは本当に創作Options=(T-ビット| 電子ビット)で=0にいつも年をとらせます; TOSできるLSは=5をタイプします; 外部のASリンクLink州ID=DefaultDestinationを示します。 ルータデフォルトルートAdvertising Router=RTAのIDビットE=1; メートル法の2タイプのメートル法のTOS=0の=の1Forwardingのアドレス=RTXのIPアドレス
In figure 16, suppose instead that both RTA and RTB exchange EGP information with RTX. In this case, RTA and RTB would originate the same set of external advertisements. These advertisements, 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 external advertisements, 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 advertisements (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 advertisements (i.e., same destination, cost and non-zero forwarding address), then the advertisement originated by the router having the highest OSPF Router ID is used. The router having the lower OSPF Router ID can then flush its advertisement. Flushing a link
16図では、代わりにRTAとRTBの両方がEGP情報をRTXと交換すると仮定してください。 この場合、RTAとRTBは同じセットの外部の広告を溯源するでしょう。 同じ目的地とフォーワーディング・アドレス(RTX)を指定するでしょう、したがって、同じようにメートル法で指定するなら、これらの広告は機能上同等でしょう。 これは努力の明確な複製に通じます。 RTAかRTBの唯一の1つが外部の広告のセットを溯源するなら、ルーティングは同じままで残っているでしょうに、そして、リンク州のデータベースのサイズは減少するでしょう。 しかしながら、どのルータが広告を溯源するかに関して明白にそれを定義しなければなりません(そうでなければ、どちらもそうするかもしれませんか、または創始者のアイデンティティは振動するかもしれません)。 その結果、以下の規則は確立されます: お互いからともに届いている2つのルータが機能上同等なAS外部の広告(すなわち、同じ目的地、費用、および非ゼロフォーワーディング・アドレス)を溯源するなら、持っている中でOSPF Router ID最も高いルータによって溯源された広告は使用されています。 そして、下側のOSPF Router IDを持っているルータは広告を洗い流すことができます。 リンクを洗い流します。
[Moy] [Page 102] RFC 1247 OSPF Version 2 July 1991
[Moy][102ページ]RFC1247OSPFバージョン1991年7月2日
state advertisement is discussed in Section 14.1.
セクション14.1で州の広告について議論します。
13. The Flooding Procedure
13. 氾濫手順
Link State Update packets provide the mechanism for flooding link state advertisements. A Link State Update packet may contain several distinct advertisements, and floods each advertisement one hop further from its point of origination. To make the flooding procedure reliable, each advertisement must be acknowledged separately. Acknowledgments are transmitted in Link State Acknowledgment packets. Many separate acknowledgments can be grouped together into a single packet.
リンク州Updateパケットは氾濫リンク州の広告にメカニズムを提供します。 Link州Updateパケットは、いくつかの異なった広告を含むかもしれなくて、さらに創作のポイントからのワンバウンドのそれぞれの広告をあふれさせます。 氾濫手順を信頼できるようにするように、別々に各広告を承諾しなければなりません。 承認はLink州Acknowledgmentパケットで伝えられます。 多くの別々の承認を単一のパケットに一緒に分類できます。
The flooding procedure starts when a Link State Update packet has been received. Many consistency checks have been made on the received packet before being handed to the flooding procedure (see Section 8.2). In particular, the Link State Update packet has been associated with a particular neighbor, and a particular area. If the neighbor is in a lesser state than Exchange, the packet should be dropped without further processing.
Link州Updateパケットを受け取ったとき、氾濫手順は始まります。 氾濫手順に手渡す前に容認されたパケットの上で多くの一貫性チェックをしました(セクション8.2を見てください)。 Link州Updateパケットは特定の隣人、および特定の領域に特に、関連しています。 隣人がExchangeより少ない状態にあるなら、パケットはさらなる処理なしで落とされるべきです。
All types of link state advertisements, other than AS external links, are associated with a specific area. However, link state advertisements do not contain an area field. A link state advertisement's area must be deduced from the Link State Update packet header.
ASの外部のリンクを除いて、すべてのタイプのリンク州の広告は特定の領域に関連しています。 しかしながら、リンク州の広告は領域分野を含んでいません。 Link州のUpdateパケットのヘッダーからリンク州の広告の領域を推論しなければなりません。
For each link state advertisement contained in the packet, the following steps are taken:
パケットに含まれたそれぞれのリンク州の広告において、以下の方法を取ります:
(1) Validate the advertisement's link state checksum. If the checksum
turns out to be invalid, discard the advertisement and get the next
one from the Link State Update packet.
(1) 広告のリンク州のチェックサムを有効にしてください。 チェックサムが無効であると判明するなら、広告を捨ててください、そして、Link州Updateパケットから次のものを得てください。
(2) Examine the link state advertisement's LS type. If the LS type is
unknown, discard the advertisement and get the next one from the
Link State Update Packet. This specification defines LS Types 1-5
(see Section 4.3).
(2) リンク州の広告のLSタイプを調べてください。 LSタイプが未知であるなら、広告を捨ててください、そして、Link州Update Packetから次のものを得てください。 この仕様はLS Types1-5を定義します(セクション4.3を見てください)。
(3) Else if this is a AS external advertisement (LS type = 5), and the
area has been configured as a stub area, discard the advertisement
and get the next one from the Link State Update Packet. AS external
advertisements are not flooded into/throughout stub areas (see
Section 3.6).
(3) これがASの外部の広告(LSは=5をタイプする)であり、領域がスタッブ領域として構成されたなら、ほかに、広告を捨ててください、そして、Link州Update Packetから次のものを得てください。 ASの外部の広告はスタッブ領域中に/へあふれません(セクション3.6を見てください)。
(4) Else if the advertisement's age is equal to MaxAge, and there is
currently no instance of the advertisement in the router's link
state database, then take the following actions:
(4) 広告の年令がMaxAgeと等しく、ルータのリンク州のデータベースに広告の例が全く現在なければ、ほかに、以下の行動を取ってください:
[Moy] [Page 103] RFC 1247 OSPF Version 2 July 1991
[Moy][103ページ]RFC1247OSPFバージョン1991年7月2日
(a) Acknowledge the receipt of the advertisement by sending a Link
State Acknowledgment packet back to the sending neighbor (see
Section 13.5).
(a) Link州Acknowledgmentパケットを送付隣人に送り返すことによって、広告の領収書を受け取ったことを知らせてください(セクション13.5を見てください)。
(b) Purge all outstanding requests for equal or previous instances
of the advertisement from the sending neighbor's Link State
Request list (see Section 10).
(b) 送付隣人のLink州Requestリストからの広告の等しいか前の例を求めるすべての傑出している要求を掃除してください(セクション10を見てください)。
(c) If the sending neighbor is in state Exchange or in state
Loading, then install the MaxAge advertisement in the link state
database. Otherwise, simply discard the advertisement. In
either case, examine the next advertisement (if any) listed in
the Link State Update packet.
(c) 送付隣人が州のExchangeか州のLoadingにいるなら、リンク州のデータベースにMaxAge広告をインストールしてください。 さもなければ、単に広告を捨ててください。 どちらの場合ではも、Link州Updateパケットに記載された次の広告(もしあれば)を調べてください。
(5) Otherwise, find the instance of this advertisement that is currently
contained in the router's link state database. If there is no
database copy, or the received advertisement is more recent than the
database copy (see Section 13.1 below for the determination of which
advertisement is more recent) the following steps must be performed:
(5) さもなければ、現在ルータのリンク州のデータベースに含まれているこの広告の例を見つけてください。 データベースコピーが全くないか、または受け取られていている広告が以下が踏むデータベースコピー(広告が、より最近である決断に関して以下のセクション13.1を見る)を実行しなければならないより最近なら:
(a) If there is already a database copy, and if the database copy
was installed less than MinLSInterval seconds ago, discard the
new advertisement (without acknowledging it) and examine the
next advertisement (if any) listed in the Link State Update
packet.
(a) データベースコピーが既にあって、データベースコピーがMinLSInterval秒ほどインストールされなかった、前、新しい広告(それを承認することのない)を捨ててください、そして、Link州Updateパケットに記載された次の広告(もしあれば)を調べてください。
(b) Otherwise immediately flood the new advertisement 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
advertisement was received from a router other than the Backup
DR) the advertisement will be flooded back out the receiving
interface. This occurrence should be noted for later use by the
acknowledgment process (Section 13.5).
(b) さもなければ、至急、ルータのインタフェースの何らかの部分集合から新しい広告をあふれさせてください(セクション13.3を見てください)。 いくつかの場合(例えば、受信インタフェースの状態はDRです、そして、Backup DR以外のルータから広告を受け取った)、広告は水浸しにして戻されて、受信が連結するということでしょう。 この発生は後の使用で承認工程(セクション13.5)で有名であるべきです。
(c) Remove the current database copy from all neighbors' Link state
retransmission lists.
(c) すべての隣人のLink州の「再-トランスミッション」リストから現在のデータベースコピーを取り外してください。
(d) Install the new advertisement 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 advertisement with the current time (i.e., the
time it was received). The flooding procedure cannot overwrite
the newly installed advertisement until MinLSInterval seconds
have elapsed. The advertisement installation process is
discussed further in Section 13.2.
(d) リンク州のデータベースに新しい広告をインストールしてください(現在のデータベースコピーを取り替えて)。 これで、経路指定テーブル計算を予定するかもしれません。 添加、タイムスタンプでの現在の時間(すなわち、それが受け取られた時)がある新しい広告。 MinLSInterval秒が経過するまで、氾濫手順は新たにインストールされた広告を上書きできません。 セクション13.2で、より詳しく広告インストールの過程について議論します。
(e) Possibly acknowledge the receipt of the advertisement by sending
a Link State Acknowledgment packet back out the receiving
(e) Link州Acknowledgmentパケットを送るのによる広告の領収書が受信の手を引くとことによると認めてください。
[Moy] [Page 104] RFC 1247 OSPF Version 2 July 1991
[Moy][104ページ]RFC1247OSPFバージョン1991年7月2日
interface. This is explained below in Section 13.5.
連結してください。 これはセクション13.5で以下で説明されます。
(f) If this new link state advertisement indicates that it was
originated by this router itself, the router must advance the
advertisement's link state sequence number, and issue a new
instance of the advertisement (see Section 13.4).
(f) この新しいリンク州の広告が、それがこのルータ自体によって溯源されたのを示すなら、ルータは、広告のリンク州の一連番号を進めて、広告の新しい例を発行しなければなりません(セクション13.4を見てください)。
(6) Else, if there is an instance of the advertisement on the sending
neighbor's Link state request list, an error has occurred in the
Database Description process. In this case, restart the Database
Description process by generating the neighbor event BadLSReq for
the sending neighbor and stop processing the Link State Update
packet.
(6) ほかに、広告の例が送付隣人のLink州の要求リストにあれば、誤りはDatabase記述の過程で発生しました。 この場合、送付隣人のために隣人イベントBadLSReqを発生させることによって、Database記述の過程を再開してください、そして、Link州Updateパケットを処理するのを止めてください。
(7) Else, if the received advertisement is the same instance as the
database copy (i.e., neither one is more recent) the following two
steps should be performed:
(7) ほかに、以下の2ステップは受け取られていている広告がデータベースコピーと同じ例(すなわち、どちらも、より最近でない)であるなら実行されるべきです:
(a) If the advertisement is listed in the Link state retransmission
list for the receiving adjacency, the router itself is expecting
an acknowledgment for this advertisement. The router should
treat the received advertisement as an acknowledgment, by
removing the advertisement 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) 広告が受信隣接番組のためのLink州の「再-トランスミッション」リストに記載されるなら、ルータ自体はこの広告のための承認を予想しています。 ルータは、Link州の「再-トランスミッション」リストから広告を取り除くことによって、受け取られていている広告を承認として扱うべきです。 これは「暗示している承認」と呼ばれます。 発生は後の使用で承認工程(セクション13.5)で有名であるべきです。
(b) Possibly acknowledge the receipt of the advertisement by sending
a Link State Acknowledgment packet back out the receiving
interface. This is explained below in Section 13.5.
(b) Link州Acknowledgmentパケットを送るのによる広告の領収書が受信インタフェースの手を引くとことによると認めてください。 これはセクション13.5で以下で説明されます。
(8) Else, the database copy is more recent. Note an unusual event to
network management, discard the advertisement and process the next
link state advertisement contained in the packet.
(8) ほかに、データベースコピーは、より最近です。 ネットワークマネージメントへの珍しい出来事に注意してください、そして、広告を捨ててください、そして、パケットに含まれた次のリンク州の広告を処理してください。
13.1 Determining which link state is newer
13.1 どちらのリンク状態が、より新しいかを決定すること。
When a router encounters two instances of a link state advertisement, it must determine which is more recent. This occurred above when comparing a received advertisement to the database copy. This comparison must also be done during the database exchange procedure which occurs during adjacency bring-up.
ルータがリンク州の広告の2つの例に遭遇すると、それは、どちらが、より最近であるかを決定しなければなりません。 受け取られていている広告をデータベースコピーにたとえるとき、これは上に起こりました。 また、起こるデータベース交換手順をこの比較にしなければならない、隣接番組は-上にもたらします。
A link state advertisement is identified by its LS type, Link State ID and Advertising Router. For two instances of the same advertisement, the LS sequence number, LS age, and LS checksum fields are used to determine which instance is more recent:
リンク州の広告はLink州のLSタイプ、ID、およびAdvertising Routerによって特定されます。 同じ広告の2つの例において、LS一連番号、LS時代、およびLSチェックサム分野はどちらの例が、より最近であるかを決定するために費やされます:
[Moy] [Page 105] RFC 1247 OSPF Version 2 July 1991
[Moy][105ページ]RFC1247OSPFバージョン1991年7月2日
o The advertisement 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一連番号がある広告は、より最近です。 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 is of age MaxAge, the instance of
age MaxAge is considered to be more recent.
o ほかに、例の唯一の1つが時代MaxAgeのものであるなら、時代MaxAgeの例が、より最近であると考えられます。
o Else, if the ages of the two instances differ by more than
MaxAgeDiff, the instance having the smaller (younger) age is
considered to be more recent.
o ほかに、2つの例の時代がMaxAgeDiff以上で異なるなら、よりわずかな(より若い)時代を過す例が、より最近であると考えられます。
o Else, the two instances are considered to be identical.
o ほかに、2つの例が同じであると考えられます。
13.2 Installing link state advertisements in the database
13.2 リンク州の広告をデータベースにインストールすること。
Installing a new link state advertisement in the database, either as the result of flooding or a newly self originated advertisement, may cause the routing table structure to be recalculated. The contents of the new advertisement should be compared to the old instance, if present. If there is no difference, there is no need to recalculate the routing table. (Note that even if the contents are the same, the LS checksum will probably be different, since the checksum covers the LS sequence number.)
新しいリンク州の広告をデータベースにインストールして、どちらか氾濫かaの結果として、新たに、自己は広告を溯源して、経路指定テーブル構造が再計算されることを引き起こすかもしれません。 新しい広告のコンテンツは、古い例と比較されていて、存在しているべきです。 違いが全くなければ、ルーティングがテーブルの上に置くrecalculateにおける必要は全くありません。 (内容が同じであっても、LSチェックサムがたぶん異なることに注意してください、チェックサムがLS一連番号をカバーしているので。)
If the contents are different, the following pieces of the routing table must be recalculated, depending on the LS type field:
内容が異なるなら、経路指定テーブルの以下の断片について再計算しなければなりません、LSタイプフィールドによって:
Router links, network links
The entire routing table must be recalculated, starting with the
shortest path calculations for each area (not just the area whose
topological 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.[15]
ルータリンク、全体のルーティングがテーブルの上に置くネットワークリンクについて再計算しなければなりません、各領域(位相的なデータベースが変化した領域であるだけではない)のための最短パス計算から始まって。 最短パス計算がただ一つの変えられた領域に制限されない場合がある理由はAS境界ルータが複数の領域に属すかもしれないという事実と関係があります。 現在提供する中でルート最も良い領域の変化によって、ルータはやむを得ず異なった領域によって提供されたイントラ領域ルートを使用するかもしれません。[15]
Summary link
The best route to the destination described by the summary link
advertisement must be re-examined (see Section 16.5). If this
destination is an AS boundary router, it may also be necessary to
目的地への最も良いルートが概要リンク広告で説明した概要リンクを再検討しなければなりません(セクション16.5を見てください)。 また、この目的地がAS境界ルータであるなら、必要であるかもしれません。
[Moy] [Page 106] RFC 1247 OSPF Version 2 July 1991
[Moy][106ページ]RFC1247OSPFバージョン1991年7月2日
re-examine all the AS external link advertisements.
すべてのASの外部のリンク広告を再検討してください。
AS external link
The best route to the destination described by the AS external link
advertisement must be re-examined (see Section 16.6).
目的地への最も良いルートがASの外部のリンク広告で説明したASの外部のリンクを再検討しなければなりません(セクション16.6を見てください)。
Also, any old instance of the advertisement must be removed from the database when the new advertisement is installed. This old instance must also be removed from all neighbors' Link state retransmission lists (see Section 10).
また、新しい広告をインストールするとき、データベースから広告のどんな古い例も取り除かなければなりません。 また、すべての隣人のLink州の「再-トランスミッション」リストからこの古い例を取り除かなければなりません(セクション10を見てください)。
13.3 Next step in the flooding procedure
13.3 氾濫手順における次のステップ
When a new (and more recent) advertisement 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 advertisement 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.
新しくて(より最近)の広告を受け取ったとき、水浸しにされて、或るものがルータのインタフェースをセットしたということであるに違いありません。 このセクションは、すなわち、外向的なインタフェースを選択して、適切な隣人のLink州の「再-トランスミッション」リストに広告を追加しながら、氾濫手順(セクション13に起こった処理である最初の部分)の第二部について説明します。 また、氾濫手順のこの部分に含まれているのは、隣人のLink州の要求リストの維持です。
This section is equally applicable to the flooding of an advertisement that the router itself has just originated (see Section 12.4). For these advertisements, this section provides the entirety of the flooding procedure (i.e., the processing of Section 13 is not performed, since, for example, the advertisement has not been received from a neighbor and therefore does not need to be acknowledged).
このセクションは等しくルータ自体がちょうど溯源した広告の氾濫に適切です(セクション12.4を見てください)。 これらの広告のために、このセクションは氾濫手順の全体を提供します(すなわち、セクション13の処理が実行されません、例えば、広告は隣人から受け取られていなくて、したがって、承認される必要はありません)。
Depending upon the advertisement's LS type, the advertisement can be flooded out only certain interfaces. These interfaces, defined by the following, are called the eligible interfaces:
広告のLSタイプに頼っていて、あるインタフェースだけから広告をあふれさせることができます。 以下によって定義されたこれらのインタフェースは適任のインタフェースと呼ばれます:
AS external links (LS Type = 5)
AS external links 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の外部のリンク(LS Type=5)のASの外部のリンクは全体のAS中で水につかっています、スタッブ領域を除いて(セクション3.6を見てください)。 領域を引き抜くために付く仮想のリンクとそれらのインタフェースを除いて、適任のインタフェースはすべてのルータのインタフェースです。
All other 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.
他のタイプAll他のすべてのタイプがただ一つの領域(領域A)に特定です。 適任のインタフェースはすべてArea A.に付くそれらのインタフェースです。If Area Aが背骨である、これはすべての仮想のリンクを含んでいます。
[Moy] [Page 107] RFC 1247 OSPF Version 2 July 1991
[Moy][107ページ]RFC1247OSPFバージョン1991年7月2日
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 a link state advertisement out a particular interface, if there is a high probability that the attached neighbors have already received the advertisement. However, in these cases the flooding procedure must be absolutely sure that the neighbors eventually do receive the advertisement, so the advertisement is still added to each adjacency's Link state retransmission list. For each eligible interface:
リンク州のデータベースは上の適任のインタフェースに関連しているすべての隣接番組の上で連動したままで残らなければなりません。 これは、それぞれの適任のインタフェースにおける以下のステップを実行することによって、達成されます。 この手順が、特定のインタフェースでありそれが高い確率にいればリンク州の広告を水浸しにしないように、付属隣人が既に広告を受け取ったと決めるかもしれないことに注意されるべきです。 しかしながら、これらの場合を、氾濫手順が隣人が結局広告を受け取るのを絶対に確認していなければならないので、広告はまだ各隣接番組のLink州の「再-トランスミッション」リストに追加されています。 それぞれの適任のインタフェースに:
(1) Each of the neighbors attached to this interface are examined, to
determine whether they must receive the new advertisement. The
following steps are executed for each neighbor:
(1) このインタフェースに付けられた隣人各人は、彼らが新しい広告を受け取らなければならないかどうか決定するために調べられます。 以下のステップは各隣人のために実行されます:
(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 advertisement on the list, it indicates that the neighboring
router has an instance of the advertisement already. Compare
the new advertisement to the neighbor's copy:
(b) 隣接番組がまだ完全でないなら(隣人状態は、ExchangeかLoadingです)、ほかに、この隣接番組に関連しているLink州の要求リストを調べてください。 新しい広告の例がリストにあれば、それは、隣接しているルータには広告の例が既にあるのを示します。 新しい広告を隣人のコピーにたとえてください:
o If the new advertisement is less recent, then try the next
neighbor.
o 新しい広告がそれほど最近でないなら、次の隣人を裁いてください。
o If the two copies are the same instance, then delete the
advertisement from the Link state request list, and try the
next neighbor.[16]
o コピー2部が同じ例であるなら、Link州の要求リストから広告を削除してください、そして、次の隣人を裁いてください。[16]
o Else, the new advertisement is more recent. Delete the
advertisement from the Link state request list.
o ほかに、新しい広告は、より最近です。 Link州の要求リストから広告を削除してください。
(c) If the new advertisement was received from this neighbor, try
the next neighbor.
(c) この隣人から新しい広告を受け取ったなら、次の隣人を裁いてください。
(d) At this point we are not positive that the new neighbor has an
up-to-date instance of this new advertisement. Add the new
advertisement to the Link state retransmission list for the
adjacency. This ensures that the flooding procedure is
reliable; the advertisement will be retransmitted at intervals
until an acknowledgment is seen from the neighbor.
(d) ここに、私たちは新しい隣人にはこの新しい広告の最新の例があるのを確信していません。 隣接番組のためのLink州の「再-トランスミッション」リストに新しい広告を追加してください。 これは、氾濫手順が信頼できるのを確実にします。 間隔を置いて、承認が隣人から見られるまで、広告は再送されるでしょう。
[Moy] [Page 108] RFC 1247 OSPF Version 2 July 1991
[Moy][108ページ]RFC1247OSPFバージョン1991年7月2日
(2) The router must now decide whether to flood the new link state
advertisement out this interface. If in the previous step, the link
state advertisement was NOT added to any of the Link state
retransmission lists, there is no need to flood the advertisement
and the next interface should be examined.
(2) ルータは、現在、新しいリンク州の広告を水浸しにするために、これが連結するかどうか決めなければなりません。 リンク州の広告が前のステップでLink州の「再-トランスミッション」リストのいずれにも追加されなかったなら、広告をあふれさせる必要は全くありません、そして、次のインタフェースは調べられるべきです。
(3) If the new advertisement was received on this interface, and it was
received from either the Designated Router or the Backup Designated
Router, chances are all the neighbors have received the
advertisement already. Therefore, examine the next interface.
(3) このインタフェースに新しい広告を受け取って、Designated RouterかBackup Designated Routerのどちらかからそれを受け取ったなら、多分、すべての隣人が既に広告を受け取りました。 したがって、次のインタフェースを調べてください。
(4) If the new advertisement 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. If the Designated
Router fails, this router will end up retransmitting the updates.
(4) このインタフェースに新しい広告を受け取って、界面準位がBackup(すなわち、ルータ自体はBackup Designated Routerである)であるなら、次のインタフェースを調べてください。 Designated Routerはこのインタフェースで氾濫させるでしょう。 Designated Routerが失敗すると、このルータは結局、アップデートを再送するでしょう。
(5) If this step is reached, the advertisement must be flooded out the
interface. Send a Link State Update packet (with the new
advertisement as contents) out the interface. The advertisement's
LS age must be incremented by InfTransDelay (which must be > 0) when
copied into the outgoing packet (until the LS age field reaches its
maximum value of MaxAge).
(5) このステップに達しているなら、広告はインタフェースから水につかっているに違いありません。 インタフェースからLink州Updateパケット(コンテンツとしての新しい広告がある)を送ってください。 出発しているパケットにコピーされると(LS時代分野がMaxAgeの最大値に達するまで)、InfTransDelay(>0であるに違いない)は広告のLS時代を増加しなければなりません。
On broadcast networks, the Link State Update packets are multicast.
The destination IP address specified for the Link State Update
Packet depends on the state of the interface. If the interface
state is DR or Backup, the address AllSPFRouters should be used.
Otherwise, the address AllDRouters should be used.
放送網では、Link州Updateパケットはマルチキャストです。 Link州Update Packetに指定された送付先IPアドレスはインタフェースの状態に依存します。 界面準位がDRかBackupであるなら、アドレスAllSPFRoutersは使用されるべきです。 さもなければ、アドレスAllDRoutersは使用されるべきです。
On non-broadcast, multi-access networks, separate Link State Update
packets must be sent, as unicasts, to each adjacent neighbor (i.e.,
those in state Exchange or greater). The destination IP addresses
for these packets are the neighbors' IP addresses.
非放送であって、マルチアクセスしているネットワークに、別々のLink州Updateパケットを送らなければなりません、ユニキャストとして、それぞれの隣接している隣人(すなわち、州のExchangeか、よりすばらしいところのそれら)に。 これらのパケットのための送付先IPアドレスは隣人のIPアドレスです。
13.4 Receiving self-originated link state
13.4 受信は自己にリンク状態を溯源しました。
It is a common occurrence to receive a self-originated link state advertisement via the flooding procedure. If the advertisement received is a newer instance than the last instance that the router actually originated, the router must take special action.
氾濫手順で自己によって溯源されたリンク州の広告を受け取るのは、よくあります。 受け取られた広告がルータが実際に溯源した最終審より新しい例であるなら、ルータは特別な行動を取らなければなりません。
The reception of such an advertisement indicates that there are link state advertisements in the routing domain that were originated before the last time the router was restarted. In this case, the router must advance the sequence number for the advertisement one past the received sequence number, and originate a new instance of the advertisement.
そのような広告のレセプションは、リンク州の広告がルータが前回再開されたとき以前溯源された経路ドメインにあるのを示します。 この場合、ルータは、広告1のために容認された一連番号の先で一連番号を進めて、広告の新しい例を溯源しなければなりません。
[Moy] [Page 109] RFC 1247 OSPF Version 2 July 1991
[Moy][109ページ]RFC1247OSPFバージョン1991年7月2日
Note also that if the type of the advertisement is Summary link or AS external link, the router may no longer have an (advertisable) route to the destination. In this case, the advertisement should be flushed from the routing domain by incrementing the advertisement's LS age to MaxAge and reflooding (see Section 14.1).
また、ルータが広告のタイプがSummaryリンクかASの外部のリンクであるなら、もう(「広告を出-可能」)ルートを目的地に持っていないかもしれないことに注意してください。 この場合、広告は広告のLS時代をMaxAgeに増加して、「再-あふれ」るのによる経路ドメインから紅潮しているべきです(セクション14.1を見てください)。
13.5 Sending Link State Acknowledgment packets
13.5 送付Link州Acknowledgmentパケット
Each newly received link state advertisement 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).
それぞれの新たに受け取られたリンク州の広告を承諾しなければなりません。 通常、州AcknowledgmentパケットをLinkに送ることによって、これをします。 しかしながら、また、州UpdateパケットをLinkに送ることによって、それとなく承認を実行できます(セクション13のステップ7aを見てください)。
Many acknowledgments may be grouped together into a single Link State Acknowledgment packet. Such a packet is sent back out the interface that has received the advertisements. The packet can be sent in one of two ways: delayed and sent on an interval timer, or sent directly (as a unicast) to a particular neighbor. The particular acknowledgment strategy used depends on the circumstances surrounding the receipt of the advertisement.
多くの承認が単一のLink州Acknowledgmentパケットに一緒に分類されるかもしれません。 パケットが送られるそのようなものは広告を受け取ったインタフェースの手を引きます。 2つの方法の1つでパケットを送ることができます: インタバルタイマを遅らせて、転送したか、または特定の隣人に直送しました(ユニキャストとして)。 戦略が使用した特定の承認は広告の領収書を囲む事情に依存します。
Sending delayed acknowledgments accomplishes several things: it facilitates the packaging of multiple acknowledgments in a single packet; it enables a single packet to indicate acknowledgments to several neighbors at once (through multicasting); and it randomizes the acknowledgment packets sent by the various routers attached to a multi- access network. The fixed interval between a router's delayed transmissions must be short (less than RxmtInterval) or needless retransmissions will ensue.
遅れた承認を送ると、数個のものが達成されます: それは単一のパケットでの複数の承認のパッケージを容易にします。 それは、単一のパケットがすぐに(マルチキャスティングを通して)数人の隣人に承認を示すのを可能にします。 そして、それはマルチアクセスネットワークに付けられた様々なルータによって送られた確認応答パケットをランダマイズします。 ルータの遅れたトランスミッションの固定間隔が短いに違いありませんか(RxmtIntervalよりそれほど)、または不必要な「再-トランスミッション」は続くでしょう。
Direct acknowledgments are sent to a particular neighbor in response to the receipt of duplicate link state advertisements. These acknowledgments are sent as unicasts, and are sent immediately when the duplicate is received.
写しリンク州の広告の領収書に対応してダイレクト承認を特定の隣人に送ります。 これらの承認をユニキャストとして送って、すぐ写しが受け取られているとき、送ります。
The precise procedure for sending Link State Acknowledgment packets is described in Table 19. The circumstances surrounding the receipt of the advertisement 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.
送付Link州Acknowledgmentパケットのための正確な手順はTable19で説明されます。 広告の領収書を囲む事情は左のコラムにリストアップされています。 承認動作、次に、取っているのは、正しい2つのコラムの記載されたコネ1です。 この動作を関係があるインタフェースの状態に依存します。 Backupが他のすべての州のインタフェースと異なって振る舞わせる状態のインタフェース。
Action taken in state
Circumstances Backup All other states
______________________________________________________________
州のCircumstances Backup All他の州で取られた行動______________________________________________________________
[Moy] [Page 110] RFC 1247 OSPF Version 2 July 1991
[Moy][110ページ]RFC1247OSPFバージョン1991年7月2日
Action taken in state
Circumstances Backup All other states
______________________________________________________________
Advertisement has No acknowledgment No acknowledgment
been flooded back sent. sent.
out receiving in-
terface (see Sec-
tion 13, step 5b).
______________________________________________________________
Advertisement is Delayed ack- Delayed ack-
more recent than nowledgment sent nowledgment sent.
database copy, but if advertisement
was not flooded received from DR,
back out receiving otherwise do noth-
interface ing
______________________________________________________________
Advertisement is a Delayed ack- No acknowledgment
duplicate, and was nowledgment sent sent.
treated as an im- if advertisement
plied acknowledg- received from DR,
ment (see Section otherwise do noth-
13, step 7a). ing
______________________________________________________________
Advertisement is a Direct acknowledg- Direct acknowledg-
duplicate, and was ment sent. ment sent.
not treated as an
implied ack-
nowledgment.
______________________________________________________________
Advertisement's age Direct acknowledg- Direct acknowledg-
is equal to MaxAge, ment sent. ment sent.
and there is no
current instance of
the advertisement in
the link state
database (see
Section 13, step 4).
州のCircumstances Backup All他の州で取られた行動______________________________________________________________ 広告には、あふれ返さない承認が全く発信したという承認が全くありません。送って. 中で外で受信するのはterfaceされます(Sec- tion13を見てください、ステップ5b)。 ______________________________________________________________ 広告は遅れたack nowledgmentが発信したより最近のnowledgmentが. データベースコピーを送ったDelayed ackですが、広告がそうでなければ、外で受信しながら逆のDRから受け取られていた状態であふれなかったなら、nothインタフェースingをしてください。______________________________________________________________ 広告が運航されたなら、acknowledgはDRから受信されました、ment。広告がa Delayed ack承認写しでなく、送った状態で送られたnowledgmentであった、扱いにされる、不-、(そうでなければ、セクションがnoth13をするのを見てください、ステップ7a)、ing______________________________________________________________ 広告はDirect acknowledgがacknowledg写しを指示するということです、そして、. 送られたmentが送られたmentはことです。暗示しているack- nowledgmentとして扱われません。 ______________________________________________________________ 広告の時代Direct acknowledgのダイレクトacknowledgはMaxAge(. 送られたmentが送られたment)と等しいです、そして、リンク州のデータベースには広告のどんな現在の例もありません(セクション13を見てください、ステップ4)。
Table 19: Sending link state acknowledgements.
テーブル19: リンク州の承認を送ります。
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 on the state of the interface. If the state is DR or Backup, the destination AllSPFRouters is used. In other states, the destination AllDRouters is used. On non-broadcast networks, delayed acks must be unicast separately over
インタフェースに関連しているすべての隣接しているルータに遅れた承認を提供しなければなりません。 放送網では、これは、マルチキャストとして遅れたLink州Acknowledgmentパケットを送ることによって、達成されます。 アドレスが使用したDestination IPはインタフェースの状態に依存します。 状態がDRかBackupであるなら、目的地AllSPFRoutersは使用されています。 他の州目的地AllDRoutersは使用されています。 遅れたacksが別々に非放送網では、ユニキャストであるに違いない、終わっている。
[Moy] [Page 111] RFC 1247 OSPF Version 2 July 1991
[Moy][111ページ]RFC1247OSPFバージョン1991年7月2日
each adjacency (neighbor whose state is >= Exchange).
各隣接番組(状態が>である隣人は交換と等しいです)。
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 DR, and RT3 as Backup for the network N3. When router RT4 floods a new advertisement to network N3, it is received by routers RT1, RT2, and RT3. These routers will not flood the advertisement back onto net N3, but they still must ensure that their topological databases remain synchronized with their adjacent neighbors. So RT1, RT2, and RT4 are waiting to see an acknowledgment from RT3. Likewise, RT4 and RT3 are both waiting to see acknowledgments from RT1 and RT2. This is best achieved by sending the acknowledgments as multicasts.
例でマルチキャストとして上のパケットを送る後ろの推理について説明するのは最も良いです。 図15に表現されたネットワーク・コンフィギュレーションを考えてください。 RT4がDR、およびネットワークN3のためのBackupとしてのRT3として選出されたと仮定してください。 ルータRT4がネットワークN3へ新しい広告をあふれさせるとき、それはルータのRT1、RT2、およびRT3によって受け取られます。 これらのルータはネットの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 link state advertisements (see Section 13.3, step 4).
Backup DRsのための承認論理がわずかに異なっている理由は彼らがリンク州の広告の氾濫の間、異なって働くから(セクション13.3を見てください、ステップ4)です。
13.6 Retransmitting link state advertisements
13.6 リンク州の広告を再送すること。
Advertisements flooded out an adjacency are placed on the adjacency's Link state retransmission list. In order to ensure that flooding is reliable, these advertisements 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.
隣接番組から水につかっている広告は隣接番組のLink州の「再-トランスミッション」リストに置かれます。 氾濫が信頼できるのを確実にするために、それらが承認されるまで、これらの広告は再送されます。 RxmtInterval、1インタフェースあたり「再-トランスミッション」の間の時間の長さは1つの構成可能な値です。 これがインタフェースのときにあまりに低く予定されると、不必要な「再-トランスミッション」は続くでしょう。 値があまり高く設定されるなら、無くなっているパケットに直面して、氾濫の速度は影響を受けるかもしれません。
Several retransmitted advertisements may fit into a single Link State Update packet. When advertisements are to be retransmitted, only the number fitting in a single Link State Update packet should be transmitted. Another packet of retransmissions can be sent when some of the advertisements are acknowledged, or on the next firing of the retransmission timer.
いくつかの再送された広告が単一のLink州Updateパケットに収まるかもしれません。 広告が再送されることであるときに、単一のLink州Updateパケットをうまくはめ込む数だけが伝えられるべきです。 承認されるか、または再送信タイマーの次の発火に広告のいくつかがあるとき、「再-トランスミッション」の別のパケットを送ることができます。
Link State Update Packets carrying retransmissions are always sent as unicasts (directly to the physical address of the neighbor). They are never sent as multicasts. Each advertisement's LS age must be incremented by InfTransDelay (which must be > 0) when copied into the outgoing packet (until the LS age field reaches its maximum value of MaxAge).
ユニキャスト(直接隣人の物理アドレスへの)としていつも「再-トランスミッション」を運ぶリンク州Update Packetsを送ります。 マルチキャストとしてそれらを決して送りません。 出発しているパケットにコピーされると(LS時代分野がMaxAgeの最大値に達するまで)、InfTransDelay(>0であるに違いない)は各広告のLS時代を増加しなければなりません。
If the adjacent router goes down, retransmissions may occur until the adjacency is destroyed by OSPF's Hello Protocol. When the adjacency is destroyed, the Link state retransmission list is cleared.
隣接しているルータが落ちるなら、隣接番組がOSPFのHelloプロトコルによって破壊されるまで、「再-トランスミッション」は現れるかもしれません。 隣接番組が破壊されるとき、Link州の「再-トランスミッション」リストはきれいにされます。
[Moy] [Page 112] RFC 1247 OSPF Version 2 July 1991
[Moy][112ページ]RFC1247OSPFバージョン1991年7月2日
13.7 Receiving link state acknowledgments
13.7 リンク州の承認を受けること。
Many consistency checks have been made on a received Link State Acknowledgment packet before it is handed to the flooding procedure. In particular, it has been associated with a particular neighbor. If this neighbor is in a lesser state than Exchange, the packet is discarded.
氾濫手順にそれを手渡す前に容認されたLink州Acknowledgmentパケットの上で多くの一貫性チェックをしました。 それは特定の隣人に特に、関連しています。 この隣人がExchangeより少ない状態にあるなら、パケットは捨てられます。
Otherwise, for each acknowledgment in the packet, the following steps are performed:
さもなければ、パケットでの各承認において、以下のステップは実行されます:
o Does the advertisement acknowledged have an instance on the Link
state retransmission list for the neighbor? If not, examine the
next acknowledgment. Otherwise:
o 承諾された広告は隣人へのLink州の「再-トランスミッション」リストに例を持っていますか? そうでなければ、次の承認を調べてください。 そうでなければ:
o If the acknowledgment is for the same instance that is contained on
the list, remove the item from the list and examine the next
acknowledgment. Otherwise:
o 承認がリストに含まれている同じ例のためのものであるなら、リストから商品を取り外してください、そして、次の承認を調べてください。 そうでなければ:
o Log the questionable acknowledgment, and examine the next one.
o 疑わしい承認を登録してください、そして、次のものを調べてください。
14. Aging The Link State Database
14. リンク州のデータベースの年をとります。
Each link state advertisement has an age field. The age is expressed in seconds. An advertisement's 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 advertisement's age is incremented by InfTransDelay.
それぞれのリンク州の広告には、時代分野があります。 時代は秒に表されます。 それはルータのデータベースに含まれていますが、広告の時代分野は増加されています。 また、特定のインタフェースを水浸しにするためにLink州Update Packetにコピーされると、広告の時代はInfTransDelayによって増加されます。
An advertisement's age is never incremented past the value MaxAge. Advertisements having age MaxAge are not used in the routing table calculation. As a router ages its link state database, an advertisement's age may reach MaxAge.[17] At this time, the router must attempt to flush the advertisement from the routing domain. This is done simply by reflooding the MaxAge advertisement just as if it was a newly originated advertisement (see Section 13.3).
広告の時代は値のMaxAgeの先で決して増加されません。 時代MaxAgeを持っている広告が経路指定テーブル計算に使用されません。 ルータがリンク州のデータベースに年をとらせるのに従って、広告の時代はこのときMaxAge.[17]に達するかもしれなくて、ルータは、経路ドメインからの広告を洗い流すのを試みなければなりません。 単にまるでまさしくそれが新たに溯源された広告(セクション13.3を見る)であるかのようにMaxAge広告を「再-あふれ」させることによって、これをします。
When a Database summary list for a newly adjacent neighbor is formed, any MaxAge advertisements present in the link state database are added to the neighbor's Link state retransmission list instead of the neighbor's Database summary list. See Section 10.3 for more details.
新たに隣接している隣人へのDatabase概要リストが形成されるとき、リンク州のデータベースの現在のどんなMaxAge広告も隣人のDatabase概要リストの代わりに隣人のLink州の「再-トランスミッション」リストに追加されます。 その他の詳細に関してセクション10.3を見てください。
A MaxAge advertisement is removed entirely from the router's link state database when a) it is no longer contained on any neighbor Link state retransmission lists and b) none of the router's neighbors are in states Exchange or Loading.
もうどんな隣人Link州の「再-トランスミッション」リストにもa) それを含まないとき、完全にルータのリンク州のデータベースからMaxAge広告を取り除きます、そして、b) ルータの隣人のだれも州のExchangeかLoadingにいません。
[Moy] [Page 113] RFC 1247 OSPF Version 2 July 1991
[Moy][113ページ]RFC1247OSPFバージョン1991年7月2日
When, in the process of aging the link state database, an advertisement's age hits a multiple of CheckAge, its checksum should be verified. If the checksum is incorrect, a program or memory error has been detected, and at the very least the router itself should be restarted.
リンク州のデータベースの年をとることの途中に広告の時代がCheckAgeの倍数を打つと、チェックサムは確かめられるべきです。 チェックサムが不正確であるなら、プログラムかメモリ誤りが検出されました、そして、少なくとも、ルータ自体は再開されるべきです。
14.1 Premature aging of advertisements
14.1 広告の時期尚早な年をとること
A link state advertisement can be flushed from the routing domain by setting its age to MaxAge and reflooding the advertisement. This procedure follows the same course as flushing an advertisement whose age has naturally reached the value MaxAge (see Section 14). In particular, the MaxAge advertisement 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 advertisement's age to MaxAge premature aging.
リンク州の広告は、時代の設定のそばの経路ドメインからMaxAgeまで洗い流されて、広告を「再-あふれ」させることができます。 この手順は時代が自然に値のMaxAgeに達した広告を洗い流すのと同じコースに続きます(セクション14を見てください)。 a) それがもうどんな隣人Link州の「再-トランスミッション」リストにも含まれていないとすぐに、特に、ルータのリンク州のデータベースからMaxAge広告を取り除きます、そして、b) ルータの隣人のだれも州のExchangeかLoadingにいません。 私たちは広告の時代の設定をMaxAgeの時期尚早な年をとるのに呼びます。
Premature aging is used when it is time for a self-originated advertisement's sequence number field to wrap. At this point, the current advertisement instance (having LS sequence number of 0x7fffffff) must be prematurely aged and flushed from the routing domain before a new instance with sequence number 0x80000001 can be originated. See Section 12.1.6 for more information.
自己によって溯源された広告の一連番号分野が包装する時間であるとき、時期尚早な年をとるのは使用されています。 ここに、一連番号0x80000001がある新しい例を溯源できる前に、経路ドメインから現在の広告例(0x7fffffffのLS一連番号を持っている)を早まって、熟成して、洗い流さなければなりません。 詳しい情報に関してセクション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 external advertisement from the routing domain via premature aging. This procedure is preferable to the alternative, which is to originate a new advertisement for the destination specifying a metric of LSInfinity.
また、例えば、ルータの以前に広告を出した外部経路の1つがもう届いていないとき、時期尚早な年をとることを使用できます。 この状況では、ルータは時期尚早な年をとることを通して経路ドメインからの外部の広告を洗い流すことができます。 この手順はLSInfinityにおけるメートル法のaを指定する目的地に新しい広告を溯源することである代替手段より望ましいです。
A router may only prematurely age its own (self-originated) link state advertisements. These are the link state advertisements having the router's own OSPF Router ID in the Advertising Router field.
ルータは早まって、それ自身(自己に溯源される)のリンク州の広告に年をとらせるだけであるかもしれません。 これらはAdvertising Router分野にルータの自己のOSPF Router IDを持っているリンク州の広告です。
15. Virtual Links
15. 仮想のリンク
The single backbone area (Area ID = 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 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-
ただ一つの背骨領域(Area ID=0)を外すことができませんか、またはAutonomous Systemのいくつかの領域が手が届かなくなるでしょう。 背骨の接続性を確立するか、または維持するために、非背骨領域を通って仮想のリンクを構成できます。 仮想のリンクは、背骨の別々のコンポーネントを接続するのに役立ちます。 仮想のリンクの2つの終点が境界ルータです。 両方のルータで仮想のリンクを構成しなければなりません。 そして、各ルータにおける設定情報がもう片方の仮想の終点(もう片方の境界ルータ)から成る、非
[Moy] [Page 114] RFC 1247 OSPF Version 2 July 1991
[Moy][114ページ]RFC1247OSPFバージョン1991年7月2日
backbone area the two routers have in common (called the transit area). Virtual links cannot be configured through stub areas (see Section 3.6).
2つのルータが共通である(トランジット領域と呼ばれます)背骨領域。 スタッブ領域を通って仮想のリンクを構成できません(セクション3.6を見てください)。
The virtual link is treated as if it were an unnumbered point-to-point network (belonging to the backbone) 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 links advertisements, and OSPF packets pertaining to the backbone area will flow over the adjacency. Such an adjacency has been referred to as a "virtual adjacency".
仮想のリンクは、まるでそれが無数の二地点間ネットワーク(背骨に属して)であるかのように2つの境界ルータを接合しながら、扱われます。 仮想のリンクの上に隣接番組を確立するのを試みをします。 この隣接番組が確立されるとき、仮想のリンクは背骨ルータリンク広告に含まれるでしょう、そして、背骨領域に関係する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). Actually, there may be a separate routing table entry for each Type of Service. These are called the virtual link's corresponding routing table entries. The Interface Up event occurs for a virtual link when its corresponding TOS 0 routing table entry becomes reachable. Conversely, the Interface Down event occurs when its TOS 0 routing table entry becomes unreachable.[18] 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. The other details concerning virtual links are as follows:
それぞれの終点ルータでは、仮想のリンクの費用と生存力は、もう片方の終点ルータのための経路指定テーブルエントリーを調べることによって、発見されます。 (エントリーの関連地域は構成されたトランジット領域であるに違いありません。) 実際に、Serviceの各Typeのための別々の経路指定テーブルエントリーがあるかもしれません。 これらは仮想のリンクの対応する経路指定テーブルエントリーと呼ばれます。 対応するTOS0経路指定テーブルエントリーが届くようになると、Interface Up出来事は仮想のリンクに起こります。 TOS0経路指定テーブルエントリーが手の届かない.[18]になると、逆に、Interface Down出来事は起こります。言い換えれば、仮想のリンクの生存力はイントラ領域経路の存在で決定します、トランジット領域を通って、2つの終点の間で。 仮想のリンクに関する他の詳細は以下の通りです:
o AS external links are NEVER flooded over virtual adjacencies. This
would be duplication of effort, since the same AS external links are
already flooded throughout the virtual link's transit area. For
this same reason, AS external link advertisements are not summarized
over virtual adjacencies during the database exchange process.
o ASの外部のリンクは仮想の隣接番組の上で決して水につかっていません。 これは努力の複製でしょう、同じASの外部のリンクが仮想のリンクのトランジット領域中で既に水につかっているので。 この同じ理由で、ASの外部のリンク広告はデータベース交換の過程の間、仮想の隣接番組の上へまとめられません。
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 links advertisement should be originated for the backbone
area.
o 仮想のリンクの費用は構成されません。 それは、境界ルータを定義する2つの間のイントラ領域経路の費用になるように定義されます。 この費用は仮想のリンクの対応する経路指定テーブルエントリーに現れます。 仮想のリンク変化の費用、新しいルータがリンクされるとき、広告は背骨領域に溯源されるべきです。
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 protocol packets over the virtual link.
o ちょうど経路指定テーブル成型の過程(もう片方の終点のための経路指定テーブルエントリーの工事による)で仮想のリンクの費用と生存力が決定するように、仮想インターフェースへのIPインターフェース・アドレスと仮想の隣人のIPアドレスもそうです。 仮想のリンクの上にプロトコルパケットを送るとき、これらは使用されています。
o In each endpoint's router links advertisement for the backbone, the
virtual link is represented as a link having link type 4, Link ID
set to the virtual neighbor's OSPF Router ID and Link Data set to
the virtual interface's IP address. See Section 12.4.1 for more
information. Also, it may be the case that there is a TOS 0 path,
o 終点の各ところでは、ルータが背骨のために広告をリンクして、仮想のリンクはリンク型4がいるリンク、仮想の隣人のOSPF Router IDに設定されたLink ID、および仮想インターフェースのIPアドレスに用意ができているLink Dataとして表されます。 詳しい情報に関してセクション12.4.1を見てください。 また、TOS0経路があるのは、事実であるかもしれません。
[Moy] [Page 115] RFC 1247 OSPF Version 2 July 1991
[Moy][115ページ]RFC1247OSPFバージョン1991年7月2日
but no non-zero TOS paths to the other endpoint router. In this
case, non-zero TOS costs must be set to LSInfinity in the router
links advertisement.
しかし、もう片方の終点ルータへの非ゼロTOS経路がありません。 この場合、非ゼロTOSコストはルータにおけるLSInfinityへのセットが広告をリンクするということであるに違いありません。
o When virtual links are configured for the backbone, information
concerning backbone networks should not be condensed before being
summarized for the transit areas. In other words, each backbone
network should be advertised in a separate summary link
advertisement, regardless of the backbone's configured area address
ranges. See Section 12.4.3 for more information.
o 背骨のために仮想のリンクを構成するとき、トランジット領域へまとめる前に背骨ネットワークの情報を凝縮するべきではありません。 言い換えれば、別々の概要リンク広告にそれぞれの背骨ネットワークの広告を出すべきです、背骨の構成された領域のアドレスの範囲にかかわらず。 詳しい情報に関してセクション12.4.3を見てください。
o The time between link state retransmissions, RxmtInterval, is
configured for a virtual link. This should be well over the
expected round-trip delay between the two routers. This may be hard
to estimate for a virtual link. It is better to err on the side of
making it too large.
o リンク州の「再-トランスミッション」の間の時間(RxmtInterval)は仮想のリンクに構成されます。 2つのルータの間には、予想された往復の遅れのかなり上にこれはあるべきです。 これは仮想のリンクに見積もっているのが困難であるかもしれません。 それを大きくし過ぎることの側で間違えるほうがよいです。
16. Calculation Of The Routing Table
16. 経路指定テーブルの計算
This section details the OSPF routing table calculation. Using its attached areas' link state databases as input, a router runs the following algorithm, building its routing table step by step. At each step, the router must access individual pieces of the link state databases (e.g., a router links advertisement originated by a certain router). This access is performed by the lookup function discussed in Section 12.2. The lookup process may return a link state advertisement whose LS age is equal to MaxAge. Such an advertisement should not be used in the routing table calculation, and is treated just as if the lookup process had failed.
このセクションはOSPF経路指定テーブル計算を詳しく述べます。 入力されるように付属領域のリンク州のデータベースを使用して、ルータは以下のアルゴリズムを走らせます、一歩一歩経路指定テーブルを組立てて。 各ステップでは、ルータはリンク州のデータベースの個体にアクセスしなければなりません(例えば、ルータはあるルータによって溯源された広告をリンクします)。 このアクセスはセクション12.2で議論したルックアップ機能によって実行されます。 ルックアップの過程はLS年令がMaxAgeと等しいリンク州の広告を返すかもしれません。 そのような広告を経路指定テーブル計算に使用するべきでなくて、まるでまさしくルックアップの過程が失敗したかのように扱います。
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.
(2) イントラ領域ルートは、それぞれの付属領域に最短パス木を建てることによって、計算されます。 特に、Destinationタイプが「領域境界ルータ」であるすべての経路指定テーブルエントリーがこのステップで計算されます。 このステップは2つの部品で説明されます。 初めに、木は、ルータと輸送網とのそれらのリンクを考えるだけで組み立てられます。 そして、スタッブネットワークは木に組み入れられます。
[Moy] [Page 116] RFC 1247 OSPF Version 2 July 1991
[Moy][116ページ]RFC1247OSPFバージョン1991年7月2日
(3) The inter-area routes are calculated, through examination of summary
link advertisements. If the router is attached to multiple areas
(i.e., it is an area border router), only backbone summary link
advertisements are examined.
(3) 相互領域ルートは概要リンク広告の試験で計算されます。 ルータが複数の領域に付けられるなら(すなわち、それは境界ルータです)、背骨概要リンク広告だけが調べられます。
(4) For those routing entries whose next hop is over a virtual link, a
real (physical) next hop is calculated. The real next hop will be
on one of the router's directly attached networks. This step only
concerns routers having configured virtual links.
(4) 仮想のリンクの上に次のホップがあるそれらのルーティングエントリーにおいて、次の本当(物理的な)のホップは計算されます。 次の本当のホップはルータの直接付属しているネットワークの1つにあるでしょう。 仮想のリンクを構成して、このステップはルータに関係があるだけです。
(5) Routes to external destinations are calculated, through examination
of AS external link advertisements. The location of the AS boundary
routers (which originate the AS external link advertisements) has
been determined in steps 2-4.
(5) 外部の目的地へのルートはASの外部のリンク広告の試験で計算されます。 AS境界ルータ(ASの外部のリンク広告を溯源する)の位置はステップ2-4で断固としています。
Steps 2-5 are explained in further detail below. The explanations describe the calculations for TOS 0 only. It may also be necessary to perform each step (separately) for each of the non-zero TOS values.[19] For more information concerning the building of non-zero TOS routes see Section 16.9.
ステップ2-5は以下の詳細で説明されます。 説明はTOS0だけのために計算について説明します。 また、それぞれの非ゼロのために(別々に)各ステップを実行するために、非ゼロTOSのビルに関する詳しい情報のための.[19]が発送するTOS値がセクション16.9を見るのも必要であるかもしれません。
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 link advertisements (see Section 12.4). See Section 16.7 for a complete list of the OSPF protocol actions resulting from routing table table changes.
これらの計算の結果、経路指定テーブルエントリーにされた変更で、OSPFプロトコルはさらなる行動を取ることができます。 例えば、イントラ領域ルートへの変化で、境界ルータは新しい概要リンク広告を溯源するでしょう(セクション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.[20] The formation of the shortest path tree is done here in two stages. In the first stage, only links between routers and transit networks are considered. Using the Dijkstra algorithm, a tree is formed from this subset of the link state database. In the second stage, leaves are added to the tree by considering the links to stub networks.
この計算は領域(今後、Area Aと呼ぶ)に関連しているイントラ領域ルートのセットをもたらします。 ルータは、最短パス木の構成がここ、2つの段階で行われる根の.[20]としてそれ自体を使用することで最短パス木について計算します。 第一段階では、ルータと輸送網とのリンクだけが考えられます。 ダイクストラアルゴリズムを使用して、木はリンク州のデータベースのこの部分集合から形成されます。 2番目の段階では、リンクがネットワークを引き抜くと考えることによって、葉は木に加えられます。
The procedure will be explained using the graph terminology that was introduced in Section 2. The area's link state database is represented as a directed graph. The graph's vertices are routers, transit networks and stub networks. The first stage of the procedure concerns only the transit vertices (routers and transit networks) and their connecting links. Throughout the shortest path calculation, the following data is also associated with each transit vertex:
手順は、セクション2で紹介されたグラフ用語を使用することで説明されるでしょう。 領域のリンク州のデータベースは有向グラフとして表されます。 グラフの頭頂は、ルータと、輸送網とスタッブネットワークです。 手順の第一段階はトランジット頭頂(ルータと輸送網)とそれらの結合リンクだけに関係があります。 また、最短パス計算の間中、以下のデータもそれぞれのトランジット頂点に関連しています:
[Moy] [Page 117] RFC 1247 OSPF Version 2 July 1991
[Moy][117ページ]RFC1247OSPFバージョン1991年7月2日
Vertex (node) ID
A 32-bit number uniquely identifying the vertex. For router
vertices this is the OSPF Router ID. For network vertices, this is
the IP address of the network's Designated Router.
唯一頂点を特定する頂点の(ノード)IDのA32ビットの番号。 ルータ頭頂に関しては、これはOSPF Router IDです。 ネットワーク頭頂に関しては、これはネットワークのDesignated RouterのIPアドレスです。
A link state advertisement
Each transit vertex has an associated link state advertisement. For
router vertices, this is a router links advertisement. For transit
networks, this is a network links advertisement (which is actually
originated by the network's Designated Router). In any case, the
advertisement's Link State ID is always equal to the above Vertex
ID.
リンク州の広告Eachトランジット頂点は関連リンク州の広告を出しています。 ルータ頭頂に関しては、これはルータリンク広告です。 輸送網において、これはネットワークリンク広告(実際にネットワークのDesignated Routerによって溯源される)です。 どのような場合でも、広告のLink州IDはいつも上のVertex IDと等しいです。
List of next hops
The list of next hops for the current 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 multi-access networks, the next hop also includes
the IP address of the next router (if any) in the path towards the
destination.
次のリストは現在の最短パスのために根からこの頂点まで次のホップのリストを飛び越します。 等価コストマルチパス能力への複数の最短パス支払われるべきものがあることができます。 次の各ホップは交通を目的地に送るとき使用する外向的なルータインタフェースを示します。 また、マルチアクセスネットワークでは、次のホップは経路で次のルータ(もしあれば)のIPアドレスを目的地に向かって含めます。
Distance from root
The link state cost of the current shortest path(s) 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 links and network links advertisements). One path is said to
be "shorter" than another if it has a smaller link state cost.
根から、現在の最短パスのリンク州の費用を根から頂点まで遠ざけてください。 経路の成分のコストの合計がリンクされるとき(ルータリンクとネットワークリンク広告の広告に掲載されているように)、経路のリンク州の費用は計算されます。 それによりわずかなリンク州の費用があるなら、1つの経路が「別のものより短い」と言われます。
The first stage of the procedure can now be summarized as follows. At each iteration of the algorithm, there is a list of candidate vertices. The shortest paths from the root to these vertices have not (necessarily) been found. The candidate vertex closest to the root 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 first stage in detail. Remember that we are computing the shortest path tree for Area A. All references to link state database lookup below are from Area A's database.
以下のステップは詳細に第一段階について説明します。 私たちがArea A.のために最短パス木を計算しているのを覚えていてください。以下の州のデータベースルックアップをリンクするAll参照はArea Aのデータベースから来ています。
(1) Initialize the algorithm's data structures. Clear the list of
candidate vertices. Initialize the shortest-path tree to only the
root (which is the router doing the calculation).
(1) アルゴリズムのデータ構造を初期化してください。 候補頭頂をリストから取り除いてください。 根(計算をするルータである)だけに最短パス木を初期化してください。
[Moy] [Page 118] RFC 1247 OSPF Version 2 July 1991
[Moy][118ページ]RFC1247OSPFバージョン1991年7月2日
(2) Call the vertex just added to the tree vertex V. Examine the link
state advertisement associated with vertex V. This is a lookup in
the area link state database based on the Vertex ID. Each link
described by the advertisement gives the cost to an adjacent vertex.
For each described link, (say it joins vertex V to vertex W):
(2) 頂点がただリンク州の広告が頂点V.Thisに関連づけた木の頂点V.Examineに加えた呼び出しはVertex IDに基づく領域リンク州のデータベースのルックアップです。 広告で説明された各リンクは隣接している頂点への費用を与えます。 説明されたそれぞれに関してはリンクしてください、(頂点Vを頂点Wに接合すると言います):
(a) If this is a link to a stub network, examine the next link in
V's advertisement. Links to stub networks will be considered in
the second stage of the shortest path calculation.
(a) これがスタッブネットワークへのリンクであるなら、Vで次のリンクを調べてください。広告。 ネットワークを引き抜くリンクは最短パス計算の2番目の段階で考えられるでしょう。
(b) Otherwise, W is a transit vertex (router or transit network).
Look up the vertex W's link state advertisement (router links or
network links) in Area A's link state database. If the
advertisement does not exist, or its age is equal to MaxAge, or
it does not have a link back to vertex V, examine the next link
in V's advertisement. Both ends of a link must advertise the
link before it will be used for data traffic.[21]
(b) さもなければ、Wはトランジット頂点(ルータかトランジットネットワーク)です。 Area Aのリンク州のデータベースにおける頂点Wのリンク州の広告(ルータリンクかネットワークリンク)を見上げてください。 広告が存在していないか、年令がMaxAgeと等しいか、または頂点Vにリンクを返してもらわないなら、次のリンクを試験してください、V、広告 それがデータ通信量に使用される前にリンクの両端はリンクの広告を出さなければなりません。[21]
(c) If vertex W is already on the shortest-path tree, examine the
next link in the advertisement.
(c) 最短パス木の上に頂点Wが既にあるなら、広告で次のリンクを調べてください。
(d) If the cost of the link (from V to W) is LSInfinity, the link
should not be used for data traffic. In this case, examine the
next link in the advertisement.
(d) リンク(VからWまでの)の費用がLSInfinityであるなら、データ通信量にリンクを使用するべきではありません。 この場合、広告で次のリンクを調べてください。
(e) 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:
(e) 結果として起こる根から頂点W.Dまでの経路のリンク州の費用Dが頂点Vへの(既に計算されています)の最短パスのリンク州の費用と頭頂Vの間のリンクの広告を出している費用の合計と等しく、W.If Dは以下の通りであると見込んでください。
o Greater than the value that already appears for vertex W on
the candidate list, then examine the next link.
o 候補リストで既に頂点Wの弁護に出廷する値よりすばらしくて、そして、次のリンクを調べてください。
o Equal to the value that appears for vertex W on the 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 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
o 候補リストで頂点Wの弁護に出廷する値よりそれほど、またはWが候補リストにまだ現れていないなら、根からDの距離に示す候補リストにWのためのエントリーを設定してください。 また、広告を出しているリンクを使用するので、結果として生じる次のホップのリストについて計算してください、それに従って、次のホップ値をWに設定して。 次のホップ計算はセクション16.1.1で説明されます。 それ
[Moy] [Page 119] RFC 1247 OSPF Version 2 July 1991
[Moy][119ページ]RFC1247OSPFバージョン1991年7月2日
takes as input the destination (W) and its parent (V).
目的地(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 algorithm 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).
(3) 候補リストがこのステップで空であるなら、最短パス木(トランジット頭頂の)は完全に建てられました、そして、アルゴリズムのこのステージは終わります。 さもなければ、根の最も近くにある候補リストに属す頂点を選んでください、そして、最短パス木(過程による候補リストからそれを取り除く)にそれを加えてください。
(4) Possibly modify the routing table. For those routing table entries
modified, the associated area will be set to Area A, the path type
will be set to intra-area, and the cost will be set to the newly
discovered shortest path's calculated distance.
(4) ことによると経路指定テーブルを変更してください。 エントリーが変更したテーブルを発送するものにおいて、関連領域はArea Aに設定されて、経路タイプはイントラ領域に用意ができて、費用は新たに発見された最短パスの計算された距離に設定されるでしょう。
If the newly added vertex is an area border router, a routing table
entry is added whose destination type is "area border router". The
Options field found in the associated router links advertisement is
copied into the routing table entry's Optional capabilities field.
新たに加えられた頂点が境界ルータであるなら、目的地タイプが「領域境界ルータ」である経路指定テーブルエントリーは加えられます。 Options分野によって、関連ルータリンクで広告が経路指定テーブルエントリーのOptional能力分野にコピーされるのがわかりました。
If the newly added vertex is an AS boundary router, the routing
table entry of type "AS boundary router" for the destination is
located. Since routers can belong to more than one area, it is
possible that several sets of intra-area paths exist to the AS
boundary router, each set using a different area. However, the AS
boundary router's routing table entry must indicate a set of paths
which utilize a single area. The area leading to the routing table
entry is selected as follows: A set of intra-area paths having no
virtual next hops is always preferred over a set of intra-area paths
in which some virtual next hops appear[22] ; all other things being
equal the set of paths having lower cost is preferred. Note that
whenever an AS boundary router's routing table entry is
added/modified, the Options found in the associated router links
advertisement is copied into the routing table entry's Optional
capabilities field.
新たに加えられた頂点がAS境界ルータであるなら、目的地へのタイプ「AS境界ルータ」の経路指定テーブルエントリーは見つけられています。 ルータが1つ以上の領域に属すことができるので、数セットのイントラ領域経路がAS境界ルータに存在するのは、可能です、異なった領域を使用するように設定されたそれぞれ。 しかしながら、AS境界ルータの経路指定テーブルエントリーはただ一つの領域を利用する1セットの経路を示さなければなりません。 経路指定テーブルエントリーに通じる領域は以下の通り選択されます: 次のどんな仮想のホップも持っていない1セットのイントラ領域経路は次のいくつかの仮想のホップが[22]に見える1セットのイントラ領域経路にわたっていつも好まれます。 低い費用を持っている経路のセットと等しいことである他のすべてのものが好まれます。 AS境界ルータの経路指定テーブルエントリーが加えられるか変更されているときはいつも、Optionsが、関連ルータリンクで広告が経路指定テーブルエントリーのOptional能力分野にコピーされるのがわかったことに注意してください。
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
associated network links advertisement). 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' link state advertisement.
新たに加えられた頂点がトランジットネットワークであるなら、ネットワークのための経路指定テーブルエントリーは見つけられています。 エントリーの目的地IDはIPネットワーク・ナンバーです。(関連サブネットマスク(関連では、ネットワークが広告をリンクするのがわかる)でVertex ID(リンク州ID)にマスクをかけることによって、そのネットワーク・ナンバーを得ることができます)。 経路指定テーブルエントリーが既に存在しているなら(すなわち、既に、経路指定テーブルにインストールされた目的地へのイントラ領域ルートがあります)、複数の頭頂が同じIPにネットワークを写像しました。 新しいDesignated Routerが設立されているとき、例えば、これは起こることができます。 そして、'この場合現在の経路指定テーブルエントリーが上書きされるべきである、'新たに見つけられた経路がちょうど同じくらい短く、現在の経路指定テーブルエントリーのLink州Originに新たに加えられた頂点より小さいLink州IDがある場合にだけ、州の広告をリンクしてください。
[Moy] [Page 120] RFC 1247 OSPF Version 2 July 1991
[Moy][120ページ]RFC1247OSPFバージョン1991年7月2日
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' link state advertisement.
ネットワーク(普通のケース)のための経路指定テーブルエントリーが全くなければ、IPネットワークのための経路指定テーブルエントリーは加えられるべきです。 '経路指定テーブルエントリー'のLink州の起源は新たに加えられた'リンク州の頂点広告に設定されるべきです。
(5) Iterate the algorithm by returning to Step 2.
(5) Step2に戻ることによって、アルゴリズムを繰り返してください。
The stub networks are added to the tree in the procedure's second stage. In this stage, all router vertices are again examined. Those that have been determined to be unreachable in the above first phase are discarded. For each reachable router vertex (call it V), the associated router links advertisement is found in the link state database. Each stub network link appearing in the advertisement is then examined, and the following steps are executed:
スタッブネットワークはプロシージャの2番目の段階の木に加えられます。 この段階では、すべてのルータ頭頂が再び調べられます。 上の第1段階で手が届かないと決心しているものは捨てられます。 それぞれの届いているルータ頂点(それをVと呼ぶ)、広告がリンク州のデータベースで見つけられる関連ルータリンクに。 次に、広告に現れるそれぞれのスタッブネットワークリンクは調べられます、そして、以下のステップは実行されます:
(1) If the cost of the stub network link is LSInfinity, the link should
not be used for data traffic. In this case, go on to examine the
next stub network link in the advertisement.
(1) スタッブネットワークリンクの費用がLSInfinityであるなら、データ通信量にリンクを使用するべきではありません。 この場合、広告で次のスタッブネットワークリンクを調べ続けてください。
(2) Otherwise, 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 network's current routing
table entry. If the calculated distance D is larger, go on to
examine the next stub network link in the advertisement.
(2) そうでなければ、根からのスタッブネットワークの距離DのCalculate。 Dはルータ頂点(段階1では、計算される)、および根から広告を出しているスタッブネットワークリンクの費用まで距離と等しいです。 スタッブネットワークへの現在の最も良い費用にこの距離をたとえてください。 ネットワークの現在の経路指定テーブルエントリーを見上げることによって、これをします。 計算された距離Dが、より大きいなら、広告で次のスタッブネットワークリンクを調べ続けてください。
(3) 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 links advertisement whose Link
State ID is smaller than V's Router ID, reset the Link State origin
to V's router links advertisement.
(3) このステップに達しているなら、スタッブネットワークの経路指定テーブルエントリーをアップデートしなければなりません。 スタッブネットワークリンクを使用するので、結果として生じる次のホップのセットについて計算してください。 この計算はセクション16.1.1で示されます。 この計算に入力されているのは、目的地(スタッブネットワーク)と親頂点(ルータ頂点)です。 距離Dが現在の経路指定テーブル費用と同じであるなら、単に経路指定テーブルエントリーの次のホップのリストにこのセットの次のホップを追加してください。 この場合、経路指定テーブルには、Link州の起源が既にあります。 ルータはこのLink州の起源がそうならLink州IDがV Router IDより小さい広告をリンクして、Link州の起源をVにリセットしてください。ルータリンク広告。
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 links advertisement. Then go on to examine the next stub
network link.
さもなければ、Dは経路指定テーブル費用より小さいです。 経路指定テーブルエントリーの費用をDに設定して、エントリーの次のホップのリストを新たに計算されたセットに設定することによって、現在の経路指定テーブルエントリーを上書きしてください。 ルーティングテーブル項目のLink州の起源をVに設定してください。ルータリンク広告。 そして、次のスタッブネットワークリンクを調べ続けてください。
[Moy] [Page 121] RFC 1247 OSPF Version 2 July 1991
[Moy][121ページ]RFC1247OSPFバージョン1991年7月2日
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 links is exhausted, the second stage is completed. At this time, all intra-area routes associated with Area A have been determined.
2番目の段階で加えられるか、または変更されたすべての経路指定テーブルエントリーにおいて関連領域はArea Aに設定されるでしょう、そして、経路タイプはイントラ領域に用意ができるでしょう。 届いているルータリンクのリストが空になるとき、2番目のステージは完成します。 このとき、Area Aに関連しているすべてのイントラ領域ルートが決定しています。
The specification does not require that the above two stage method be used to calculate the shortest path tree. However, if another algorithm is used, an identical tree must be produced. For this reason, it is important to note that links between transit vertices must be bidirectional in ordered to be included in the above tree. It should also be mentioned that algorithms exist for incrementally updating the shortest-path tree (see [BBN]).
仕様は、上の2ステージ方法が最短パス木について計算するのに使用されるのを必要としません。 しかしながら、別のアルゴリズムが使用されているなら、同じ木を生産しなければなりません。 この理由で、トランジット頭頂の間のリンクが上の木に含まれるように命令されるところで双方向でなければならないことに注意するのは重要です。 また、アルゴリズムが最短パス木を増加してアップデートするために存在する([BBN]を見る)と言及されるべきです。
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 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 2e of Stage 1). In stage 2 a shorter path is discovered each time the destination's routing table entry is modified (Step 3 of Stage 2).
このセクションは目的地に使用する現在のセットの次のホップについて計算する方法を説明します。 次の各ホップは次のホップルータ(もしあれば)と共に推進パケットで目的地に使用する外向的なインタフェースから成ります。 目的地への、より短い経路が発見されるたびに次のホップ計算は呼び出されます。 これは最短パス木の計算のどちらの段階でも起こることができます(セクション16.1を見てください)。 最短パス木の計算の段階1では、目的地が候補リストに追加されるとき、より短い経路は見つけられて、候補リストの上の目的地のエントリーがいつ変更されているかを(Stage1のステップ2e)そうされます。 段階2では、目的地の経路指定テーブルエントリーが変更されているたびに(Stage2のステップ3)より短い経路は発見されます。
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 next hop in this case is simply the OSPF interface connecting to the network/router; no next hop router is required.
目的地と根の間には、現在の最短パスに少なくとも1つの介入しているルータがあれば、目的地は親から次のホップのセットを単に引き継ぎます。 さもなければ、2つのケースがあります。 前者の場合、親頂点は根(計算のルータ自体)です。 これは、目的地が直接接続されたネットワークか直接接続されたルータのどちらかであることを意味します。 この場合、次のホップは単にネットワーク/ルータに接続するOSPFインタフェースです。 次のホップルータは全く必要ではありません。
[Moy] [Page 122] RFC 1247 OSPF Version 2 July 1991
[Moy][122ページ]RFC1247OSPFバージョン1991年7月2日
In the second case, the destination is a router, and its parent vertex is a network. The list of next hops is then determined by examining the destination's router links advertisement. For each link in the advertisement 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番目の場合では、目的地はルータです、そして、親頂点はネットワークです。 目的地のルータを調べることによって、広告をリンクします次に、次のホップのリストが決定している。 親ネットワークを示す広告における各リンクに、リンクのLink Data分野は次のホップルータのIPアドレスを供給します。 そして、次のホップIPアドレスから使用する外向的なインタフェースを得ることができます(親ネットワークからそれを引き継ぐことができます)。
16.2 Calculating the inter-area routes
16.2 相互領域ルートを計算すること。
The inter-area routes are calculated by examining summary link advertisements. If the router has active attachments to multiple areas, only backbone summary link advertisements are examined. Routers attached to a single area examine that area's summary links. In either case, the summary links examined below are all part of a single area's link state database (call it Area A).
相互領域ルートは、概要リンク広告を調べることによって、計算されます。 ルータが複数の領域にアクティブな付属を持っているなら、背骨概要リンク広告だけが調べられます。 ただ一つの領域に付けられたルータはその領域の概要リンクを調べます。 どちらかの場合では、以下で調べられた概要リンクはすべてただ一つの領域のリンク州のデータベースの一部(それをArea Aと呼ぶ)です。
Summary link advertisements are originated by the area border routers. Each summary link advertisement in Area A is considered in turn. Remember that the destination described by a summary link advertisement is either a network (type 3 summary link advertisements) or an AS boundary router (type 4 summary link advertisements). For each summary link advertisement:
概要リンク広告は境界ルータによって溯源されます。 Area Aでのそれぞれの概要リンク広告は順番に考えられます。 概要リンク広告で説明された目的地がネットワーク(3つの概要リンク広告をタイプする)かAS境界ルータのどちらかであることを覚えていてください(4つの概要リンク広告をタイプしてください)。 各概要に関しては、広告をリンクしてください:
(1) If the cost specified by the advertisement is LSInfinity, then
examine the next advertisement.
(1) 広告で指定された費用がLSInfinityであるなら、次の広告を調べてください。
(2) If the advertisement was originated by the calculating router
itself, examine the next advertisement.
(2) 広告が計算のルータ自体によって溯源されたなら、次の広告を調べてください。
(3) If the collection of destinations described by the summary link
falls into one of the router's configured area address ranges (see
Section 3.5) and the particular area address range is active, the
summary link should be ignored. Active means that there are one or
more reachable (by intra-area paths) networks contained in the area
range. In this case, all addresses in the area range are assumed to
be either reachable via intra-area paths, or else to be unreachable
by any other means.
(3) 概要リンクによって説明された目的地の収集がルータの構成された領域のアドレスの範囲の1つになって(セクション3.5を見てください)、特定の領域のアドレスの範囲がアクティブであるなら、概要リンクは無視されるべきです。 含まれた1つ以上の届いている(イントラ領域経路のそばの)ネットワークが領域の範囲にあるアクティブな手段。 この場合、イントラ領域経路を通して届くか、または領域の範囲のすべてのアドレスがいかなる他の手段でも手が届かないと思われます。
(4) Else, call the destination described by the advertisement N, and the
area border originating the advertisement BR. Look up the routing
table entry for BR having 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 advertisement and consider the next in the list.
Else, this advertisement describes an inter-area path to destination
N, whose cost is the distance to BR plus the cost specified in the
(4) ほかに、広告Nで説明された目的地、および広告BRを溯源する領域の境界に電話をしてください。 関連領域としてAを持っているBRのために経路指定テーブルエントリーを見上げてください。 どれかそのようなエントリーがルータBRのために存在しないなら(すなわち、BRはArea Aで手が届きません)、この広告で何もしないでください、そして、リストの次を考えてください。 ほかに、この広告は相互領域経路について目的地Nに説明します、とだれの費用がBRへの距離であるか、そして、費用は指定しました。
[Moy] [Page 123] RFC 1247 OSPF Version 2 July 1991
[Moy][123ページ]RFC1247OSPFバージョン1991年7月2日
advertisement. Call the cost of this inter-area path IAC.
広告。 IACにこの相互領域経路の費用に電話をしてください。
(5) Next, look up the routing table entry for the destination N. (The
entry's Destination type is either Network or AS boundary router.)
If no entry exists for N or if the entry's path type is "AS
external", install the inter-area path to N, with associated area A,
cost IAC, next hop equal to the list of next hops to router BR, and
advertising router equal to BR.
(5) 次に、目的地N.のための経路指定テーブルエントリーを見上げてください。(エントリーのDestinationタイプは、NetworkかAS境界ルータのどちらかです。) エントリーが全くNのために存在していないか、またはエントリーの経路タイプが「AS外部である」なら、相互領域経路を次にのリストと等しい次のホップが関連領域A、費用IACと共にBRと等しいルータBR、および広告ルータに飛び越すNまでインストールしてください。
(6) Else, if the paths present in the table are intra-area paths, do
nothing with the advertisement (intra-area paths are always
preferred).
(6) ほかに、テーブルの現在の経路がイントラ領域経路であるなら、広告で何もしないでください(イントラ領域経路はいつも好まれます)。
(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 Resolving virtual next hops
16.3 次の仮想のホップを決議すること。
This step is only necessary in area-border routers having configured virtual links. In these routers, some of the routing table entries may have virtual next hops. That is, one or more of the next hops installed in Sections 16.1 and 16.2 may be over a virtual link. However, when forwarding data traffic to a destination, the next hops must always be on a directly attached network.
仮想のリンクを構成して、このステップが領域境界ルータだけで必要です。 これらのルータでは、経路指定テーブルエントリーのいくつかが次の仮想のホップを持っているかもしれません。 仮想のリンクの上にすなわち、セクション16.1と16.2にインストールされた次のホップの1つ以上があるかもしれません。 しかしながら、データ通信量を目的地に送るとき、次のホップが直接付属しているネットワークにいつもあるに違いありません。
In this section, each virtual next hop is replaced by a real next hop. In the process a new routing table distance is calculated that may be smaller than the previously calculated distance. In this case, the list of next hops is pruned so that only those giving rise to the new shortest distance are included, and the routing table entry's distance is updated accordingly.
このセクションでは、次のそれぞれの仮想のホップを次の本当のホップに取り替えます。 過程で、以前に計算された距離よりわずかであるかもしれない新しい経路指定テーブル距離は計算されます。 この場合次のホップのリストが剪定されるので、新しい最短距離をもたらすものだけが含んでいます、そして、それに従って、経路指定テーブルエントリーの距離をアップデートします。
______________________________________
______________________________________
(Figure not included in text version.)
(テキストバージョンに含まれていなかった図。)
Figure 17: Resolving virtual next hops
______________________________________
図17: 次の仮想のホップを決議します。______________________________________
[Moy] [Page 124] RFC 1247 OSPF Version 2 July 1991
[Moy][124ページ]RFC1247OSPFバージョン1991年7月2日
This resolution of virtual next hops is done only for Destination types Network or AS Boundary router. Suppose that one of a routing table entry's next hops is a virtual link. This is determined by the following combination: the routing table entry's path type is either intra-area or inter-area, the area associated with the routing table entry must be the backbone, yet the next hop belongs to a different area (the virtual link's transit area).
DestinationタイプNetworkかAS Boundaryルータのためだけに次の仮想のホップのこの解決をします。 経路指定テーブルエントリーの次のホップの1つが仮想のリンクであると仮定してください。 これは以下の組み合わせで決定します: 経路指定テーブルエントリーの経路タイプがイントラ領域か相互領域のどちらかである、経路指定テーブルエントリーに関連している領域が背骨であるに違いない、しかし、次のホップは異なった領域(仮想のリンクのトランジット領域)に属します。
Let N be the above entry's destination, and A the virtual link's transit area. The real next hop (and new distance) is calculated as follows. Let D be a distance counter, and set the real next hop NH to null. Then, look up all the summary link advertisements for N in area A's database, performing the following steps for each advertisement:[23]
上のエントリーのもの目的地、およびAが仮想のリンクのトランジット領域であったならNをさせてください。 次の本当のホップ(そして、新しい距離)は以下の通り計算されます。 Dが距離カウンタであることをさせてください、そして、次の本当のホップニューハンプシャーをヌルに設定してください。 次に、Nのために領域Aのデータベースですべての概要リンク広告を見上げてください、各広告のための以下のステップを実行して:[23]
(1) Call the border router that originated the advertisement BR. If
there is no routing table entry for BR having A as associated area
(i.e., BR is unreachable through Area A), examine the next
advertisement.
(1) BRに広告を溯源した境界ルータに電話をしてください。 関連領域としてAを持っているBRのための経路指定テーブルエントリーが全くなければ(すなわち、BRはArea Aを通して手が届きません)、次の広告を調べてください。
(2) Else, let X be the distance to BR via Area A. If the cost
advertised by BR (call it Y) to the destination is LSInfinity,
examine the next summary link advertisement. Else, the cost to
destination N through area border router BR is X+Y.
(2) ほかに、XによるBR(それをYと呼ぶ)で費用が目的地に広告を出したArea A.Ifを通したBRへの距離がLSInfinityであるということであることをさせてください、そして、次の概要リンク広告を調べてください。 ほかに、領域境界ルータBRを通した目的地Nへの費用はX+Yです。
(3) If next hop NH is null or X+Y is smaller is smaller than D, set D to
X+Y and set the next hop NH to the next hop specified in router BR's
routing table entry.
(3) 次のホップニューハンプシャーがヌルである、またはD、X+YへのセットDより小さく、設定されて、X+Yが、より小さいなら、次のホップへの次のホップニューハンプシャーはルータでBRの経路指定テーブルエントリーを指定しました。
At this point, the real next hop NH should be set, and the distance D calculated should be less than or equal to the cost originally specified in destination N's routing table entry. This same calculation should be done for all of N's virtual next hops, and then N's new cost set to the minimum calculated distance, with the its new set of next hops that combination of non-virtual and recalculated next hops that correspond to this (possibly same as original) distance.
ここに、次の本当のホップニューハンプシャーは設定されるべきです、そして、Dが計算した距離は元々目的地Nの経路指定テーブルエントリーで指定されたより費用以下であるべきです。 Nの次の仮想のホップのすべてのためにこの同じ計算をするべきであり、次に、Nの新しい費用が最小の計算された距離にセットした、非仮想で次に再計算されることの組み合わせが飛び越すこの(ことによるとオリジナルと同じ)距離に対応する新しいセットの次のホップ。
The resolving of virtual next hops may produce unexpected results. After the virtual next hops are resolved, traffic that was originally scheduled to go over the virtual link may instead take a different path through the virtual link's transit area. 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.
次の仮想のホップの決議は予期しなかった結果を生産するかもしれません。 次の仮想のホップが決議された後に、元々仮想のリンクを調べる予定であった交通は代わりに仮想のリンクのトランジット領域を通って異なった経路を取るかもしれません。 言い換えれば、仮想のリンクは、トランジット交通が領域を通って進められるのを許容しますが、交通が取る正確な経路を書き取りません。
As an example, 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
例と、図17に描写されたAutonomous Systemを考えてください。 物理的に背骨を2つの別々の断片に分割するただ一つの非背骨領域(領域1)があります。 接続性を維持します。
[Moy] [Page 125] RFC 1247 OSPF Version 2 July 1991
[Moy][125ページ]RFC1247OSPFバージョン1991年7月2日
backbone, a virtual link has been configured between routers RT1 and RT4. On the right side of the figure, network N1 belongs to the backbone. The dotted lines indicate that there is a much shorter intra-area backbone path between router RT5 and network N1 (cost 20) than there is between router RT4 and network N1 (cost 100). Both router RT4 and router RT5 will inject summary link advertisements for network N1 into Area 1.
背骨、仮想のリンクはルータのRT1とRT4の間で構成されました。 図の右側では、ネットワークN1が背骨に属します。 点線は、ルータRT4とネットワークN1の間には、あるよりルータRT5とネットワークN1の間には、はるかに短いイントラ領域背骨経路があるのを示します(20かかってください)(100かかってください)。 ルータRT4とルータRT5の両方がネットワークN1のための概要リンク広告をArea1に注ぐでしょう。
After the shortest-path tree has been calculated for the backbone, router RT1 (one end of the virtual link) will have selected router RT4 as the virtual next hop 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 resolving the virtual next hop by the above calculation, router RT1 will also forward network N1 traffic towards RT5. So, in this example the virtual link enables network N1 traffic to be forwarded through the transit Area 1, but the actual path the data traffic takes does not follow the virtual link.
最短パス木が背骨のために計算された後に、すべてのデータ通信量への次の仮想のホップがネットワークN1のために運命づけられて、ルータRT1(仮想のリンクの片端)はルータRT4を選択してしまうでしょう。 しかしながら、したがって、ルータRT5がネットワークN1にはるかに近いので、Area1(例えば、ルータのRT2とRT3)への内部のすべてのルータがそれらのネットワークN1交通をルータRT5に向かって送るでしょう、RT4の代わりに。 本当に、そして、また、上の計算で次の仮想のホップを決議した後に、ルータRT1はネットワークN1交通をRT5に向かって送るでしょう。 それで、この例では、仮想のリンクは、ネットワークN1交通がトランジットArea1で進められるのを可能にしますが、データ通信量が取る実際の経路は仮想のリンクに続きません。
16.4 Calculating AS external routes
16.4 計算のAS外部経路
AS external routes are calculated by examining AS external link advertisements. Each of the AS external link advertisements is considered in turn. Most AS external advertisements describe routes to specific IP destinations. An AS external advertisement can also describe a default route for the Autonomous System (destination = DefaultDestination). For each AS external link advertisement:
AS外部経路は、ASの外部のリンク広告を調べることによって、計算されます。 それぞれのASの外部のリンク広告は順番に考えられます。 ほとんどのASの外部の広告が特定のIPの目的地にルートを説明します。 また、ASの外部の広告はAutonomous System(目的地=DefaultDestination)のためにデフォルトルートを説明できます。 それぞれのASの外部のリンク広告のために:
(1) If the cost specified by the advertisement is LSInfinity, then
examine the next advertisement.
(1) 広告で指定された費用がLSInfinityであるなら、次の広告を調べてください。
(2) If the advertisement was originated by the calculating router
itself, examine the next advertisement.
(2) 広告が計算のルータ自体によって溯源されたなら、次の広告を調べてください。
(3) Call the destination described by the advertisement N. Look up the
routing table entry for the AS boundary router (ASBR) that
originated the advertisement. If no entry exists for router ASBR
(i.e., ASBR is unreachable), do nothing with this advertisement and
consider the next in the list.
(3) 広告N.で説明された目的地に電話をしてください。広告を溯源したAS境界ルータ(ASBR)のための経路指定テーブルエントリーにほら。 エントリーが全くルータASBRのために存在しないなら(すなわち、ASBRは手が届きません)、この広告で何もしないでください、そして、リストの次を考えてください。
Else, this advertisement describes an AS external path to
destination N. Examine the forwarding address specified in the
external advertisement. This indicates the IP address to which
packets for the destination should be forwarded. If forwarding
address is set to 0.0.0.0, packets should be sent to the ASBR
ほかに、この広告はフォーワーディング・アドレスが外部の広告で指定した目的地N.ExamineにASの外部の経路について説明します。 これは目的地へのパケットが送られるべきであるIPアドレスを示します。 フォーワーディング・アドレスが0.0に.0を設定することであるなら、.0、パケットをASBRに送るべきです。
[Moy] [Page 126] RFC 1247 OSPF Version 2 July 1991
[Moy][126ページ]RFC1247OSPFバージョン1991年7月2日
itself. Otherwise, look up the forwarding address in the routing
table.[24] An intra-area or inter-area path must exist to the
forwarding address. If no such path exists, do nothing with the
advertisement and consider the next in the list.
それ自体。 さもなければ、経路指定テーブル.[24]のフォーワーディング・アドレスを調べてください。イントラ領域か相互領域経路はフォーワーディング・アドレスに存在しなければなりません。 何かそのような経路が存在しないなら、広告で何もしないでください、そして、リストの次を考えてください。
Call the routing table distance to the forwarding address X (when
the forwarding address is set to 0.0.0.0, this is the distance to
the ASBR itself), and the cost specified in the advertisement Y. X
is in terms of the link state metric, and Y is a Type 1 or 2
external metric.
Xにフォーワーディング・アドレスへの経路指定テーブル距離に電話をしてください、(フォーワーディング・アドレスであるときに、0.0へのセットが.0である、.0、これがASBR自身への距離である、)、リンク状態では、広告Y.Xで指定された費用はメートル法であり、Yはa Type1か2外部メートル法です。
(4) Next, 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 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.
(4) 次に、目的地N.Ifにルーティングテーブル項目を見上げてください。エントリーは全くNのために存在しないで、ASの外部の経路をNにインストールしてください、ASBRと等しいフォーワーディング・アドレス、および広告ルータへの次のホップのリストと等しい次のホップで。 外部のメートル法のタイプが1歳であるなら、経路タイプは1つの外部をタイプするように用意ができています、そして、費用はX+Yと等しいです。 外部のメートル法のタイプが2歳であるなら、経路タイプは2外部をタイプするように用意ができています、そして、ルートの費用のリンク州の部品はXです、そして、Type2費用はYです。
(5) Else, if the paths present in the table are not type 1 or type 2
external paths, do nothing (AS external paths have the lowest
priority).
(5) テーブルの現在の経路がタイプ1でない2つの外部の経路をタイプするなら、ほかに、何もしないでください(ASの外部の経路には、最も低い優先度があります)。
(6) Otherwise, compare the cost of this new AS external path to the ones
present in the table. Type 1 external paths are always shorter than
Type 2 external paths. 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 are compared
by looking at the advertised Type 2 metrics, and then if necessary,
the distance to the forwarding addresses.
(6) さもなければ、この新しいAS外部の経路の費用をテーブルのもの現在にたとえてください。 タイプ1の外部の道はType2の外部の経路よりいつも短いです。 1の外部の経路がフォーワーディング・アドレスと広告を出しているType1への距離の合計をメートル法であるとして見ながら比較されるタイプ(X+Y)。 2つの外部の経路が2つの測定基準は広告を出しているTypeを見て、次に、必要ならフォーワーディング・アドレスへの距離を見ながら比較されるタイプ。
If the new path is shorter, it replaces the present paths in the
routing table entry. If the new path is the same cost, it is added
to the routing table entry's list of paths.
新しい経路が、より短いなら、それは経路指定テーブルエントリーで現在の経路を取り替えます。 新しい経路が同じ費用であるなら、それは経路指定テーブルエントリーの経路のリストに追加されます。
16.5 Incremental updates --- summary links
16.5 増加のアップデート--- 概要リンク
When a new summary link advertisement is received, it is not necessary to recalculate the entire routing table. Call the destination described by the summary link advertisement N, and let A be the area to which the advertisement belongs.
新しい概要リンク広告が受け取られているとき、それは全体のルーティングがテーブルの上に置くrecalculateに必要ではありません。 概要リンク広告Nで説明された目的地に電話をしてください、そして、Aが広告が属する領域であることをさせてください。
Look up the routing table entry for N. If the next hop to N is a virtual link through Area A (this means that the entry's associated area is the backbone, and the listed next hop does not belong to the backbone, but instead belongs to Area A), the real next hop must again
ほら、N.Ifのための経路指定テーブルエントリーに、Nへの次のホップがArea Aを通した仮想のリンク(これが、エントリーの関連領域が背骨であることを意味して、次の記載されたホップは、背骨に属しませんが、代わりにArea Aに属す)である、次の本当のホップは再びそうしなければなりません。
[Moy] [Page 127] RFC 1247 OSPF Version 2 July 1991
[Moy][127ページ]RFC1247OSPFバージョン1991年7月2日
be resolved. This means running the algorithm in Section 16.3 for destination N only.
決議されてください。 これは、セクション16.3のアルゴリズムを目的地Nだけへ走らせることを意味します。
Else, if there is an intra-area route to destination N nothing need be done (intra-area routes always take precedence). Otherwise, if Area A is the router's sole attached area, or Area A is the backbone, the procedure in Section 16.2 will have to be performed, but only for those summary link advertisements whose destination is N. Before this procedure is performed, the present routing table entry for N should be invalidated (but kept for comparison purposes). If this procedure leads to a virtual next hop, the algorithm in Section 16.3 will again have to be performed in order to calculate the real next hop.
ほかに、目的地Nへのイントラ領域ルートがあれば、何もする必要はありません(イントラ領域ルートはいつも優先します)。 さもなければ、セクション16.2の手順はArea Aがルータの唯一の付属領域であるかArea Aが背骨であるなら、実行されなければならないでしょうが、目的地がN.Beforeであるそれらの概要リンク広告だけにおいて、この手順は実行されて、Nのための現在の経路指定テーブルエントリーは無効にされるべきです(しかし、比較目的のために、保たれます)。 この手順が次の仮想のホップに通じると、セクション16.3のアルゴリズムは、次の本当のホップについて計算するために再び実行されなければならないでしょう。
If N's routing table entry changes, and N is an AS boundary router, the AS external links will have to be reexamined (Section 16.4).
Nの経路指定テーブルエントリー変化、およびNがAS境界ルータであるなら、ASの外部のリンクは再検討されなければならないでしょう(セクション16.4)。
16.6 Incremental updates --- AS external links
16.6 増加のアップデート--- ASの外部のリンク
When a new AS external link advertisement is received, it is not necessary to recalculate the entire routing table. Call the destination described by the AS external link advertisement N. If there is already an intra-area or inter-area route to the destination, no recalculation is necessary (these routes take precedence).
新しいAS外部のリンク広告が受け取られているとき、それは全体のルーティングがテーブルの上に置くrecalculateに必要ではありません。 どんな再計算も目的地がそこでASの外部のリンク広告N.Ifで説明した呼び出しが既に目的地へのイントラ領域か相互領域ルートであることが必要ではありません(これらのルートは優先します)。
Otherwise, the procedure in Section 16.4 will have to be performed, but only for those AS external link advertisements whose destination is N. Before this procedure is performed, the present routing table entry for N should be invalidated.
目的地がN.BeforeであるそれらのASの外部のリンク広告だけにおいて、この手順は実行されます、そして、さもなければ、セクション16.4の手順は実行されなければならないでしょうが、Nのための現在の経路指定テーブルエントリーは無効にされるべきです。
16.7 Events generated as a result of routing table changes
16.7回の出来事が経路指定テーブルの結果、変化を発生させました。
Changes to routing table entries sometimes cause the OSPF area border routers to take additional actions. These routers need to act on the following routing table changes:
経路指定テーブルエントリーへの変化で、OSPF境界ルータは時々追加行動を取ります。 これらのルータは、以下の経路指定テーブル変化に影響する必要があります:
o The cost or path type of a routing table entry has changed. If the
destination described by this entry is a Network or AS boundary
router, and this is not simply a change of AS external routes, new
summary link advertisements 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
advertisement must be flushed from the routing domain by setting its
age to MaxAge and reflooding (see Section 14.1).
o 経路指定テーブルエントリーの費用か経路タイプが変化しました。 このエントリーで説明された目的地がNetworkかAS境界ルータであり、これが単にAS外部経路の変化でないなら、新しい概要リンク広告は作られなければならないかもしれません(潜在的に背骨を含むそれぞれの付属領域あたり1つ)。 詳しい情報に関してセクション12.4.3を見てください。 以前に広告を出したエントリーが削除されたか、またはもう特定の領域に「広告を出-可能」でないなら、広告はMaxAgeに時代を設定して、「再-あふれ」るのによる経路ドメインから紅潮しているに違いありません(セクション14.1を見てください)。
[Moy] [Page 128] RFC 1247 OSPF Version 2 July 1991
[Moy][128ページ]RFC1247OSPFバージョン1991年7月2日
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 (via TOS 0), the corresponding virtual link is now
operational. An Interface Up 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 interface's IP address
and the virtual neighbor's IP address are also calculated.
エントリーが、境界ルータが新たに届いているのを(TOS0を通した)示すなら、対応する仮想のリンクは現在、操作上です。 Interface Up出来事は仮想のリンクに発生するべきです(セクション10.3を見てください)。(仮想の隣接番組はそれで、形成し始めるでしょう)。 また、このとき、仮想インターフェースのIPアドレスと仮想の隣人のIPアドレスは計算されます。
If the entry indicates that the area border router is no longer
reachable (via TOS 0), the virtual link and its associated adjacency
should be destroyed. This means an Interface Down event should be
generated for the associated virtual link.
エントリーが、境界ルータがもう届いていないのを(TOS0を通した)示すなら、仮想のリンクとその関連隣接番組は破壊されるべきです。 これは、Interface Down出来事が関連仮想のリンクに発生するべきであることを意味します。
If the cost of the entry has changed, and there is a fully
established virtual adjacency, a new router links advertisement for
the backbone must be originated. This in turn may cause further
routing table changes.
エントリーの費用が変化して、完全に確立した仮想の隣接番組があれば、背骨のための新しいルータリンク広告を溯源しなければなりません。 これは順番に一層の経路指定テーブル変化を引き起こすかもしれません。
16.8 Equal-cost multipath
16.8 等価コストマルチパス
The OSPF protocol maintains multiple equal-cost routes to all destinations. This can be seen in the steps used above to calculate the routing table, and in the definition of the routing table structure.
OSPFプロトコルは複数の等しい費用ルートをすべての目的地に維持します。 経路指定テーブルについて計算するのに上で使用されたステップ、および経路指定テーブル構造の定義でこれを見ることができます。
Each one of the multiple routes will be of the same type (intra-area, inter-area, type 1 external or type 2 external), cost, and will have the same associated area. However, each route specifies a separate next hop and advertising router.
複数のルートの各々は、(イントラ領域、相互領域、タイプ1外部またはタイプ2外部)がかかる同じタイプにはあって、同じ関連領域を持つでしょう。 しかしながら、各ルートは次の別々のホップと広告ルータを指定します。
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を走らせるルータがすべての可能な等しい費用ルートの目的地に動向をおさえるという要件が全くありません。 実現は、どんな与えられた目的地にもルートの定数だけを保つのを選ぶかもしれません。 これはこの仕様に提示されたアルゴリズムのいずれにも影響しません。
16.9 Building the non-zero-TOS portion of the routing table
16.9 経路指定テーブルの非無TOS部分を築き上げること。
The OSPF protocol can calculate a different set of routes for each IP TOS (see Section 2.4). Support for TOS-based routing is optional. TOS-capable and non-TOS-capable routers can be mixed in an OSPF routing domain. Routers not supporting TOS calculate only the TOS 0 route to each destination. These routes are then used to forward all data
OSPFプロトコルは各IP TOSのために異なったセットのルートを計算できます(セクション2.4を見てください)。 TOSベースのルーティングのサポートは任意です。 そして、TOSできる、できる非TOSルータはOSPF経路ドメインで複雑であることができます。 支持ではなく、ルータTOSはTOS0ルートだけを各目的地に計算します。 そして、これらのルートは、すべてのデータを転送するのに使用されます。
[Moy] [Page 129] RFC 1247 OSPF Version 2 July 1991
[Moy][129ページ]RFC1247OSPFバージョン1991年7月2日
traffic, regardless of the TOS indications in the data packet's IP header. A router that does not support TOS indicates this fact to the other OSPF routers by clearing the T-bit in the Options field of its router links advertisement.
データ・パケットのIPヘッダーでのTOS指摘にかかわらず交通。 TOSを支持しないルータは、ルータのOptions分野でT-ビットをきれいにするのによる他のOSPFルータへのこの事実が広告をリンクするのを示します。
The above sections detailing the routing table calculations handle the TOS 0 case only. In general, for routers supporting TOS-based routing, each piece of the routing table calculation must be rerun separately for the non-zero TOS values. When calculating routes for TOS X, only TOS X metrics can be used. Any link state advertisement may specify a separate cost for each TOS (a cost for TOS 0 must always be specified). The encoding of TOS in OSPF link state advertisements is described in Section 12.3.
経路指定テーブル計算を詳しく述べる上のセクションはTOS0ケースだけを扱います。 一般に、TOSベースのルーティングを支持するルータにおいて、非ゼロTOS値のために別々に経路指定テーブル計算の各断片を再放送しなければなりません。 TOS Xのためにルートを計算するとき、TOS X測定基準しか使用できません。 どんなリンク州の広告も各TOSに別々の費用を指定するかもしれません(いつもTOS0のための費用を指定しなければなりません)。 OSPFリンク州の広告における、TOSのコード化はセクション12.3で説明されます。
An advertisement can specify that it is restricted to TOS 0 (i.e., non- zero TOS is not handled) by clearing the T-bit in the link state advertisement's Option field. Such advertisements are not used when calculating routes for non-zero TOS. For this reason, it is possible that a destination is unreachable for some non-zero TOS. In this case, the TOS 0 path is used when forwarding packets (see Section 11.1).
すなわち、広告が、それがTOS0に制限されると指定できる、(非、-TOSが全く扱われない、)、リンクでT-ビットをきれいにすることによって、広告のOption分野を述べてください。 非ゼロTOSのためのルートを計算するとき、そのような広告は使用されていません。 この理由で、いくつかの非ゼロTOSに、目的地が手が届かないのは、可能です。 この場合パケットを進めるとき、TOS0経路は使用されています(セクション11.1を見てください)。
The following lists the modifications needed when running the routing table calculation for a non-zero TOS value (called TOS X). In general, routers and advertisements that do not support TOS are omitted from the calculation.
ルーティングを走らせるとき変更が必要とした以下のリストは非ゼロTOS価値(TOS Xと呼ばれる)のための計算を見送ります。 一般に、TOSを支持しないルータと広告が計算から省略されます。
Calculating the shortest-path tree (Section 16.1).
Routers that do not support TOS-based routing should be omitted from
the shortest-path tree calculation. These routers are identified as
those having the T-bit reset in their router links advertisements.
Such routers should never be added to the Dijktra algorithm's
candidate list, nor should their router links advertisements be
examined when adding the stub networks to the tree.
最短パス木(セクション16.1)について計算します。 TOSベースのルーティングを支持しないルータは最短パス木の計算から省略されるべきです。 T-ビットを持っている人がそれらのルータリンクに広告をリセットしたので、これらのルータは特定されます。 Dijktraアルゴリズムの候補リストにそのようなルータを決して追加するべきではありません、そして、スタッブネットワークを木に加えるとき、彼らのルータリンク広告を調べるべきではありません。
Calculating the inter-area routes (Section 16.2).
Inter-area paths are the concatenation of a path to an area border
router with a summary link. When calculating TOS X routes, both
path components must also specify TOS X. In other words, only TOS X
paths to the area border router are examined, and the area border
router must be advertising a TOS X route to the destination. Note
that this means that summary link advertisements having the T-bit
reset in their Options field are not considered.
相互領域について計算すると、(セクション16.2)は発送されます。 相互領域経路は概要リンクがある境界ルータへの経路の連結です。 また、TOS Xルートを計算するとき、両方の経路コンポーネントはTOS X.In他の単語を指定しなければなりません、そして、境界ルータへのTOS X経路だけが調べられます、そして、境界ルータはTOS Xルートの目的地に広告を出さなければなりません。 これが、それらのOptions分野にT-ビットをリセットする概要リンク広告が考えられないことを意味することに注意してください。
Resolving virtual next hops (Section 16.3).
This calculation again considers the concatenation of a path to an
area border router with a summary link. As with inter-area routes,
only TOS X paths to the area border router are examined, and the
次の仮想のホップ(セクション16.3)を決議します。 この計算は再び概要リンクがある境界ルータと経路の連結を考えます。 そして境界ルータへのTOS X経路だけが相互領域ルートのように調べられる。
[Moy] [Page 130] RFC 1247 OSPF Version 2 July 1991
[Moy][130ページ]RFC1247OSPFバージョン1991年7月2日
area border router must be advertising a TOS X route to the
destination.
領域境界ルータはTOS Xルートの目的地に広告を出さなければなりません。
Calculating AS external routes (Section 16.4).
This calculation considers the concatenation of a path to a
forwarding address with an AS external link. Only TOS X paths to
the forwarding address are examined, and the AS boundary router must
be advertising a TOS X route to the destination. Note that this
means that AS external link advertisements having the T-bit reset in
their Options field are not considered.
外部であることの形でASについて計算すると、(セクション16.4)は発送されます。 この計算はASの外部のリンクがあるフォーワーディング・アドレスと経路の連結を考えます。 フォーワーディング・アドレスへのTOS X経路だけが調べられます、そして、AS境界ルータはTOS Xルートの目的地に広告を出さなければなりません。 これが、それらのOptions分野にT-ビットをリセットするASの外部のリンク広告が考えられないことを意味することに注意してください。
In addition, the advertising AS boundary router must also be
reachable for its advertisements to be considered (see Section
16.4). However, if the advertising router and the forwarding
address are not one in the same, the advertising router need only be
reachable via TOS 0.
また、さらに、広告AS境界ルータも、広告が考えられるために届いていなければなりません(セクション16.4を見てください)。 しかしながら、広告ルータとフォーワーディング・アドレスが同じくらいの1でないなら、広告ルータはTOS0を通して届いているだけでよいです。
[Moy] [Page 131] RFC 1247 OSPF Version 2 July 1991
[Moy][131ページ]RFC1247OSPFバージョン1991年7月2日
[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 links advertisement as a host route.
[2] ルータのインタフェースのすべてが無数のポイントツーポイント接続であることは可能です。 この場合、IPアドレスをルータに割り当てなければなりません。 そして、ホストルートとしてルータのルータリンク広告にこのアドレスの広告を出すでしょう。
[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 the Backup Designated Router RT2. If router RT1
crashes (or maybe its interface to the network dies), the other
routers on the network will detect RT1's absence within
RouterDeadInterval seconds. All routers may not detect this at
precisely the same time; the routers that detect RT1's absence
before RT2 does will, for a time, select RT2 to be both Designated
Router and Backup Designated Router. When RT2 detects that RT1 is
gone it will move itself to Designated Router. At this time, the
remaining router having highest Router Priority will be selected as
Backup Designated Router.
[5] ネットワークのためのDesignated Routerがクラッシュすると何が起こるかわかるのはためになっています。 ネットワークのためのDesignated RouterをRT1、およびBackup Designated Router RT2と呼んでください。 ルータRT1がクラッシュすると(多分、ネットワークへのインタフェースは死にます)、ネットワークの他のルータはRouterDeadInterval秒以内にRT1の不在を検出するでしょう。 すべてのルータは正確に同時にこれを検出しないかもしれません。 RT2が検出する前にRT1の不在を検出するルータはそうするでしょう、時間、Designated RouterとBackup Designated Routerの両方である選んだRT2。 RT2がそれを検出するときのどんどんやられて、それ自体をDesignated Routerに動かすというRT1によることです。 このとき、持っている中でRouter Priority最も高い残っているルータはBackup Designated Routerとして選定されるでしょう。
[6]On point-to-point networks, the lower level protocols indicate
whether the neighbor is up and running. Likewise, existence of the
neighbor on virtual links is indicated by the routing table
calculation. However, in both these cases, the Hello Protocol is
still used. This ensures that communication between the neighbors
is bidirectional, and that each of the neighbors has a functioning
routing protocol layer.
[6] 二地点間ネットワークでは、下のレベルプロトコルは、隣人が活動しているかどうかを示します。 同様に、仮想のリンクの上の隣人の存在は経路指定テーブル計算で示されます。 しかしながら、これらの場合の両方では、Helloプロトコルはまだ使用されています。 これは隣人のコミュニケーションが双方向であり、隣人各人には機能しているルーティングプロトコル層があるのを確実にします。
[7]When the identity of the Designated Router is changing, it may be
quite common for a neighbor in this state to send the router a
Database Description packet; this means that there is some momentary
disagreement on the Designated Router's identity.
[7] Designated Routerのアイデンティティが変化するとき、この状態の隣人がDatabase記述パケットをルータに送るのは、全く一般的であるかもしれません。 これは、何らかの瞬間の不一致がDesignated Routerのアイデンティティにあることを意味します。
[8]Note that it is possible for a router to resynchronize any of its
fully established adjacencies by setting the adjacency's state back
to ExStart. This will cause the other end of the adjacency to
process a Seq Number Mismatch event, and therefore to also go back
to ExStart state.
[8] ルータが隣接番組の状態をExStartに遅らせることによって完全に確立した隣接番組のどれかを再連動させるのが、可能であることに注意してください。 これは隣接番組のもう一方の端がSeq Number Mismatch出来事を処理して、したがって、また、ExStart状態に戻ることを引き起こすでしょう。
[Moy] [Page 132] RFC 1247 OSPF Version 2 July 1991
[Moy][132ページ]RFC1247OSPFバージョン1991年7月2日
[9]The address space of IP networks and the address space of OSPF
Router IDs may overlap. That is, a network may have an IP address
which is identical (when considered as a 32-bit number) to some
router's Router ID.
[9] IPネットワークのアドレス空間とOSPF Router IDのアドレス空間は重なるかもしれません。 すなわち、ネットワークには、何らかのルータのRouter IDと同じ(32ビットの数であるとみなされると)IPアドレスがあるかもしれません。
[10]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.
[10] 目的地に合っている2つの異なったアドレスの範囲には、1つの範囲がもう片方より特定であると思われます。 この仮定に違反するために非隣接のサブネットマスクを構成できます。 OSPFプロトコルはそのようなサブネットマスク構成を扱うことができません。
[11]MaxAgeDiff is an architectural constant. It indicates the
maximum dispersion of ages, in seconds, that can occur for a single
link state instance as it is flooded throughout the routing domain.
If two advertisements differ by more than this, they are assumed to
be different instances of the same advertisement. This can occur
when a router restarts and loses track of its previous sequence
number. See Section 13.4 for more details.
[11] MaxAgeDiffは建築定数です。 それは秒のそれが経路ドメイン中で水につかっているときただ一つのリンク州の例のために起こることができる時代の最大の分散を示します。 2つの広告がこれ以上で異なるなら、それらは同じ広告の異なった例であると思われます。 ルータが前の一連番号を再開して、見失うとき、これは起こることができます。 その他の詳細に関してセクション13.4を見てください。
[12]When two advertisements have different checksums, they are
assumed to be separate instances. This can occur when a router
restarts, and loses track of its previous sequence number. In this
case, since the two advertisements have the same sequence number, it
is not possible to determine which link state is actually newer. If
the wrong advertisement is accepted as newer, the originating router
will originate another instance. See Section 13.4 for further
details.
[12] 2つの広告に異なったチェックサムがあると、それらは別々の例であると思われます。 ルータが前の一連番号を再開して、見失うとき、これは起こることができます。 2つの広告には同じ一連番号があるので、この場合、どちらのリンク状態が実際により新しいかを決定するのは可能ではありません。 間違った広告が、より新しいとして認められると、由来しているルータは別の例を溯源するでしょう。 さらに詳しい明細についてはセクション13.4を見てください。
[13]There is one instance where a lookup must be done based on
partial information. This is during the routing table calculation,
when a network links advertisement must be found based solely on its
Link State ID. The lookup in this case is still well defined, since
no two network advertisements can have the same Link State ID.
[13] ルックアップをしなければならない部分的な情報に基づく1つの例があります。 これは経路指定テーブル計算の間、あって、ネットワークがリンクされるとき、唯一Link州IDで広告がベースであることがわからなければなりません。 この場合、ルックアップはまだよく定義されていて、どんな2以来も、ネットワーク広告は同じLink州IDを持つことができません。
[14]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.
[14] この節はケースをカバーしています: 相互領域ルートは背骨へまとめられません。 これは相互領域ルートがいつも背骨領域に関連しているからです。
[15]By keeping more information in the routing table, it is possible
for an implementation to recalculate the shortest path tree only for
a single area. In fact, there are incremental algorithms that allow
an implementation to recalculate only a portion of the shortest path
tree [BBN]. These algorithms are beyond the scope of this
specification.
[15] ただ一つの領域だけへの実現に、経路指定テーブルでは、それがrecalculateに可能であるという詳しい情報を保つのによる最短パス木。 事実上、最短パス木[BBN]のrecalculateへの一部だけを実現に許容する増加のアルゴリズムがあります。 これらのアルゴリズムはこの仕様の範囲を超えています。
[16]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.
[16] これはLink州の要求リスト(結局、Fullへの変遷に隣人状態を引き起こす)がどう空にされているかということです。 その他の詳細に関してセクション10.9を見てください。
[Moy] [Page 133] RFC 1247 OSPF Version 2 July 1991
[Moy][133ページ]RFC1247OSPFバージョン1991年7月2日
[17]It should be a relatively rare occurrence for an advertisement's
age to reach MaxAge. Usually, the advertisement will be replaced by
a more recent instance before it ages out.
[17]広告の期間、MaxAgeに達するのは、比較的まれな発生であるべきです。 通常、外で年をとる前に広告をより最近の例に取り替えるでしょう。
[18]Only the TOS 0 routes are important here. This is because all
routing protocol packets are sent with TOS= 0. See Appendix A.
[18] TOS0ルートだけがここで重要です。 これはTOS=0と共にすべてのルーティング・プロトコルパケットを送るからです。 付録Aを見てください。
[19]It may be the case that paths to certain destinations do not
vary based on TOS. For these destinations, the routing calculation
need not be repeated for each TOS value. In addition, there need
only be a single routing table entry for these destinations (instead
of a separate entry for each TOS value).
[19] ある目的地への経路がTOSに基づいて異ならないのは、事実であるかもしれません。 これらの目的地に関しては、ルーティング計算はそれぞれのTOS値のために繰り返される必要はありません。 さらに、これらの目的地(それぞれのTOS値のための別々のエントリーの代わりに)のための単一の経路指定テーブルエントリーがあるだけでよいです。
[20]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.
[20] 等価コストマルチパスのために、厳密に言うと、アルゴリズムは木を作成しません。 私たちは、それがたいてい既存文献に起こることであるので「木」用語を使用し続けています。
[21]This means that before data traffic will flow between a pair of
neighboring routers, their link state databases must be
synchronized. Before synchronization (neighbor state < Full), a
router will not include the connection to its neighbor in its link
state advertisements.
[21] データ通信量が1組の隣接しているルータ、それらのリンク州のデータベースの間を流れる前に同期しなければならないこの手段。 同期(隣人州の<Full)の前に、ルータはリンク州の広告における隣人に接続を含まないでしょう。
[22]As a result of this clause, when a virtual link exists between
the calculating router and an AS boundary router, the intra-area
path through the virtual link's transit area is always preferred
over the virtual link itself.
[22] 仮想のリンクが計算のルータとAS境界ルータの間に存在するとき、この節の結果、仮想のリンクのトランジット領域を通るイントラ領域経路は仮想のリンク自体よりいつも好まれます。
[23]Note the similarity between this procedure and the calculation
of inter-area routes by a router internal to Area A.
[23] Area Aへの内部のルータで相互領域ルートのこの手順と計算の間の類似性に注意してください。
[24]When the forwarding address is non-zero, it should point to a
router belonging to another Autonomous System. See Section 12.4.4
for more details.
[24] フォーワーディング・アドレスが非ゼロであるときに、それは別のAutonomous Systemに属すルータを示すべきです。 その他の詳細に関してセクション12.4.4を見てください。
[Moy] [Page 134] RFC 1247 OSPF Version 2 July 1991
[Moy][134ページ]RFC1247OSPFバージョン1991年7月2日
References
参照
[BBN] McQuillan, J.M., Richer, I. and Rosen, E.C. ARPANET
Routing Algorithm Improvements. BBN Technical Report 3803,
April 1978.
[BBN]マッキランとJ.M.とリシェとI.とローゼン、E.C.アルパネットルーティング・アルゴリズム改良。 1978年4月のBBN技術報告書3803。
[DEC] Digital Equipment Corporation. Information processing
systems -- Data communications -- Intermediate System to
Intermediate System Intra-Domain Routing Protocol. October
1987.
[12月]DEC。 情報処理システム--データ通信--Intermediate System Intra-ドメインルート設定プロトコルへの中間的System。 1987年10月。
[McQuillan] McQuillan, J. et.al. The New Routing Algorithm for the
Arpanet. IEEE Transactions on Communications, May 1980.
[マッキラン]マッキラン、J.et.al。 Arpanetのための新しいルーティング・アルゴリズム。 1980年5月のコミュニケーションにおけるIEEE取引。
[Perlman] Perlman, Radia. Fault-Tolerant Broadcast of Routing
Information. Computer Networks, Dec. 1983.
[パールマン]パールマン、Radia。 経路情報のフォールトトレラント放送。 1983年12月のコンピュータネットワーク。
[RFC 791] Postel, Jon. Internet Protocol. September 1981
[RFC791] ポステル、ジョン。 インターネットプロトコル。 1981年9月
[RFC 944] ANSI X3S3.3 86-60. Final Text of DIS 8473, Protocol for
Providing the Connectionless-mode Network Service. March
1986.
[RFC944] ANSI X3S3.3 86-60。 不-8473年の最終版の教科書、コネクションレスなモードネットワーク・サービスを提供するためのプロトコル。 1986年3月。
[RFC 1060] Reynolds, J. and Postel, J. Assigned Numbers. March 1990.
[RFC1060] レイノルズとJ.とポステル、J.は数を割り当てました。 1990年3月。
[RFC 1112] Deering, S.E. Host extensions for IP multicasting. May
1988.
[RFC1112] デアリング、IPマルチキャスティングのための東南Host拡張子。 1988年5月。
[RFC 1131] Moy, J. The OSPF Specification. October 1989.
[RFC1131] J. Moy、OSPF仕様。 1989年10月。
[RS-85-153] Leiner, Dr. Barry M., et.al. The DARPA Internet Protocol
Suite. DDN Protocol Handbook, April 1985.
[RS-85-153]Leiner、バリーM.博士、et.al。 DARPAインターネットプロトコル群。 DDNはハンドブック、1985年4月について議定書の中で述べます。
[Moy] [Page 135] RFC 1247 OSPF Version 2 July 1991
[Moy][135ページ]RFC1247OSPFバージョン1991年7月2日
A. OSPF data formats
A。 OSPFデータ形式
This appendix describes the format of OSPF protocol packets and OSPF link state advertisements. 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リンク州の広告の形式について説明します。 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. It is contained both in OSPF protocol packets and in OSPF link state advertisements.
次に、OSPFオプション分野は説明されます。 この分野はOSPF経路ドメインの断片によってサポートされるかもしれない様々な能力について説明します。 それはOSPFプロトコルパケットとOSPFリンク州の広告に含まれています。
OSPF packet formats are detailed in Section A.3. A description of OSPF link state advertisements appears in Section A.4.
OSPFパケット・フォーマットはセクションA.3で詳細です。 OSPFリンク州の広告の記述はセクションA.4に現れます。
A.1 Encapsulation of OSPF packets
OSPFパケットのA.1カプセル化
OSPF runs directly over the Internet Protocol's network layer. OSPF packets are therefore encapsulated solely by IP and local network 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. 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 packets sent over virtual links to 576 bytes. However, if necessary, the length of OSPF packets can be up to 65,535 bytes (including the IP header).
OSPFはプロトコルパケットを断片化する方法を定義しないで、ネットワークMTUより大きいパケットを伝えるとき、IP断片化によります。 通常、大きい傾向があるOSPFパケットタイプ(データベース記述Packets、Link州Request、Link州Update、およびLink州Acknowledgmentパケット)はいくつかの別々のプロトコルパケットに分けることができます、機能性の損失なしで。 これはお勧めです。 可能であるときはいつも、IP断片化は避けられるべきです。 この推理を使用して、576バイトへの仮想のリンクの上に送られたパケットのサイズを制限するのを試みをするべきです。 必要ならしかしながら、OSPFパケットの長さは最大6万5535バイトであるかもしれません(IPヘッダーを含んでいて)。
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 multi-access networks. Two distinct IP multicast addresses are
used. Packets destined to these multicast addresses should never be
forwarded. Such packets 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 protocol packets are sent to this
AllSPFRouters Thisマルチキャストアドレスに値224.0を割り当ててあります。.0 .5。 OSPFを実行するすべてのルータがこのアドレスに送られたパケットを受けるように準備されるべきです。 こんにちは、この目的地に送って、いつもパケットはそうです。 また、あるプロトコルパケットをこれに送ります。
[Moy] [Page 136] RFC 1247 OSPF Version 2 July 1991
[Moy][136ページ]RFC1247OSPFバージョン1991年7月2日
address during the flooding procedure.
氾濫手順の間のアドレス。
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
packets are sent to this address during the flooding procedure.
AllDRouters Thisマルチキャストアドレスに値224.0を割り当ててあります。.0 .6。 このアドレスに運命づけられたパケットを受けるようにDesignated RouterとBackup Designated Routerの両方を準備しなければなりません。 氾濫手順の間、あるパケットをこのアドレスに送ります。
o OSPF is IP protocol number 89. This number has been registered with
the Network Information Center. IP protocol number assignments are
documented in [RFC 1060].
o OSPFはIPプロトコル番号89です。 この数はNetworkインフォメーション・センターに示されました。 IPプロトコル番号課題は[RFC1060]に記録されます。
o Routing protocol packets are sent with IP TOS of 0. The OSPF
protocol supports TOS-based routing. Routes to any particular
destination may vary based on TOS. However, all OSPF routing
protocol packets are sent with the DTR bits in the IP header's TOS
field (see [RFC 791]) set to 0.
o 0のIP TOSと共にルーティング・プロトコルパケットを送ります。 OSPFプロトコルはTOSベースのルーティングをサポートします。 どんな特定の目的地へのルートもTOSに基づいて異なるかもしれません。 しかしながら、DTRビットでIPヘッダーのTOS分野([RFC791]を見る)セットですべてのOSPFルーティング・プロトコルパケットを0に送ります。
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 [RFC 791] may help implement this objective.
o Internetwork Controlに設定されたIP先行と共にルーティング・プロトコルパケットを送ります。 発信と受信の両方の定期的なIPデータ通信量の上の優先権をOSPFプロトコルパケットに与えるべきです。 Internetwork Control[RFC791]へのIPヘッダーにIP先行分野をはめ込むのは、この目的を実装するのを助けるかもしれません。
[Moy] [Page 137] RFC 1247 OSPF Version 2 July 1991
[Moy][137ページ]RFC1247OSPFバージョン1991年7月2日
A.2 The options field
A.2はオプション分野です。
The OSPF options field is present in OSPF Hello packets, Database Description packets and all link state advertisements. 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パケット、Database記述パケット、およびすべてのリンク州の広告に存在しています。 オプション分野は、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 LSA types to a neighbor because of its reduced functionality. Lastly, listing capabilities in LSAs allows routers to route traffic around reduced functionality routers, by excluding them from parts of the routing table calculation.
Helloパケットで使用されると、オプション分野で、ルータは能力ミスマッチで隣人を拒絶できます。 ルータが進めないのを選ぶことができるDatabase記述パケットで能力を交換するとき、減少している機能性のために、あるいはまた、あるLSAは隣人にタイプします。 最後に、ルータはLSAsに能力を記載するのに減少している機能性ルータの周りにトラフィックを発送できます、経路指定テーブル計算の部品にそれらを入れないようにすることによって。
Two capabilities are currently defined. For each capability, the effect of the capability's appearance (or lack of appearance) in Hello packets, Database Description packets and link state advertisements is specified below. For example, the external routing capability (below called the E-bit) has meaning only in OSPF Hello Packets. Routers should reset (i.e. clear) the unassigned part of the capability field when sending Hello packets or Database Description packets and when originating link state advertisements.
2つの能力が現在、定義されます。 各能力として、Helloパケット、Database記述パケット、およびリンク州の広告における能力の外観(または、外観の不足)の効果は以下で指定されます。 例えば、外部のルーティング能力(E-ビットと呼ばれる下)はOSPF Hello Packetsだけに意味を持っています。 HelloパケットかDatabase記述パケットといつにリンク州の広告を溯源させるかとき、ルータは能力分野の割り当てられなかった地域をリセットするべきです(すなわち、クリアします)。
Additional capabilities may be assigned in the future. Routers encountering unrecognized capabilities in received Hello Packets, Database Description packets or link state advertisements should ignore the capability and process the packet/advertisement normally.
追加能力は将来、割り当てられるかもしれません。 容認されたHello Packetsで認識されていない能力に遭遇するルータ、Database記述パケットまたはリンク州の広告が、能力を無視して、通常、パケット/広告を処理するはずです。
+-+-+-+-+-+-+-+-+
| | | | | | |E|T|
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+ | | | | | | |E|T| +-+-+-+-+-+-+-+-+
The options field
オプション分野
T-bit
This describes the router's TOS capability. If the T-bit is reset,
then the router supports only a single TOS (TOS 0). Such a router
is also said to be incapable of TOS-routing. The absence of the T-
bit in a router links advertisement causes the router to be skipped
when building a non-zero TOS shortest-path tree (see Section 16.9).
In other words, routers incapable of TOS routing will be avoided as
much as possible when forwarding data traffic requesting a non-zero
TOS. The absence of the T-bit in a summary link advertisement or an
AS external link advertisement indicates that the advertisement is
T-ビットThisはルータのTOS能力について説明します。 T-ビットがリセットされるなら、ルータは独身のTOS(TOS0)だけをサポートします。 また、そのようなルータはTOS-ルーティングで不可能であると言われています。 非ゼロTOS最短パス木(セクション16.9を見る)を建てるとき広告でルータをスキップするルータで噛み付いたTリンクの不在。 言い換えれば、非ゼロTOSを要求するデータ通信量を進めるとき、TOSルーティングで不可能なルータはできるだけ避けられるでしょう。 概要リンク広告かASの外部のリンク広告における、T-ビットの欠如は、広告がそうであることを示します。
[Moy] [Page 138] RFC 1247 OSPF Version 2 July 1991
[Moy][138ページ]RFC1247OSPFバージョン1991年7月2日
describing a TOS 0 route only (and not routes for non-zero TOS).
TOS0ルート(そして、非ゼロTOSのためのルートでない)だけを説明します。
E-bit
AS external link advertisements are not flooded into/through OSPF
stub areas (see Section 3.6). The E-bit ensures that all members of
a stub area agree on that area's configuration. The E-bit is
meaningful only in OSPF Hello packets. When the E-bit is reset in
the Hello packet sent out a particular interface, it means that the
router will neither send nor receive AS external link state
advertisements on that interface (in other words, the interface
connects to a stub area). Two routers will not become neighbors
unless they agree on the state of the E-bit.
電子ビットのASの外部のリンク広告はOSPFスタッブ領域を通って/へあふれません(セクション3.6を見てください)。 E-ビットは、スタッブ領域のすべてのメンバーがその領域の構成に同意するのを確実にします。 E-ビットはOSPF Helloパケットだけで重要です。 E-ビットがいつHelloパケットにリセットされるかが特定のインタフェースを出して、それは、ルータがそのインタフェースに関するASの外部のリンク州の広告を送付でない、また受け取らないことを意味します(言い換えれば、インタフェースはスタッブ領域に接続します)。 彼らがE-ビットの状態に同意しないなら、2つのルータは隣人にならないでしょう。
[Moy] [Page 139] RFC 1247 OSPF Version 2 July 1991
[Moy][139ページ]RFC1247OSPFバージョン1991年7月2日
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 link state advertisements. For example, Link State Update packets implement the flooding of advertisements throughout the OSPF routing domain. Because of this, OSPF protocol packets cannot be parsed unless the format of link state advertisements is also understood. The format of Link state advertisements is described in Section A.4.
すべてのOSPFパケットタイプ(OSPF Helloパケットを除いた)がリンク州の広告のリストに対処します。 例えば、Link州UpdateパケットはOSPF経路ドメイン中で広告の氾濫を実装します。 これのために、また、リンク州の広告の形式が理解されていない場合、OSPFプロトコルパケットを分析できません。 Link州の広告の形式はセクションA.4で説明されます。
The receive processing of OSPF packets is detailed in Section 8.2. The sending of OSPF packets is explained in Section 8.1.
セクション8.2で詳述したOSPFパケットの処理を受けてください。 OSPFパケットの発信はセクション8.1で説明されます。
[Moy] [Page 140] RFC 1247 OSPF Version 2 July 1991
[Moy][140ページ]RFC1247OSPFバージョン1991年7月2日
A.3.1 The OSPF packet header
OSPFパケットのヘッダーのA.3.1
Every OSPF packet starts with a common 24 byte header. This header contains all the necessary information to determine whether the packet should be accepted for further processing. This determination is described in Section 8.2 of the specification.
あらゆるOSPFパケットが24バイトの一般的なヘッダーから始めます。 このヘッダーはさらなる処理のためにパケットを受け入れるべきであるか否かに関係なく、決定するすべての必要事項を含んでいます。 この決断は仕様のセクション8.2で説明されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | Type | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Autype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン#| タイプ| パケット長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルータID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 領域ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| Autype| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version #
The OSPF version number. This specification documents version 2 of
the protocol.
OSPFバージョンが付番するバージョン#。 この仕様はプロトコルのバージョン2を記録します。
Type
The OSPF packet types are as follows. The format of each of these
packet types is described in a succeeding section.
OSPFパケットがタイプするタイプは以下の通りです。 これらのパケットタイプ各人の形式は続くセクションで説明されます。
Type Description
________________________________
1 Hello
2 Database Description
3 Link State Request
4 Link State Update
5 Link State Acknowledgment
型記述________________________________ こんにちは、2データベース記述3リンク州が、4リンク州のアップデート5がリンクするよう要求する1は承認を述べます。
[Moy] [Page 141] RFC 1247 OSPF Version 2 July 1991
[Moy][141ページ]RFC1247OSPFバージョン1991年7月2日
Packet length
The length of the protocol packet in bytes. This length includes
the standard OSPF header.
パケット長、バイトで表現されるプロトコルパケットの長さ。 この長さは標準のOSPFヘッダーを含んでいます。
Router ID
The Router ID of the packet's source. In OSPF, the source and
destination of a routing protocol packet are the two ends of an
(potential) adjacency.
パケットのソースのルータID Router ID。 OSPFに、ルーティング・プロトコルパケットのソースと目的地は(潜在的)の隣接番組の2つの終わりです。
Area ID
A 32 bit number identifying the area that this packet belongs to.
All OSPF packets are associated with a single area. Most travel a
single hop only. Packets travelling over a virtual link are
labelled with the backbone area ID of 0.
領域ID A32はこのパケットが属す領域を特定する数に噛み付きました。 すべてのOSPFパケットがただ一つの領域に関連しています。 大部分は単一のホップだけを旅行します。 仮想のリンクの上に移動するパケットは0のバックボーン領域IDでラベルされます。
Checksum
The standard IP checksum of the entire contents of the packet,
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.
チェックサム、64ビットの認証分野を除いたパケットの全体のコンテンツの標準のIPチェックサム。 このチェックサムはパケットでのすべての16ビットの単語の1の補数合計の16ビットの1の補数として計算されます、認証分野を除いて。 パケットの長さが整数の16ビットの単語でないなら、パケットはchecksummingする前に、1バイトのゼロで水増しされます。
AuType
Identifies the authentication scheme to be used for the packet.
Authentication is discussed in Appendix E of the specification.
Consult Appendix E for a list of the currently defined
authentication types.
AuType Identifies、パケットに使用されるべき認証体系。 仕様のAppendix Eで認証について議論します。 現在定義された認証タイプのリストのためにAppendix Eに相談してください。
Authentication
A 64-bit field for use by the authentication scheme.
認証体系による使用のための認証のA64ビットの分野。
[Moy] [Page 142] RFC 1247 OSPF Version 2 July 1991
[Moy][142ページ]RFC1247OSPFバージョン1991年7月2日
A.3.2 The Hello packet
A.3.2はHelloパケットです。
Hello packets are OSPF packet type 1. These packets are sent periodically on all interfaces (including virtual links) in order to establish and maintain neighbor relationships. In addition, Hellos are multicast on those physical networks having a multicast or broadcast capability, enabling dynamic discovery of neighboring routers.
こんにちは、パケットはそうです。OSPFパケットは1をタイプします。 隣人関係を確立して、維持するためにすべてのインタフェース(仮想のリンクを含んでいる)で定期的にこれらのパケットを送ります。 さらに、ハローズはマルチキャストか放送能力(隣接しているルータの可能なダイナミックな発見)を持っているそれらの物理ネットワークのマルチキャストです。
All routers connected to a common network must agree on certain parameters (network mask, hello and dead intervals). 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.
一般的なネットワークに関連づけられたすべてのルータが、あるパラメタに同意しなければなりません。そして、(ネットワークがマスクをかける、こんにちは、死んでいる間隔) これらのパラメタは、違いが隣人関係の形成を禁止できるように、Helloパケットに含まれています。 Aが説明を詳しく述べた、パケットがセクション10.5に提示されるHelloのために処理を受けてください。 Helloパケットの発信はセクション9.5でカバーされています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 1 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Autype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInt | Options | Rtr Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DeadInt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Designated Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Designated Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン#| 1 | パケット長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルータID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 領域ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| Autype| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ネットワークマスク| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HelloInt| オプション| Rtr Pri| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DeadInt| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 代表ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バックアップに指定されたルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 隣人| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
[Moy] [Page 143] RFC 1247 OSPF Version 2 July 1991
[Moy][143ページ]RFC1247OSPFバージョン1991年7月2日
Network mask
The network mask associated with this interface. For example, if
the interface is to a class B network whose third byte is used for
subnetting, the network mask is 0xffffff00.
ネットワークマスクがこのインタフェースに関連づけたマスクをネットワークでつないでください。 例えば、3番目のバイトがサブネッティングに使用されるクラスBネットワークにインタフェースがあるなら、ネットワークマスクは0xffffff00です。
Options
The optional capabilities supported by the router, as documented in
Section A.2.
任意の能力がセクションA.2に記録されるようにルータでサポートしたオプション。
HelloInt
The number of seconds between this router's Hello packets.
HelloInt、このルータのHelloパケットの間の秒数。
Rtr Pri
This router's Router Priority. Used in (Backup) Designated Router
election. If set to 0, the router will be ineligible to become
(Backup) Designated Router.
Rtr Pri ThisルータのRouter Priority。 Router選挙に指定された(バックアップ)では、使用されています。 0に設定されると、ルータはRouterに指定された(バックアップ)になるのにおいて不適格になるでしょう。
Deadint
The number of seconds before declaring a silent router down.
Deadint、静かなルータを宣言する前の秒数はダウンします。
Designated Router
The identity of the Designated Router for this network, in the view
of the advertising router. The Designated Router is identified here
by its IP interface address on the network. Set to 0 if there is no
Designated Router.
このネットワークのために広告ルータの視点でDesignated RouterのアイデンティティにRouterを指定しました。 Designated Routerはここでネットワークに関するIPインターフェース・アドレスによって特定されます。 Designated Routerが全くなければ、0にセットしてください。
Backup Designated Router
The identity of the Backup Designated Router for this network, in
the view of the advertising router. The Backup Designated Router is
identified here by its IP interface address on the network. Set to
0 if there is no backup Designated Router.
Designated Routerのバックアップをとってください。広告ルータの視点におけるこのネットワークのためのBackup Designated Routerのアイデンティティ。 Backup Designated Routerはここでネットワークに関するIPインターフェース・アドレスによって特定されます。 バックアップDesignated Routerが全くなければ、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
DeadInt seconds.
ネットワークで有効なHelloパケットが最近見られたそれぞれのルータのRouter IDを近所付き合いさせてください。 最後のDeadInt秒に最近、意味します。
[Moy] [Page 144] RFC 1247 OSPF Version 2 July 1991
[Moy][144ページ]RFC1247OSPFバージョン1991年7月2日
A.3.3 The Database Description packet
A.3.3はDatabase記述パケットです。
Database Description packets are OSPF packet type 2. These packets are exchanged when an adjacency is being initialized. They describe the contents of the topological 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 master, the other a 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' sequence numbers.
データベース記述パケットはOSPFパケットタイプ2です。 隣接番組を初期化しているとき、これらのパケットを交換します。 彼らは位相的なデータベースのコンテンツについて説明します。 複数のパケットが、データベースについて説明するのに使用されるかもしれません。 このために投票応答手順は使用されています。 ルータの1つはマスターになるように指定されて、もう片方が奴隷です。 マスターは奴隷(応答)によって送られたDatabase記述パケットによって承認される記述パケット(投票)をDatabaseに送ります。 応答はパケットの一連番号で投票にリンクされます。
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 topological 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.
Database記述パケットの形式はLink州RequestとLink州Acknowledgmentパケットの両方と非常に同様です。 すべての3の主部は項目のリスト、位相的なデータベースの1つの断片について説明する各個条です。 Database記述Packetsの発信はセクション10.8に記録されます。 Database記述パケットのレセプションはセクション10.6に記録されます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | Options |0|0|0|0|0|I|M|MS
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DD sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| A |
+- Link State Advertisement -+
| Header |
+- -+
| |
+- -+
| |
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン#| 2 | パケット長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルータID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 領域ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| Autype| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 0 | オプション|0|0|0|0|0|I|M|+++++++++++++++++++++++++++++++++さん| DD一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | A| +リンク州広告-+| ヘッダー| +- -+ | | +- -+ | |
[Moy] [Page 145] RFC 1247 OSPF Version 2 July 1991
[Moy][145ページ]RFC1247OSPFバージョン1991年7月2日
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
0 These fields are reserved. They must be 0.
0 これらの分野は予約されています。 それらは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 descriptions.
Initが噛み付いたI-ビット。 1に設定されると、このパケットはデータベース記述の系列で1番目です。
M-bit
The More bit. When set to 1, it indicates that more database
descriptions are to follow.
Moreが噛み付いたM-ビット。 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.
Master/奴隷が噛み付いたMS-ビット。 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 sequence number then increments until the complete
database description has been sent.
データベース記述パケットの収集を配列するDD一連番号Used。 初期の値(設定されるInitビットで、示される)はユニークであるべきです。 記述を送る完全なデータベースまでの一連番号の当時の増分。
The rest of the packet consists of a (possibly partial) list of the topological database's pieces. Each link state advertisement in the database is described by its link state header. The link state header is documented in Section A.4.1. It contains all the information required to uniquely identify both the advertisement and the advertisement's current instance.
パケットの残りは位相的なデータベースの片の(ことによると部分的)のリストから成ります。 データベースにおけるそれぞれのリンク州の広告はリンク州のヘッダーによって説明されます。 リンク州のヘッダーはセクションA.4.1に記録されます。 それは唯一広告と広告の現在のインスタンスの両方を特定するのに必要であるすべての情報を含んでいます。
[Moy] [Page 146] RFC 1247 OSPF Version 2 July 1991
[Moy][146ページ]RFC1247OSPFバージョン1991年7月2日
A.3.4 The Link State Request packet
A.3.4はLink州Requestパケットです。
Link State Request packets are OSPF packet type 3. After exchanging Database Description packets with a neighboring router, a router may find that parts of its topological 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. The sending of Link State Request packets is the last step in bringing up an adjacency.
リンク州RequestパケットはOSPFパケットタイプ3です。 Database記述パケットを隣接しているルータと交換した後に、ルータによって、位相的なデータベースの部分が時代遅れであることがわかるかもしれません。 Link州Requestパケットは、隣人のデータベースの、より最新の断片を要求するのに使用されます。 複数のLink州Requestパケットが、使用される必要があるかもしれません。 Link州Requestパケットの発信は隣接番組を持って来ることにおいて最後のステップです。
A router that sends a Link State Request packet has in mind the precise instance of the database pieces it is requesting (defined by LS sequence number, LS checksum, and LS age). It may receive even more recent instances in response.
Link州Requestパケットを送るルータはそれが要求している(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.
Link州Requestパケットの発信はセクション10.9に記録されます。 Link州Requestパケットのレセプションはセクション10.7に記録されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 3 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Autype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン#| 3 | パケット長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルータID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 領域ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| Autype| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSはタイプします。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 州のIDをリンクしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 広告ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
Each advertisement requested is specified by its LS type, Link State ID, and Advertising Router. This uniquely identifies the advertisement, but not its instance. Link State Request packets are understood to be requests for the most recent instance (whatever that might be).
要求された各広告はLink州のLSタイプ、ID、およびAdvertising Routerによって指定されます。 これは唯一インスタンスではなく、広告を特定します。 リンク州Requestパケットは最新のインスタンス(それはことなら何でもであるかもしれない)を求める要求であることが理解されています。
[Moy] [Page 147] RFC 1247 OSPF Version 2 July 1991
[Moy][147ページ]RFC1247OSPFバージョン1991年7月2日
A.3.5 The Link State Update packet
A.3.5はLink州Updateパケットです。
Link State Update packets are OSPF packet type 4. These packets implement the flooding of link state advertisements. Each Link State Update packet carries a collection of link state advertisements one hop further from its origin. Several link state advertisements may be included in a single packet.
リンク州UpdateパケットはOSPFパケットタイプ4です。 これらのパケットはリンク州の広告の氾濫を実装します。 それぞれのLink州Updateパケットはさらに発生源からのワンバウンドのリンク州の広告の収集を運びます。 いくつかのリンク州の広告が単一のパケットに含まれるかもしれません。
Link State Update packets are multicast on those physical networks that support multicast/broadcast. In order to make the flooding procedure reliable, flooded advertisements are acknowledged in Link State Acknowledgment packets. If retransmission of certain advertisements is necessary, the retransmitted advertisements are always carried by unicast Link State Update packets. For more information on the reliable flooding of link state advertisements, consult Section 13.
リンク州Updateパケットはマルチキャスト/放送をサポートするそれらの物理ネットワークのマルチキャストです。 氾濫手順を信頼できるようにするように、水につかっている広告はLink州Acknowledgmentパケットで承諾されます。 ある広告の「再-トランスミッション」が必要であるなら、再送された広告はいつもユニキャストLink州Updateパケットによって運ばれます。 リンク州の広告の信頼できる氾濫の詳しい情報に関しては、セクション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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # advertisements |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- +-+
| Link state advertisements |
+- +-+
| ... |
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン#| 4 | パケット長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルータID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 領域ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| Autype| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # 広告| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- +-+ | リンク州の広告| +- +-+ | ... |
# advertisements
The number of link state advertisements included in this update.
# このアップデートにリンク州の広告の数を含んでいる広告。
The body of the Link State Update packet consists of a list of link state advertisements. Each advertisement begins with a common 20 byte
Link州Updateパケットのボディーはリンク州の広告のリストから成ります。 各広告は一般的な20バイトで始まります。
[Moy] [Page 148] RFC 1247 OSPF Version 2 July 1991
[Moy][148ページ]RFC1247OSPFバージョン1991年7月2日
header, the link state advertisement header. This header is described in Section A.4.1. Otherwise, the format of each of the five types of link state advertisements is different. Their formats are described in Section A.4.
ヘッダー、リンク州の広告ヘッダー。 このヘッダーはセクションA.4.1で説明されます。 さもなければ、それぞれの5つのタイプのリンク州の広告の形式は異なっています。 それらの形式はセクションA.4で説明されます。
[Moy] [Page 149] RFC 1247 OSPF Version 2 July 1991
[Moy][149ページ]RFC1247OSPFバージョン1991年7月2日
A.3.6 The Link State Acknowledgment packet
A.3.6はLink州Acknowledgmentパケットです。
Link State Acknowledgment Packets are OSPF packet type 5. To make the flooding of link state advertisements reliable, flooded advertisements are explicitly acknowledged. This acknowledgment is accomplished through the sending and receiving of Link State Acknowledgment packets. Multiple link state advertisements can be acknowledged in a single packet.
リンク州Acknowledgment PacketsはOSPFパケットタイプ5です。 リンク州の広告の氾濫を信頼できるようにするように、水につかっている広告は明らかに承諾されます。 この承認はLink州Acknowledgmentパケットの送受信で実行されます。 単一のパケットで複数のリンク州の広告を承諾できます。
Depending on the state of the sending interface and the source of the advertisements being acknowledged, 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州Acknowledgmentパケットを送ります。 Link州Acknowledgementパケットの発信はセクション13.5に記録されます。 Link州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 link state advertisement headers.
このパケットの形式はData記述パケットのものと同様です。 両方のパケットのボディーは単にリンク州の広告ヘッダーのリストです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 5 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Autype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| A |
+- Link State Advertisement -+
| Header |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン#| 5 | パケット長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルータID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 領域ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| Autype| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | A| +リンク州広告-+| ヘッダー| +- -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
[Moy] [Page 150] RFC 1247 OSPF Version 2 July 1991
[Moy][150ページ]RFC1247OSPFバージョン1991年7月2日
Each acknowledged link state advertisement is described by its link state header. The link state header is documented in Section A.4.1. It contains all the information required to uniquely identify both the advertisement and the advertisement's current instance.
それぞれの承認されたリンク州の広告はリンク州のヘッダーによって説明されます。 リンク州のヘッダーはセクションA.4.1に記録されます。 それは唯一広告と広告の現在のインスタンスの両方を特定するのに必要であるすべての情報を含んでいます。
[Moy] [Page 151] RFC 1247 OSPF Version 2 July 1991
[Moy][151ページ]RFC1247OSPFバージョン1991年7月2日
A.4 Link state advertisement formats
A.4リンク州の広告形式
There are five distinct types of link state advertisements. Each link state advertisement begins with a standard 20-byte link state header. This header is explained in Section A.4.1. Succeeding sections then diagram the separate link state advertisement types.
5つの異なったタイプのリンク州の広告があります。 それぞれのリンク州の広告は標準の20バイトのリンク州のヘッダーと共に始まります。 このヘッダーはセクションA.4.1で説明されます。 そして、続くセクションは別々のリンク州の広告タイプを図解します。
Each link state advertisement describes a piece of the OSPF routing domain. Every router originates a router links advertisement. In addition, whenever the router is elected Designated Router, it originates a network links advertisement. Other types of link state advertisements may also be originated (see Section 12.4). All link state advertisements are then flooded throughout the OSPF routing domain. The flooding algorithm is reliable, ensuring that all routers have the same collection of link state advertisements. (See Section 13 for more information concerning the flooding algorithm). This collection of advertisements is called the link state (or topological) database.
それぞれのリンク州の広告はOSPF経路ドメインの1つの断片について説明します。 あらゆるルータがルータリンク広告を溯源します。 さらに、ルータがDesignated Routerに選出されて、起因するときはいつも、ネットワークは広告をリンクします。 また、他のタイプのリンク州の広告は溯源されるかもしれません(セクション12.4を見てください)。 すべてのリンク州の広告がその時、OSPF経路ドメイン中で水につかっています。 すべてのルータにはリンク州の広告の同じ収集があるのを確実にして、氾濫アルゴリズムは信頼できます。 (詳しい情報に関して氾濫アルゴリズムに関してセクション13を見ます。) 広告のこの収集はリンク状態の、そして、(位相的)のデータベースと呼ばれます。
From the link state database, each router constructs a shortest path tree with itself as root. This yields a routing table (see Section 11). For the details of the routing table build process, see Section 16.
リンク州のデータベースから、各ルータは根としてそれ自体で最短パス木を組み立てます。 これは経路指定テーブルをもたらします(セクション11を見てください)。 経路指定テーブルの細部に関しては、プロセスを建ててください、そして、セクション16を見てください。
[Moy] [Page 152] RFC 1247 OSPF Version 2 July 1991
[Moy][152ページ]RFC1247OSPFバージョン1991年7月2日
A.4.1 The Link State Advertisement header
Link州AdvertisementヘッダーのA.4.1
All link state advertisements begin with a common 20 byte header. This header contains enough information to uniquely identify the advertisement (LS type, Link State ID, and Advertising Router). Multiple instances of the link state advertisement 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 link state advertisement header.
すべてのリンク州の広告が20バイトの一般的なヘッダーと共に始まります。 このヘッダーは唯一、広告(Link州のLSタイプ、ID、およびAdvertising Router)を特定できるくらいの情報を含んでいます。 リンク州の広告の複数のインスタンスが同時に、経路ドメインに存在するかもしれません。 どちらのインスタンスが、より最近であるかを決定するのがその時、必要です。 これは、また、リンク州の広告ヘッダーに含まれているLS時代、LS一連番号、およびLSチェックサム分野を調べることによって、達成されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | LS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS時代| オプション| LSはタイプします。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 州のIDをリンクしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 広告ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSチェックサム| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LS age
The time in seconds since the link state advertisement was
originated.
LSは秒のリンク州の広告が溯源されて以来の時に年をとります。
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 link state advertisement. Each link state type has
a separate advertisement format. The link state types are as
follows (see Section 12.1.3 for further explanation):
LSはリンク州の広告のタイプをタイプします。 それぞれのリンク州のタイプには、別々の広告形式があります。 リンク州のタイプは以下の通りです(詳細な説明に関してセクション12.1.3を見てください):
[Moy] [Page 153] RFC 1247 OSPF Version 2 July 1991
[Moy][153ページ]RFC1247OSPFバージョン1991年7月2日
LS Type Description
___________________________________
1 Router links
2 Network links
3 Summary link (IP network)
4 Summary link (ASBR)
5 AS external link
LS型記述___________________________________ 1つのルータが2個のNetworkリンク3Summaryリンク(IPネットワーク)4Summaryリンク(ASBR)5ASの外部のリンクをリンクします。
Link State ID
This field identifies the portion of the internet environment that
is being described by the advertisement. The contents of this field
depend on the advertisement's LS type. For example, in network
links advertisements the Link State ID is set to the IP interface
address of the network's Designated Router (from which the network's
IP address can be derived). The Link State ID is further discussed
in Section 12.1.4.
Thisがさばくリンク州IDは広告で説明されているインターネット環境の部分を特定します。 この分野の内容は広告のLSタイプに頼っています。 例えば、ネットワークリンクでは、広告Link州IDはネットワークのDesignated Router(ネットワークのIPアドレスを引き出すことができる)のIPインターフェース・アドレスに設定されます。 セクション12.1.4でLink州IDについてさらに議論します。
Advertising Router
The Router ID of the router that originated the link state
advertisement. For example, in network links advertisements this
field is set to the Router ID of the network's Designated Router.
リンク州の広告を溯源したルータのRouter Router IDの広告を出します。 例えば、ネットワークリンク広告では、この分野はネットワークのDesignated RouterのRouter IDに設定されます。
LS sequence number
Detects old or duplicate link state advertisements. Successive
instances of a link state advertisement are given successive LS
sequence numbers. See Section 12.1.6 for more details.
LS一連番号Detects老人か写しリンク州の広告。 リンク州の広告の連続したインスタンスに連続したLS一連番号を与えます。 その他の詳細に関してセクション12.1.6を見てください。
LS checksum
The Fletcher checksum of the complete contents of the link state
advertisement. See Section 12.1.7 for more details.
完全のフレッチャーチェックサムが満足させるリンク州の広告のLSチェックサム。 その他の詳細に関してセクション12.1.7を見てください。
length
The length in bytes of the link state advertisement. This includes
the 20 byte link state header.
長さ、リンク州の広告のバイトで表現される長さ。 これは20バイトのリンク州のヘッダーを含んでいます。
[Moy] [Page 154] RFC 1247 OSPF Version 2 July 1991
[Moy][154ページ]RFC1247OSPFバージョン1991年7月2日
A.4.2 Router links advertisements
A.4.2ルータは広告をリンクします。
Router links advertisements are the Type 1 link state advertisements. Each router in an area originates a router links advertisement. The advertisement describes the state and cost of the router's links (or interfaces) to the area. All of the router's links to the area must be described in a single router links advertisement. For details concerning the construction of router links advertisements, see Section 12.4.1.
ルータリンク広告はType1リンク州の広告です。 領域の各ルータはルータリンク広告を溯源します。 広告はその領域へのルータのリンク(または、インタフェース)の状態と費用について説明します。 ただ一つのルータリンク広告でその領域へのルータのリンクのすべてについて説明しなければなりません。 ルータリンク広告の工事に関する詳細に関しては、セクション12.4.1を見てください。
In router links advertisements, the Link State ID field is set to the router's OSPF Router ID. The T-bit is set in the advertisement's Option field if and only if the router is able to calculate a separate set of routes for each IP TOS. Router links advertisements are flooded throughout a single area only.
ルータリンクでは、広告であり、Link州ID分野はルータのOSPF Router IDに設定されます。 そして、T-ビットが広告のOption分野に設定される、ルータが各IP TOSのために別々のセットのルートを計算できる場合にだけ。 ルータリンク広告はただ一つの領域だけ中で水につかっています。
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 |E|B| 0 | # links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | # TOS | TOS 0 metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOS | 0 | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOS | 0 | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS時代| オプション| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 州のIDをリンクしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 広告ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSチェックサム| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |E|B| 0 | # リンク| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IDをリンクしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | リンクデータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| # TOS| TOS0メートル法です。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOS| 0 | メートル法| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOS| 0 | メートル法| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IDをリンクしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | リンクデータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[Moy] [Page 155] RFC 1247 OSPF Version 2 July 1991
[Moy][155ページ]RFC1247OSPFバージョン1991年7月2日
| ... |
| ... |
bit E
When set, the router is an AS boundary router (E is for external)
ビットE Whenはセットして、ルータはAS境界ルータです。(外部にはEがあります)
bit B
When set, the router is an area border router (B is for border)
ビットB Whenはセットして、ルータは境界ルータです。(境界にはBがあります)
# links
The number of router links described by this advertisement. This
must be the total collection of router links to the area.
# ルータリンクの数がこの広告で説明したリンク。 これはその領域へのルータリンクの総収集であるに違いありません。
The following fields are used to describe each router link. 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 data field. For links to stub networks this field specifies the network's IP address mask. For the other link types the Link Data specifies the router's associated IP interface address.
以下の分野は、それぞれのルータリンクについて説明するのに使用されます。 それぞれのルータリンクはタイプされます(下にType分野を見てください)。 タイプ分野は説明されるリンクの種類を示します。 それはトランジットネットワーク、または、別のルータ、または、スタッブネットワークへのリンクであるかもしれません。 ルータリンクについて説明する他のすべての分野の値はリンクのタイプに頼っています。 例えば、各リンクには、関連32ビットのデータ分野があります。 リンクがネットワークを引き抜くように、この分野はネットワークのIPアドレスマスクを指定します。 他のリンク型として、Link Dataはルータの関連IPインターフェース・アドレスを指定します。
Type
A quick description of the router link. One of the following. Note
that host routes are classified as links to stub networks whose
network mask is 0xffffffff.
ルータリンクのA迅速な記述をタイプしてください。 以下の1つ。 ホストルートがネットワークマスクが0xffffffffであるネットワークを引き抜くためにリンクとして分類されることに注意してください。
Type Description
__________________________________________________
1 Point-to-point connection to another router
2 Connection to a transit network
3 Connection to a stub network
4 Virtual link
型記述__________________________________________________ 1 aへの2Connectionが通過する別のルータへの二地点間接続はスタッブネットワーク4Virtualリンクに3Connectionをネットワークでつなぎます。
Link ID
Identifies the object that this router link connects to. Value
depends on the link's type. When connecting to an object that also
originates a link state advertisement (i.e., another router or a
transit network) the Link ID is equal to the other advertisement's
ID Identifiesをリンクしてください。このルータリンクが接続するオブジェクト。 値はリンクのタイプに頼っています。 また、リンク州の広告(すなわち、別のルータかトランジットネットワーク)を溯源するオブジェクトに接続するとき、Link IDは広告のもう片方のものと等しいです。
[Moy] [Page 156] RFC 1247 OSPF Version 2 July 1991
[Moy][156ページ]RFC1247OSPFバージョン1991年7月2日
Link State ID. This provides the key for looking up said
advertisement in the link state database. See Section 12.2 for more
details.
州のIDをリンクしてください。 これは前述の広告を見上げるためのキーをリンク州のデータベースに提供します。 その他の詳細に関してセクション12.2を見てください。
Type Link ID
______________________________________
1 Neighboring router's ID
2 IP address of Designated Router
3 IP network/subnet number
4 Neighboring router's ID
リンクIDをタイプしてください。______________________________________ Designated Router3IPネットワーク/サブネットNo.4NeighboringルータのIDに関する1つの隣接しているルータのID2IPアドレス
Link Data
Contents again depend on the link's Type field. For connections to
stub network, it specifies the network mask. For the other link
types it specifies the router's associated IP interface address.
This latter piece of information is needed during the routing table
build process, when calculating the IP address of the next hop. See
Section 16.1.1 for more details.
リンクData Contentsは再びリンクのTypeフィールドによります。 接続がネットワークを引き抜くように、それはネットワークマスクを指定します。 他のリンク型として、それはルータの関連IPインターフェース・アドレスを指定します。 次のホップのIPアドレスについて計算するとき、この後者の情報がテーブルがプロセスを建てるルーティングの間、必要です。 その他の詳細に関してセクション16.1.1を見てください。
#metrics
The number of different TOS metrics given for this link, not
counting the required metric for TOS 0. For example, if no
additional TOS metrics are given, this field should be set to 0.
#測定基準はTOS0における、メートル法の必要を数えるのではなく、このリンクに与えられた異なったTOS測定基準の数です。 例えば、どんな追加TOS測定基準も与えないなら、この分野を0に設定するべきです。
TOS 0 metric
The cost of using this router link for TOS 0.
TOS0メートル法、TOS0にこのルータリンクを使用する費用
For each link, separate metrics may be specified for each Type of Service (TOS). The metric for TOS 0 must always be included, and was discussed above. Metrics for non-zero TOS are described below. The encoding of TOS in OSPF link state advertisements is described in Section 12.3. Note that the cost for non-zero TOS values that are not specified defaults to the TOS 0 cost. Metrics must be listed in order of increasing TOS encoding. For example, the metric for TOS 16 must always follow the metric for TOS 8 when both are specified.
各リンクとして、別々の測定基準はService(TOS)の各Typeに指定されるかもしれません。 TOS0のためのメートル法について、いつも含まなければならなくて、上で議論しました。 非ゼロTOSのための測定基準は以下で説明されます。 OSPFリンク州の広告における、TOSのコード化はセクション12.3で説明されます。 指定されない非ゼロTOS値のための費用がTOS0費用をデフォルトとすることに注意してください。 TOSコード化を増強することの順に測定基準を記載しなければなりません。 両方が指定されるとき、例えば、TOS16のためのメートル法はいつもTOS8のためのメートル法に続かなければなりません。
TOS IP type of service that this metric refers to. The encoding of TOS
in OSPF link state advertisements is described in Section 12.3.
TOS IPはそんなにこれほどメートル法でサービスをタイプします。言及します。 OSPFリンク州の広告における、TOSのコード化はセクション12.3で説明されます。
metric
The cost of using this outbound router link, for traffic of the
メートル法、この外国行きのルータを使用する費用はトラフィックのためにリンクします。
[Moy] [Page 157] RFC 1247 OSPF Version 2 July 1991
[Moy][157ページ]RFC1247OSPFバージョン1991年7月2日
specified TOS.
指定されたTOS。
[Moy] [Page 158] RFC 1247 OSPF Version 2 July 1991
[Moy][158ページ]RFC1247OSPFバージョン1991年7月2日
A.4.3 Network links advertisements
A.4.3ネットワークは広告をリンクします。
Network links advertisements are the Type 2 link state advertisements. A network links advertisement is originated for each transit network in the area. A transit network is a multi-access network that has more than one attached router. The network links advertisement is originated by the network's Designated Router. The advertisement describes all routers attached to the network, including the Designated Router itself. The advertisement's Link State ID field lists the IP interface address of the Designated Router.
ネットワークリンク広告はType2リンク州の広告です。 ネットワークリンク広告はその領域のそれぞれのトランジットネットワークのために溯源されます。 トランジットネットワークは1つ以上の付属ルータがあるマルチアクセスネットワークです。 ネットワークリンク広告はネットワークのDesignated Routerによって溯源されます。 広告はDesignated Router自身を含むネットワークに付けられたすべてのルータについて説明します。 広告のLink州ID分野はDesignated RouterのIPインターフェース・アドレスを記載します。
The distance from the network to all attached routers is zero, for all types of service. This is why the TOS and metric fields need not be specified in the network links advertisement. For details concerning the construction of network links advertisements, see Section 12.4.2.
ネットワークから付属すべてのルータまでの距離はすべてのタイプのサービスのためのゼロです。 これはTOSとメートル法の分野がネットワークリンク広告で指定される必要はない理由です。 ネットワークリンク広告の工事に関する詳細に関しては、セクション12.4.2を見てください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attached Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS時代| オプション| 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 州のIDをリンクしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 広告ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSチェックサム| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ネットワークマスク| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 付属ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
Network Mask
The IP address mask for the network. For example, a class A network
would have the mask 0xff000000.
アドレスがネットワークのためにマスクをかけるMask IPをネットワークでつないでください。 例えば、クラスAネットワークには、マスク0xff000000があるでしょう。
Attached Router
The Router IDs of each of the routers attached to the network.
Actually, only those routers that are fully adjacent to the
Designated Router are listed. The Designated Router includes itself
in this list. The number of routers included can be deduced from
the link state advertisement's length field.
それぞれのルータの付属Router Router IDはネットワークに付きました。 それは完全にそうです。実際にそれらのルータだけ、記載されたDesignated Routerに隣接して。 Designated Routerはこのリストにそれ自体を含んでいます。 リンク州の広告の長さの分野からルータを含む数を推論できます。
[Moy] [Page 159] RFC 1247 OSPF Version 2 July 1991
[Moy][159ページ]RFC1247OSPFバージョン1991年7月2日
A.4.4 Summary link advertisements
A.4.4概要リンク広告
Summary link advertisements are the Type 3 and 4 link state advertisements. These advertisements are originated by area border routers. A separate summary link advertisement is made for each destination (known to the router) which belongs to the AS, yet is outside the area. For details concerning the construction of summary link advertisements, see Section 12.4.3.
概要リンク広告はType3と4リンク州の広告です。 これらの広告は境界ルータによって溯源されます。 別々の概要リンク広告はASに属しますが、領域の外にある各目的地(ルータに知られている)に作られています。 概要リンク広告の工事に関する詳細に関しては、セクション12.4.3を見てください。
Type 3 link state advertisements are used when the destination is an IP network. In this case the advertisement's Link State ID field is an IP network number. When the destination is an AS boundary router, a Type 4 advertisement 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 link state advertisements is identical.
目的地がIPネットワークであるときに、タイプ3リンク州の広告は使用されています。 この場合、広告のLink州ID分野はIPネットワーク・ナンバーです。 目的地がAS境界ルータであるときに、Type4広告は使用されています、そして、Link州ID分野はAS境界ルータのOSPF Router IDです。 (それぞれのASBRの位置の広告を出すのがなぜ必要であるかを確認するには、セクション16.4に相談してください。) Link州ID分野の違いを除いて、Type3と4リンク州の広告の形式は同じです。
For stub areas, type 3 summary link advertisements 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 advertisement'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概要リンク広告を使用できます。 デフォルト概要ルートは完全な外部経路をあふれさせることの代わりにスタッブ領域で使用されます。 デフォルト概要ルートを説明するとき、広告のLink州IDがいつもDefaultDestinationに設定される、(0.0、.0、.0と)Network Maskは.0に0.0に.0を設定することです。
Separate costs may be advertised for each IP Type of Service. The encoding of TOS in OSPF link state advertisements is described in Section 12.3. Note that the cost for TOS 0 must be included, and is always listed first. If the T-bit is reset in the advertisement's Option field, only a route for TOS 0 is described by the advertisement. Otherwise, routes for the other TOS values are also described; if a cost for a certain TOS is not included, its cost defaults to that specified for TOS 0.
ServiceのそれぞれのIP Typeのために別々のコストの広告を出すかもしれません。 OSPFリンク州の広告における、TOSのコード化はセクション12.3で説明されます。 TOS0のための費用が含まなければならなくて、最初にいつも記載されることに注意してください。 T-ビットが広告のOption分野にリセットされるなら、TOS0のためのルートだけが広告で説明されます。 また、さもなければ、他のTOS値のためのルートは説明されます。 あるTOSのための費用が含まれていないなら、費用はTOS0に指定されたそれをデフォルトとします。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS時代| オプション| 3か4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 州のIDをリンクしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 広告ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSチェックサム| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[Moy] [Page 160] RFC 1247 OSPF Version 2 July 1991
[Moy][160ページ]RFC1247OSPFバージョン1991年7月2日
| Network Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOS | metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
| ネットワークマスク| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOS| メートル法| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
Network Mask
For Type 3 link state advertisements, this indicates the
destination's IP network 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 link state
advertisements.
ネットワークMask For Type3は州の広告をリンクして、これは目的地のIPネットワークマスクを示します。 クラスAネットワークの位置の広告を出すとき、例えば、値の0xff000000は使用されるでしょう。 この分野は、重要でなく、Type4リンク州の広告のためのゼロでなければなりません。
For each specified type of service, the following fields are defined. The number of TOS routes included can be calculated from the link state advertisement's length field. Values for TOS 0 must be specified; they are listed first. Other values must be listed in order of increasing TOS encoding. For example, the cost for TOS 16 must always follow the cost for TOS 8 when both are specified.
それぞれの指定されたタイプのサービスにおいて、以下の分野は定義されます。 リンク州の広告の長さの分野からTOSルートを含む数について計算できます。 TOS0のための値を指定しなければなりません。 それらは最初に、記載されます。 TOSコード化を増強することの順に他の値を記載しなければなりません。 両方が指定されるとき、例えば、TOS16のための費用はいつもTOS8のための費用に続かなければなりません。
TOS The Type of Service that the following cost concerns. The encoding
of TOS in OSPF link state advertisements is described in Section
12.3.
以下の費用が関するServiceのTOS Type。 OSPFリンク州の広告における、TOSのコード化はセクション12.3で説明されます。
metric
The cost of this route. Expressed in the same units as the
interface costs in the router links advertisements.
メートル法、このルートの費用。 同じくらいで言い表されて、ルータにおけるインタフェースコストとしてのユニットは広告をリンクします。
[Moy] [Page 161] RFC 1247 OSPF Version 2 July 1991
[Moy][161ページ]RFC1247OSPFバージョン1991年7月2日
A.4.5 AS external link advertisements
A.4.5 ASの外部のリンク広告
AS external link advertisements are the Type 5 link state advertisements. These advertisements are originated by AS boundary routers. A separate advertisement is made for each destination (known to the router) which is external to the AS. For details concerning the construction of AS external link advertisements, see Section 12.4.3.
ASの外部のリンク広告はType5リンク州の広告です。 これらの広告はAS境界ルータによって溯源されます。 別々の広告はASに外部であることのそれぞれの目的地(ルータに知られている)に作られています。 ASの外部のリンク広告の工事に関する詳細に関しては、セクション12.4.3を見てください。
AS external link advertisements usually describe a particular external destination. For these advertisements the Link State ID field specifies an IP network number. AS external link advertisements 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の外部のリンク広告は特定の外部の目的地について説明します。 これらの広告として、Link州ID分野はIPネットワーク・ナンバーを指定します。 また、ASの外部のリンク広告は、デフォルトルートを説明するのに使用されます。 どんな特定のルートも目的地に存在しないとき、デフォルトルートは使用されています。 デフォルトルートを説明するとき、Link州IDがいつもDefaultDestinationに設定される、(0.0、.0、.0と)Network Maskは.0に0.0に.0を設定することです。
Separate costs may be advertised for each IP Type of Service. The encoding of TOS in OSPF link state advertisements is described in Section 12.3. Note that the cost for TOS 0 must be included, and is always listed first. If the T-bit is reset in the advertisement's Option field, only a route for TOS 0 is described by the advertisement. Otherwise, routes for the other TOS values are also described; if a cost for a certain TOS is not included, its cost defaults to that specified for TOS 0.
ServiceのそれぞれのIP Typeのために別々のコストの広告を出すかもしれません。 OSPFリンク州の広告における、TOSのコード化はセクション12.3で説明されます。 TOS0のための費用が含まなければならなくて、最初にいつも記載されることに注意してください。 T-ビットが広告のOption分野にリセットされるなら、TOS0のためのルートだけが広告で説明されます。 また、さもなければ、他のTOS値のためのルートは説明されます。 あるTOSのための費用が含まれていないなら、費用はTOS0に指定されたそれをデフォルトとします。
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| TOS | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forwarding address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Route Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS時代| オプション| 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 州のIDをリンクしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 広告ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSチェックサム| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ネットワークマスク| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| TOS| メートル法| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | フォーワーディング・アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 外部経路タグ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
[Moy] [Page 162] RFC 1247 OSPF Version 2 July 1991
[Moy][162ページ]RFC1247OSPFバージョン1991年7月2日
Network Mask
The IP network mask for the advertised destination. For example,
when advertising a class A network the mask 0xff000000 would be
used.
ネットワークMask IPは広告を出している目的地にマスクをネットワークでつなぎます。 クラスAネットワークの広告を出すとき、例えば、マスク0xff000000は使用されるでしょう。
For each specified type of service, the following fields are defined. The number of TOS routes included can be calculated from the link state advertisement's length field. Values for TOS 0 must be specified; they are listed first. Other values must be listed in order of increasing TOS encoding. For example, the cost for TOS 16 must always follow the cost for TOS 8 when both are specified.
それぞれの指定されたタイプのサービスにおいて、以下の分野は定義されます。 リンク州の広告の長さの分野からTOSルートを含む数について計算できます。 TOS0のための値を指定しなければなりません。 それらは最初に、記載されます。 TOSコード化を増強することの順に他の値を記載しなければなりません。 両方が指定されるとき、例えば、TOS16のための費用はいつもTOS8のための費用に続かなければなりません。
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 is is
comparable directly (without translation) to the link state metric.
外部のタイプのEに噛み付いて、メートル法にしました。 ビットEが設定されるなら、指定されたメートル法はa Type2外部メートル法です。 これは、メートル法がどんなリンク州の経路よりも大きいと考えられることを意味します。 噛み付かれるならEがゼロである、メートル法で指定されて、Type1外部はメートル法ですか? この手段は直接(翻訳なしで)リンク状態にメートル法で匹敵しています。
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 advertisement's originator
(i.e., the responsible AS boundary router).
広告を出している目的地へのフォーワーディング・アドレスDataトラフィックをこのアドレスに送るでしょう。 Forwardingであるならアドレスを設定します。0.0 .0 .0 代わりに広告の創始者(すなわち、原因となるAS境界ルータ)にデータ通信量を送るでしょう。
TOS The Type of Service that the following cost concerns. The encoding
of TOS in OSPF link state advertisements is described in Section
12.3.
以下の費用が関するServiceのTOS Type。 OSPFリンク州の広告における、TOSのコード化はセクション12.3で説明されます。
metric
The cost of this route. Interpretation depends on the external type
indication (bit E above).
メートル法、このルートの費用。 解釈は外部のタイプ指示(上のEに噛み付く)によります。
External Route Tag
A 32-bit field attached to each external route. This is not used by
the OSPF protocol itself. It may be used to communicate information
between AS boundary routers; the precise nature of such information
is outside the scope of this specification.
外部のRoute Tag A32ビットの分野は各外部経路に付きました。 これはOSPFプロトコル自体によって使用されません。 それはAS境界ルータの間の情報を伝えるのに使用されるかもしれません。 この仕様の範囲の外にそのような情報の正確な本質があります。
[Moy] [Page 163] RFC 1247 OSPF Version 2 July 1991
[Moy][163ページ]RFC1247OSPFバージョン1991年7月2日
B. Architectural Constants
B。 建築定数
Several OSPF protocol parameters have fixed architectural values. These parameters have been referred to in the text by names such as LSRefreshTimer. The same naming convention is used for the configurable protocol parameters. They are defined in appendix C.
いくつかのOSPFプロトコルパラメタが建築的価値を修理しました。 これらのパラメタはテキストにLSRefreshTimerなどの名前によって示されました。 同じ命名規則は構成可能なプロトコルパラメタに使用されます。 それらは付録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
link state advertisement. For each link state advertisement that a
router originates, an interval timer should be set to this value.
Firing of this timer causes a new instance of the link state
advertisement to be originated. The value of LSRefreshTime is set
to 30 minutes.
異なった創作の間のどんな特定のリンク州の広告の最大の時間のLSRefreshTime。 ルータが溯源するそれぞれのリンク州の広告において、インタバルタイマはこの値に設定されるべきです。 このタイマの発火で、リンク州の広告の新しいインスタンスを溯源します。 LSRefreshTimeの値は30分に設定されます。
MinLSInterval
The minimum time between distinct originations of any particular
link state advertisement. The value of MinLSInterval is set to 5
seconds.
異なった創作の間のどんな特定のリンク州の広告の最小の時間のMinLSInterval。 MinLSIntervalの値は5秒に設定されます。
MaxAge
The maximum age that a link state advertisement can attain. When an
advertisement's age reaches MaxAge, it is reflooded. It is then
removed from the database as soon as this flood is acknowledged,
i.e., as soon as it has been removed from all neighbor Link state
retransmission lists. Advertisements having age MaxAge are not used
in the routing table calculation. The value of MaxAge must be
greater than LSRefreshTime. The value of MaxAge is set to 1 hour.
リンク州の広告が達することができる最大の時代のMaxAge。 広告の時代がMaxAgeに達するとき、それは「再-あふれ」ます。 次に、この洪水が承認されるとすぐに、データベースからそれを取り除きます、すべての隣人Link州の「再-トランスミッション」リストからそれを取り除くとすぐにすなわち、。 時代MaxAgeを持っている広告が経路指定テーブル計算に使用されません。 MaxAgeの値はLSRefreshTimeより大きいに違いありません。 MaxAgeの値は1時間に設定されます。
CheckAge
When the age of a link state advertisement (that is contained in the
link state database) hits a multiple of CheckAge, the
advertisement's checksum is verified. An incorrect checksum at this
time indicates a serious error. The value of CheckAge is set to 5
minutes.
リンク州の広告(すなわち、リンク州のデータベースでは、含まれている)の時代のCheckAge WhenはCheckAgeの倍数に当って、広告のチェックサムは確かめられます。 不正確なチェックサムはこのとき、重大な誤りを示します。 CheckAgeの値は5分に設定されます。
MaxAgeDiff
The maximum time dispersion that can occur, as a link state
advertisement is flooded throughout the AS. Most of this time is
accounted for by the link state advertisements sitting on router
output queues (and therefore not aging) during the flooding process.
The value of MaxAgeDiff is set to 15 minutes.
MaxAgeDiff、リンク州の広告がAS中で水につかっているとき起こることができる最大の時間分散。 この時間の大部分は氾濫プロセスの間にルータ出力キュー(したがって、年をとらないで)に座るリンク州の広告で説明されます。 MaxAgeDiffの値は15分に設定されます。
[Moy] [Page 164] RFC 1247 OSPF Version 2 July 1991
[Moy][164ページ]RFC1247OSPFバージョン1991年7月2日
LSInfinity
The link state metric value indicating that the destination is
unreachable. It is defined to be the binary value of all ones. It
depends on the size of the metric field, which is 16 bits in router
links advertisements, and 24 bits in both summary and AS external
links advertisements.
LSInfinity、目的地が手が届かないのを示すリンク州のメートル法の値。 それは、すべてのものの2進の値になるように定義されます。 場合によりけりです、メートル法の分野のサイズでどれがルータで16ビットであるかは両方の概要とASの外部のリンク広告で広告、および24ビットをリンクします。
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 link
advertisements and in type 3 summary link advertisements for stub
areas. Its value is the IP address 0.0.0.0.
デフォルトルートを示すDefaultDestination Destination ID。 他の合っている経路指定テーブルエントリーを全く見つけることができないとき、このルートは使用されています。 ASの外部のリンク広告とスタッブ領域へのタイプ3概要リンク広告にデフォルトの目的地の広告を出すことができるだけです。 値はIPアドレス0.0.0.0です。
[Moy] [Page 165] RFC 1247 OSPF Version 2 July 1991
[Moy][165ページ]RFC1247OSPFバージョン1991年7月2日
C. Configurable Constants
C。 構成可能な定数
The OSPF protocol has quite a few configurable parameters. These parameters are listed below. They are grouped into general functional categories (area parameters, interface parameters, etc.). Sample values are given for some of the parameters.
OSPFプロトコルには、かなり多くの構成可能なパラメタがあります。 これらのパラメタは以下にリストアップされています。 それらは一般的な機能的なカテゴリ(領域パラメタ、インタフェース・パラメータなど)に分類されます。 パラメタのいくつかのために標本値を与えます。
Some parameter settings need to be consistent among groups of routers. For example, all routers in an area must agree on that area's parameters, and all routers attached to a network must agree on that network's IP network number and mask.
いくつかのパラメタ設定が、ルータのグループで一貫している必要があります。 例えば、領域のすべてのルータがその領域のパラメタに同意しなければなりません、そして、ネットワークに付けられたすべてのルータがそのネットワークのIPネットワーク・ナンバーとマスクに同意しなければなりません。
Some parameters may be determined by router algorithms outside of this specification (e.g., the address of a host connected to the router via a SLIP line). From OSPF's point of view, these items are still configurable.
いくつかのパラメタがこの仕様の外でルータアルゴリズムで決定するかもしれません(例えばホストのアドレスはSLIP系列でルータに接続しました)。 OSPFの観点から、これらの項目はまだ構成可能です。
C.1 Global parameters
C.1のグローバルなパラメタ
In general, a separate copy of the OSPF protocol is run for each area. Because of this, most configuration parameters are defined on a per-area basis. The few global configuration parameters are listed below.
一般に、OSPFプロトコルの別々のコピーは各領域に動かされます。 これのために、ほとんどの設定パラメータが地域制で定義されます。 わずかなグローバルな設定パラメータが以下にリストアップされています。
Router ID
This is a 32-bit number that uniquely identifies the router in the
Autonomous System. One algorithm for Router ID assignment is to
choose the largest or smallest IP address assigned to the router.
If a router's OSPF Router ID is changed, the router's OSPF software
should be restarted before the new Router ID takes effect.
ルータID ThisはAutonomous Systemで唯一ルータを特定する32ビットの数です。 Router ID課題のための1つのアルゴリズムは最も大きいかルータに割り当てられる中で最も小さいIPアドレスを選ぶことです。 ルータのOSPF Router IDを変えるなら、新しいRouter IDが効く前にルータのOSPFソフトウェアを再開するべきです。
TOS capability
This item indicates whether the router will calculate separate
routes based on TOS. For more information, see Sections 4.5 and
16.9.
TOS能力Thisの品目は、ルータがTOSに基づく別々のルートを計算するかどうかを示します。 詳しくは、セクション4.5と16.9を見てください。
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 traffic. The following items must be configured for an area:
領域に属すすべてのルータがその領域の構成に同意しなければなりません。 2つのルータの不一致はそれらの間で隣接番組を形成できないことにつながるでしょう、ルーティング・プロトコルトラフィックの流れへの結果として起こる妨害で。 以下の項目を領域に構成しなければなりません:
[Moy] [Page 166] RFC 1247 OSPF Version 2 July 1991
[Moy][166ページ]RFC1247OSPFバージョン1991年7月2日
Area ID
This is a 32-bit number that identifies the area. The Area ID of 0
is reserved for the backbone. If the area represents a subnetted
network, the IP network number of the subnetted network may be used
for the area ID.
領域ID Thisは領域を特定する32ビットの数です。 0のArea IDはバックボーンのために予約されます。 領域がサブネット化したネットワークを代表するなら、サブネット化したネットワークのIPネットワーク・ナンバーは領域IDに使用されるかもしれません。
List of address ranges
An OSPF area is defined as a list of [IP address, mask] pairs. Each
pair describes a range of IP addresses. 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. Routing information is condensed at area
boundaries. External to the area, a single route is advertised for
each address range.
アドレス範囲An OSPF部門のリストは[IPアドレス、マスク]組のリストと定義されます。 各組はさまざまなIPアドレスについて説明します。 ネットワークとホストは彼らのアドレスが、領域がアドレスの範囲を定義するものになるかどうかによる領域に選任されます。 ルータはそれらの付属ネットワークの領域会員資格によって、複数の領域に属すと見なされます。 ルート設定情報はエリアの境界で凝縮します。 その領域に外部であり、それぞれのアドレスの範囲にただ一つのルートの広告を出します。
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 internet mask. A single route would
be advertised external to the area, describing the entire subnetted
network.
例として、IPサブネット化したネットワークによるそれ自身のOSPF領域であることになっていると仮定してください。 領域はマスクがIPアドレスがサブネット化したネットワークのアドレスであり、自然類A、B、またはCインターネットマスクであるただ一つのアドレスの範囲として構成されるでしょう。 全体のサブネット化したネットワークについて説明して、ただ一つのルートのその領域に外部であることの形で広告を出すでしょう。
Authentication type
Each area can be configured for a separate type of
authentication. See Appendix E for a discussion of the
defined authentication types.
別々のタイプの認証のために認証タイプEach領域を構成できます。 定義された認証の議論のためのAppendix Eがタイプするのを確実にしてください。
External routing capability
Whether AS external advertisements will be flooded into/throughout
the area. If AS external advertisements 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.
外部のルーティング能力Whether AS外部の広告は領域中に/へあふれるでしょう。 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 link that the router should
advertise into the area. There can be a separate cost configured
for each IP TOS. See Section 12.4.3 for more information.
StubDefaultCost If、ルータ自体が境界ルータである、領域はスタッブ領域として構成されて、次に、StubDefaultCostはルータが領域に広告を出すべきであるデフォルト概要リンクの費用を示します。 各IP TOSのために構成された別々の費用があることができます。 詳しい情報に関してセクション12.4.3を見てください。
[Moy] [Page 167] RFC 1247 OSPF Version 2 July 1991
[Moy][167ページ]RFC1247OSPFバージョン1991年7月2日
C.3 Router interface parameters
C.3ルータインタフェース・パラメータ
Some of the configurable router interface parameters (such as IP interface address and subnet mask) actually imply properties of the attached networks, and therefore must be consistent across all the routers attached to that network. The parameters that must be configured for a router interface are:
構成可能なルータインタフェース・パラメータ(IPインターフェース・アドレスやサブネットマスクなどの)のいくつかが、実際に付属ネットワークの特性を含意して、したがって、そのネットワークに付けられたすべてのルータの向こう側に一貫しているに違いありません。 ルータインタフェースに構成しなければならないパラメタは以下の通りです。
IP interface address
The IP protocol address for this interface. This uniquely
identifies the router over the entire internet. An IP address is
not required on serial lines. Such a serial line is called
"unnumbered".
IPインタフェースは、IPプロトコルがこのインタフェースへのアドレスであると扱います。 これは全体のインターネットの上で唯一ルータを特定します。 IPアドレスはシリアル・ラインの上で必要ではありません。 そのようなシリアル・ラインは「無数である」と呼ばれます。
IP interface mask
This denotes the portion of the IP interface address that
identifies the attached network. This is often referred to
as the subnet mask.
IPインタフェースマスクThisは付属ネットワークを特定するIPインターフェース・アドレスの部分を指示します。 これはしばしばサブネットマスクと呼ばれます。
Interface output cost(s)
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 links advertisement. There may be
a separate cost for each IP Type of Service. The interface output
cost(s) must always be greater than 0.
インタフェース出力は(s) リンク状態でメートル法で言い表されたインタフェースにパケットを送る費用かかります。 ルータのルータにおけるこのインタフェースへのリンク費用が広告をリンクするとき、これの広告を出します。 ServiceのそれぞれのIP Typeのための別々の費用があるかもしれません。 いつもインタフェース製作費は0以上であるに違いありません。
RxmtInterval
The number of seconds between link state advertisement
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. It will need to be larger on low speed serial lines and
virtual links. Sample value for a local area network: 5 seconds.
間の秒数がリンクするRxmtIntervalはこのインタフェースに属す隣接番組のために広告「再-トランスミッション」を述べます。 また、Database記述とLink州Request Packetsを再送するとき、使用されます。 付属ネットワークのどんな2つのルータの間にはも、予想された往復の遅れのかなり上にこれはあるべきです。 この価値の設定が保守的であるべきですか、または不必要な「再-トランスミッション」は結果として生じるでしょう。 それは、低速シリアル・ラインと仮想のリンクでは、より大きい必要があるでしょう。 ローカル・エリア・ネットワークのために値を抽出してください: 5秒。
InfTransDelay
The estimated number of seconds it takes to transmit a Link State
Update Packet over this interface. Link state advertisements
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 for the interface.
It must be greater than 0. Sample value for a local area network: 1
second.
概算のInfTransDelayは、Link州Update Packetをこのインタフェースの上に伝えるのにそれがかかる秒に付番します。 アップデートパケットに含まれたリンク州の広告で、トランスミッションの前にこの量で彼らの時代を増加しなければなりません。 この値はトランスミッションと伝播遅延をインタフェースに考慮に入れるべきです。 それは0以上であるに違いありません。 ローカル・エリア・ネットワークのために値を抽出してください: 1 2番目に。
Router Priority
An 8-bit unsigned integer. When two routers attached to a network
ルータPriority An、8ビットの符号のない整数。 2つのルータがネットワークに付いたとき
[Moy] [Page 168] RFC 1247 OSPF Version 2 July 1991
[Moy][168ページ]RFC1247OSPFバージョン1991年7月2日
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 multi-access networks.
両方が、Designated Routerになるのを試みて、最も高いRouter Priorityがあるものは優先します。 繋がりがまだあれば、最も高いRouter IDがあるルータは優先します。 Router Priorityが0に用意ができているルータは付属ネットワークでDesignated Routerになるのにおいて不適格です。 ルータPriorityはマルチアクセスネットワークへのインタフェースに構成されるだけです。
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 hello interval, the
faster topological changes will be detected, but more routing
traffic will ensue. Sample value for a X.25 PDN network: 30
seconds. Sample value for a local area network: 10 seconds.
ルータがインタフェースで送るHelloパケットの間の秒の時間の長さのHelloInterval。 ルータのHelloパケットにこの値の広告を出します。 一般的なネットワークに付けられたすべてのルータに、それは同じであるに違いありません。 より小さい、こんにちは、間隔、より速い位相的な変化は検出されるでしょうが、より多くのルーティングトラフィックが続くでしょう。 X.25 PDNネットワークのために値を抽出してください: 30秒。 ローカル・エリア・ネットワークのために値を抽出してください: 10秒。
RouterDeadInterval
The number of seconds that a router's Hellos have not been seen
before its neighbors declare the router down. This is also
advertised in the router's Hello Packets in the DeadInt 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、隣人がルータを宣言する前にルータのハローズが見られていない秒の数はダウンします。 また、DeadInt分野のルータのHello Packetsにこれの広告を出します。 これはHelloIntervalの何らかの倍数であるべきです(4を言ってください)。 一般的なネットワークに付けられたすべてのルータには、この値は再び同じでなければなりません。
Authentication key
This configured data allows the authentication procedure to generate
and/or verify the authentication field in the OSPF header. For
example, if the authentication type indicates simple password, the
authentication key would be a 64-bit password. This key would be
inserted directly into the OSPF header when originating routing
protocol packets. There could be a separate password for each
network.
認証の主要なThisは、認証手順がOSPFヘッダーの認証分野について生成する、そして/または、データで確かめることができるのを構成しました。 例えば、認証タイプが簡単なパスワードを示すなら、認証キーは64ビットのパスワードでしょう。 ルーティング・プロトコルパケットを溯源するとき、このキーは直接OSPFヘッダーに差し込まれるでしょう。 各ネットワークのための別々のパスワードがあるかもしれません。
C.4 Virtual link parameters
C.4の仮想のリンクパラメータ
Virtual links are used to restore/increase connectivity of the backbone. Virtual links may be configured between any pair of area border routers having interfaces to a common (non-backbone) area. The virtual link appears as an unnumbered point-to-point link in the graph for the backbone. The virtual link must be configured in both of the area border routers.
仮想のリンクは、バックボーンの接続性を回復するか、または増強するのに使用されます。 仮想のリンクは、一般的な(非バックボーンの)領域にインタフェースを持ちながら、どんな組の境界ルータの間でも構成されるかもしれません。 仮想のリンクは無数のポイントツーポイント接続としてバックボーンのためのグラフに現れます。 境界ルータの両方で仮想のリンクを構成しなければなりません。
A virtual link appears in router links advertisements (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 protocol packets it sends along the
仮想のリンクはまるでそれがバックボーンへの別々のルータインタフェースであるかのようにルータリンク広告(バックボーンのための)に現れます。 そういうものとして、それには、ルータインタフェースに関連しているパラメタのすべてがあります(セクションC.3を見てください)。 仮想のリンクはポイントへの無数のポイントリンクのように作動しますが、それには、関連IPインターフェース・アドレスがあります。 このアドレスはそれが送るプロトコルパケットのIPソースとして使用されます。
[Moy] [Page 169] RFC 1247 OSPF Version 2 July 1991
[Moy][169ページ]RFC1247OSPFバージョン1991年7月2日
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.
仮想であることは、リンクして、セットが経路指定テーブルの間、ダイナミックにプロセスを建てるということです。 また、仮想のリンクは、2つのルータの間のイントラ領域経路の費用になるようにダイナミックにインタフェース製作費にけしかけられます。 パラメタRxmtIntervalは構成しなければならなくて、2つのルータの間には、予想された往復の遅れのかなり上にあるはずです。 これは仮想のリンクに見積もっているのが困難であるかもしれません。 それを大きくし過ぎることの側で間違えるほうがよいです。 ルータPriorityは仮想のリンクの上に使用されません。
A virtual link is defined by the following two configurable parameters: the Router ID of the virtual link's other endpoint, and the (non- backbone) area through which the virtual link runs (referred to as the virtual link's transit area). Virtual links cannot be configured through stub areas.
仮想のリンクは以下の2つの構成可能なパラメタによって定義されます: 仮想のリンクの他の終点のRouter ID、および仮想のリンクが動く(非バックボーン)の領域(仮想のリンクのトランジット領域と呼ばれます)。 スタッブ領域を通って仮想のリンクを構成できません。
C.5 Non-broadcast, multi-access network parameters
C.5の非放送であって、マルチアクセスしている回路パラメータ
OSPF treats a non-broadcast, multi-access network much like it treats a broadcast network. Since there many be many routers attached to the network, a Designated Router is selected for the network. This Designated Router then originates a networks links advertisement, which lists all routers attached to the non-broadcast network.
放送網を扱うようにOSPFは非放送であって、マルチアクセスしているネットワークを扱います。 そこ以来の多く、ネットワークに付けられた、多くのルータになってください、そして、Designated Routerはネットワークのために選択されます。 そして、このDesignated Routerはネットワークリンク広告を溯源します。(それは、非放送網に付けられたすべてのルータを記載します)。
However, due to the lack of broadcast capabilities, it is necessary to use configuration parameters in the Designated Router selection. These parameters need only be configured in those routers that are themselves eligible to become Designated Router (i.e., those router's whose DR Priority for the network is non-zero):
しかしながら、放送能力の不足のために、Designated Router選択に設定パラメータを使用するのが必要です。 これらのパラメタはそれらのDesignated Router(すなわち、ネットワークのためのDR Priorityが非ゼロであるルータのそれらのもの)になるのが自分たちで適任のルータで構成されるだけでよいです:
List of all other attached routers
The list of all other routers attached to the non-broadcast 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 non-
broadcast 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.
他のリストは他のすべてのルータのリストが非放送網に付けたルータを付けました。 各ルータはIPインターフェース・アドレスによってネットワークに記載されます。 Designated Routerになる各ルータが記載したのでそのルータのも適任を定義しなければなりません。 非放送網へのインタフェースが来るとき、ルータはDesignated Routerになるのが適任のそれらの隣人だけへのパケットをHelloに送ります、Designated Routerのアイデンティティが発見されるまで。
PollInterval
If a neighboring router has become inactive (hellos have not been
seen for RouterDeadInterval seconds), it may still be necessary to
send Hellos to the dead neighbor. These Hellos will be sent at the
reduced rate PollInterval, which should be much larger than
HelloInterval. Sample value for a PDN X.25 network: 2 minutes.
PollInterval Ifのa隣接しているルータは不活発になって(hellosはRouterDeadInterval秒の間、見られていません)、死んでいる隣人にハローズを送るのがまだ必要であるかもしれません。 割引料金PollIntervalでこれらのハローズを送るでしょう。(PollIntervalはHelloIntervalよりはるかに大きいはずです)。 PDN X.25ネットワークのために値を抽出してください: 2 書き留めます。
[Moy] [Page 170] RFC 1247 OSPF Version 2 July 1991
[Moy][170ページ]RFC1247OSPFバージョン1991年7月2日
C.6 Host route parameters
C.6ホストルートパラメタ
Host routes are advertised in network links advertisements 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:
スタッブネットワークとしてネットワークリンク広告にマスク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. There may be multiple costs configured, one for each IP
TOS. However, since the host probably has only a single connection
to the internet, the actual configured cost(s) in many cases is
unimportant (i.e., will have no effect on routing).
メートル法でリンク状態に関してパケットをホストに送る費用を接待するリンクの費用。 構成された複数のコスト、各IP TOSあたり1つがあるかもしれません。 しかしながら、ホストがたぶんインターネットに単独結合しか持っていないので、多くの場合、実際の構成された費用は重要ではありません(すなわち、ルーティングでは、効き目がないでしょう)。
[Moy] [Page 171] RFC 1247 OSPF Version 2 July 1991
[Moy][171ページ]RFC1247OSPFバージョン1991年7月2日
D. Required Statistics
D。 必要な統計
An OSPF implementation must provide a minimum set of statistics indicating the operational state of the protocol. These statistics must be accessible to the user; this will probably be accomplished through some sort of network management interface.
OSPF実装はプロトコルの操作上の事情を示す最小のセットの統計を提供しなければなりません。 ユーザにとって、これらの統計はアクセスしやすいに違いありません。 これはたぶんある種のネットワークマネージメントインタフェースを通して達成されるでしょう。
It is hoped that these statistics will aid in the debugging of the implementation, and in the analysis of the protocol's performance.
これらの統計が実装のデバッグ、およびプロトコルの性能の分析で支援されることが望まれています。
The statistics can be broken into two broad categories. The first consists of what we will call logging messages. These are messages produced in real time, with generally a single message produced as the result of a single protocol event. Such messages are also commonly referred to as traps.
2つの広いカテゴリを統計に細かく分けることができます。 1番目は私たちがメッセージを登録すると呼ぶつもりであることから成ります。 これらはリアルタイムで出されたメッセージです、一般にただ一つのメッセージがただ一つのプロトコルイベントの結果として出されている状態で。 また、そのようなメッセージは一般的に罠と呼ばれます。
The second category will be referred to as cumulative statistics. These are counters whose value have collected over time, such as the count of link state retransmissions over the last hour. Also falling into this category are dumps of the various routing data structures.
2番目のカテゴリは累積している統計と呼ばれるでしょう。 これらは値が時間がたつにつれて集まったカウンタです、最後の時間のリンク州の「再-トランスミッション」のカウントなどのように。 また、このカテゴリになるのは、様々なルーティングデータ構造の憂鬱です。
D.1 Logging messages
D.1伐採メッセージ
A logging message should be produced on every significant protocol event. The major events are listed below. Most of these events indicate a topological change in the routing domain. However, some number of logging messages can be expected even when the routing domain remains intact for long periods of time. For example, link state originations will still happen due to the link state refresh timer firing.
伐採メッセージはあらゆる重要なプロトコルイベントで出されるべきです。 主要なイベントは以下に記載されています。 これらのイベントの大部分は経路ドメインの位相的な変化を示します。 しかしながら、経路ドメインが長期間の間元の状態のままになるときさえ、何らかの数の伐採メッセージを予想できます。 例えば、それでも、リンク州の創作はタイマ発火をリフレッシュするのにおいてリンクが、述べる当然の状態で起こるでしょう。
Any of the messages that refer to link state advertisements should print the area associated with the advertisement. There is no area associated with AS external link advertisements.
リンク州の広告を参照するメッセージのいずれも広告に関連している領域を印刷するべきです。 ASの外部のリンク広告に関連しているどんな領域もありません。
The following list of logging messages indicate topological changes in the routing domain:
伐採メッセージの以下のリストは経路ドメインの位相的な変化を示します:
T1 The state of a router interface changes. Interface state changes
are documented in Section 9.3. In general, they will cause new link
state advertisements to be originated. The logging message produced
should include the interface's IP address (or other name), interface
type (virtual link, etc.) and old and new state values (as
documented in Section 9.1).
ルータの州が連結するT1は変化します。 界面準位変化はセクション9.3に記録されます。 一般に、彼らは新しいリンク州の広告を溯源させるでしょう。 出された伐採メッセージはインタフェースのIPアドレス(または、他の名前)、インターフェース型(仮想のリンクなど)、および年取って新しい州の値を含むべきです(セクション9.1に記録されるように)。
[Moy] [Page 172] RFC 1247 OSPF Version 2 July 1991
[Moy][172ページ]RFC1247OSPFバージョン1991年7月2日
T2 The state of a neighbor changes. Neighbor state changes are
documented in Section 10.3. The logging message produced should
include the neighbor IP address, and old and new state values.
隣人の州が変えるT2。 隣人州の変化はセクション10.3に記録されます。 出された伐採メッセージは隣人IPアドレス、および古くて新しい州の値を含むべきです。
T3 The (Backup) Designated Router has changed on one of the attached
networks. See Section 9.4. The logging message produced should
include the network IP address, and the old and new (Backup)
Designated Routers.
Routerに指定されたT3(バックアップ)は付属ネットワークの1つで変化しました。 セクション9.4を見てください。 出された伐採メッセージはネットワークIPアドレスを含むべきです、そして、古くて新しい(バックアップ)はRoutersを指定しました。
T4 The router is originating a new instance of a link state
advertisement. The logging message produced should indicate the LS
type, Link State ID and Advertising Router associated with the
advertisement (see Section 12.4).
T4、ルータはリンク州の広告の新しいインスタンスを溯源しています。 出された伐採メッセージは広告に関連しているLink州のLSタイプ、ID、およびAdvertising Routerを示すべきです(セクション12.4を見てください)。
T5 The router has received a new instance of a link state
advertisement. The router receives these in Link State Update
packets. This will cause recalculation of the routing table. The
logging message produced should indicate the advertisement's LS
type, Link State ID and Advertising Router. The message should also
include the neighbor from whom the advertisement was received.
T5、ルータはリンク州の広告の新しいインスタンスを受けました。 ルータはLink州Updateパケットでこれらを受けます。 これは経路指定テーブルの再計算を引き起こすでしょう。 出された伐採メッセージはLink州の広告のLSタイプ、ID、およびAdvertising Routerを示すべきです。 また、メッセージは広告が受け取られた隣人を含むべきです。
T6 An entry in the routing table has changed (see Section 11). The
logging message produced should indicate the Destination type,
Destination ID, and the old and new paths to the destination.
経路指定テーブルのエントリーが変えた(セクション11を見ます)T6。 出された伐採メッセージはDestinationタイプ、Destination ID、および年取って新しい経路を目的地に示すべきです。
The following logging messages may indicate that there is a network configuration error:
以下の伐採メッセージは、ネットワーク・コンフィギュレーション誤りがあるのを示すかもしれません:
C1 A received OSPF packet is rejected due to errors in its IP/OSPF
header. The reasons for rejection are documented in Section 8.2.
They include OSPF checksum failure, authentication failure, and
inability to match the source with an active OSPF neighbor. The
logging message produced should include the IP source and
destination addresses, the router ID in the OSPF header, and the
reason for the rejection.
C1のA容認されたOSPFパケットはIP/OSPFヘッダーの誤りのため拒絶されます。 拒絶の理由はセクション8.2に記録されます。 彼らはOSPFチェックサムの故障、認証失敗、および活発なOSPF隣人にソースを合わせることができないことを含んでいます。 出された伐採メッセージはIPソースと送付先アドレス、OSPFヘッダーのルータID、および拒絶の理由を含むべきです。
C2 An incoming Hello packet is rejected due to mismatches between the
Hello's parameters and those configured for the receiving interface
(see Section 10.5). This indicates a configuration problem on the
attached network. The logging message should include the Hello's
source, the receiving interface, and the non-matching parameters.
C2、入って来るHelloパケットはHelloのパラメタの間のミスマッチのため拒絶されて、受信のために構成されたものは連結します(セクション10.5を見てください)。 これは付属ネットワークで設定問題を示します。 伐採メッセージはHelloのソース、受信インタフェース、および非合っているパラメタを含むべきです。
C3 An incoming Database Description packet, Link State Request Packet,
Link State Acknowledgment Packet or Link State Update packet is
rejected due to the source neighbor being in the wrong state (see
Sections 10.6, 10.7, 13.7 , and 13 respectively). This can be
C3、入って来るDatabase記述パケット、Link州Request Packet、Link州Acknowledgment PacketまたはLink州Updateパケットが間違った状態にあるソース隣人のため拒絶されます(それぞれセクション10.6、10.7、13.7、および13を見てください)。 これはそうであることができます。
[Moy] [Page 173] RFC 1247 OSPF Version 2 July 1991
[Moy][173ページ]RFC1247OSPFバージョン1991年7月2日
normal when the identity of the network's Designated Router changes,
causing momentary disagreements over the validity of adjacencies.
The logging message should include the source neighbor, its state,
and the packet's type.
ネットワークのDesignated Routerのアイデンティティであるときに、隣接番組の正当性について瞬間の不一致を引き起こして、標準は変化します。 伐採メッセージはソース隣人、状態、およびパケットのタイプを含むべきです。
C4 A Database Description packet has been retransmitted. This may mean
that the value of RxmtInterval that has been configured for the
associated interface is too small. The logging message should
include the neighbor to whom the packet is being sent.
C4A Database記述パケットは再送されました。 これは、関連インタフェースに構成されたRxmtIntervalの値が小さ過ぎることを意味するかもしれません。 伐採メッセージはパケットが送られる隣人を含むべきです。
The following messages can be caused by packet transmission errors, or software errors in an OSPF implementation:
以下のメッセージはOSPF実装でパケット伝送誤り、またはソフトウェア誤りで引き起こされる場合があります:
E1 The checksum in a received link state advertisement is incorrect.
The advertisement is discarded (see Section 13). The logging
message should include the advertisement's LS type, Link State ID
and Advertising Router (which may be incorrect). The message should
also include the neighbor from whom the advertisement was received.
受け取られていているリンク州の広告におけるチェックサムは1E、不正確です。 広告は捨てられます(セクション13を見てください)。 伐採メッセージはLink州の広告のLSタイプ、ID、およびAdvertising Router(不正確であるかもしれない)を含むべきです。 また、メッセージは広告が受け取られた隣人を含むべきです。
E2 During the aging process, it is discovered that one of the link
state advertisements in the database has an incorrect checksum.
This indicates memory corruption or a software error in the router
itself. The router should be dumped and restarted.
古いプロセスの間の2E、データベースにおけるリンク州の広告の1つには不正確なチェックサムがあると発見されます。 これはメモリの誤りかルータ自体におけるソフトウェア誤りを示します。 ルータは、どさっと落とされて、再開されるべきです。
The following messages are an indication that a router has restarted, losing track of its previous LS sequence number. Should these messages continue, it may indicate the presence of duplicate Router IDs:
以下のメッセージは前のLS一連番号を見失って、ルータが再開したという指示です。 これらのメッセージが続くなら、写しRouter IDの存在を示すかもしれません:
R1 Two link state advertisements have been seen, whose LS type, Link
State ID, Advertising Router and LS sequence number are the same,
yet with differing LS checksums. These are considered to be
different instances of the same advertisement. The instance with
the larger checksum is accepted as more recent (see Section 12.1.7,
13.1). The logging message should include the LS type, Link State
ID, Advertising Router, LS sequence number and the two differing
checksums.
LSタイプ、広告は見られて、Link州ID、Advertising Router、およびLS一連番号は同じです、まだ異なったLSチェックサムで。2がリンクするR1は、これらが同じ広告の異なったインスタンスであると考えられると述べます。 より大きいチェックサムがあるインスタンスは、より最近として認められます(セクション12.1.7、13.1を見てください)。 伐採メッセージはLSタイプ、Link州ID、Advertising Router、LS一連番号、および2つの異なったチェックサムを含むべきです。
R2 Two link state advertisements have been seen, whose LS type, Link
State ID, Advertising Router, LS sequence number and LS checksum are
the same, yet can be distinguished by their LS age fields. This
means that one of the advertisement's LS age is MaxAge, or the two
LS age fields differ by more than MaxAgeDiff. The logging message
should include the LS type, Link State ID, Advertising Router, LS
sequence number and the two differing ages.
彼らのLS時代分野でまだ広告が持っている見られたR2Twoリンク状態(LSタイプ、Link州ID、Advertising Router、LS一連番号、およびLSチェックサムは同じである)は区別できます。 これは、広告のLS時代の1つがMaxAgeであるか2つのLS時代分野がMaxAgeDiff以上で異なることを意味します。 伐採メッセージはLSタイプ(州IDの、そして、Advertising Routerの、そして、LS一連番号の、そして、2回の異なった時代のLink)を含むべきです。
[Moy] [Page 174] RFC 1247 OSPF Version 2 July 1991
[Moy][174ページ]RFC1247OSPFバージョン1991年7月2日
R3 The router has received an instance of one of its self-originated
advertisements, that is considered to be more recent. This forces
the router to originate a new advertisement (see Section 13.4). The
logging message should include the advertisement's LS type, Link
State ID, and Advertising Router along with the neighbor from whom
the advertisement was received.
R3、ルータは自己によって溯源された広告の1つのインスタンスを受けて、それが、より最近であると考えられます。 これによって、ルータはやむを得ず新しい広告を溯源します(セクション13.4を見てください)。 伐採メッセージは広告が受け取られた隣人に伴うLink州の広告のLSタイプ、ID、およびAdvertising Routerを含むべきです。
R4 An acknowledgment has been received for an instance of an
advertisement that is not currently contained in the router's
database (see Section 13.7). The logging message should detail the
instance being acknowledged and the database copy (if any), along
with the neighbor from whom the acknowledgment was received.
R4、現在ルータのデータベースに含まれていない広告のインスタンスのために承認を受けました(セクション13.7を見てください)。 伐採メッセージは承認されるインスタンスと(もしあれば)のデータベースコピーについて詳述するべきです、承認が受けられた隣人と共に。
R5 An advertisement has been received through the flooding procedure
that is LESS recent the the router's current database copy (see
Section 13). The logging message should include the received
advertisement's LS type, Link State ID, Advertising Router, LS
sequence number, LS age and LS checksum. Also, the message should
display the neighbor from whom the advertisement was received.
R5、広告はLESS最近の氾濫手順で受け取って、ルータの現在のデータベースにコピーされるという(セクション13を見てください)ことです。 伐採メッセージは受け取られていている広告のLSタイプ、Link州ID、Advertising Router、LS一連番号、LS時代、およびLSチェックサムを含むべきです。 また、メッセージは広告が受け取られた隣人を表示するべきです。
The following messages are indication of normal, yet infrequent protocol events. These messages will help in the interpretation of some of the above messages:
以下のメッセージは正常で、しかし、珍しいプロトコルイベントのしるしです。 これらのメッセージはいくつかの上記のメッセージの解釈で助けるでしょう:
N1 The Link state refresh timer has fired for one of the router's
self-originated advertisements (see Section 12.4). A new instance
of the advertisement must be originated. The message should include
the advertisement's LS type, Link State ID and Advertising Router.
リフレッシュするLinkがタイマを述べるN1はルータの自己によって溯源された広告の1つのために発火しました(セクション12.4を見てください)。 広告の新しいインスタンスを溯源しなければなりません。 メッセージはLink州の広告のLSタイプ、ID、およびAdvertising Routerを含むべきです。
N2 One of the advertisements in the router's link state database has
aged to MaxAge (see Section 14). At this point, the advertisement
is no longer included in the routing table calculation, and is
reflooded. The message should list the advertisement's LS type,
Link State ID and Advertising Router.
ルータのリンク州のデータベースにおける広告のN2 1はMaxAgeに年をとりました(セクション14を見てください)。 ここに、広告は、もう経路指定テーブル計算に含まれていなくて、「再-あふれ」ます。 メッセージはLink州の広告のLSタイプ、ID、およびAdvertising Routerを記載するべきです。
N3 An advertisement of age MaxAge has been flushed from the router's
database. This occurs after the advertisement has been acknowledged
by all adjacent neighbors. The message should list the
advertisement's LS type, Link State ID and Advertising Router.
N3、時代MaxAgeの広告はルータのデータベースから洗い流されました。 広告がすべての隣接している隣人によって承諾された後にこれは起こります。 メッセージはLink州の広告のLSタイプ、ID、およびAdvertising Routerを記載するべきです。
D.2 Cumulative statistics
D.2の累積している統計
These statistics display collections of the routing data structures. They should be able to be obtained interactively, through some kind of network management facility.
これらの統計はルーティングデータ構造の収集を表示します。 彼らはある種のネットワークマネージメント施設でインタラクティブに得ることができるべきです。
[Moy] [Page 175] RFC 1247 OSPF Version 2 July 1991
[Moy][175ページ]RFC1247OSPFバージョン1991年7月2日
All the following statistics displays, with the exception of the area list, routing table and the AS external links, are specific to a single area. As noted in Section 4, most OSPF protocol mechanisms work on each area separately.
領域リスト以外の以下のすべての統計ディスプレイ(経路指定テーブルとASの外部のリンク)が、ただ一つの領域に特定です。 セクション4に述べられるように、ほとんどのOSPFプロトコルメカニズムが別々に各領域で動作します。
The following statistics displays should be available:
以下の統計ディスプレイは利用可能であるべきです:
(1) A list of all the areas attached to the router, along with the
authentication type to use for the area, the number of router
interfaces attaching to the area, and the total number of nets and
routers belonging to the area.
(1) すべての領域のリストは領域に使用する認証タイプ、その領域に付くルータインタフェースの数、および領域に属すネットとルータの総数に伴うルータに付きました。
For example, consider the router RT3 pictured in Figure 15. It has
interfaces to two separate areas, Area 1 and the backbone (Area 0).
Table 20 then indicates that the backbone is using a simple password
for authentication, and that Area 1 is not using any authentication.
The number of nets includes IP networks, subnets, and hosts (this is
the reason for 2 backbone nets -- they are the host routes
corresponding to the serial line between backbone routers RT6 and
RT10).
例えば、ルータが図15に描写されたRT3であると考えてください。 それは2つの分離した部分、Area1、およびバックボーン(領域0)にインタフェースを持っています。 そして、テーブル20は、バックボーンが認証に簡単なパスワードを使用していて、Area1が少しの認証も使用していないのを示します。 ネットの数はIPネットワーク、サブネット、およびホストを含んでいます(これは2つのバックボーンネットの理由です--それらはバックボーンルータのRT6とRT10の間のシリアル・ラインに対応するホストルートです)。
Area ID # ifcs AuType # nets # routers
______________________________________________
0 1 1 2 7
1 2 0 4 4
領域ID#ifcs AuType#ネット#ルータ______________________________________________ 0 1 1 2 7 1 2 0 4 4
Table 20: Sample OSPF area display.
テーブル20: OSPF領域ディスプレイを抽出してください。
(2) A list of all the router's interfaces to an area, along with their
addresses, output cost, current state, the (Backup) Designated
Router for the attached network, and the number of neighbors
currently associated with the interface. Some number of these
neighbors will have become adjacent, the number of these is noted in
the display also.
(2) それらのアドレスに伴う領域へのルータのインタフェースのリスト、製作費、現状、(バックアップ)は付属ネットワークのためのRouter、および現在インタフェースに関連している隣人の数を指定しました。 これらの隣人の何らかの数が隣接するようになってしまうでしょう、また、ディスプレイでこれらの数に注意します。
Again consider router RT3 in Figure 15. Table 21 below indicates
that RT4 has been selected as Designated Router for network N3, and
router RT1 has been selected as Backup. Adjacencies have been
established to both of these routers. There are no routers besides
RT3 attached to network N4, so it becomes DR, yet still advertises
the network as a stub in its router links advertisements.
図15でルータがRT3であるともう一度考えてください。 以下のテーブル21は、RT4がネットワークN3のためのDesignated Routerとして選定されて、ルータRT1がBackupとして選定されたのを示します。 隣接番組はこれらのルータの両方に確立されました。 ルータにおけるスタッブが広告をリンクするとき、ネットワークは、DRになって、ネットワークN4には添付のRT3以外にルータが全くそこでは、ないのはまだまだ広告を出しています。
[Moy] [Page 176] RFC 1247 OSPF Version 2 July 1991
[Moy][176ページ]RFC1247OSPFバージョン1991年7月2日
Ifc IP address state cost DR Backup # nbrs # adjs __________________________________________________________________________ 192.1.1.3 DR other 1 192.1.1.4 192.1.1.1 3 2 192.1.4.3 DR 2 192.1.4.3 none 0 0
Ifc IPアドレス州の費用DR Backup#nbrs#adjs__________________________________________________________________________ 192.1.1.3 DR他の1つ192.1.1.4 192.1.1.1 3 2 192.1.4.3DR2 192.1.4、.3、なにも、0 0
Table 21: Sample OSPF interface display.
テーブル21: サンプルOSPFはディスプレイを連結します。
(3) The list of neighbors associated with a particular interface. Each
neighbor's IP address, router ID, state, and the length of the three
link state advertisement queues (see Section 10) to the neighbor is
displayed.
(3) 特定のインタフェースに関連している隣人のリスト。 州の広告が隣人へ列に並ばせる(セクション10を見ます)3リンクの各隣人のIPアドレス、ルータID、状態、および長さを表示します。
Suppose router RT4 is the Designated Router for network N3, and
router RT1 is the Backup Designated router. Suppose also that the
adjacency between router RT3 and RT1 has not yet fully formed. The
display of router RT3's neighbors (associated with its interface to
network N3) may then look like Table 22. The display indicates that
RT3 and RT1 are still in the database exchange procedure, Router RT3
has more Database Description packets to send to RT1, and RT1 has at
least one link state advertisement that RT3 doesn't. Also, there is
a single link state advertisement that has been flooded, but not
acknowledged, to each neighbor that participates in the flooding
procedure (state >= Exchng). (In the following examples we assume
that a router's Router ID is assigned to be its smallest IP
interface address).
ルータRT4がネットワークN3のためのDesignated Routerであり、ルータRT1がBackup Designatedルータであるなら。 また、ルータRT3とRT1の間の隣接番組がまだ完全に形成されるというわけではなかったと仮定してください。 そして、ルータRT3の隣人(N3をネットワークでつなぐためにインタフェースに関連づけられます)のディスプレイはTable22に似るかもしれません。 ディスプレイは、RT3とRT1がまだデータベース交換手順にあるのを示します、そして、Router RT3はRT1に送るより多くのDatabase記述パケットを持っています、そして、RT1はRT3が出していない少なくとも1つのリンク州の広告を出しています。 また、水につかりますが、それが氾濫手順に参加する(州の>はExchngと等しい)と各隣人に認めていないただ一つのリンク州の広告があります。 (以下の例では、私たちは、ルータのRouter IDが最も小さいIPインターフェース・アドレスになるように割り当てられると思います。)
Nbr IP address Router ID state LS rxmt len DB summ len LS req len ____________________________________________________________________________ 192.1.1.1 192.1.1.1 Exchng 1 10 1 192.1.1.2 192.1.1.2 2-Way 0 0 0 192.1.1.4 192.1.1.4 Full 1 0 0
Nbr IPアドレスRouter ID州のLS rxmt len DB summ len LS req len____________________________________________________________________________ 192.1.1.1 192.1 .1.1Exchng1 10 1 192.1.1.2 192.1.1.2 2ウェイ0 0 0 192.1.1.4 192.1.1.4は1 0 0を洗い張りします。
Table 22: Sample OSPF neighbor display.
テーブル22: OSPF隣人ディスプレイを抽出してください。
(4) A list of the area's link state database. This is the same in all
of the routers attached to the area. It is composed of that area's
router links, network links, and summary links advertisements.
Also, the AS external link advertisements are a part of all the
areas' databases.
(4) 領域のリンク州のデータベースのリスト。 これはその領域に付けられたルータで全部で同じです。 それはその領域のルータリンク、ネットワークリンク、および概要リンク広告で構成されます。 また、ASの外部のリンク広告はすべての領域のデータベースの一部です。
[Moy] [Page 177] RFC 1247 OSPF Version 2 July 1991
[Moy][177ページ]RFC1247OSPFバージョン1991年7月2日
The link state database for Area 1 in Figure 15 might look like
Table 23 (compare this with Figure 7). Assume the the Designated
Router for network N3 is router RT4, as above. Both routers RT3 and
RT4 are originating summary link advertisements into Area 1, since
they are area border routers. Routers RT5 and RT7 are AS external
routers. Their location must be described in summary links
advertisements. Also, their AS external link advertisements are
flooded throughout the entire AS.
図15のArea1のためのリンク州のデータベースはTable23に似るかもしれません(図7とこれを比べてください)。 ネットワークN3のためのDesignated Routerが同じくらい上のルータRT4であると仮定してください。 ルータRT3とRT4の両方が、それらが境界ルータであるので、概要リンク広告をArea1に溯源しています。 ルータのRT5とRT7はASの外部のルータです。 概要リンク広告でそれらの位置について説明しなければなりません。 また、彼らのASの外部のリンク広告も全体のAS中で水につかっています。
Router RT3 can locate its self-originated advertisements by looking
for its own router ID (192.1.1.3) in advertisements' Advertising
Router fields.
ルータRT3がそれ自身のルータIDを探すことによって自己によって溯源された広告の場所を見つけることができる、(192.1 .1 .3) 広告のAdvertising Router分野で。
The LS sequence number, LS age, and LS checksum fields indicate the
advertisement's instance. Their values are stored in the
advertisement's link state header; we have not bothered to make up
values for the example.
LS一連番号、LS時代、およびLSチェックサム分野は広告のインスタンスを示します。 それらの値は広告のリンク州のヘッダーに保存されます。 私たちは例のためにわざわざ値を作っていません。
LS type Link State ID Advertising Router LS seq no LS age LS checksum _______________________________________________________________________________ 1 192.1.1.1 192.1.1.1 * * * 1 192.1.1.2 192.1.1.2 * * * 1 192.1.1.3 192.1.1.3 * * * 1 192.1.1.4 192.1.1.4 * * * _______________________________________________________________________________ 2 192.1.1.4 192.1.1.4 * * * _______________________________________________________________________________ 3 Ia,Ib 192.1.1.3 * * * 3 N6 192.1.1.3 * * * 3 N7 192.1.1.3 * * * 3 N8 192.1.1.3 * * * 3 N9-N11,H1 192.1.1.3 * * * 3 Ia,Ib 192.1.1.4 * * * 3 N6 192.1.1.4 * * * 3 N7 192.1.1.4 * * * 3 N8 192.1.1.4 * * * 3 N9-N11,H1 192.1.1.4 * * * 4 RT5 192.1.1.3 * * * 4 RT7 192.1.1.3 * * * 4 RT5 192.1.1.4 * * * 4 RT7 192.1.1.4 * * * _______________________________________________________________________________ 4 N12 RT5's ID * * * 4 N13 RT5's ID * * * 4 N14 RT5's ID * * * 4 N12 RT7's ID * * *
LSタイプLink州ID Advertising Router LS seqノーLSはLSチェックサムに年をとらせます。_______________________________________________________________________________ 1 192.1.1.1 192.1.1.1 * * * 1 192.1.1.2 192.1.1.2 * * * 1 192.1.1.3 192.1.1.3 * * * 1 192.1.1.4 192.1.1.4 * * * _______________________________________________________________________________ 2 192.1.1.4 192.1.1.4 * * * _______________________________________________________________________________ イブ..イブ_______________________________________________________________________________ 4 N12 RT5ID**の*4N13 RT5のID***4N14 RT5のID***4N12 RT7のID***
[Moy] [Page 178] RFC 1247 OSPF Version 2 July 1991
[Moy][178ページ]RFC1247OSPFバージョン1991年7月2日
LS type Link State ID Advertising Router LS seq no LS age LS checksum _______________________________________________________________________________ 4 N15 RT7's ID * * *
LSタイプLink州ID Advertising Router LS seqノーLSはLSチェックサムに年をとらせます。_______________________________________________________________________________ 4 N15 RT7のID***
Table 23: Sample OSPF link state database display.
テーブル23: サンプルOSPFは州のデータベースディスプレイをリンクします。
(5) The contents of any particular link state advertisement. For
example, a listing of the router links advertisement for Area 1,
with LS type = 1 and Link State ID = 192.1.1.3 is shown in Section
12.4.1.
(5) どんな特定のリンクの内容も広告を述べます。 例えば、ルータのリストはArea1のために広告をリンクして、1とLSタイプ=Linkと共に、州ID=192.1.1.3はセクション12.4.1で見せられます。
(6) A listing of the entire routing table. Several examples are shown
in Section 11. The routing table is calculated from the combined
databases of each attached area (see Section 16). It may be
desirable to sort the routing table by Type of Service, or by
destination, or a combination of the two.
(6) 全体の経路指定テーブルのリスト。 いくつかの例がセクション11に示されます。 経路指定テーブルはそれぞれの付属領域の結合したデータベースから計算されます(セクション16を見てください)。 ServiceのType、目的地、または2つのものの組み合わせで経路指定テーブルを分類するのは望ましいかもしれません。
[Moy] [Page 179] RFC 1247 OSPF Version 2 July 1991
[Moy][179ページ]RFC1247OSPFバージョン1991年7月2日
E. Authentication
E。 認証
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-area basis. Additional authentication data is configurable on a per-interface basis. For example, if an area uses a simple password scheme for authentication, a separate password may be configured for each network contained in the area.
認証タイプは地域制で構成可能です。 追加認証データは1インタフェースあたり1個のベースで構成可能です。 例えば、領域が認証に簡単なパスワード体系を使用するなら、別々のパスワードはその領域に保管されていた各ネットワークのために構成されるかもしれません。
Authentication types 0 and 1 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 24.
認証タイプ0と1はこの仕様で定義されます。 他のすべての認証タイプが定義のためにIANA( iana@ISI.EDU )によって予約されます。 認証タイプの現在のリストはTable24で以下で説明されます。
AuType Description
_______________________________________________________________
0 No authentication
1 Simple password
All others Reserved for assignment by the IANA (iana@ISI.EDU)
AuType記述_______________________________________________________________ 0 IANAによる課題のために認証の1SimpleのパスワードがないAll他のものReserved( iana@ISI.EDU )
Table 24: OSPF authentication types.
テーブル24: OSPF認証タイプ。
E.1 Autype 0 -- No authentication
E.1 Autype0--認証がありません。
Use of this authentication type means that routing exchanges in the area are not authenticated. The 64-bit field in the OSPF header can contain anything; it is not examined on packet reception.
この認証タイプの使用は、その領域でのルーティング交換が認証されないことを意味します。 OSPFヘッダーの64ビットの分野は何でも含むことができます。 それはパケットレセプションで調べられません。
E.2 Autype 1 -- Simple password
E.2 Autype1--簡単なパスワード
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.
この認証タイプを使用して、64ビットの分野がaで構成される、-、ネットワーク基礎。 すべてのパケットが、特定のネットワークがそれらのOSPFのヘッダーの64ビットの認証分野にこの構成された値を持たなければならないのを転送しました。 これは64ビットの「明確な」パスワードとして本質的には機能します。
This guards against routers inadvertently coming up in the area. They must first be configured with their attached networks' passwords before they can join the routing domain.
これはその領域でうっかり上って来るルータに用心します。 経路ドメインを接合できる前に最初に、それらの付属ネットワークのパスワードでそれらを構成しなければなりません。
[Moy] [Page 180] RFC 1247 OSPF Version 2 July 1991
[Moy][180ページ]RFC1247OSPFバージョン1991年7月2日
F. Version 1 differences
F。 バージョン1差
This section documents the changes between OSPF version 1 and OSPF version 2. The impetus for these changes derives from comments received on RFC 1131 and recent field experience with the OSPF protocol. Unfortunately, the changes are not backward-compatible. For that reason, OSPF version 1 will not interoperate with OSPF version 2. However, the changes are small in scope and should not greatly affect any existing implementations. In addition, some of the proposed changes should enable future protocol additions to be made in a backward- compatible manner (see Section F.4).
このセクションはOSPFバージョン1とOSPFバージョン2の間の変化を記録します。 これらの変化のための起動力がOSPFプロトコルのRFC1131で受けられたコメントと最近の実地経験に由来しています。 残念ながら、変化は互換性がありません後方の。 その理由で、OSPFバージョン1はOSPFバージョン2で共同利用しないでしょう。 しかしながら、変化は、範囲で小さく、どんな既存の実装にも大いに影響するはずがありません。 さらに、いくつかの変更案が、将来のプロトコル追加が後方のコンパチブル方法で作られているのを可能にするはずです(セクションF.4を見てください)。
F.1 Protocol Enhancements
F.1プロトコル増進
The following enhancements were made to the OSPF protocol.
以下の増進をOSPFプロトコルにしました。
F.1.1 Stub area support
F.1.1スタッブ領域サポート
In many Autonomous Systems, the majority of the OSPF link state database consists of AS external advertisements. In these Autonomous Systems, some OSPF areas may be organized in such a way that external advertisements can be safely ignored, enabling a reduction of the area's database size. This applies to OSPF areas where there is only a single exit/entry that is used by all externally addressed packets, or to cases where some sub-optimality of external routing is acceptable.
多くのAutonomous Systemsでは、OSPFリンク州のデータベースの大部分がASの外部の広告から成ります。 これらのAutonomous Systemsでは、いくつかのOSPF領域が安全に外部の広告を無視できるような方法で組織化されるかもしれません、領域のデータベースサイズの減少を可能にして。 これはすべての外部的に扱われたパケットか、ケースに使用される単一の出口/エントリーしか外部のルーティングの何らかのサブの最適が許容できるところにないOSPF領域に適用されます。
Therefore, an OSPF area configuration option has been added (see Sections 3.6 and C.2) allowing the import of external advertisements to be disabled for an area. When this option is enabled, no AS external advertisements will be flooded into the area (Sections 13, 13.3 and 10.3). Instead, within the area all data traffic to external destinations will follow a (per-area) default route. These areas are called "stub" areas.
したがって、外部の広告の輸入が領域に無効にされるのを許容しながら、OSPF領域設定オプションは加えられます(セクション3.6とC.2を見ます)。 このオプションが可能にされるとき、どんなASの外部の広告も領域(セクション13、13.3、および10.3)へあふれないでしょう。 代わりに、領域の中では、外部の目的地へのすべてのデータ通信量が(領域)デフォルトルートに続いて起こるでしょう。 これらの領域は「スタッブ」領域と呼ばれます。
To implement this, all area border routers attached to stub areas will originate a default summary link advertisement for the area (Section 12.4.3). This will direct all internal routers to an area border router when forwarding externally addressed packets. In addition, to ensure that stub areas are configured consistently, an Options field has been added to OSPF Hello packets (Sections A.2 and A.3.2). A bit is reset in the Options field indicating that the attached area is a stub area (Section 9.5). A router will not accept a neighbor's hellos unless they both agree on the area's ability to process AS external advertisements (Section 10.5). In this way, a system administrator will be able to discover incorrectly configured routers, and data traffic will be routed around them (in order to avoid potential looping situations) until their
これを実装するために、領域を引き抜くために付けられたすべての境界ルータが領域(セクション12.4.3)にデフォルト概要リンク広告を溯源するでしょう。 推進が外部的にパケットを扱ったとき、これはすべての内部のルータを境界ルータに向けるでしょう。 さらに、スタッブ領域が一貫して構成されるのを保証するために、Options分野はOSPF Helloパケット(セクションのA.2とA.3.2)に加えられます。 付属地域がスタッブ領域(セクション9.5)であることを示すOptions分野に少しリセットされます。 それらの両方がASの外部の広告(セクション10.5)を処理する領域の能力に同意しないと、ルータは隣人のhellosを受け入れないでしょう。 このように、システム管理者が不当に構成されたルータを発見できて、データ通信量がそれらの周りで発送される、(潜在的ループ状況を避けるために)それら
[Moy] [Page 181] RFC 1247 OSPF Version 2 July 1991
[Moy][181ページ]RFC1247OSPFバージョン1991年7月2日
configuration can be repaired.
構成を修理できます。
F.1.2 Optional TOS support
F.1.2の任意のTOSサポート
In OSPF there is conceptually a separate routing table for each TOS; the calculations detailed in steps 1-5 of Section 16 must be done separately for each TOS. (Note however that link and summary costs need not be specified separately for each TOS; costs for unspecified TOS values default to the cost of TOS 0).
OSPFに、各TOSのための別々の経路指定テーブルが概念的にあります。 各TOSのために別々にセクション16のステップ1-5で詳細な計算をしなければなりません。 (しかしながら、リンクしてください。そうすれば、概要コストが別々に各TOSに指定される必要はないことに注意してください; 不特定のTOS値のためのコストはTOS0の費用をデフォルトとします。)
In version 1 of the OSPF specification, all OSPF routers were required to route based on TOS. However, producing a separate routing table for each TOS may prove costly, both in terms of memory and processor resources. For this reason, version 2 allows the system administrator to configure routers to calculate/use only a single routing table (the TOS 0 table). When this is done, some traffic may take non-optimal routes. But all packets will still be delivered, and routing will remain loop free (see Section 2.4).
OSPF仕様のバージョン1では、発送するOSPFルータが必要であったすべてがTOSを基礎づけました。 しかしながら、各TOSのために別々の経路指定テーブルを生産するのはメモリとプロセッサ資源で高価であると判明するかもしれません。 この理由で、バージョン2で、システム管理者は、単一の経路指定テーブル(TOS0テーブル)だけを計算するか、または使用するためにルータを構成できます。 これが完了していると、何らかのトラフィックが非最適のルートを取るかもしれません。 しかし、それでも、すべてのパケットが提供されるでしょう、そして、ルーティングは輪から無料で残るでしょう(セクション2.4を見てください)。
In order to avoid routing loops, a router (router X) using a single table must communicate this information to its peers. This is done by resetting the new TOS-capable bit in the router X's router links advertisement (Section 12.4.1). Then, when its peers perform the Dijkstra calculation (Section 16.1) for non-zero TOS values, they will omit router X from the calculation. In effect, an attempt will be made to bypass router X when forwarding non-zero TOS traffic. Summary link and AS external link advertisements can also indicate their non- availability for non-zero TOS traffic (Sections 12.4.3 and 12.4.4).
輪を発送するのを避けるために、単一のテーブルを使用するルータ(ルータX)はこの情報を同輩に伝えなければなりません。 ルータXのルータリンク広告(セクション12.4.1)に新しいTOSできるビットをリセットすることによって、これをします。 そして、同輩が非ゼロTOS値のためのダイクストラの計算(セクション16.1)を実行するとき、それらは計算からルータXを省略するでしょう。 事実上、非ゼロTOSトラフィックを進めるとき、ルータXを迂回させるのを試みをするでしょう。 また、概要リンクとASの外部のリンク広告が非ゼロTOSトラフィックのためのそれらの非の有用性を示すことができる、(セクション12.4 .3と12.4、.4)。
The result may be that no route can be found for some non-zero value of TOS. When this happens, the packet is routed along the TOS 0 route instead (Section 11.1).
結果はTOSの何らかの非ゼロ価値に関してルートを全く見つけることができないということであるかもしれません。 これが起こるとき、パケットは代わりに(セクション11.1)TOS0ルートに沿って発送されます。
It is still mandatory for all OSPF implementations to be able to construct separate routing tables for each TOS value, if desired by the system administrator.
すべてのOSPF実装がそれぞれのTOS値のために別々の経路指定テーブルを組み立てることができるのは、まだ義務的です、システム管理者によって望まれているなら。
F.1.3 Preventing external extra-hops
外部の付加的なホップを防ぐF.1.3
In some cases, version 1 of the OSPF specification will introduce extra-hops when calculating routes to external destinations. This is because it is implicit in the format of AS external advertisements that packets should be forwarded through the advertising router. However, consider the situation where multiple OSPF routers share a LAN with an external router (call it router Y) , and only one OSPF router (call it router X) exchanges routing information with Y. The OSPF routers on the
外部の目的地にルートを計算するとき、いくつかの場合、OSPF仕様のバージョン1は付加的なホップを導入するでしょう。 これは広告ルータを通してパケットを進めるのがASの外部の広告の形式で暗黙であるからです。 しかしながら、複数のOSPFルータが外部のルータとLANを共有して(それをルータYと呼んでください)、1つのOSPFルータ(それをルータXと呼ぶ)だけがY. OSPFルータとルーティング情報を交換する状況がオンであると考えてください。
[Moy] [Page 182] RFC 1247 OSPF Version 2 July 1991
[Moy][182ページ]RFC1247OSPFバージョン1991年7月2日
LAN other than X will forward packets destined for Y and beyond through X, generating an extra hop (see Section 2.2).
Xを除いたLANはYのために運命づけられたパケットを進めるでしょう、そして、向こうでは、Xを通して、エキストラを作るのは跳びます(セクション2.2を見てください)。
To fix this, a new field has been added to AS external advertisements. This field (called the forwarding address) will indicate the router address to which packets should be forwarded (Section 12.4.4). In the above example, router X will put Y's IP address into this field. If the field is 0, packets are (as before) forwarded to the originator of the advertisement. A different forwarding address can be specified for each TOS value.
これを修理するために、新しい分野はASの外部の広告に加えられます。 この分野(フォーワーディング・アドレスと呼ばれる)はパケットが送られるべきであるルータアドレス(セクション12.4.4)を示すでしょう。 上記の例では、ルータXはYのIPアドレスをこの分野に入れるでしょう。 分野が0であるなら、(従来と同様)広告の創始者にパケットを送ります。 それぞれのTOS値に異なったフォーワーディング・アドレスを指定できます。
Whenever possible, this new field should be set to 0. This is because setting it to an actual router address incurs additional cost during the routing table build process (Section 16.4).
可能であるときはいつも、この新しい分野は0に設定されるべきです。 これはアドレスが被る実際のルータにそれを設定して、経路指定テーブルの間の別途費用がプロセス(セクション16.4)を建てるからです。
Besides preventing extra-hops, there are two other applications for this field. The first is for use by "route servers". Using the forwarding address, a router in the middle of the Autonomous System can gather external routing information and originate AS external advertisements that specify the correct exit route to use for each external destination (Section 2.2).
付加的なホップを防ぐこと以外に、この分野の他の2つの利用があります。 1番目は「ルートサーバ」による使用のためのものです。 フォーワーディング・アドレスを使用して、Autonomous Systemの中央のルータは、外部のルーティング情報を集めて、それぞれの外部の目的地(セクション2.2)に使用する正しい出口ルートを指定するASの外部の広告を溯源できます。
The other application possibly enables the reduction of the number of AS external advertisements that need be imported. Suppose in the example at the beginning of this section that there are two routers (X and Z) exchanging EGP information with the non-OSPF router Y. It is then likely that both X and Z will originate the same set of external routes. Two AS external advertisements that specify the same (non-zero) forwarding address, destination and cost are obviously functionally equivalent, regardless of their originators (advertising routers). The OSPF specification dictates that the advertisement originated by the router with the largest Router ID will always be used. This allows the other router to flush its equivalent advertisement (Section 12.4.4).
もう片方のアプリケーションはことによるとインポートされなければならないASの外部の広告の数の減少を可能にします。 このセクションの始めに例で非OSPFルータY.とEGP情報を交換する2つのルータ(XとZ)があると仮定してください。次に、ItはXとZの両方が同じセットの外部経路を溯源しそうでしょう。 同じように(非ゼロ)フォーワーディング・アドレス、目的地、および費用を指定する2つのASの外部の広告が明らかに機能上同等です、彼らの創始者(広告ルータ)にかかわらず。 OSPF仕様は、最も大きいRouter IDと共にルータによって溯源された広告がいつも使用されると決めます。 これで、もう片方のルータは同等な広告(セクション12.4.4)を洗い流すことができます。
F.2 Corrected problems
F.2は問題を修正しました。
The following problems in OSPF version 1 have been corrected in version 2.
バージョン2でOSPFバージョン1の以下の問題を修正してあります。
F.2.1 LS sequence number space changes
F.2.1 LS一連番号スペース変化
The LS sequence number space has been changed from version 1's lollipop shape to a linear sequence space (Section 12.1.6). Sequence numbers will now be compared as signed 32-bit integers. Link state advertisements having larger sequence numbers will be considered more recent. The sequence number space will still begin at (-N+1) (where N =
LS一連番号スペースはバージョン1の棒付きキャンディ形から線形連続スペース(セクション12.1.6)に変わりました。 32ビットの整数であると署名されるように一連番号は現在、比較されるでしょう。 より大きい一連番号を持っているリンク州の広告は、より最近であると考えられるでしょう。 それでも、一連番号スペースが(-N+1)で始まる、(どこ、Nは等しいか。
[Moy] [Page 183] RFC 1247 OSPF Version 2 July 1991
[Moy][183ページ]RFC1247OSPFバージョン1991年7月2日
2**31). The value of -N remains reserved. The LS sequence number of successive instances of an advertisement will continue to be incremented until it reaches the maximum possible value: N-1. At this point, when a new instance of the advertisement must be originated (due either to topological change of the expiration of the LS refresh timer) the current instance must first be "prematurely aged".
2**31). -nの値は予約されていたままで残っています。 広告の連続したインスタンスのLS一連番号は、最大の可能な値に達するまで増加され続けるでしょう: N-1。 ここに広告の新しいインスタンスを溯源しなければならないとき(どちらかLSの満了の位相的な変化への支払われるべきものはタイマをリフレッシュします)、現在のインスタンスは最初に、「早まって、熟成しなければなりません」。
There will be a new section discussing premature aging (Section 14.1). This is a method for flushing a link state advertisement from the routing domain: the advertisement's age is set to MaxAge and advertisement is reflooded just as if it were a newly received advertisement. As soon as the new flooding is acknowledged by all of the router's adjacent neighbors, the advertisement is flushed from the database.
時期尚早な年をとること(セクション14.1)について論ずる新しいセクションがあるでしょう。 これは経路ドメインからのリンク州の広告を洗い流すためのメソッドです: 広告の時代はMaxAgeに設定されます、そして、広告はまるでまさしくそれが新たに受け取られた広告であるかのように「再-あふれ」ます。 新しい氾濫がルータの隣接している隣人のすべてによって承認されるとすぐに、広告はデータベースから洗い流されます。
Premature aging can also be used when, for example, a previously advertised external route is no longer reachable. In this circumstance, premature aging is preferable to the alternative, which is to originate a new advertisement for the destination specifying a metric of LSInfinity.
また、例えば、以前に広告を出した外部経路がもう届いていないとき、時期尚早な年をとることを使用できます。 この状況では、時期尚早な年をとるのはLSInfinityにおけるメートル法のaを指定する目的地に新しい広告を溯源することである代替手段より望ましいです。
A router may only prematurely age its own (self-originated) link state advertisements. These are the link state advertisements having the router's own OSPF router ID in the Advertising Router field.
ルータは早まって、それ自身(自己に溯源される)のリンク州の広告に年をとらせるだけであるかもしれません。 これらはAdvertising Router分野にルータの自己のOSPFルータIDを持っているリンク州の広告です。
F.2.2 Flooding of unexpected MaxAge advertisements
予期していなかったMaxAge広告のF.2.2氾濫
Version 1 of the OSPF omitted the handling of a special case in the flooding procedure: the reception of a MaxAge advertisement that has no database instance. A paragraph has been added to Section 13 to deal with this occurrence. Without this paragraph, retransmissions of MaxAge advertisements could possibly delay their being flushed from the routing domain.
OSPFのバージョン1は氾濫手順における特別なケースの取り扱いを省略しました: データベースインスタンスを全く持っていないMaxAge広告のレセプション。 この発生と取り引きするためにセクション13にパラグラフを追加してあります。 このパラグラフがなければ、MaxAge広告の「再-トランスミッション」は、それらが経路ドメインから紅潮しているのを遅らせることができました。
F.2.3 Virtual links and address ranges
F.2.3の仮想のリンクとアドレスの範囲
When summarizing information into a virtual link's transit area, version 2 of the OSPF specification prohibits the collapsing of multiple backbone IP networks/subnets into a single summary link. This restriction has been added to deal with certain anomalous OSPF area configurations. See Sections 15 and 12.4.3 for more information.
仮想のリンクのトランジット領域へ情報をまとめるとき、OSPF仕様のバージョン2は複数のバックボーンIPネットワーク/サブネットの微片を単一の概要リンクに禁止します。 この制限は、ある変則的なOSPF領域構成に対処するために加えられます。 詳しい情報に関してセクション15と12.4.3を見てください。
[Moy] [Page 184] RFC 1247 OSPF Version 2 July 1991
[Moy][184ページ]RFC1247OSPFバージョン1991年7月2日
F.2.4 Routing table lookup explained
索表を発送するF.2.4が説明しました。
When forwarding an IP data packet, a router looks up the packet's IP destination in the routing table. This determines the packet's next hop. A new section (Section 11.1) has been added describing the routing table lookup (instead of just specifying a "best match"). This section clarifies OSPF's four level routing hierarchy (i.e., intra-area, inter- area, external type 1 and external type 2 routes). It also specifies the effect of TOS on routing.
IPデータ・パケットを進めるとき、ルータは経路指定テーブルでパケットのIPの目的地を見上げます。 これはパケットの次のホップを決定します。 新しいセクション(セクション11.1)は、経路指定テーブルルックアップ(ただ「最も良いマッチ」を指定することの代わりに)について説明しながら、加えられます。 このセクションはOSPFの4の平らなルーティング階層構造(すなわち、イントラ領域、相互領域、外部のタイプ1、および外部のタイプ2ルート)をはっきりさせます。 また、それはルーティングへのTOSの効果を指定します。
F.2.5 Sending Link State Request packets
F.2.5送付Link州Requestパケット
OSPF Version 2 eases the restrictions on the sending of Link State Request packets. Link State Request packets can now be sent to a neighboring router before a complete set of Database Description packets have been exchanged. This enables a more efficient use of a router's memory resources; an OSPF version 2 implementation may limit the size of the neighbor Link state request lists. See Sections 10.9, 10.7 and 10.3 for more details.
OSPFバージョン2はLink州Requestパケットの発信のときに制限を緩和します。 完全なセットのDatabase記述パケットを交換する前に現在、リンク州Requestパケットを隣接しているルータに送ることができます。 これはルータのメモリリソースの、より効率的な使用を可能にします。 OSPFバージョン2実装は隣人Link州の要求リストのサイズを制限するかもしれません。 その他の詳細に関してセクション10.9、10.7、および10.3を見てください。
F.2.6 Changes to the Database description process
Database記述プロセスへのF.2.6変化
The specification has been modified to ensure that, when two routers are synchronizing their databases during the Database Description process, none of the component link state advertisements can have their sequence numbers decrease. A link state advertisement's sequence number decreases when it is flushed from the routing domain via premature- aging, and then reoriginated with the smallest sequence number 0x80000001 (see Section 14.1). So the specification now dictates that an advertisement cannot be flushed from a router's database until both a) it no longer appears on any neighbor Link State Retransmission lists and b) none of the router's neighbors are in states Exchange or Loading. See Sections 13 (step 4c) and 14.1 for more details.
仕様は、2つのルータがDatabase記述プロセスの間それらのデータベースを同期させているとき、それらの一連番号がコンポーネントリンク州の広告のどれかで減少できないのを保証するように変更されました。 それがあるとき、リンク州の広告の一連番号減少は、時期尚早な年をとることを通して経路ドメインから追い立てて、次に、最もわずかな一連番号0x80000001で再起因しました(セクション14.1を見てください)。 それで、仕様は、現在、それがもうどんな隣人Link州Retransmissionリストでも見えないa)とbの両方) ルータの隣人のだれも州のExchangeかLoadingにいないまでルータのデータベースから広告を洗い流すことができないと決めます。 その他の詳細に関してセクション13(ステップ4c)と14.1を見てください。
In addition, a new step has been added to the flooding procedure (Section 13) in order to make the Database Description process more robust. This step detects when a neighbor lists one instance of an advertisement in its Database Description packets, but responds to Link State Request packets by sending another (earlier) instance. This behavior now causes the event BadLSReq to be generated, which restarts the Database Description process with the neighbor. In OSPF version 1, the neighbor event BadLSReq erroneously did not restart the Database Description process.
さらに、Database記述プロセスをより強健にするように氾濫手順(セクション13)に新しいステップを追加してあります。 このステップは、Database記述パケットに隣人がいつ広告の1つのインスタンスを記載するかを検出しますが、別の(以前)のインスタンスを送ることによって、Link州Requestパケットに応じます。 この振舞いで、現在、イベントBadLSReqを生成します(隣人と共にDatabase記述プロセスを再開します)。 OSPFバージョン1では、隣人イベントBadLSReqは誤ってDatabase記述プロセスを再開しませんでした。
[Moy] [Page 185] RFC 1247 OSPF Version 2 July 1991
[Moy][185ページ]RFC1247OSPFバージョン1991年7月2日
F.2.7 Receiving OSPF Hello packets
OSPF Helloパケットを受けるF.2.7
The section detailing the receive processing of OSPF Hello packets (Section 10.5) has been modified to include the generation of the neighbor Backup Seen event. In addition, the section detailing the Designated Router election algorithm (Section 9.4) has been modified to include the algorithm's initial state.
OSPF Helloパケット(セクション10.5)の処理を受けてください。セクション細部、隣人Backup Seenイベントの世代を含むように、変更されました。 さらに、Designated Router選挙アルゴリズム(セクション9.4)を詳しく述べるセクションは、アルゴリズムの初期状態を含むように変更されました。
F.2.8 Network mask defined for default route
デフォルトルートと定義されたF.2.8ネットワークマスク
The network mask for the default route, when it appears as the destination in either an AS external link advertisement or in a summary link advertisement, has been set to 0.0.0.0. See Sections A.4.4 and A.4.5 for more details.
ASの外部のリンク広告か概要リンク広告における目的地として現れるとき、デフォルトルートへのネットワークマスクは.0に0.0に.0を設定することです。 その他の詳細に関してセクションのA.4.4とA.4.5を見てください。
F.2.9 Rate limit imposed on flooding
氾濫に課されたF.2.9レート限界
When an advertisement is installed in the link state database, it is timestamped. The flooding procedure is then not allowed to install a new instance of the advertisement until MinLSInterval seconds have elapsed. This enforces a rate limit on the flooding procedure; a new instance can be flooded only once every MinLSInterval seconds. This guards against routers that disregard the limit on self-originated advertisements (already present in OSPF version 1) of one origination every MinLSInterval seconds. For more information, see Section 13.
広告がリンク州のデータベースにインストールされるとき、それはtimestampedされます。 そして、MinLSInterval秒が経過するまで、氾濫手順は広告の新しいインスタンスをインストールできません。 これはレート限界に氾濫手順に押しつけます。 新しいインスタンスはかつてだけ水につかっている場合があります。あらゆるMinLSIntervalが後援します。 これはあらゆるMinLSIntervalが後援するある創作の自己によって溯源された広告(既にOSPFバージョン1で現在の)における限界を無視するルータに用心します。 詳しくは、セクション13を見てください。
F.3 Packet format changes
F.3パケット・フォーマット変化
The following changes have been made to the format of OSPF packets and link state advertisements. Some of these changes were required to support the added functionality listed above. Other changes were made to further simplify the parsing of OSPF packets.
以下の変更をOSPFパケットとリンク州の広告の形式にしました。 これらのいくつかの変化が、上にリストアップされた付記された機能性をサポートするのに必要でした。 他の変更がさらにOSPFパケットの構文解析を簡素化すると行われました。
F.3.1 Adding a Capability bitfield
Capability bitfieldを加えるF.3.1
To support the new "stub area" and "optional TOS" features, a bitfield listing protocol capabilities has been added to the Hello packet, Database Description packet and all link state advertisements. When used in Hello packets, this 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 link state advertisements to a neighbor because of its reduced functionality. Lastly, listing capabilities in link state advertisements allows routers to route traffic around reduced
新しい「スタッブ領域」と「任意のTOS」の特徴をサポートするために、プロトコル能力を記載するbitfieldはHelloパケット、Database記述パケット、およびすべてのリンク州の広告に加えられます。 Helloパケットで使用されると、これで、ルータは能力ミスマッチで隣人を拒絶できます。 Database記述パケットで能力を交換するとき、あるいはまた、ルータは、減少している機能性のためにあるリンク州の広告を隣人に転送しないのを選ぶことができます。 最後に、リンク州の広告における能力を記載するのに、ルータは周囲で減少していた状態でトラフィックを発送できます。
[Moy] [Page 186] RFC 1247 OSPF Version 2 July 1991
[Moy][186ページ]RFC1247OSPFバージョン1991年7月2日
functionality router, by excluding them from parts of the routing table calculation. See Section A.2 for more details.
経路指定テーブル計算の部品にそれらを入れないようにするのによる機能性ルータ。 その他の詳細に関してセクションA.2を見てください。
F.3.2 Packet simplification
F.3.2パケット簡素化
To simplify the format of Database Description packets and Link State Acknowledgment packets, their description of link state advertisements has been modified. Each advertisement is now be described by its 20- byte link state header (see Section A.4). This does not consume any additional space in the packets. The one additional piece of information that will be present is the LS length. However, this field need not be used when processing the Database Description and Link State Acknowledgment packets.
Database記述パケットとLink州Acknowledgmentパケットの形式を簡素化するために、彼らのリンク州の広告の記述は変更されました。 各広告は現在説明されて、20バイトが州のヘッダーをリンクするという(セクションA.4を見てください)ことであることです。 これはパケットの少しの追加スペースも消費しません。 1つの存在している追加情報がLSの長さです。 しかしながら、Database記述とLink州Acknowledgmentパケットを処理するとき、この分野は使用される必要はありません。
F.3.3 Adding forwarding addresses to AS external advertisements
ASの外部の広告にフォーワーディング・アドレスを加えるF.3.3
As discussed in Section F.1.3, a forwarding address field has been added to the AS external advertisement.
セクションF.1.3で議論するように、推進アドレス・フィールドはASの外部の広告に加えられます。
F.3.4 Labelling of virtual links
仮想のリンクのF.3.4ラベル
Virtual links will be labelled as such in router links advertisements. This separates virtual links from unnumbered point-to-point links, allowing all backbone routers to discover whether any virtual links are in use. See Section 12.4.1 for more details.
ルータにおけるそのようなものが広告をリンクするとき、仮想のリンクはラベルされるでしょう。 これは無数のポイントツーポイント接続と仮想のリンクを切り離します、すべてのバックボーンルータが、何か仮想のリンクが使用中であるかどうか発見するのを許容して。 その他の詳細に関してセクション12.4.1を見てください。
F.3.5 TOS costs ordered
F.3.5 TOSコストは注文されました。
When a link state advertisement specifies a separate cost depending on TOS, these costs must be ordered by increasing TOS value. For example, the cost for TOS 16 must always follow the cost for TOS 8.
リンク州の広告がTOSに依存する別々の費用を指定すると、TOS値を増強することによって、これらのコストを命令しなければなりません。 例えば、TOS16のための費用はいつもTOS8のための費用に続かなければなりません。
F.3.6 OSPF's TOS encoding redefined
コード化が再定義したF.3.6 OSPFのTOS
The way that OSPF encodes TOS in its link state advertisements has been redefined in version 2. OSPF's encoding of the Delay (D), Throughput (T) and Reliability (R) TOS flags defined by [RFC 791] is described in Section 12.3.
OSPFがリンク州の広告でTOSをコード化する方法はバージョン2に再定義されました。 OSPFの旗が[RFC791]で定義したDelay(D)、Throughput(T)、およびReliability(R)TOSのコード化はセクション12.3で説明されます。
[Moy] [Page 187] RFC 1247 OSPF Version 2 July 1991
[Moy][187ページ]RFC1247OSPFバージョン1991年7月2日
F.4 Backward-compatibility provisions
F.4後方の互換性条項
Additional functionality will probably be added to OSPF in the future. One example of this is a multicast routing capability, which is currently under development. In order to be able to add such features in a backward-compatible manner, the following provisions have been made in the OSPF specification.
追加機能性は将来、たぶんOSPFに加えられるでしょう。 この1つの例がマルチキャストルーティング能力です。(その能力は現在、開発中です)。 後方コンパチブル方法におけるそのような特徴を加えることができるように、以下の条項はOSPF仕様で作られています。
New capabilities will probably involve the introduction of new link state advertisements. If a router receives a link state advertisement of unknown type during the flooding procedure, the advertisement is simply ignored (Section 13. The router should not attempt to further flood the advertisement, nor acknowledge it. The advertisement should not be installed into the link state database. If the router receives an advertisement of unknown type during the Database Description process, this is an error (see Sections 10.6 and 10.3). The Database Description process is then restarted.
新しい能力はたぶん新しいリンク州の広告の導入にかかわるでしょう。 ルータは、広告をさらにあふれさせて、それを承認するのを試みるべきではありません。リンク州のデータベースに広告をインストールするべきではありません。ルータがDatabase記述プロセスの間、未知のタイプの広告を受け取るなら、これは誤り(セクション10.6と10.3を見る)です。ルータが氾濫手順の間、未知のタイプのリンク州の広告を受け取るなら、広告が単に無視される、(セクション13 次に、Database記述プロセスは再開されます。
There is also an Options field in both the Hello packets, Database Description packets and the link state advertisement headers. Unrecognized capabilities found in these places should be ignored, and should not affect the normal processing of protocol packets/link state advertisements (see Sections 10.5 and 10.6). Routers will originate their Hello packets, Database Description packets and link state advertisements with unrecognized capabilities set to 0 (see Sections 9.5, 10.8 and 12.1.2).
また、Options分野が両方のHelloパケット、Database記述パケット、およびリンク州の広告ヘッダーにあります。 これらの場所で見つけられた認識されていない能力は、無視されるべきであり、プロトコルパケット/リンク州の広告の正常処理に影響するべきではありません(セクション10.5と10.6を見てください)。 ルータはそれらのHelloパケットを溯源するでしょう、認識されていない能力があるパケットとリンク州の広告が0に設定するDatabase記述(セクション9.5、10.8、および12.1.2を見てください)。
[Moy] [Page 188] RFC 1247 OSPF Version 2 July 1991
[Moy][188ページ]RFC1247OSPFバージョン1991年7月2日
Security Considerations
セキュリティ問題
All OSPF protocol exchanges are authenticated. This is accomplished through authentication fields contained in the OSPF packet header. For more information, see Sections 8.1, 8.2, and Appendix E.
すべてのOSPFプロトコル交換が認証されます。 これはOSPFパケットのヘッダーに含まれた認証分野を通って達成されます。 詳しくは、セクション8.1、8.2、およびAppendix Eを見てください。
Author's Address
作者のアドレス
John Moy Proteon, Inc. 2 Technology Drive Westborough, MA 01581
Driveウェストボーラフ、ジョンMoy Proteon Inc.2Technology MA 01581
Phone: (508) 898-2800 EMail: jmoy@proteon.com
以下に電話をしてください。 (508) 898-2800 メールしてください: jmoy@proteon.com
[Moy] [Page 189]
[Moy][189ページ]
一覧
スポンサーリンク
