RFC5250 日本語訳
5250 The OSPF Opaque LSA Option. L. Berger, I. Bryskin, A. Zinin, R.Coltun. July 2008. (Format: TXT=37657 bytes) (Obsoletes RFC2370) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group L. Berger
Request for Comments: 5250 LabN
Obsoletes: 2370 I. Bryskin
Category: Standards Track Adva
A. Zinin
Alcatel-Lucent
R. Coltun
Acoustra Productions
July 2008
コメントを求めるワーキンググループL.バーガー要求をネットワークでつないでください: 5250LabNは以下を時代遅れにします。 2370年のI.Bryskinカテゴリ: R.Coltun Acoustra創作2008年7月にアルカテル透明な標準化過程Adva A.ジニン
The OSPF Opaque LSA Option
OSPFの不明瞭なLSAオプション
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document defines enhancements to the OSPF protocol to support a new class of link state advertisements (LSAs) 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 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.
このドキュメントは、Opaque LSAsと呼ばれる新しいクラスのリンク州の広告(LSAs)を支持するためにOSPFプロトコルと増進を定義します。 不透明なLSAsは、OSPFの将来の伸展性を考慮するために一般化されたメカニズムを提供します。 不透明なLSAsはアプリケーション特有の情報があとに続いた標準のLSAヘッダーから成ります。 情報フィールドは直接OSPFか他のアプリケーションで使用されるかもしれません。 標準のOSPFリンク州のデータベース氾濫メカニズムは、OSPFトポロジーのすべてか何らかの限られた部分にOpaque LSAsを分配するのに使用されます。
This document replaces RFC 2370 and adds to it a mechanism to enable an OSPF router to validate Autonomous System (AS)-scope Opaque LSAs originated outside of the router's OSPF area.
このドキュメントは、OSPFルータがOpaque LSAsがルータのOSPF領域の外で溯源したAutonomous System(AS)範囲を有効にするのを可能にするためにRFC2370を取り替えて、それにメカニズムを加えます。
Berger, et al. Standards Track [Page 1] RFC 5250 OSPF Opaque LSA Option July 2008
バーガー、他 標準化過程[1ページ]RFC5250OSPFはオプション2008年7月にLSAについて不透明にします。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Organization of This Document ..............................3
1.2. Acknowledgments ............................................3
2. Conventions Used in This Document ...............................4
3. The Opaque LSA ..................................................4
3.1. Flooding Opaque LSAs .......................................5
3.2. Modifications to the Neighbor State Machine ................6
4. Protocol Data Structures ........................................7
4.1. Additions to the OSPF Neighbor Structure ...................8
5. Inter-Area Considerations .......................................8
6. Management Considerations .......................................9
7. Backward Compatibility ..........................................9
8. Security Considerations .........................................9
9. IANA Considerations ............................................11
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................12
Appendix A. OSPF Data formats .....................................13
A.1. The Options Field .........................................13
A.2. The Opaque LSA ............................................14
1. 序論…3 1.1. このドキュメントの組織…3 1.2. 承認…3 2. このドキュメントで中古のコンベンション…4 3. 不透明なLSA…4 3.1. 氾濫の不透明なLSAs…5 3.2. 隣人への変更はマシンを述べます…6 4. データ構造について議定書の中で述べてください…7 4.1. OSPF隣人構造への追加…8 5. 相互領域問題…8 6. 管理問題…9 7. 後方の互換性…9 8. セキュリティ問題…9 9. IANA問題…11 10. 参照…12 10.1. 標準の参照…12 10.2. 有益な参照…12 付録A.OSPF Data形式…13 A.1。 オプション分野…13 A.2。 不透明なLSA…14
Berger, et al. Standards Track [Page 2] RFC 5250 OSPF Opaque LSA Option July 2008
バーガー、他 標準化過程[2ページ]RFC5250OSPFはオプション2008年7月にLSAについて不透明にします。
1. Introduction
1. 序論
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 document defines enhancements to the OSPF protocol to support a new class of link state advertisements (LSAs) 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. The exact use of Opaque LSAs is beyond the scope of this document.
このドキュメントは、Opaque LSAsと呼ばれる新しいクラスのリンク州の広告(LSAs)を支持するためにOSPFプロトコルと増進を定義します。 不透明なLSAsは、OSPFの将来の伸展性を考慮するために一般化されたメカニズムを提供します。 Opaque LSAsに含まれた情報は直接OSPFか間接的にOSPFドメインに情報を分配したがっている何らかのアプリケーションで使用されるかもしれません。 Opaque LSAsの正確な使用はこのドキュメントの範囲を超えています。
Opaque LSAs consist of a standard LSA header followed by a 32-bit aligned 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ビットの並べられたアプリケーション特有の情報分野があとに続いた標準のLSAヘッダーから成ります。 いかなる他のLSAのようにも、Opaque LSAは、トポロジー中にこの情報をあふれさせるのにリンク州のデータベース分配メカニズムを使用します。 Opaque LSAのリンク州のタイプ分野はLSAの位相的な分配の範囲を特定します。 この範囲は氾濫範囲と呼ばれます。
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を)送って、受け取って、位相的な変化がいつ検出されるかを以前に受信された情報の正当性における変化のアプリケーションに知らせて。
1.1. Organization of This Document
1.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はパケット・フォーマットを与えます。
1.2. Acknowledgments
1.2. 承認
We would like to thank Acee Lindem for his detailed review and useful feedback. The handling of AS-scope Opaque LSAs described in this document is taken from "Validation of OSPF AS-scope opaque LSAs" (April 2006).
彼の詳細なレビューと役に立つフィードバックについてAcee Lindemに感謝申し上げます。 「OSPF AS-範囲の不透明なLSAsの合法化」(2006年4月)から本書では説明されたAS-範囲Opaque LSAsの取り扱いを取ります。
Berger, et al. Standards Track [Page 3] RFC 5250 OSPF Opaque LSA Option July 2008
バーガー、他 標準化過程[3ページ]RFC5250OSPFはオプション2008年7月にLSAについて不透明にします。
2. Conventions Used in This Document
2. 本書では使用されるコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
3. The Opaque LSA
3. 不透明な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 or Not-So-Stubby
Areas (NSSAs), see [NSSA], from the backbone, and 3) not
originated by routers into their connected stub areas or NSSAs.
As with type-5 LSAs, if a type-11 Opaque LSA is received in a stub
area or NSSA from a neighboring router within the stub area or
NSSA, the LSA is rejected.
o リンク州のタイプ-11は、LSAがAutonomous System(AS)中で水につかっているのを指示します。 タイプ-11LSAsの氾濫範囲はAS外部(タイプ-5)のLSAsの氾濫範囲に同等です。 明確に、タイプ-11Opaque LSAsがすべてのトランジット領域中のあふれる、1歳です)、と2は)スタッブ領域かとても短く太いNot Areas(NSSAs)へあふれさせませんでした、と[NSSA]は見ます、背骨から、そして、3が)ルータでそれらの接続スタッブ領域かNSSAsに由来しませんでした。 タイプ-5LSAsのように、スタッブ領域かNSSAにスタッブの領域かNSSAの中の隣接しているルータからタイプ-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 describes Opaque type allocation and assignment.
Opaque LSAのリンク州のIDはOpaqueタイプ分野(最初の8ビット)とタイプ特有のID(残っている24ビット)に分割されます。 Opaque LSAの書式がAppendix A.セクション7で与えられているパケットは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
Opaque LSAの氾濫範囲の適切な取り扱いへの責任は送付者とLSAの受信機の両方に置かれます。 受信機はリンク州のデータベースにいつも有効な容認されたOpaque LSAを格納しなければなりません。 受信機が氾濫範囲に違反するOpaque LSAsを受け入れてはいけない、(例えば、タイプ-11の(ドメイン全体)の不透明なLSA
Berger, et al. Standards Track [Page 4] RFC 5250 OSPF Opaque LSA Option July 2008
バーガー、他 標準化過程[4ページ]RFC5250OSPFはオプション2008年7月にLSAについて不透明にします。
is not accepted in a stub area or NSSA). The flooding scope affects both the synchronization of the link-state database and the flooding procedure.
スタッブ領域かNSSAで受け入れられない、) 氾濫範囲はリンク州のデータベースの同期と氾濫手順の両方に影響します。
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. Those procedures MUST be followed as defined except where modified in this section. The following describes the Opaque LSA's type-specific flooding restrictions.
Opaque LSAsの氾濫はこのセクションの指定されるとしての氾濫範囲の規則に続いて起こらなければなりません。 [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 be discarded and not
acknowledged. An implementation SHOULD keep track of the IP
interface associated with each Opaque LSA having a link-local
flooding scope.
o Opaque LSAが9タイプ-歳(氾濫範囲はリンク地方である)であり、LSAが受け取られたインタフェースが目標インタフェース(例えば、特定の目標隣人に関連しているインタフェース)と同じでないなら、Opaque LSAを捨てて、承認してはいけません。 SHOULDがリンク地方の氾濫範囲を持っている各Opaque LSAに関連しているIPインタフェースの道であることを保つ実現。
o If the Opaque LSA is type-10 (the flooding scope is area-local)
and the area associated with the Opaque LSA (as identified during
origination or from a received LSA's associated OSPF packet
header) is not the same as the area associated with the target
interface, the Opaque LSA MUST be discarded and not acknowledged.
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(創作、または、容認されたLSAの関連OSPFパケットのヘッダーから特定されるように)に関連している領域が目標インタフェースに関連している領域と同じでないなら、Opaque LSAを捨てて、承認してはいけません。 SHOULDが領域の地方の氾濫範囲を持っている各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 or
NSSA, 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 or NSSA MUST be discarded and not acknowledged
(the neighboring router has flooded the LSA in error).
o Opaque LSAが11タイプ-歳(LSAはAS中で水につかっている)であり、目標インタフェースがスタッブ領域かNSSAに関連しているなら、Opaque LSAはインタフェースから水につかっているはずがありません。 インタフェースに受け取られるタイプ-11Opaque LSAは捨てられて、承認されないスタッブ領域かNSSA MUSTと交際しました(隣接しているルータはLSAを間違ってあふれさせました)。
When opaque-capable routers and non-opaque-capable OSPF routers are mixed together in a routing domain, the Opaque LSAs are typically 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] regarding receiving Database Description packets from a
不透明にできるルータが「データベース交換の過程」の始めに隣人の不透明な能力を知っている、(aからDatabase記述パケットを受けることに関して[OSPF]のセクション10.6を見てください。
Berger, et al. Standards Track [Page 5] RFC 5250 OSPF Opaque LSA Option July 2008
バーガー、他 標準化過程[5ページ]RFC5250OSPFはオプション2008年7月にLSAについて不透明にします。
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 SHOULD NOT be set and MUST be ignored when received in packets other than Database Description packets. Using the O-bit in OSPF packets other than Database Description packets will result in interoperability issues. The setting of the O-bit is a "SHOULD NOT" rather than a "MUST NOT" to remain compatible with earlier specifications.
州のExStartの隣人) そして、隣人が不透明にできる、Database記述パケットのOptions分野にO-ビットをはめ込む場合にだけ。 Database記述パケット以外のパケットに受け取ると、O-ビットSHOULD NOTは用意ができて、無視しなければなりません。 Database記述パケット以外のOSPFパケットでO-ビットを使用すると、相互運用性問題はもたらされるでしょう。 O-ビットの設定がaである、「」 以前の仕様と互換性があったままで残る「必須NOT」よりむしろであるべきです。
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]) when the neighbor is opaque capable.
Database Exchangeの過程の次のステップでは、Opaque LSAsは隣人が不透明なものできるとき隣人(以下のセクション3.2と10.3[OSPF]を見る)に送られるDatabase概要リストに含まれています。
When flooding Opaque LSAs to adjacent neighbors, an 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 MUST be placed on the link-state retransmission lists of opaque-capable neighbors and MUST NOT be placed on the link-state retransmission lists of non-opaque-capable neighbors. However, when sending 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] regarding receiving LSAs having unknown LS types).
隣接している隣人へOpaque LSAsをあふれさせるとき、不透明にできるルータは隣人の不透明な能力を見ます。 不透明なLSAsは不透明に有能な隣人へあふれるだけです。 Opaque LSAsは、不透明に有能な隣人のリンク州の「再-トランスミッション」リストに置かなければならなくて、[OSPF]のセクション13.3では、より正確に、なるようにできる非不透明なもの隣人のリンク州の「再-トランスミッション」リストに置かれてはいけません。 しかしながら、マルチキャストとして州UpdateパケットをLinkに送るとき、できる非不透明なもの隣人は(うっかり)Opaque LSAsを受け取るかもしれません。 そして、できる非不透明なものルータは単に、LSA(未知のLSを持っているLSAsを受けることに関する[OSPF]のセクション13がタイプされるのを見る)を捨てるでしょう。
Information contained in received Opaque LSAs SHOULD only be used when the router originating the LSA is reachable. As mentioned in [OSPFv3], reachability validation MAY be done less frequently than every SPF calculation. Additionally, routers processing received Opaque LSAs MAY choose to give priority to processing base OSPF LSA types over Opaque LSA types.
中に含まれた情報はOpaque LSAs SHOULDを受けました。LSAを溯源するルータが届いているときだけ、使用されます。 [OSPFv3]で言及されるように、あらゆるSPF計算より頻繁であるというわけではなく合法化をするかもしれない可到達性です。 さらに、容認されたOpaque LSAsを処理するルータは、Opaque LSAタイプで処理ベースOSPF LSAタイプに優先的に取り扱うのを選ぶかもしれません。
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、出来事: NegotiationDone。(そのNegotiationDoneはDatabase概要リストが組立しているところです)。 Opaque LSAをOSPFに組み込むために、この動作は以下に変わります。
State(s): ExStart
州: ExStart
Event: NegotiationDone
出来事: NegotiationDone
Berger, et al. Standards Track [Page 6] RFC 5250 OSPF Opaque LSA Option July 2008
バーガー、他 標準化過程[6ページ]RFC5250OSPFはオプション2008年7月にLSAについて不透明にします。
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, type-9 Opaque
LSAs, and type-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 MUST be omitted from a virtual
neighbor's Database summary list. AS External LSAs and
type-11 Opaque LSAs MUST be omitted from the Database
summary list if the area has been configured as a stub
area or NSSA (see Section 3.6 of [OSPF]).
動作: ルータは隣人Database概要リストの全体の領域リンク州のデータベースのコンテンツを記載しなければなりません。 領域リンク州のデータベースはRouter LSAsから成ります、Network LSAs、領域構造に含まれたSummary LSAs、タイプ-9Opaque LSAs、およびタイプ-10Opaque LSAs、グローバル構造に含まれたAS Externalとタイプ-11Opaque LSAsと共に。 仮想の隣人のDatabase概要リストからAS Externalとタイプ-11Opaque LSAsを省略しなければなりません。 領域がスタッブ領域かNSSAとして構成されたなら([OSPF]のセクション3.6を見てください)、Database概要リストからAS External LSAsとタイプ-11Opaque LSAsを省略しなければなりません。
Type-9 Opaque LSAs MUST be 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).
隣人に関連しているインタフェースがOpaque LSAに関連しているインタフェース(レセプションに述べられるように)でないならDatabase概要リストからタイプ-9Opaque LSAsを省略しなければなりません。
Any advertisement whose age is equal to MaxAge MUST be
omitted from the Database summary list. It MUST instead
be 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.
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].
Database概要リストから年令がMaxAgeと等しいどんな広告も省略しなければなりません。 代わりに隣人のリンク州の「再-トランスミッション」リストにそれを追加しなければなりません。 Database概要リストの概要をDatabase記述パケットの隣人に送るでしょう。 1Database記述Packetだけがいかなる時も傑出しているのが許容されています。 Database記述パケットの送受信に関するその他の詳細に関しては、[OSPF]のセクション10.6と10.8を見てください。
4. Protocol Data Structures
4. プロトコルデータ構造
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. They 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 interoperate with non-opaque-capable OSPF
routers.
o 能力について不透明にしてください。 ルータがOpaqueオプション(すなわち、Opaque LSAsを格納できる)を走らせているか否かに関係なく、示します。 そのようなルータは、できる非不透明なものOSPFルータで共同利用し続けるでしょう。
Berger, et al. Standards Track [Page 7] RFC 5250 OSPF Opaque LSA Option July 2008
バーガー、他 標準化過程[7ページ]RFC5250OSPFはオプション2008年7月にLSAについて不透明にします。
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 that 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を見てください。
5. Inter-Area Considerations
5. 相互領域問題
As defined above, link-state type-11 Opaque LSAs are flooded throughout the Autonomous System (AS). One issue related to such AS-scoped Opaque LSAs is that there must be a way for OSPF routers in remote areas to check availability of the LSA originator. Specifically, if an OSPF router originates a type-11 LSA and, after that, goes out of service, OSPF routers located outside of the originator's OSPF area have no way of detecting this fact and may use the stale information for a considerable period of time (up to 60 minutes). This could prove to be suboptimal for some applications and may result in others not functioning.
上で定義されるように、リンク州のタイプ-11Opaque LSAsがAutonomous System(AS)中で水につかっています。 そのようなASによって見られたOpaque LSAsに関連する1冊は遠隔地のOSPFルータがLSA創始者の有用性をチェックする方法があるに違いないということです。 明確に、OSPFルータがタイプ-11LSAを溯源して、その後に使われなくなるようになるなら、創始者のOSPF領域の外に位置したOSPFルータは、この事実を検出する方法を全く持たないで、かなりの長期間に渡って(最大60分)聞き古した情報を使用するかもしれません。 これは、いくつかのアプリケーションにおいて準最適であると判明できて、機能ではなく、他のものをもたらすかもしれません。
Type-9 Opaque LSAs and type-10 Opaque LSAs do not have this problem as a receiving router can detect if the advertising router is reachable within the LSA's respective flooding scope. In the case of type-9 LSAs, the originating router must be an OSPF neighbor in Exchange state or greater. In the case of type-10 Opaque LSAs, the intra-area SPF calculation will determine the advertising router's reachability.
受信ルータが、広告ルータがLSAのそれぞれの氾濫範囲の中で届くかどうか検出できるので、タイプ-9Opaque LSAsとタイプ-10Opaque LSAsには、この問題がありません。 タイプ-9LSAsの場合では、由来しているルータはExchange状態か、よりすばらしいところのOSPF隣人であるに違いありません。 タイプ-10Opaque LSAsの場合では、イントラ領域SPF計算は広告ルータの可到達性を決定するでしょう。
There is a parallel issue in OSPF for the AS-scoped AS External LSAs (type-5 LSAs). OSPF addresses this by using AS border information advertised in AS boundary router (ASBR) Summary LSAs (type-4 LSAs); see Section 16.4 of [OSPF]. This same mechanism is reused by this document for type-11 Opaque LSAs.
平行起債がASによって見られたAS External LSAs(タイプ-5LSAs)のためのOSPFにあります。 OSPFはAS境界ルータ(ASBR)概要LSAs(タイプ-4LSAs)の広告に掲載されたAS境界情報を使用することによって、これを記述します。 [OSPF]のセクション16.4を見てください。 この同じメカニズムはタイプ-11Opaque LSAsのためのこのドキュメントによって再利用されます。
To enable OSPF routers in remote areas to check availability of the originator of link-state type-11 Opaque LSAs, the originators advertise themselves as ASBRs. This will enable routers to track the reachability of the LSA originator either directly via the SPF calculation (for routers in the same area) or indirectly via type-4 LSAs originated by ABRs (for routers in other areas). It is
遠隔地のOSPFルータがリンク州のタイプ-11Opaque LSAsの創始者の有用性をチェックするのを可能にするために、創始者はASBRsとして自分を売り込みます。 これは、ルータがSPF計算(同じ領域のルータのための)の近く、または、間接的にABRsによって溯源されたタイプ-4LSAs(他の領域のルータのための)を通してLSA創始者の可到達性を追跡するのを可能にするでしょう。 それはそうです。
Berger, et al. Standards Track [Page 8] RFC 5250 OSPF Opaque LSA Option July 2008
バーガー、他 標準化過程[8ページ]RFC5250OSPFはオプション2008年7月にLSAについて不透明にします。
important to note that per [OSPF], this solution does not apply to OSPF stub areas or NSSAs as AS-scoped Opaque LSAs are not flooded into these area types.
[OSPF]単位でそれに注意するために重要です、ASによって見られたOpaque LSAsがこれらの領域タイプへあふれないとき、この解決策はOSPFスタッブ領域かNSSAsに適用されません。
The procedures related to inter-area Opaque LSAs are as follows:
相互領域Opaque LSAsに関連する手順は以下の通りです:
(1) An OSPF router that is configured to originate AS-scope opaque
LSAs will advertise itself as an ASBR and MUST follow the
requirements related to setting of the Options field E-bit in
OSPF LSA headers as specified in [OSPF].
(1) AS-範囲の不透明なLSAsを溯源するために構成されるOSPFルータは、ASBRとして自分を売り込んで、[OSPF]の指定されるとしてのOSPF LSAヘッダーでOptions分野E-ビットの設定に関連する要件に続かなければなりません。
(2) When processing a received type-11 Opaque LSA, the router MUST
look up the routing table entries (potentially one per attached
area) for the ASBR that originated the LSA. If no entries exist
for the ASBR (i.e., the ASBR is unreachable), the router MUST do
nothing with this LSA. It also MUST discontinue using all Opaque
LSAs injected into the network by the same originator whenever it
is detected that the originator is unreachable.
(2) 容認されたタイプ-11Opaque LSAを処理するとき、ルータはLSAを溯源したASBRのために、経路指定テーブルエントリー(潜在的に付属領域あたり1つ)を見上げなければなりません。 エントリーが全くASBRのために存在していないなら(すなわち、ASBRは手が届きません)、ルータはこのLSAと共に何でもしてはいけません。 また、それは、創始者がすべて、それが検出されるときはいつも、同じ創始者によってネットワークに注がれたOpaque LSAsですが使用するのを中止しなければなりません。手の届かない。
6. Management Considerations
6. 管理問題
The updated OSPF MIB, [RFC4750], provides explicit support for Opaque LSAs and SHOULD be used to support implementations of this document. See Section 12.3 of [RFC4750] for details. In addition to that section, implementations supporting [RFC4750] will also include Opaque LSAs in all appropriate generic LSA objects, e.g., ospfOriginateNewLsas and ospfLsdbTable.
アップデートされたOSPF MIB[RFC4750]はOpaque LSAsとSHOULDの明白なサポートを提供します。使用されて、このドキュメントの実現を支持してください。 詳細に関して[RFC4750]のセクション12.3を見てください。 また、そのセクションに加えて、[RFC4750]を支持する実現が例えばすべての適切な一般的なLSA物にOpaque LSAsを含むでしょう。ospfOriginateNewLsasとospfLsdbTable。
7. Backward Compatibility
7. 後方の互換性
The solution proposed in this document introduces no interoperability issues. In the case that a non-opaque-capable neighbor receives Opaque LSAs, per [OSPF], the non-opaque-capable router will simply discard the LSA.
本書では提案された解決策は相互運用性問題を全く紹介しません。 できる非不透明なもの隣人がOpaque LSAsを受け取って、できる非不透明なものルータは[OSPF]に従って単にLSAを捨てるでしょう。
Note that OSPF routers that implement [RFC2370] will continue using stale type-11 LSAs even when the LSA originator implements the inter-area procedures described in Section 6 of this document.
[RFC2370]を実行するOSPFルータが、LSA創始者がこのドキュメントのセクション6で説明された相互領域手順を実行さえするとき、聞き古したタイプ-11LSAsを使用し続けることに注意してください。
8. Security Considerations
8. セキュリティ問題
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 of a large number of distinct advertisements resulting in database overflow. Note that both of
misconfigurationsと悪意ある攻撃からルーティング・プロトコルを保護するのを検討するとき記述されなければならない2つのタイプの問題があります。 1番目は、ルーティングプロトコル情報の認証と証明です。 2番目は同じルータ通知の反復性の創作かデータベースオーバーフローをもたらす多くの異なった広告の創作から生じるサービス不能攻撃です。 注意、そんなにともに。
Berger, et al. Standards Track [Page 9] RFC 5250 OSPF Opaque LSA Option July 2008
バーガー、他 標準化過程[9ページ]RFC5250OSPFはオプション2008年7月にLSAについて不透明にします。
these concerns exist independently of a router's support for the Opaque option.
これらの関心はルータの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は複数のタイプの認証を支持します。 セグメントをネットワークでつないでいるベースで使用中の認証のタイプを構成できます。 受け身の攻撃に対して安全であり、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を見てください。
Repetitive origination of advertisements is 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 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]).
広告の反復性の創作は頻度におけるどんな特定のLSAの新しい例もそうであることができる限界を強制することによって溯源されて、氾濫手順の間に受け入れられたOSPFによって記述されます。 新しいLSA例が溯源されているのが、セットであるということであるかもしれない頻度は値が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]は優雅に思いがけないデータベースオーバーフローを扱う方法を詳しく述べます。
Berger, et al. Standards Track [Page 10] RFC 5250 OSPF Opaque LSA Option July 2008
バーガー、他 標準化過程[10ページ]RFC5250OSPFはオプション2008年7月にLSAについて不透明にします。
In the case of type-11 Opaque LSAs, this document reuses an ASBR tracking mechanism that is already employed in basic OSPF for type-5 LSAs. Therefore, applying it to type-11 Opaque LSAs does not create any threats that are not already known for type-5 LSAs.
タイプ-11Opaque LSAsの場合では、このドキュメントはタイプ-5LSAsに基本的なOSPFで既に使われるASBR追跡メカニズムを再利用します。 したがって、タイプ-11Opaque LSAsにそれを適用するのはタイプ-5LSAsで既に知られていないどんな脅威も作成しません。
9. IANA Considerations
9. IANA問題
This document updates the requirements for the OSPF Opaque LSA type registry. Three following changes have been made:
このドキュメントはOSPF Opaque LSAタイプ登録のための要件をアップデートします。 3つの次の変更が行われました:
1. References to [RFC2370] have been replaced with references to this
document.
1. [RFC2370]の参照をこのドキュメントの参照に取り替えました。
2. The Opaque type values in the range of 128-255 have been reserved
for "Private Use" as defined in [RFC5226].
2. 128-255の範囲のOpaqueタイプ値は「私用」のために[RFC5226]で定義されるように予約されました。
3. The reference for Opaque type registry value 1, Traffic
Engineering LSA, has been updated to [RFC3630].
3. Opaqueタイプ登録価値1の参照(Traffic Engineering LSA)を[RFC3630]にアップデートしました。
The registry now reads:
登録は現在、読みます:
Open Shortest Path First (OSPF) Opaque Link-State
Advertisements (LSA) Option Types
開いている最短パス最初(OSPF)の不透明なリンク州の広告(LSA)オプションタイプ
Registries included below:
- Opaque Link-State Advertisements (LSA) Option Types
登録は以下に含みました: - 不透明なリンク州の広告(LSA)オプションタイプ
Registry Name: Opaque Link-State Advertisements (LSA) Option Types
Reference: [RFC5250]
Range Registration Procedures Notes
-------- ------------------------------------------ --------
0-127 IETF Consensus
128-255 Private Use
登録名: 不透明なリンク州の広告(LSA)オプションは参照をタイプします: [RFC5250]範囲登録手順注意-------- ------------------------------------------ -------- 0-127 IETFコンセンサス128-255私用
Registry:
Value Opaque Type Reference
------- ------------------------------------------ ---------
1 Traffic Engineering LSA [RFC3630]
2 Sycamore Optical Topology Descriptions [Moy]
3 grace-LSA [RFC3623]
4 Router Information (RI) [RFC4970]
5-127 Unassigned
128-255 Private Use
登録: 不明瞭なタイプ参照を評価してください。------- ------------------------------------------ --------- 1 [Moy]3優雅-LSA[RFC3623]4ルータ情報(ロードアイランド)[RFC4970]5-127が128-255 私用を割り当てなかった交通工学LSA[RFC3630]2アメリカスズカケノキの光のトポロジー記述
Berger, et al. Standards Track [Page 11] RFC 5250 OSPF Opaque LSA Option July 2008
バーガー、他 標準化過程[11ページ]RFC5250OSPFはオプション2008年7月にLSAについて不透明にします。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[DEMD] Moy, J., "Extending OSPF to Support Demand Circuits", RFC
1793, April 1995.
[DEMD] Moy、J.、「要求サーキットを支えるためにOSPFを広げています」、RFC1793、1995年4月。
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPF]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate
requirements levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
[RFC4750] Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed.,
Coltun, R., and F. Baker, "OSPF Version 2 Management
Information Base", RFC 4750, December 2006.
[RFC4750]Joyal、D.(エド)、Galecki、P.(エド)、Giacalone、S.(エド)、Coltun、R.、およびF.ベイカー、「OSPFバージョン2管理情報ベース」、RFC4750(2006年12月)。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5226] Narten、T.、およびH.Alvestrand(「RFCsにIANA問題部に書くためのガイドライン」、BCP26、RFC5226)は2008がそうするかもしれません。
10.2. Informative References
10.2. 有益な参照
[MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March
1994.
[MOSPF] Moy、J.、「OSPFへのマルチキャスト拡大」、RFC1584、1994年3月。
[NSSA] Murphy P., "The OSPF Not-So-Stubby Area (NSSA) Option",
RFC 3101, January 2003.
[NSSA]マーフィーP.、「OSPFしたがって、短く太くない領域(NSSA)オプション」、RFC3101、2003年1月。
[OSPF-MT] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC
4915, June 2007.
[OSPF-MT] Psenak、P.、Mirtorabi、S.、ロイ、A.、Nguyen、L.、およびP.Pillay-Esnault、「OSPFのマルチトポロジー(MT)ルート設定」、RFC4915(2007年6月)。
[OSPFv3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, Ed.,
"OSPF for IPv6", Work in Progress, May 2008.
[OSPFv3] ColtunとR.とファーガソンとD.とMoy、J.とA.Lindem、エド、「IPv6"のためのOSPF、処理中の作業、2008年5月。」
[OVERFLOW] Moy, J., "OSPF Database Overflow", RFC 1765, March 1995.
[オーバーフロー]Moy、J.、「OSPFデータベースオーバーフロー」、RFC1765、1995年3月。
[RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July
1998.
[RFC2370]Coltun、1998年7月のR.、「OSPFの不明瞭なLSAオプション」RFC2370。
[RFC3630] Katz, D., Kompella, K., and D. Yeund, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, September
2003.
[RFC3630] キャッツ、D.、Kompella、K.、およびD.Yeund、「(Te)拡大をOSPFにバージョン2インチ設計する交通、RFC3630、2003年9月。」
[RFC4576] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using a
Link State Advertisement (LSA) Options Bit to Prevent
Looping in BGP/MPLS IP Virtual Private Networks (VPNs)",
RFC 4576, June 2006.
[RFC4576] ローゼン、E.、Psenak、P.、およびP.Pillay-Esnault、「リンク州の広告(LSA)を使用して、オプションにBGP/MPLS IP仮想私設網(VPNs)で輪にするのを防ぐために噛み付きました」、RFC4576、2006年6月。
Berger, et al. Standards Track [Page 12] RFC 5250 OSPF Opaque LSA Option July 2008
バーガー、他 標準化過程[12ページ]RFC5250OSPFはオプション2008年7月にLSAについて不透明にします。
Appendix A. OSPF Data Formats
付録A.OSPFデータ形式
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 flood 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記述パケットで能力を交換するとき、あるいはまた、ルータは、減少している機能性のためにあるリンク州の広告を隣人へあふれさせないのを選ぶことができます。 最後に、リンク州の広告における能力を記載するのに、ルータは、経路指定テーブル計算の部品にそれらを入れないようにすることによって、減少している機能性ルータの周りの交通を進めることができます。
All 8 bits of the OSPF Options field have been assigned, although only the O-bit is described completely by this document. 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.
OSPF Options分野のすべての8ビットを割り当ててあります、O-ビットだけが完全にこのドキュメントによって説明されますが。 各ビットは簡潔に以下で説明されます。 HelloパケットかDatabase記述パケットといつにリンク州の広告を溯源させるかとき、ルータSHOULDはOptions分野に(すなわち、明確)の認識されていないビットをリセットしました。 逆に、容認されたHello Packets、Database記述パケット、またはリンク州の広告SHOULDで認識されていないOptionビットに遭遇するルータが、能力を無視して、通常、パケット/広告を処理します。
+--------------------------------------+
| DN | O | DC | EA | N/P | MC | E | MT |
+--------------------------------------+
+--------------------------------------+ | DN| O| DC| EA| N/P| M.C.| E| MT| +--------------------------------------+
The Options Field
オプション分野
MT-bit
This bit describes the router's multi-topology link-excluding
capability, as described in [OSPF-MT].
MT-ビットThisビットは[OSPF-MT]で説明されるようにルータのマルチトポロジーリンク除外能力について説明します。
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]で説明されるように。
Berger, et al. Standards Track [Page 13] RFC 5250 OSPF Opaque LSA Option July 2008
バーガー、他 標準化過程[13ページ]RFC5250OSPFはオプション2008年7月にLSAについて不透明にします。
MC-bit
This bit describes whether IP multicast datagrams are forwarded
according to the specifications in [MOSPF].
ビットThisビットM.C.は、IPマルチキャストデータグラムが[MOSPF]の仕様通りに進められるかどうか説明します。
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. While defined, the documents
specifying this bit have all expired. The use of this bit may
be deprecated in the future.
EA-ビットThisビットは受信するルータの意欲と前進の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について説明します。
DN-bit
This bit is used to prevent looping in BGP/MPLS IP VPNs, as
specified in [RFC4576].
DN-ビットThisビットは、[RFC4576]で指定されるようにBGP/MPLS IP VPNsで輪にするのを防ぐのに使用されます。
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 OSPF extensibility.
不透明な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には、氾濫の範囲がリンク地方であることができるようにそれに関連づけられた領域の地方(タイプ-10)の氾濫範囲(タイプ-9)か全体のOSPF経路ドメイン(タイプ-11)があります。 このドキュメントのセクション3はOpaque LSAのために氾濫手順について説明します。
Berger, et al. Standards Track [Page 14] RFC 5250 OSPF Opaque LSA Option July 2008
バーガー、他 標準化過程[14ページ]RFC5250OSPFはオプション2008年7月にLSAについて不透明にします。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 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の位相的な分配の範囲を特定します。 この範囲は氾濫範囲と呼ばれます。 以下で、それぞれのリンク状態の氾濫範囲がタイプされるのがわかります。
o A value of 9 denotes a link-local scope. Opaque LSAs with a
link-local scope MUST NOT be flooded beyond the local
(sub)network.
o 9の値はリンク地方の範囲を指示します。 リンク地方の範囲がある不透明なLSAsはローカルの(潜水艦)ネットワークを超えて水につかっているはずがありません。
o A value of 10 denotes an area-local scope. Opaque LSAs with an
area-local scope MUST NOT be flooded beyond their area of
origin.
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 MUST NOT be flooded into stub
areas or NSSAs.
o 11の値は、LSAがAutonomous System(例えば、タイプ-5LSAsと同じ範囲を持っている)中で水につかっているのを指示します。 AS-広範囲がある不透明なLSAsをスタッブ領域かNSSAsへあふれさせてはいけません。
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 of this document for a description of Opaque type
allocation and assignment.
Opaque LSAのリンク州のIDはOpaque Type分野(最初の8ビット)とOpaque ID(残っている24ビット)に分割されます。 Opaqueの記述のためのこのドキュメントのセクション7が配分と課題をタイプするのを見てください。
Berger, et al. Standards Track [Page 15] RFC 5250 OSPF Opaque LSA Option July 2008
バーガー、他 標準化過程[15ページ]RFC5250OSPFはオプション2008年7月にLSAについて不透明にします。
Authors' Addresses
作者のアドレス
Lou Berger LabN Consulting, L.L.C. EMail: lberger@labn.net
ルウバーガーLabN Consulting、L.L.C.はメールされます: lberger@labn.net
Igor Bryskin ADVA Optical Networking Inc 7926 Jones Branch Drive Suite 615 McLean, VA 22102 EMail: ibryskin@advaoptical.com
イーゴリのBryskin ADVAの光学ネットワークInc7926ジョーンズ支店ドライブSuite615マクリーン、ヴァージニア 22102はメールされます: ibryskin@advaoptical.com
Alex Zinin Alcatel-Lucent 750D Chai Chee Rd #06-06 Technopark@ChaiChee Singapore, 469004 EMail: alex.zinin@alcatel-lucent.com
アルカテル透明なアレックス・750DチャイChee#06-06 Technopark@ChaiChee ジニン第シンガポール、469004メール: alex.zinin@alcatel-lucent.com
Rob Coltun Acoustra Productions 3204 Brooklawn Terrace Chevy Chase, MD 20815 USA
ロブColtun Acoustra Productions3204Brooklawn Terrace MD20815チェビー・チェイス(米国)
Berger, et al. Standards Track [Page 16] RFC 5250 OSPF Opaque LSA Option July 2008
バーガー、他 標準化過程[16ページ]RFC5250OSPFはオプション2008年7月にLSAについて不透明にします。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Berger, et al. Standards Track [Page 17]
バーガー、他 標準化過程[17ページ]
一覧
スポンサーリンク
