Network Working Group D. Brungard, Ed.
Request for Comments: 4258 ATT
Category: Informational November 2005
Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON)
自動的に光ネットワーク（ASON）スイッチのルーティング汎用マルチプロトコルラベルスイッチング（GMPLS）の要件
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 (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting Time Division Multiplexing (TDM) connections including Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) and Optical Transport Networks (OTNs).
一般マルチプロトコルラベルスイッチング（GMPLS）プロトコルのスイートは異なるスイッチング技術だけでなく、さまざまなアプリケーションを制御するために定義されています。これらは、同期光ネットワーク（SONET）/同期デジタル階層（SDH）および光トランスポートネットワーク（OTNs）を含む時分割多重（TDM）接続を要求するためのサポートが含まれています。
This document concentrates on the routing requirements placed on the GMPLS suite of protocols in order to support the capabilities and functionalities of an Automatically Switched Optical Network (ASON) as defined by the ITU-T.
この文書では、ITU-Tによって定義されるような自動交換光ネットワーク（ASON）の能力と機能性をサポートするためにプロトコルのGMPLSスイートに載置されたルーティング要件に集中します。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................4
3. ASON Routing Architecture and Requirements ......................4
3.1. Multiple Hierarchical Levels of ASON Routing Areas (RAs) ...5
3.2. Hierarchical Routing Information Dissemination .............6
3.3. Configuration ..............................................8
3.3.1. Configuring the Multi-Level Hierarchy ...............8
3.3.2. Configuring RC Adjacencies ..........................8
3.4. Evolution ..................................................8
3.5. Routing Attributes .........................................8
3.5.1. Taxonomy of Routing Attributes ......................9
3.5.2. Commonly Advertised Information .....................9
3.5.3. Node Attributes ....................................10
3.5.4. Link Attributes ....................................11
4. Security Considerations ........................................12
5. Conclusions ....................................................12
6. Contributors ...................................................15
7. Acknowledgements ...............................................15
8. References .....................................................16
8.1. Normative References ......................................16
8.2. Informative References ....................................16
The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols provides, among other capabilities, support for controlling different switching technologies. These include support for requesting TDM connections utilizing SONET/SDH (see [T1.105] and [G.707], respectively) as well as Optical Transport Networks (OTNs, see [G.709]). However, there are certain capabilities that are needed to support the ITU-T G.8080 control plane architecture for an Automatically Switched Optical Network (ASON). Therefore, it is desirable to understand the corresponding requirements for the GMPLS protocol suite. The ASON control plane architecture is defined in [G.8080]; ASON routing requirements are identified in [G.7715] and in [G.7715.1] for ASON link state protocols. These Recommendations apply to all [G.805] layer networks (e.g., SDH and OTN), and provide protocol-neutral functional requirements and architecture.
プロトコルの一般化マルチプロトコルラベルスイッチング（GMPLS）スイートは、他の機能の中で、異なるスイッチング技術を制御するためのサポートを提供します。これらは、SONET / SDHを利用TDM接続を要求するためのサポート（それぞれ、[T1.105]と[G.707]を参照）と同様に光トランスポートネットワーク（OTNsは、[G.709]を参照）が含まれます。しかし、自動的に交換光ネットワーク（ASON）のためのITU-T G.8080コントロールプレーンアーキテクチャをサポートするために必要な特定の機能があります。したがって、GMPLSプロトコルスイートの対応する要件を理解することが望ましいです。 ASONの制御プレーンアーキテクチャは[G.8080]で定義されています。 ASONルーティング要件は、ASONリンク状態プロトコルの[G.7715]および[G.7715.1]で識別されます。これらの推奨事項は、すべて[G.805]層のネットワーク（例えば、SDH及びOTN）に適用され、プロトコル中立機能要件とアーキテクチャを提供します。
This document focuses on the routing requirements for the GMPLS suite of protocols to support the capabilities and functionality of ASON control planes. This document summarizes the ASON requirements using ASON terminology. This document does not address GMPLS applicability or GMPLS capabilities. Any protocol (in particular, routing) applicability, design, or suggested extensions are strictly outside the scope of this document. ASON (Routing) terminology sections are provided in Appendixes 1 and 2.
この文書では、ASON制御プレーンの機能と機能性をサポートするためのプロトコルのGMPLSスイートのルーティングの要件に焦点を当てています。この文書では、ASON用語を使用してASONの要件をまとめたもの。このドキュメントは、GMPLSの適用性やGMPLS機能には対応していません。適用性、デザイン、または推奨拡張（特に、ルーティングで）任意のプロトコルは、この文書の範囲外に厳密です。 ASON（ルーティング）用語切片を付録1及び2に設けられています。
The ASON routing architecture is based on the following assumptions:
ASONルーティングアーキテクチャは、次の前提に基づいています。
- A network is subdivided based on operator decision and criteria (e.g., geography, administration, and/or technology); the network subdivisions are defined in ASON as Routing Areas (RAs).
- ネットワークは、オペレータの判断及び基準（例えば、地理、投与、および/または技術）に基づいて細分されます。ネットワークサブディビジョンは、ルーティングエリアとしてASON（RAS）で定義されています。
- The routing architecture and protocols applied after the network is subdivided are an operator's choice. A multi-level hierarchy of RAs, as defined in ITU-T [G.7715] and [G.7715.1], provides for a hierarchical relationship of RAs based on containment; i.e., child RAs are always contained within a parent RA. The hierarchical containment relationship of RAs provides for routing information abstraction, thereby enabling scalable routing information representation. The maximum number of hierarchical RA levels to be supported is not specified (outside the scope of this document).
- ネットワークが細分化された後に適用され、ルーティングアーキテクチャとプロトコルは、オペレータの選択です。 、ITU-T [G.7715]と[G.7715.1]で定義されるように、Rasのマルチレベル階層は封じ込めに基づいて、Rasの階層関係を提供します。すなわち、子RAは常に親RA内に含まれています。 Rasの階層的な包含関係は、それによって、スケーラブルなルーティング情報の表現を可能にする、情報の抽象化をルーティングするために提供します。階層RAレベルの最大数（この文書の範囲外）が指定されていないサポートします。
- Within an ASON RA and for each level of the routing hierarchy, multiple routing paradigms (hierarchical, step-by-step, source-based), centralized or distributed path computation, and multiple different routing protocols MAY be supported. The architecture does not assume a one-to-one correspondence between a routing protocol and an RA level, and allows the routing protocol(s) used within different RAs (including child and parent RAs) to be different. The realization of the routing paradigm(s) to support the hierarchical levels of RAs is not specified.
- ASON RA内およびルーティング階層、複数のルーティングパラダイム（階層的、段階的、ソースベース）の各レベルのために、集中型または分散型経路計算、および複数の異なるルーティングプロトコルをサポートすることができます。アーキテクチャは、ルーティングプロトコルとRAのレベルとの間の1対1の対応を想定し、そして（子と親のRAを含む）別のRA内で使用されるルーティングプロトコル（単数または複数）が異なることができません。 Rasの階層レベルをサポートするルーティングパラダイム（S）の実現が指定されていません。
- The routing adjacency topology (i.e., the associated Protocol Controller (PC) connectivity) and transport topology are NOT assumed to be congruent.
- ルーティング隣接トポロジー（すなわち、関連するプロトコルコントローラ（PC）接続）とトランスポートトポロジーは合同であると仮定されません。
- The requirements support architectural evolution, e.g., a change in the number of RA levels, as well as aggregation and segmentation of RAs.
- 要求は、アーキテクチャの進化、例えば、RAレベルの数の変化、ならびに凝集およびRasのセグメンテーションをサポートします。
The description of 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 facilitate management of ASON networks. This description is only conceptual: no physical partitioning of these functions is implied.
ASONルーティングアーキテクチャの記述は、プロトコルの不均一の場合には、エンドツーエンドルーティングをイネーブルにし、ASONネットワークの管理を容易にするための機能構成要素と共通の情報要素の定義で、概念的な参照アーキテクチャを提供します。この説明は、単に概念的なものであり：これらの機能の物理的な分割は暗示されません。
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]に記載されているように解釈されます。
Although [RFC2119] describes interpretations of these key words in terms of protocol specifications and implementations, they are used in this document to describe design requirements for protocol extensions.
[RFC2119]は、プロトコルの仕様と実装の観点からこれらのキーワードの解釈を説明しているが、彼らは、プロトコル拡張のための設計要件を記述するために、このドキュメントで使用されています。
The fundamental architectural concept is the RA and its related functional components (see Appendix 2 on terminology). The routing services offered by an RA are provided by a Routing Performer (RP). An RP is responsible for a single RA, and it MAY be functionally realized using distributed Routing Controllers (RCs). The RC, itself, MAY be implemented as a cluster of distributed entities (ASON refers to the cluster as a Routing Control Domain (RCD)). The RC components for an RA receive routing topology information from their associated Link Resource Manager(s) (LRMs) and store this information in the Routing Information Database (RDB). The RDB is replicated at each RC bounded to the same RA, and MAY contain information about multiple transport plane network layers. Whenever the routing topology changes, the LRM informs the corresponding RC, which in turn updates its associated RDB. In order to ensure RDB synchronization, the RCs cooperate and exchange routing information. Path computation functions MAY exist in each RC, MAY exist on selected RCs within the same RA, or MAY be centralized for the RA.
基本的なアーキテクチャのコンセプトは、RAおよびその関連機能コンポーネント（用語の付録2を参照）です。 RAによって提供されるルーティングサービスは、ルーティング演奏（RP）によって提供されます。 RPは、単一のRAのために責任があり、それが機能的に分散ルーティングコントローラ（RCS）を使用して実現することができます。 RC自体は、分散型エンティティ（ASONルーティング制御ドメイン（RCD）などのクラスタを指す）のクラスタとして実装されてもよいです。 RAのためのRCコンポーネントは、関連リンクリソースマネージャ（複数可）（LRMを）からトポロジルーティング情報を受信して、ルーティング情報データベース（RDB）にこの情報を格納します。 RDBは、各RCで複製される同じRAに囲まれ、そして複数のトランスポート・プレーン・ネットワーク層についての情報を含むことができます。たびルーティングトポロジの変更、LRMは、今度はそれに関連するRDBを更新し、対応するRCを、知らせます。 RDBの同期を確保するために、RCSは協力と交換ルーティング情報。経路計算機能は、同じRA内の選択されたレンジングコードに存在することができ、各RCで存在してもよく、またはRAのために集中されるかもしれません。
In this context, communication between RCs within the same RA is realized using a particular routing protocol (or multiple protocols). In ASON, the communication component is represented by the protocol controller (PC) component(s) and the protocol messages are conveyed over the ASON control plane's Signaling Control Network (SCN). The PC MAY convey information for one or more transport network layers (refer to the note in Section 3.2). The RC is protocol independent, and RC communications MAY be realized by multiple, different PCs within an RA.
この文脈において、同じRA内のRCとの間の通信は、特定のルーティングプロトコル（または複数のプロトコル）を使用して実現されます。 ASONにおいて、通信コンポーネントは、プロトコル制御（PC）成分（S）とASONの制御プレーンの制御シグナリングネットワーク（SCN）で搬送されるプロトコルメッセージによって表されています。 PCは、一の以上のトランスポートネットワーク層（第3.2節でノートを参照してください）のための情報を伝えることができます。 RCはプロトコル独立しており、RC通信がRA内の複数の、異なるPCで実現してもよいです。
The ASON routing architecture defines a multi-level routing hierarchy of RAs based on a containment model to support routing information abstraction. [G.7715.1] defines the ASON hierarchical link state routing protocol requirements for communication of routing information within an RA (one level) to support hierarchical routing information dissemination (including summarized routing information for other levels). The communication between any of the other functional component(s) (e.g., SCN, LRM, and between RCDs (RC-RC communication between RAs)) is outside the scope of [G.7715.1] protocol requirements and, thus, is also outside the scope of this document.
ASONルーティングアーキテクチャは、ルーティング情報の抽象化をサポートするために、封じ込めモデルに基づいて、Rasのマルチレベルのルーティング階層を定義します。 [G.7715.1]（他のレベルの要約ルーティング情報を含む）階層ルーティング情報発信をサポートするために、RA（一段階）内ルーティング情報の通信のためにASON階層リンクステートルーティングプロトコルの要件を定義します。他の機能性成分（複数可）（例えば、SCN、LRM、及びRCDSのRAとの間の（RC-RC通信）との間）のいずれかとの間の通信は、[G.7715.1]プロトコル要件の範囲外であり、したがって、外部でもありますこのドキュメントの範囲。
ASON routing components are identified by identifiers that are drawn from different name spaces (see [G.7715.1]). These are control plane identifiers for transport resources, components, and SCN addresses. The formats of those identifiers in a routing protocol realization SHALL be implementation specific and outside the scope of this document.
ASONルーティング構成要素が異なる名前空間から引き出される識別子によって識別される（[G.7715.1]参照）。これらは、トランスポート・リソース、コンポーネント、およびSCNアドレスの制御プレーン識別子です。ルーティングプロトコルの実現において、これらの識別子の形式は特定し、この文書の範囲外で実装されなければなりません。
The failure of an RC, or the failure of communications between RCs, and the subsequent recovery from the failure condition MUST NOT disrupt calls in progress (i.e., already established) and their associated connections. Calls being set up MAY fail to complete, and the call setup service MAY be unavailable during recovery actions.
RCの故障、またはのRCとの間の通信の障害、および障害状態からその後の回復が進行中のコール（即ち、既に確立された）とそれに関連する接続を破壊してはいけません。設定されているコールが完了するまでに失敗する可能性があり、かつ呼設定サービスは、回復アクション中に使用できない場合があります。
[G.8080] introduces the concept of a Routing Area (RA) in reference to a network subdivision. RAs provide for routing information abstraction. Except for the single RA case, RAs are hierarchically contained: a higher-level (parent) RA contains lower-level (child) RAs that in turn MAY also contain RAs, etc. Thus, RAs contain RAs that recursively define successive hierarchical RA levels.
[G.8080]はネットワークサブディビジョンを参照してルーティングエリア（RA）の概念を導入します。 RAは情報の抽象化をルーティングを提供します。単一RAの場合を除いて、RAは階層的に含まれる：上位（親）RAは、順番にまたのRAを含むことができること下位（子）RAS、等が含ま従って、RAは再帰的に連続した階層的なRAレベルを定義するのRAを含みます。
However, the RA containment relationship describes only an architectural hierarchical organization of RAs. It does not restrict a specific routing protocol's realization (e.g., OSPF multi-areas, path computation, etc.). Moreover, the realization of the routing paradigm to support a hierarchical organization of RAs and the number of hierarchical RA levels to be supported is routing protocol specific and outside the scope of this document.
しかし、RAの包含関係は、RASの唯一の建築階層構造を説明しています。これは、特定のルーティングプロトコルの実現（例えば、OSPFマルチエリア、経路計算など）を制限しません。また、ルーティングパラダイムの実現は、Rasの階層構造と特定し、この文書の範囲外プロトコルをルーティングしているサポートする階層RAレベルの数をサポートします。
In a multi-level hierarchy of RAs, it is necessary to distinguish among RCs for the different levels of the RA hierarchy. Before any pair of RCs establishes communication, they MUST verify that they are bound to the same parent RA (see Section 3.2). An RA identifier (RA ID) is required to provide the scope within which the RCs can communicate. To distinguish between RCs bound to the same RA, an RC identifier (RC ID) is required; the RC ID MUST be unique within its containing RA.
Rasのマルチレベルの階層では、RAの階層の異なるレベルのためのRCを区別することが必要です。 RCの任意のペアが通信を確立する前に、彼らはそれらが同じ親RAにバインドされていることを確かめなければなりません（セクション3.2を参照してください）。 RA識別子（RA ID）は、RCSは通信可能範囲内を提供するために必要とされます。同じRAに結合されたレンジングコードを区別するために、RC識別子（RC ID）が必要です。 RC IDは、それを含むRA内で一意でなければなりません。
An RA represents a partition of the data plane, and its identifier (i.e., RA ID) is used within the control plane as a reference to the data plane partition. Each RA within a carrier's network SHALL be uniquely identifiable. RA IDs MAY be associated with a transport plane name space, whereas RC IDs are associated with a control plane name space.
RAは、データプレーンのパーティションを表し、その識別子（すなわち、RA ID）は、データ・プレーン・パーティションへの参照として、制御プレーン内で使用されています。キャリアのネットワーク内の各RAは、一意に識別されなければなりません。 RC IDはコントロールプレーンの名前空間に関連付けられているのに対し、RA IDは、輸送機の名前空間に関連付けることができます。
Routing information can be exchanged between RCs bound to adjacent 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.
ルーティング情報は、レベルN + 1とレベルNは、レベルN + 1に含まれるのRAを表すN、すなわち、RA階層の隣接するレベルに結合のRCとの間で交換することができます。 RAを接続するリンクは、外部リンク（インターRAリンク）として見ることができる、及びRA内の接続を表すリンクは内部リンク（イントラRAリンク）とみなすことができます。階層の1つのレベルでのRAへの外部リンクは、親RAにおける内部リンクであってもよいです。子RAのイントラRAリンクは親RAの視界から隠すことができます。
The physical location of RCs for adjacent RA levels, their relationship, and their communication protocol(s) are outside the scope of this document. No assumption is made regarding how RCs communicate between adjacent RA levels. If routing information is exchanged between an RC, its parent, and its child RCs, it SHOULD include reachability (see Section 3.5.3) and MAY include, upon policy decision, node and link topology. Communication between RAs only takes place between RCs with a parent/child relationship. RCs of one RA never communicate with RCs of another RA at the same level. There SHOULD not be any dependencies on the different routing protocols used within an RA or in different RAs.
隣接RAレベル、それらの関係、およびそれらの通信プロトコル（単数または複数）のためのRCの物理的な位置は、この文書の範囲外です。何の仮定はRCSが隣接RAレベルとの間の通信方法についてなされていません。ルーティング情報は、RC、その親、そしてその子のRCとの間でやりとりされている場合は、それが到達可能性を含むべきである（セクション3.5.3を参照）、政策決定、ノードとリンクトポロジーにより含むことができます。 RAの間の通信は、親/子関係を持つのRCとの間で行われます。 1 RAのRCSは同じレベルで別のRAのRCを通信することはありません。 RA内または別のRAで使用される別のルーティングプロトコルに依存関係があってはなりません。
Multiple RCs bound to the same RA MAY transform (filter, summarize, etc.) and then forward information to RCs at different levels. However, in this case, the resulting information at the receiving level must be self-consistent (i.e., ensure consistency between transform operations performed on routing information at different levels to ensure proper information processing). This MAY be achieved using a number of mechanisms.
異なるレベルでのRCに同じRAに結合された複数のRC（等、要約、フィルタ）を変換してもよいし、次いでフォワード情報。しかし、この場合には、受信レベルで得られた情報は、自己矛盾のない（すなわち、適切な情報の処理を確保するために、異なるレベルでのルーティング情報に対して実行変換操作の間の一貫性を確保する）でなければなりません。これは、多数の機構を使用して達成することができます。
Note: There is no implied relationship between multi-layer transport networks and multi-level routing. Implementations MAY support a hierarchical routing topology (multi-level) with a single routing protocol instance for multiple transport switching layers or a hierarchical routing topology for one transport switching layer.
注：マルチレイヤトランスポートネットワークとマルチレベルのルーティングの間に暗黙の関係はありません。実装は、複数のトランスポートスイッチング層のための単一のルーティングプロトコルインスタンスまたは1つのトランスポートスイッチング層のための階層的なルーティングトポロジを有する階層的なルーティングトポロジ（マルチレベル）をサポートすることができます。
The type of information flowing upward (i.e., Level N to Level N+1) and the information flowing downward (i.e., Level N+1 to Level N) are used for similar purposes, namely, the exchange of reachability information and summarized topology information to allow routing across multiple RAs. The summarization of topology information may impact the accuracy of routing and may require additional path calculation.
上向きに流れる情報の種類（すなわち、レベルN N + 1レベル）と流下情報（すなわち、レベルNのレベルN + 1）は、同様の目的、すなわち、到達可能性情報の交換及び要約トポロジー情報のために使用されます複数のRA間でルーティングできるようにします。トポロジ情報の要約は、ルーティングの精度に影響を与えることができ、追加の経路計算を必要とするかもしれません。
The following information exchanges are expected:
以下の情報交換が期待されています。
- Level N+1 visibility to Level N reachability and topology (or upward information communication) allowing RC(s) at Level N+1 to determine the reachable endpoints from Level N.
- レベルレベルNの到達可能性およびトポロジー（または上向きの情報通信）にN + 1つの視認性レベルN + 1におけるRC（s）は、レベルNから到達可能なエンドポイントを決定することを可能にします
- Level N visibility to Level N+1 reachability and topology (or downward information communication) allowing RC(s) bounded to an RA at Level N to develop paths to reachable endpoints outside of the RA.
- RC（S）許可レベルNのレベルNの可視+ 1つの到達可能性およびトポロジー（又は下方情報通信）がRAの外部到達エンドポイントへのパスを開発するために、レベルNでRAに囲ま。
When both upward and downward information exchanges contain endpoint reachability information, a feedback loop could potentially be created. Consequently, the routing protocol MUST include a method 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, and
- レベルN + 1 RAのRCに再導入されてからレベルN RAのRCにレベルN + 1 RAのRCから伝播情報を防ぎ、
- 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.
- レベルN-1 RAのRCに再導入されてからレベルN RAのRCにレベルN-1 RAのRCから伝播情報を防ぎます。
The routing protocol SHALL 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. This is a necessary condition to be fulfilled by routing protocols to be loop free.
ルーティング情報を区別するものとルーティングプロトコルは、この情報を同じレベルに別のRCによって転送された場合でも、（外部のRAから受信した）由来のルーティング情報から所定のレベルのRAで発信しました。これは、ループがないことをルーティングプロトコルによって満たされるために必要な条件です。
Two approaches exist for communication between Level N and N+1:
2つのアプローチは、レベルNとNとの間の通信+ 1のために存在します。
- The first approach places an instance of a Level N routing function and an instance of a Level N+1 routing function in the same system. The communications interface is within a single system and is thus not an open interface subject to standardization. However, information re-advertisement or leaking MUST be performed in a consistent manner to ensure interoperability and basic routing protocol correctness (e.g., cost/metric value).
- 第1のアプローチは、レベルNルーティング機能と同じシステムのレベルN + 1つのルーティング機能のインスタンスのインスタンスを配置します。通信インターフェースは、単一のシステム内にあり、従って標準化へのオープンインタフェース受けません。しかし、情報の再広告または漏れは、相互運用性と基本的なルーティングプロトコルの正しさ（例えば、コスト/メトリック値）を確保するために一貫した方法で実行されなければなりません。
- The second approach places the Level N routing function on a separate system from the Level N+1 routing function. In this case, a communication interface must be used between the systems containing the routing functions for different levels. This communication interface and mechanisms are outside the scope of this document.
- 第二のアプローチは、レベルN + 1のルーティング機能とは別のシステム上のレベルNのルーティング機能を配置します。この場合、通信インタフェースは、異なるレベルのルーティング機能を含むシステムとの間で使用されなければなりません。この通信インタフェース及び機構は、この文書の範囲外です。
The RC MUST support static (i.e., operator assisted) and MAY support automated configuration of the information describing its relationship to its parent and its child within the hierarchical structure (including RA ID and RC ID). When applied recursively, the whole hierarchy is thus configured.
RCは、静的（すなわち、オペレータ支援）をサポートしなければならないと（RA IDとRC IDを含む）を階層構造内のその親と子との関係を記述した情報の自動設定をサポートするかもしれません。再帰的に適用される場合、全体の階層は、このように構成されています。
The RC MUST support static (i.e., operator assisted) and MAY support automated configuration of the information describing its associated adjacencies to other RCs within an RA. The routing protocol SHOULD 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).
RCは、静的（すなわち、オペレータ支援）をサポートしなければならなくて、RA内の他のRCにその関連の隣接関係を記述する情報の自動設定をサポートするかもしれません。ルーティングプロトコルは[G.7715]のセクション9に記載のRC隣接関係のすべてのタイプをサポートしなければなりません。後者は（分散RCと）一致トポロジーおよびではハブトポロジーを含む（例えば、後者は自動的に指定されたRCを意味するものではないことに留意されたいです）。
The containment relationships of RAs may change, motivated by events such as mergers, acquisitions, and divestitures.
Rasの包含関係は、合併、買収、および売却などのイベントにより動機付け、変更することができます。
The routing protocol SHOULD be capable of supporting architectural evolution in terms of the number of hierarchical levels of RAs, as well as the aggregation and segmentation of RAs. RA ID uniqueness within an administrative domain may facilitate these operations. The routing protocol is not expected to automatically initiate and/or execute these operations. Reconfiguration of the RA hierarchy may not disrupt calls in progress, though calls being set up may fail to complete, and the call setup service may be unavailable during reconfiguration actions.
ルーティングプロトコルは、RASの階層レベルの数、ならびに凝集およびRasのセグメンテーションの観点アーキテクチャ進化をサポートすることができなければなりません。管理ドメイン内のRA IDの一意性は、これらの操作を容易にすることができます。ルーティングプロトコルは、これらの操作を自動的に開始および/または実行することが予想されていません。設定された呼び出しが完了しないことがあり、かつ呼設定サービスは、再構成アクション中に使用できないかもしれないがRA階層の再構成は、進行中のコールを妨害しないことがあります。
Routing for transport networks is performed on a per-layer basis, where the routing paradigms MAY differ among layers and within a layer. Not all equipment supports the same set of transport layers or the same degree of connection flexibility at any given layer. A server layer trail may support various clients, involving different adaptation functions. In addition, equipment may support variable adaptation functionality, whereby a single server layer trail dynamically supports different multiplexing structures. As a result, routing information MAY include layer-specific, layer-independent, and client/server adaptation information.
トランスポートネットワークのためのルーティングは、ルーティングパラダイムは、層の間及び層内で異なっていてもよいあたり層基づき、上で行われます。いないすべての機器は、トランスポート層または任意の層での接続の柔軟性の同程度の同じセットをサポートしています。サーバ層の道は、異なる適応機能を含む、さまざまなクライアントをサポートすることができます。加えて、装置は、単一のサーバ層の道を動的異なる多重化構造をサポートすることにより、可変適応機能をサポートしてもよいです。結果として、ルーティング情報は、レイヤ固有の、層に依存し、およびクライアント/サーバアダプテーション情報を含むことができます。
Attributes can be organized according to the following categories:
属性は、次のカテゴリに応じて整理することができます。
- Node related or link related
- ノード関連リンク関連
- Provisioned, negotiated, or automatically configured
- 、プロビジョニング交渉し、または自動的に設定
- Inherited or layer specific (client layers can inherit some attributes from the server layer, while other attributes such as Link Capacity are specified by layer)
- 継承または層の特定の（例えば、リンク容量などの他の属性は、層によって指定されている間、クライアント層は、サーバ層からのいくつかの属性を継承することができます）
(Component) link attributes MAY be statically or automatically configured for each transport network layer. This may lead to unnecessary repetition. Hence, the inheritance property of attributes MAY also be used to optimize the configuration process.
（成分）リンク属性は、静的に又は自動的に各トランスポートネットワーク層のために構成されてもよいです。これは、不必要な繰り返しにつながる可能性があります。従って、属性の継承プロパティも設定プロセスを最適化するために使用されるかもしれません。
ASON uses the term SubNetwork Point (SNP) for the control plane representation of a transport plane resource. The control plane representation and transport plane topology are NOT assumed to be congruent; the control plane representation SHALL not be restricted by the physical topology. The relational grouping of SNPs for routing is termed an SNP Pool (SNPP). The routing function understands topology in terms of SNPP links. Grouping MAY be based on different link attributes (e.g., SRLG information, link weight, etc).
ASONは、トランスポート・プレーン・リソースの制御平面表現の長期サブネットワークポイント（SNP）を使用します。制御平面表現と搬送面トポロジーは合同であると仮定されていません。コントロールプレーンの表現は、物理トポロジによって限定されるものではありません。ルーティングのためのSNPの関係グループはSNPプール（SNPP）と呼ばれます。ルーティング機能はSNPPリンクの面でトポロジーを理解しています。グルーピングは、異なるリンク属性（例えば、SRLG情報、リンク重み、など）に基づいてもよいです。
Two RAs may be linked by one or more SNPP links. Multiple SNPP links may be required when component links are not equivalent for routing purposes with respect to the RAs to which they are attached, to the containing RA, or when smaller groupings are required.
二つのRAは、一つ以上のSNPPリンクによってリンクされてもよいです。コンポーネントリンクがそれらが結合しているのRAに対して目的をルーティングするための等価でない場合、複数のSNPPリンクを含むRAに、必要とされ得る、またはより小さなグループが必要とされる場合。
Advertisements MAY contain the following common set of information regardless of whether they are link or node related:
広告は関係なく、リンクまたはノードに関連しているかどうかの情報を、以下の共通セットが含まれる場合があります。
- RA ID of the RA to which the advertisement is bounded
- 広告が制限されているためにRAのRA ID
- RC ID of the entity generating the advertisement
- RCエンティティのIDは、広告を作成します
- Information to uniquely identify advertisements
- ユニークな広告を識別するための情報
- Information to determine whether an advertisement has been updated
- 広告が更新されているかどうかを判断するための情報
- Information to indicate when an advertisement has been derived from a different level RA
- 広告が異なるレベルRAから導出されたときを示すための情報
All nodes belong to an RA; hence, the RA ID can be considered an attribute of all nodes. Given that no distinction is made between abstract nodes and those that cannot be decomposed any further, the same attributes MAY be used for their advertisement. In the following tables, Capability refers to the level of support required in the realization of a link state routing protocol, whereas Usage refers to the degree of operational control that SHOULD be available to the operator.
すべてのノードがRAに属します。したがって、RA IDは、すべてのノードの属性とみなすことができます。何の区別は抽象ノードおよび任意のさらなる分解できないものとの間で行われていないことを考えると、同じ属性は、その広告のために使用されるかもしれません。使用法はオペレータに利用可能であるべき動作制御の程度を指すのに対し、以下の表に、機能は、リンクステートルーティングプロトコルの実現に必要なサポートのレベルを指します。
The following Node Attributes are defined:
以下のノード属性が定義されています。
Attribute Capability Usage
----------- ----------- ---------
Node ID REQUIRED REQUIRED
Reachability REQUIRED OPTIONAL
Table 1. Node Attributes
表1.ノード属性
Reachability information describes the set of endpoints that are reachable by the associated node. It MAY be advertised as a set of associated external (e.g., User Network Interface (UNI)) address/address prefixes or a set of associated SNPP link IDs/SNPP ID prefixes, the selection of which MUST be consistent within the applicable scope. These are control plane identifiers; the formats of these identifiers in a protocol realization are implementation specific and outside the scope of this document.
到達可能性情報は、関連するノードによって到達可能であるエンドポイントのセットを記述する。これは、関連する外部（例えば、ユーザネットワークインタフェース（UNI））アドレス/アドレスプレフィクスのセットまたは関連SNPPのリンクID / SNPPのIDプレフィックスの集合として宣伝されてもよく、の選択は、適用範囲内で一致していなければなりません。これらは、制御プレーン識別子です。プロトコルの実現にこれらの識別子の形式は特定し、この文書の範囲外で実装されています。
Note: No distinction is made between nodes that may have further internal details (i.e., abstract nodes) and those that cannot be decomposed any further. Hence, the attributes of a node are not considered as only single-switch attributes but MAY apply to a node at a higher level of the hierarchy that represents a subnetwork.
注：区別はさらに内部の詳細（すなわち、抽象ノード）と任意のさらに分解することができないものを有していてもよく、ノード間で行われていません。したがって、ノードの属性は、単一のスイッチ属性として考慮されていないが、サブネットワークを表す階層のより高いレベルのノードに適用することができます。
The following Link Attributes are defined:
以下のリンク属性が定義されています。
Link Attribute Capability Usage
--------------- ----------- ---------
Local SNPP link ID REQUIRED REQUIRED
Remote SNPP link ID REQUIRED REQUIRED
Layer Specific Characteristics see Table 3
Table 2. Link Attributes
表2のリンク属性
The SNPP link ID MUST be sufficient to uniquely identify (within the Node ID scope) the corresponding transport plane resource, taking into account the separation of data and control planes (see Section 3.5.1; the control plane representation and transport plane topology are not assumed to be congruent). The SNPP link ID format is routing protocol specific.
SNPPリンクIDは、アカウントにデータおよび制御プレーンの分離をとる対応するトランスポート・プレーンリソースは、（セクション3.5.1参照（ノードIDの範囲内で）一意に識別するのに十分なものでなければならない、制御平面表現と輸送面トポロジありません）に合同であると想定。 SNPPリンクIDのフォーマットは、プロトコル特定ルーティングされます。
Note: When the remote end of an SNPP link is located outside of the RA, the remote SNPP link ID is OPTIONAL.
注：SNPPリンクのリモート側がRAの外側に配置されている場合、リモートSNPPリンクIDは任意です。
The following link characteristic attributes are defined:
次のリンク特性の属性が定義されています。
- Signal Type: This identifies the characteristic information of the layer network.
- シグナルタイプ：これはレイヤネットワークの特性情報を識別します。
- Link Weight: This is the metric indicating the relative desirability of a particular link over another, e.g., during path computation.
- リンク重さ：これは、経路計算中に他の上の特定のリンク、例えば、の相対的な望ましさを示すメトリックです。
- Resource Class: This corresponds to the set of administrative groups assigned by the operator to this link. A link MAY belong to zero, one, or more administrative groups.
- リソースクラス：これは、このリンクにオペレータによって割り当てられた管理グループのセットに対応します。リンクは、ゼロ、1、または複数の管理グループに属していてもよいです。
- Local Connection Types: This attribute identifies whether the local SNP represents a Termination Connection Point (CP), a Connection Point (CP), or can be flexibly configured as a TCP.
- ローカル接続タイプ：この属性は、ローカルSNPは、終端接続ポイント（CP）、接続ポイント（CP）を表し、又は柔軟TCPとして構成することができるかどうかを識別する。
- Link Capacity: This provides the sum of the available and potential bandwidth capacity for a particular network transport layer. Other capacity measures MAY be further considered.
- リンク容量：これは、特定のネットワーク・トランスポート層のために利用可能と潜在的な帯域幅容量の合計を提供します。その他の容量の対策をさらに考慮することができます。
- Link Availability: This represents the survivability capability such as the protection type associated with the link.
- リンクの可用性：これは、このようなリンクに関連付けられている保護タイプとして存続可能性を表しています。
- Diversity Support: This represents diversity information such as the SRLG information associated with the link.
- 多様性のサポート：これは、リンクに関連するSRLG情報などの多様性情報を表します。
- Local Adaptation Support: This indicates the set of client layer adaptations supported by the TCP associated with the local SNPP. This is applicable only when the local SNP represents a TCP or can be flexibly configured as a TCP.
- 現地適応のサポート：これはローカルSNPPに関連付けられているTCPによってサポートされているクライアント層の適応のセットを示します。これは、ローカルSNPは、TCPを表すか、または柔軟TCPとして構成することができる場合にのみ適用可能です。
Link Characteristics Capability Usage
----------------------- ---------- ---------
Signal Type REQUIRED OPTIONAL
Link Weight REQUIRED OPTIONAL
Resource Class REQUIRED OPTIONAL
Local Connection Types REQUIRED OPTIONAL
Link Capacity REQUIRED OPTIONAL
Link Availability OPTIONAL OPTIONAL
Diversity Support OPTIONAL OPTIONAL
Local Adaptation Support OPTIONAL OPTIONAL
Table 3. Link Characteristics
表3リンク特性
Note: Separate advertisements of layer-specific attributes MAY be chosen. However, this may lead to unnecessary duplication. This can be avoided using the inheritance property, so that the attributes derivable from the local adaptation information do not need to be advertised. Thus, an optimization MAY be used when several layers are present by indicating when an attribute is inheritable from a server layer.
注意：レイヤー固有の属性の別々の広告を選択することができます。しかし、これは不要な重複につながる可能性があります。局所順応情報から誘導属性は宣伝する必要がないように、これは、継承プロパティを使用して回避することができます。いくつかの層は、属性は、サーバレイヤから継承されたときに示すことによって存在する場合したがって、最適化が使用されてもよいです。
The ASON routing protocol MUST deliver the operational security objectives where required. The overall security objectives (defined in ITU-T Recommendation [M.3016]) of confidentiality, integrity, and accountability may take on varying levels of importance. These objectives do not necessarily imply requirements on the routing protocol itself, and MAY be met by other established means.
ASONルーティングプロトコルは、必要な運用上のセキュリティ目標を実現しなければなりません。機密性、完全性、およびアカウンタビリティの（ITU-T勧告[M.3016]で定義された）全体的なセキュリティの目標は、重要性の様々なレベルをとることができます。これらの目的は、必ずしもルーティングプロトコル自体の要件を意味するものではありませんし、他の確立の手段によって満たすことができます。
Note: A threat analysis of a proposed routing protocol SHOULD address masquerade, eavesdropping, unauthorized access, loss or corruption of information (including replay attacks), repudiation, forgery, and denial of service attacks.
提案されたルーティングプロトコルの脅威分析は（リプレイアタックを含む）情報のなりすまし、盗聴、不正アクセス、紛失または破損に対処すべきである、否認、偽造、及びサービス拒否攻撃注：。
The description of the ASON routing architecture and components is provided in terms of routing functionality. This description is only conceptual: no physical partitioning of these functions is implied.
ASONルーティングアーキテクチャおよびコンポーネントの説明は、機能ルーティングの面に設けられています。この説明は、単に概念的なものであり：これらの機能の物理的な分割は暗示されません。
In summary, the ASON routing architecture assumes:
要約すると、ASONルーティングアーキテクチャは前提としています。
- A network is subdivided into ASON RAs, which MAY support multiple routing protocols; no one-to-one relationship SHALL be assumed.
- ネットワークは、複数のルーティングプロトコルをサポートすることができる、ASONバーRASに細分されます。 1対1の関係が想定されてはなりません。
- Routing Controllers (RCs) provide for the exchange of routing information (primitives) for the RA. The RC is protocol independent and MAY be realized by multiple, different protocol controllers within an RA. The routing information exchanged between RCs SHALL be subject to policy constraints imposed at reference points (External- and Internal-NNI).
- ルーティングコントローラ（RCS）RAのための情報（プリミティブ）ルーティングの交換を提供します。 RCはプロトコル独立しており、RA内の複数の異なるプロトコルコントローラによって実現されてもよいです。 RCとの間で交換ルーティング情報は、基準点（External-と内部-NNI）で課されるポリシーの制約を受けなければなりません。
- In a multi-level RA hierarchy based on containment, communication between RCs of different RAs happens only when there is a parent/child relationship between the RAs. RCs of child RAs never communicate with the RCs of other child RAs. There SHOULD not be any dependencies on the different routing protocols used within a child RA and that of its parent. The routing information exchanged within the parent RA SHALL be independent of both the routing protocol operating within a child RA and any control distribution choice(s), e.g., centralized, fully distributed.
- RAの間の親/子関係がある場合にのみ閉じ込めに基づくマルチレベルRA階層で、異なるRasのレンジングコードとの間の通信が起こります。子のRAのRCSは他の子のRAのRCを通信することはありません。子供RAとその親のもの内で使用される別のルーティングプロトコルに依存関係があってはなりません。親RA内で交換ルーティング情報は、子RAと任意の制御分布の選択（複数可）、例えば、集中型、完全分散型内で動作するルーティングプロトコルの両方を独立していなければなりません。
- For an RA, the set of RCs is referred to as an ASON routing (control) domain. The routing information exchanged between routing domains (inter-RA, i.e., inter-domain) SHALL be independent of both the intra-domain routing protocol(s) and the intra-domain control distribution choice(s), e.g., centralized, fully distributed. RCs bounded to different RA levels MAY be collocated within the same physical element or physically distributed.
- RAのため、RCのセットは、ASONルーティング（コントロール）ドメインと呼ばれます。ルーティング情報は、ルーティングドメイン（インターRA、すなわち、ドメイン間）、例えば、集中は、完全分散型ドメイン内ルーティングプロトコル（複数可）とドメイン内の制御分布の選択（複数可）、両方の独立していなければならないとの間で交換しました。 RCSは、同じ物理的要素内に並置又は物理的に分散させることができる異なるRAレベルに囲ま。
- The routing adjacency topology (i.e., the associated PC connectivity topology) and the transport network topology SHALL NOT be assumed to be congruent.
- ルーティング隣接トポロジー（すなわち、関連したPCとの接続トポロジー）とトランスポートネットワークトポロジは合同であると仮定することがないもの。
- The routing topology SHALL support multiple links between nodes and RAs.
- ルーティングトポロジは、ノードとRASとの間の複数のリンクをサポートしなければなりません。
In summary, the following functionality is expected from GMPLS routing to instantiate the ASON hierarchical routing architecture realization (see [G.7715] and [G.7715.1]):
要約すると、以下の機能が（[G.7715]と[G.7715.1]参照）ASON階層ルーティングアーキテクチャの実現をインスタンス化するGMPLSルーティングから期待されています。
- RAs SHALL be uniquely identifiable within a carrier's network, each having a unique RA ID within the carrier's network.
- RAは、各キャリアのネットワーク内でユニークなRA IDを有し、キャリアのネットワーク内で一意に識別されなければなりません。
- Within an 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つのレベル）内では、ルーティングプロトコルは、Rasの複数階層のアーキテクチャをサポートするために（他のレベルのための要約ルーティング情報を含む）階層ルーティング情報の普及をサポートします。ルーティングプロトコルによってサポートされる階層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 subnetwork 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 RDBs become synchronized after a period of time.
- ルーティングプロトコルは、分散型のRDBは、一定期間後に同期なるように収束するものとします。
To support hierarchical routing information dissemination within an RA, the routing protocol MUST deliver:
RA内の階層型ルーティング情報発信をサポートするために、ルーティングプロトコルが提供しなければなりません：
- 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 RC to RC(s) at different levels when multiple RCs are bound to a single RA.
- 任意の変換から得られた受信レベルでの自己一貫性情報（フィルタを、等、要約）と異なるレベルで1つのRCからRC（S）への情報の転送複数のRCが単一のRAに結合されています。
- A mechanism to prevent the 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.
- この情報が最初に受信された隣接するレベルRAのRCに戻すレベルN RAのRCに伝播情報の再導入を防止するための機構。
In order to support operator-assisted changes in the containment relationships of RAs, the routing protocol SHALL support evolution in terms of the number of hierarchical levels of RAs. For example: support of non-disruptive operations such as adding and removing 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. The number of hierarchical levels to be supported is routing protocol specific and reflects a containment relationship; e.g., an RA insertion involves supporting a different routing protocol domain in a portion of the network.
Rasの包含関係におけるオペレータ支援変更をサポートするために、ルーティングプロトコルは、RASの階層レベルの数の点で進化をサポートしなければなりません。たとえば、次のような階層階層の中央に又はからRasのレベル、ならびに凝集およびRasのセグメントを追加または削除、階層の最上部/底部でのRAの追加や削除などの無停止の動作のサポート。サポートされる階層の数は、ルーティングプロトコル固有のものであり、包含関係を反映しています。例えば、RA挿入は、ネットワークの一部に異なるルーティングプロトコルドメインをサポートすることを含みます。
Reachability information (see Section 3.5.3) of the set of endpoints reachable by a node may be advertised either as a set of UNI Transport Resource addresses/address prefixes or a set of associated 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 an RA should not restrict the choice of routing protocols for use in other RAs (child or parent).
ノードにより到達可能なエンドポイントのセットの到達可能性情報（セクション3.5.3参照）、いずれかのUNIトランスポートリソースアドレス/アドレスプレフィックスまたは関連SNPPのリンクID / SNPPリンクIDプレフィックスの集合の組としてアドバタイズ割り当てられ、選択されてもよいです一貫してその適用範囲インチプロトコル実現における制御プレーン識別子の形式は実装特有です。 RA内のルーティングプロトコルの使用は、他のRA（子または親）で使用するためのルーティングプロトコルの選択を制限するべきではありません。
As ASON does not restrict the control plane architecture choice used, either a collocated architecture or a physically separated architecture may be used. A collection of links and nodes such as a subnetwork 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 document is the result of the CCAMP Working Group ASON Routing Requirements design team joint effort. The following are the design team member authors who contributed to the present document:
この文書では、CCAMPワーキンググループASONルーティング要件の設計チームの共同の努力の結果です。以下、本文書に貢献し、設計チームのメンバーの作者です：
Wesam Alanqar (Sprint) Deborah Brungard (ATT) David Meyer (Cisco Systems) Lyndon Ong (Ciena) Dimitri Papadimitriou (Alcatel) Jonathan Sadler (Tellabs) Stephen Shew (Nortel)
Wesam Alanqar（スプリント）デボラBrungard（ATT）デビッド・マイヤー（シスコシステムズ）リンドンオング（シエナ）ディミトリPapadimitriou（アルカテル）ジョナサン・サドラー（テラブス）スティーブン供え（ノーテル）
The authors would like to thank Kireeti Kompella for having initiated the proposal of an ASON Routing Requirement Design Team and the ITU-T SG15/Q14 for their careful review and input.
著者は、ASONルーティング要件設計チームとその慎重に検討し、入力のためのITU-T SG15 / Q14の提案を開始したためKireeti Kompellaに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
For information on the availability of the following documents, please see http://www.itu.int:
次の書類の入手については、http://www.itu.intを参照してください。
[G.707] ITU-T Rec. G.707/Y.1322, "Network Node Interface for the Synchronous Digital Hierarchy (SDH)", December 2003.
[G.707] ITU-T勧告。 、2003年12月G.707 / Y.1322、 "同期デジタル階層（SDH）のためのネットワークノードインタフェース"。
[G.709] ITU-T Rec. G.709/Y.1331, "Interfaces for the Optical Transport Network (OTN)", March 2003.
[G.709] ITU-T勧告。 、2003年3月G.709 / Y.1331、 "オプティカルトランスポートネットワーク（OTN）用のインタフェース"。
[G.7715] ITU-T Rec. G.7715/Y.1306, "Architecture and Requirements for the Automatically Switched Optical Network (ASON)", June 2002.
[G.7715] ITU-T勧告。 、2002年6月G.7715 / Y.1306、「自動的に交換光ネットワーク（ASON）のためのアーキテクチャと要件」。
[G.7715.1] ITU-T Draft Rec. G.7715.1/Y.1706.1, "ASON Routing Architecture and Requirements for Link State Protocols", November 2003.
【G.7715.1] ITU-Tドラフト撮影。 G.7715.1 / Y.1706.1、「ASONルーティングアーキテクチャとリンクステートプロトコルのための要件」、2003年11月。
[G.805] ITU-T Rec. G.805, "Generic Functional Architecture of Transport Networks", March 2000.
[G.805] ITU-T勧告。 G.805、「トランスポート・ネットワークの一般的な機能アーキテクチャ」、2000年3月。
[G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the Automatically Switched Optical Network (ASON)", November 2001 (and Revision, January 2003).
[G.8080] ITU-T勧告。 G.8080 / Y.1304、2001年11月（および改訂、2003年1月） "を自動的に交換光ネットワーク（ASON）のためのアーキテクチャ"。
[M.3016] ITU-T Rec. M.3016.0, "Security for the Management Plane: Overview", May 2005.
[M.3016] ITU-T勧告。 M.3016.0、「管理プレーンのセキュリティ：概要」、2005年5月。
[T1.105] ANSI T1.105, "Synchronous Optical Network (SONET) - Basic Description including Multiplex Structure, Rates, and Formats", 2001.
[T1.105] ANSI T1.105、 "同期光ネットワーク（SONET） - 多重構造、料金、およびフォーマットを含む基本的な説明"、2001年。
Appendix 1: ASON Terminology
付録1：ASON用語
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]の目的のために、管理ドメインは、ネットワークオペレータ、サービスプロバイダ、またはエンドとしてシングルプレーヤーに属するリソースの程度を表しますユーザー。異なるプレイヤーの管理ドメインは、それ自体で重複していません。
Adaptation function (see Recommendation [G.805]): A "transport processing function" that processes the client layer information for transfer over a server layer trail.
適応機能（勧告[G.805]を参照）：サーバー層トレイル上に転送するためのクライアント層情報を処理し、「トランスポート処理機能」。
Client/Server relationship: The association between layer networks that is performed by an "adaptation" function to allow the link connection in the client layer network to be supported by a trail in the server layer network.
クライアント/サーバーの関係：クライアントレイヤネットワークにおけるリンク接続を許可するように「適応」機能によって行われる層のネットワーク間の関連付けは、サーバレイヤネットワークにおけるトレイルによってサポートされます。
Control plane: Performs the call control and connection control functions. Through signaling, the control plane sets up and releases connections and may restore a connection in case of a failure.
コントロールプレーンは、呼制御と接続制御機能を実行します。シグナリングを介して、制御プレーンがセットアップ及びリリース接続が故障した場合の接続を復元することができます。
(Control) Domain: Represents a collection of (control) entities that are grouped for a particular purpose. The control plane is subdivided into domains matching administrative domains. Within an administrative domain, further subdivisions of the control plane are recursively applied. A routing control domain is an abstract entity that hides the details of the RC distribution.
（コントロール）ドメイン：特定の目的のためにグループ化されている（制御）エンティティのコレクションを表します。制御プレーンは、管理ドメインに一致するドメインに細分されます。管理ドメイン内に、制御プレーンのさらなる細分化を再帰的に適用されます。経路制御ドメインは、RC分布の詳細を隠蔽する抽象エンティティです。
External NNI (E-NNI): Interfaces are located between protocol controllers between control domains.
外部NNI（E-NNI）：インタフェースは、制御ドメインとの間のプロトコルコントローラとの間に配置されています。
Internal NNI (I-NNI): Interfaces are located between protocol controllers within control domains.
内部NNI（I-NNI）：インタフェースは、制御ドメイン内のプロトコルコントローラとの間に配置されています。
Link (see Recommendation [G.805]): A "topological component" that describes a fixed relationship between a "subnetwork" or "access group" and another "subnetwork" or "access group". Links are not limited to being provided by a single server trail.
リンク（勧告[G.805]を参照）：「サブ」または「アクセスグループ」と別の「サブネットワーク」または「アクセスグループ」との間の一定の関係を記述する「トポロジー成分」。リンクは、単一のサーバ証跡によって提供されることに限定されません。
Management plane: Performs management functions for the transport plane, the control plane, and the system as a whole. It also provides coordination between all the planes. The following management functional areas are performed in the management plane: performance, fault, configuration, accounting, and security management.
管理プレーンは：トランスポート・プレーン、コントロールプレーン、およびシステム全体の管理機能を実行します。また、すべての面の間の調整を提供します。パフォーマンス、障害、設定、アカウンティング、およびセキュリティ管理：以下の管理機能領域は、管理プレーンで実行されています。
Management domain (see Recommendation [G.805]): A management domain defines a collection of managed objects that are grouped to meet organizational requirements according to geography, technology, policy, or other structure, and for a number of functional areas such as configuration, security, (FCAPS), for the purpose of providing control in a consistent manner. Management domains can be disjoint, contained, or overlapping. As such, the resources within an administrative domain can be distributed into several possible overlapping management domains. The same resource can therefore belong to several management domains simultaneously, but a management domain shall not cross the border of an administrative domain.
管理ドメイン（勧告[G.805]を参照）：管理ドメインは、地理学、技術、政策、または他の構造に応じて、組織の要件を満たすためにグループ化された管理対象オブジェクトのコレクションを定義し、このような構成などの機能領域の数について、一貫した方法で制御を提供する目的のためのセキュリティ、（FCAPS）。管理ドメインが含まれる、互いに素、または重複することができます。このように、管理ドメイン内のリソースは、いくつかの可能な重複管理ドメイン内に分布させることができます。同じリソースは、したがって、同時に複数の管理ドメインに属することができますが、管理ドメインは、管理ドメインの境界を越えてはなりません。
Multiplexing (see Recommendation [G.805]): Multiplexing techniques are used to combine client layer signals. The many-to-one relationship represents the case of several link connections of client layer networks supported by one server layer trail at the same time.
多重化（勧告[G.805]を参照）：多重化技術は、クライアントレイヤ信号を合成するために使用されています。多対1の関係は、同時に1つのサーバ層の道でサポートされているクライアントレイヤネットワークの複数のリンク接続の場合を表しています。
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 (see Recommendation [G.805]): A "transport entity" that consists of an associated pair of "unidirectional trails" capable of simultaneously transferring information in opposite directions between their respective inputs and outputs.
トレイル（勧告[G.805]を参照）、同時にそれぞれの入力と出力との間に逆方向に情報を転送することが可能な「一方向トレイル」の関連する対から成る「輸送実体」。
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 the [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基準点に関連付けられたルーティング機能は存在しません。
Variable adaptation function: A single server layer trail may dynamically support different multiplexing structures, i.e., link connections for multiple client layer networks.
可変適応機能：単一のサーバ層の道は、動的に異なる多重構造、複数のクライアントレイヤネットワークのための、すなわち、リンクの接続をサポートすることができます。
Appendix 2: ASON Routing Terminology
付録2：ASONルーティング用語
This document makes use of the following terms:
このドキュメントでは、次の用語を使用します：
Routing Area (RA): An RA represents a partition of the data plane, and its identifier is used within the control plane as the representation of this partition. Per [G.8080], an RA is defined by a set of 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): Repository for the local topology, network topology, reachability, and other routing information that is updated as part of the routing information exchange and may additionally contain information that is configured. The RDB may contain routing information for more than one Routing Area (RA).
ルーティングデータベース（RDB）：ルーティング情報交換の一部として更新され、さらに構成されている情報を含むことができるローカル・トポロジ、ネットワークトポロジ、到達可能性、および他のルーティング情報のリポジトリ。 RDBは、複数のルーティングエリア（RA）のためのルーティング情報を含んでいてもよいです。
Routing Components: ASON routing architecture functions. These functions can be classified as protocol independent (Link Resource Manager or LRM, Routing Controller or RC) 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上で操作してのRCをピアリングとルーティング情報を交換するために必要なハンドル（アブストラクト）情報。 RCは、RDBのビューへのアクセスを持っています。 RCはプロトコルに依存しています。
Note: Since the RDB may contain routing information pertaining to multiple RAs (and possibly to multiple layer networks), the RCs accessing the RDB may share the routing information.
注：RDBは、複数のRA（および場合によっては複数層ネットワークへ）に関連するルーティング情報を含むかもしれないので、RDBにアクセスRCSはルーティング情報を共有することができます。
Link Resource Manager (LRM): Supplies all the relevant component and Traffic Engineering (TE) link information to the RC. It informs the RC about any state changes of the link resources it controls.
リンクリソースマネージャ（LRM）：RCに関連するすべてのコンポーネントおよびトラフィックエンジニアリング（TE）リンク情報を提供します。それはそれが制御するリンクリソースのいずれかの状態の変化についてのRCを通知します。
Protocol Controller (PC): Handles protocol-specific message exchanges according to the reference point over which the information is exchanged (e.g., E-NNI, I-NNI), and internal exchanges with the RC. The PC function is protocol dependent.
プロトコルコントローラ（PC）は：情報が交換される上の基準点（例えば、E-NNI、I-NNI）によれば、プロトコル固有のメッセージ交換を処理し、RCと内部交換。 PCの機能は、プロトコルに依存しています。
Authors' Addresses
著者のアドレス
Wesam Alanqar Sprint
Wesam Alanqarスプリント
EMail: wesam.alanqar@mail.sprint.com
メールアドレス：wesam.alanqar@mail.sprint.com
Deborah Brungard, Ed. AT&T Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ 07748, USA
デボラBrungard、エド。 AT＆T Rmの。 D1-3C22 - 200 S.ローレルアベニュー。ミドルタウン、NJ 07748、USA
Phone: +1 732 4201573 EMail: dbrungard@att.com
電話：+1 732 4201573 Eメール：dbrungard@att.com
David Meyer Cisco Systems
デビッド・マイヤーシスコシステムズ
EMail: dmm@1-4-5.net
メールアドレス：dmm@1-4-5.net
Lyndon Ong Ciena Corporation 5965 Silver Creek Valley Rd, San Jose, CA 95128, USA
リンドン・オングCienaの株式会社5965シルバークリークバレーRdを、サンノゼ、CA 95128、USA
Phone: +1 408 8347894 EMail: lyong@ciena.com
電話：+1 408 8347894 Eメール：lyong@ciena.com
Dimitri Papadimitriou Alcatel Francis Wellensplein 1, B-2018 Antwerpen, Belgium
ディミトリPapadimitriouアルカテルフランシスVellensplein 1 B-2018アントワープ、Velgiom
Phone: +32 3 2408491 EMail: dimitri.papadimitriou@alcatel.be
電話：+32 3 2408491 Eメール：dimitri.papadimitriou@alcatel.be
Jonathan Sadler 1415 W. Diehl Rd Naperville, IL 60563
ジョナサン・サドラー1415 W. DiehlのRdのネーパーヴィル、IL 60563
EMail: jonathan.sadler@tellabs.com
メールアドレス：jonathan.sadler@tellabs.com
Stephen Shew Nortel Networks PO Box 3511 Station C Ottawa, Ontario, CANADA K1Y 4H7
スティーブン供えNortel Networksの私書箱3511駅のCオタワ、オンタリオ、カナダK1Y 4H7
Phone: +1 613 7632462 EMail: sdshew@nortelnetworks.com
電話：+1 613 7632462 Eメール：sdshew@nortelnetworks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。