[要約] RFC 5787はASONルーティングのためのOSPFv2ルーティングプロトコルの拡張に関するものであり、ASONネットワークでのルーティングをサポートするための仕様を提供しています。このRFCの目的は、ASONネットワークでの効率的なルーティングを実現するための拡張機能を定義することです。
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
自動化された光ネットワーク（ASON）ルーティング用のOSPFV2ルーティングプロトコル拡張
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）、Lambdaスイッチングなどのタイムディビジョンマルチプレックス（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.
ASONルーティングの要件を満たすためのGMPLSルーティングの要件と、既存の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.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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）ネットワークなどの光学ネットワークを含むさまざまなネットワークテクノロジーのコントロールプレーンを提供するように設計されています。Lambdaは光ネットワークを切り替えます。
The ITU-T defines the architecture of the Automatically Switched Optical Network (ASON) in [G.8080].
ITU-Tは、[G.8080]の自動化された光ネットワーク（ASON）のアーキテクチャを定義します。
[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ルーティングモデルには、スケーリングと機密性の利点を提供するルーティングレベルの定義が含まれています。マルチレベルのルーティングでは、ルーティングエリア（RA）と呼ばれるドメインが階層関係に配置されます。[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.
一般的なアソンの用語は付録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.
RAは、1つの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ルーティングエリアの階層にマッピングされません。代わりに、RAの連続した階層レベルは、プロトコルの個別のインスタンスで表現する必要があります。したがって、レベル間のルーティング情報交換（セクション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ビット番号）の形を取得します。ローカルアドレスのセットは、OSPFV2 TE LSAノード属性TLVで運ばれます（特定のサブTLVは、住所ファミリ、つまりIPv4およびIPv6がネットワークユニーク識別子として使用されます）に定義されます）。
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:
提案されたソリューションは、ルーターのローカルアドレスプレフィックスを（OSPFV2 TE LSA）ノード属性のトップレベルTLVの新しいサブTLVとして宣伝することです。このドキュメントでは、次のサブTLVを定義します。
- Node IPv4 Local Prefix sub-TLV: Length: variable - Node IPv6 Local Prefix sub-TLV: Length: variable
- ノードIPv4ローカルプレフィックスSub-TLV：length：variable-node ipv6 local prefix sub-tlv：length：variable
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ローカルプレフィックスSub-TLVのタイプフィールドには、実験のすべての参加者が合意した範囲32768-32777の値が割り当てられます。このSub-TLVの値フィールドには、1つ以上のローカルIPv4プレフィックスが含まれています。長さはバイトで測定され、[RFC3630]で定義されているように、サブTLVの値部分のバイトの長さを報告します。8 x nに設定されています。nは、sub-tlvに含まれるローカルIPv4プレフィックスの数です。
The Node IPv4 Local Prefix sub-TLV has the following format:
ノードIPv4ローカルプレフィックスSub-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：IPv4アドレスマスクを示す32ビット番号ITH宛先のプレフィックス。
Each <Network mask, IPv4 Address> pair listed as part of this sub-TLV represents a reachable destination prefix hosted by the advertising Router ID.
各<ネットワークマスク、IPv4アドレス>このSub-TLVの一部としてリストされているペアは、広告ルーター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ローカルプレフィックスSub-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ローカルプレフィックスSub-TLVのタイプフィールドには、実験のすべての参加者が合意した範囲32768-32777の値が割り当てられます。このSub-TLVの値フィールドには、1つ以上のローカルIPv6プレフィックスが含まれています。IPv6プレフィックス表現は[RFC5340]、セクションA.4.1を使用します。
The Node IPv6 Local Prefix sub-TLV has the following format:
ノードIPv6ローカルプレフィックスSub-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).
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.
プレフィックスの長さ：プレフィックスのビットの長さ。
PrefixOptions: 8-bit field describing various capabilities associated with the prefix (see [RFC5340], Section A.4.2).
プレフィキソップ：プレフィックスに関連付けられたさまざまな機能を記述する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：リスト内の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ローカルプレフィックスSub-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でのリンク属性と特性とその表現の間のマップを提供します（以下を参照）。この情報の広告は、層ごとにサポートされる必要があります。つまり、スイッチング機能ごとに1つの不透明なte LSA（および帯域幅の粒度、たとえば、低次の仮想コンテナや高次仮想コンテナ）。
Local adaptation is defined as a TE link attribute (i.e., sub-TLV) that describes the cross/inter-layer relationships.
ローカル適応は、交差/層間の関係を説明するTEリンク属性（つまり、Sub-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.
たとえば、2つの光クロスコネクト間のリンクには、Lambdaスイッチング可能（LSC）スイッチング機能を記述する少なくとも1つのISCD属性が含まれます。一方、光クロスコネクトとIP/MPLS LSRとの間のリンクには、少なくとも2つのISCD属性が含まれます。1つはLSC終端機能の説明とパケットスイッチング能力（PSC）適応機能の1つです。
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）は、トップレベルリンクTLV（タイプ2の）[RFC4203]のサブTLV（タイプ15の）です。
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 Sub-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]に従って、1つ以上のISCDサブTLVをインターフェイスに関連付けることができます。この情報は、保証されていない帯域幅（[RFC3630]で定義されているSub-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].
ASONのコンテキストでは、他の広告フィールドの表現と情報が特定の技術（SDHなど）に十分ではない場合に追加情報が含まれる場合があります。技術固有の情報要素の定義は、このドキュメントの範囲を超えています。一部のテクノロジーでは、[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は物理的な（Bearer/Data/Transport Plane）ノードです。
- 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は、単一のデータプレーン（要約）ノードに関連付けられている論理制御プレーンエンティティです。各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がその範囲に複数のLIを持っている可能性があることを除いて、特定のエンティティ関係にあるとは想定されていません。RIとLIの関係は、いつでも簡単です。LIは、いつでも1つのRIによって宣伝される場合があります。ただし、RIは1つ以上のLIのセットを宣伝する場合があります。したがって、OSPFV2ルーティングプロトコルは、複数のLIに代わって単一の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）広告は、ルーターIDとTEルーターIDの間に1：N関係を作成します。Link Local and Link Remote（Unnoumbered）ID Associationはノードごとに一意ではないため、広告はリモートLJ値を示し、[Li; LJ]関係を取得するための初期発見プロセスに依存する必要があります。簡単に言えば、Noumbered LinkがIDを1人ごとに定義しているため、リモートLJを識別する必要があります。したがって、ルーティングプロトコルは、正しい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.
この目的のために、ローカルおよびリモートTEルーターIDを定義する（OSPFV2 TE LSA）トップレベルリンクTLVの新しいサブTLVが導入されています。
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のタイプフィールドには、実験のすべての参加者が合意した範囲32768-32777の値が割り当てられます。長さのフィールドは値8を取得します。このサブTLVの値フィールドには、ローカル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の一部として含める必要があります。他のいずれの場合でも、オペレーターが1 LIから始めて、一貫性を維持するなどのLI（同じRIの下）を徐々に追加することを計画している場合を除き、このSUB-TLVを省略する必要があります。
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ごとに正確に1回表示する必要があります。このサブTLVは、[RFC3630]で定義されているように処理する必要があります。
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のタイプフィールドには、実験のすべての参加者が合意した範囲32768-32777の値が割り当てられます。長さフィールドは値4を取得します。このサブTLVの値フィールドには、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.
RAの連続した階層レベルは、プロトコルの個別のインスタンスで表すことができます。
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.
RASをサポートするルーティングコントローラー（RCS）は、この階層で情報を下方および上方に広めます。このセクションで説明する垂直ルーティング情報普及メカニズムは、新しい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.
RASをサポートするRCSは、ルーティング情報をLSタイプ10の不透明なTE LSA（不透明タイプ1）としてインポート/エクスポートすることにより、階層内の情報を上方および下向きに広めます。トップレベルのTLV。
The Opaque TE LSA import/export rules are governed as follows:
不透明な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を参照）を含むと予想されます（セクション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]).
ルーティング階層にルーティング情報を広めることができるRCを発見するために、ルーター情報LSA（[RFC4970]）に掲載されているOSPFルーター情報実験機能TLV（セクション6.2.3を参照）に次の機能記述子ビットが設定されています（[RFC4970]）。
- 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から宣伝されている場合、ルーティング情報の上向きの普及のためにRCとして選択する必要があります。他のRCは、最高のルーター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）レベルに隣接することを考慮するように、追加の制限を適用する必要があります。この目的のために、RCがルーティング情報を普及させることができる（低い）RA IDをインデックス作成する特定のTLVが必要です。
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のタイプフィールドには、実験のすべての参加者が合意した範囲32768-32777の値が割り当てられます。このTLVの長さはn x 4オクテットです。このSub-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]).
ルーティング階層を介してルーティング情報を下方に広めることができるRCを発見するために、ルーター情報LSA（[RFC4970]）に携帯されている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.
同じ関連RA IDに対して複数のRCが宣伝されている場合、DビットセットのRCの中で最高のルーターIDを持つRCは、ルーティング情報の下向きの普及のためのRCとして選択する必要があります。同じ関連RA IDの他のRCは、最高のルーター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の選択を許可する情報が特定のRAに自動的に発見できない場合は、手動で構成する必要があることに注意してください。
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.
OSPFルーター情報不透明LSA（4の不透明なタイプ4、0の不透明ID）およびその内容、特にルーター情報機能TLV [RFC4970]およびTEノード機能記述子[RFC5073]は、再編成されてはなりません。
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.
ルーター情報LSAを運ぶために、ルーター情報LSAに含めるために新しいTLVが定義されています。これは、ルーターの情報機能機能TLVのBITの割り当てポリシーが「標準アクション」[RFC5226]であるため、実験文書を禁止するためです。
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のタイプA値。
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.
長さは、オクテットの値部分の長さを示す16ビットフィールドで、宣伝されている機能の数に依存する4オクテットの倍数になります。当初、長さは4で、情報能力ビットの4オクテットを意味します。
Value A variable-length sequence of capability bits rounded to a multiple of 4 octets padded with undefined bits.
値のあるビットの倍数に丸められた可変長のシーケンスの可変長シーケンスビットを値化しないビットをパッドに詰めます。
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ビット（セクション6.2.1を参照）1 Dビット（セクション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.
これらの条件が満たされている場合、同じRAに関連付けられたRCによって下方に輸入/エクスポートされた不透明なte LSAを受け取った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 Sub-TLVのタイプフィールドには、実験のすべての参加者が合意した範囲32768-32777の値が割り当てられます。Sub-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オクテットです。このSub-TLVの値フィールドには、関連するRA IDが含まれています。関連するRA ID値は、[RFC2328]で定義されたルールをエンコードするOSPFエリアID（32ビット）エンコードに従ってエンコードされます。
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が受信した不透明な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.
- 受信した不透明なテルサの関連RA IDと、エクスポートターゲットインターフェイスのエリアに属するRA IDの間に一致が見つかった場合、不透明なテルサをインポートしてはなりません。
- 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は同じ広告がRA_X（RC_3）でRC_4に伝播する前にその情報を受信することができます。この目的のために、RC_1Aは関連するRA XをRA_Xからインポートされたルーティング情報に挿入します。RC_2Bは、受信した不透明なLSAの関連RA ID（x）とエクスポートターゲットインターフェイスのRAの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は、ルーティング情報を交換する目的で、隣接するルーター間の隣接を作成します。隣人が発見された後、双方向のコミュニケーションが確保され、RCの間にルーティング隣接が形成され、通信が失われると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にルーティング情報を下方に交換できるように、再構成可能にすることをお勧めします。この再構成は、手動または自動的に実行される場合があります。後者の場合、自動再構成により、セクション6.2で説明されているメカニズムが使用されます（発信されるRCが到達できなくなった場合に、対応する不透明LSA情報の最大値を強制します）。手動再構成をサポートする必要があります。
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の再構成は、RA IDが値Zから値XまたはYに変更されたときに発生します（図2を参照）。
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.
- LSDBが一貫していることを確認するために、すべてのルーターでリンク状態データベース（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情報からローカルレベルのLSDBを再同期させるなどです。
- 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).
- 下流のルーティング情報のエクスポートを有効にして、新しく再構成された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).
- 新しく再構成されたRA ID（再承認された不透明なTe LSAの一部として）と上流レベルを再同期するなど、上流のルーティング情報のエクスポートを有効にします。
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.
- 情報属性を含む階層内のルーティング情報交換は、厳格な政策管理下にある必要があります。トリガーされた更新のペーシングおよびMin/Maxしきい値を強くお勧めします。
- 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に等しく適用できます。OSPFV2 LSA交換（OSPF暗号認証[RFC2328]や[RFC5709]など）の認証を使用して、受動的な攻撃を確保し、アクティブな攻撃に対する大幅な保護を提供できます。[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]は、1）OSPF LSAデータを認証するためのデジタル署名、2）ルーティング情報の配布の認証メカニズム、および3）近隣からneighborへの認証アルゴリズムを追加して、ローカルOSPFv2プロトコル交換を保護する。
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およびSub-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 sub-tlv-関連RA id sub-tlv関連
The defining text for code point assignment for sub-TLVs of the OSPF TE Link TLV says ([RFC3630]):
OSPF TE LINK TLVのサブTLVのコードポイント割り当ての定義テキスト（[RFC3630]）：
o Types in the range 10-32767 are to be assigned via Standards Action.
o 範囲10-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.
o 範囲32768-32777のタイプは、実験用のものです。これらはIANAに登録されておらず、RFCSで言及してはなりません。
o Types in the range 32778-65535 are not to be assigned at this time.
o 範囲32778-65535のタイプは、現時点では割り当てられません。
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 Sub-TLVの同じ値を使用する必要があることに注意してください。
This document defines the following sub-TLVs of the Node Attribute TLV carried in the OSPF TE LSA.
このドキュメントでは、OSPF TE LSAで運ばれるノード属性TLVの次のサブ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ローカルプレフィックスSub-TLV-Node IPv6ローカルプレフィックスSub-TLV-Local TE Router ID Sub-TLV-関連RA ID Sub-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.
o 範囲3-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.
o 範囲32768-32777のタイプは、実験用のものです。これらはIANAに登録されておらず、RFCSで言及してはなりません。
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.
o 範囲32778-65535のタイプは、現時点では割り当てられません。この範囲で割り当てを行う前に、割り当てられている範囲をカバーする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 Sub-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 Sub-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ルーター情報のTLVのコードポイント割り当ての定義テキストLSAは言う（[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.
o 範囲32768-32777のタイプは、実験用のものです。これらはIANAに登録されておらず、RFCSで言及してはなりません。
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.
o 範囲32778-65535のタイプは予約されており、現時点では割り当てられません。この範囲で割り当てを行う前に、割り当てられている範囲をカバーする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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997.
[RFC2154] Murphy、S.、Badger、M.、およびB. Wellington、「Digital Signatures with Digital Signatures」、RFC 2154、1997年6月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、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] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering（TE）Extensions to OSPFバージョン2」、RFC 3630、2003年9月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] Mannie、E.、ed。、「一般化されたマルチプロトコルラベルスイッチング（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.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（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.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするOSPF拡張」、RFC 4203、2005年10月。
[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.、Ed。、Shen、N.、Vasseur、Jp。、Aggarwal、R。、およびS. Shaffer、「オプションのルーター機能の広告のための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] Berger、L.、Bryskin、I.、Zinin、A。、およびR. Coltun、「OSPF Opaque 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.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、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] Aggarwal、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.、ed。、「自動化された光ネットワーク（ASON）の一般化されたマルチプロトコルラベルスイッチング（GMPLS）ルーティングの要件」、RFC 4258、2005年11月。
[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.、Ed。、Ong、L.、Sadler、J.、Shew、S。、およびD. Ward、「自動切り替え光ネットワーク（ASON）ルーティング要件に対する既存のルーティングプロトコルの評価」、RFC4652、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.、ed。、およびJ. Le Roux、ed。、「トラフィックエンジニアリング機能の発見のための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.、White、R.、Barnes、M.、Li、T。、およびR. Atkinson、「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 rec。G.7715/Y.1306、「自動化された光ネットワーク（ASON）のアーキテクチャと要件」、2002年6月。
[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ドラフトRec。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 rec。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 rec。G.8080/Y.1304、「自動化された光ネットワーク（ASON）のアーキテクチャ」、2001年11月（および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.
著者は、ディーン・チェン、エーシー・リンデム、パンディアン・ヴィジェイ、アラン・デイビー、エイドリアン・ファレル、デボラ・ブルガード、ベン・キャンベルの有用なコメントと提案に感謝したいと思います。
Lisa Dusseault and Jari Arkko provided useful comments during IESG review.
Lisa DusseaultとJari Arkkoは、IESGレビュー中に有用なコメントを提供しました。
Question 14 of Study Group 15 of the ITU-T provided useful and constructive input.
ITU-Tの研究グループ15の質問14は、有用で建設的な入力を提供しました。
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を参照してください。）「サブネットワーク」または「アクセスグループ」と別の「サブネットワーク」または「アクセスグループ」の間の固定関係を説明する「トポロジコンポーネント」。リンクは、単一のサーバートレイルによって提供されることに限定されません。
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参照ポイントに関連付けられたルーティング機能はありません。
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を操作することにより、RCSとのルーティング情報交換を処理します。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には、複数のRAS（およびおそらく複数のレイヤーネットワークに関するルーティング情報が含まれている可能性があるため、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.
Link Resource Manager（LRM）：関連するすべてのコンポーネントとTEリンク情報をRCに提供します。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
dimitri papadimitriou alcatel-lucent bell copernicuslaan 50 B-2018 Antwerpen Belgium電話：32 3 2408491メール：dimitri.papadimitriou@alcatel-lucent.be