[要約] RFC 6827は、ASONルーティングをサポートするためのOSPFv2プロトコルに関する仕様です。このRFCの目的は、光ネットワークの自動切り替えを実現するためのルーティングメカニズムを提供することです。
Internet Engineering Task Force (IETF) A. Malis, Ed.
Request for Comments: 6827 Verizon Communications
Obsoletes: 5787 A. Lindem, Ed.
Updates: 5786 Ericsson
Category: Standards Track D. Papadimitriou, Ed.
ISSN: 2070-1721 Alcatel-Lucent
January 2013
Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols
OSPFv2プロトコル用の自動切り替え光ネットワーク（ASON）ルーティング
Abstract
概要
The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON).
ITU-Tは、Automatically Switched Optical Network（ASON）を運用するためのアーキテクチャと要件を定義しています。
The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies. These include optical networks such as time division multiplexing (TDM) networks including the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH), Optical Transport Networks (OTNs), and lambda switching optical networks.
Generalized Multiprotocol Label Switching（GMPLS）プロトコルスイートは、さまざまなネットワークテクノロジーにコントロールプレーンを提供するように設計されています。これらには、同期光ネットワーク/同期デジタル階層（SONET / SDH）、光トランスポートネットワーク（OTN）、ラムダスイッチング光ネットワークなど、時分割多重（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 that were current when those documents were written. Future extensions or 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. This document obsoletes RFC 5787 and updates RFC 5786.
この作業は、RFC 4258とRFC 4652で表現された要件と評価、およびそれらのドキュメントが書かれたときに最新であったITU-T勧告に範囲が限定されていることに注意してください。 ITU-T勧告が改訂された場合、またはRFC 4258の改訂版に新しい要件が導入された場合、この作業の将来の拡張または改訂が必要になることがあります。このドキュメントはRFC 5787を廃止し、RFC 5786を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc6827.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6827で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Conventions Used in This Document ..........................5
2. Routing Areas, OSPF Areas, and Protocol Instances ...............5
3. Terminology and Identification ..................................6
4. Reachability ....................................................7
5. Link Attribute ..................................................8
5.1. Local Adaptation ...........................................8
5.2. Bandwidth Accounting .......................................9
6. Routing Information Scope .......................................9
6.1. Link Advertisement (Local and Remote TE Router ID Sub-TLV) .9
6.2. Reachability Advertisement (Local TE Router ID Sub-TLV) ...11
7. Routing Information Dissemination ..............................11
7.1. Import/Export Rules .......................................12
7.2. Loop Prevention ...........................................12
7.2.1. Inter-RA Export Upward/Downward Sub-TLVs ...........13
7.2.2. Inter-RA Export Upward/Downward Sub-TLV Processing .13
8. OSPFv2 Scalability .............................................14
9. Security Considerations ........................................15
10. IANA Considerations ...........................................15
10.1. Sub-TLVs of the Link TLV .................................15
10.2. Sub-TLVs of the Node Attribute TLV .......................16
10.3. Sub-TLVs of the Router Address TLV .......................16
11. Management Considerations .....................................17
11.1. Routing Area (RA) Isolation ..............................17
11.2. Routing Area (RA) Topology/Configuration Changes .........17
12. Comparison to Requirements in RFC 4258 ........................17
13. References ....................................................25
13.1. Normative References .....................................25
13.2. Informative References ...................................25
14. Acknowledgements ..............................................26
14.1. RFC 5787 Acknowledgements ................................26
Appendix A. ASON Terminology ......................................27
Appendix B. ASON Routing Terminology ..............................28
Appendix C. Changes from RFC 5787 .................................29
The Generalized Multiprotocol Label Switching (GMPLS) [RFC3945] protocol suite is designed to provide a control plane for a range of network technologies. These include optical networks such as time division multiplexing (TDM) networks including SONET/SDH, Optical Transport Networks (OTNs), and lambda switching optical networks.
Generalized Multiprotocol Label Switching（GMPLS）[RFC3945]プロトコルスイートは、さまざまなネットワークテクノロジーにコントロールプレーンを提供するように設計されています。これらには、SONET / SDH、光トランスポートネットワーク（OTN）、ラムダスイッチング光ネットワークなどの時分割多重（TDM）ネットワークなどの光ネットワークが含まれます。
The ITU-T defines the architecture of the Automatically Switched Optical Network (ASON) in [G.8080].
ITU-Tは、[G.8080]で自動切り替え光ネットワーク（ASON）のアーキテクチャを定義しています。
[RFC4258] describes 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 describes 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 describes 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 described in Section 5.2, technology-specific traffic engineering attributes and their processing may be defined in other documents that complement this document.
このドキュメントは、[RFC3630]、[RFC4202]、および[RFC4203]で定義され、このドキュメントで拡張された一般的な（技術に依存しない）リンク属性の処理について説明します。セクション5.2で説明されているように、テクノロジー固有のトラフィックエンジニアリング属性とその処理は、このドキュメントを補完する他のドキュメントで定義される場合があります。
Note that this work is scoped to the requirements and evaluation expressed in [RFC4258] and [RFC4652] and the ITU-T Recommendations that were current when those documents were written. Future extensions or 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]の改訂に導入された場合、この作業の将来の拡張または改訂が必要になることがあります。
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 described 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 transport plane, and its identifier is used within the control plane as the representation of this partition.
ASONルーティングエリア（RA）はトランスポートプレーンのパーティションを表し、その識別子はコントロールプレーン内でこのパーティションの表現として使用されます。
RAs are hierarchically contained: a higher-level (parent) RA contains lower-level (child) RAs that in turn MAY also contain RAs. Thus, RAs contain RAs that recursively define successive hierarchical RA levels. Routing information may be exchanged between levels of the RA hierarchy, i.e., Level N+1 and N, where Level N represents the RAs contained by Level N+1. The links connecting RAs may be viewed as external links (inter-RA links), and the links representing connectivity within an RA may be viewed as internal links (intra-RA links). The external links to an RA at one level of the hierarchy may be internal links in the parent RA. Intra-RA links of a child RA MAY be hidden from the parent RA's view [RFC4258].
RAは階層的に含まれています。上位レベル（親）RAには下位レベル（子）RAが含まれ、RAも含まれる場合があります。したがって、RAには、連続した階層RAレベルを再帰的に定義するRAが含まれます。ルーティング情報は、ＲＡ階層のレベル、すなわち、レベルＮ ＋ １とＮの間で交換されてもよく、ここで、レベルＮは、レベルＮ ＋ １に含まれるＲＡを表す。 RAを接続するリンクは外部リンク（RA間リンク）として表示され、RA内の接続を表すリンクは内部リンク（RA内リンク）として表示されます。階層の1つのレベルにあるRAへの外部リンクは、親RAの内部リンクである場合があります。子RAのRA内リンクは、親RAのビューから非表示にすることができます[RFC4258]。
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 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 7) involves the export and import of routing information between protocol instances.
ASON RAはOSPFエリアにマップできますが、ASON RAレベルの階層はOSPFエリアの階層にマップされません。代わりに、RAの連続した階層レベルは、プロトコルの個別のインスタンスによって表されなければなりません（MUST）。したがって、レベル間のルーティング情報交換（セクション7で説明）には、プロトコルインスタンス間のルーティング情報のエクスポートとインポートが含まれます。
An ASON RA may therefore be identified by the combination of its OSPF Instance ID and its OSPF Area ID. With proper and careful network-wide configuration, this can be achieved using just the OSPF Area ID, and this process is RECOMMENDED in this document. These concepts are discussed in Section 7.
したがって、ASON RAは、そのOSPFインスタンスIDとそのOSPFエリアIDの組み合わせによって識別できます。ネットワーク全体に適切かつ注意深く構成すると、OSPFエリアIDだけを使用してこれを実現できます。このドキュメントでは、このプロセスを推奨しています。これらの概念については、セクション7で説明します。
A key ASON requirement is the support of multiple transport planes or layers. Each transport node has associated topology (links and reachability), which is used for ASON routing.
ASONの重要な要件は、複数のトランスポートプレーンまたはレイヤーのサポートです。各トランスポートノードには、ASONルーティングに使用される関連付けられたトポロジ（リンクと到達可能性）があります。
This section describes the mapping of key ASON entities to OSPF entities. Appendix A contains a complete glossary of ASON routing terminology.
このセクションでは、主要なASONエンティティのOSPFエンティティへのマッピングについて説明します。付録Aには、ASONルーティング用語の完全な用語集が含まれています。
There are three categories of identifiers used for ASON routing (G.7715.1): transport-plane names, control-plane identifiers for components, and Signaling Communications Network (SCN) addresses. This section discusses the mapping between ASON routing identifiers and corresponding identifiers defined for GMPLS routing and how these support the physical (or logical) separation of transport-plane entities and control-plane components. GMPLS supports this separation of identifiers and planes.
ASONルーティング（G.7715.1）に使用される識別子には、トランスポートプレーン名、コンポーネントのコントロールプレーン識別子、およびSignaling Communications Network（SCN）アドレスの3つのカテゴリがあります。このセクションでは、ASONルーティング識別子とGMPLSルーティング用に定義された対応する識別子の間のマッピングと、これらがトランスポートプレーンエンティティとコントロールプレーンコンポーネントの物理的（または論理的）分離をどのようにサポートするかについて説明します。 GMPLSは、識別子とプレーンのこの分離をサポートしています。
In the context of OSPF Traffic Engineering (TE), an ASON transport node corresponds to a unique OSPF TE node. An OSPF TE node is uniquely identified by the TE Router Address TLV [RFC3630]. In this document, the TE Router Address is referred to as the TE Router ID. In GMPLS, TE router addresses are advertised as reachable in both the control and transport planes, see Section 4 below. Furthermore, the TE Router ID should not be confused with the OSPF Router ID that uniquely identifies an OSPF router within an OSPF routing domain [RFC2328] and is in a name space for control-plane components.
OSPFトラフィックエンジニアリング（TE）のコンテキストでは、ASONトランスポートノードは一意のOSPF TEノードに対応します。 OSPF TEノードは、TEルータアドレスTLV [RFC3630]によって一意に識別されます。このドキュメントでは、TEルータアドレスをTEルータIDと呼びます。 GMPLSでは、TEルーターアドレスは、コントロールプレーンとトランスポートプレーンの両方で到達可能としてアドバタイズされます。以下のセクション4を参照してください。さらに、TEルーターIDは、OSPFルーティングドメイン[RFC2328]内のOSPFルーターを一意に識別し、コントロールプレーンコンポーネントの名前空間にあるOSPFルーターIDと混同しないでください。
The Router Address top-level TLV definition, processing, and usage are largely unchanged from [RFC3630]. This TLV specifies a stable OSPF TE node IP address, i.e., the IP address is always reachable when there is IP connectivity to the associated OSPF TE node.
ルーターアドレスのトップレベルのTLV定義、処理、および使用法は、[RFC3630]からほとんど変更されていません。このTLVは、安定したOSPF TEノードIPアドレスを指定します。つまり、関連付けられたOSPF TEノードへのIP接続がある場合、IPアドレスは常に到達可能です。
ASON defines a Routing Controller (RC) as an entity that handles (abstract) information needed for routing and the routing information exchange with peering RCs by operating on the Routing Database (RDB). ASON defines a Protocol Controller (PC) as an entity that 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 [RFC4258]. In this document, an OSPF router advertising ASON TE topology information will perform both the functions of the RC and PC. The OSPF routing domain comprises the control plane, and each OSPF router is uniquely identified by its OSPF Router ID [RFC2328].
ASONでは、ルーティングコントローラー（RC）を、ルーティングに必要な情報（ルーティング）と、ルーティングデータベース（RDB）を操作してピアリングRCとのルーティング情報交換を処理する（抽象的な）エンティティとして定義しています。 ASONは、プロトコルコントローラー（PC）を、情報が交換される参照ポイント（E-NNI、I-NNIなど）およびRCとの内部交換（RFC4258）に従ってプロトコル固有のメッセージ交換を処理するエンティティとして定義します。このドキュメントでは、ASON TEトポロジー情報をアドバタイズするOSPFルーターが、RCとPCの両方の機能を実行します。 OSPFルーティングドメインはコントロールプレーンを構成し、各OSPFルーターはそのOSPFルーターID [RFC2328]によって一意に識別されます。
In ASON, reachability information describes the set of endpoints that are reachable by the associated node in the transport plane. Reachability information represents transport-plane resources, e.g., an optical cross-connect interface, and uses transport-plane identifiers.
ASONでは、到達可能性情報は、トランスポートプレーン内の関連ノードが到達可能なエンドポイントのセットを記述します。到達可能性情報は、トランスポートプレーンリソース（光クロスコネクトインターフェイスなど）を表し、トランスポートプレーン識別子を使用します。
In order to advertise blocks of reachable address prefixes, a summarization mechanism is introduced that is based on the techniques described in [RFC5786]. For ASON reachability advertisement, blocks of reachable address prefixes are advertised together with the associated transport-plane node. The transport-plane node is identified in OSPF TE Link State Advertisements (LSAs) by its TE Router ID, as discussed in Section 6.
到達可能なアドレスプレフィックスのブロックをアドバタイズするために、[RFC5786]で説明されている手法に基づく要約メカニズムが導入されています。 ASON到達可能性アドバタイズメントの場合、到達可能なアドレスプレフィックスのブロックは、関連するトランスポートプレーンノードとともにアドバタイズされます。セクション6で説明されているように、トランスポートプレーンノードは、TEルータIDによってOSPF TEリンクステートアドバタイズメント（LSA）で識別されます。
In order to support ASON reachability advertisement, the Node Attribute TLV defined in [RFC5786] is used to advertise the combination of a TE Router ID and its set of associated reachable address prefixes. The Node Attribute TLV can contain the following sub-TLVs:
ASON到達可能性アドバタイズメントをサポートするために、[RFC5786]で定義されているノード属性TLVを使用して、TEルーターIDとその関連する到達可能アドレスプレフィックスのセットの組み合わせをアドバタイズします。ノード属性TLVには、次のサブTLVを含めることができます。
- Local TE Router ID sub-TLV: Length: 4; Defined in Section 6.2 - Node IPv4 Local Address sub-TLV: Length: variable; [RFC5786] - Node IPv6 Local Address sub-TLV: Length: variable; [RFC5786]
- ローカルTEルータIDサブTLV：長さ：4;セクション6.2で定義-ノードIPv4ローカルアドレスサブTLV：長さ：変数。 [RFC5786]-ノードIPv6ローカルアドレスサブTLV：長さ：変数。 [RFC5786]
A router may support multiple transport nodes as discussed in Section 6 and, as a result, may be required to advertise reachability separately for each transport node. As a consequence, it MUST be possible for the router to originate more than one TE LSA containing the Node Attribute TLV when used for ASON reachability advertisement.
ルーターは、セクション6で説明したように複数のトランスポートノードをサポートしている可能性があり、その結果、各トランスポートノードに対して個別に到達可能性をアドバタイズする必要があります。結果として、ASON到達可能性アドバタイズメントに使用する場合、ルーターがノード属性TLVを含む複数のTE LSAを発信できるようにする必要があります。
Hence, the Node Attribute TLV [RFC5786] advertisement rules are relaxed. A Node Attribute TLV MAY appear in more than one TE LSA originated by the RC when the RC is advertising reachability information for a different transport node identified by the Local TE Router sub-TLV (refer to Section 6.2).
したがって、ノード属性TLV [RFC5786]のアドバタイズメントルールは緩和されます。ノード属性TLVは、RCがローカルTEルーターサブTLV（セクション6.2を参照）によって識別される別のトランスポートノードの到達可能性情報をアドバタイズしているときに、RCが発信した複数のTE LSAに表示される場合があります。
As specified in [RFC3630], TE-advertised router addresses are also advertised as reachable in the control plane and are therefore also valid identifiers in the ASON SCN name space.
[RFC3630]で指定されているように、TEアドバタイズされたルーターアドレスは、コントロールプレーンで到達可能であるとアドバタイズされるため、ASON SCN名前空間で有効な識別子でもあります。
With the exception of local adaptation (described below), the mapping of link attributes and characteristics to OSPF TE Link TLV sub-TLVs is unchanged [RFC4652]. OSPF TE Link TLV sub-TLVs are described in [RFC3630] and [RFC4203]. Advertisement of this information SHOULD be supported on a per-layer basis, i.e., one TE LSA per unique switching capability and bandwidth granularity combination.
ローカル適応（下記で説明）を除いて、リンク属性と特性のOSPF TEリンクTLVサブTLVへのマッピングは変更されていません[RFC4652]。 OSPF TEリンクTLVサブTLVは、[RFC3630]および[RFC4203]で説明されています。この情報のアドバタイズは、レイヤごとにサポートされる必要があります。つまり、一意のスイッチング機能と帯域幅の粒度の組み合わせごとに1つの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. When advertising link adaptation, it also identifies 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 advertised with the adaptation capability.
Interface Switching Capability Descriptor（ISCD）TE属性[RFC4202]は、TEリンクが同じレイヤー内の別のリンクへの相互接続をサポートする機能を識別します。リンク適応をアドバタイズするとき、ある層に属するローカルで終端された接続を別の層のデータリンクとして使用する機能（適応機能）も識別します。ただし、その層内の接続を終了する機能（終了機能と呼ばれる）に関連する情報は、適応機能で通知されます。
For instance, a link between two optical cross-connects will contain at least one ISCD attribute describing the Lambda Switching Capable (LSC) switching capability. Conversely, a link between an optical cross-connect and an IP/MPLS Label Switching Router (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つの光クロスコネクト間のリンクには、ラムダスイッチング機能（LSC）スイッチング機能を説明する少なくとも1つのISCD属性が含まれます。逆に、光クロスコネクトとIP / MPLSラベルスイッチングルーター（LSR）間のリンクには、少なくとも2つのISCD属性が含まれます。1つはLSC終端機能の説明用で、もう1つはパケットスイッチング機能（PSC）適応機能用です。 。
In OSPFv2, the Interface Switching Capability Descriptor (ISCD) is a sub-TLV (type 15) of the top-level Link TLV (type 2) [RFC4203]. The adaptation and termination capabilities are advertised using two separate ISCD sub-TLVs within the same top-level Link TLV.
OSPFv2では、Interface Switching Capability Descriptor（ISCD）は、トップレベルのリンクTLV（タイプ2）[RFC4203]のサブTLV（タイプ15）です。適応および終端機能は、同じトップレベルのリンクTLV内の2つの別個のISCDサブTLVを使用してアドバタイズされます。
An interface MAY have more than one ISCD sub-TLV, per [RFC4202] and [RFC4203]. Hence, the corresponding advertisements should not result in any compatibility issues.
[RFC4202]および[RFC4203]ごとに、インターフェイスに複数のISCDサブTLVが存在する場合があります。したがって、対応する広告によって互換性の問題が発生することはありません。
GMPLS routing defines an ISCD that provides, among other things, the quantities of the maximum/minimum available bandwidth per priority for Label Switched Paths (LSPs). One or more ISCD sub-TLVs can be associated with an interface, per [RFC4202] and [RFC4203]. This information, combined with the Unreserved Bandwidth Link TLV sub-TLV [RFC3630], provides the basis for bandwidth accounting.
GMPLSルーティングは、とりわけ、ラベルスイッチドパス（LSP）の優先度ごとに利用可能な最大/最小帯域幅の量を提供するISCDを定義します。 [RFC4202]および[RFC4203]に従って、1つ以上のISCDサブTLVをインターフェイスに関連付けることができます。この情報は、予約されていない帯域幅リンクTLVサブTLV [RFC3630]と組み合わせて、帯域幅アカウンティングの基礎を提供します。
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]ですでに定義されている以上の追加情報は必要ありません。
For ASON routing, the control-plane component routing adjacency topology (i.e., the associated Protocol Controller (PC) connectivity) and the transport topology are not assumed to be congruent [RFC4258]. Hence, a single OSPF router (i.e., the PC) MUST be able to advertise on behalf of multiple transport-layer nodes. The OSPF routers are identified by OSPF Router ID, and the transport nodes are identified by TE Router ID.
ASONルーティングの場合、コントロールプレーンコンポーネントのルーティング隣接トポロジ（つまり、関連するプロトコルコントローラー（PC）接続）とトランスポートトポロジは一致するとは見なされません[RFC4258]。したがって、単一のOSPFルーター（つまり、PC）は、複数のトランスポート層ノードの代わりにアドバタイズできなければなりません（MUST）。 OSPFルーターはOSPFルーターIDで識別され、トランスポートノードはTEルーターIDで識別されます。
The Router Address TLV [RFC3630] is used to advertise the TE Router ID associated with the advertising Routing Controller (RC). TE Router IDs for additional transport nodes are advertised through specification of the Local TE Router Identifier in the Local and Remote TE Router TE sub-TLV and the Local TE Router Identifier sub-TLV described in the sections below. These Local TE Router Identifiers are typically used as the local endpoints for TE LSPs terminating on the associated transport node.
ルータアドレスTLV [RFC3630]は、アドバタイジングルーティングコントローラ（RC）に関連付けられたTEルータIDをアドバタイズするために使用されます。追加のトランスポートノードのTEルーターIDは、以下のセクションで説明するローカルおよびリモートTEルーターTEサブTLVおよびローカルTEルーターIDサブTLVのローカルTEルーターIDの指定によってアドバタイズされます。これらのローカルTEルーター識別子は、通常、関連するトランスポートノードで終了するTE LSPのローカルエンドポイントとして使用されます。
The use of multiple OSPF Routers to advertise TE information for the same transport node is not considered a required use case and is not discussed further in this document.
複数のOSPFルーターを使用して同じトランスポートノードのTE情報をアドバタイズすることは、必須のユースケースとは見なされず、このドキュメントではこれ以上説明しません。
When an OSPF Router advertises on behalf of multiple transport nodes, the link endpoints cannot be automatically assigned to a single transport node associated with the advertising router. In this case, the local and remote transport nodes MUST be identified by TE Router ID to unambiguously specify the transport topology.
OSPFルーターが複数のトランスポートノードに代わってアドバタイズする場合、リンクエンドポイントは、アドバタイズルーターに関連付けられている単一のトランスポートノードに自動的に割り当てることができません。この場合、ローカルおよびリモートのトランスポートノードは、トランスポートトポロジを明確に指定するために、TEルーターIDで識別される必要があります。
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 the value 10 (see Section 10). 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 MUST NOT be set to 0.
ローカルおよびリモートTEルータIDサブTLVのタイプフィールドには、値10が割り当てられています（セクション10を参照）。長さフィールドの値は8です。このサブTLVの値フィールドには、ローカルTEルータ識別子の4オクテットと、それに続くリモートTEルータ識別子の4オクテットが含まれています。ローカルおよびリモートTEルーターIDの値を0に設定してはなりません（MUST NOT）。
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 (10) | Length (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local TE Router Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote TE Router Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This sub-TLV MUST be included as a sub-TLV of the top-level Link TLV if the OSPF router is advertising on behalf of one or more transport nodes having TE Router IDs different from the TE Router ID advertised in the Router Address TLV. For consistency, this sub-TLV MUST be included when OSPF is used for the advertisement of ASON information as described herein. If it is not included in a Link TLV, or if a value of 0 is specified for the Local or Remote TE Router Identifier, the Link TLV will not be used for transport-plane path computation. Additionally, the condition SHOULD be logged for possible action by the network operator.
OSPFアドレスが、ルーターアドレスTLVでアドバタイズされたTEルーターIDとは異なるTEルーターIDを持つ1つ以上のトランスポートノードに代わってアドバタイズしている場合、このサブTLVはトップレベルのリンクTLVのサブTLVとして含まれている必要があります。一貫性を保つために、ここで説明するように、OSPFがASON情報のアドバタイズに使用される場合、このサブTLVを含める必要があります。リンクTLVに含まれていない場合、またはローカルまたはリモートTEルーター識別子に0の値が指定されている場合、リンクTLVはトランスポートプレーンパスの計算に使用されません。さらに、ネットワークオペレーターによる可能なアクションのために、条件をログに記録する必要があります。
Note: The Link ID sub-TLV identifies the other end of the link (i.e., Router ID of the neighbor for point-to-point links) [RFC3630]. When the Local and Remote TE Router ID sub-TLV is present, it MUST be used to identify local and remote transport node endpoints for the link and the Link-ID sub-TLV MUST be ignored. In fact, when the Local and Remote TE Router ID sub-TLV is specified, the Link-ID sub-TLV MAY be omitted. The Local and Remote TE Router ID sub-TLV, if specified, MUST only be specified once. If specified more than once, instances other than the first will be ignored and the condition SHOULD be logged for possible action by the network operator.
注：リンクIDサブTLVは、リンクのもう一方の端（つまり、ポイントツーポイントリンクのネイバーのルーターID）を識別します[RFC3630]。ローカルおよびリモートTEルーターIDサブTLVが存在する場合、それを使用して、リンクのローカルおよびリモートトランスポートノードエンドポイントを識別しなければならず、リンクIDサブTLVは無視されなければなりません（MUST）。実際、ローカルおよびリモートTEルータIDサブTLVが指定されている場合、リンクIDサブTLVは省略される場合があります。ローカルおよびリモートTEルーターIDサブTLVが指定されている場合は、1回だけ指定する必要があります。 2回以上指定した場合、最初のインスタンス以外のインスタンスは無視され、ネットワークオペレーターによる可能なアクションのために条件をログに記録する必要があります（SHOULD）。
When an OSPF router is advertising on behalf of multiple transport nodes, the routing protocol MUST be able to associate the advertised reachability information with the correct transport node.
OSPFルーターが複数のトランスポートノードの代わりにアドバタイズしている場合、ルーティングプロトコルは、アドバタイズされた到達可能性情報を正しいトランスポートノードに関連付けることができる必要があります。
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 transport node identified by the TE Router ID.
この目的のために、OSPFv2 TE LSAトップレベルノード属性TLVの新しいサブTLVが導入されています。このTLVは、ローカルプレフィックス（上記を参照）を、TEルーターIDで識別される特定のトランスポートノードに関連付けます。
The Type field of the Local TE Router ID sub-TLV is assigned the value 5 (see Section 10). The Length field takes the value 4. The Value field of this sub-TLV contains the Local TE Router Identifier encoded over 4 octets.
ローカルTEルータIDサブTLVのタイプフィールドには、値5が割り当てられています（セクション10を参照）。長さフィールドの値は4です。このサブTLVの値フィールドには、4オクテットでエンコードされたローカルTEルータ識別子が含まれています。
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 (5) | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local TE Router Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This sub-TLV MUST be included as a sub-TLV of the top-level Node Attribute TLV if the OSPF router is advertising on behalf of one or more transport nodes having TE Router IDs different from the TE Router ID advertised in the Router Address TLV. For consistency, this sub-TLV MUST be included when OSPF is used for the advertisement of ASON information as described herein. If it is not included in a Node Attribute TLV, or if a value of 0 is specified for the Local TE Router Identifier, the Note Attribute TLV will not be used for determining ASON SCN reachability. Additionally, the condition SHOULD be logged for possible action by the network operator.
OSPFルーターが、ルーターアドレスTLVでアドバタイズされたTEルーターIDとは異なるTEルーターIDを持つ1つ以上のトランスポートノードに代わってアドバタイズしている場合、このサブTLVはトップレベルのノード属性TLVのサブTLVとして含める必要があります。一貫性を保つために、ここで説明するように、OSPFがASON情報のアドバタイズに使用される場合、このサブTLVを含める必要があります。ノード属性TLVに含まれていない場合、またはローカルTEルーター識別子に値0が指定されている場合、ノート属性TLVはASON SCN到達可能性の決定に使用されません。さらに、ネットワークオペレーターによる可能なアクションのために、条件をログに記録する必要があります。
An ASON routing area (RA) represents a partition of the transport 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. ASON RA levels do not map directly to OSPF areas. Rather, hierarchical levels of RAs are represented by separate OSPF protocol instances. However, it is useful to align the RA IDs and area ID in order to facilitate isolation of RAs as described in Section 11.1.
ASONルーティングエリア（RA）はトランスポートプレーンのパーティションを表し、その識別子はコントロールプレーン内でこのパーティションの表現として使用されます。 RAには、リンクで相互接続された小さなRAが含まれる場合があります。 ASON RAレベルは、OSPFエリアに直接マップされません。むしろ、RAの階層レベルは、別個のOSPFプロトコルインスタンスによって表されます。ただし、セクション11.1で説明されているように、RAの分離を容易にするために、RA IDとエリアIDを揃えることは有用です。
Routing Controllers (RCs) supporting multiple RAs disseminate information downward and upward in this ASON hierarchy. The vertical routing information dissemination mechanisms described in this section do not introduce or imply hierarchical OSPF areas. RCs supporting RAs at multiple levels are structured as separate OSPF instances with routing information exchange between levels described by import and export rules between these instances. The functionality described herein does not pertain to OSPF areas or OSPF Area Border Router (ABR) functionality.
複数のRAをサポートするルーティングコントローラー（RC）は、このASON階層で下方および上方に情報を配信します。このセクションで説明する垂直ルーティング情報配信メカニズムは、階層型OSPFエリアを導入したり、示唆したりするものではありません。複数のレベルでRAをサポートするRCは、これらのインスタンス間のインポートおよびエクスポートルールによって記述されたレベル間でルーティング情報を交換する個別のOSPFインスタンスとして構成されます。ここで説明する機能は、OSPFエリアまたはOSPFエリア境界ルーター（ABR）機能には関係しません。
RCs supporting RAs disseminate information upward and downward in the hierarchy by importing/exporting routing information as TE LSAs. TE LSAs are area-scoped Opaque LSAs with Opaque type 1 [RFC3630]. The information that MAY be exchanged between adjacent levels includes the Router Address, Link, and Node Attribute top-level TLVs.
RAをサポートするRCは、ルーティング情報をTE LSAとしてインポート/エクスポートすることにより、情報を階層内で上下に配布します。 TE LSAは、エリアタイプのOpaqueタイプ1のOpaque LSA [RFC3630]です。隣接するレベル間で交換できる情報には、ルーターアドレス、リンク、ノード属性のトップレベルのTLVが含まれます。
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 are 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 4) and, upon strict policy control, link topology information.
実際には、スケーラビリティと処理のオーバーヘッドを回避するために、階層内で下向き/上向きにインポート/エクスポートされたルーティング情報には、到達可能性情報（セクション4を参照）が含まれ、厳密なポリシー制御に基づいて、トポロジ情報がリンクされます。
When more than one RC is bound to an adjacent level of the ASON hierarchy and is configured to export routing information upward or downward, a specific mechanism is required to avoid looping of routing information. Looping is the re-advertisement of routing information into an RA that had previously advertised that routing information upward or downward into an upper or lower level RA in the ASON hierarchy. For example, without loop-prevention mechanisms, this could happen when the RC advertising routing information downward in the hierarchy is not the same one that advertises routing information upward in the hierarchy.
複数のRCがASON階層の隣接レベルにバインドされており、ルーティング情報を上方または下方にエクスポートするように構成されている場合、ルーティング情報のループを回避するために特定のメカニズムが必要です。ループとは、以前にそのルーティング情報を上方または下方にASON階層の上位または下位レベルのRAにアドバタイズしたRAにルーティング情報を再アドバタイズすることです。たとえば、ループ防止メカニズムがない場合、これは、階層の下位にルーティング情報をアドバタイズするRCが、階層の上位にルーティング情報をアドバタイズするRCと同じでない場合に発生する可能性があります。
The Inter-RA Export sub-TLVs can be used to prevent the re-advertisement of OSPF TE routing information into an RA that previously advertised that information. The type value 13 (see Section 10) will indicate that the associated routing information has been exported downward. The type value 12 (see Section 10) will indicate that the associated routing information has been exported upward. While it is not required for routing information exported downward, both sub-TLVs will include the Routing Area (RA) ID from which the routing information was exported. This RA is not necessarily the RA originating the routing information but the RA from which the information was immediately exported.
Inter-RA ExportサブTLVを使用して、以前にその情報をアドバタイズしたRAへのOSPF TEルーティング情報の再アドバタイズを防止できます。タイプ値13（セクション10を参照）は、関連するルーティング情報が下方にエクスポートされたことを示します。タイプ値12（セクション10を参照）は、関連するルーティング情報が上方にエクスポートされたことを示します。下方にエクスポートされるルーティング情報には必要ありませんが、両方のサブTLVには、ルーティング情報がエクスポートされたルーティングエリア（RA）IDが含まれます。このRAは必ずしもルーティング情報を発信しているRAではなく、情報がすぐにエクスポートされたRAです。
These additional sub-TLVs MAY be included in TE LSAs that include any of the following top-level TLVs:
これらの追加のサブTLVは、次のトップレベルTLVのいずれかを含むTE LSAに含まれる場合があります。
- Router Address top-level TLV - Link top-level TLV - Node Attribute top-level TLV
- ルーターアドレストップレベルTLV-リンクトップレベルTLV-ノード属性トップレベルTLV
The Type field of the Inter-RA Export Upward and Inter-RA Export Downward sub-TLVs are respectively assigned the values 12 and 13 (see Section 10). The Length field in these sub-TLVs takes the value 4. The Value field in these sub-TLVs contains the associated RA ID. The RA ID value must be a unique identifier for the RA within the ASON routing domain.
Inter-RA Export UpwardおよびInter-RA Export DownwardサブTLVのTypeフィールドには、それぞれ値12および13が割り当てられています（セクション10を参照）。これらのサブTLVの長さフィールドの値は4です。これらのサブTLVの値フィールドには、関連するRA IDが含まれています。 RA ID値は、ASONルーティングドメイン内のRAの一意の識別子である必要があります。
The format of the Inter-RA Export Upward and Inter-RA Export Downward sub-TLVs is graphically depicted below:
Inter-RA Export UpwardおよびInter-RA Export Downwardサブ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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upward/Downward Type | Length (4) |
| (12/13) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated RA ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TE LSAs MAY be imported or exported downward or upward in the ASON routing hierarchy. The direction and advertising RA ID are advertised in an Inter-RA Export Upward/Downward sub-TLV. They MUST be retained and advertised in the receiving RA with the associated routing information.
TE LSAは、ASONルーティング階層で下向きまたは上向きにインポートまたはエクスポートできます。方向とアドバタイズRA IDは、RA間エクスポートの上位/下位サブTLVでアドバタイズされます。それらは保持され、関連するルーティング情報とともに受信側RAでアドバタイズされなければなりません（MUST）。
When exporting routing information upward in the ASON routing hierarchy, any information received from a level above, i.e., tagged with an Inter-RA Export Downward sub-TLV, MUST NOT be exported upward. Since an RA at Level N is contained by a single RA at Level N+1, this is the only checking that is necessary and the associated RA ID is used solely for informational purposes.
ルーティング情報をASONルーティング階層で上向きにエクスポートする場合、上位レベルから受信した情報、つまり、RA間エクスポート下向きサブTLVでタグ付けされた情報は、上向きにエクスポートしてはなりません。レベルNのRAはレベルN + 1の単一のRAに含まれるため、これが必要な唯一のチェックであり、関連するRA IDは情報提供のみを目的として使用されます。
When exporting routing information downward in the ASON routing hierarchy, any information received from a level below, i.e., tagged with an Inter-RA Export Upward sub-TLV, MUST NOT be exported downward if the target RA ID matches the RA ID associated with the routing information. This additional checking is required for routing information exported downward since a single RA at Level N+1 may contain multiple RAs at Level N in the ASON routing hierarchy. In other words, routing information MUST NOT be exported downward into the RA from which it was received.
ASONルーティング階層でルーティング情報を下向きにエクスポートする場合、下位レベルから受信した情報、つまりRA間エクスポート上向きサブTLVでタグ付けされた情報は、ターゲットRA IDがルーティング情報。レベルN + 1の単一のRAはASONルーティング階層のレベルNの複数のRAを含む可能性があるため、この追加のチェックは、ルーティング情報を下方にエクスポートするために必要です。言い換えると、ルーティング情報は、それを受信したRAに下向きにエクスポートしてはならない（MUST NOT）。
The extensions described herein are only applicable to ASON routing domains, and it is not expected that the attendant reachability (see Section 4) and link information will ever be combined with global Internet or Layer 3 Virtual Private Network (VPN) routing. If there were ever a requirement for a given RC to participate in both domains, separate OSPFv2 instances would be utilized. However, in a multi-level ASON hierarchy, the potential volume of information could be quite large and the recommendations in this section MUST be followed by RCs implementing this specification.
ここで説明する拡張機能はASONルーティングドメインにのみ適用され、アテンダントの到達可能性（セクション4を参照）およびリンク情報がグローバルインターネットまたはレイヤー3仮想プライベートネットワーク（VPN）ルーティングと組み合わせられることは想定されていません。特定のRCが両方のドメインに参加する必要がある場合、別個のOSPFv2インスタンスが使用されます。ただし、マルチレベルのASON階層では、潜在的な情報量が非常に大きくなる可能性があり、このセクションの推奨事項の後に、この仕様を実装するRCが続く必要があります。
- Routing information exchange upward/downward in the hierarchy between adjacent RAs MUST, by default, be limited to reachability information. In addition, several transformations such as prefix aggregation are RECOMMENDED to reduce the amount of information imported/exported by a given RC when such transformations will not impact consistency.
- 隣接するRA間の階層内で上下にルーティング情報を交換する場合、デフォルトでは、到達可能性情報に限定する必要があります。さらに、プレフィックス集約などのいくつかの変換は、そのような変換が一貫性に影響を与えない場合に、特定のRCによってインポート/エクスポートされる情報の量を減らすために推奨されます。
- Routing information exchange upward/downward in the ASON hierarchy involving TE attributes MUST be under strict policy control. Pacing and min/max thresholds for triggered updates are strongly RECOMMENDED.
- TE属性を含むASON階層内の上方/下方へのルーティング情報交換は、厳密なポリシー制御下にある必要があります。トリガーされた更新のペーシングおよび最小/最大しきい値は強く推奨されます。
- The number of routing levels MUST be maintained under strict policy control.
- ルーティングレベルの数は、厳密なポリシー制御の下で維持する必要があります。
This document specifies the contents and processing of OSPFv2 TE LSAs [RFC3630] and [RFC4202]. The TE LSA extensions defined in this document are not used for Shortest Path First (SPF) computation and have no direct effect on IP routing. Additionally, ASON routing domains are delimited by the usual administrative domain boundaries.
このドキュメントでは、OSPFv2 TE LSA [RFC3630]および[RFC4202]の内容と処理について説明しています。このドキュメントで定義されているTE LSA拡張機能は、SPF（Shortest Path First）計算には使用されず、IPルーティングには直接影響しません。さらに、ASONルーティングドメインは通常の管理ドメイン境界によって区切られます。
Any mechanisms used for securing the exchange of normal OSPF LSAs can be applied equally to all TE LSAs used in the ASON context. Authentication of OSPFv2 LSA exchanges (such as OSPF cryptographic authentication [RFC2328] [RFC5709]) can be used to provide significant protection against active attacks. [RFC5709] defines a mechanism for authenticating OSPFv2 packets by making use of the Hashed Message Authentication Code (HMAC) algorithm in conjunction with the SHA family of cryptographic hash functions.
通常のOSPF LSAの交換を保護するために使用されるメカニズムは、ASONコンテキストで使用されるすべてのTE LSAに等しく適用できます。 OSPFv2 LSA交換の認証（OSPF暗号化認証[RFC2328] [RFC5709]など）を使用して、アクティブな攻撃に対する重要な保護を提供できます。 [RFC5709]は、ハッシュメッセージ認証コード（HMAC）アルゴリズムを暗号化ハッシュ関数のSHAファミリと組み合わせて利用することにより、OSPFv2パケットを認証するメカニズムを定義しています。
RCs implementing export/import of ASON routing information between RAs MUST also include policy control of both the maximum amount of information advertised between RAs and the maximum rate at which it is advertised. This is to isolate the consequences of an RC being compromised to the RAs to which that subverted RC is attached.
RA間でASONルーティング情報のエクスポート/インポートを実装するRCには、RA間でアドバタイズされる情報の最大量とそれがアドバタイズされる最大レートの両方のポリシー制御も含める必要があります。これは、その破壊されたRCが接続されているRAに対してRCが危害を受ける結果を分離するためです。
The "Analysis of OSPF Security According to KARP Design Guide" [OSPF-SEC] provides a comprehensive analysis of OSPFv2 and OSPFv3 security relative to the requirements specified in [RFC6518].
「KARP設計ガイドによるOSPFセキュリティの分析」[OSPF-SEC]は、[RFC6518]で指定された要件に関連するOSPFv2およびOSPFv3セキュリティの包括的な分析を提供します。
This document defines new sub-TLVs for inclusion in OSPF TE LSAs. IANA has assigned values per the assignment policies for the registries of code points for these sub-TLVs [RFC3630].
このドキュメントでは、OSPF TE LSAに含めるための新しいサブTLVを定義しています。 IANAは、これらのサブTLV [RFC3630]のコードポイントのレジストリの割り当てポリシーに従って値を割り当てています。
The following subsections summarize the required sub-TLVs.
以下のサブセクションでは、必要なサブTLVを要約しています。
This document defines the following sub-TLVs of the Link TLV advertised in the OSPF TE LSA:
このドキュメントでは、OSPF TE LSAでアドバタイズされるリンクTLVの次のサブTLVを定義しています。
- Local and Remote TE Router ID sub-TLV (10) - Inter-RA Export Upward sub-TLV (12) - Inter-RA Export Downward sub-TLV (13)
- ローカルおよびリモートTEルーターIDサブTLV（10）-RA間エクスポート上方サブTLV（12）-RA間エクスポート下方サブTLV（13）
Codepoints for these sub-TLVs have been allocated in the Standards Action range of the "Types for sub-TLVs of TE Link TLV (Value 2)" registry [RFC3630].
これらのサブTLVのコードポイントは、「TE Link TLVのサブTLVのタイプ（値2）」レジストリ[RFC3630]の標準アクション範囲に割り当てられています。
Note that the same values for the Inter-RA Export Upward sub-TLV and the Inter-RA Export Downward sub-TLV MUST be used when they appear in the Link TLV, Node Attribute TLV, and Router Address TLV.
リンクTLV、ノード属性TLV、およびルーターアドレスTLVに表示される場合、RA間上向きサブTLVとRA間下向きサブTLVに同じ値を使用する必要があることに注意してください。
This document defines the following sub-TLVs of the Node Attribute TLV advertised in the OSPF TE LSA:
このドキュメントでは、OSPF TE LSAでアドバタイズされるノード属性TLVの次のサブTLVを定義しています。
- Local TE Router ID sub-TLV (5) - Inter-RA Export Upward sub-TLV (12) - Inter-RA Export Downward sub-TLV (13)
- ローカルTEルーターIDサブTLV（5）-RA間エクスポート上方サブTLV（12）-RA間エクスポート下方サブTLV（13）
Codepoints for these sub-TLVs have been assigned in Standards Action range of the "Types for sub-TLVs of TE Node Attribute TLV (Value 5)" [RFC5786].
これらのサブTLVのコードポイントは、「TEノード属性TLVのサブTLVのタイプ（値5）」の標準アクション範囲[RFC5786]に割り当てられています。
Note that the same values for the Inter-RA Export Upward sub-TLV and the Inter-RA Export Downward sub-TLV MUST be used when they appear in the Link TLV, Node Attribute TLV, and Router Address TLV.
リンクTLV、ノード属性TLV、およびルーターアドレスTLVに表示される場合、RA間上向きサブTLVとRA間下向きサブTLVに同じ値を使用する必要があることに注意してください。
The Router Address TLV is advertised in the OSPF TE LSA [RFC3630]. Since the TLV had no sub-TLVs defined, a "Types for sub-TLVs of Router Address TLV (Value 1)" registry has been defined.
ルータアドレスTLVは、OSPF TE LSA [RFC3630]でアドバタイズされます。 TLVにはサブTLVが定義されていないため、「ルーターアドレスTLVのサブTLVのタイプ（値1）」レジストリが定義されています。
The registry guidelines for the assignment of types for sub-TLVs of the Router Address TLV are as follows:
ルータアドレスTLVのサブTLVのタイプの割り当てに関するレジストリガイドラインは次のとおりです。
o Types in the range 0-32767 are to be assigned via Standards Action.
o 0〜32767の範囲のタイプは、標準アクションによって割り当てられます。
o Type 0 in the aforementioned Standards Action range (0-32767) is reserved.
o 前述の標準アクション範囲（0〜32767）のタイプ0は予約されています。
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に登録されず、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.
o 現時点では、32778〜65535の範囲のタイプは割り当てられません。この範囲で割り当てを行う前に、割り当てられる範囲を対象とするIANAの考慮事項を指定する標準規格トラックRFCが存在する必要があります。
This document defines the following sub-TLVs for inclusion in the Router Address TLV:
このドキュメントでは、ルーターアドレスTLVに含める次のサブTLVを定義しています。
- Inter-RA Export Upward sub-TLV (12) - Inter-RA Export Downward sub-TLV (13)
- RA間エクスポート上方サブTLV（12）-RA間エクスポート下方サブTLV（13）
Codepoints for these sub-TLVs have been allocated in the Standards Action range of the "Types for sub-TLVs of Router Address TLV (Value 1)" registry.
これらのサブTLVのコードポイントは、「ルーターアドレスTLVのサブTLVのタイプ（値1）」レジストリの標準アクション範囲に割り当てられています。
Note that the same values for the Inter-RA Export Upward sub-TLV and the Inter-RA Export Downward sub-TLV MUST be used when they appear in the Link TLV, Node Attribute TLV, and Router Address TLV.
リンクTLV、ノード属性TLV、およびルーターアドレスTLVに表示される場合、RA間上向きサブTLVとRA間下向きサブTLVに同じ値を使用する必要があることに注意してください。
If the RA ID is mapped to the OSPF Area ID as recommended in Section 2, OSPF [RFC2328] implicitly provides isolation. On any intra-RA link, packets will only be accepted if the area ID in the OSPF packet header matches the area ID for the OSPF interface on which the packet was received. Hence, RCs will only establish adjacencies and exchange reachability information (see Section 4.0) with RCs in the same RA. Other mechanisms for RA isolation are beyond the scope of this document.
セクション2で推奨されているようにRA IDがOSPFエリアIDにマップされている場合、OSPF [RFC2328]は暗黙的に分離を提供します。 RA内リンクでは、OSPFパケットヘッダーのエリアIDが、パケットが受信されたOSPFインターフェイスのエリアIDと一致する場合にのみ、パケットが受け入れられます。したがって、RCは隣接関係を確立し、同じRAのRCとの到達可能性情報（セクション4.0を参照）のみを交換します。 RA分離の他のメカニズムは、このドキュメントの範囲外です。
The GMPLS Routing for ASON requirements [RFC4258] dictate that the routing protocol MUST support reconfiguration and SHOULD support architectural evolution. OSPF [RFC2328] includes support for the dynamic introduction or removal of ASON reachability information through the flooding and purging of OSPF Opaque LSAs [RFC5250]. Also, when an RA is partitioned or an RC fails, stale LSAs SHOULD NOT be used unless the advertising RC is reachable. The configuration of OSPF RAs and the policies governing the redistribution of ASON reachability information between RAs are implementation issues outside of the OSPF routing protocol and beyond the scope of this document.
GMPLS Routing for ASON要件[RFC4258]は、ルーティングプロトコルが再構成をサポートする必要があり、アーキテクチャの進化をサポートする必要があることを示しています。 OSPF [RFC2328]には、OSPF Opaque LSA [RFC5250]のフラッディングとパージによるASON到達可能性情報の動的な導入または削除のサポートが含まれています。また、RAがパーティション分割されている場合、またはRCに障害が発生した場合、アドバタイジングRCが到達可能でない限り、古いLSAを使用しないでください。 OSPF RAの設定と、RA間のASON到達可能性情報の再配布を管理するポリシーは、OSPFルーティングプロトコルの範囲外であり、このドキュメントの範囲を超える実装の問題です。
The following table shows how this document complies with the requirements in [RFC4258]. The first column contains a requirements number (1-30) and the relevant section in RFC 4258. The second column describes the requirement, the third column discusses the compliance to that requirement, and the fourth column lists the relevant section in this document and/or another RFC that already satisfies the requirement.
次の表は、このドキュメントが[RFC4258]の要件にどのように準拠するかを示しています。最初の列には、要件番号（1〜30）とRFC 4258の関連セクションが含まれています。2番目の列は要件について説明し、3番目の列はその要件への準拠について説明し、4番目の列はこのドキュメントの関連セクションと/またはまたは、すでに要件を満たしている別のRFC。
+----------+---------------------------+---------------+-------------+
| RFC 4258 | RFC 4258 Requirement | Compliance | Reference |
| Section | | | |
| (Req. | | | |
| Number) | | | |
+----------+---------------------------+---------------+-------------+
| 3 (1) | The failure of an RC, or | Implied by | Not an |
| | the failure of | separation of |attribute of |
| |communications between RCs,| transport and | routing |
| |and the subsequent recovery|control plane. | protocol. |
| |from the failure condition | | |
| | MUST NOT disrupt calls in | | |
| | progress. | | |
+----------+---------------------------+---------------+-------------+
| 3.1 (2) | Multiple Hierarchical | Yes | Sections 2 |
| | Levels of ASON Routing | | and 3. |
| | Areas (RAs). | | |
+----------+---------------------------+---------------+-------------+
| 3.1 (3) | Prior to establishing | Yes, when RA |Section 11.1.|
| | communications, RCs MUST | maps to OSPF | |
| |verify that they are bound | Area ID. | |
| | to the same parent RA. | Otherwise, | |
| | | out of scope. | |
+----------+---------------------------+---------------+-------------+
| 3.1 (4) | The RC ID MUST be unique | Yes |RFC 2328 and |
| | within its containing RA. | | Section 3. |
+----------+---------------------------+---------------+-------------+
| 3.1 (5) |Each RA within a carrier's |Yes - although | Sections 2, |
| | network SHALL be uniquely | uniqueness is | 3, and 11.1.|
| | identifiable. RA IDs MAY |the operator's | |
| | be associated with a |responsibility.| |
| |transport-plane name space,| | |
| | whereas RC IDs are | | |
| | associated with a | | |
| | control-plane name space. | | |
+----------+---------------------------+---------------+-------------+
| 3.2 (6) | Hierarchical Routing | Yes | Section 7. |
| | Information Dissemination.| | |
+----------+---------------------------+---------------+-------------+
| 3.2 (7) | Routing Information | Yes | Section 7.1.|
| |exchanged between levels N | | |
| | and N+1 via separate | | |
| | instances and | | |
| | import/export. | | |
+----------+---------------------------+---------------+-------------+
+----------+---------------------------+---------------+-------------+
| 3.2 (8) | Routing Information | No - Not | |
| |exchanged between levels N | described. | |
| | and N+1 via external link | | |
| | (inter-RA links). | | |
+----------+---------------------------+---------------+-------------+
| 3.2 (9) | Routing information | Yes | Sections 4, |
| | exchange MUST include | |6, 6.1, 6.2, |
| | reachability information | | and 8. |
| | and MAY include, upon | | |
| | policy decision, node and | | |
| | link topology. | | |
+----------+---------------------------+---------------+-------------+
| 3.2 (10) | There SHOULD NOT be any |Yes - separate | Sections 2 |
| | dependencies on the | instances. | and 3. |
| |different routing protocols| | |
| | used within an RA or in | | |
| | different RAs. | | |
+----------+---------------------------+---------------+-------------+
| 3.2 (11) |The routing protocol SHALL | Yes | Section 7.2.|
| | differentiate the routing | | |
| |information originated at a| | |
| |given-level RA from derived| | |
| | routing information | | |
| | (received from external | | |
| | RAs), even when this | | |
| |information is forwarded by| | |
| | another RC at the same | | |
| | level. | | |
+----------+---------------------------+---------------+-------------+
| 3.2 (12) | The routing protocol MUST | Yes | Section 7.2.|
| | provide a mechanism to | | |
| | prevent information | | |
| |propagated from a Level N+1| | |
| | RA's RC into the Level N | | |
| | RA's RC from being | | |
| | re-introduced into the | | |
| | Level N+1 RA's RC. | | |
+----------+---------------------------+---------------+-------------+
| 3.2 (13) | The routing protocol MUST | Yes | Section 7.2.|
| | provide a mechanism to | | |
| | prevent information | | |
| |propagated from a Level N-1| | |
| | RA's RC into the Level N | | |
| | RA's RC from being | | |
| | re-introduced into the | | |
| | Level N-1 RA's RC. | | |
+----------+---------------------------+---------------+-------------+
+----------+---------------------------+---------------+-------------+
| 3.2 (14) | Instance of a Level N | Yes | Sections 2, |
| | routing function and an | | 3, and 7. |
| | instance of a Level N+1 | | |
| | routing function in the | | |
| | same system. | | |
+----------+---------------------------+---------------+-------------+
| 3.2 (15) | The Level N routing | Not described | N/A |
| | function is on a separate | but possible. | |
| | system than the Level | | |
| | N+1 routing function. | | |
+----------+---------------------------+---------------+-------------+
| 3.3 (16) |The RC MUST support static | The automation| Sections 2 |
| | (i.e., operator assisted) | requirement is|and 3. Refer |
| | and MAY support automated | ambiguous. | to RFC 2328 |
| | configuration of the | OSPF supports | for OSPF |
| |information describing its | auto-discovery| auto- |
| |relationship to its parent | of neighbors | discovery. |
| | and its child within the | and topology. | |
| | hierarchical structure | Default and | |
| | (including RA ID and RC | automatically | |
| | ID). | configured | |
| | | polices are | |
| | | out of scope. | |
+----------+---------------------------+---------------+-------------+
| 3.3 (17) |The RC MUST support static |Yes - when OSPF|RFC 2328 and |
| | (i.e., operator assisted) |area maps to RA|Section 11.1.|
| | and MAY support automated | discovery is | |
| | configuration of the | automatic. | |
| |information describing its | | |
| | associated adjacencies to | | |
| | other RCs within an RA. | | |
+----------+---------------------------+---------------+-------------+
| 3.3 (18) |The routing protocol SHOULD| Yes | RFC 2328. |
| |support all the types of RC| | |
| | adjacencies described in | | |
| |Section 9 of [G.7715]. The | | |
| | latter includes congruent | | |
| |topology (with distributed | | |
| | RC) and hubbed topology | | |
| |(e.g., note that the latter| | |
| | does not automatically | | |
| | imply a designated RC). | | |
+----------+---------------------------+---------------+-------------+
+----------+---------------------------+---------------+-------------+
| 3.4 (19) |The routing protocol SHOULD| Yes |RFC 2328, RFC|
| | be capable of supporting | | 5250, and |
| |architectural evolution in | |Section 11.2.|
| | terms of the number of | | |
| |hierarchical levels of RAs,| | |
| |as well as the aggregation | | |
| | and segmentation of RAs. | | |
+----------+---------------------------+---------------+-------------+
|3.5.2 (20)|Advertisements MAY contain | | |
| |the following common set of| | |
| | information regardless of | | |
| | whether they are link or | | |
| | node related: | | |
| | - RA ID of the RA to | Yes | Section |
| | which the | | 7.2.1. |
| | advertisement is | | |
| | bounded | | |
| | - RC ID of the entity | Yes | RFC 2328. |
| | generating the | | |
| | advertisement | | |
| | - Information to | Yes |RFC 2328, RFC|
| | uniquely identify | | 5250. |
| | advertisements | | |
| | - Information to | No - Must | |
| | determine whether an |compare to old.| |
| | advertisement has | | |
| | been updated | | |
| | - Information to | Yes | Section |
| | indicate when an | | 7.2.1. |
| | advertisement has been| | |
| | derived from a | | |
| | different level RA. | | |
+----------+---------------------------+---------------+-------------+
+----------+---------------------------+---------------+-------------+
|3.5.3 (21)|The Node Attributes' Node |Yes - Prefixes | RFC 5786, |
| |ID and Reachability must be| only for | Sections 4 |
| | advertised. It MAY be | reachability. | and 6. |
| | advertised as a set of | | |
| |associated external (e.g., | | |
| | User Network Interface | | |
| | (UNI)) address/address | | |
| | prefixes or a set of | | |
| | associated Subnetwork | | |
| | Point Pool (SNPP) link | | |
| | IDs/SNPP ID prefixes, the | | |
| |selection of which MUST be | | |
| | consistent within the | | |
| | applicable scope. | | |
+----------+---------------------------+---------------+-------------+
|3.5.4 (22)| The Link Attributes' Local| Yes | Section 6.1.|
| | SNPP link ID, Remote SNPP | | |
| |link ID, and layer specific| | |
| | characteristics must be | | |
| | advertised. | | |
+----------+---------------------------+---------------+-------------+
|3.5.4 (23)| Link Signaling Attributes | Yes | Section 5, |
| |other than Local Adaptation| | RFC 4652 - |
| |(Signal Type, Link Weight, | | Section |
| | Resource Class, Local | | 5.3.1. |
| | Connection Types, Link | | |
| | Capacity, Link | | |
| | Availability, Diversity | | |
| | Support). | | |
+----------+---------------------------+---------------+-------------+
|3.5.4 (24)| Link Signaling Local | Yes | Section 5.1.|
| | Adaptation. | | |
+----------+---------------------------+---------------+-------------+
| 5 (25) | The routing adjacency | Yes | Sections 2, |
| | topology (i.e., the | | 3, and 6. |
| |associated PC connectivity | | |
| |topology) and the transport| | |
| |network topology SHALL NOT | | |
| |be assumed to be congruent.| | |
+----------+---------------------------+---------------+-------------+
| 5 (26) |The routing topology SHALL | Yes |RFC 2328, RFC|
| | support multiple links | | 3630. |
| | between nodes and RAs. | | |
+----------+---------------------------+---------------+-------------+
+----------+---------------------------+---------------+-------------+
| 5 (27) |The routing protocol SHALL | Yes |RFC 2328, RFC|
| | converge such that the | | 5250. |
| | distributed Routing | | |
| | Databases (RDBs) become | | |
| |synchronized after a period| | |
| | of time. | | |
+----------+---------------------------+---------------+-------------+
| 5 (28) |Self-consistent information|Yes - However, | Section 7.1.|
| | at the receiving level | this is not a | |
| | resulting from any | routing | |
| | transformation (filter, | protocol | |
| | summarize, etc.) and | function. | |
| | forwarding of information | | |
| | from one RC to RC(s) at | | |
| | different levels when | | |
| |multiple RCs are bound to a| | |
| | single RA. | | |
+----------+---------------------------+---------------+-------------+
| 5 (29) | In order to support |Partial - OSPF |RFC 2328 and |
| | operator-assisted changes | supports the | RFC 5250. |
| | in the containment | purging of | |
| | relationships of RAs, the | stale | |
| | routing protocol SHALL |advertisements | |
| |support evolution in terms |and origination| |
| | of the number of | of new. The | |
| |hierarchical levels of RAs.|non-disruptive | |
| | For example, support of | behavior is | |
| | non-disruptive operations |implementation | |
| |such as adding and removing| specific. | |
| | RAs at the top/bottom of | | |
| | the hierarchy, adding or | | |
| | removing a hierarchical | | |
| |level of RAs in or from the| | |
| |middle of the hierarchy, as| | |
| | well as aggregation and | | |
| | segmentation of RAs. | | |
+----------+---------------------------+---------------+-------------+
| 5 (30) | A collection of links and |Yes - Within an| Sections 4 |
| |nodes such as a subnetwork | RA it must be | and 6. |
| | or RA MUST be able to | consistent. | |
| | represent itself to the | | |
| | wider network as a single | | |
| | logical entity with only | | |
| |its external links visible | | |
| | to the topology database. | | |
+----------+---------------------------+---------------+-------------+
[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月。
[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 Version 2」、RFC 3630、2003年9月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] Mannie、E。、編、「Generalized Multi-Protocol Label Switching（GMPLS）Architecture」、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.、Ed。、and Y. Rekhter、Ed。、 "OSPF Extensions Support in Supported Generalized Multi-Protocol Label Switching（GMPLS）"、RFC 4203、October 2005。
[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月。
[RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions", RFC 5786, March 2010.
[RFC5786] Aggarwal、R。およびK. Kompella、「OSPFトラフィックエンジニアリング（TE）拡張でのルーターのローカルアドレスのアドバタイズ」、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。、編、「自動切り替え光ネットワーク（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.、and D. Ward、 "Evaluation of Existing Routing Protocols to Automatic Switched Optical Network（ASON）Routing Requirements"、RFC 4652、2006年10月。
[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 Cryptographic Authentication」、RFC 5709、 2009年10月。
[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines", RFC 6518, February 2012.
[RFC6518] Lebovitz、G。およびM. Bhatia、「Keying and Authentication for Routing Protocols（KARP）Design Guidelines」、RFC 6518、2012年2月。
[OSPF-SEC] Hartman, S. and Zhang, D., "Analysis of OSPF Security According to KARP Design Guide", Work in Progress, November 2012.
[OSPF-SEC] Hartman、S.およびZhang、D。、「Analysis of OSPF Security Using KARP Design Guide」、Work in Progress、2012年11月。
[G.7715] ITU-T Rec. G.7715/Y.1706, "Architecture and Requirements in the Automatically Switched Optical Network", June 2002.
[G.7715] ITU-T Rec。 G.7715 / Y.1706、「自動切り替え光ネットワークのアーキテクチャと要件」、2002年6月。
[G.7715.1] ITU-T Rec. G.7715.1/Y.1706.1, "ASON Routing Architecture and Requirements for Link State Protocols", February 2004.
[G.7715.1] ITU-T Rec。 G.7715.1 / Y.1706.1、「ASONルーティングアーキテクチャとリンクステートプロトコルの要件」、2004年2月。
[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", February 2012.
[G.8080] ITU-T Rec。 G.8080 / Y.1304、「自動切り替え光ネットワークのアーキテクチャ」、2012年2月。
The editors would like to thank Lyndon Ong, Remi Theillaud, Stephen Shew, Jonathan Sadler, Deborah Brungard, Lou Berger, and Adrian Farrel for their useful comments and suggestions.
編集者は、有益なコメントと提案を提供してくれたLyndon Ong、Remi Theillaud、Stephen Shew、Jonathan Sadler、Deborah Brungard、Lou Berger、およびAdrian Farrelに感謝します。
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 [G.7715.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]を参照。）[G.7715.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 located between protocol controllers between control domains.
外部NNI（E-NNI）：制御ドメイン間のプロトコルコントローラー間にあるインターフェイス。
Internal NNI (I-NNI): interfaces 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 Fault, Configuration, Accounting, Performance, and 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は、Trail Termination関数の出力またはTrail Termination Sink関数への入力を表します。
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 transport 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 subnetworks, 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 subnetworks 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 (LRM), Routing Controller (RC)) or protocol specific (Protocol Controller (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にアクセスするRCはルーティング情報を共有する場合があります。
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）：すべての関連コンポーネントとTEリンク情報をRCに提供します。これは、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機能はプロトコルに依存します。
This document contains the following changes from RFC 5787:
このドキュメントには、RFC 5787からの以下の変更が含まれています。
1. This document will be on the Standards Track, rather than Experimental, and reflects experience gained from RFC 5787 implementation and interoperability testing. This also required changes to the IANA Considerations.
1. このドキュメントは、Experimentalではなく、Standards Track上にあり、RFC 5787の実装と相互運用性テストから得られた経験を反映しています。これには、IANAの考慮事項の変更も必要でした。
2. There is a new Section 3 on Terminology and Identification to describe the mapping of key ASON entities to OSPF entities.
2. 重要なASONエンティティのOSPFエンティティへのマッピングを説明する用語と識別に関する新しいセクション3があります。
3. Sections were reorganized to explain terminology before defining prefix extensions.
3. 接頭辞の拡張を定義する前に、用語を説明するためにセクションが再編成されました。
4. There is a new Section 11, Management Considerations, which describes how existing OSPF mechanisms address ASON requirements on Routing Area changes.
4. 新しいセクション11「管理上の考慮事項」があり、既存のOSPFメカニズムがルーティングエリアの変更に関するASON要件にどのように対処するかを説明しています。
5. There is a new Section 12, which compares the document to the requirements in RFC 4258.
5. ドキュメントをRFC 4258の要件と比較する新しいセクション12があります。
6. The prefix format was changed to reference RFC 5786 rather than defining a separate format and The Node Attribute TLV in RFC 5786 has been updated as a result.
6. プレフィックス形式は、個別の形式を定義するのではなくRFC 5786を参照するように変更され、その結果、RFC 5786のノード属性TLVが更新されました。
7. Routing Information Advertisements were simplified from RFC 5787.
7. ルーティング情報アドバタイズメントはRFC 5787から簡素化されました。
8. Review comments from ITU-T SG15 and the IESG were incorporated.
8. ITU-T SG15およびIESGからのレビューコメントが組み込まれました。
Authors' Addresses
著者のアドレス
Andrew G. Malis Verizon Communications 60 Sylvan Rd. Waltham, MA 02451 USA
アンドリューG.マリスベライゾンコミュニケーションズ60シルバンロードアメリカ合衆国、マサチューセッツ州ウォルサム
EMail: andrew.g.malis@verizon.com
Acee Lindem Ericsson 102 Carric Bend Court Cary, NC 27519
Acee Lindem Ericsson 102 Carric Bend Court Cary、NC 27519
EMail: acee.lindem@ericsson.com
Dimitri Papadimitriou Alcatel-Lucent Copernicuslaan, 50 2018 Antwerpen, Belgium
Dimitris Papadimitriou Alcatel-Lykent Copernicoslaan、50 2018アントワープ、ベルギー
EMail: dimitri.papadimitriou@alcatel-lucent.com