[要約] 要約：RFC 4652は、既存のルーティングプロトコルをASON（Automatic Switched Optical Network）のルーティング要件に対して評価するためのものです。 目的：ASONのルーティング要件に対して既存のルーティングプロトコルがどれだけ適しているかを評価し、ASONの実装と展開に役立つ情報を提供することです。
Network Working Group D. Papadimitriou, Ed.
Request for Comments: 4652 Alcatel
Category: Informational L.Ong
Ciena
J. Sadler
Tellabs
S. Shew
Nortel
D. Ward
Cisco
October 2006
Evaluation of Existing Routing Protocols against Automatic Switched Optical Network (ASON) Routing Requirements
自動スイッチ型光ネットワーク（ASON）ルーティング要件に対する既存のルーティングプロトコルの評価
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
The Generalized MPLS (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) and Optical Transport Networks (OTNs).
This document provides an evaluation of the IETF Routing Protocols against the routing requirements for an Automatically Switched Optical Network (ASON) as defined by ITU-T.
このドキュメントは、ITU-Tで定義されているように、自動化された光ネットワーク（ASON）のルーティング要件に対するIETFルーティングプロトコルの評価を提供します。
Certain capabilities are needed to support the ITU-T Automatically Switched Optical Network (ASON) control plane architecture as defined in [G.8080].
[G.8080]で定義されているように、ITU-Tを自動的に切り替えた光ネットワーク（ASON）制御プレーンアーキテクチャをサポートするには、特定の機能が必要です。
[RFC4258] details the routing requirements for the GMPLS routing suite of protocols to support the capabilities and functionality of ASON control planes identified in [G.7715] and in [G.7715.1]. The ASON routing architecture provides for a conceptual reference architecture, with definition of functional components and common information elements to enable end-to-end routing in the case of protocol heterogeneity and to facilitate management of ASON networks. This description is only conceptual: no physical partitioning of these functions is implied.
[RFC4258]は、[G.7715]および[G.7715.1]で特定されたASONコントロールプレーンの機能と機能をサポートするために、GMPLSルーティングスイートのプロトコルスイートのルーティング要件を詳述しています。ASONルーティングアーキテクチャは、プロトコルの不均一性の場合にエンドツーエンドルーティングを可能にし、ASONネットワークの管理を促進するための機能コンポーネントと共通の情報要素の定義を備えた概念的な参照アーキテクチャを提供します。この説明は概念的なものです。これらの関数の物理的な分割は暗示されていません。
However, [RFC4258] does not address GMPLS routing protocol applicability or capabilities. This document evaluates the IETF Routing Protocols against the requirements identified in [RFC4258]. The result of this evaluation is detailed in Section 5. Close examination of applicability scenarios and the result of the evaluation of these scenarios are provided in Section 6.
ただし、[RFC4258]はGMPLSルーティングプロトコルの適用性または機能に対処していません。このドキュメントでは、[RFC4258]で特定された要件に対してIETFルーティングプロトコルを評価します。この評価の結果については、セクション5で詳しく説明します。適用性シナリオの綿密な調査と、これらのシナリオの評価の結果はセクション6に記載されています。
ASON (Routing) terminology sections are provided in Appendices A and B.
Ason（ルーティング）用語セクションは、付録AおよびBに記載されています。
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 expected to be familiar with the terminology introduced in [RFC4258].
読者は、[RFC4258]で導入された用語に精通していると予想されます。
This document is the result of the CCAMP Working Group ASON Routing Solution design team's joint effort.
このドキュメントは、CCAMPワーキンググループASONルーティングソリューションデザインチームの共同の取り組みの結果です。
Dimitri Papadimitriou (Alcatel, Team Leader and Editor) EMail: dimitri.papadimitriou@alcatel.be Chris Hopps (Cisco) EMail: chopps@rawdofmt.org Lyndon Ong (Ciena Corporation) EMail: lyong@ciena.com Jonathan Sadler (Tellabs) EMail: jonathan.sadler@tellabs.com
Dimitri Papadimitriou（Alcatel、チームリーダー兼編集者）メール：dimitri.papadimitriou@alcatel.be chris hopps（cisco）メール：chopps@rawdofmt.org lyndon ong（ciena Corporation）メール：jonathan.sadler@tellabs.com
Stephen Shew (Nortel Networks) EMail: sdshew@nortel.com Dave Ward (Cisco) EMail: dward@cisco.com
Stephen Shew（Nortel Networks）メール：sdshew@nortel.com Dave Ward（cisco）メール：dward@cisco.com
The following functionality is expected from GMPLS routing protocols to instantiate the ASON hierarchical routing architecture realization (see [G.7715] and [G.7715.1]):
GMPLSルーティングプロトコルから次の機能が予想され、ASON階層ルーティングアーキテクチャの実現をインスタンス化します（[G.7715]および[G.7715.1]を参照）：
- Routing Areas (RAs) shall be uniquely identifiable within a carrier's network, each having a unique RA Identifier (RA ID) within the carrier's network.
- ルーティングエリア（RA）は、キャリアのネットワーク内で一意に識別できるものとし、それぞれがキャリアのネットワーク内に一意のRA識別子（RA ID）を備えているものとします。
- Within a RA (one level), the routing protocol shall support dissemination of hierarchical routing information (including summarized routing information for other levels) in support of an architecture of multiple hierarchical levels of RAs; the number of hierarchical RA levels to be supported by a routing protocol is implementation specific.
- RA（1レベル）内で、ルーティングプロトコルは、RAの複数の階層レベルのアーキテクチャをサポートする階層的ルーティング情報（他のレベルの要約ルーティング情報を含む）の普及をサポートするものとします。ルーティングプロトコルによってサポートされる階層RAレベルの数は、実装固有です。
- The routing protocol shall support routing information based on a common set of information elements as defined in [G.7715] and [G.7715.1], divided between attributes pertaining to links and abstract nodes (each representing either a sub-network or simply a node). [G.7715] recognizes that the manner in which the routing information is represented and exchanged will vary with the routing protocol used.
- ルーティングプロトコルは、[G.7715]および[G.7715.1]で定義されている一般的な情報要素セットに基づくルーティング情報をサポートするものとします。ノード）。[G.7715]は、ルーティング情報が表され、交換される方法が使用されるルーティングプロトコルによって異なることを認識しています。
- The routing protocol shall converge such that the distributed Routing DataBases (RDB) become synchronized after a period of time.
- ルーティングプロトコルは、分散ルーティングデータベース（RDB）が一定期間後に同期されるように収束するものとします。
To support dissemination of hierarchical routing information, the routing protocol must deliver:
階層的なルーティング情報の普及をサポートするには、ルーティングプロトコルが提供する必要があります。
- Processing of routing information exchanged between adjacent levels of the hierarchy (i.e., Level N+1 and N), including reachability and (upon policy decision) summarized topology information.
- 到達可能性や（政策決定に基づく）要約されたトポロジ情報を含む、階層の隣接レベル（つまり、レベルn 1およびn）の間で交換されるルーティング情報の処理。
- Self-consistent information at the receiving level resulting from any transformation (filter, summarize, etc.) and forwarding of information from one Routing Controller (RC) to RC(s) at different levels when multiple RCs are bound to a single RA.
- 複数のRCが単一のRAにバインドされている場合、さまざまなレベルで1つのルーティングコントローラー（RC）からRCへの情報の転送（フィルター、要約など）に起因する受信レベルでの自己整合的な情報。
- A mechanism to prevent re-introduction of information propagated into the Level N RA's RC back to the adjacent level RA's RC from which this information has been initially received.
- レベルn RaのRCに伝播された情報の再導入を防ぐためのメカニズムは、この情報を最初に受け取った隣接レベルRAのRCに戻ります。
Note: The number of hierarchical levels to be supported is routing protocol specific and reflects a containment relationship.
注：サポートされる階層レベルの数は、ルーティングプロトコル固有であり、封じ込め関係を反映しています。
Reachability information may be advertised either as a set of UNI Transport Resource address prefixes, or as a set of associated Subnetwork Point Pool (SNPP) link IDs/SNPP link ID prefixes, assigned and selected consistently in their applicability scope. The formats of the control plane identifiers in a protocol realization are implementation specific. Use of a routing protocol within a RA should not restrict the choice of routing protocols for use in other RAs (child or parent).
到達可能な情報は、UNIトランスポートリソースアドレスのプレフィックスのセットとして、または関連するサブネットワークポイントプール（SNPP）リンクID/SNPPリンクIDプレフィックスのセットとして、適用性範囲で一貫して割り当てられ選択されています。プロトコル実現における制御プレーン識別子の形式は、実装固有です。RA内でのルーティングプロトコルの使用は、他のRA（子または親）で使用するルーティングプロトコルの選択を制限してはなりません。
As ASON does not restrict the control plane architecture choice, either a co-located architecture or a physically separated architecture may be used. A collection of links and nodes, such as a sub-network or RA, must be able to represent itself to the wider network as a single logical entity with only its external links visible to the topology database.
Asonはコントロールプレーンのアーキテクチャの選択を制限していないため、共同配置されたアーキテクチャまたは物理的に分離されたアーキテクチャのいずれかを使用できます。サブネットワークやRAなどのリンクとノードのコレクションは、トポロジーデータベースに見える外部リンクのみを備えた単一の論理エンティティとして、より広いネットワークに自分自身を表すことができなければなりません。
This section evaluates support of existing IETF routing protocols with respect to the requirements summarized from [RFC4258] in Section 4. Candidate routing protocols are Interior Gateway Protocol (IGP) (OSPF and Intermediate System to Intermediate System (IS-IS)) and BGP. The latter is not addressed in the current version of this document. BGP is not considered a candidate protocol mainly because of the following reasons:
このセクションでは、セクション4の[RFC4258]から要約された要件に関する既存のIETFルーティングプロトコルのサポートを評価します。後者は、このドキュメントの現在のバージョンでは扱われていません。BGPは、主に次の理由により、候補プロトコルとは見なされません。
- Non-support of TE information exchange. Each BGP router advertises only its path to each destination in its vector for loop avoidance, with no costs or hop counts; each BGP router knows little about network topology.
- TE情報交換の非サポート。各BGPルーターは、コストやホップカウントなしで、ループ回避のためにベクトル内の各宛先へのパスのみを宣伝しています。各BGPルーターは、ネットワークトポロジについてほとんど知りません。
- BGP can only advertise routes that are eligible for use (local RIB) or routing loops can occur; there is one best route per prefix, and that is the route that is advertised.
- BGPは、使用対象のルート（ローカルリブ）またはルーティングループのみが発生する可能性があるルートのみを宣伝できます。プレフィックスごとに1つの最適なルートがあり、それが宣伝されているルートです。
- BGP is not widely deployed in optical equipment and networks.
- BGPは、光学機器やネットワークに広く展開されていません。
- 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. The Li is identified by the TE Router_ID. The latter is a control plane identifier defined as follows:
- Liは、単一のデータプレーン（要約）ノードに関連付けられている論理制御プレーンエンティティです。LiはTe router_idによって識別されます。後者は、次のように定義されたコントロールプレーン識別子です。
[RFC3630]: Router_Address (top level) TLV of the Type 1 TE LSA [RFC3784]: Traffic Engineering Router ID TLV (Type 134)
[RFC3630]：Router_Address（上位レベル）タイプ1 TE LSA [RFC3784]のTLV：トラフィックエンジニアリングルーターID TLV（タイプ134）
Note: This document does not define what the TE Router ID is. This document simply states the use of the TE Router ID to identify Li. [RFC3630] and [RFC3784] provide the definitions.
注：このドキュメントでは、TEルーターIDが何であるかを定義していません。このドキュメントは、Liを識別するためにTEルーターIDの使用を単に示しています。[RFC3630]および[RFC3784]は定義を提供します。
- 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
- RIは、コントロールプレーンの「ルーター」に関連付けられている論理制御プレーンエンティティです。後者は、他のコントロールプレーン「ルーター」と生成および共有するトポロジ情報のソースです。RIは（広告）router_idによって識別されます
[RFC2328]: Router ID (32-bit) [RFC1195]: IS-IS System ID (48-bit)
[RFC2328]：ルーターID（32ビット）[RFC1195]：IS-ISシステムID（48ビット）
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. Note that, in the ASON context, an arrangement consisting of multiple Ris announcing routing information related to a single Li is under evaluation.
RIで表され、RC_ID [RFC4258]に対応するRouter_IDは、リンクなどのデータプレーンリソースを表す論理エンティティの識別には入りません。ルーティングデータベース（RDB）はRIに関連付けられています。ASONコンテキストでは、単一のLIに関連するルーティング情報を発表する複数のRIで構成される配置が評価中であることに注意してください。
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. Thus, the routing protocol MUST be able to advertise multiple TE Router IDs (see Section 5.7).
LI/PIマッピングは別として、これらの識別子は、RIがその範囲に複数のLIを持っている可能性があることを除いて、特定のエンティティ関係にあると想定されていません。RIとLIの関係は、いつでも簡単です。LIは、いつでも1つのRIによって宣伝される場合があります。ただし、RIは1つ以上のLIのセットを宣伝する場合があります。したがって、ルーティングプロトコルは複数のTEルーターIDを宣伝できる必要があります（セクション5.7を参照）。
Note: Si is a control plane signaling function associated with one or more Lis. This document does not assume any specific constraint on the relationship between Si and Li. This document does not discuss issues of control plane accessibility for the signaling function, and it makes no assumptions about how control plane accessibility to the Si is achieved.
注：SIは、1つ以上のLIに関連するコントロールプレーンシグナル伝達機能です。このドキュメントでは、SiとLiの関係に関する特定の制約は想定されていません。このドキュメントでは、シグナル伝達機能の制御プレーンのアクセシビリティの問題については議論しておらず、SIへの制御プレーンのアクセシビリティがどのように達成されるかについての仮定はありません。
G.7715.1 notes some necessary characteristics for RA identifiers, e.g., that they may provide scope for the Ri, and that they must be provisioned to be unique within an administrative domain. The RA ID format itself is allowed to be derived from any global address space. Provisioning of RA IDs for uniqueness is outside the scope of this document.
G.7715.1は、RA識別子に必要な特性をいくつか指摘しています。たとえば、RIの範囲を提供する可能性があり、管理領域内で一意であるようにプロビジョニングする必要があることを指摘しています。RA ID形式自体は、グローバルアドレススペースから導出されることができます。一意性のためのRA IDのプロビジョニングは、このドキュメントの範囲外です。
Under these conditions, GMPLS link state routing protocols provide the capability for RA Identification without further modification.
これらの条件下では、GMPLSリンク状態ルーティングプロトコルは、さらに変更することなくRA識別の機能を提供します。
In this section, the focus is on routing information exchange Ri entities (through routing adjacencies) within a single hierarchical level. Routing information mapping between levels require specific processing (see Section 5.5).
このセクションでは、単一の階層レベル内の情報交換RIエンティティ（隣接をルーティングを介して）ルーティングに焦点を当てています。レベル間のルーティング情報マッピングには、特定の処理が必要です（セクション5.5を参照）。
The control plane does not transport Pi identifiers, as these are data plane addresses for which the Li/Pi mapping is kept (link) local; see, for instance the transport LMP document [RFC4394] where such an exchange is described. Example: The transport plane identifier is the Pi (the identifier assigned to the physical element) that could be, for instance, "666B.F999.AF10.222C", whereas the control plane identifier is the Li (the identifier assigned by the control plane), which could be, for instance, "192.0.2.1".
コントロールプレーンは、PI識別子を輸送しません。これらは、LI/PIマッピングが保持されるデータプレーンアドレス（リンク）ローカルです。たとえば、そのような交換が記載されている場合、Transport LMPドキュメント[RFC4394]を参照してください。例：輸送平面識別子は、たとえば「666b.f999.af10.222c」である可能性のあるpi（物理的要素に割り当てられた識別子）です。一方平面）、たとえば「192.0.2.1」である可能性があります。
The control plane exchanges the control plane identifier information, but not the transport plane identifier information (i.e., not "666B.F999.AF10.222C", but only "192.0.2.1"). The mapping Li/Pi is kept local. So, when the Si receives a control plane message requesting the use of "192.0.2.1", Si knows locally that this information refers to the data plane entity identified by the transport plane identifier "666B.F999.AF10.222C".
コントロールプレーンは、コントロールプレーンの識別子情報を交換しますが、輸送平面識別子情報（つまり、「666b.f99.af10.222c」ではなく、「192.0.2.1」のみ）を交換します。マッピングLI/PIはローカルに保たれます。したがって、SIが「192.0.2.1」の使用を要求するコントロールプレーンのメッセージを受信すると、SIはこの情報が輸送平面識別子「666B.F999.AF10.222C」によって識別されるデータプレーンエンティティを指すことをローカルに知っています。
Note also that the Li and Pi addressing spaces may be identical.
また、LIおよびPIアドレス指定スペースは同一である可能性があることに注意してください。
The control plane carries:
コントロールプレーンが運びます：
1) its view of the data plane link end-points and other link connection end-points.
1) データプレーンリンクのエンドポイントおよびその他のリンク接続エンドポイントのビュー。
2) the identifiers scoped by the Lis, i.e., referred to as an associated IPv4/IPv6 addressing space. Note that these identifiers may be either bundled TE link addresses or component link addresses.
2) 識別子は、LISによってスコープ、つまり関連するIPv4/IPv6アドレス指定スペースと呼ばれます。これらの識別子は、バンドルされたTEリンクアドレスまたはコンポーネントリンクアドレスのいずれかである場合があることに注意してください。
3) when using OSPF or ISIS as the IGP in support of traffic engineering, [RFC3477] RECOMMENDS that the Li value (referred to the "LSR Router ID") be set to the TE Router ID value.
3) トラフィックエンジニアリングをサポートするIGPとしてOSPFまたはISISを使用する場合、[RFC3477]は、LI値（「LSRルーターID」と呼ばれる）をTEルーターID値に設定することを推奨しています。
Therefore, OSPF and IS-IS carry sufficient node identification information without further modification.
したがって、OSPFとIS-ISは、それ以上の変更なしに十分なノード識別情報を運びます。
[RFC4258] provides a list of link attributes and characteristics that need to be advertised by a routing protocol. All TE link attributes and characteristics are currently handled by OSPF and IS-IS (see Table 1) with the exception of Local Adaptation support. Indeed, GMPLS routing does not currently consider the use of dedicated TE link attribute(s) to describe the cross/inter-layer relationships.
[RFC4258]は、ルーティングプロトコルで宣伝する必要があるリンク属性と特性のリストを提供します。すべてのリンク属性と特性は、現在OSPFおよびIS-ISによって処理されます（表1を参照）は、ローカル適応サポートを除きます。実際、GMPLSルーティングは現在、交差/層間関係を記述するための専用のTEリンク属性の使用を考慮していません。
In addition, the representation of bandwidth requires further consideration. GMPLS Routing defines an Interface Switching Capability Descriptor (ISCD) that delivers information about the (maximum/ minimum) bandwidth per priority of which an LSP can make use. This information is usually used in combination with the Unreserved Bandwidth sub-TLV that provides the amount of bandwidth not yet reserved on a TE link.
さらに、帯域幅の表現にはさらに考慮が必要です。GMPLSルーティングは、LSPが使用できる優先度ごとに（最大/最小）帯域幅に関する情報を提供するインターフェイススイッチング機能記述子（ISCD）を定義します。この情報は通常、TEリンクにまだ予約されていない帯域幅の量を提供する、予約されていない帯域幅サブTLVと組み合わせて使用されます。
In the ASON context, other bandwidth accounting representations are possible, e.g., in terms of a set of tuples <signal_type; number of unallocated timeslots>. The latter representation may also require definition of additional signal types (from those defined in [RFC3946]) to represent support of contiguously concatenated signals, i.e., STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64, 256.
ASONの文脈では、たとえば、一連のTupple <Signal_Typeのセットの観点から、他の帯域幅の会計表現が可能です。未割り当てのタイムスロットの数>。後者の表現は、連続的に連結したシグナルのサポート、すなわちSTS-（3XN）C SPE / VC-4-NC、n = 4、16、64、256。
However, the method proposed in [RFC4202] is the most straightforward without requiring any bandwidth accounting change from an LSR perspective (in particular, when the ISCD sub-TLV information is combined with the information provided by the Unreserved Bandwidth sub-TLV).
ただし、[RFC4202]で提案されている方法は、LSRの観点から帯域幅の会計変更を必要とせずに最も簡単です（特に、ISCDサブTLV情報が、未整備帯域幅Sub-TLVが提供する情報と組み合わせた場合）。
Link Characteristics GMPLS OSPF
----------------------- ----------
Local SNPP link ID Link-local part of the TE link identifier
sub-TLV [RFC4203]
Remote SNPP link ID Link remote part of the TE link identifier
sub-TLV [RFC4203]
Signal Type Technology specific part of the Interface
Switching Capability Descriptor sub-TLV
[RFC4203]
Link Weight TE metric sub-TLV [RFC3630]
Resource Class Administrative Group sub-TLV [RFC3630]
Local Connection Types Switching Capability field part of the
Interface Switching Capability Descriptor
sub-TLV [RFC4203]
Link Capacity Unreserved bandwidth sub-TLV [RFC3630]
Max LSP Bandwidth part of the Interface
Switching Capability Descriptor sub-TLV
[RFC4203]
Link Availability Link Protection sub-TLV [RFC4203]
Diversity Support SRLG sub-TLV [RFC4203]
Local Adaptation support See above
Table 1. TE link attributes in GMPLS OSPF-TE
表1. GMPLS OSPF-TEのTEリンク属性
Link Characteristics GMPLS IS-IS
----------------------- -----------
Local SNPP link ID Link-local part of the TE link identifier
sub-TLV [RFC4205]
Remote SNPP link ID Link-remote part of the TE link identifier
sub-TLV [RFC4205]
Signal Type Technology specific part of the Interface
Switching Capability Descriptor sub-TLV
[RFC4205]
Link Weight TE Default metric [RFC3784]
Resource Class Administrative Group sub-TLV [RFC3784]
Local Connection Types Switching Capability field part of the
Interface Switching Capability Descriptor
sub-TLV [RFC4205]
Link Capacity Unreserved bandwidth sub-TLV [RFC3784]
Max LSP Bandwidth part of the Interface
Switching Capability Descriptor sub-TLV
[RFC4205]
Link Availability Link Protection sub-TLV [RFC4205]
Diversity Support SRLG sub-TLV [RFC4205]
Local Adaptation support See above
Table 2. TE link attributes in GMPLS IS-IS-TE
表2. GMPLS IS-ISTEのTEリンク属性
Note: Link Attributes represent layer resource capabilities and their utilization i.e. the IGP should be able to advertise these attributes on a per-layer basis.
注：リンク属性は、レイヤーリソース機能とその使用率を表します。つまり、IGPはこれらの属性を層ごとに宣伝できる必要があります。
Node attributes are the "Logical Node ID" (described in Section 5.1) and the reachability information described in Section 5.3.3.
ノード属性は、「論理ノードID」（セクション5.1で説明）とセクション5.3.3で説明されている到達可能性情報です。
Advertisement of reachability can be achieved using the techniques described in [OSPF-NODE], where the set of local addresses are carried in an OSPF TE LSA node attribute TLV (a specific sub-TLV is defined per address family, e.g., IPv4 and IPv6). However, [OSPF-NODE] is restricted to advertisement of Host addresses and not prefixes, and therefore it requires enhancement (see below). Thus, in order to advertise blocks of reachable address prefixes a summarization mechanism is additionally required. This mechanism may take the form of a prefix length (which indicates the number of significant bits in the prefix) or a network mask.
到達可能性の広告は、[OSPFノード]で説明されている手法を使用して達成できます。ここでは、ローカルアドレスのセットがOSPF te lsaノード属性TLVで運ばれます（特定のサブTLVは、アドレスファミリごとに定義されます。たとえば、IPv4およびIPv6）。ただし、[OSPF-Node]は、プレフィックスではなくホストアドレスの広告に制限されているため、強化が必要です（以下を参照）。したがって、到達可能なアドレスのプレフィックスのブロックを宣伝するために、要約メカニズムがさらに必要です。このメカニズムは、プレフィックスの長さ（プレフィックス内の重要なビットの数を示す）またはネットワークマスクの形をとる場合があります。
A similar mechanism does not exist for IS-IS. Moreover, the Extended IP Reachability TLV [RFC3784] focuses on IP reachable end-points (terminating points), as its name indicates.
同様のメカニズムは、IS-ISには存在しません。さらに、拡張されたIPリーチビリティTLV [RFC3784]は、その名前が示すように、IPリーチ可能なエンドポイント（終端ポイント）に焦点を当てています。
G.7715.1 describes both static and dynamic methods for abstraction of routing information for advertisement at a different level of the routing hierarchy. However, the information that is advertised continues to be in the form of link and node advertisements consistent with the link state routing protocol used at that level. Hence, no specific capabilities need to be added to the routing protocol beyond the ability to locally identify when routing information originates outside of a particular RA.
G.7715.1は、ルーティング階層の異なるレベルで広告のルーティング情報を抽出するための静的および動的方法の両方を説明しています。ただし、宣伝されている情報は、そのレベルで使用されるリンク状態ルーティングプロトコルと一致するリンクおよびノード広告の形で引き続きあります。したがって、ルーティング情報が特定のRA以外で発生する場合にローカルに識別する機能を超えて、ルーティングプロトコルに特定の機能を追加する必要はありません。
The methods used for abstraction of routing information are outside the scope of GMPLS routing protocols.
ルーティング情報の抽象化に使用される方法は、GMPLSルーティングプロトコルの範囲外です。
G.7715.1 does not define specific mechanisms to support multiple hierarchical levels of RAs beyond the ability to support abstraction as discussed above. However, if RCs bound to adjacent levels of the RA hierarchy are allowed to redistribute routing information in both directions between adjacent levels of the hierarchy without any additional mechanisms, they would not be able to determine looping of routing information.
G.7715.1は、上記のように抽象化をサポートする能力を超えて、RAの複数の階層レベルをサポートする特定のメカニズムを定義しません。ただし、RA階層の隣接レベルにバインドされているRCが、追加のメカニズムなしに階層の隣接レベル間の両方の方向にルーティング情報を再配布することが許可されている場合、ルーティング情報のループを決定することはできません。
To prevent this looping of routing information between levels, IS-IS [RFC1195] allows only advertising routing information upward in the level hierarchy and disallows the advertising of routing information downward in the hierarchy. [RFC2966] defines the up/down bit to allow advertising downward in the hierarchy the "IP Internal Reachability Information" TLV (Type 128) and "IP External Reachability Information" TLV (Type 130). [RFC3784] extends its applicability for the "Extended IP Reachability" TLV (Type 135). Using this mechanism, the up/down bit is set to 0 when routing information is first injected into IS-IS. If routing information is advertised from a higher level to a lower level, the up/down bit is set to 1, indicating that it has traveled down the hierarchy. Routing information that has the up/down bit set to 1 may only be advertised down the hierarchy, i.e., to lower levels. This mechanism applies independently of the number of levels. However, this mechanism does not apply to the "Extended IS Reachability" TLV (Type 22) used to propagate the summarized topology (see Section 5.3), traffic engineering information as listed in Table 1, as well as reachability information (see Section 5.3.3).
レベル間のルーティング情報のこのループを防ぐために、IS-IS [RFC1195]により、広告ルーティング情報のみがレベルの階層に上方に上方になり、階層で情報を下方にルーティングする広告を許可します。[RFC2966]は、アップ/ダウンビットを定義して、階層内の「IP内部リーチビリティ情報」TLV（タイプ128）および「IP外部リーチビリティ情報」TLV（タイプ130）を下に広めることを可能にします。[RFC3784]は、「拡張されたIPリーチ可能性」TLV（タイプ135）の適用性を拡張します。このメカニズムを使用して、ルーティング情報が最初にIS-ISに注入されると、アップ/ダウンビットが0に設定されます。ルーティング情報がより高いレベルから低レベルに宣伝されている場合、アップ/ダウンビットは1に設定されており、階層を下って移動したことを示します。アップ/ダウンビットが1に設定されているルーティング情報は、階層のみで宣伝される場合があります。つまり、より低いレベルになります。このメカニズムは、レベルの数とは独立して適用されます。ただし、このメカニズムは、要約されたトポロジ（セクション5.3を参照）、表1にリストされているトラフィックエンジニアリング情報、および到達可能性情報（セクション5.3を参照するために使用される「拡張性ISリーチ可能性」TLV（タイプ22）には適用されません。3）。
OSPFv2 [RFC2328] prevents inter-area routes (which are learned from area 0) from being passed back to area 0. However, GMPLS makes use of Type 10 (area-local scope) LSAs to propagate TE information [RFC3630], [RFC4202]. Type 10 Opaque LSAs are not flooded beyond the borders of their associated area. It is therefore necessary to have a means by which Type 10 Opaque LSA may carry the information that a particular piece of routing information has been learned from a higher-level RC when propagated to a lower-level RC. Any downward RC from this level, which receives an LSA with this information would omit the information in this LSA and thus not re-introduce this information back into a higher-level RC.
OSPFV2 [RFC2328]は、エリア間のルート（エリア0から学習された）を防止します（エリア0）はエリア0に渡されます。ただし、GMPLSはタイプ10（エリアローカルスコープ）LSAを使用してTE情報を伝播します[RFC3630]、[RFC4202]。タイプ10の不透明なLSAは、関連する領域の境界を越えて浸水していません。したがって、タイプ10の不透明LSAが、低レベルのRCに伝播すると、特定のルーティング情報が高レベルのRCから学習されたという情報を伝えることができる手段を持つ必要があります。この情報を使用してLSAを受信するこのレベルから下向きのRCは、このLSAの情報を省略し、この情報を高レベルのRCに再導入することはありません。
Link state protocols have been designed to propagate detected topological changes (such as interface failures and link attributes modification). The convergence period is short and involves a minimum of routing information exchange.
リンク状態プロトコルは、検出されたトポロジーの変化を伝播するように設計されています（インターフェイス障害やリンク属性の変更など）。収束期間は短く、最小限のルーティング情報交換が含まれます。
Therefore, existing routing protocol convergence involves mechanisms that are sufficient for ASON applications.
したがって、既存のルーティングプロトコル収束には、ASONアプリケーションに十分なメカニズムが含まれます。
The routing protocol MUST support a single Ri advertising on behalf of more than one Li. Since each Li is identified by a unique TE Router ID, the routing protocol MUST be able to advertise multiple TE Router IDs. That is, for [RFC3630], multiple Router Addresses and for [RFC3784] multiple Traffic Engineering Router Ids.
ルーティングプロトコルは、複数のLIに代わって単一のRI広告をサポートする必要があります。各LIは一意のTEルーターIDによって識別されるため、ルーティングプロトコルは複数のTEルーターIDを宣伝できる必要があります。つまり、[RFC3630]の場合、複数のルーターアドレスと[RFC3784]の複数のトラフィックエンジニアリングルーターIDです。
The Link sub-TLV that is currently part of the top level Link TLV associates the link to the Router_ID. However, having the Ri advertising on behalf of multiple Lis creates the following issue, as there is no longer a 1:1 relationship between the Router_ID and the TE Router_ID, but a 1:N relationship is possible (see Section 5.1). As the link-local and link-remote (unnumbered) ID association may not be unique per abstract 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(s). In brief, as unnumbered links have their ID defined on per Li bases, 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.
現在トップレベルのリンクTLVの一部であるリンクサブTLVは、リンクをRouter_Idに関連付けます。ただし、Router_idとTe Router_IDの間に1：1の関係がなくなったが、1：Nの関係が可能であるため、複数のLIに代わってRI広告を使用すると、次の問題が生じます（セクション5.1を参照）。Link-LocalおよびLink-Remote（Unnoumbered）ID Associationは抽象ノード（Li Unicityごと）ごとに一意ではない可能性があるため、広告はリモートLJ値を示し、{Li; LJを取得するための初期発見プロセスに依存する必要があります。}関係（s）。簡単に言えば、Noumbered LinksがLIベースごとにIDを定義しているため、リモートLJを識別する必要があります。したがって、ルーティングプロトコルは、正しいTEルーターIDに関連付けられるように、広告されたTEリンクを明確にすることができなければなりません。
Moreover, when the Ri advertises on behalf multiple Lis, the routing protocol MUST be able to disambiguate the advertised reachability information (see Section 5.3.3) so that it can be associated with the correct TE Router ID.
さらに、RIが複数のLIに代わって宣伝する場合、ルーティングプロトコルは、正しいTEルーターIDに関連付けることができるように、広告された到達可能性情報を明確にすることができなければなりません（セクション5.3.3を参照）。
The evaluation scenarios are the following; they are respectively referred to as cases 1, 2, 3, and 4.
評価シナリオは次のとおりです。それらはそれぞれケース1、2、3、および4と呼ばれます。
In Figure 1, below,
以下の図1、
- R3 represents an LSR with all components collocated. - R2 shows how the "router" component may be disjoint from the node. - R1 shows how a single "router" may manage multiple nodes.
- R3は、すべてのコンポーネントがコロークされるLSRを表します。-R2は、「ルーター」コンポーネントがノードからどのように見捨てられているかを示しています。-R1は、単一の「ルーター」が複数のノードを管理する方法を示しています。
------------------- -------
|R1 | |R2 |
| | | | ------
| L1 L2 L3 | | L4 | |R3 |
| : : : | | : | | |
| : : : | | : | | L5 |
Control ---+-----+-----+--- ---+--- | : |
Plane : : : : | : |
----------------+-----+-----+-----------+-------+---+--+-
Data : : : : | : |
Plane -- : -- -- | -- |
----|P1|--------|P3|--------|P4|------+-|P5|-+-
-- \ : / -- -- | -- |
\ -- / | |
|P2| ------
--
Figure 1. Evaluation Cases 1, 2, and 3
図1.評価ケース1、2、および3
Case 1 as represented refers either to direct links between edges or to "logical links" as shown in Figure 2 (or any combination of them).
表現されるケース1は、図2（またはそれらの任意の組み合わせ）に示すように、エッジ間のリンクまたは「論理リンク」の直接リンクのいずれかを指します。
------ ------
| | | |
| L1 | | L2 |
| : | | : |
| : R1| | : R2|
Control Plane --+--- --+---
Elements : :
------------------+-----------------------------+------------------
Data Plane : :
Elements : :
----+-----------------------------+-----
| : : |
| --- --- --- |
| | |----------| P |----------| | |
---+--| | --- | |---+---
| | | | | |
| | P1|-------------------------| P2| |
| --- --- |
----------------------------------------
Figure 2. Case 1 with Logical Links
図2.論理リンク付きのケース1
Another case (referred to as Case 4) is constituted by the Abstract Node as represented in Figure 3. There is no internal structure associated (externally) to the abstract node.
別のケース（ケース4と呼ばれる）は、図3に示すように抽象ノードで構成されています。抽象ノードに関連する内部構造（外部）はありません。
--------------
|R4 |
| |
| L6 |
| : |
| ...... |
---:------:---
Control Plane : :
+------+------+------+
Data Plane : :
---:------:---
|P8 : : |
| -- -- |
--+-|P |----|P |-+--
| -- -- |
--------------
Figure 3. Case 4: Abstract Node
図3.ケース4：要約ノード
Note: the "signaling function" referred to as Si, i.e., the control plane entity that processes the signaling messages, is not represented in these figures.
注：SIと呼ばれる「シグナル関数」、つまりシグナリングメッセージを処理する制御面エンティティは、これらの図には表されません。
The following sections summarize the additions to be provided to OSPF and IS-IS in support of ASON routing.
次のセクションでは、ASONルーティングをサポートするOSPFとIS-ISに提供される追加を要約します。
Reachability Extend Node Attribute sub-TLVs to support address prefixes (see Section 5.3.3).
Reachabilityは、ノード属性サブTLVを拡張してアドレスプレフィックスをサポートします（セクション5.3.3を参照）。
Link Attributes Representation of cross/inter-layer relationships in link top-level link TLV (see Section 5.3.1).
リンク属性リンクトップレベルリンクTLVのクロス/レイヤー関係の表現（セクション5.3.1を参照）。
Optionally, provide for per-signal-type bandwidth accounting (see Section 5.3.1).
オプションでは、シグナル型帯域幅の会計を提供します（セクション5.3.1を参照）。
Scoping TE link advertisements to allow for retrieving their respective local-remote TE Router_ID relationship(s) (see Section 5.7).
スコーピングTEリンク広告は、それぞれのローカルリモートTE Router_ID関係を取得できるようにします（セクション5.7を参照）。
Prefixes part of the reachability advertisement (using Node Attribute top-level TLV) needs to be associated to its respective local TE Router_ID (see Section 5.7).
Reachability Advertisementの一部（ノード属性のトップレベルTLVを使用）の一部を、それぞれのローカルTE Router_IDに関連付ける必要があります（セクション5.7を参照）。
Hierarchy Provide a mechanism by which Type 10 Opaque LSA may carry the information that a particular piece of routing information has been learned from a higher-level RC when propagated to a lower-level RC (so as not to re-introduce this information into a higher-level RC).
階層は、タイプ10の不透明LSAが、低レベルのRCに伝播すると、特定のルーティング情報が高レベルのRCから学習されたという情報を伝えるメカニズムを提供します（この情報を再導入しないように、高レベルのRC）。
Reachability Provide for reachability advertisement (in the form of reachable TE prefixes).
到達可能性は、到達可能な広告を提供します（リーチ可能なTEプレフィックスの形式）。
Link Attributes Representation of cross/inter-layer relationships in Extended IS Reachability TLV (see Section 5.3.1).
リンク属性拡張におけるクロス/レイヤー間の関係の表現は、到達可能性TLVです（セクション5.3.1を参照）。
Optionally, provide for per-signal-type bandwidth accounting (see Section 5.3.1).
オプションでは、シグナル型帯域幅の会計を提供します（セクション5.3.1を参照）。
Scoping Extended IS Reachability TLVs to allow for retrieving their respective local-remote TE Router_ID relationship(s) (see Section 5.7).
拡張されたスコーピングは、それぞれのローカルリモートTE Router_ID関係を取得できるようにするための到達可能性TLVです（セクション5.7を参照）。
Prefixes part of the reachability advertisement needs to be associated to its respective local TE Router_ID (see Section 5.7).
Reachability広告の一部を、それぞれのローカルTE Router_IDに関連付ける必要があります（セクション5.7を参照）。
Hierarchy Extend the up/down bit mechanisms to propagate the summarized topology (see Section 5.3) and traffic engineering information as listed in Table 1, as well as reachability information (see Section 5.3.3).
階層は、アップ/ダウンビットメカニズムを拡張して、まとめられたトポロジ（セクション5.3を参照）と表1にリストされているトラフィックエンジニアリング情報、および到達可能性情報（セクション5.3.3を参照）を伝播します。
The introduction of a dynamic control plane to an ASON network exposes it to additional security risks that may have been controlled or limited by the use of management plane solutions. The routing protocols play a part in the control plane and may be attacked so that they become unstable or provide incorrect information for use in path computation or by the signaling protocols.
ASONネットワークへの動的制御プレーンの導入により、管理プレーンソリューションの使用によって制御または制限されている可能性のある追加のセキュリティリスクにさらされます。ルーティングプロトコルはコントロールプレーンで役割を果たし、攻撃され、不安定になるか、パス計算またはシグナル伝達プロトコルで使用するための誤った情報を提供することができます。
Nevertheless, there is no reason why the control plane components cannot be secured, and the security mechanisms developed for the routing protocol and used within the Internet are equally applicable within an ASON context.
それにもかかわらず、制御プレーンコンポーネントを保護できない理由はありません。また、ルーティングプロトコル用に開発され、インターネット内で使用されるセキュリティメカニズムは、ASONコンテキスト内で等しく適用できます。
[RFC4258] describes the requirements for security of routing protocols for the Automatically Switched Optical Network. Reference is made to [M.3016], which lays out the overall security objectives of confidentiality, integrity, and accountability. These are well discussed for the Internet routing protocols in [THREATS].
[RFC4258]は、自動化された光ネットワークのルーティングプロトコルのセキュリティの要件を説明しています。[M.3016]への参照が行われます。これは、機密性、整合性、および説明責任の全体的なセキュリティ目標を示しています。これらは、[脅威]のインターネットルーティングプロトコルについてよく議論されています。
A detailed discussion of routing threats and mechanisms that are currently deployed in operational networks to counter these threats is found in [OPSECPRACTICES]. A detailed listing of the device capabilities that can be used to support these practices can be found in [RFC3871].
現在、これらの脅威に対抗するために運用ネットワークに展開されているルーティングの脅威とメカニズムの詳細な議論は、[opsecpractices]にあります。これらのプラクティスをサポートするために使用できるデバイス機能の詳細なリストは、[RFC3871]に記載されています。
The authors would like to thank Adrian Farrel for having initiated the proposal of an ASON Routing Solution Design Team and the ITU-T SG15/Q14 for their careful review and input.
著者は、ASONルーティングソリューション設計チームとITU-T SG15/Q14の提案を開始してくれたAdrian Farrelに、慎重なレビューと入力について感謝します。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195] Callon、R。、「TCP/IPおよびデュアル環境でのルーティングのためのOSI IS-I-ISの使用」、RFC 1195、1990年12月。
[RFC2966] Li, T., Przygienda, T., and H. Smit, "Domain-wide Prefix Distribution with Two-Level IS-IS", RFC 2966, October 2000.
[RFC2966] Li、T.、Przygienda、T。、およびH. Smit、「2レベルのIS-ISを備えたドメイン全体の接頭分布」、RFC 2966、2000年10月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[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月。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3477] Kompella、K。およびY. Rekhter、「リソース予約プロトコルにおける無数のリンク - トラフィックエンジニアリング（RSVP -TE）」、RFC 3477、2003年1月。
[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月。
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[RFC3784] Smit、H。およびT. Li、「トラフィックエンジニアリングの中間システム（IS-IS）拡張（TE）」、RFC 3784、2004年6月。
[RFC3871] Jones, G., Ed., "Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure", RFC 3871, September 2004.
[RFC3871] Jones、G.、ed。、「大規模なインターネットサービスプロバイダー（ISP）IPネットワークインフラストラクチャの運用セキュリティ要件」、RFC 3871、2004年9月。
[RFC3946] Mannie, E. and D. Papadimitriou, "Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 3946, October 2004.
[RFC3946] Mannie、E。およびD. Papadimitriou、「同期光学ネットワーク（SONET）および同期デジタル階層（SDH）コントロール用の一般化マルチプロトコルラベルスイッチング（GMPLS）拡張」、RFC 3946、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月。
[RFC4205] Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4205, October 2005.
[RFC4205] Kompella、K.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートする中間システム（IS-IS）拡張」、RFC 4205、2005年10月。
[RFC4258] Brungard, D., "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月。
[RFC4394] Fedyk, D., Aboul-Magd, O., Brungard, D., Lang, J., and D. Papadimitriou, "A Transport Network View of the Link Management Protocol (LMP)", RFC 4394, February 2006.
[RFC4394] Fedyk、D.、Aboul-Magd、O.、Brungard、D.、Lang、J。、およびD. Papadimitriou、「リンク管理プロトコル（LMP）の輸送ネットワークビュー」、RFC 4394、2006年2月。
[OPSECPRACTICES] Kaeo, M., "Operational Security Current Practices", Work in Progress, July 2006.
[opsecpractices] Kaeo、M。、「運用セキュリティ現在の慣行」、2006年7月、進行中の作業。
[OSPF-NODE] Aggarwal, R. and K. Kompella, "Advertising a Router's Local Addresses in OSPF TE Extensions", Work in Progress, June 2006.
[OSPF-Node] Aggarwal、R。およびK. Kompella、「OSPF TE Extensionsでのルーターのローカルアドレスを宣伝する」、2006年6月、進行中の作業。
[THREATS] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006.
[脅威] Barbir、A.、Murphy、S。、およびY. Yang、「ルーティングプロトコルに対する一般的な脅威」、RFC 4593、2006年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.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the Automatically Switched Optical Network (ASON)", June 2006.
[g.8080] itu-t rec。G.8080/Y.1304、「自動化された光ネットワーク（ASON）のアーキテクチャ」、2006年6月。
[M.3016] ITU-T Rec. M.3016.0, "Security for the Management Plane: Overview", May 2005.
[M.3016] itu-t rec。M.3016.0、「管理プレーンのセキュリティ：概要」、2005年5月。
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 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 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.
管理ドメイン（推奨G.805を参照）：管理ドメインは、地理、技術、ポリシー、またはその他の構造に従って組織の要件を満たすためにグループ化された管理オブジェクトのコレクションを定義し、障害、構成などの多くの機能領域について定義します。、会計、パフォーマンス、セキュリティ（FCAPS）、一貫した方法で制御を提供する目的。管理ドメインは、ばらばら、封じ込め、または重複する可能性があります。そのため、管理ドメイン内のリソースは、いくつかの可能な重複する管理ドメインに分配できます。
The same resource can therefore belong to several management domains simultaneously, but a management domain shall not cross the border of an administrative domain.
したがって、同じリソースは複数の管理ドメインに同時に属することができますが、管理ドメインは管理ドメインの境界を越えてはなりません。
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 bi-directional 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 G.805 Recommendation.
輸送面：ある場所から別の場所へのユーザー情報の双方向または単方向転送を提供します。また、一部の制御およびネットワーク管理情報の転送を提供することもできます。輸送面は階層化されています。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): Repository for the local topology, network topology, reachability, and other routing information that is updated as part of the routing information exchange and that 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 being protocol independent (Link Resource Manager or LRM, Routing Controller or RC) and 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には、複数のRAに関連するルーティング情報が含まれている可能性があるため（およびおそらく複数のレイヤーネットワーク）、RDBにアクセスするRCSはルーティング情報を共有する場合があります。
Link Resource Manager (LRM): Supplies all the relevant component and TE link information to the RC. It informs the RC about any state changes of the link resources it controls.
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.
Authors' Addresses
著者のアドレス
Dimitri Papadimitriou, Ed. Alcatel Francis Wellensplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 2408491 EMail: dimitri.papadimitriou@alcatel.be
Dimitri Papadimitriou、編Alcatel Francis Wellensplein 1、B-2018 Antwerpen、Belgium電話：32 3 2408491メール：dimitri.papadimitriou@alcatel.be
Lyndon Ong Ciena Corporation PO Box 308 Cupertino, CA 95015 , USA Phone: +1 408 705 2978 EMail: lyong@ciena.com
Lyndon Ong Ciena Corporation PO Box 308 Cupertino、CA 95015、USA電話：1 408 705 2978メール：lyong@ciena.com
Jonathan Sadler Tellabs 1415 W. Diehl Rd Naperville, IL 60563 EMail: jonathan.sadler@tellabs.com
Jonathan Sadler Tellabs 1415 W. Diehl Rd Naperville、IL 60563メール：jonathan.sadler@tellabs.com
Stephen Shew Nortel Networks 3500 Carling Ave. Ottawa, Ontario, CANADA K2H 8E9 Phone: +1 613 7632462 EMail: sdshew@nortel.com
Stephen Shew Nortel Networks 3500 Carling Ave. Ottawa、Ontario、Canada K2H 8e9電話：1 613 7632462メール：sdshew@nortel.com
Dave Ward Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 USA Phone: +1-408-526-4000 EMail: dward@cisco.com
Dave Ward Cisco Systems 170 W. Tasman Dr. San Jose、CA 95134 USA電話：1-408-526-4000メール：dward@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。