RFC2370 日本語訳
2370 The OSPF Opaque LSA Option. R. Coltun. July 1998. (Format: TXT=33789 bytes) (Obsoleted by RFC5250) (Updated by RFC3630) (Also RFC2328) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Coltun Request for Comments: 2370 FORE Systems See Also: 2328 July 1998 Category: Standards Track
Coltunがコメントのために要求するワーキンググループR.をネットワークでつないでください: また、2370台の前面のシステムが見られます: 2328 1998年7月のカテゴリ: 標準化過程
The OSPF Opaque LSA Option
OSPFの不明瞭なLSAオプション
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Table Of Contents
目次
1.0 Abstract ................................................. 1 2.0 Overview ................................................. 2 2.1 Organization Of This Document ............................ 2 2.2 Acknowledgments .......................................... 3 3.0 The Opaque LSA ........................................... 3 3.1 Flooding Opaque LSAs ..................................... 4 3.2 Modifications To The Neighbor State Machine .............. 5 4.0 Protocol Data Structures ................................. 6 4.1 Additions To The OSPF Neighbor Structure ................. 6 5.0 Management Considerations ................................ 7 6.0 Security Considerations .................................. 9 7.0 IANA Considerations ...................................... 10 8.0 References ............................................... 10 9.0 Author's Information ..................................... 11 Appendix A: OSPF Data Formats ................................ 12 A.1 The Options Field ........................................ 12 A.2 The Opaque LSA ........................................... 13 Appendix B: Full Copyright Statment .......................... 15
1.0要約… 1 2.0概観… 2 2.1 このドキュメントの組織… 2 2.2の承認… 3 3.0 不透明なLSA… 3 3.1 氾濫の不透明なLSAs… 4 隣人への3.2の変更がマシンを述べます… 5 4.0 データ構造について議定書の中で述べてください… 6 OSPF隣人構造への4.1の追加… 6 5.0 管理問題… 7 6.0 セキュリティ問題… 9 7.0 IANA問題… 10 8.0の参照箇所… 10 9.0作者の情報… 11 付録A: OSPFデータ形式… 12 A.1オプション分野… 12 A.2の不透明なLSA… 13 付録B: 完全なCopyright Statment… 15
1.0 Abstract
1.0 要約
This memo defines enhancements to the OSPF protocol to support a new class of link-state advertisements (LSA) called Opaque LSAs. Opaque LSAs provide a generalized mechanism to allow for the future extensibility of OSPF. Opaque LSAs consist of a standard LSA header followed by application-specific information. The information field
このメモは、Opaque LSAsと呼ばれる新しいクラスのリンク州の広告(LSA)を支持するためにOSPFプロトコルと増進を定義します。 不透明なLSAsは、OSPFの将来の伸展性を考慮するために一般化されたメカニズムを提供します。 不透明なLSAsはアプリケーション特有の情報があとに続いた標準のLSAヘッダーから成ります。 情報フィールド
Coltun Standards Track [Page 1] RFC 2370 The OSPF Opaque LSA Option July 1998
OSPFがLSAオプション1998年7月に不透明にするColtun標準化過程[1ページ]RFC2370
may be used directly by OSPF or by other applications. Standard OSPF link-state database flooding mechanisms are used to distribute Opaque LSAs to all or some limited portion of the OSPF topology.
直接OSPFか他のアプリケーションで使用されるかもしれません。 標準のOSPFリンク州のデータベース氾濫メカニズムは、OSPFトポロジーのすべてか何らかの限られた部分にOpaque LSAsを分配するのに使用されます。
2.0 Overview
2.0 概観
Over the last several years the OSPF routing protocol [OSPF] has been widely deployed throughout the Internet. As a result of this deployment and the evolution of networking technology, OSPF has been extended to support many options; this evolution will obviously continue.
ここ数年間、OSPFルーティング・プロトコル[OSPF]はインターネット中で広く配備されています。 ネットワーク・テクノロジーのこの展開と発展の結果、OSPFは多くのオプションをサポートするために広げられました。 この発展は明らかに続くでしょう。
This memo defines enhancements to the OSPF protocol to support a new class of link-state advertisements (LSA) called Opaque LSAs. Opaque LSAs provide a generalized mechanism to allow for the future extensibility of OSPF. The information contained in Opaque LSAs may be used directly by OSPF or indirectly by some application wishing to distribute information throughout the OSPF domain. For example, the OSPF LSA may be used by routers to distribute IP to link-layer address resolution information (see [ARA] for more information). The exact use of Opaque LSAs is beyond the scope of this memo.
このメモは、Opaque LSAsと呼ばれる新しいクラスのリンク州の広告(LSA)を支持するためにOSPFプロトコルと増進を定義します。 不透明なLSAsは、OSPFの将来の伸展性を考慮するために一般化されたメカニズムを提供します。 Opaque LSAsに含まれた情報は直接OSPFか間接的にOSPFドメインに情報を分配したがっている何らかのアプリケーションで使用されるかもしれません。 例えば、OSPF LSAはルータによって使用されて(詳しい情報に関して[ARA]を見てください)、リンクレイヤアドレス解決情報にIPを分配するかもしれません。 Opaque LSAsの正確な使用はこのメモの範囲を超えています。
Opaque LSAs consist of a standard LSA header followed by a 32-bit qaligned application-specific information field. Like any other LSA, the Opaque LSA uses the link-state database distribution mechanism for flooding this information throughout the topology. The link- state type field of the Opaque LSA identifies the LSA's range of topological distribution. This range is referred to as the Flooding Scope.
不透明なLSAsは32ビットのqalignedアプリケーション特有の情報分野があとに続いた標準のLSAヘッダーから成ります。 いかなる他のLSAのようにも、Opaque LSAは、トポロジー中にこの情報をあふれさせるのにリンク州のデータベース分配メカニズムを使用します。 Opaque LSAのリンク州のタイプ分野はLSAの位相的な分配の範囲を特定します。 この範囲はFlooding Scopeと呼ばれます。
It is envisioned that an implementation of the Opaque option provides an application interface for 1) encapsulating application-specific information in a specific Opaque type, 2) sending and receiving application-specific information, and 3) if required, informing the application of the change in validity of previously received information when topological changes are detected.
それは思い描かれます。Opaqueオプションの実現が特定のOpaqueのアプリケーション特有の情報を1のためのアプリケーション・インターフェース) 要約に提供するのはタイプされます、必要なら、2が)アプリケーション特有の情報、および3を)送って、受け取って、位相的な変化がいつ検出されるかを以前に受信された情報の正当性における変化のアプリケーションに知らせて。
2.1 Organization Of This Document
2.1 このドキュメントの組織
This document first defines the three types of Opaque LSAs followed by a description of OSPF packet processing. The packet processing sections include modifications to the flooding procedure and to the neighbor state machine. Appendix A then gives the packet formats.
このドキュメントは最初に、OSPFパケット処理の記述があとに続いたOpaque LSAsの3つのタイプを定義します。 パケット処理部は氾濫手順と、そして、隣人州のマシンへの変更を含めます。 そして、付録Aはパケット・フォーマットを与えます。
Coltun Standards Track [Page 2] RFC 2370 The OSPF Opaque LSA Option July 1998
OSPFがLSAオプション1998年7月に不透明にするColtun標準化過程[2ページ]RFC2370
2.2 Acknowledgments
2.2 承認
The author would like to thank Dennis Ferguson, Acee Lindem, John Moy, Sandra Murphy, Man-Kit Yeung, Zhaohui "Jeffrey" Zhang and the rest of the OSPF Working Group for the ideas and support they have given to this project.
作者は、このプロジェクトに与えたのを考えとサポートのためのデニスファーガソン、Acee Lindem、ジョンMoy、サンドラ・マーフィー、Man-キットYeung、Zhaohui「ジェフリー」チャン、およびOSPF作業部会の残りに感謝したがっています。
3.0 The Opaque LSA
3.0 不透明なLSA
Opaque LSAs are types 9, 10 and 11 link-state advertisements. Opaque LSAs consist of a standard LSA header followed by a 32-bit aligned application-specific information field. Standard link-state database flooding mechanisms are used for distribution of Opaque LSAs. The range of topological distribution (i.e., the flooding scope) of an Opaque LSA is identified by its link-state type. This section documents the flooding of Opaque LSAs.
不透明なLSAsはタイプ9、10と11のリンク州の広告です。 不透明なLSAsは32ビットの並べられたアプリケーション特有の情報分野があとに続いた標準のLSAヘッダーから成ります。 標準のリンク州のデータベース氾濫メカニズムはOpaque LSAsの分配に使用されます。 Opaque LSAの位相的な分配(すなわち、氾濫範囲)の範囲はリンク州のタイプによって特定されます。 このセクションはOpaque LSAsの氾濫を記録します。
The flooding scope associated with each Opaque link-state type is defined as follows.
それぞれのOpaqueリンク州のタイプに関連している氾濫範囲は以下の通り定義されます。
o Link-state type 9 denotes a link-local scope. Type-9 Opaque
LSAs are not flooded beyond the local (sub)network.
o リンク州のタイプ9はリンク地方の範囲を指示します。 タイプ-9Opaque LSAsはローカルの(潜水艦)ネットワークを超えてあふれません。
o Link-state type 10 denotes an area-local scope. Type-10 Opaque
LSAs are not flooded beyond the borders of their associated area.
o リンク州のタイプ10は領域の地方の範囲を指示します。 タイプ-10Opaque LSAsはそれらの関連領域の境界を超えてあふれません。
o Link-state type 11 denotes that the LSA is flooded throughout
the Autonomous System (AS). The flooding scope of type-11
LSAs are equivalent to the flooding scope of AS-external (type-5)
LSAs. Specifically type-11 Opaque LSAs are 1) flooded throughout
all transit areas, 2) not flooded into stub areas from the
backbone and 3) not originated by routers into their connected
stub areas. As with type-5 LSAs, if a type-11 Opaque LSA is
received in a stub area from a neighboring router within the
stub area the LSA is rejected.
o リンク州のタイプ11は、LSAがAutonomous System(AS)中で水につかっているのを指示します。 タイプ-11LSAsの氾濫範囲はAS外部(タイプ-5)のLSAsの氾濫範囲に同等です。 明確にタイプ-11Opaque LSAsがすべてのトランジット領域中のあふれる、1歳です)、と2は)背骨からスタッブ領域へあふれさせませんでした、そして、3は)ルータでそれらの接続スタッブ領域に由来しませんでした。 タイプ-5LSAsのように、スタッブ領域にスタッブ領域の中の隣接しているルータからタイプ-11Opaque LSAを受け取るなら、LSAを拒絶します。
The link-state ID of the Opaque LSA is divided into an Opaque type field (the first 8 bits) and a type-specific ID (the remaining 24 bits). The packet format of the Opaque LSA is given in Appendix A. Section 7.0 describes Opaque type allocation and assignment.
Opaque LSAのリンク州のIDはOpaqueタイプ分野(最初の8ビット)とタイプ特有のID(残っている24ビット)に分割されます。 Opaque LSAの書式がAppendix A.セクション7.0で与えられているパケットはOpaqueタイプ配分と課題について説明します。
The responsibility for proper handling of the Opaque LSA's flooding scope is placed on both the sender and receiver of the LSA. The receiver must always store a valid received Opaque LSA in its link- state database. The receiver must not accept Opaque LSAs that violate the flooding scope (e.g., a type-11 (domain-wide) Opaque LSA is not accepted in a stub area). The flooding scope effects both the
Opaque LSAの氾濫範囲の適切な取り扱いへの責任は送付者とLSAの受信機の両方に置かれます。 受信機はリンク州のデータベースにいつも有効な容認されたOpaque LSAを格納しなければなりません。 受信機は氾濫範囲に違反するOpaque LSAsを受け入れてはいけません(例えばタイプ-11の(ドメイン全体)の不透明なLSAはスタッブ領域で受け入れられません)。 氾濫範囲は両方に作用します。
Coltun Standards Track [Page 3] RFC 2370 The OSPF Opaque LSA Option July 1998
OSPFがLSAオプション1998年7月に不透明にするColtun標準化過程[3ページ]RFC2370
synchronization of the link-state database and the flooding procedure.
リンク州のデータベースと氾濫手順の同期。
The following describes the modifications to these procedures that are necessary to insure conformance to the Opaque LSA's Scoping Rules.
以下はこれらのOpaque LSAのScoping Rulesに順応を保障するのに必要な手順に変更を説明します。
3.1 Flooding Opaque LSAs
3.1 氾濫の不透明なLSAs
The flooding of Opaque LSAs must follow the rules of Flooding Scope as specified in this section. Section 13 of [OSPF] describes the OSPF flooding procedure. The following describes the Opaque LSA's type-specific flooding restrictions.
Opaque LSAsの氾濫はこのセクションの指定されるとしてのFlooding Scopeの規則に続いて起こらなければなりません。 [OSPF]のセクション13はOSPF氾濫手順について説明します。 以下はOpaque LSAのタイプ特有の氾濫制限について説明します。
o If the Opaque LSA is type 9 (the flooding scope is link-local)
and the interface that the LSA was received on is not the same as
the target interface (e.g., the interface associated with a
particular target neighbor), the Opaque LSA must not be flooded
out that interface (or to that neighbor). An implementation
should keepk track of the IP interface associated with each
Opaque LSA having a link-local flooding scope.
o Opaque LSAがタイプ9であり(氾濫範囲はリンク地方です)、LSAが受け取られたインタフェースが目標インタフェース(例えば、特定の目標隣人に関連しているインタフェース)、Opaque LSAでなければならないのと同じでないなら、水浸しにされて、それは連結します(またはその隣人に)。 実現はリンク地方の氾濫範囲を持っている各Opaque LSAに関連しているIPインタフェースのkeepk道がそうするべきです。
o If the Opaque LSA is type 10 (the flooding scope is area-local)
and the area associated with Opaque LSA (upon reception) is not
the same as the area associated with the target interface, the
Opaque LSA must not be flooded out the interface. An
implementation should keep track of the OSPF area associated
with each Opaque LSA having an area-local flooding scope.
o Opaque LSAがタイプ10(氾濫範囲は領域の地方です)とOpaque LSAに関連している領域(レセプションの)であるなら、目標インタフェース、Opaque LSAに関連している領域を水浸しにしてはいけないような同じくらいはインタフェースではありませんか? 実現は領域の地方の氾濫範囲を持っている各Opaque LSAに関連しているOSPF領域の動向をおさえるべきです。
o If the Opaque LSA is type 11 (the LSA is flooded throughout the
AS) and the target interface is associated with a stub area the
Opaque LSA must not be flooded out the interface. A type-11
Opaque LSA that is received on an interface associated with a
stub area must be discarded and not acknowledged (the
neighboring router has flooded the LSA in error).
o Opaque LSAがタイプ11であり(LSAはAS中で水につかっています)、目標インタフェースがスタッブ領域に関連しているなら、Opaque LSAはインタフェースから水につかっているはずがありません。 スタッブ領域に関連しているインタフェースに受け取られるタイプ-11Opaque LSAを捨てて、承認してはいけません(隣接しているルータはLSAを間違ってあふれさせました)。
When opaque-capable routers and non-opaque-capable OSPF routers are mixed together in a routing domain, the Opaque LSAs are not flooded to the non-opaque-capable routers. As a general design principle, optional OSPF advertisements are only flooded to those routers that understand them.
不透明にできるルータとできる非不透明なものOSPFルータが経路ドメインで一緒に複雑であるときに、Opaque LSAsはできる非不透明なものルータへあふれません。 一般的な設計原理として、任意のOSPF広告はそれらを理解しているそれらのルータへあふれるだけです。
An opaque-capable router learns of its neighbor's opaque capability at the beginning of the "Database Exchange Process" (see Section 10.6 of [OSPF], receiving Database Description packets from a neighbor in state ExStart). A neighbor is opaque-capable if and only if it sets the O-bit in the Options field of its Database Description packets; the O-bit is not set in packets other than Database Description
不透明にできるルータは「データベース交換の過程」の始めに隣人の不透明な能力を知っています([OSPF]のセクション10.6を見てください、州のExStartの隣人からDatabase記述パケットを受けて)。 そして、隣人が不透明にできる、Database記述パケットのOptions分野にO-ビットをはめ込む場合にだけ。 O-ビットはDatabase記述以外のパケットに設定されません。
Coltun Standards Track [Page 4] RFC 2370 The OSPF Opaque LSA Option July 1998
OSPFがLSAオプション1998年7月に不透明にするColtun標準化過程[4ページ]RFC2370
packets. Then, in the next step of the Database Exchange process, Opaque LSAs are included in the Database summary list that is sent to the neighbor (see Sections 3.2 below and 10.3 of [OSPF]) if and only if the neighbor is opaque capable.
パケット。 そして、次に、Opaque LSAsが隣人に送られるDatabase概要リストにDatabase Exchangeの過程の次のステップでは、含まれている、(以下のセクション3.2と10.3[OSPF]を見てください)隣人が不透明なものできる場合にだけ。
When flooding Opaque-LSAs to adjacent neighbors, a opaque-capable router looks at the neighbor's opaque capability. Opaque LSAs are only flooded to opaque-capable neighbors. To be more precise, in Section 13.3 of [OSPF], Opaque LSAs are only placed on the link-state retransmission lists of opaque-capable neighbors. However, when send ing Link State Update packets as multicasts, a non-opaque-capable neighbor may (inadvertently) receive Opaque LSAs. The non-opaque- capable router will then simply discard the LSA (see Section 13 of [OSPF], receiving LSAs having unknown LS types).
隣接している隣人へOpaque-LSAsをあふれさせるとき、不透明にできるルータは隣人の不透明な能力を見ます。 不透明なLSAsは不透明に有能な隣人へあふれるだけです。 [OSPF]のセクション13.3では、より正確に、なるように、Opaque LSAsは不透明に有能な隣人のリンク州の「再-トランスミッション」リストに置かれるだけです。 しかしながら、マルチキャスト、できる非不透明なもの隣人(うっかり)Opaque LSAsを受け取るとき、いつが州Updateパケットをing Linkに送りますか? 非、-そして、不透明にできるルータは単にLSAを捨てるでしょう([OSPF]のセクション13を見てください、未知のLSタイプがあるLSAsを受けて)。
3.2 Modifications To The Neighbor State Machine
隣人への3.2の変更がマシンを述べます。
The state machine as it exists in section 10.3 of [OSPF] remains unchanged except for the action associated with State: ExStart, Event: NegotiationDone which is where the Database summary list is built. To incorporate the Opaque LSA in OSPF this action is changed to the following.
[OSPF]のセクション10.3に存在するとき、州に関連している動作以外に、州のマシンは変わりがありません: ExStart、出来事: Database概要リストが組立しているところであるNegotiationDone。 Opaque LSAをOSPFに組み込むために、この動作は以下に変わります。
State(s): ExStart
州: ExStart
Event: NegotiationDone
出来事: NegotiationDone
New state: Exchange
新しい州: 交換
Action: The router must list the contents of its entire area
link-state database in the neighbor Database summary
list. The area link-state database consists of the
Router LSAs, Network LSAs, Summary LSAs and types 9 and
10 Opaque LSAs contained in the area structure, along
with AS External and type-11 Opaque LSAs contained in
the global structure. AS External and type-11 Opaque
LSAs are omitted from a virtual neighbor's Database
summary list. AS External LSAs and type-11 Opaque LSAs
are omitted from the Database summary list if the area
has been configured as a stub area (see Section 3.6 of
[OSPF]).
動作: ルータは隣人Database概要リストの全体の領域リンク州のデータベースのコンテンツを記載しなければなりません。 領域リンク州のデータベースはRouter LSAs、Network LSAs、Summary LSAs、および領域構造に含まれたタイプ9と10Opaque LSAsから成ります、グローバル構造に含まれたAS Externalとタイプ-11Opaque LSAsと共に。 AS Externalとタイプ-11Opaque LSAsが仮想の隣人のDatabase概要リストから省略されます。 領域がスタッブ領域として構成されたなら([OSPF]のセクション3.6を見てください)、AS External LSAsとタイプ-11Opaque LSAsがDatabase概要リストから省略されます。
Type-9 Opaque LSAs are omitted from the Database summary
list if the interface associated with the neighbor is
not the interface associated with the Opaque LSA (as
noted upon reception).
タイプ-9Opaque LSAsが隣人に関連しているインタフェースがOpaque LSAに関連しているインタフェース(レセプションに述べられるように)でないならDatabase概要リストから省略されます。
Coltun Standards Track [Page 5] RFC 2370 The OSPF Opaque LSA Option July 1998
OSPFがLSAオプション1998年7月に不透明にするColtun標準化過程[5ページ]RFC2370
Any advertisement whose age is equal to MaxAge is
omitted from the Database summary list. It is instead
added to the neighbor's link-state retransmission list.
A summary of the Database summary list will be sent to
the neighbor in Database Description packets. Each
Database Description Packet has a DD sequence number,
and is explicitly acknowledged. Only one Database
Description Packet is allowed to be outstanding at any
one time. For more detail on the sending and receiving
of Database Description packets, see Sections 10.6 and
10.8 of [OSPF].
年令がMaxAgeと等しいどんな広告もDatabase概要リストから省略されます。 それは代わりに隣人のリンク州の「再-トランスミッション」リストに追加されます。 Database概要リストの概要をDatabase記述パケットの隣人に送るでしょう。 それぞれのDatabase記述PacketはDD一連番号を持って、明らかに承認されます。 1Database記述Packetだけがいかなる時も傑出しているのが許容されています。 Database記述パケットの送受信に関するその他の詳細に関しては、[OSPF]のセクション10.6と10.8を見てください。
4.0 Protocol Data Structures
4.0 プロトコルデータ構造
The Opaque option is described herein in terms of its operation on various protocol data structures. These data structures are included for explanatory uses only, and are not intended to constrain an implementation. In addition to the data structures listed below, this specification references the various data structures (e.g., OSPF neighbors) defined in [OSPF].
Opaqueオプションは様々なプロトコルデータ構造で操作でここに説明されます。 これらのデータ構造は、説明している用途だけのために含まれていて、実現を抑制することを意図しません。 以下に記載されたデータ構造、様々なデータ構造(例えば、OSPF隣人)が[OSPF]で定義したこの仕様参照に加えて。
In an OSPF router, the following item is added to the list of global OSPF data structures described in Section 5 of [OSPF]:
OSPFルータでは、以下の項目は[OSPF]のセクション5で説明されたグローバルなOSPFデータ構造のリストに追加されます:
o Opaque capability. Indicates whether the router is running the
Opaque option (i.e., capable of storing Opaque LSAs). Such a
router will continue to inter-operate with non-opaque-capable
OSPF routers.
o 能力について不透明にしてください。 ルータがOpaqueオプション(すなわち、Opaque LSAsを格納できる)を走らせているか否かに関係なく、示します。 そのようなルータは、できる非不透明なものOSPFルータで共同利用し続けるでしょう。
4.1 Additions To The OSPF Neighbor Structure
4.1 OSPF隣人構造への追加
The OSPF neighbor structure is defined in Section 10 of [OSPF]. In an opaque-capable router, the following items are added to the OSPF neighbor structure:
OSPF隣人構造は[OSPF]のセクション10で定義されます。 不透明にできるルータでは、以下の項目はOSPF隣人構造に追加されます:
o Neighbor Options. This field was already defined in the OSPF
specification. However, in opaque-capable routers there is a new
option which indicates the neighbor's Opaque capability. This new
option is learned in the Database Exchange process through
reception of the neighbor's Database Description packets, and
determines whether Opaque LSAs are flooded to the neighbor. For a
more detailed explanation of the flooding of the Opaque LSA see
section 3 of this document.
o 隣人オプション。 この分野はOSPF仕様に基づき既に定義されました。 しかしながら、不透明にできるルータには、隣人のOpaque能力を示す新しいオプションがあります。 この新しいオプションは、隣人のDatabase記述パケットのレセプションを通してDatabase Exchangeの過程で学習されて、隣人にとって、Opaque LSAsが水につかっているかどうか決定します。 Opaque LSAの氾濫の、より詳細な説明に関しては、このドキュメントのセクション3を見てください。
Coltun Standards Track [Page 6] RFC 2370 The OSPF Opaque LSA Option July 1998
OSPFがLSAオプション1998年7月に不透明にするColtun標準化過程[6ページ]RFC2370
5.0 Management Considerations
5.0 管理問題
This section identifies the current OSPF MIB [OSPFMIB] capabilities that are applicable to the Opaque option and lists the additional management information which is required for its support.
このセクションは、Opaqueオプションに適切な現在のOSPF MIB[OSPFMIB]能力を特定して、サポートに必要である追加経営情報をリストアップします。
Opaque LSAs are types 9, 10 and 11 link-state advertisements. The link-state ID of the Opaque LSA is divided into an Opaque type field (the first 8 bits) and a type-specific ID (the remaining 24 bits). The packet format of the Opaque LSA is given in Appendix A. The range of topological distribution (i.e., the flooding scope) of an Opaque LSA is identified by its link-state type.
不透明なLSAsはタイプ9、10と11のリンク州の広告です。 Opaque LSAのリンク州のIDはOpaqueタイプ分野(最初の8ビット)とタイプ特有のID(残っている24ビット)に分割されます。 Appendix A.でOpaque LSAのパケット・フォーマットを与えます。リンク州のタイプはOpaque LSAの位相的な分配(すなわち、氾濫範囲)の範囲を特定します。
o Link-State type 9 Opaque LSAs have a link-local scope. Type-9
Opaque LSAs are flooded on a single local (sub)network but are
not flooded beyond the local (sub)network.
o リンク州のタイプ9Opaque LSAsには、リンク地方の範囲があります。 タイプ-9Opaque LSAsはただ一つのローカルの(潜水艦)ネットワークで水につかりますが、ローカルの(潜水艦)ネットワークを超えてあふれません。
o Link-state type 10 Opaque LSAs have an area-local scope. Type-10
Opaque LSAs are flooded throughout a single area but are not
flooded beyond the borders of the associated area.
o リンク州のタイプ10Opaque LSAsには、領域の地方の範囲があります。 タイプ-10Opaque LSAsはただ一つの領域中で水につかりますが、関連領域の境界を超えてあふれません。
o Link-state type 11 Opaque LSAs have an Autonomous-System-wide
scope. The flooding scope of type-11 LSAs are equivalent to the
flooding scope of AS-external (type-5) LSAs.
o リンク州のタイプ11Opaque LSAsには、Autonomousシステム広範囲があります。 タイプ-11LSAsの氾濫範囲はAS外部(タイプ-5)のLSAsの氾濫範囲に同等です。
The OSPF MIB provides a number of objects that can be used to manage and monitor an OSPF router's Link-State Database. The ones that are relevant to the Opaque option are as follows.
OSPF MIBはOSPFルータのLink-州のDatabaseを管理して、モニターするのに使用できる多くの物を提供します。 Opaqueオプションに関連しているものは以下の通りです。
The ospfGeneralGroup defines two objects for keeping track of newly
originated and newly received LSAs (ospfOriginateNewLsas and
ospfRxNewLsas respectively).
ospfGeneralGroupが新たに溯源されて、新たに受け取られたLSAsの動向をおさえるために2個の物を定義する、(ospfOriginateNewLsasとospfRxNewLsas、それぞれ)
The OSPF MIB defines a set of optional traps. The ospfOriginateLsa
trap signifies that a new LSA has been originated by a router and
the ospfMaxAgeLsa trap signifies that one of the LSAs in the
router's link-state database has aged to MaxAge.
OSPF MIBは1セットの任意の罠を定義します。 ospfOriginateLsa罠は、新しいLSAがルータによって溯源されたのを意味します、そして、ospfMaxAgeLsa罠はルータのリンク州のデータベースのLSAsの1つがMaxAgeに年をとったのを意味します。
The ospfAreaTable describes the configured parameters and
cumulative statistics of the router's attached areas. This table
includes a count of the number of LSAs contained in the area's
link-state database (ospfAreaLsaCount), and a sum of the LSA's LS
checksums contained in this area (ospfAreaLsaCksumSum). This sum
can be used to determine if there has been a change in a router's
link-state database, and to compare the link-state database of two
routers.
ospfAreaTableはルータの付属領域の構成されたパラメタと累積している統計について説明します。 このテーブルは領域のリンク州のデータベース(ospfAreaLsaCount)に含まれた、LSAsの数のカウント、およびこの領域(ospfAreaLsaCksumSum)に保管されていたLSAのLSチェックサムの合計を含んでいます。 ルータのリンク州のデータベースにおける変化があったかどうか決定して、2つのルータに関するリンク州のデータベースを比較するのにこの合計を使用できます。
Coltun Standards Track [Page 7] RFC 2370 The OSPF Opaque LSA Option July 1998
OSPFがLSAオプション1998年7月に不透明にするColtun標準化過程[7ページ]RFC2370
The ospfLsdbTable describes the OSPF Process's link-state database
(excluding AS-external LSAs). Entries in this table are indexed
with an Area ID, a link-state type, a link-state ID and the
originating router's Router ID.
ospfLsdbTableはOSPF Processのリンク州のデータベース(AS外部のLSAsを除いた)について説明します。 このテーブルのエントリーはArea ID、リンク州のタイプ、リンク州のID、および由来しているルータのRouter IDと共に索引をつけられます。
The management objects that are needed to support the Opaque option are as follows.
Opaqueオプションをサポートするのが必要である管理物は以下の通りです。
An Opaque-option-enabled object is needed to indicate if the Opaque
option is enabled on the router.
可能にされたOpaqueオプション物が、Opaqueオプションがルータで可能にされるかどうかを示すのに必要です。
The origination and reception of new Opaque LSAs should be
reflected in the counters ospfOriginateNewLsas and ospfRxNewLsas
(inclusive for types 9, 10 and 11 Opaque LSAs).
新しいOpaque LSAsの創作とレセプションはカウンタのospfOriginateNewLsasとospfRxNewLsasに(タイプ9、10、および11Opaque LSAsに包括的)で反映されるべきです。
If the OSPF trap option is supported, the origination of new Opaque
LSAs and purging of MaxAge Opaque LSAs should be reflected in the
ospfOriginateLsa and ospfMaxAgeLsa traps (inclusive for types 9, 10
and 11 Opaque LSAs).
OSPF罠オプションがサポートされるなら、新しいOpaque LSAsの創作とMaxAge Opaque LSAsを除くことはospfOriginateLsaとospfMaxAgeLsa罠に(タイプ9、10、および11Opaque LSAsに包括的)で反映されるべきです。
The number of type-10 Opaque LSAs should be reflected in
ospfAreaLsaCount; the checksums of type-10 Opaque LSAs should be
included in ospfAreaLsaChksumSum.
タイプ-10Opaque LSAsの数はospfAreaLsaCountに反映されるべきです。 タイプ-10Opaque LSAsのチェックサムはospfAreaLsaChksumSumに含まれるべきです。
Type-10 Opaque LSAs should be included in the ospfLsdbTable. Note
that this table does not include a method of examining the Opaque
type field (in the Opaque option this is a sub-field of the link-
state ID).
タイプ-10Opaque LSAsがospfLsdbTableに含まれるべきです。 このテーブルがOpaqueタイプ分野を調べる方法を含んでいないという(Opaqueオプションでは、これはリンク州のIDのサブ分野です)メモ。
Up until now, LSAs have not had a link-local scope so there is no
method of requesting the number of, or examining the LSAs that are
associated with a specific OSPF interface. A new group of
management objects are required to support type-9 Opaque LSAs.
These objects should include a count of type-9 Opaque LSAs, a
checksum sum and a table for displaying the link-state database for
type-9 Opaque LSAs on a per-interface basis. Entries in this table
should be indexed with an Area ID, interface's IP address, Opaque
type, link-state ID and the originating router's Router ID.
LSAsには現在まで、リンク地方の範囲がなくて、したがって、特定のOSPFインタフェースに関連しているLSAsを数を要求する方法が全くないか、または調べます。 管理物の新しいグループが、タイプ-9Opaque LSAsを支持するのに必要です。 これらの物は1インタフェースあたり1個のベースにタイプ-9Opaque LSAsのためのリンク州のデータベースを表示するためのタイプ-9Opaque LSAsのカウント、チェックサム合計、およびテーブルを含んでいるはずです。 このテーブルのエントリーはArea ID、インタフェースのIPアドレス、Opaqueタイプ、リンク州のID、および由来しているルータのRouter IDと共に索引をつけられるべきです。
Prior to the introduction of type-11 Opaque LSAs, AS-External
(type-5) LSAs have been the only link-state types which have an
Autonomous-System-wide scope. A new group of objects are required
to support type-11 Opaque LSAs. These objects should include a
count of type-11 Opaque LSAs, a type-11 checksum sum and a table
for displaying the type-11 link-state database. Entries in this
table should be indexed with the Opaque type, link-state ID and the
タイプ-11Opaque LSAsの導入の前に、AS外部(タイプ-5)のLSAsはAutonomousシステム広範囲を持っている唯一のリンク州のタイプです。 物の新しいグループが、タイプ-11Opaque LSAsを支持するのに必要です。 これらの物はタイプ-11Opaque LSAsのカウント、タイプ-11チェックサム合計、およびタイプ-11リンク州のデータベースを表示するためのテーブルを含んでいるはずです。 そしてOpaqueタイプでこのテーブルのエントリーが索引をつけられるべきであり、リンク状態がIDである。
Coltun Standards Track [Page 8] RFC 2370 The OSPF Opaque LSA Option July 1998
OSPFがLSAオプション1998年7月に不透明にするColtun標準化過程[8ページ]RFC2370
originating router's Router ID. The type-11 link-state database
table will allow type-11 LSAs to be displayed once for the router
rather than once in each non-stub area.
ルータのRouter IDを溯源します。 タイプ-11リンク州のデータベースのテーブルは、タイプ-11LSAsがそれぞれの非スタッブ領域に一度であるというよりむしろルータのための一度表示されるのを許容するでしょう。
6.0 Security Considerations
6.0 セキュリティ問題
There are two types of issues that need be addressed when looking at protecting routing protocols from misconfigurations and malicious attacks. The first is authentication and certification of routing protocol information. The second is denial of service attacks resulting from repetitive origination of the same router advertisement or origination a large number of distinct advertisements resulting in database overflow. Note that both of these concerns exist independently of a router's support for the Opaque option.
misconfigurationsと悪意ある攻撃からルーティング・プロトコルを保護するのを検討するとき記述されなければならない2つのタイプの問題があります。 1番目は、ルーティングプロトコル情報の認証と証明です。 2番目は同じルータ通知の反復性の創作かデータベースオーバーフローをもたらす異なった広告の創作多くから生じるサービス不能攻撃です。 これらの関心の両方がルータのOpaqueオプションのサポートの如何にかかわらず存在することに注意してください。
To address the authentication concerns, OSPF protocol exchanges are authenticated. OSPF supports multiple types of authentication; the type of authentication in use can be configured on a per network segment basis. One of OSPF's authentication types, namely the Cryptographic authentication option, is believed to be secure against passive attacks and provide significant protection against active attacks. When using the Cryptographic authentication option, each router appends a "message digest" to its transmitted OSPF packets. Receivers then use the shared secret key and received digest to verify that each received OSPF packet is authentic.
認証関心を記述するために、OSPFプロトコル交換は認証されます。 OSPFは複数のタイプの認証を支持します。 ネットワークセグメント基礎あたりのaで使用中の認証のタイプを構成できます。 受け身の攻撃に対して安全であり、OSPFの認証タイプのひとり(すなわち、Cryptographic認証オプション)が活発な攻撃に対して重要な保護を提供すると信じられています。 Cryptographic認証オプションを使用するとき、各ルータは「メッセージダイジェスト」を伝えられたOSPFパケットに追加します。 そして、受信機は、それぞれの容認されたOSPFパケットが正統であることを確かめるのに共有秘密キーの主要で受け取られていているダイジェストを使用します。
The quality of the security provided by the Cryptographic authentication option depends completely on the strength of the message digest algorithm (MD5 is currently the only message digest algorithm specified), the strength of the key being used, and the correct implementation of the security mechanism in all communicating OSPF implementations. It also requires that all parties maintain the secrecy of the shared secret key. None of the standard OSPF authentication types provide confidentiality. Nor do they protect against traffic analysis. For more information on the standard OSPF security mechanisms, see Sections 8.1, 8.2, and Appendix D of [OSPF].
Cryptographic認証オプションで提供されたセキュリティの品質は完全メッセージダイジェストアルゴリズム(現在、MD5は指定された唯一のメッセージダイジェストアルゴリズムである)の強さ、使用されるキーの強さ、およびすべてでのOSPF実現を伝えるセキュリティー対策の正しい実現に依存します。 また、それは、すべてのパーティーが共有された秘密鍵の秘密主義を維持するのを必要とします。 標準のOSPF認証タイプのだれも秘密性を提供しません。 また、彼らはトラヒック分析から守りません。 標準のOSPFセキュリティー対策の詳しい情報に関しては、セクション8.1、8.2、および[OSPF]のAppendix Dを見てください。
[DIGI] describes the extensions to OSPF required to add digital signature authentication to Link State data and to provide a certification mechanism for router data. [DIGI] also describes the added LSA processing and key management as well as a method for migration from, or co-existence with, standard OSPF V2.
[DIGI]はLink州データにデジタル署名認証を追加して、証明メカニズムをルータデータに提供しなければならなかったOSPFに拡大について説明します。 また、[DIGI]が移動のためのa方法と同様に加えられたLSA処理とかぎ管理を説明する、共存、標準のOSPF V2。
Repetitive origination of advertisements are addressed by OSPF by mandating a limit on the frequency that new instances of any particular LSA can be originated and accepted during the flooding procedure. The frequency at which new LSA instances may be
広告の反復性の創作は頻度におけるどんな特定のLSAの新しい例もそうであることができる限界を強制することによって溯源されて、氾濫手順の間に受け入れられたOSPFによって記述されます。 新しいLSA例がそうである頻度
Coltun Standards Track [Page 9] RFC 2370 The OSPF Opaque LSA Option July 1998
OSPFがLSAオプション1998年7月に不透明にするColtun標準化過程[9ページ]RFC2370
originated is set equal to once every MinLSInterval seconds, whose value is 5 seconds (see Section 12.4 of [OSPF]). The frequency at which new LSA instances are accepted during flooding is once every MinLSArrival seconds, whose value is set to 1 (see Section 13, Appendix B and G.5 of [OSPF]).
溯源されているのは、かつての秒、値が5秒であるあらゆるMinLSIntervalと等しいセット([OSPF]のセクション12.4を見る)です。 かつて新しいLSA例が氾濫の間に受け入れられる頻度は秒、値が1に設定されるあらゆるMinLSArrival([OSPF]のセクション13、Appendix B、およびG.5を見る)です。
Proper operation of the OSPF protocol requires that all OSPF routers maintain an identical copy of the OSPF link-state database. However, when the size of the link-state database becomes very large, some routers may be unable to keep the entire database due to resource shortages; we term this "database overflow". When database overflow is anticipated, the routers with limited resources can be accommodated by configuring OSPF stub areas and NSSAs. [OVERFLOW] details a way of gracefully handling unanticipated database overflows.
OSPFプロトコルの適切な操作は、すべてのOSPFルータがOSPFリンク州のデータベースの同一の複製物を維持するのを必要とします。 しかしながら、リンク州のデータベースのサイズが非常に大きくなるとき、リソース不足のため、いくつかのルータは全体のデータベースを保つことができないかもしれません。 私たち、用語、この「データベースオーバーフロー。」 データベースオーバーフローが予期されるとき、OSPFスタッブ領域とNSSAsを構成することによって、限りある資源があるルータを設備することができます。 [OVERFLOW]は優雅に思いがけないデータベースオーバーフローを扱う方法を詳しく述べます。
7.0 IANA Considerations
7.0 IANA問題
Opaque types are maintained by the IANA. Extensions to OSPF which require a new Opaque type must be reviewed by the OSPF working group. In the event that the OSPF working group has disbanded the review shall be performed by a recommended Designated Expert.
分っているタイプはIANAによって維持されます。 OSPFワーキンググループは新しいOpaqueタイプを必要とするOSPFへの拡大を見直さなければなりません。 OSPFワーキンググループが解散された場合、レビューはお勧めのDesignated Expertによって実行されるものとします。
Following the policies outlined in [IANA], Opaque type values in the range of 0-127 are allocated through an IETF Consensus action and Opaque type values in the range of 128-255 are reserved for private and experimental use.
[IANA]に概説された方針に従って、IETF Consensus動作で0-127の範囲のOpaqueタイプ値を割り当てます、そして、個人的で実験的な使用のために128-255の範囲のOpaqueタイプ値を予約します。
8.0 References
8.0の参照箇所
[ARA] Coltun, R., and J. Heinanen, "The OSPF Address Resolution
Advertisement Option", Work in Progress.
[ARA] Coltun、R.、およびJ.Heinanen、「OSPFアドレス解決広告オプション」が進行中で働いています。
[DEMD] Moy, J., "Extending OSPF to Support Demand Circuits", RFC
1793, April 1995.
[DEMD] Moy、J.、「要求サーキットを支えるためにOSPFを広げています」、RFC1793、1995年4月。
[DIGI] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital
Signatures", RFC 2154, June 1997.
1997年6月の[DIGI]マーフィーとS.とムジナ、M.とB.ウェリントン、「デジタル署名があるOSPF」RFC2154。
[IANA] Narten, T., and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", Work in Progress.
T.、およびH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」という[IANA]Nartenは進行中で働いています。
[MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March
1994.
[MOSPF] Moy、J.、「OSPFへのマルチキャスト拡大」、RFC1584、1994年3月。
Coltun Standards Track [Page 10] RFC 2370 The OSPF Opaque LSA Option July 1998
OSPFがLSAオプション1998年7月に不透明にするColtun標準化過程[10ページ]RFC2370
[NSSA] Coltun, R., and V. Fuller, "The OSPF NSSA Option", RFC 1587,
March 1994.
1994年3月の[NSSA]Coltun、R.とV.フラー、「OSPF NSSAオプション」RFC1587。
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPF]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
[OSPFMIB] Baker, F., and R. Coltun, "OSPF Version 2 Management
Information Base", RFC 1850, November 1995.
[OSPFMIB] ベイカー、F.とR.Coltun、「OSPFバージョン2管理情報ベース」、RFC1850、1995年11月。
[OVERFLOW] Moy, J., "OSPF Database Overflow", RFC 1765,
March 1995.
[オーバーフロー]Moy、J.、「OSPFデータベースオーバーフロー」、RFC1765、1995年3月。
9.0 Author's Information
9.0 作者の情報
Rob Coltun FORE Systems
Coltunの前面のシステムから、略奪してください。
Phone: (703) 245-4543 EMail: rcoltun@fore.com
以下に電話をしてください。 (703) 245-4543 メールしてください: rcoltun@fore.com
Coltun Standards Track [Page 11] RFC 2370 The OSPF Opaque LSA Option July 1998
OSPFがLSAオプション1998年7月に不透明にするColtun標準化過程[11ページ]RFC2370
Appendix A: OSPF Data formats
付録A: OSPF Data形式
This appendix describes the format of the Options Field followed by the packet format of the Opaque LSA.
この付録はOpaque LSAのパケット・フォーマットがあとに続いたOptions Fieldの形式について説明します。
A.1 The Options Field
A.1オプション分野
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 Options分野はOSPF Helloパケット、Database記述パケット、およびすべてのリンク州の広告に存在しています。 Options分野は、OSPFルータが(または、サポートでない)任意の能力を支持して、それらの能力レベルを他のOSPFルータに伝えるのを可能にします。 このメカニズムを通して、異なった能力のルータはOSPF経路ドメインの中で複雑であることができます。
When used in Hello packets, the Options field allows a router to reject a neighbor because of a capability mismatch. Alternatively, when capabilities are exchanged in Database Description packets a router can choose not to forward certain link-state advertisements to a neighbor because of its reduced functionality. Lastly, listing capabilities in link-state advertisements allows routers to forward traffic around reduced functionality routers by excluding them from parts of the routing table calculation.
Helloパケットで使用されると、Options分野で、ルータは能力ミスマッチで隣人を拒絶できます。 Database記述パケットで能力を交換するとき、あるいはまた、ルータは、減少している機能性のためにあるリンク州の広告を隣人に転送しないのを選ぶことができます。 最後に、リンク州の広告における能力を記載するのに、ルータは、経路指定テーブル計算の部品にそれらを入れないようにすることによって、減少している機能性ルータの周りの交通を進めることができます。
Six bits of the OSPF Options field have been assigned, although only the O-bit is described completely by this memo. Each bit is described briefly below. Routers should reset (i.e., clear) unrecognized bits in the Options field when sending Hello packets or Database Description packets and when originating link-state advertisements. Conversely, routers encountering unrecognized Option bits in received Hello Packets, Database Description packets or link-state advertisements should ignore the capability and process the packet/advertisement normally.
O-ビットだけが完全にこのメモで説明されますが、OSPF Options分野の6ビットを割り当ててあります。 各ビットは簡潔に以下で説明されます。 HelloパケットかDatabase記述パケットといつにリンク州の広告を溯源させるかとき、ルータはOptions分野に(すなわち、明確)の認識されていないビットをリセットするべきです。 逆に、容認されたHello Packetsで認識されていないOptionビットに遭遇するルータ、Database記述パケットまたはリンク州の広告が、能力を無視して、通常、パケット/広告を処理するはずです。
+------------------------------------+
| * | O | DC | EA | N/P | MC | E | * |
+------------------------------------+
+------------------------------------+ | * | O| DC| EA| N/P| M.C.| E| * | +------------------------------------+
The Options Field
オプション分野
E-bit
This bit describes the way AS-external-LSAs are flooded, as
described in Sections 3.6, 9.5, 10.8 and 12.1.2 of [OSPF].
電子ビットThisビットはASの外部のLSAsが.2セクション3.6、9.5、10.8、および12.1[OSPF]で説明されるように水につかっている方法を述べます。
MC-bit
This bit describes whether IP multicast datagrams are forwarded
according to the specifications in [MOSPF].
ビットThisビットM.C.は、IPマルチキャストデータグラムが[MOSPF]の仕様通りに進められるかどうか説明します。
Coltun Standards Track [Page 12] RFC 2370 The OSPF Opaque LSA Option July 1998
OSPFがLSAオプション1998年7月に不透明にするColtun標準化過程[12ページ]RFC2370
N/P-bit
This bit describes the handling of Type-7 LSAs, as specified in
[NSSA].
PでN/噛み付いているThisビットは[NSSA]で指定されるようにType-7 LSAsの取り扱いについて説明します。
DC-bit
This bit describes the router's handling of demand circuits, as
specified in [DEMD].
DC-ビットThisビットは[DEMD]で指定されるように要求サーキットのルータの取り扱いについて説明します。
EA-bit
This bit describes the router's willingness to receive and
forward External-Attributes-LSAs, as specified in [EAL].
EA-ビットThisビットは[EAL]で指定されるように受信するルータの意欲と前進のExternal属性LSAsについて説明します。
O-bit
This bit describes the router's willingness to receive and
forward Opaque-LSAs as specified in this document.
O-ビットThisビットはこのドキュメントの指定されるとしての受信するルータの意欲と前進のOpaque-LSAsについて説明します。
A.2 The Opaque LSA
A.2の不透明なLSA
Opaque LSAs are Type 9, 10 and 11 link-state advertisements. These advertisements may be used directly by OSPF or indirectly by some application wishing to distribute information throughout the OSPF domain. The function of the Opaque LSA option is to provide for future extensibility of OSPF.
不透明なLSAsはType9、10、および11リンク州の広告です。 これらの広告は直接OSPFか間接的にOSPFドメインに情報を分配したがっている何らかのアプリケーションで使用されるかもしれません。 Opaque LSAオプションの機能はOSPFの将来の伸展性に備えることです。
Opaque LSAs contain some number of octets (of application-specific data) padded to 32-bit alignment. Like any other LSA, the Opaque LSA uses the link-state database distribution mechanism for flooding this information throughout the topology. However, the Opaque LSA has a flooding scope associated with it so that the scope of flooding may be link-local (type 9), area-local (type 10) or the entire OSPF routing domain (type 11). Section 3 of this document describes the flooding procedures for the Opaque LSA.
不透明なLSAsは32ビットの整列に水増しされた何らかの数の八重奏(アプリケーション特有のデータの)を含んでいます。 いかなる他のLSAのようにも、Opaque LSAは、トポロジー中にこの情報をあふれさせるのにリンク州のデータベース分配メカニズムを使用します。 しかしながら、Opaque LSAには、それに関連している氾濫範囲が、氾濫の範囲がリンク地方であって(9をタイプします)、領域の地方であって(10をタイプします)全体のOSPF経路ドメインであることができる(11をタイプする)ようにあります。 このドキュメントのセクション3はOpaque LSAのために氾濫手順について説明します。
Coltun Standards Track [Page 13] RFC 2370 The OSPF Opaque LSA Option July 1998
OSPFがLSAオプション1998年7月に不透明にするColtun標準化過程[13ページ]RFC2370
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 | 9, 10 or 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Type | Opaque ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Opaque Information |
+ +
| ... |
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時代| オプション| 9、10または11| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 分っているタイプ| 不透明なID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 広告ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSチェックサム| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | 不明瞭な情報| + + | ... |
Link-State Type
リンク州のタイプ
The link-state type of the Opaque LSA identifies the LSA's range of
topological distribution. This range is referred to as the Flooding
Scope. The following explains the flooding scope of each of the
link-state types.
Opaque LSAのリンク州のタイプはLSAの位相的な分配の範囲を特定します。 この範囲はFlooding Scopeと呼ばれます。 以下で、それぞれのリンク状態の氾濫範囲がタイプされるのがわかります。
o A value of 9 denotes a link-local scope. Opaque LSAs with a
link-local scope are not flooded beyond the local (sub)network.
o 9の値はリンク地方の範囲を指示します。 リンク地方の範囲がある不透明なLSAsはローカルの(潜水艦)ネットワークを超えてあふれません。
o A value of 10 denotes an area-local scope. Opaque LSAs with a
area-local scope are not flooded beyond the area that they are
originated into.
o 10の値は領域の地方の範囲を指示します。 領域の地方の範囲がある不透明なLSAsは彼らが溯源される領域を超えてあふれません。
o A value of 11 denotes that the LSA is flooded throughout the
Autonomous System (e.g., has the same scope as type-5 LSAs).
Opaque LSAs with AS-wide scope are not flooded into stub areas.
o 11の値は、LSAがAutonomous System(例えば、タイプ-5LSAsと同じ範囲を持っている)中で水につかっているのを指示します。 AS-広範囲がある不透明なLSAsはスタッブ領域へあふれません。
Syntax Of The Opaque LSA's Link-State ID
不透明なLSAのリンク州のIDの構文
The link-state ID of the Opaque LSA is divided into an Opaque Type field (the first 8 bits) and an Opaque ID (the remaining 24 bits). See section 7.0 of this document for a description of Opaque type allocation and assignment.
Opaque LSAのリンク州のIDはOpaque Type分野(最初の8ビット)とOpaque ID(残っている24ビット)に分割されます。 Opaqueの記述のためのこのドキュメントのセクション7.0が配分と課題をタイプするのを見てください。
Coltun Standards Track [Page 14] RFC 2370 The OSPF Opaque LSA Option July 1998
OSPFがLSAオプション1998年7月に不透明にするColtun標準化過程[14ページ]RFC2370
Appendix B. Full Copyright Statement
付録のB.の完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Coltun Standards Track [Page 15]
Coltun標準化過程[15ページ]
一覧
スポンサーリンク
