RFC5185 日本語訳
5185 OSPF Multi-Area Adjacency. S. Mirtorabi, P. Psenak, A. Lindem,Ed., A. Oswal. May 2008. (Format: TXT=18698 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Mirtorabi
Request for Comments: 5185 Nuova Systems
Category: Standards Track P. Psenak
Cisco Systems
A. Lindem, Ed.
A. Oswal
Redback Networks
May 2008
Mirtorabiがコメントのために要求するワーキンググループS.をネットワークでつないでください: 5185年のヌオーヴァシステムカテゴリ: 規格は2008年5月にエドP.PsenakシスコシステムズA.Lindem、A.Oswal20ドル紙幣ネットワークを追跡します。
OSPF Multi-Area Adjacency
OSPFマルチ領域隣接番組
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 describes an extension to the Open Shortest Path First (OSPF) protocol to allow a single physical link to be shared by multiple areas. This is necessary to allow the link to be considered an intra-area link in multiple areas. This would create an intra- area path in each of the corresponding areas sharing the same link.
このドキュメントは、単一の物理的なリンクが複数の領域によって共有されるのを許容するためにオープンShortest Path First(OSPF)プロトコルに拡大について説明します。 これが、リンクが複数の領域のイントラ領域のリンクであると考えられるのを許容するのに必要です。 これは、同じリンクを共有しながら、それぞれの対応する領域でイントラ領域経路を作成するでしょう。
Mirtorabi, et al. Standards Track [Page 1] RFC 5185 OSPF Multi-Area Adjacency May 2008
Mirtorabi、他 隣接番組2008年5月のマルチ領域の標準化過程[1ページ]RFC5185OSPF
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Possible Solutions . . . . . . . . . . . . . . . . . . . . 3
1.3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . 4
1.4. Requirements Notation . . . . . . . . . . . . . . . . . . . 4
2. Functional Specifications . . . . . . . . . . . . . . . . . . . 4
2.1. Multi-Area Adjacency Configuration and Neighbor
Discovery . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Multi-Area Adjacency Packet Transmission . . . . . . . . . 5
2.3. Multi-Area Adjacency Control Packet Reception Changes . . . 5
2.4. Interface Data Structure . . . . . . . . . . . . . . . . . 6
2.5. Interface FSM . . . . . . . . . . . . . . . . . . . . . . . 6
2.6. Neighbor Data Structure and Neighbor FSM . . . . . . . . . 6
2.7. Advertising Multi-Area Adjacencies . . . . . . . . . . . . 6
3. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Adjacency Endpoint Compatibility . . . . . . . . . . . . . 7
4. OSPFv3 Applicability . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . . 8
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 9
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 動機. . . . . . . . . . . . . . . . . . . . . . . . 3 1.2。 可能なソリューション. . . . . . . . . . . . . . . . . . . . 3 1.3。 ソリューション. . . . . . . . . . . . . . . . . . . . . 4 1.4を提案しました。 要件記法. . . . . . . . . . . . . . . . . . . 4 2 機能的な仕様. . . . . . . . . . . . . . . . . . . 4 2.1。 マルチ領域隣接番組構成と隣人発見. . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2。 マルチ領域隣接番組パケット伝送. . . . . . . . . 5 2.3。 マルチ領域隣接番組コントロールパケットレセプションは.52.4を変えます。 データ構造. . . . . . . . . . . . . . . . . 6 2.5を連結してください。 FSM. . . . . . . . . . . . . . . . . . . . . . . 6 2.6を連結してください。 隣人のデータ構造と隣人FSM. . . . . . . . . 6 2.7。 マルチ領域隣接番組. . . . . . . . . . . . 6 3の広告を出します。 互換性. . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1。 隣接番組終点の互換性. . . . . . . . . . . . . 7 4。 OSPFv3の適用性. . . . . . . . . . . . . . . . . . . . . 7 5。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 7 6。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1。 引用規格. . . . . . . . . . . . . . . . . . . 8 6.2。 有益な参照. . . . . . . . . . . . . . . . . . 8付録A.承認. . . . . . . . . . . . . . . . . . . 9
Mirtorabi, et al. Standards Track [Page 2] RFC 5185 OSPF Multi-Area Adjacency May 2008
Mirtorabi、他 隣接番組2008年5月のマルチ領域の標準化過程[2ページ]RFC5185OSPF
1. Introduction
1. 序論
1.1. Motivation
1.1. 動機
It is often a requirement to have an Open Shortest Path First (OSPF) [OSPF] link in multiple areas. This will allow the link to be considered as an intra-area path in each area and be preferred over higher cost links. A simple example of this requirement is to use a high-speed link between two Area Border Routers (ABRs)in multiple areas.
しばしばそれはオープンShortest Path First(OSPF)[OSPF]に複数の領域でリンクさせるという要件です。 これは、リンクが各領域のイントラ領域経路であるとみなされて、より高い費用リンクより好ましいのを許容するでしょう。 この要件の簡単な例は複数の領域で2Area Border Routersの間の高速リンク(ABRs)を使用することです。
Consider the following topology:
以下のトポロジーを考えてください:
R1-------Backbone------R2
| |
Area 1 Area 1
| |
R3--------Area 1--------R4
R1-------背骨------R2| | 1つの領域の地域1| | R3--------領域1--------R4
Multi-Link Topology
マルチリンクトポロジー
The backbone area link between R1 and R2 is a high-speed link, and it is desirable to forward Area 1's traffic between R1 and R2 over that link. In the current OSPF specification [OSPF], intra-area paths are preferred over inter-area paths. As a result, R1 will always route traffic to R4 through Area 1 over the lower speed links. R1 will even use the intra-area Area 1 path though R3 to get to Area 1 networks connected to R2. An OSPF virtual link cannot be used to solve this problem without moving the link between R1 and R2 to Area 1. This is not desirable if the physical link is, in fact, part of the network's backbone topology.
R1とR2との背骨領域のリンクは高速リンクです、そして、R1とR2の間のArea1の交通をそのリンクの上に送るのは望ましいです。 現在のOSPF仕様[OSPF]では、イントラ領域経路は相互領域経路より好まれます。 その結果、R1は下側の速度リンクの上のArea1を通していつも交通をR4に発送するでしょう。 Area1ネットワークを始めるR3はR2に接続しましたが、R1はイントラ領域Area1経路を使用さえするでしょう。 R1とR2とのリンクをArea1に動かさないでこの問題を解決するのにOSPFの仮想のリンクを使用できません。 これは物理的なリンクが事実上ネットワークの背骨トポロジーの一部であるなら望ましくはありません。
The protocol extension described herein will rectify this problem by allowing the link between R1 and R2 to be part of both the backbone area and Area 1.
R1とR2とのリンクが背骨領域とArea1の両方の一部であることを許容することによって、ここに説明されたプロトコル拡大はこの問題を調整するでしょう。
1.2. Possible Solutions
1.2. 可能なソリューション
For numbered interfaces, the OSPF (Open Shortest Path First) specification [OSPF] allows a separate OSPF interface to be configured in each area using a secondary address. The disadvantages of this approach are that it requires additional IP address configuration, it doesn't apply to unnumbered interfaces, and advertising secondary addresses will result in a larger overall routing table.
番号付のインタフェースに関しては、OSPF(開いているShortest Path First)仕様[OSPF]は、別々のOSPFインタフェースが各領域で構成されるのを二次アドレスを使用することで許容します。 このアプローチの損失は追加IPアドレス構成を必要とするということです、そして、それは無数のインタフェースに適用されません、そして、二次アドレスの広告を出すと、より大きい総合的な経路指定テーブルはもたらされるでしょう。
Mirtorabi, et al. Standards Track [Page 3] RFC 5185 OSPF Multi-Area Adjacency May 2008
Mirtorabi、他 隣接番組2008年5月のマルチ領域の標準化過程[3ページ]RFC5185OSPF
Allowing a link with a single address to simply be configured in multiple areas would also solve the problem. However, this would result in the subnet corresponding to the interface residing in multiple areas that is contrary to the definition of an OSPF area as a collection of subnets.
また、ただ一つのアドレスとのリンクが複数の領域で単に構成されるのを許容するのが問題を解決するでしょう。 しかしながら、これはOSPF領域の定義とは逆にサブネットの収集として複数の領域に住んでいるインタフェースに対応するサブネットをもたらすでしょう。
Another approach is to simply allow unnumbered links to be configured in multiple areas. Section 8.2. of the OSPF specification [OSPF] already specifies that the OSPF area ID should be used to de- multiplex received OSPF packets. One limitation of this approach is that multi-access networks are not supported. Although this limitation may be overcome for LAN media with support of "Point-to- Point operation over LAN in link-state routing protocols" [P2PLAN], it may not be acceptable to configure the link as unnumbered due to network management policies. Many popular network management applications individually test the path to each interface by pinging its IP address.
別のアプローチは無数のリンクが複数の領域で構成されるのを単に許容することです。 OSPF仕様[OSPF]のセクション8.2は、OSPF領域IDが反-容認されたOSPFパケットを多重送信するのに使用されるべきであると既に指定します。 このアプローチの1つの制限はマルチアクセスネットワークがサポートされないということです。 この制限はそうですが、「LinkState方式プロトコルのLANの上のポイントからポイントへの操作」[P2PLAN]のサポートがあるLANメディアのために打ち勝ってください、そして、ネットワークマネージメント方針による無数としてリンクを構成するのは許容できる必要はありません。 多くのポピュラーなネットワークマネージメントアプリケーションが、IPアドレスを確認することによって、個別に各インタフェースに経路をテストします。
1.3. Proposed Solution
1.3. 提案されたソリューション
ABRs will simply establish multiple adjacencies belonging to different areas. Each multi-area adjacency is announced as a point- to-point link in the configured area. However, unlike numbered point-to-point links, no type 3 link is advertised for multi-area adjacencies. This point-to-point link will provide a topological path for that area. The first or primary adjacency using the link will operate and advertise the link in a manner consistent with RFC 2328 [OSPF].
ABRsは単に異なった領域に属す複数の隣接番組を確立するでしょう。 それぞれのマルチ領域隣接番組はポイントへのポイントリンクとして構成された領域で発表されます。 しかしながら、番号付のポイントツーポイント接続と異なって、マルチ領域隣接番組のために、3がリンクしないタイプの全く広告を出します。 このポイントツーポイント接続は位相的な経路をその領域に提供するでしょう。 リンクを使用する1番目の、または、第一の隣接番組は、RFC2328[OSPF]と一致した方法でリンクを操作して、広告を出すでしょう。
1.4. Requirements Notation
1.4. 要件記法
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 RFC 2119 [RFC-KEYWORDS].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC-キーワード]で説明されるように本書では解釈されることであるべきですか?
2. Functional Specifications
2. 機能的な仕様
2.1. Multi-Area Adjacency Configuration and Neighbor Discovery
2.1. マルチ領域隣接番組構成と隣人発見
Multi-area adjacencies are configured between two routers having a common interface. On point-to-point interfaces, there is no need to configure the neighbor's address since there can be only one neighbor. For all other network types, the neighbor address of each multi-area adjacency must be configured or automatically discovered via a mechanism external to OSPF.
マルチ領域隣接番組は、一般的なインタフェースを持ちながら、2つのルータの間で構成されます。 二地点間インタフェースには、1人の隣人しかいることができないので隣人のアドレスを構成する必要は全くありません。 他のすべてのネットワークタイプにおいて、それぞれのマルチ領域隣接番組の隣人アドレスを構成されなければならないか、またはOSPFへの外部のメカニズムで自動的に発見しなければなりません。
Mirtorabi, et al. Standards Track [Page 4] RFC 5185 OSPF Multi-Area Adjacency May 2008
Mirtorabi、他 隣接番組2008年5月のマルチ領域の標準化過程[4ページ]RFC5185OSPF
2.2. Multi-Area Adjacency Packet Transmission
2.2. マルチ領域隣接番組パケット伝送
On point-to-point interfaces, OSPF control packets are sent to the AllSPFRouters address. For all other network types, OSPF control packets are unicast to the remote neighbor's IP address.
二地点間インタフェースでは、OSPFコントロールパケットをAllSPFRoutersアドレスに送ります。 他のすべてのネットワークタイプにおいて、OSPFコントロールパケットはリモート隣人のIPアドレスへのユニキャストです。
2.3. Multi-Area Adjacency Control Packet Reception Changes
2.3. マルチ領域隣接番組コントロールパケットレセプション変化
Receiving protocol packets is described in Section 8.2 of [OSPF]. The text starting with the second paragraph and continuing through the third bullet beneath that paragraph is changed as follows:
プロトコルパケットを受けるのは[OSPF]のセクション8.2で説明されます。 以下の通り第2パラグラフから始まって、そのパラグラフの下で3番目の弾丸を通して続くテキストを変えます:
Next, the OSPF packet header is verified. The fields specified in the header must match those configured for the receiving interface. If they do not, the packet should be discarded:
次に、OSPFパケットのヘッダーは確かめられます。 ヘッダーで指定された分野は受信インタフェースに構成されたものに合わなければなりません。 そうしないなら、パケットは捨てられるべきです:
o The version number field must specify protocol version 2.
o バージョンナンバーフィールドはプロトコルバージョン2を指定しなければなりません。
o The Area ID found in the OSPF header must be verified. If all of
the following cases fail, the packet should be discarded. The
Area ID specified in the header must either:
o OSPFヘッダーで見つけられたArea IDについて確かめなければなりません。 以下のケースのすべてが失敗するなら、パケットは捨てられるべきです。 ヘッダーで指定されたArea IDはそうしなければなりません:
1. Match the Area ID of the receiving interface. In this case,
the packet has been sent over a single hop. Therefore, the
packet's IP source address is required to be on the same
network as the receiving interface. This can be verified by
comparing the packet's IP source address to the interface's IP
address, after masking both addresses with the interface mask.
This comparison should not be performed on point-to-point
networks. On point-to-point networks, the interface addresses
of each end of the link are assigned independently, if they
are assigned at all.
1. 受信インタフェースのArea IDを合わせてください。 この場合、単一のホップの上にパケットを送りました。 したがって、パケットのIPソースアドレスが、受信インタフェースと同じネットワークにあるのに必要です。 パケットのIPソースアドレスをインタフェースのIPアドレスにたとえることによって、これについて確かめることができます、インタフェースマスクで両方のアドレスにマスクをかけた後に。 二地点間ネットワークにこの比較を実行するべきではありません。 二地点間ネットワークに、リンクのそれぞれの端のインターフェース・アドレスは独自に配属されます、それらが少しでも割り当てられるなら。
2. Indicate a non-backbone area. In this case, the packet has
been sent over a multi-area adjacency. If the area-id matches
the configured area for a multi-area adjacency, the packet is
accepted and is from now on associated with the multi-area
adjacency for that area.
2. 非背骨領域を示してください。 この場合、マルチ領域隣接番組の上にパケットを送りました。 領域イドがマルチ領域隣接番組のための構成された領域に合っているなら、パケットは、受け入れられて、これから先、その領域のためにマルチ領域隣接番組に関連づけられます。
3. Indicate the backbone. In this case, the packet has been sent
over a virtual link or a multi-area adjacency.
3. 背骨を示してください。 この場合、仮想のリンクかマルチ領域隣接番組の上にパケットを送りました。
o For virtual links, the receiving router must be an ABR, and the
Router ID specified in the packet (the source router) must be the
other end of a configured virtual link. The receiving interface
must also attach to the virtual link's configured transit area.
If all of these checks succeed, the packet is accepted and is from
now on associated with the virtual link.
o 仮想のリンクに関しては、受信ルータはABRであるに違いありません、そして、パケット(ソースルータ)で指定されたRouter IDは構成された仮想のリンクのもう一方の端であるに違いありません。 また、受信インタフェースは仮想のリンクの構成されたトランジット領域に付かなければなりません。 これらのチェックのすべてが成功するなら、パケットは、受け入れられて、これから先、仮想のリンクに関連づけられます。
Mirtorabi, et al. Standards Track [Page 5] RFC 5185 OSPF Multi-Area Adjacency May 2008
Mirtorabi、他 隣接番組2008年5月のマルチ領域の標準化過程[5ページ]RFC5185OSPF
o For multi-area adjacencies, if the area-id matches the configured
area for the multi-area adjacency, the packet is accepted and is
from now on associated with the multi-area adjacency for that
area.
o マルチ領域隣接番組において、領域イドがマルチ領域隣接番組のための構成された領域に合っているなら、パケットは、受け入れられて、これから先、その領域のためにマルチ領域隣接番組に関連づけられます。
o Note that if there is a match for both a virtual link and a multi-
area adjacency then this is a configuration error that should be
handled at the configuration level.
o 仮想のリンクとマルチ領域隣接番組の両方のためのマッチがあればこれが構成レベルで扱われるべきである構成誤りであることに注意してください。
o Packets whose IP destination is AllDRouters should only be
accepted if the state of the receiving interface is DR or Backup
(see Section 9.1 of [OSPF]).
o 受信インタフェースの状態がDRかBackup([OSPF]のセクション9.1を見る)である場合にだけIPの目的地がAllDRoutersであるパケットを受け入れるべきです。
o [...] The remainder of Section 8.2 of [OSPF] is unchanged.
o [...] [OSPF]のセクション8.2の残りは変わりがありません。
2.4. Interface Data Structure
2.4. インタフェースデータ構造
An OSPF interface data structure is built for each configured multi- area adjacency as specified in Section 9 of [OSPF]. The interface type will always be point-to-point.
OSPFインタフェースデータ構造は[OSPF]のセクション9における指定されるとしてのそれぞれの構成されたマルチ領域隣接番組のために築き上げられます。 インターフェース型はいつも二地点間になるでしょう。
2.5. Interface FSM
2.5. インタフェースFSM
The interface Finite State Machine (FSM) will be the same as a point- to-point link irrespective of the underlying physical link.
インタフェースFinite州Machine(FSM)は基本的な物理的なリンクの如何にかかわらずポイントへのポイントリンクと同じになるでしょう。
2.6. Neighbor Data Structure and Neighbor FSM
2.6. 隣人データ構造と隣人FSM
Both the neighbor data structure and neighbor FSM are the same as for standard OSPF, specified in Section 10 of [OSPF].
隣人データ構造と隣人FSMの両方が、同じで標準のOSPFのように、[OSPF]のセクション10で指定されています。
2.7. Advertising Multi-Area Adjacencies
2.7. 広告マルチ領域隣接番組
Multi-area adjacencies are announced as point-to-point links. Once the router's multi-area adjacency reaches the FULL state, it will be added as a link type 1 to the Router Link State Advertisement (LSA) with:
ポイントツーポイントがリンクされるとき、マルチ領域隣接番組は発表されます。 FULLが述べるかつてのルータのマルチ領域の隣接番組範囲、それはリンク型1として以下でRouter Link州Advertisement(LSA)に加えられるでしょう。
Link ID = Remote's Router ID
リンクID=リモートであるのは、Router IDです。
Link Data = Neighbor's IP Address or IfIndex (if the underlying
interface is unnumbered).
リンクDataは隣人のIP AddressかIfIndexと等しいです(基本的なインタフェースが無数であるなら)。
Unlike numbered point-to-point links, no type 3 link is advertised for multi-area adjacencies.
番号付のポイントツーポイント接続と異なって、マルチ領域隣接番組のために、3がリンクしないタイプの全く広告を出します。
Mirtorabi, et al. Standards Track [Page 6] RFC 5185 OSPF Multi-Area Adjacency May 2008
Mirtorabi、他 隣接番組2008年5月のマルチ領域の標準化過程[6ページ]RFC5185OSPF
3. Compatibility
3. 互換性
All mechanisms described in this document are backward compatible with standard OSPF implementations [OSPF].
本書では説明されたすべてのメカニズムが標準のOSPF実現[OSPF]と互換性があった状態で後方です。
3.1. Adjacency Endpoint Compatibility
3.1. 隣接番組終点の互換性
Since multi-area adjacencies are modeled as point-to-point links, it is only necessary for the router at the other end of the adjacency to model the adjacency as a point-to-point link. However, the network topology will be easier to represent and troubleshoot if both neighbors are symmetrically configured as multi-area adjacencies.
ポイントツーポイントがリンクされるときマルチ領域隣接番組がモデル化されるので、隣接番組のもう一方の端のルータがポイントツーポイント接続として単に隣接番組をモデル化するのが必要です。 しかしながら、両方の隣人がマルチ領域隣接番組として対称的に構成されるなら、ネットワーク形態は表して、より障害調査しやすいようになるでしょう。
4. OSPFv3 Applicability
4. OSPFv3の適用性
The mechanisms defined in this document also apply to OSPFv3 [OSPFV3]. As in OSPF, a multi-area adjacency is advertised as a point-to-point link in the advertising router's router-LSA. Since OSPFv3 router-LSA links are independent of addressing semantics and unambiguously identify OSPFv3 neighbors (refer to Section 3.4.3.1 of [OSPFV3]), the change to router-LSA links described in Section 2.7 is not applicable to OSPFv3. Furthermore, no prefixes corresponding to the multi-area adjacency are advertised in the router's intra-area- prefix-LSA.
また、本書では定義されたメカニズムはOSPFv3[OSPFV3]に適用されます。 OSPFのように、ポイントツーポイント接続として広告ルータのルータ-LSAにマルチ領域隣接番組の広告を出します。 セクション3.4を参照してください。OSPFv3ルータ-LSAリンクが以来意味論を記述するのから独立していて、明白にOSPFv3隣人を特定する、(.3 .1[OSPFV3)、セクション2.7で説明されたルータ-LSAリンクへの変化はOSPFv3に適切ではありません。 その上、ルータのイントラ領域接頭語-LSAにマルチ領域隣接番組に対応するどんな接頭語も広告を出しません。
A link-LSA SHOULD NOT be advertised for a multi-area adjacency. The neighbor's IPv6 link local address can be learned in other ways, e.g., it can be extracted from the IPv6 header of Hello packets received over the multi-area adjacency. The neighbor IPv6 link local address is required for the OSPFv3 route next-hop calculation on multi-access networks (refer to Section 3.8.1.1 of [OSPFV3]).
リンク-LSA SHOULD NOT、マルチ領域隣接番組には、広告を出してください。 他の方法で隣人のIPv6リンクローカルアドレスについて学習できます、例えば、マルチ領域隣接番組の上に受け取られたHelloパケットのIPv6ヘッダーからそれを抽出できます。 セクション3.8を参照してください。隣人IPv6リンクローカルアドレスがマルチアクセスネットワークにおけるOSPFv3ルート次のホップ計算に必要である、(.1 .1[OSPFV3。)
5. Security Considerations
5. セキュリティ問題
This document does not raise any security issues that are not already covered in [OSPF] or [OSPFV3].
このドキュメントは[OSPF]か[OSPFV3]で既にカバーされていない少しの安全保障問題も提起しません。
Mirtorabi, et al. Standards Track [Page 7] RFC 5185 OSPF Multi-Area Adjacency May 2008
Mirtorabi、他 隣接番組2008年5月のマルチ領域の標準化過程[7ページ]RFC5185OSPF
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
April 1998.
[OSPF]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
[OSPFV3] Coltun, R., Ferguson, D., and J. Moy, "OSPF for
IPv6", RFC 2740, December 1999.
[OSPFV3] ColtunとR.とファーガソン、D.とJ.Moy、「IPv6"、RFC2740、1999年12月のためのOSPF。」
[RFC-KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
6.2. Informative References
6.2. 有益な参照
[P2PLAN] Shen, N. and A. Zinin, "Point-to-point operation over
LAN in link-state routing protocols", Work
in Progress.
Progressの[P2PLAN]シンとN.とA.ジニン、「LinkState方式プロトコルのLANの上の二地点間操作」、Work。
Mirtorabi, et al. Standards Track [Page 8] RFC 5185 OSPF Multi-Area Adjacency May 2008
Mirtorabi、他 隣接番組2008年5月のマルチ領域の標準化過程[8ページ]RFC5185OSPF
Appendix A. Acknowledgments
付録A.承認
The authors wish to acknowledge Pat Murphy for convincing the OSPF WG to address the requirement.
作者は、要件を記述するようにOSPF WGに納得させるためにパット・マーフィーを承認したがっています。
Thanks to Mitchell Erblich's for his last call review and comments.
おかげに、ミッチェルErblichは彼の最後の呼び出しレビューとコメントのためのものです。
Thanks to Padma Pillay-Esnault for her last call review and comments. Also, thanks to Padma for comments on the OSPFv3 applicability section that was last called separately.
おかげに、彼女のためのPadma Pillay-Esnaultは、最後にレビューとコメントと呼びます。 また、最後であるOSPFv3適用性部のコメントのためのPadmaへの感謝は別々に呼びました。
Thanks to Nischal Seth for pointing out that the document inadvertently precluded point-to-point over LAN interfaces.
ドキュメントがLANインタフェースの上でうっかりポイントツーポイントを排除したとNischalセスに指摘してくださってありがとうございます。
Thanks to Ben Campbell for performing the General Area review.
司令官のAreaを実行するためのベン・キャンベルへの感謝は論評します。
Thanks to Jari Arkko for comments during the IESG review.
おかげに、IESGの間のコメントのためのヤリArkkoは論評します。
The RFC text was produced using Marshall Rose's xml2rfc tool.
RFCテキストは、マーシャル・ローズのxml2rfcツールを使用することで製作されました。
Mirtorabi, et al. Standards Track [Page 9] RFC 5185 OSPF Multi-Area Adjacency May 2008
Mirtorabi、他 隣接番組2008年5月のマルチ領域の標準化過程[9ページ]RFC5185OSPF
Authors' Addresses
作者のアドレス
Sina Mirtorabi Nuova Systems 3 West Plumeria Drive San Jose, CA 95134 USA
西Plumeria DriveシーナMirtorabiヌオーヴァSystems3カリフォルニア95134サンノゼ(米国)
EMail: sina@nuovasystems.com
メール: sina@nuovasystems.com
Peter Psenak Cisco Systems Apollo Business Center Mlynske nivy 43 821 09 Bratislava Slovakia
ピーターPsenakシスコシステムズアポロビジネスセンターMlynske nivy43 821 09ブラティスラバスロバキア
EMail: ppsenak@cisco.com
メール: ppsenak@cisco.com
Acee Lindem (editor) Redback Networks 102 Carric Bend Court Cary, NC 27519 USA
Acee Lindem(エディタ)20ドル紙幣ネットワーク102こづなつなぎ法廷のNC27519ケーリー(米国)
EMail: acee@redback.com
メール: acee@redback.com
Anand Oswal Redback Networks 300 Holger Way San Jose, CA 95134 USA
アナンドOswal Redbackは300オルガーWayでサンノゼ、カリフォルニア95134米国をネットワークでつなぎます。
EMail: aoswal@redback.com
メール: aoswal@redback.com
Mirtorabi, et al. Standards Track [Page 10] RFC 5185 OSPF Multi-Area Adjacency May 2008
Mirtorabi、他 隣接番組2008年5月のマルチ領域の標準化過程[10ページ]RFC5185OSPF
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に情報を記述してください。
Mirtorabi, et al. Standards Track [Page 11]
Mirtorabi、他 標準化過程[11ページ]
一覧
スポンサーリンク
