Internet Engineering Task Force (IETF) D. Papadimitriou
Request for Comments: 5787 Alcatel-Lucent
Category: Experimental March 2010
ISSN: 2070-1721
OSPFv2 Routing Protocols Extensions for
Automatically Switched Optical Network (ASON) Routing
Abstract
抽象
The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON).
ITU-Tは、アーキテクチャと自動交換光ネットワーク（ASON）を操作するための要件を定義しています。
The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies including optical networks such as time division multiplexing (TDM) networks including SONET/SDH and Optical Transport Networks (OTNs), and lambda switching optical networks.
汎用マルチプロトコルラベルスイッチング（GMPLS）プロトコル・スイートは、SONET / SDHと光トランスポートネットワーク（OTNs）を含む時分割多重（TDM）ネットワーク、及びラムダスイッチングなどの光ネットワークを含むネットワーク技術の範囲のための制御プレーンを提供するように設計され光ネットワーク。
The requirements for GMPLS routing to satisfy the requirements of ASON routing, and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON.
GMPLSルーティングのための要件は、ASONルーティングの要件を満たすために、既存のGMPLSルーティングプロトコルの評価は、他の文書で提供されています。この文書では、ASONにルーティングするための要件を満たすためのOSPFv2リンクステートルーティングプロトコルの拡張機能を定義します。
Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations current when those documents were written. Future extensions of revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of RFC 4258.
この作品は、要件にスコープし、それらの文書が書かれた時の評価はRFC 4258およびRFC 4652およびITU-T勧告現在で表現されることに注意してください。 ITU-T勧告が改訂された場合、または新しい要件はRFC 4258の改定に導入されている場合は、この作品の改正の今後の拡張が必要になることがあります。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはインターネット標準化過程仕様ではありません。それは、検査、実験的な実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5787.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5787で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Conventions Used in This Document ..........................5
2. Routing Areas, OSPF Areas, and Protocol Instances ...............5
3. Reachability ....................................................6
3.1. Node IPv4 Local Prefix Sub-TLV .............................6
3.2. Node IPv6 Local Prefix Sub-TLV .............................7
4. Link Attribute ..................................................8
4.1. Local Adaptation ...........................................8
4.2. Bandwidth Accounting .......................................9
5. Routing Information Scope .......................................9
5.1. Terminology and Identification .............................9
5.2. Link Advertisement (Local and Remote TE Router ID
Sub-TLV) ..................................................10
5.3. Reachability Advertisement (Local TE Router ID sub-TLV) ...11
6. Routing Information Dissemination ..............................12
6.1. Import/Export Rules .......................................13
6.2. Discovery and Selection ...................................13
6.2.1. Upward Discovery and Selection .....................13
6.2.2. Downward Discovery and Selection ...................14
6.2.3. Router Information Experimental Capabilities TLV ...16
6.3. Loop Prevention ...........................................16
6.3.1. Associated RA ID ...................................17
6.3.2. Processing .........................................18
6.4. Resiliency ................................................19
6.5. Neighbor Relationship and Routing Adjacency ...............20
6.6. Reconfiguration ...........................................20
7. OSPFv2 Scalability .............................................21
8. Security Considerations ........................................21
9. Experimental Code Points .......................................21
9.1. Sub-TLVs of the Link TLV ..................................22
9.2. Sub-TLVs of the Node Attribute TLV ........................22
9.3. Sub-TLVs of the Router Address TLV ........................23
9.4. TLVs of the Router Information LSA ........................23
10. References ....................................................24
10.1. Normative References .....................................24
10.2. Informative References ...................................25
11. Acknowledgements ..............................................26
Appendix A. ASON Terminology ......................................27
Appendix B. ASON Routing Terminology ..............................28
The Generalized Multiprotocol Label Switching (GMPLS) [RFC3945] protocol suite is designed to provide a control plane for a range of network technologies including optical networks such as time division multiplexing (TDM) networks including SONET/SDH and Optical Transport Networks (OTNs), and lambda switching optical networks.
汎用マルチプロトコルラベルスイッチング（GMPLS）は[RFC3945]プロトコルスイートは、例えばSONET / SDHと光トランスポートネットワーク（OTNs）を含む時分割多重（TDM）ネットワークのような光ネットワークを含むネットワーク技術の範囲のための制御プレーンを提供するように設計されラムダは、光ネットワークを切り替えます。
The ITU-T defines the architecture of the Automatically Switched Optical Network (ASON) in [G.8080].
ITU-Tは、自動的に交換光ネットワーク（ASON）[G.8080]のアーキテクチャを定義します。
[RFC4258] details the routing requirements for the GMPLS suite of routing protocols to support the capabilities and functionality of ASON control planes identified in [G.7715] and in [G.7715.1].
[RFC4258]は[G.7715]および[G.7715.1]において同定ASONの制御プレーンの機能と機能をサポートするルーティングプロトコルのGMPLSスイートのルーティング要件を詳述します。
[RFC4652] evaluates the IETF Link State routing protocols against the requirements identified in [RFC4258]. Section 7.1 of [RFC4652] summarizes the capabilities to be provided by OSPFv2 [RFC2328] in support of ASON routing. This document details the OSPFv2 specifics for ASON routing.
[RFC4652]は[RFC4258]で特定された要件に対してIETFリンクステートルーティングプロトコルを評価します。 [RFC4652]のセクション7.1は、ASONルーティングをサポートするのOSPFv2 [RFC2328]で提供される機能をまとめたものです。この文書では、ASONルーティングのためのOSPFv2詳細を詳しく説明します。
Multi-layer transport networks are constructed from multiple networks of different technologies operating in a client-server relationship. The ASON routing model includes the definition of routing levels that provide scaling and confidentiality benefits. In multi-level routing, domains called routing areas (RAs) are arranged in a hierarchical relationship. Note that as described in [RFC4652] there is no implied relationship between multi-layer transport networks and multi-level routing. The multi-level routing mechanisms described in this document work for both single-layer and multi-layer networks.
マルチレイヤトランスポートネットワークは、クライアント - サーバの関係で動作し、異なる技術の複数のネットワークから構成されています。 ASONルーティングモデルは、スケーリング、機密性の利点を提供し、ルーティングレベルの定義を含んでいます。マルチレベルのルーティングでは、ルーティングエリア（RAS）と呼ばれるドメインは、階層関係に配置されています。 [RFC4652]に記載されているように多層トランスポートネットワークとマルチレベルのルーティングの間に暗黙の関係が存在しないことに留意されたいです。単層および多層両方のネットワークについては、この文書の作業に記載のマルチレベルルーティングメカニズム。
Implementations may support a hierarchical routing topology (multi-level) for multiple transport network layers and/or a hierarchical routing topology for a single transport network layer.
実装は、複数のトランスポートネットワーク層および/または単一のトランスポートネットワーク層のための階層的なルーティングトポロジの階層ルーティングトポロジ（マルチレベル）をサポートすることができます。
This document details the processing of the generic (technology-independent) link attributes that are defined in [RFC3630], [RFC4202], and [RFC4203] and that are extended in this document. As detailed in Section 4.2, technology-specific traffic engineering attributes (and their processing) may be defined in other documents that complement this document.
この文書では、ジェネリックで定義されている（技術に依存しない）リンク属性[RFC3630]、[RFC4202]、および[RFC4203]の処理を詳述しているが、この文書に延びています。セクション4.2、技術固有のトラフィックエンジニアリング属性（およびその加工）に詳述されているように、この文書を補完する他のドキュメントで定義されてもよいです。
Note that this work is scoped to the requirements and evaluation expressed in [RFC4258] and [RFC4652] and the ITU-T Recommendations current when those documents were written. Future extensions of revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of [RFC4258].
この作業は、要求にスコープ、それらの文書が書かれたときに評価する[RFC4258]及び[RFC4652]とITU-T勧告電流で発現されることに留意されたいです。 ITU-T勧告が改訂されている場合や、新たな要件が[RFC4258]の改定に導入されている場合は、この作品の改正の今後の拡張が必要になることがあります。
This document is classified as Experimental. Significant changes to routing protocols are of concern to the stability of the Internet. The extensions described in this document are intended for cautious use in self-contained environments. The objective is to determine whether these extensions are stable and functional, whether there is a demand for implementation and deployment, and whether the extensions have any impact on existing routing protocol deployments.
この文書では、実験的に分類されます。ルーティングプロトコルへの大幅な変更は、インターネットの安定性に懸念されます。この文書で説明する拡張機能は、自己完結型の環境での慎重な使用を目的としています。目的は、これらの拡張機能は、実装および展開のための需要があるか否かを、安定かつ機能的であるかどうかを判定することで、拡張機能は、既存のルーティングプロトコルの展開に影響を持っているかどうか。
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 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
The reader is assumed to be familiar with the terminology and requirements developed in [RFC4258] and the evaluation outcomes detailed in [RFC4652].
読者は用語と[RFC4258]で開発要件と[RFC4652]に詳述された評価結果に精通していると仮定されます。
General ASON terminology is provided in Appendix A. ASON routing terminology is described in Appendix B.
一般ASON用語は、付録A. ASONルーティング用語に設けられているが、付録Bに記載されています
An ASON routing area (RA) represents a partition of the data plane, and its identifier is used within the control plane as the representation of this partition.
ASONルーティングエリア（RA）は、データプレーンのパーティションを表し、その識別子は、このパーティションの表現として制御プレーン内で使用されています。
RAs are arranged in hierarchical levels such that any one RA may contain multiple other RAs, and is wholly contained by a single RA. Thus, an RA may contain smaller RAs inter-connected by links. The limit of the subdivision results in an RA that contains just two sub-networks interconnected by a single link.
RASがいずれRAは、複数の他のRAを含んでいてもよいし、完全に単一RAに含まれるような階層レベルに配置されています。従って、RAは小さいRAのリンクによって相互接続を含んでいてもよいです。単一のリンクによって相互接続されたちょうど2つのサブネットワークを含んRAにおける細分割結果の限界。
An ASON RA can be mapped to an OSPF area, but the hierarchy of ASON RA levels does not map to the hierarchy of OSPF routing areas. Instead, successive hierarchical levels of RAs MUST be represented by separate instances of the protocol. Thus, inter-level routing information exchange (as described in Section 6) involves the export and import of routing information between protocol instances.
ASON RAは、OSPFエリアにマッピングすることができるが、ASON RAレベルの階層は、OSPFルーティング領域の階層にマップされません。代わりに、Rasの連続した階層プロトコルの別々のインスタンスによって表されなければなりません。したがって、レベル間のルーティング情報交換（第6節に記載されているように）プロトコルインスタンス間でルーティング情報のエクスポートおよびインポートを含みます。
An ASON RA may therefore be identified by the combination of its OSPF instance identifier and its OSPF area identifier. With proper and careful network-wide configuration, this can be achieved using just the OSPF area identifier, and this process is RECOMMENDED in this document. These concepts and the subsequent handling of network reconfiguration is discussed in Section 6.
ASON RAは、したがって、そのOSPFインスタンス識別子とそのOSPFエリア識別子の組合せによって識別することができます。適切かつ慎重に、ネットワーク全体の構成では、これはただのOSPFエリアの識別子を使用して達成することができ、そしてこのプロセスは、この文書で推奨されています。これらの概念とネットワーク再構成のその後の取り扱いはセクション6で説明されています。
In order to advertise blocks of reachable address prefixes, a summarization mechanism is introduced that complements the techniques described in [RFC5786].
到達可能アドレスプレフィックスのブロックをアドバタイズするために、集計機構は、[RFC5786]に記載された技術を補完することに導入されます。
This extension takes the form of a network mask (a 32-bit number indicating the range of IP addresses residing on a single IP network/subnet). The set of local addresses is carried in an OSPFv2 TE LSA Node Attribute TLV (a specific sub-TLV is defined per address family, i.e., IPv4 and IPv6, used as network-unique identifiers).
この拡張は、ネットワークマスク（単一IPネットワーク/サブネット上に存在するIPアドレスの範囲を示す32ビット数）の形態をとります。ローカルアドレスのセットは、（特定のサブTLVは、ネットワーク固有の識別子として使用される、アドレス・ファミリー、すなわち、IPv4およびIPv6ごとに定義される）のOSPFv2 TE LSAノード属性TLVで搬送されます。
The proposed solution is to advertise the local address prefixes of a router as new sub-TLVs of the (OSPFv2 TE LSA) Node Attribute top-level TLV. This document defines the following sub-TLVs:
提案されたソリューションは、トップレベルTLV属性（OSPFv2のTE LSA）ノードの新しいサブのTLVとしてルータのローカルアドレスのプレフィックスを通知することです。このドキュメントでは、次のサブTLVを定義します。
- Node IPv4 Local Prefix sub-TLV: Length: variable - Node IPv6 Local Prefix sub-TLV: Length: variable
- ノードのIPv4ローカルプレフィックスサブTLV：長さ：可変 - ノードのIPv6ローカルプレフィックスサブTLV：長さ：可変
The Type field of the Node IPv4 Local Prefix sub-TLV is assigned a value in the range 32768-32777 agreed to by all participants in the experiment. The Value field of this sub-TLV contains one or more local IPv4 prefixes. The Length is measured in bytes and, as defined in [RFC3630], reports the length in bytes of the Value part of the sub-TLV. It is set to 8 x n, where n is the number of local IPv4 prefixes included in the sub-TLV.
ノードのIPv4ローカルプレフィックスサブTLVのタイプフィールドは、32768から32777の範囲の値を割り当てられている実験ではすべての参加者が合意しました。このサブTLVのValueフィールドは1つ以上のローカルのIPv4プレフィックスが含まれています。 [RFC3630]で定義される長さは、バイト単位で測定され、サブTLVの値部分の長さ（バイト単位）を報告します。なお、nはローカルIPv4のプレフィックスの数は、サブTLVに含まれる8×Nに設定されています。
The Node IPv4 Local Prefix sub-TLV has the following format:
ノードのIPv4ローカルプレフィックスのサブTLVの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length (8 x n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Network mask i: A 32-bit number indicating the IPv4 address mask for the ith advertised destination prefix.
ネットワークマスクI：i番目のIPv4アドレスマスクを示す32ビットの数は、宛先プレフィクスをアドバタイズ。
Each <Network mask, IPv4 Address> pair listed as part of this sub-TLV represents a reachable destination prefix hosted by the advertising Router ID.
このサブTLVの一部としてリストされている各<ネットワークマスク、IPv4アドレス>ペアは、広告ルータIDによってホスト到達可能宛先プレフィックスを表します。
The local addresses that can be learned from Opaque TE LSAs (that is, the router address and TE interface addresses) SHOULD NOT be advertised in the node IPv4 Local Prefix sub-TLV.
不透明TEのLSA（すなわち、ルータアドレス及びTEインタフェースアドレスである）から学習することができるローカル・アドレスは、ノードのIPv4ローカルプレフィックスサブTLVでアドバタイズされるべきではありません。
The Type field of the Node IPv6 Local Prefix sub-TLV is assigned a value in the range 32768-32777 agreed to by all participants in the experiment. The Value field of this sub-TLV contains one or more local IPv6 prefixes. IPv6 Prefix representation uses [RFC5340], Section A.4.1.
ノードのIPv6ローカルプレフィックスのサブTLVのTypeフィールドは、範囲32768から32777までの値は、実験のすべての参加者によって合意割り当てられます。このサブTLVのValueフィールドは1つ以上のローカルIPv6プレフィックスが含まれています。 IPv6のプレフィックス表現は、[RFC5340]、セクションA.4.1を使用しています。
The Node IPv6 Local Prefix sub-TLV has the following format:
ノードのIPv6ローカルプレフィックスのサブTLVの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Address Prefix 1 |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Address Prefix n |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length reports the length of the Value part of the sub-TLV in bytes. It is set to the sum over all of the local prefixes included in the sub-TLV of (4 + (number of 32-bit words in the prefix) * 4).
長さはバイト単位で、サブTLVの値部分の長さを報告します。これは、（4 * 4 +（接頭辞の32ビット・ワードの数））のサブTLVに含まれるローカルプレフィックスの全てにわたって合計に設定されています。
The encoding of each prefix potentially using fewer than four 32-bit words is described below.
潜在的により少ない4つの32ビットワードを使用して、各プレフィックスの符号化について説明します。
PrefixLength: Length in bits of the prefix.
PrefixLength：プレフィックスのビットの長さ。
PrefixOptions: 8-bit field describing various capabilities associated with the prefix (see [RFC5340], Section A.4.2).
PrefixOptions：プレフィックスに関連する様々な機能を説明する8ビットのフィールド（[RFC5340]を参照し、セクションA.4.2）。
IPv6 Address Prefix i: The ith IPv6 address prefix in the list. Each prefix is encoded in an even multiple of 32-bit words using the fewest pairs of 32-bit words necessary to include the entire prefix. Thus, each prefix is encoded in either 64 or 128 bits with trailing zero bit padding as necessary.
IPv6アドレスプレフィックスI：リスト内のi番目のIPv6アドレスのプレフィックス。各プレフィックスは、全体のプレフィックスを含める必要は32ビット・ワードの最も少ないペアを使用して32ビット・ワードの偶数倍で符号化されます。したがって、各プレフィックスは、必要に応じてゼロビットパディングを末尾のいずれか64または128ビットで符号化されます。
The local addresses that can be learned from TE LSAs, i.e., router address and TE interface addresses, SHOULD NOT be advertised in the node IPv6 Local Prefix sub-TLV.
TE LSAを、すなわち、ルータアドレス及びTEインタフェースアドレスから学習することができるローカルアドレスは、ノードのIPv6ローカルプレフィックスサブTLVでアドバタイズされるべきではありません。
[RFC4652] provides a map between link attributes and characteristics and their representation in sub-TLVs of the top-level Link TLV of the Opaque TE LSA [RFC3630] and [RFC4203], with the exception of the local adaptation (see below). Advertisement of this information SHOULD be supported on a per-layer basis, i.e., one Opaque TE LSA per switching capability (and per bandwidth granularity, e.g., low-order virtual container and high-order virtual container).
[RFC4652]はリンクの属性と特性と不透明TE LSAローカル適応を除いて、[RFC3630]及び[RFC4203]、（下記参照）の最上位リンクTLVのサブTLVの中のそれらの表現の間のマッピングを提供します。この情報の広告、すなわち、スイッチング能力ごとに不透明TE LSA（および帯域幅粒度ごとに、例えば、低次の仮想コンテナ高次仮想コンテナ）、毎層に基づいてサポートされる必要があります。
Local adaptation is defined as a TE link attribute (i.e., sub-TLV) that describes the cross/inter-layer relationships.
局所的な適応は、クロス/層間の関係を記述するTEリンク属性（すなわち、サブTLV）として定義されます。
The Interface Switching Capability Descriptor (ISCD) TE Attribute [RFC4202] identifies the ability of the TE link to support cross-connection to another link within the same layer, and the ability to use a locally terminated connection that belongs to one layer as a data link for another layer (adaptation capability). However, the information associated with the ability to terminate connections within that layer (referred to as the termination capability) is embedded with the adaptation capability.
インターフェーススイッチング能力記述子（ISCD）TE属性は[RFC4202]は、同一層内の別のリンクへの相互接続をサポートするためにTEリンクの能力、およびデータのような1つの層に属する局所的に終端接続を使用する能力を識別する別の層（適応性）へのリンク。しかし、（終端機能と呼ぶ）が層内の接続を終了させる能力に関連する情報は、適応能力が埋め込まれています。
For instance, a link between two optical cross-connects will contain at least one ISCD attribute describing the lambda switching capable (LSC) switching capability; whereas a link between an optical cross-connect and an IP/MPLS LSR will contain at least two ISCD attributes: one for the description of the LSC termination capability and one for the packet switching capable (PSC) adaptation capability.
例えば、二つの光クロスコネクトとの間のリンクは、少なくとも一つのISCDができる（LSC）のスイッチング能力を切り換えるラムダを記述する属性が含まれます。 LSC終端機能の説明のためのものとすることができる（PSC）適応能力をパケット交換のための1つの光学クロスコネクトおよびIP / MPLS LSRは、少なくとも二つISCD属性を含むことになるとの間のリンクに対し。
In OSPFv2, the Interface Switching Capability Descriptor (ISCD) is a sub-TLV (of type 15) of the top-level Link TLV (of type 2) [RFC4203].
OSPFv2のでは、インターフェーススイッチング能力記述子（ISCD）は、トップレベルの（タイプ15の）サブTLV（タイプ2）リンクTLV [RFC4203]です。
The adaptation and termination capabilities are advertised using two separate ISCD sub-TLVs within the same top-level Link TLV.
適応および終了機能は同じトップレベルリンクTLV内の2つの別個のISCDサブTLVを使用してアドバタイズされます。
Per [RFC4202] and [RFC4203], an interface MAY have more than one ISCD sub-TLV. Hence, the corresponding advertisements should not result in any compatibility issues.
[RFC4202]及び[RFC4203]あたり、インターフェースは、複数のISCDサブTLVがあるかもしれません。したがって、対応する広告は、任意の互換性の問題を生じてはなりません。
Further refinement of the ISCD sub-TLV for multi-layer networks is outside the scope of this document.
マルチレイヤネットワークのISCDサブTLVのさらなる改良は、この文書の範囲外です。
GMPLS routing defines an Interface Switching Capability Descriptor (ISCD) that delivers, among other things, information about the (maximum/minimum) bandwidth per priority that a Label Switched Path (LSP) can make use of. Per [RFC4202] and [RFC4203], one or more ISCD sub-TLVs can be associated with an interface. This information, combined with the Unreserved Bandwidth (sub-TLV defined in [RFC3630], Section 2.5.8), provides the basis for bandwidth accounting.
GMPLSルーティングは、とりわけ、ラベルスイッチパス（LSP）を利用することができ、優先度ごとに（最大値/最小値）帯域幅に関する情報を配信するインタフェーススイッチング能力記述子（ISCD）を定義します。 [RFC4202]及び[RFC4203]、一つ以上のISCDサブTLVのインターフェイスに関連付けることができます。未予約帯域幅（[RFC3630]で定義されたサブTLV、セクション2.5.8）と組み合わせたこの情報は、帯域幅アカウンティングのための基礎を提供します。
In the ASON context, additional information may be included when the representation and information in the other advertised fields are not sufficient for a specific technology (e.g., SDH). The definition of technology-specific information elements is beyond the scope of this document. Some technologies will not require additional information beyond what is already defined in [RFC3630], [RFC4202], and [RFC4203].
他のアドバタイズ分野における表現及び情報は、特定の技術（例えば、SDH）のために十分ではない場合にASONの文脈では、追加情報が含まれていてもよいです。技術固有の情報要素の定義は、この文書の範囲を超えています。いくつかの技術はすでに[RFC3630]、[RFC4202]、および[RFC4203]で定義されているものを超えた追加情報を必要としません。
The definition of short-hand terminology introduced in [RFC4652] is repeated here for clarity.
[RFC4652]で導入され、短手の用語の定義を明確にするためにここで繰り返されます。
- Pi is a physical (bearer/data/transport plane) node.
- Piは、物理的（ベアラ/データ/搬送面）ノードです。
- Li is a logical control plane entity that is associated to a single data plane (abstract) node. Each Li is identified by a unique TE Router ID. The latter is a control plane identifier, defined as the Router Address top-level TLV of the Type 1 TE LSA [RFC3630].
- Liが単一のデータ・プレーン（要約）ノードに関連付けられている論理制御プレーンエンティティです。各リーは、独自のTEルータIDによって識別されます。後者は、タイプ1のTE LSA [RFC3630]のルータアドレスの最上位のTLVとして定義され、制御プレーン識別子です。
Note: The Router Address top-level TLV definition, processing, and usage remain per [RFC3630]. This TLV specifies a stable IP address of the advertising router (Ri) that is always reachable if there is any IP connectivity to it (e.g., via the Data Communication Network). Moreover, each advertising router advertises a unique, reachable IP address for each Pi on behalf of which it makes advertisements.
注：ルータアドレス最上位のTLV定義、処理、および使用は[RFC3630]あたりに残ります。このTLVは、（データ通信ネットワークを経由して、例えば）それへのIP接続がある場合は、常に到達可能である広告ルータ（RI）の安定したIPアドレスを指定します。また、各広告ルータは、それが広告を作るその代わりに、各Piのためのユニークな、到達可能なIPアドレスをアドバタイズします。
- Ri is a logical control plane entity that is associated to a control plane "router". The latter is the source for topology information that it generates and shares with other control plane "routers". The Ri is identified by the (advertising) Router ID (32-bit) [RFC2328].
- Riが制御プレーン「ルータ」に関連付けられている論理制御プレーンエンティティです。後者は、それが生成され、他の制御プレーン「ルータ」と共有するトポロジ情報のソースです。 Riをは、（広告）ルータID（32ビット）[RFC2328]によって識別されます。
The Router ID, which is represented by Ri and which corresponds to the RC-ID [RFC4258], does not enter into the identification of the logical entities representing the data plane resources such as links. The Routing Database (RDB) is associated to the Ri.
Riを表されるとRC-ID [RFC4258]に対応しているルータIDは、そのようなリンクのようなデータプレーンリソースを表す論理エンティティの識別に入りません。ルーティングデータベース（RDB）は、RIに関連しています。
Note: Aside from the Li/Pi mappings, these identifiers are not assumed to be in a particular entity relationship except that the Ri may have multiple Lis in its scope. The relationship between Ri and Li is simple at any moment in time: an Li may be advertised by only one Ri at any time. However, an Ri may advertise a set of one or more Lis. Hence, the OSPFv2 routing protocol must support a single Ri advertising on behalf of more than one Li.
注：脇のLi / PIマッピングから、これらの識別子は、Riは、その範囲内に複数のリスを有していてもよいことを除いて、特定のエンティティの関係にあると仮定されていません。 Rおよびリチウムとの関係は、時間の任意の瞬間に簡単である：Liが任意の時点でのみ1個のR 1によって通知されてもよいです。しかし、Riが一つ以上のリスのセットを広告することがあります。したがって、OSPFv2のルーティングプロトコルは、複数のリチウムの代わりに、単一のRi広告をサポートしている必要があります。
A Router ID (Ri) advertising on behalf multiple TE Router IDs (Lis) creates a 1:N relationship between the Router ID and the TE Router ID. As the link local and link remote (unnumbered) ID association is not unique per node (per Li unicity), the advertisement needs to indicate the remote Lj value and rely on the initial discovery process to retrieve the [Li;Lj] relationship. In brief, as unnumbered links have their ID defined on a per-Li basis, the remote Lj needs to be identified to scope the link remote ID to the local Li. Therefore, the routing protocol MUST be able to disambiguate the advertised TE links so that they can be associated with the correct TE Router ID.
代表複数TEルータID（LIS）上のルータID（RI）広告は、1を作成：NルータIDとTEルータIDとの間の関係。 【; Ljのリチウム]の関係（番号なし）IDの関連付けは、ノードごとに一意でないリンクローカルおよびリモートリンクとしてリチウム（Liの単一性当たり）、広告が遠隔Ljの値を示し、取得するために、最初の発見プロセスに依存する必要があります。簡単に言えば、などアンナンバードリンクは、そのIDごとのリチウム基準で定義されている、リモートLjのスコープにローカルリーへのリンクのリモートIDを識別する必要があります。したがって、ルーティングプロトコルは、彼らが正しいTEルータIDに関連付けることができるようにアドバタイズTEリンクを明確にすることができなければなりません。
For this purpose, a new sub-TLV of the (OSPFv2 TE LSA) top-level Link TLV is introduced that defines the Local and Remote TE Router ID.
この目的のために、（OSPFv2のTE LSA）の新たなサブTLV最上位リンクTLVは、ローカルおよびリモートのTEルータIDを定義するに導入されます。
The Type field of the Local and Remote TE Router ID sub-TLV is assigned a value in the range 32768-32777 agreed to by all participants in the experiment. The Length field takes the value 8. The Value field of this sub-TLV contains 4 octets of the Local TE Router Identifier followed by 4 octets of the Remote TE Router Identifier. The value of the Local and Remote TE Router Identifier SHOULD NOT be set to 0.
ローカルとリモートのTEルータIDサブTLVのTypeフィールドは、範囲32768から32777までの値は、実験のすべての参加者によって合意割り当てられます。 Lengthフィールドは、このサブTLVの値フィールド8の値をとるリモートTEルータ識別子の4つのオクテットに続くローカルTEルータ識別子の4つのオクテットを含んでいます。ローカルとリモートのTEルータ識別子の値が0に設定しないでください。
The format of the Local and Remote TE Router ID sub-TLV is:
ローカルとリモートのTEルータIDサブTLVの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local TE Router Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote TE Router Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This sub-TLV is only required to be included as part of the top-level Link TLV if the Router ID is advertising on behalf of more than one TE Router ID. In any other case, this sub-TLV SHOULD be omitted except if the operator plans to start off with 1 Li and progressively add more Lis (under the same Ri) such as to maintain consistency.
このサブTLVは唯一のルータIDが複数のTEルータIDに代わって宣伝されている場合、トップレベルリンクTLVの一部として含まれるために必要とされます。他の場合には、このサブTLVは、オペレータが1 Liとオフ開始し、徐々にそのような一貫性を維持するように（同じRiを下）よりリスを追加することを計画している場合を除いて省略されるべきです。
Note: The Link ID sub-TLV that identifies the other end of the link (i.e., Router ID of the neighbor for point-to-point links) MUST appear exactly once per Link TLV. This sub-TLV MUST be processed as defined in [RFC3630].
注：リンクのもう一方の端を識別するリンクIDサブTLV（すなわち、ポイントツーポイントリンクのネイバーのルータID）が正確に一度リンクTLV当たり現れなければなりません。 [RFC3630]で定義されるように、このサブTLVが処理されなければなりません。
When the Router ID is advertised on behalf of multiple TE Router IDs (Lis), the routing protocol MUST be able to associate the advertised reachability information with the correct TE Router ID.
ルータIDが複数のTEルータID（LIS）の代わりにアドバタイズされる場合、ルーティングプロトコルは正しいTEルータIDでアドバタイズ到達可能性情報を関連付けることができなければなりません。
For this purpose, a new sub-TLV of the (OSPFv2 TE LSA) top-level Node Attribute TLV is introduced. This TLV associates the local prefixes (see above) to a given TE Router ID.
この目的のため、（OSPFv2のTE LSA）の新たなサブTLVトップレベルノードのTLVが導入された属性。このTLVは、所与のTEルータIDに（上記参照）は、ローカルプレフィックスを関連付けます。
The Type field of the Local TE Router ID sub-TLV is assigned a value in the range 32768-32777 agreed to by all participants in the experiment. The Length field takes the value 4. The Value field of this sub-TLV contains the Local TE Router Identifier [RFC3630] encoded over 4 octets.
ローカルTEルータIDサブTLVのTypeフィールドは、32768から32777は、実験のすべての参加者が合意した範囲内の値が割り当てられます。 Lengthフィールドは、このサブTLVの値フィールド4.値が4つのオクテット上に符号化されたローカルTEルータ識別子[RFC3630]を含まとります。
The format of the Local TE Router ID sub-TLV is:
ローカルTEルータIDサブTLVの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local TE Router Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This sub-TLV is only required to be included as part of the Node Attribute TLV if the Router ID is advertising on behalf of more than one TE Router ID. In any other case, this sub-TLV SHOULD be omitted.
このサブTLVは唯一のルータIDが複数のTEルータIDに代わって宣伝されている場合ノード属性TLVの一部として含まれるために必要とされます。他の場合には、このサブTLVを省略するべきです。
An ASON routing area (RA) represents a partition of the data plane, and its identifier is used within the control plane as the representation of this partition. An RA may contain smaller RAs inter-connected by links. The limit of the subdivision results is an RA that contains two sub-networks interconnected by a single link. ASON RA levels do not reflect routing protocol levels (such as OSPF areas).
ASONルーティングエリア（RA）は、データプレーンのパーティションを表し、その識別子は、このパーティションの表現として制御プレーン内で使用されています。 RAは小さいRAのリンクによって相互接続されているが含まれていてもよいです。細分結果の限界は、単一のリンクによって相互接続された2つのサブネットワークを含んRAです。 ASON RAレベルは、（例えば、OSPFエリアのような）ルーティングプロトコルレベルを反映していません。
Successive hierarchical levels of RAs can be represented by separate instances of the protocol.
Rasの連続した階層プロトコルの別のインスタンスで表すことができます。
Routing controllers (RCs) supporting RAs disseminate information downward and upward in this hierarchy. The vertical routing information dissemination mechanisms described in this section do not introduce or imply a new OSPF routing area hierarchy. RCs supporting RAs at multiple levels are structured as separate OSPF instances with routing information exchanges between levels described by import and export rules operating between OSPF instances.
ルーティングコントローラは、（RCS）支持RAはこの階層に下方と上方情報を広めます。このセクションで説明する垂直ルーティング情報発信の仕組みは導入したり、新しいOSPFルーティングエリア階層を意味するものではありません。複数のレベルでのRAを支持するのRCは、OSPFインスタンス間で動作インポートおよびエクスポート規則によって記述レベルとの間の情報交換をルーティングと別個OSPFインスタンスとして構成されています。
The implication is that an RC that performs import/export of routing information as described in this document does not implement an Area Border Router (ABR) functionality.
含意は、この文書に記載されているように、ルーティング情報のインポート/エクスポートを行うRCは、エリア境界ルータ（ABR）の機能を実装していないことです。
RCs supporting RAs disseminate information upward and downward in the hierarchy by importing/exporting routing information as Opaque TE LSAs (Opaque Type 1) of LS Type 10. The information that MAY be exchanged between adjacent levels includes the Router Address, Link, and Node Attribute top-level TLVs.
RAを支持RCSは隣接するレベルの間で交換される情報は、ルータのアドレス、リンクが含まれており、ノード属性LSタイプ10の不透明TEのLSA（不透明タイプ1）のように、ルーティング情報をエクスポート/インポートすることによって、上下階層の情報を広めますトップレベルのTLV。
The Opaque TE LSA import/export rules are governed as follows:
次のように不透明TE LSAのインポート/エクスポートのルールが支配されています。
- If the export target interface is associated with the same RA as is associated with the import interface, the Opaque LSA MUST NOT be imported.
- 輸出ターゲット・インタフェースがインポートインターフェイスに関連付けられているのと同じRAに関連付けられている場合、不透明LSAをインポートしてはなりません。
- If a match is found between the advertising Router ID in the header of the received Opaque TE LSA and one of the Router IDs belonging to the RA of the export target interface, the Opaque LSA MUST NOT be imported.
- 一致が受信不透明TE LSAのヘッダ内の広告ルータIDと輸出ターゲットインタフェースのRAに属するルータのIDのうちの1つとの間に発見された場合、オペークLSAをインポートしてはいけません。
- If these two conditions are not met, the Opaque TE LSA MAY be imported according to local policy. If imported, the LSA MAY be disseminated according to local policy. If disseminated, the normal OSPF flooding rules MUST be followed and the advertising Router ID MUST be set to the importing router's Router ID.
- これらの2つの条件が満たされていない場合は、不透明TE LSAは、ローカルポリシーに従ってインポートされる場合があります。インポートした場合、LSAは、ローカルポリシーに基づいて配布されるかもしれません。普及した場合、通常のOSPFフラッディングのルールに従わなければならないと広告ルータIDは、インポートルータのルータIDを設定しなければなりません。
The imported/exported routing information content MAY be transformed, e.g., filtered or aggregated, as long as the resulting routing information is consistent. In particular, when more than one RC is bound to adjacent levels and both are allowed to import/export routing information, it is expected that these transformations are performed in a consistent manner. Definition of these policy-based mechanisms is outside the scope of this document.
インポート/エクスポートされたルーティング情報の内容であれば、得られたルーティング情報が一致しているように、例えば、形質転換された濾過または集計されるかもしれません。具体的には、複数のRCは、隣接するレベルに結合され、両方が/エクスポートルーティング情報をインポートするために許可されている場合には、これらの変換は、一貫した方法で実行されることが期待されます。これらのポリシーベースのメカニズムの定義は、この文書の範囲外です。
In practice, and in order to avoid scalability and processing overhead, routing information imported/exported downward/upward in the hierarchy is expected to include reachability information (see Section 3) and, upon strict policy control, link topology information.
実際に、およびスケーラビリティと処理オーバーヘッドを回避するために、階層内の下方/上方エクスポート/インポートルーティング情報は、到達可能性情報を含むと予想（セクション3を参照）と、厳密なポリシー制御、リンクトポロジ情報に基づいています。
In order to discover RCs that are capable of disseminating routing information up the routing hierarchy, the following capability descriptor bit is set in the OSPF Router Information Experimental Capabilities TLV (see Section 6.2.3) carried in the Router Information LSA ([RFC4970]).
ルーティング階層のルーティング情報を発信することが可能なレンジングコードを発見するために、以下の能力の記述ビットはルータ情報LSA（[RFC4970]）で運ば（セクション6.2.3を参照）OSPFルータ情報実験能力TLVに設定されています。
- U bit: When set, this flag indicates that the RC is capable of disseminating routing information upward to the adjacent level.
- Uビット：セットは、このフラグはRCが隣接するレベルまで上昇ルーティング情報を広めることが可能であることを示す場合。
In the case that multiple RCs are advertised from the same RA with their U bit set, the RC with the highest Router ID, among those RCs with the U bit set, SHOULD be selected as the RC for upward dissemination of routing information. The other RCs MUST NOT participate in the upward dissemination of routing information as long as the Opaque LSA information corresponding to the highest Router ID RC does not reach MaxAge. This mechanism prevents more than one RC advertising routing information upward in the routing hierarchy from the same RA.
複数のRCは、そのUと同じRAからアドバタイズされる場合にビットセット、Uを有するもののRCビットセットのうち最高のルータIDを持つRCは、ルーティング情報の上向きの普及のためにRCとして選択されるべきです。他のRCSはMaxAgeのに到達していない最高のルータID RCに対応する不透明LSA情報限り、ルーティング情報の上向きの普及に参加してはなりません。このメカニズムは同じRAからのルーティング階層に上向きのルーティング情報を、複数のRC広告を防ぎます。
Note that if the information to allow the selection of the RC that will be used to disseminate routing information up the hierarchy from a specific RA cannot be discovered automatically, it MUST be manually configured.
情報を自動的に発見することができない特定のRAから階層を情報をルーティング広めるために使用されるRCの選択を可能にした場合、それは手動で設定する必要があることに注意してください。
Once an RC has been selected, it remains unmodified even if an RC with a higher Router ID is introduced and advertises its capability to disseminate routing information upward the adjacent level (i.e., U bit set). This hysteresis mechanism prevents from disturbing the upward routing information dissemination process in case, e.g., of flapping.
RCが選択されたら、それはより高いルータIDとRCが導入されて上方に隣接するレベル（すなわち、Uビットセット）ルーティング情報を発信する能力をアドバタイズされた場合でも。未修飾のままこのヒステリシス機構は、ケースに、例えば、羽ばたきの上方ルーティング情報配布プロセスを妨害することを防止します。
The same discovery mechanism is used for selecting the RC responsible for dissemination of routing information downward in the hierarchy. However, an additional restriction MUST be applied such that the RC selection process takes into account that an upper level may be adjacent to one or more lower (RA) levels. For this purpose, a specific TLV indexing the (lower) RA ID to which the RCs are capable of disseminating routing information is needed.
同じ検出メカニズムは、階層内の下方へのルーティング情報の普及のための責任RCを選択するために使用されます。しかし、追加の制限は、RCの選択プロセスは、上位は、1つまたは複数の（RA）レベル下に隣接していてもよいことを考慮に入れるように適用されなければなりません。この目的のために、特定のTLVインデクシング（低級）RA IDは、RCSは必要とされているルーティング情報を発信することが可能であることができます。
The Downstream Associated RA ID TLV is carried in the OSPF Router Information LSA [RFC4970]. The Type field of the Downstream Associated RA ID TLV is assigned a value in the range 32768-32777 agreed to by all participants in the experiment. The Length of this TLV is n x 4 octets. The Value field of this sub-TLV contains the list of Associated RA IDs. Each Associated RA ID value is encoded following the OSPF area ID (32 bits) encoding rules defined in [RFC2328].
ダウンストリーム関連RA ID TLVは、OSPFルータ情報LSA [RFC4970]で運ばれます。ダウンストリーム関連RA ID TLVのTypeフィールドは、範囲32768から32777までの値は、実験のすべての参加者によって合意割り当てられます。このTLVの長さが4つのオクテットのn Xです。このサブTLVの値フィールドは、関連するRA IDのリストが含まれています。各関連RA ID値は[RFC2328]で定義されたOSPFエリアID（32ビット）の符号化規則に従って符号化されます。
The format of the Downstream Associated RA ID TLV is:
ダウンストリーム関連RA ID TLVの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length (4 x n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated RA ID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated RA ID n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
To discover RCs that are capable of disseminating routing information downward through the routing hierarchy, the following capability descriptor bit is set in the OSPF Router Information Experimental Capabilities TLV (see Section 6.2.3) carried in the Router Information LSA ([RFC4970]).
ルーティング階層を通って下方にルーティング情報を発信することが可能なレンジングコードを検出するには、以下の能力の記述ビットはルータ情報LSAで運ばOSPFルータ情報実験機能TLV（セクション6.2.3を参照）（[RFC4970]）に設定されています。
Note that the Downstream Associated RA ID TLV MUST be present when the D bit is set.
Dビットが設定されているときに下流関連RA ID TLVが存在しなければならないことに注意してください。
- D bit: when set, this flag indicates that the RC is capable of disseminating routing information downward to the adjacent levels.
- Dビット：設定した場合、このフラグはRCが隣接するレベルまで下方ルーティング情報を広めることが可能であることを示しています。
If multiple RCs are advertised for the same Associated RA ID, the RC with the highest Router ID, among the RCs with the D bit set, MUST be selected as the RC for downward dissemination of routing information. The other RCs for the same Associated RA ID MUST NOT participate in the downward dissemination of routing information as long as the Opaque LSA information corresponding to the highest Router ID RC does not reach MaxAge. This mechanism prevents more than one RC from advertising routing information downward through the routing hierarchy.
複数のRCは同じ関連RA IDをアドバタイズしている場合、Dビットが設定されたレンジングコードのうち最も高いルータIDとRCは、ルーティング情報の下方への普及のためにRCとして選択されなければなりません。同じ関連RA IDの他のRCSはMaxAgeのに到達していない最高のルータID RCに対応する不透明LSA情報限り、ルーティング情報の下方への普及に参加してはなりません。このメカニズムは、ルーティング階層を下方ルーティング情報を広告から複数のRCを防止します。
Note that if the information to allow the selection of the RC that will be used to disseminate routing information down the hierarchy to a specific RA cannot be discovered automatically, it MUST be manually configured.
情報を自動的に検出することができない特定のRAに階層ダウンルーティング情報を発信するために使用されるRCの選択を可能にする場合、それは手動で設定しなければならないことに留意されたいです。
The OSPF Router information Opaque LSA (Opaque type of 4, Opaque ID of 0) and its content, in particular the Router Informational Capabilities TLV [RFC4970] and TE Node Capability Descriptor TLV [RFC5073], MUST NOT be re-originated.
ルータ情報の能力TLV [RFC4970]とTEノード機能記述子TLV [RFC5073]は、再発信してはいけません、特にOSPFルータ情報オペークLSA（4の不透明タイプ、0の不透明ID）とその内容、。
A new TLV is defined for inclusion in the Router Information LSA to carry experimental capabilities because the assignment policy for bits in the Router Informational Capabilities TLV is "Standards Action" [RFC5226] prohibiting its use from Experimental documents.
新しいTLVは、ルータ情報の能力TLVのビットの割り当てポリシーは、実験的文書から、その使用を禁止する「標準化アクション」[RFC5226]であるため、実験的な機能を実行するルータ情報LSAに含めるために定義されています。
The format of the Router Information Experimental Capabilities TLV is as follows:
次のようにルータ情報実験的機能TLVの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Experimental Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type A value in the range 32768-32777 agreed to by all participants in the experiment.
範囲32768から32777までの値を入力し、実験のすべての参加者が合意しました。
Length A 16-bit field that indicates the length of the value portion in octets and will be a multiple of 4 octets dependent on the number of capabilities advertised. Initially, the length will be 4, denoting 4 octets of informational capability bits.
長さオクテットの値部分の長さを示し、アドバタイズ機能の数に依存する4つのオクテットの倍数であろう16ビットのフィールド。最初は、長さは情報の能力ビットの4つのオクテットを表す、4になります。
Value A variable-length sequence of capability bits rounded to a multiple of 4 octets padded with undefined bits.
値は4つのオクテットの倍数に丸め能力ビットの可変長配列は未定義ビットで埋め。
The following experimental capability bits are assigned:
以下の実験的機能ビットが割り当てられています。
Bit Capabilities
ビット機能
0 The U bit (see Section 6.2.1) 1 The D bit (see Section 6.2.2)
0 UビットDのビット1（セクション6.2.1を参照）（セクション6.2.2を参照）
When more than one RC is bound to an adjacent level of the hierarchy, and is configured or selected to redistribute routing information upward and downward, a specific mechanism is required to avoid looping of routing information. Looping is the re-introduction of routing information that has been advertised from the upper level back to the upper level. This specific case occurs, for example, when the RC advertising routing information downward in the hierarchy is not the same one that advertises routing upward in the hierarchy.
複数のRCは、階層の隣接するレベルに結合され、上下ルーティング情報を再配布するように構成された、または選択された場合、特定の機構は、ルーティング情報のループを回避するために必要とされます。ループバック上位に上位からアドバタイズされたルーティング情報の再導入です。この特定の場合には、階層内の下方ルーティング情報RCの広告は、階層に上方ルーティングアドバタイズ同じものでない場合、例えば、発生します。
When these conditions are met, it is necessary to have a means by which an RC receiving an Opaque TE LSA imported/exported downward by an RC associated to the same RA does not import/export the content of this LSA back upward into the (same) upper level.
これらの条件が満たされたとき、不透明TE LSAを受信したRCが同じRAに関連するRCによって下方にエクスポート/インポートする手段を有することが必要である（同様に背面上方エクスポート/このLSAのコンテンツをインポートしません）上位。
Note that configuration and operational simplification can be obtained when both functionalities are configured on a single RC (per pair of adjacent levels) fulfilling both roles. Figure 1 provides an example where such simplification applies.
両方の機能が単一のRCに構成されている場合、その構成及び動作簡略化の両方の役割を果たし（隣接するレベルのペアごと）を得ることができます。図1は、このような単純化が適用される例を提供します。
....................................................
. .
. RC_5 ------------ RC_6 .
. | | .
. | | RA_Y .
Upper . ********* ********* .
Layer ............* RC_1a *.........* RC_2a *.............
__________________* | *_________* | *__________________
............* RC_1b *... ...* RC 2b *.............
Lower . ********* . . ********* .
Layer . | . . | .
. RA_Z | . . | RA_X .
. RC_3 . . RC_4 .
. . . .
........................ .........................
Figure 1. Hierarchical Environment (Example)
図1階層環境（例）
In this case, the procedure described in this section MAY be omitted, as long as these conditions are permanently guaranteed. In all other cases, without exception, the procedure described in this section MUST be applied.
この場合には、この項で説明する手順であれば、これらの条件が永久的に保証されているように省略してもよいです。他のすべての場合において、例外なく、このセクションに記載された手順を適用しなければなりません。
We need some way of filtering the downward/upward re-originated Opaque TE LSA. Per [RFC5250], the information contained in Opaque LSAs may be used directly by OSPF. By adding the RA ID associated with the incoming routing information, the loop prevention problem can be solved.
私たちは、上向き/下向き再発不透明TE LSAをフィルタリングするいくつかの方法が必要です。 [RFC5250]あたり、不透明LSAに含まれる情報は、OSPFによって直接使用することができます。着信ルーティング情報に関連付けられたRA IDを追加することにより、ループの防止の問題を解決することができます。
This additional information, referred to as the Associated RA ID, MAY be carried in Opaque LSAs that include any of the following top-level TLVs:
関連RA IDと呼ばれるこの追加情報は、次の最上位のTLVのいずれかを含む不透明LSAで実施することができます。
- Router Address top-level TLV - Link top-level TLV - Node Attribute top-level TLV
- ルータアドレス、トップレベルTLV - リンクトップレベルTLV - ノードのトップレベルTLV属性
The Associated RA ID reflects the identifier of the area from which the routing information is received. For example, for a multi-level hierarchy, this identifier does not reflect the originating RA ID; it will reflect the RA from which the routing information is imported.
関連RA IDは、ルーティング情報が受信されたエリアの識別子を反映しています。例えば、マルチレベル階層のため、この識別子は、発信RAのIDを反映していません。それは、ルーティング情報がインポートされてからRAを反映します。
The Type field of the Associated RA ID sub-TLV is assigned a value in the range 32768-32777 agreed to by all participants in the experiment. The same value MUST be used for the Type regardless of which TLV the sub-TLV appears in.
関連RA IDサブTLVのTypeフィールドは、範囲32768から32777までの値を割り当てられている実験ではすべての参加者が合意しました。同じ値にかかわらず、TLVのサブTLVはで表示されるタイプのために使用されなければなりません。
The Length of the Associated RA ID TLV is 4 octets. The Value field of this sub-TLV contains the Associated RA ID. The Associated RA ID value is encoded following the OSPF area ID (32 bits) encoding rules defined in [RFC2328].
関連RA ID TLVの長さは4つのオクテットです。このサブTLVの値フィールドは、関連するRA IDが含まれています。関連RA ID値がOSPFエリアID（32ビット）[RFC2328]で定義された符号化規則に従って符号化されます。
The format of the Associated RA ID TLV is defined as follows:
次のように関連するRA ID TLVのフォーマットが定義されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated RA ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When fulfilling the rules detailed in Section 6.1, a given Opaque LSA is imported/exported downward or upward the routing hierarchy, and the Associated RA ID TLV is added to the received Opaque LSA list of TLVs such as to identify the area from which this routing information has been received.
セクション6.1で詳細な規則を満たす場合に、所定のオペークLSAは、ルーティング階層下方又は上方エクスポート/インポートされ、そして関連するRA ID TLVは、このルーティングれる領域を識別するためのTLVの受信されたオペークLSAのリストに追加されます情報が受信されています。
When the RC adjacent to the lower or upper routing level receives this Opaque LSA, the following rule is applied (in addition to the rule governing the import/export of Opaque LSAs as detailed in Section 6.1).
下部又は上部ルーティングレベルに隣接RCこのオペークLSAを受信した場合（6.1節に詳述したように不透明LSAのインポート/エクスポートを支配するルールに加えて）、次の規則が適用されます。
- If a match is found between the Associated RA ID of the received Opaque TE LSA and the RA ID belonging to the area of the export target interface, the Opaque TE LSA MUST NOT be imported.
- 試合を受信不透明TE LSAの関連RA IDと輸出ターゲット・インタフェースのエリアに属するRAのIDとの間で発見された場合、不透明TE LSAをインポートしてはなりません。
- Otherwise, this Opaque LSA MAY be imported and disseminated downward or upward the routing hierarchy following the OSPF flooding rules.
- それ以外の場合、このオペークLSAは、インポートされてもよく、OSPFフラッディング規則以下下向き又は上向きのルーティング階層播種します。
This mechanism ensures that no race condition occurs when the conditions depicted in Figure 2 are met.
この機構は、図2に示された条件が満たされたとき全く競合状態が発生しないことを確実にします。
RC_5 ------------- RC_6
| |
| | RA_Y
Upper ********* *********
Layer ............* RC_1a *.........* RC_2a *.............
__________________* | *_________* | *__________________
............* RC_1b *.........* RC_2b *.............
Lower ********* *********
Layer | |
| | RA_X
RC_3 --- . . . --- RC_4
Figure 2. Race Condition Prevention (Example)
図2.競合状態防止（例）
Assume that RC_1b is configured for exporting routing information upward toward RA_Y (upward the routing hierarchy) and that RC_2a is configured for exporting routing information toward RA_X (downward the routing hierarchy).
RC_1bはRA_Y（上方ルーティング階層）に向かって上方にルーティング情報をエクスポートするために構成されており、そのRC_2aがRA_X（下方ルーティング階層）に向かってルーティング情報をエクスポートするように構成されていると仮定する。
Assume that routing information advertised by RC_3 would reach RC_4 faster across RA_Y through hierarchy.
RC_3によってアドバタイズルーティング情報は階層をRA_Y渡って速くRC_4に達するだろうと想定しています。
If RC_2b is not able to prevent from importing that information, RC_4 may receive that information before the same advertisement would propagate in RA_X (from RC_3) to RC_4. For this purpose, RC_1a inserts the Associated RA X to the imported routing information from RA_X. Because RC_2b finds a match between the Associated RA ID (X) of the received Opaque TE LSA and the ID (X) of the RA of the export target interface, this LSA MUST NOT be imported.
RC_2bは、その情報をインポートすることを防ぐことができない場合は、RC_4は同じ広告がRC_4へ（RC_3から）RA_Xに伝搬する前に、その情報を受け取ることができます。この目的のために、RC_1aはRA_Xからインポートされたルーティング情報に関連付けRA Xを挿入します。 RC_2b輸出ターゲット・インタフェースのRAの受信不透明TE LSAの関連RA ID（X）及びID（X）との間の一致を検出するので、このLSAをインポートしてはいけません。
OSPF creates adjacencies between neighboring routers for the purpose of exchanging routing information. After a neighbor has been discovered, bidirectional communication is ensured, and a routing adjacency is formed between RCs, loss of communication may result in partitioned OSPF areas and so in partitioned RAs.
OSPFルーティング情報を交換するために、隣接ルータとの間の隣接関係を作成します。隣人が発見された後、双方向通信が確保され、ルーティング隣接関係がレンジングコードとの間に形成され、通信の損失を分配OSPFエリアに等分割さのRAをもたらすことができます。
Consider for instance (see Figure 2) the case where RC_1a and RC_1b are configured for exchanging routing information downward and upward RA_Y, respectively, and that RC_2a and RC_2b are not configured for exchanging any routing information toward RA_X. If the communication between RC_1a and RC_2a is broken (due, e.g., to RC_5 - RC_6 communication failure), RA_Y could be partitioned.
例えば（図2参照）RC_1aとRC_1bは、それぞれ、下方ルーティング情報を交換し、上方RA_Yするように構成されている場合について考えると、RC_2aとRC_2bはRA_Xに向かって任意のルーティング情報を交換するために構成されていないこと。 RC_1aとRC_2a間の通信が切断された場合（これは、例えば、RC_5に - RC_6通信障害）、RA_Yを分配することができます。
In these conditions, it is RECOMMENDED that RC_2a be re-configurable such as to allow for exchanging routing information downward to RA_X. This reconfiguration MAY be performed manually or automatically. In the latter cases, automatic reconfiguration uses the mechanism described in Section 6.2 (forcing MaxAge of the corresponding opaque LSA information in case the originating RC becomes unreachable). Manual reconfiguration MUST be supported.
これらの条件では、RC_2aようなRA_Xに下方ルーティング情報の交換を可能にするように再構成することが推奨されます。この再構成は、手動または自動で行うこともできます。後者の場合には、自動再構成は、（場合にRCが到達不能になった発信に対応する不透明LSA情報のMaxAgeのを強制する）セクション6.2で説明されたメカニズムを使用します。マニュアルの再構成をサポートしなければなりません。
It is assumed that (point-to-point) IP control channels are provisioned/configured between RCs belonging to the same routing level. Provisioning/configuration techniques are outside the scope of this document.
（ポイントツーポイント）IP制御チャネルが同じルーティングレベルに属するのRCとの間に構成/プロビジョニングされているものとします。プロビジョニング/構成技術は、この文書の範囲外です。
Once established, the OSPF Hello protocol is responsible for establishing and maintaining neighbor relationships. This protocol also ensures that communication between neighbors is bidirectional. Routing adjacency can subsequently be formed between RCs following mechanisms defined in [RFC2328].
設立後は、OSPFのHelloプロトコルは、ネイバー関係を確立し、維持する責任があります。このプロトコルはまた、近隣諸国との間の通信が双方向であることを保証します。ルーティング隣接関係は、続いて、[RFC2328]で定義されたメカニズムを以下のRCとの間に形成することができます。
This section details the RA ID reconfiguration steps.
このセクションでは、RA IDの再設定手順を詳しく説明します。
Reconfiguration of the RA ID occurs when the RA ID is modified, e.g., from value Z to value X or Y (see Figure 2).
RA IDが値Zから値XまたはY（図2を参照）、例えば、変更されたとき、RA IDの再構成が起こります。
The process of reconfiguring the RA ID involves:
RA IDを再構成プロセスが含まれます。
- Disable the import/export of routing information from the upper and lower levels (to prevent any LS information update).
- 上部及び下部レベルからのルーティング情報のインポート/エクスポートを無効にする（任意LS情報の更新を防ぐため）。
- Change the RA ID of the local level RA from, e.g., Z to X or Y. Perform a Link State Database (LSDB) checksum on all routers to verify that LSDBs are consistent.
- からローカルレベルRAのRA IDを変更し、例えば、XまたはYとZはLSDBsが一貫していることを確認するために、すべてのルータ上のリンク状態データベース（LSDB）のチェックサムを実行します。
- Enable import of upstream and downstream routing information such as to re-synchronize local-level LSDBs from any LS information that may have occurred in an upper or a lower routing level.
- 上部または下部ルーティングレベルで発生している可能性のあるLS情報から再同期ローカルレベルLSDBsのような上流および下流のルーティング情報のインポートを有効にします。
- Enable export of routing information downstream such as to re-sync the downstream level with the newly reconfigured RA ID (as part of the re-advertised Opaque TE LSA).
- そのような（再アドバタイズ不透明TE LSAの一部として）新たに再構成RA IDを再同期下流レベルの下流ルーティング情報のエクスポートを有効にします。
- Enable export of routing information upstream such as to re-sync the upstream level with the newly reconfigured RA ID (as part of the re-advertised Opaque TE LSA).
- そのような（再アドバタイズ不透明TE LSAの一部として）新たに再構成RA IDを再同期上流のレベルとして上流ルーティング情報のエクスポートを有効にします。
Note that the re-sync operation needs to be carried out only between the directly adjacent upper and lower routing levels.
再同期操作のみ直接隣接上下ルーティングレベルとの間で行われる必要があることに留意されたいです。
- Routing information exchange upward/downward in the hierarchy between adjacent RAs SHOULD by default be limited to reachability information. In addition, several transformations such as prefix aggregation are RECOMMENDED when allowing the amount of information imported/exported by a given RC to be decreased without impacting consistency.
- 隣接のRAとの間の階層の上向き/下向きのルーティング情報の交換は、デフォルトで到達可能性情報に限定されるべきです。一貫性に影響を与えることなく減少させることに与えRCによってエクスポート/インポートされた情報の量を可能にする場合に加えて、そのような接頭凝集などのいくつかの変換が推奨されます。
- Routing information exchange upward/downward in the hierarchy involving TE attributes MUST be under strict policy control. Pacing and min/max thresholds for triggered updates are strongly RECOMMENDED.
- TE属性を含む階層内の上方/下方への情報交換をルーティングすることは、厳格なポリシー制御下にある必要があります。ペーシングとトリガ更新のための最小/最大しきい値が強く推奨されています。
- The number of routing levels MUST be maintained under strict policy control.
- ルーティングレベルの数は、厳密なポリシー制御下に維持されなければなりません。
This document specifies the contents and processing of Opaque LSAs in OSPFv2 [RFC2328]. Opaque TE and RI LSAs defined in this document are not used for SPF computation, and so have no direct effect on IP routing. Additionally, ASON routing domains are delimited by the usual administrative domain boundaries.
この文書では、OSPFv2の[RFC2328]に不透明LSAの内容と処理を指定します。この文書で定義された不透明なTEとRI LSAはSPFの計算に使用されていない、ので、IPルーティングには直接影響しません。また、ASONルーティングドメインは、通常の管理ドメインの境界によって区切られています。
Any mechanisms used for securing the exchange of normal OSPF LSAs can be applied equally to all Opaque TE and RI LSAs used in the ASON context. Authentication of OSPFv2 LSA exchanges (such as OSPF cryptographic authentication [RFC2328] and [RFC5709]) can be used to secure against passive attacks and provide significant protection against active attacks. [RFC5709] defines a mechanism for authenticating OSPF packets by making use of the HMAC algorithm in conjunction with the SHA family of cryptographic hash functions.
通常のOSPF LSAの交換を確保するために使用される任意のメカニズムは、ASONの文脈で使用されるすべての不透明TEとRIのLSAにも同様に適用することができます。 （例えばOSPF暗号認証[RFC2328]及び[RFC5709]など）のOSPFv2 LSA交換の認証は、受動的攻撃に対して安全と能動攻撃に対する有意な保護を提供するために使用することができます。 [RFC5709]は暗号ハッシュ関数SHAファミリに関連してHMACアルゴリズムを利用してOSPFパケットを認証するためのメカニズムを定義します。
[RFC2154] adds 1) digital signatures to authenticate OSPF LSA data, 2) a certification mechanism for distribution of routing information, and 3) a neighbor-to-neighbor authentication algorithm to protect local OSPFv2 protocol exchanges.
[RFC2154]はローカルOSPFv2のプロトコル交換を保護するために、1）デジタルOSPF LSAデータを認証するための署名、ルーティング情報の配信2）認証機構、および3）隣接対の隣接認証アルゴリズムを追加します。
This document is classified as Experimental. It defines new TLVs and sub-TLVs for inclusion in OSPF LSAs. According to the assignment policies for the registries of code points for these TLVs and sub-TLVs, values must be assigned from the experimental ranges and must not be recorded by IANA or mentioned in this document.
この文書では、実験的に分類されます。それは、OSPFのLSAに含めるための新しいTLVのサブTLVを定義します。これらのTLVサブTLVのためのコードポイントのレジストリの割り当てポリシーに従って、値は、実験範囲から割り当てられなければならないとIANAによって記録された、または本文書に記載されてはなりません。
The following sections summarize the TLVs and sub-TLVs concerned.
以下のセクションでは、TLVのサブTLVのが関係まとめます。
This document defines the following sub-TLVs of the Link TLV carried in the OSPF TE LSA:
この文書では、OSPF TE LSAで運ばリンクTLVの次のサブTLVを定義します。
- Local and Remote TE Router ID sub-TLV - Associated RA ID sub-TLV
- TEルータIDサブTLVローカルおよびリモート - 関連RA IDサブTLV
The defining text for code point assignment for sub-TLVs of the OSPF TE Link TLV says ([RFC3630]):
OSPF TEリンクTLVのサブTLVのためのコードポイントの割り当てのための規定テキストは言う（[RFC3630]）。
o Types in the range 10-32767 are to be assigned via Standards Action.
範囲10-32767におけるOタイプは標準アクションを経由して割り当てられます。
o Types in the range 32768-32777 are for experimental use; these will not be registered with IANA, and MUST NOT be mentioned by RFCs.
実験的な使用のためのものである32768から32777の範囲のOタイプ。これらは、IANAに登録されず、RFCで言及されてはなりません。
o Types in the range 32778-65535 are not to be assigned at this time.
範囲32778から65535でOタイプではありません。この時点で割り当てられます。
That means that the new sub-TLVs must be assigned type values from the range 32768-32777. It is a matter for experimental implementations to assign their own code points, and to agree with cooperating implementations participating in the same experiments what values to use.
すなわち、新たなサブTLVの範囲32768から32777のタイプ値を割り当てなければならないことを意味します。実験的な実装は、独自のコードポイントを割り当てるために、どのような値が使用する同様の実験に参加して実装を協力に同意することが問題です。
Note that the same value for the Associated RA ID sub-TLV MUST be used when it appears in the Link TLV, the Node Attribute TLV, and the Router Address TLV.
それはリンクTLV、ノード属性TLV、およびルータアドレスTLVに表示されたときに関連するRA IDサブTLVのために同じ値を使用しなければならないことに注意してください。
This document defines the following sub-TLVs of the Node Attribute TLV carried in the OSPF TE LSA.
この文書では、TLVがOSPF TE LSAで運ばノード属性の次のサブTLVを定義します。
- Node IPv4 Local Prefix sub-TLV - Node IPv6 Local Prefix sub-TLV - Local TE Router ID sub-TLV - Associated RA ID sub-TLV
- ノードのIPv4ローカルプレフィックスサブTLV - ノードのIPv6ローカルプレフィックスサブTLV - ローカルTEルータIDサブTLV - 関連RA IDサブTLV
The defining text for code point assignment for sub-TLVs of the OSPF Node Attribute TLV says ([RFC5786]):
OSPFノードの下位のTLVのコードポイントの割り当てのための規定テキストはTLVは言う属性（[RFC5786]）。
o Types in the range 3-32767 are to be assigned via Standards Action.
範囲3から32767でOタイプは標準アクションを経由して割り当てられます。
o Types in the range 32768-32777 are for experimental use; these will not be registered with IANA, and MUST NOT be mentioned by RFCs.
実験的な使用のためのものである32768から32777の範囲のOタイプ。これらは、IANAに登録されず、RFCで言及されてはなりません。
o Types in the range 32778-65535 are not to be assigned at this time. Before any assignments can be made in this range, there MUST be a Standards Track RFC that specifies IANA Considerations that covers the range being assigned.
範囲32778から65535でOタイプではありません。この時点で割り当てられます。すべての割り当ては、この範囲内で行うことができる前に、割り当てられている範囲をカバーIANAの考慮事項を指定する標準化過程のRFCがあるに違いありません。
That means that the new sub-TLVs must be assigned type values from the range 32768-32777. It is a matter for experimental implementations to assign their own code points, and to agree with cooperating implementations participating in the same experiments what values to use.
すなわち、新たなサブTLVの範囲32768から32777のタイプ値を割り当てなければならないことを意味します。実験的な実装は、独自のコードポイントを割り当てるために、どのような値が使用する同様の実験に参加して実装を協力に同意することが問題です。
Note that the same value for the Associated RA ID sub-TLV MUST be used when it appears in the Link TLV, the Node Attribute TLV, and the Router Address TLV.
それはリンクTLV、ノード属性TLV、およびルータアドレスTLVに表示されたときに関連するRA IDサブTLVのために同じ値を使用しなければならないことに注意してください。
The OSPF Router Address TLV is defined in [RFC3630]. No sub-TLVs are defined in that document and there is no registry or allocation policy for sub-TLVs of the Router Address TLV.
OSPFルータアドレスTLVは[RFC3630]で定義されています。いいえサブTLVがそのドキュメントで定義されていないと、ルータアドレスTLVのサブTLVのためのレジストリまたは割り当てポリシーがありません。
This document defines the following new sub-TLV for inclusion in the OSPF Router Address TLV:
この文書では、OSPFルータアドレスTLVに含めるため、次の新しいサブTLVを定義しています。
- Associated RA ID sub-TLV
- 関連RA IDサブTLV
Note that the same value for the Associated RA ID sub-TLV MUST be used when it appears in the Link TLV, the Node Attribute TLV, and the Router Address TLV. This is consistent with potential for a future definition of a registry with policies that match the other existing registries.
それはリンクTLV、ノード属性TLV、およびルータアドレスTLVに表示されたときに関連するRA IDサブTLVのために同じ値を使用しなければならないことに注意してください。これは、他の既存のレジストリに一致するポリシーを持つレジストリの将来の定義のための潜在的に一致しています。
This document defines two new TLVs to be carried in the Router Information LSA.
この文書では、ルータ情報LSAに実施される2つの新しいTLVを定義します。
- Downstream Associated RA ID TLV - Router Information Experimental Capabilities TLV
- ダウンストリーム関連RA ID TLV - ルータ情報実験的機能TLV
The defining text for code point assignment for TLVs of the OSPF Router Information LSA says ([RFC4970]):
OSPFルータ情報LSAのTLVのためのコードポイントの割り当てのための規定のテキストは（[RFC4970]）と言います。
o 1-32767 Standards Action.
O 1〜32767の規格アクション。
o Types in the range 32768-32777 are for experimental use; these will not be registered with IANA and MUST NOT be mentioned by RFCs.
実験的な使用のためのものである32768から32777の範囲のOタイプ。これらは、IANAに登録されず、RFCで言及されてはなりません。
o Types in the range 32778-65535 are reserved and are not to be assigned at this time. Before any assignments can be made in this range, there MUST be a Standards Track RFC that specifies IANA Considerations that covers the range being assigned.
32778から65535の範囲内のOタイプは、予約されており、この時点で割り当てられるようにされていません。すべての割り当ては、この範囲内で行うことができる前に、割り当てられている範囲をカバーIANAの考慮事項を指定する標準化過程のRFCがあるに違いありません。
That means that the new TLVs must be assigned type values from the range 32768-32777. It is a matter for experimental implementations to assign their own code points, and to agree with cooperating implementations participating in the same experiments what values to use.
それは新しいのTLVが範囲32768から32777からのタイプ値を割り当てなければならないことを意味しています。実験的な実装は、独自のコードポイントを割り当てるために、どのような値が使用する同様の実験に参加して実装を協力に同意することが問題です。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997.
[RFC2154]マーフィー、S.、アナグマ、M.、およびB.ウェリントン、 "デジタル署名とOSPF"、RFC 2154、1997年6月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630]カッツ、D.、Kompella、K.、およびD.ヨン、 "トラフィックエンジニアリング（TE）OSPFバージョン2への拡張"、RFC 3630、2003年9月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]マニー、E.、エド。、 "一般化マルチプロトコルラベルスイッチング（GMPLS）アーキテクチャ"、RFC 3945、2004年10月。
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4202] Kompella、K.、エド。、およびY. Rekhter、エド。、 "ルーティング拡張一般マルチプロトコルラベルスイッチング（GMPLS）のサポートで"、RFC 4202、2005年10月。
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
[RFC4203] Kompella、K.、エド。、およびY. Rekhter、エド。、RFC 4203、2005年10月 "OSPF拡張一般化マルチプロトコルラベルスイッチング（GMPLS）のサポートで"。
[RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 4970, July 2007.
[RFC4970] Lindem、A.編、シェン、N.、Vasseur、JP。、アガルワル、R.、およびS.シェイファー、 "広告オプションのルータの機能のためのOSPFへの拡張"、RFC 4970、2007年7月。
[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問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The OSPF Opaque LSA Option", RFC 5250, July 2008.
[RFC5250]バーガー、L.、Bryskin、I.、ジニン、A.、およびR. Coltun、 "OSPFオペークLSAオプション"、RFC 5250、2008年7月。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340] Coltun、R.、ファーガソン、D.、モイ、J.、およびA. Lindem、 "IPv6のためのOSPF"、RFC 5340、2008年7月。
[RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's Local Addresses in OSPF TE Extensions", RFC 5786, March 2010.
[RFC5786]アガルワル、R.とK. Kompella、 "OSPF TE Extensionsでルータのローカルアドレスをアドバタイズ"、RFC 5786、2010年3月。
[RFC4258] Brungard, D., Ed., "Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON)", RFC 4258, November 2005.
[RFC4258] Brungard、D.、エド。、RFC 4258、2005月 "一般化マルチプロトコルラベルのための要件は、自動的に交換光ネットワーク（ASON）のためのルーティング（GMPLS）の切り替え"。
[RFC4652] Papadimitriou, D., Ed., Ong, L., Sadler, J., Shew, S., and D. Ward, "Evaluation of Existing Routing Protocols against Automatic Switched Optical Network (ASON) Routing Requirements", RFC 4652, October 2006.
[RFC4652] Papadimitriouは、D.、編、オング、L.、サドラー、J.、供え、S.、およびD.区は、 "自動に対する既存のルーティングプロトコルの評価は光ネットワーク（ASON）ルーティング要件スイッチ"、RFC 4652、2006年10月。
[RFC5073] Vasseur, J., Ed., and J. Le Roux, Ed., "IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities", RFC 5073, December 2007.
[RFC5073] Vasseur、J.、エド。、およびJ.ル・ルー、エド。、 "トラフィックエンジニアリングノード能力の発見のためのIGPルーティングプロトコルの拡張機能"、RFC 5073、2007年12月。
[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Authentication", RFC 5709, October 2009.
[RFC5709] Bhatiaは、M.、Manral、V.、Fanto、M.、ホワイト、R.、バーンズ、M.、李、T.、およびR.アトキンソン、 "OSPFv2のHMAC-SHA暗号化認証"、RFC 5709、 2009年10月。
For information on the availability of ITU Documents, please see http://www.itu.int.
ITU文書の入手については、http://www.itu.intを参照してください。
[G.7715] ITU-T Rec. G.7715/Y.1306, "Architecture and Requirements for the Automatically Switched Optical Network (ASON)", June 2002.
[G.7715] ITU-T勧告。 、2002年6月G.7715 / Y.1306、「自動的に交換光ネットワーク（ASON）のためのアーキテクチャと要件」。
[G.7715.1] ITU-T Draft Rec. G.7715.1/Y.1706.1, "ASON Routing Architecture and Requirements for Link State Protocols", November 2003.
【G.7715.1] ITU-Tドラフト撮影。 G.7715.1 / Y.1706.1、「ASONルーティングアーキテクチャとリンクステートプロトコルのための要件」、2003年11月。
[G.805] ITU-T Rec. G.805, "Generic functional architecture of transport networks)", March 2000.
[G.805] ITU-T勧告。 G.805、「トランスポート・ネットワークの一般的な機能アーキテクチャ）」、2000年3月。
[G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the Automatically Switched Optical Network (ASON)," November 2001 (and Revision, January 2003).
[G.8080] ITU-T勧告。 G.8080 / Y.1304、2001年11月 "の自動交換光ネットワーク（ASON）、のためのアーキテクチャ"（および改訂、2003年1月）。
The author would like to thank Dean Cheng, Acee Lindem, Pandian Vijay, Alan Davey, Adrian Farrel, Deborah Brungard, and Ben Campbell for their useful comments and suggestions.
作者は彼らの役に立つコメントと提案のためのディーン・チェン、ACEE Lindem、Pandianビジェイ、アラン・デイヴィー、エードリアンファレル、デボラBrungard、ベン・キャンベルに感謝したいと思います。
Lisa Dusseault and Jari Arkko provided useful comments during IESG review.
リサDusseaultとヤリArkkoはIESGレビューの間に有用なコメントを提供しました。
Question 14 of Study Group 15 of the ITU-T provided useful and constructive input.
ITU-Tの研究グループ15の質問14が有用と建設的入力を提供しました。
Appendix A. ASON Terminology
付録A. ASON用語
This document makes use of the following terms:
このドキュメントでは、次の用語を使用します：
Administrative domain: (See Recommendation [G.805].) For the purposes of [G7715.1], an administrative domain represents the extent of resources that belong to a single player such as a network operator, a service provider, or an end-user. Administrative domains of different players do not overlap amongst themselves.
管理ドメイン：（勧告[G.805]を参照。）[G7715.1]の目的のために、管理ドメインは、ネットワークオペレータ、サービスプロバイダ、またはエンドとしてシングルプレイヤーに属するリソースの程度を表します-ユーザー。異なるプレイヤーの管理ドメインは、それ自体で重複していません。
Control plane: performs the call control and connection control functions. Through signaling, the control plane sets up and releases connections, and may restore a connection in case of a failure.
制御プレーンは：呼制御及び接続制御機能を実行します。シグナリングを介して、制御プレーンがセットアップ解放接続、障害が発生した場合に接続を復元することができます。
(Control) Domain: represents a collection of (control) entities that are grouped for a particular purpose. The control plane is subdivided into domains matching administrative domains. Within an administrative domain, further subdivisions of the control plane are recursively applied. A routing control domain is an abstract entity that hides the details of the RC distribution.
（コントロール）ドメイン：特定の目的のためにグループ化されている（制御）エンティティの集合を表します。制御プレーンは、管理ドメインに一致するドメインに細分されます。管理ドメイン内に、制御プレーンのさらなる細分化を再帰的に適用されます。経路制御ドメインは、RC分布の詳細を隠蔽する抽象エンティティです。
External NNI (E-NNI): interfaces are located between protocol controllers between control domains.
外部NNI（E-NNI）：インタフェースは、制御ドメインとの間のプロトコルコントローラとの間に配置されています。
Internal NNI (I-NNI): interfaces are located between protocol controllers within control domains.
内部NNI（I-NNI）：インタフェースは、制御ドメイン内のプロトコルコントローラとの間に配置されています。
Link: (See Recommendation G.805.) A "topological component" that describes a fixed relationship between a "subnetwork" or "access group" and another "subnetwork" or "access group". Links are not limited to being provided by a single server trail.
リンク：（勧告G.805を参照）。A「サブネットワーク」または「アクセスグループ」と別の「サブネットワーク」または「アクセスグループ」との間の一定の関係を記述する「トポロジー成分」。リンクは、単一のサーバ証跡によって提供されることに限定されません。
Management plane: performs management functions for the transport plane, the control plane, and the system as a whole. It also provides coordination between all the planes. The following management functional areas are performed in the management plane: performance, fault, configuration, accounting, and security management.
管理プレーンは：トランスポート・プレーン、制御プレーン、およびシステム全体の管理機能を実行します。また、すべての面の間の調整を提供します。パフォーマンス、障害、設定、アカウンティング、およびセキュリティ管理：以下の管理機能領域は、管理プレーンで実行されています。
Management domain: (See Recommendation G.805.) A management domain defines a collection of managed objects that are grouped to meet organizational requirements according to geography, technology, policy, or other structure, and for a number of functional areas such as configuration, security, (FCAPS), for the purpose of providing control in a consistent manner. Management domains can be disjoint, contained, or overlapping. As such, the resources within an administrative domain can be distributed into several possible overlapping management domains. The same resource can therefore belong to several management domains simultaneously, but a management domain shall not cross the border of an administrative domain.
管理ドメイン：（勧告G.805を参照してください。）管理ドメインは、地理学、技術、政策、または他の構造に応じて、組織の要件を満たすためにグループ化された管理対象オブジェクトのコレクションを定義し、このような構成などの機能領域の数について、一貫した方法で制御を提供する目的のためのセキュリティ、（FCAPS）。管理ドメインが含まれる、互いに素、または重複することができます。このように、管理ドメイン内のリソースは、いくつかの可能な重複管理ドメイン内に分布させることができます。同じリソースは、したがって、同時に複数の管理ドメインに属することができますが、管理ドメインは、管理ドメインの境界を越えてはなりません。
Subnetwork Point (SNP): The SNP is a control plane abstraction that represents an actual or potential transport plane resource. SNPs (in different subnetwork partitions) may represent the same transport resource. A one-to-one correspondence should not be assumed.
サブネットワークポイント（SNP）：SNPは、実際のまたは潜在的なトランスポート・プレーン・リソースを表す制御プレーン抽象化です。 （異なるサブネットワークパーティション内）SNPは、同じトランスポートリソースを表すことができます。 1対1の対応が想定されるべきではありません。
Subnetwork Point Pool (SNPP): A set of SNPs that are grouped together for the purposes of routing.
サブネットワークポイントプール（SNPP）：ルーティングの目的のために一緒にグループ化されるSNPのセット。
Termination Connection Point (TCP): A TCP represents the output of a Trail Termination function or the input to a Trail Termination Sink function.
終端接続ポイント（TCP）：TCPは、トレイル終端シンク機能にトレイル終端機能または入力の出力を表します。
Transport plane: provides bidirectional or unidirectional transfer of user information, from one location to another. It can also provide transfer of some control and network management information. The transport plane is layered; it is equivalent to the Transport Network defined in Recommendation G.805.
トランスポートプレーンは：一つの場所から別のものに、ユーザ情報の双方向または単方向転送を提供します。また、いくつかの制御とネットワーク管理情報の転送を提供することができます。トランスポート・プレーンは、層状です。それは、勧告G.805で定義されたトランスポートネットワークと同等です。
User Network Interface (UNI): interfaces are located between protocol controllers between a user and a control domain. Note: There is no routing function associated with a UNI reference point.
ユーザネットワークインタフェース（UNI）：インターフェイスは、ユーザと制御ドメインとの間のプロトコルコントローラとの間に配置されています。注：UNI基準点に関連付けられたルーティング機能はありません。
Appendix B. ASON Routing Terminology
付録B. ASONルーティング用語
This document makes use of the following terms:
このドキュメントでは、次の用語を使用します：
Routing Area (RA): an RA represents a partition of the data plane, and its identifier is used within the control plane as the representation of this partition. Per [G.8080], an RA is defined by a set of sub-networks, the links that interconnect them, and the interfaces representing the ends of the links exiting that RA. An RA may contain smaller RAs inter-connected by links. The limit of subdivision results in an RA that contains two sub-networks interconnected by a single link.
ルーティングエリア（RA）：RAは、データプレーンのパーティションを表し、その識別子は、このパーティションの表現として制御プレーン内で使用されています。 [G.8080]、RAは、サブネットワークのセットによって定義され、それらを相互接続するリンク、及びそのRAを出るリンクの両端を表すインターフェイス。 RAは小さいRAのリンクによって相互接続されているが含まれていてもよいです。単一のリンクによって相互接続された2つのサブネットワークを含んRAにおける細分割結果の限界。
Routing Database (RDB): a repository for the local topology, network topology, reachability, and other routing information that is updated as part of the routing information exchange and may additionally contain information that is configured. The RDB may contain routing information for more than one routing area (RA).
ルーティングデータベース（RDB）：ルーティング情報交換の一部として更新され、さらに構成されている情報を含むことができるローカル・トポロジ、ネットワークトポロジ、到達可能性、および他のルーティング情報のリポジトリ。 RDBは、複数のルーティングエリア（RA）のためのルーティング情報を含んでいてもよいです。
Routing Components: ASON routing architecture functions. These functions can be classified as protocol independent (Link Resource Manager or LRM, Routing Controller or RC) or protocol specific (Protocol Controller or PC).
ルーティングコンポーネント：ASONルーティングアーキテクチャ機能。これらの機能は、プロトコルに依存しない（リンクリソースマネージャまたはLRM、ルーティングコントローラまたはRC）またはプロトコルの特定（プロトコル・コントローラまたはPC）に分類することができます。
Routing Controller (RC): handles (abstract) information needed for routing and the routing information exchange with peering RCs by operating on the RDB. The RC has access to a view of the RDB. The RC is protocol independent.
ルーティングコントローラ（RC）：ルーティングとRDB上で操作してのRCをピアリングとルーティング情報を交換するために必要なハンドル（アブストラクト）情報。 RCは、RDBのビューへのアクセスを持っています。 RCはプロトコルに依存しています。
Note: Since the RDB may contain routing information pertaining to multiple RAs (and possibly to multiple layer networks), the RCs accessing the RDB may share the routing information.
注：RDBは、複数のRA（および場合によっては複数層ネットワークへ）に関連するルーティング情報を含むかもしれないので、RDBにアクセスRCSはルーティング情報を共有することができます。
Link Resource Manager (LRM): supplies all the relevant component and TE link information to the RC. It informs the RC about any state changes of the link resources it controls.
リンクリソースマネージャ（LRM）：RCに関連するすべてのコンポーネントとTEリンク情報を提供しています。それはそれが制御するリンクリソースのいずれかの状態の変化についてのRCを通知します。
Protocol Controller (PC): handles protocol-specific message exchanges according to the reference point over which the information is exchanged (e.g., E-NNI, I-NNI), and internal exchanges with the RC. The PC function is protocol dependent.
プロトコルコントローラ（PC）は：情報が交換される上の基準点（例えば、E-NNI、I-NNI）によれば、プロトコル固有のメッセージ交換を処理し、RCと内部交換。 PCの機能は、プロトコルに依存しています。
Author's Address
著者のアドレス
Dimitri Papadimitriou Alcatel-Lucent Bell Copernicuslaan 50 B-2018 Antwerpen Belgium Phone: +32 3 2408491 EMail: dimitri.papadimitriou@alcatel-lucent.be
ディミトリPapadimitriouアルカテルLykentペラKopernikoslaan 50 B-2018アントワープ、ベルギー電話：+ X2 3 2408491メールアドレス：δημήτρη.παπαδημητρίου@αλκατελ-λυκεντ.βε