[要約] 要約：RFC 4258は、ASONにおけるGMPLSルーティングの要件を定義しています。 目的：ASONにおけるGMPLSルーティングの効率的な実装と運用を支援するために、要件を明確化することを目的としています。
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).
Copyright（c）The Internet Society（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）および光学輸送ネットワーク（OTN）を含む、時分割多重化（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（それぞれ[T1.105]と[G.707]をそれぞれ参照）を使用してTDM接続を要求するためのサポートと光輸送ネットワーク（OTNS、[G.709]を参照）が含まれます。ただし、自動化された光ネットワーク（ASON）のITU-T G.8080制御プレーンアーキテクチャをサポートするために必要な特定の機能があります。したがって、GMPLSプロトコルスイートの対応する要件を理解することが望ましいです。ASONコントロールプレーンアーキテクチャは[G.8080]で定義されています。ASONルーティングの要件は、[G.7715]および[G.7715.1]でAson Link State Protocolsの[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のマルチレベルの階層は、封じ込めに基づくRAの階層的関係を提供します。つまり、子供の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を含む）内で使用されるルーティングプロトコルを異なることを許可します。RAの階層レベルをサポートするためのルーティングパラダイムの実現は指定されていません。
- 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レベルの数の変化、およびRAの集約とセグメンテーションなど、建築の進化をサポートしています。
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の原因であり、分散ルーティングコントローラー（RC）を使用して機能的に実現することができます。RC自体は、分散エンティティのクラスターとして実装できます（ASONは、クラスターをルーティング制御ドメイン（RCD）と呼びます）。RAのRCコンポーネントは、関連するLink Resource Manager（S）（LRMS）からルーティングトポロジ情報を受信し、この情報をルーティング情報データベース（RDB）に保存します。RDBは、同じRAに囲まれた各RCで複製されており、複数の輸送平面ネットワークレイヤーに関する情報が含まれている場合があります。ルーティングトポロジが変更されるたびに、LRMは対応するRCを通知し、関連するRDBを更新します。RDBの同期を確保するために、RCSは協力してルーティング情報を交換します。パス計算関数は、各RCに存在する場合、同じ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）コンポーネントで表され、プロトコルメッセージはASONコントロールプレーンのシグナルコントロールネットワーク（SCN）を介して伝えられます。PCは、1つ以上の輸送ネットワークレイヤーの情報を伝える場合があります（セクション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ルーティングアーキテクチャは、ルーティング情報の抽象化をサポートする封じ込めモデルに基づいて、RAのマルチレベルのルーティング階層を定義します。[g.7715.1]は、階層的なルーティング情報の普及をサポートするために、RA（1つのレベル）内のルーティング情報の通信のためのASON階層リンク状態ルーティングプロトコル要件を定義します（他のレベルの要約ルーティング情報を含む）。他の機能コンポーネント（S）（SCN、LRMなど、RAS間の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）の概念を導入します。RASは、ルーティング情報の抽象化を提供します。単一のRAケースを除き、RAは階層的に含まれています。高レベル（親）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を参照）。RCSが通信できる範囲を提供するには、RA識別子（RA ID）が必要です。同じRAに結合したRCを区別するには、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は、一意に識別できるものとします。RA IDは輸送機の名前スペースに関連付けられている場合がありますが、RC 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.
ルーティング情報は、RA階層の隣接レベルに結合したRC、つまりレベルn 1およびNとN 1で含まれるRAを表すRCと間で交換できます。RASを接続するリンクは、外部リンク（Inter-RAリンク）と見なされる場合があり、RA内の接続性を表すリンクは内部リンク（Intra-RAリンク）と見なされます。階層の1つのレベルでのRAへの外部リンクは、親RAの内部リンクである場合があります。子のRAのIntra-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レベル、その関係、および通信プロトコルのRCSの物理的位置は、このドキュメントの範囲外です。RCが隣接するRAレベル間でどのように通信するかについての仮定は行われません。ルーティング情報がRC、その親、およびその子RCの間で交換されている場合、到達可能性（セクション3.5.3を参照）を含める必要があり、ポリシー決定に応じてノードとリンクトポロジを含めることができます。RA間のコミュニケーションは、親/子関係のあるRC間でのみ行われます。1つのRAのRCは、同じレベルで別の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.
同じRAに結合した複数のRCは、変換され（フィルター、要約など）、異なるレベルでRCSに情報を転送する場合があります。ただし、この場合、受信レベルでの結果の情報は一貫性がなければなりません（つまり、適切な情報処理を確保するために、異なるレベルでルーティング情報で実行された変換操作間の一貫性を確保します）。これは、多くのメカニズムを使用して達成できます。
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つの輸送スイッチングレイヤーの階層ルーティングトポロジを使用して、階層ルーティングトポロジ（マルチレベル）をサポートする場合があります。
1. Type of Information Exchanged
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 1からレベルn）は、同様の目的、すなわち、到達可能性情報の交換と要約されたトポロジ情報の交換と複数の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 1レベルnの到達可能性とトポロジ（または上向きの情報通信）への可視性により、レベルn 1でRCがレベル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.
- レベルnレベルn 1の到達可能性とトポロジ（または下向きの情報通信）への可視性により、レベルnでRAに制限されたRC（S）がRA以外の到達可能なエンドポイントへのパスを開発できます。
2. Interactions between Upward and Downward Communication
2. 上向きと下向きのコミュニケーション間の相互作用
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から受け取った）から発信されたルーティング情報を区別するものとします。これは、ループフリーになるためにプロトコルをルーティングすることで満たされるために必要な条件です。
3. Method of Communication
3. 通信方法
Two approaches exist for communication between Level N and N+1:
レベルnとn 1の間の通信には2つのアプローチが存在します。
- 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).
- 最初のアプローチは、レベル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.
- 2番目のアプローチは、レベルnルーティング関数をレベルn 1ルーティング関数から個別のシステムに配置します。この場合、異なるレベルのルーティング関数を含むシステム間で通信インターフェイスを使用する必要があります。この通信インターフェイスとメカニズムは、このドキュメントの範囲外です。
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.
RAの封じ込め関係は、合併、買収、売却などのイベントによって動機付けられている可能性があります。
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.
ルーティングプロトコルは、RAの階層レベルの数、およびRAの集約とセグメンテーションの観点から、アーキテクチャの進化をサポートできる必要があります。管理ドメイン内の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.
2つのRAが1つ以上のSNPPリンクでリンクされる場合があります。コンポーネントリンクが、接続されているRA、含まれるRA、またはより小さなグループ化が必要な場合、ルーティング目的と同等でない場合、複数のSNPPリンクが必要になる場合があります。
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は、データとコントロールプレーンの分離を考慮して、対応するトランスポートプレーンリソースを（ノードIDスコープ内で）一意に識別するのに十分でなければなりません（セクション3.5.1を参照してください。コントロールプレーンの表現と輸送面トポロジーは一致しているとは想定されていません）。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).
- ルーティングコントローラー（RC）は、RAのルーティング情報（プリミティブ）の交換を提供します。RCはプロトコルが独立しており、RA内の複数の異なるプロトコルコントローラーによって実現される場合があります。RC間で交換されるルーティング情報は、参照ポイント（外部および内部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のRC間の通信が、RAS間に親/子の関係がある場合にのみ発生します。子どものRAのRCは、他の子供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の場合、RCSのセットはASONルーティング（コントロール）ドメインと呼ばれます。ルーティングドメイン間で交換されるルーティング情報（Inter-RA、つまりインタードメイン）は、ドメイン内のルーティングプロトコルと、たとえば集中化された完全に分散されたドメイン内制御分布の選択肢の両方とは独立しているものとします。異なるRAレベルに囲まれたRCは、同じ物理的要素内で協力するか、物理的に分布している場合があります。
- 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]):
要約すると、ASON階層ルーティングアーキテクチャの実現をインスタンス化するために、GMPLSルーティングから次の機能が予想されます（[G.7715]および[G.7715.1]を参照）：
- RAs SHALL be uniquely identifiable within a carrier's network, each having a unique RA ID within the carrier's network.
- RASは、キャリアのネットワーク内で一意に識別できるものとし、それぞれがキャリアのネットワーク内に一意の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レベル）内で、ルーティングプロトコルは、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 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.
- 複数のRCが単一のRAにバインドされている場合、変換（フィルター、要約など）および1つのRCから異なるレベルでのRCからRCへの情報の転送に起因する受信レベルでの自己整合的な情報。
- 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.
- レベルn RAのRCに伝播された情報の再導入を防ぐためのメカニズムは、この情報を最初に受け取った隣接レベル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の封じ込め関係のオペレーター支援の変化をサポートするために、ルーティングプロトコルはRAの階層レベルの数の観点から進化をサポートするものとします。たとえば、階層の上/下部でRAを追加および削除したり、階層の中央または中央に階層レベルのRAを追加または削除したり、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（Sprint）Deborah Brungard（ATT）David Meyer（Cisco Systems）Lyndon Ong（Ciena）Dimitri Papadimitriou（Alcatel）Jonathan Sadler（Tellabs）Stephen Shew（Nortel）
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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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 rec。G.707/Y.1322、「同期デジタル階層のネットワークノードインターフェイス（SDH）」、2003年12月。
[G.709] ITU-T Rec. G.709/Y.1331, "Interfaces for the Optical Transport Network (OTN)", March 2003.
[G.709] itu-t rec。G.709/Y.1331、「光輸送ネットワークのインターフェイス（OTN）」、2003年3月。
[G.7715] ITU-T Rec. G.7715/Y.1306, "Architecture and Requirements for the Automatically Switched Optical Network (ASON)", June 2002.
[G.7715] itu-t rec。G.7715/Y.1306、「自動化された光ネットワーク（ASON）のアーキテクチャと要件」、2002年6月。
[G.7715.1] ITU-T Draft Rec. G.7715.1/Y.1706.1, "ASON Routing Architecture and Requirements for Link State Protocols", November 2003.
[G.7715.1] ITU-TドラフトRec。G.7715.1/Y.1706.1、「Asonルーティングアーキテクチャとリンク状態プロトコルの要件」、2003年11月。
[G.805] ITU-T Rec. G.805, "Generic Functional Architecture of Transport Networks", March 2000.
[g.805] itu-t rec。G.805、「輸送ネットワークの一般的な機能アーキテクチャ」、2000年3月。
[G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the Automatically Switched Optical Network (ASON)", November 2001 (and Revision, January 2003).
[g.8080] itu-t rec。G.8080/Y.1304、「自動化された光ネットワーク（ASON）のアーキテクチャ」、2001年11月（および2003年1月の改訂）。
[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月。
[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つのサーバーレイヤートレイルによってサポートされているクライアントレイヤーネットワークのいくつかのリンク接続の場合を表します。
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.
Trail（推奨[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で操作して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 Traffic Engineering (TE) link information to the RC. It informs the RC about any state changes of the link resources it controls.
リンクリソースマネージャー（LRM）：関連するすべてのコンポーネントおよびトラフィックエンジニアリング（TE）リンク情報をRCに提供します。RCに、制御するリンクリソースの状態の変更について通知します。
Protocol Controller (PC): Handles protocol-specific message exchanges according to the reference point over which the information is exchanged (e.g., E-NNI, I-NNI), and internal exchanges with the RC. The PC function is protocol dependent.
プロトコルコントローラー（PC）：情報が交換される参照ポイント（E-NNI、I-NNIなど）、およびRCとの内部交換に従って、プロトコル固有のメッセージ交換を処理します。PC機能はプロトコルに依存します。
Authors' Addresses
著者のアドレス
Wesam Alanqar Sprint
Wesam Alanqar Sprint
EMail: wesam.alanqar@mail.sprint.com
Deborah Brungard, Ed. AT&T Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ 07748, USA
デボラ・ブランガード編AT＆T RM。D1-3C22-200 S.ローレルアベニュー、ミドルタウン、ニュージャージー州07748、米国
Phone: +1 732 4201573
EMail: dbrungard@att.com
David Meyer Cisco Systems
David Meyer Cisco Systems
EMail: dmm@1-4-5.net
Lyndon Ong Ciena Corporation 5965 Silver Creek Valley Rd, San Jose, CA 95128, USA
Lyndon Ong Ciena Corporation 5965 Silver Creek Valley Rd、サンノゼ、CA 95128、米国
Phone: +1 408 8347894
EMail: lyong@ciena.com
Dimitri Papadimitriou Alcatel Francis Wellensplein 1, B-2018 Antwerpen, Belgium
Dimitri Papadimitriou Alcatel Francis Wellensplein 1、B-2018 Antwerpen、ベルギー
Phone: +32 3 2408491
EMail: dimitri.papadimitriou@alcatel.be
Jonathan Sadler 1415 W. Diehl Rd Naperville, IL 60563
ジョナサン・サドラー1415 W.ディールRDネーパービル、イリノイ60563
EMail: jonathan.sadler@tellabs.com
Stephen Shew
Nortel Networks
PO Box 3511 Station C
Ottawa, Ontario, CANADA K1Y 4H7
Phone: +1 613 7632462
EMail: sdshew@nortelnetworks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、貢献者、インターネット社会とインターネットエンジニアリングタスクフォースが代表する組織、またはインターネットエンジニアリングタスクフォースは、すべての保証を否認します。
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://ww.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エディター機能の資金は現在、インターネット協会によって提供されています。