RFC4258 日本語訳
4258 Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network(ASON). D. Brungard, Ed.. November 2005. (Format: TXT=48558 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Brungard, Ed. Request for Comments: 4258 ATT Category: Informational November 2005
ワーキンググループD.Brungard、エドをネットワークでつないでください。コメントのために以下を要求してください。 4258年のATTカテゴリ: 情報の2005年11月
Requirements for Generalized Multi-Protocol Label Switching (GMPLS)
Routing for the Automatically Switched Optical Network (ASON)
自動的に切り換えられた光学ネットワークのための一般化されたマルチプロトコルラベルスイッチング(GMPLS)ルート設定のための要件(ASON)
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(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).
プロトコルのGeneralized Multi-プロトコルLabel Switching(GMPLS)スイートは、異なったアプリケーションと同様に異なった切り換え技術を制御するために定義されました。 これらは同期式光通信網(Sonet)/同期デジタルハイアラーキを含むTime事業部Multiplexing(TDM)接続(SDH)とOptical Transport Networks(OTNs)を要求するサポートを含んでいます。
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によって定義されるようにAutomatically Switched Optical Network(ASON)の能力と機能性をサポートするためにプロトコルのGMPLSスイートに置かれたルーティング要件に集中します。
Brungard, Ed. Informational [Page 1] RFC 4258 GMPLS Routing for ASON November 2005
エドBrungard、2005年11月にASONのために掘る情報[1ページ]のRFC4258GMPLS
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
1. 序論…2 2. このドキュメントで中古のコンベンション…4 3. ASONルート設定アーキテクチャと要件…4 3.1. 複数の階層レベルのASONルート設定領域(RAs)…5 3.2. 階層型ルーティング情報普及…6 3.3. 構成…8 3.3.1. マルチレベル階層構造を構成します…8 3.3.2. RC隣接番組を構成します…8 3.4. 発展…8 3.5. ルート設定属性…8 3.5.1. ルート設定属性の分類学…9 3.5.2. 一般的に、情報の広告を出します…9 3.5.3. ノード属性…10 3.5.4. 属性をリンクしてください…11 4. セキュリティ問題…12 5. 結論…12 6. 貢献者…15 7. 承認…15 8. 参照…16 8.1. 標準の参照…16 8.2. 有益な参照…16
1. Introduction
1. 序論
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.
プロトコルのGeneralized Multi-プロトコルLabel Switching(GMPLS)スイートは他の能力の中で異なった切り換え技術を制御するサポートを提供します。 これらはOptical Transport Networksと同様にSonet/SDH(それぞれ[T1.105]と[G.707]を見る)を利用しているTDM接続を要求するサポートを含んでいます(OTNs、[G.709]を見てください)。 しかしながら、Automatically Switched Optical Network(ASON)のためにITU-TがG.8080規制飛行機アーキテクチャであるとサポートするのに必要である、ある能力があります。 したがって、GMPLSプロトコル群のための対応する要件を理解しているのは望ましいです。 ASON規制飛行機アーキテクチャは[G.8080]で定義されます。 ASONルーティング要件は[G.7715]とASONリンク州のプロトコルのための[G.7715.1]で特定されます。 これらのRecommendationsはすべての[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)
このドキュメントはプロトコルのGMPLSスイートがASON制御飛行機の能力と機能性をサポートするというルーティング要件に焦点を合わせます。 このドキュメントは、ASON用語を使用することでASON要件をまとめます。 このドキュメントは、GMPLSが適用性かGMPLS能力であると扱いません。 どんなプロトコル(特にルーティング)
Brungard, Ed. Informational [Page 2] RFC 4258 GMPLS Routing for ASON November 2005
エドBrungard、2005年11月にASONのために掘る情報[2ページ]のRFC4258GMPLS
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(ルート設定)用語部をAppendixes1と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でルート設定Areas(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の上下関係に備えます。 すなわち、子供RAsは親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つの通信を仮定しないで、異なったRAs(子供と親RAsを含んでいる)の中で使用されたルーティング・プロトコルが異なっているのを許容します。 RAsの階層レベルをサポートするルーティングパラダイムの実現は指定されません。
- The routing adjacency topology (i.e., the associated Protocol
Controller (PC) connectivity) and transport topology are NOT
assumed to be congruent.
- ルーティング隣接番組トポロジー(すなわち、関連プロトコルController(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ネットワークの経営を容易にするために機能部品と一般的な情報要素の定義で概念的な参照アーキテクチャに備えます。 この記述は概念的であるだけです: これらの機能の物理的な仕切りは含意されません。
Brungard, Ed. Informational [Page 3] RFC 4258 GMPLS Routing for ASON November 2005
エドBrungard、2005年11月にASONのために掘る情報[3ページ]のRFC4258GMPLS
2. Conventions Used in This Document
2. 本書では使用されるコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[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]はプロトコル仕様と実装に関してこれらのキーワードの解釈について説明しますが、それらは、プロトコル拡大のための設計の品質について説明するのに本書では使用されます。
3. ASON Routing Architecture and Requirements
3. ASONルート設定アーキテクチャと要件
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とその関連する機能部品(用語のAppendix2を見る)です。 RAによって提供されたルーティングサービスはルート設定Performer(RP)によって提供されます。 RPは独身のRAに責任があります、そして、使用がルート設定Controllers(RCs)を分配したと機能上実感されるかもしれません。 RC(それ自体)は分配された実体のクラスタとして実装されるかもしれません(ASONはルート設定Control Domain(RCD)とクラスタを呼びます)。 RAのためのRCの部品は、彼らの関連Link Resourceマネージャ(LRMs)からルーティングトポロジー情報を受け取って、経路情報Database(RDB)にこの情報を保存します。 RDBは同じRAに境界があるそれぞれのRCに模写されて、複数の輸送機ネットワーク層に関して情報を含むかもしれません。 ルーティングトポロジーが変化するときはいつも、LRMは対応するRCに知らせます。(順番に、RCは関連RDBをアップデートします)。 RDBに同期を確実にするために、RCsは協力して、ルーティング情報を交換します。 経路計算機能は、各RCに存在しているか、同じRAの中の選択されたRCsに存在しているか、または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の中のRCsのコミュニケーションは、特定のルーティング・プロトコル(または、複数のプロトコル)を使用することで実現されます。 ASONでは、コミュニケーションコンポーネントはプロトコルコントローラ(PC)の部品によって表されます、そして、プロトコルメッセージはASONコントロール機Signaling Control Network(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
ASONルーティングアーキテクチャはルーティング情報が抽象化であるとサポートするために封じ込めモデルに基づくRAsのマルチレベルルーティング階層構造を定義します。 [G.7715.1]がRA(1つのレベル)の中のルーティング情報に関するコミュニケーションが階層型ルーティング情報が普及であるとサポートするというASONの階層的なリンク州のルーティング・プロトコル要件を定義する、(包含はルーティング情報をまとめました。
Brungard, Ed. Informational [Page 4] RFC 4258 GMPLS Routing for ASON November 2005
エドBrungard、2005年11月にASONのために掘る情報[4ページ]のRFC4258GMPLS
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.
他のレベル) 他の機能部品のいずれのコミュニケーション (例えば、SCN、LRM、RCDs(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アドレスのためのコントロール飛行機識別子です。 ルーティングによるそれらの識別子の形式は特定の、そして、外の実装がこのドキュメントの範囲であったなら実現SHALLについて議定書の中で述べます。
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の失敗、またはRCsと、失敗状態からのその後の回復とのコミュニケーションの失敗は中断してはいけません。進行中の要求(すなわち、既に設立される)と彼らの関連接続を中断してください。 セットアップされる呼び出しは完全な状態で入手できなくないかもしれません、そして、呼び出しセットアップサービスは回復動作の間、入手できないかもしれません。
3.1. Multiple Hierarchical Levels of ASON Routing Areas (RAs)
3.1. 複数の階層レベルのASONルート設定領域(RAs)
[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]はネットワーク下位区分に関してルート設定Area(RA)の概念を紹介します。 RAsはルーティング情報抽象化に備えます。 ただ一つのRAケースを除いて、RAsは階層的に含まれています: (親)よりハイレベルのRAはまた順番にRAsなどを含むかもしれない低レベル(子供)RAsを含んでいます。 したがって、RAsは連続した階層的なRAレベルを再帰的に定義するRAsを含んでいます。
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階層構造の異なったレベルのためにRCsの中で区別するのが必要です。 どんな組のRCsもコミュニケーションを確立する前に、彼らは、同じ親RAに縛られることを確かめなければなりません(セクション3.2を見てください)。 RA識別子(RA ID)が、RCsが交信できる範囲を提供するのに必要です。 同じRAに縛られたRCsを見分けるために、RC識別子(RC ID)が必要です。 RC ID MUST、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
RAはデータ飛行機のパーティションを表します、そして、識別子(すなわち、RA ID)はデータ飛行機パーティションの参照として制御飛行機の中に使用されます。 キャリヤーのネットワークSHALLの中の各RA
Brungard, Ed. Informational [Page 5] RFC 4258 GMPLS Routing for ASON November 2005
エドBrungard、2005年11月にASONのために掘る情報[5ページ]のRFC4258GMPLS
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 IDは輸送機名前スペースに関連しているかもしれませんが、RC IDはコントロール飛行機名前スペースに関連しています。
3.2. Hierarchical Routing Information Dissemination
3.2. 階層型ルーティング情報普及
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階層構造、+1の隣接しているLevel Nレベルまで縛られたRCsとNの間でルート設定情報を交換できます。そこでは、Level NはLevel N+1によって含まれたRAsを表します。 リンク接続RAsは外部のリンク(相互RAリンク)として見なされるかもしれません、そして、RAの中に接続性を表すリンクは内部のリンク(イントラ-RAリンク)として見なされるかもしれません。 階層構造の1つのレベルにおけるRAへの外部のリンクは親RAの内部のリンクであるかもしれません。 イントラ-RAは子供RA MAYにリンクします。親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の物理的な位置、それらの関係、およびそれらの通信プロトコルがあります。 RCsが隣接しているRAレベルの間でどう交信するかに関して仮定は全くされません。 掘るならRCと、親と、その子供RCsの間で情報を交換して、それは、SHOULDインクルードの可到達性(セクション3.5.3を見る)と5月のインクルードです、政策決定、ノード、およびリンクトポロジーで。 RAsのコミュニケーションは親/子供関係があるRCsの間の場所を取るだけです。 1RAのRCsは同じレベルで別のRAのRCsと決してコミュニケートしません。 SHOULDはいくらかそこでは、そうではありません。RA以内か異なったRAsで使用される異なったルーティング・プロトコルに関する依存。
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 MAYに縛られた複数のRCsが変形する、(フィルタ、要約、など) そして、異なったレベルにおける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. 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
上向きに流れる情報の種類(すなわち、Level NからLevel N+1)と下方に流れるのが(すなわち、Level NへのLevel N+1)すなわち、同様の目的、可到達性情報の交換に使用されて、トポロジー情報をまとめた情報
Brungard, Ed. Informational [Page 6] RFC 4258 GMPLS Routing for ASON November 2005
エドBrungard、2005年11月にASONのために掘る情報[6ページ]のRFC4258GMPLS
allow routing across multiple RAs. The summarization of topology
information may impact the accuracy of routing and may require
additional path calculation.
複数のRAsの向こう側に掘るのを許容してください。 トポロジー情報の総括は、ルーティングの精度に影響を与えて、追加経路計算を必要とするかもしれません。
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.
- Level N+1のRC(s)がLevel Nから届いている終点を決定するのを許容して、Level Nの可到達性とトポロジー(または、上向きの情報コミュニケーション)にN+1目に見えることを平らにしてください。
- 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.
- Level N+1の可到達性への平らなN目に見えることとRC(s)を許容するトポロジー(または、下向きの情報コミュニケーション)がRAの外の届いている終点に経路を開発するLevel Nの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
- そしてLevel N+1RAのRCからLevel N RAのRCに伝播された情報がLevel N+1RAの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.
- Level N-1 RAのRCからLevel N RAのRCに伝播された情報がLevel 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.
ルーティング・プロトコルSHALLは与えられたレベルRAで派生しているルーティング情報(外部のRAsから、受信する)から溯源されたルーティング情報を差別化します、この情報が同じレベルで別のRCによって転送さえされるとき。 これはルーティング・プロトコルによって実現している、輪から自由でなるべきである必要条件です。
3. Method of Communication
3. 伝達方法
Two approaches exist for communication between Level N and N+1:
2つのアプローチがLevel 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).
- 最初のアプローチはLevel N経路選択機能のインスタンスとLevel N+1経路選択機能のインスタンスを同じシステムに置きます。 コミュニケーションインタフェースは、ただ一つのシステムの中にあって、その結果、標準化を条件としてオープンなインタフェースではありません。 しかしながら、相互運用性と基本的なルーティング・プロトコルの正当性(例えば、費用/メートル法の数値)を確実にするために一貫した方法で情報再広告か漏出を実行しなければなりません。
Brungard, Ed. Informational [Page 7] RFC 4258 GMPLS Routing for ASON November 2005
エドBrungard、2005年11月にASONのために掘る情報[7ページ]のRFC4258GMPLS
- 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番目のアプローチはLevel N経路選択機能をLevel N+1経路選択機能から別々のシステムに置きます。 この場合、異なったレベルのための経路選択機能を含んでいて、システムの間で通信インターフェースを使用しなければなりません。 このドキュメントの範囲の外にこの通信インターフェースとメカニズムがあります。
3.3. Configuration
3.3. 構成
3.3.1. Configuring the Multi-Level Hierarchy
3.3.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 MUSTサポート静電気(すなわち、オペレータは補助した)と5月は階層構造の中で親とその子供との関係について説明する情報の自動化された構成をサポートします(RA IDとRC IDを含んでいて)。 再帰的に適用されると、全体の階層構造はこのようにして構成されます。
3.3.2. Configuring RC Adjacencies
3.3.2. RC隣接番組を構成します。
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 MUSTサポート静電気(すなわち、オペレータは補助した)と5月はRAの中の他のRCsに関連隣接番組について説明する情報の自動化された構成をサポートします。 ルーティング・プロトコルSHOULDは[G.7715]のセクション9で説明されたすべてのタイプのRC隣接番組をサポートします。 後者は一致しているトポロジー(分配されたRCと)とhubbedトポロジーを含んでいます(例えば、後者が自動的に指定されたRCを含意しないことに注意してください)。
3.4. Evolution
3.4. 発展
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.
ルーティングはSHOULDについて議定書の中で述べます。階層レベルのRAsの数に関して建築発展をサポートすることができてください、RAsの集合と分割と同様に。 管理ドメインの中のRA IDのユニークさはこれらの操作を容易にするかもしれません。 自動的にこれらの操作を開始する、そして/または、ルーティング・プロトコルが実行しないと予想されます。 RA階層構造の再構成は進行中の要求、もっとも、セットアップされるのが終了しないかもしれない要求、およびセットアップサービスが再構成動作の間、入手できないかもしれないという要求を中断しないかもしれません。
3.5. Routing Attributes
3.5. ルート設定属性
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
転送ネットワークのためのルート設定は1層あたり1個のベースの上と、そして、ルーティングパラダイムが層の中で異なるかもしれないところと層の中で実行されます。 すべての設備がどんな与えられた層でも同じセットのトランスポート層か同じ度合いの接続の柔軟性を支えるというわけではありません。 A
Brungard, Ed. Informational [Page 8] RFC 4258 GMPLS Routing for ASON November 2005
エドBrungard、2005年11月にASONのために掘る情報[8ページ]のRFC4258GMPLS
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.
異なった適合機能にかかわって、サーバ層の道は様々なクライアントをサポートするかもしれません。 さらに、設備は、可変適合が機能性であるとサポートするかもしれません。(単一のサーバ層の道はそれでダイナミックに異なったマルチプレクシング構造を支えます)。 その結果、ルーティング情報は層の特有の層独立者、およびクライアント/サーバ適合情報を含むかもしれません。
3.5.1. Taxonomy of Routing Attributes
3.5.1. ルート設定属性の分類学
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)
- 引き継ぐか、または層の特有です。(クライアント層はサーバ層からいくつかの属性を引き継ぐことができます、Link Capacityなどの他の属性が層によって指定されますが)
(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は輸送機リソースの規制飛行機表現に、用語SubNetwork Point(SNP)を使用します。 規制飛行機表現と輸送機トポロジーを一致させているのは思われません。 コントロールは表現SHALLを平らにします。物理的なトポロジーによって制限されません。 ルーティングのためのSNPsの関係組分けはSNP Pool(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.
2RAsが1個以上のSNPPリンクによってリンクされるかもしれません。 コンポーネントリンクがルーティング目的のために彼らが付けているRAsに関して同等でないときに、複数のSNPPリンクが必要であるかもしれません、含んでいるRAにより小さい組分けがいつ必要であるかをそうされます。
3.5.2. Commonly Advertised Information
3.5.2. 一般的に広告を出した情報
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
Brungard, Ed. Informational [Page 9] RFC 4258 GMPLS Routing for ASON November 2005
エドBrungard、2005年11月にASONのために掘る情報[9ページ]のRFC4258GMPLS
- 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から広告を得たとき示す情報
3.5.3. Node Attributes
3.5.3. ノード属性
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を考えることができます。 これ以上分解できない抽象的なノードとものの間で区別を全くしないなら、彼らの広告に同じ属性を使用するかもしれません。 以下のテーブルでは、Capabilityはリンク州のルーティング・プロトコルの実現で必要であるサポート水準について言及しますが、Usageはオペレータにとって利用可能な状態でSHOULDがある運用統制の度合いについて言及します。
The following Node Attributes are defined:
以下のNode Attributesは定義されます:
Attribute Capability Usage
----------- ----------- ---------
Node ID REQUIRED REQUIRED
Reachability REQUIRED OPTIONAL
属性能力用法----------- ----------- --------- ノードIDは任意の状態で必要である必要な可到達性を必要としました。
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.
可到達性情報は関連ノードで届いている終点のセットについて説明します。 1セットの関連外部(例えば、User Network Interface(UNI))のアドレス/アドレス接頭語か1セットの関連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.
以下に注意してください。 さらなる内部の詳細(すなわち、抽象的なノード)を持っているかもしれないノードとこれ以上分解できないものの間で区別を全くしません。 したがって、ノードの属性は、単一のスイッチ属性だけであることはみなされませんが、サブネットワークを表す階層構造の、より高いレベルでノードに適用されるかもしれません。
Brungard, Ed. Informational [Page 10] RFC 4258 GMPLS Routing for ASON November 2005
エドBrungard、2005年11月にASONのために掘る情報[10ページ]のRFC4258GMPLS
3.5.4. Link Attributes
3.5.4. リンク属性
The following Link Attributes are defined:
以下のLink Attributesは定義されます:
Link Attribute Capability Usage
--------------- ----------- ---------
Local SNPP link ID REQUIRED REQUIRED
Remote SNPP link ID REQUIRED REQUIRED
Layer Specific Characteristics see Table 3
リンク属性能力用法--------------- ----------- --------- 地方のSNPPのリンクID REQUIRED REQUIRED Remote SNPPリンクID REQUIRED REQUIRED Layer Specific CharacteristicsはTable3を見ます。
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は唯一対応する輸送機リソースを特定する(Node 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はOPTIONALです。
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をTermination Connection Point(CP)、Connection Point(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情報などの多様性情報を表します。
Brungard, Ed. Informational [Page 11] RFC 4258 GMPLS Routing for ASON November 2005
エドBrungard、2005年11月にASONのために掘る情報[11ページ]のRFC4258GMPLS
- 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.
以下に注意してください。 層の特有の属性の別々の広告は選ばれるかもしれません。 しかしながら、これは不要な複製に通じるかもしれません。 遺産を使用することでこれを避けることができます、局所的適応情報から誘導できる属性が広告を出される必要はないように。 属性がいつサーバ層から相続可能であるかを示すことによって数個の層が存在しているとき、したがって、最適化は使用されるかもしれません。
4. Security Considerations
4. セキュリティ問題
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 Recommendation[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.
以下に注意してください。 提案されたルーティング・プロトコルSHOULDアドレス仮面舞踏会の脅威分析、盗聴、不正アクセス、サービスの情報(反射攻撃を含んでいる)の損失か不正、拒否、偽造、および否定は攻撃されます。
5. Conclusions
5. 結論
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ルーティングアーキテクチャとコンポーネントの記述を提供します。 この記述は概念的であるだけです: これらの機能の物理的な仕切りは含意されません。
Brungard, Ed. Informational [Page 12] RFC 4258 GMPLS Routing for ASON November 2005
エドBrungard、2005年11月にASONのために掘る情報[12ページ]のRFC4258GMPLS
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に細分されます。(ASON RAsは複数のルーティングがプロトコルであるとサポートするかもしれません)。 1〜1がない関係のSHALL、想定されてください。
- 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).
- ルート設定Controllers(RCs)はRAのためのルーティング情報(基関数)の交換に備えます。 RCはプロトコル独立者であり、RAの中で複数の、そして、異なったプロトコルコントローラによって実感されるかもしれません。 方針規制への対象が参照で課されたなら情報がRCs SHALLの間で交換したルーティングは(外部とInternal-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階層構造では、RAsの間に親/子供関係があるときだけ、異なったRAsのRCsのコミュニケーションは起こります。 子供RAsのRCsは他の子供RAsのRCsと決してコミュニケートしません。 そこでは、SHOULDがいくらかそうではありません。依存は子供の中で異なったルーティング・プロトコルで親のRAとものを使用しました。 例えば、子供RAの中で作動するルーティング・プロトコルとどんなコントロール分配選択の両方からも独立していて、集結されて、完全に分配されていて、ルーティング情報は親の中でRA SHALLを交換しました。
- 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ルーティング(コントロール)ドメインと呼ばれます。 例えば、イントラドメインルーティング・プロトコルとイントラドメインコントロール分配選択の両方から独立していて、集結されて、完全に分配されていて、ルーティング情報は経路ドメイン(すなわち、相互RA、相互ドメイン)の間でSHALLを交換しました。 異なったRAレベルに境界があるRCsは同じ物理的な要素の中で並べるか物理的に分配されているかもしれません。
- The routing adjacency topology (i.e., the associated PC
connectivity topology) and the transport network topology SHALL
NOT be assumed to be congruent.
- ルーティング隣接番組トポロジー(すなわち、関連PC接続性トポロジー)と輸送はトポロジーSHALL NOTをネットワークでつなぎます。一致していると思われてください。
- The routing topology SHALL support multiple links between nodes
and RAs.
- ルーティングトポロジーSHALLはノードと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]):
概要では、GMPLSルーティングから、以下の機能性がASON階層型ルーティングアーキテクチャ実現を例示すると予想されます([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 SHALLは唯一そうです。キャリヤーのネットワークの中にそれぞれユニークな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
- を支持してRA(1つのレベル)の中では、ルーティング・プロトコルSHALLが階層型ルーティング情報の普及をサポートする、(包含は他のレベルのためのルーティング情報をまとめました)。
Brungard, Ed. Informational [Page 13] RFC 4258 GMPLS Routing for ASON November 2005
エドBrungard、2005年11月にASONのために掘る情報[13ページ]のRFC4258GMPLS
architecture of multiple hierarchical levels of RAs; the number of
hierarchical RA levels to be supported by a routing protocol is
implementation specific.
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.
- ルーティング・プロトコルSHALLは、ルーティングが[G.7715]と[G.7715.1]で定義されるように一般的なセットの情報要素に基づく情報であるとサポートします、リンクと抽象的なノードに関係する属性の間で分割されています(それぞれサブネットワークか単にノードのどちらかを表して)。 [G.7715]は、ルーティング・プロトコルが使用されている状態でルーティング情報が表されて、交換される方法が異なると認めます。
- The routing protocol SHALL converge such that the distributed RDBs
become synchronized after a period of time.
- ルーティング・プロトコルSHALLが一点に集まるので、分配されたRDBsは期間の後に連動するようになります。
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.
- 可到達性を含んでいて、ルーティング情報の処理は階層構造の隣接しているレベルの間で(すなわち、Level 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.
- どんな変換からも生じる受信レベルにおける自己一貫した情報、(フィルタ、要約、など) そして、複数のRCsが独身のRAに縛られるときの異なったレベルにおける、情報の1RCからRC(s)までの推進。
- 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へのLevel 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の封じ込め関係におけるオペレータによって補助された変化をサポートするために、ルーティング・プロトコルSHALLはRAsの階層レベルの数に関して発展をサポートします。 例えば: RAsの階層構造、付加またはRAsの階層レベルを取り除く先端/下部で中央か階層構造の中央からRAsを加えて、取り外すことなどの非破壊的な操作のサポート、集合、および分割。 サポートされる階層レベルの数は、ルーティング・プロトコル特有であり、封じ込め関係を反映します。 例えば、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
ノードで届いている終点のセットの可到達性情報(セクション3.5.3を見る)は、それらの適用性範囲で一貫して1セットのUNI Transport Resourceアドレス/アドレス接頭語か関連SNPPリンクID/SNPPの1セットがID接頭語をリンクするので広告を出して、割り当てられて、選択されるかもしれません。 形式
Brungard, Ed. Informational [Page 14] RFC 4258 GMPLS Routing for ASON November 2005
エドBrungard、2005年11月にASONのために掘る情報[14ページ]のRFC4258GMPLS
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).
プロトコル実現におけるコントロール飛行機識別子は実装特有です。 RAの中のルーティング・プロトコルの使用は他のRAs(子供か親)における使用のためにルーティング・プロトコルの選択を制限するべきではありません。
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 MUSTなどのリンクとノードでは、外部だけがあるただ一つの論理的な実体がトポロジーデータベースに目に見えた状態でリンクされるので、より広いネットワークにそれ自体を表すことができてください。
6. Contributors
6. 貢献者
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ルート設定Requirementsデザインチーム共同している取り組みの結果です。 ↓これは現在のドキュメントに貢献したデザインチームメンバーの作者です:
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)デヴィッド・マイヤー(シスコシステムズ)・リンドン・オング(Ciena)ディミトリPapadimitriou(アルカテル)ジョナサン・サドラー(Tellabs)・スティーブン・シュー(ノーテル)
7. Acknowledgements
7. 承認
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ルート設定Requirement Design TeamとITU-T SG15/Q14の提案を開始して頂いて、Kireeti Kompellaに感謝したがっています。
Brungard, Ed. Informational [Page 15] RFC 4258 GMPLS Routing for ASON November 2005
エドBrungard、2005年11月にASONのために掘る情報[15ページ]のRFC4258GMPLS
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
8.2. Informative References
8.2. 有益な参照
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。 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草稿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(そして、改正、2003年1月)年11月。
[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がそうするかもしれません。
[T1.105] ANSI T1.105, "Synchronous Optical Network (SONET) - Basic
Description including Multiplex Structure, Rates, and
Formats", 2001.
[T1.105]ANSI T1.105、「同期式光通信網(Sonet)--Multiplex Structure、Ratesを含む基本的な記述、Formats、」、2001
Brungard, Ed. Informational [Page 16] RFC 4258 GMPLS Routing for ASON November 2005
エドBrungard、2005年11月にASONのために掘る情報[16ページ]のRFC4258GMPLS
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.
管理ドメイン(Recommendation[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.
適合機能(Recommendation[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(電子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.
管理飛行機: 輸送機、制御飛行機、および全体でシステムのために管理機能を実行します。 また、それはすべての飛行機の間にコーディネートを供給します。 以下の管理の機能的な領域は管理飛行機で実行されます: 性能、欠点、構成、会計、およびセキュリティ管理。
Brungard, Ed. Informational [Page 17] RFC 4258 GMPLS Routing for ASON November 2005
エドBrungard、2005年11月にASONのために掘る情報[17ページ]のRFC4258GMPLS
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.
管理ドメイン(Recommendation[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は実際の、または、潜在的の輸送機リソースを表すコントロール飛行機抽象化です。 SNPs(異なったサブネットワークパーティションにおける)は同じ輸送リソースを表すかもしれません。 1〜1つの通信を想定するべきではありません。
Subnetwork Point Pool (SNPP): A set of SNPs that are grouped together for the purposes of routing.
サブネットワークポイントプール(SNPP): ルーティングの目的のために一緒に分類されるSNPsの1セット。
Termination Connection Point (TCP): A TCP represents the output of a Trail Termination function or the input to a Trail Termination Sink function.
終了接続拠点(TCP): TCPはTrail Termination機能か入力の出力をTrail Termination Sink機能に表します。
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.
輸送機: ユーザー情報の1つの位置からもう1つの位置までの双方向か単方向の転送を供給します。 また、それは何らかのコントロールとネットワークマネージメント情報の転送を供給できます。 輸送機は層にされます。 それは[G.805]推薦で定義されたTransport Networkに同等です。
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.
可変適合機能: 単一のサーバ層の道は複数のクライアント層ネットワークのためにダイナミックに異なったマルチプレクシング構造、すなわち、リンク結合をサポートするかもしれません。
Brungard, Ed. Informational [Page 18] RFC 4258 GMPLS Routing for ASON November 2005
エドBrungard、2005年11月にASONのために掘る情報[18ページ]のRFC4258GMPLS
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を出るサブネットワーク、それらとインタコネクトするリンク、およびリンクの端を表すインタフェースの1セットによって定義されます。 RAはリンクによってインタコネクトされたより小さいRAsを含むかもしれません。 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は1ルート設定Area(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ルーティングアーキテクチャは機能します。 プロトコル独立者(Resourceマネージャ、LRM、ルート設定ControllerまたはRCをリンクする)とプロトコル特有(プロトコルControllerかPC)としてこれらの機能を分類できます。
Routing Controller (RC): Handles (abstract) information needed for routing and the routing information exchange with peering RCs by operating on the RDB. The RC has access to a view of the RDB. The RC is protocol independent.
ルート設定コントローラ(RC): (抽象的)の情報がRDBを作動させることによってルーティングとじっと見るRCsとのルーティング情報交換に必要としたハンドル。 RCはRDBの視点に近づく手段を持っています。 RCはプロトコル独立者です。
Note: Since the RDB may contain routing information pertaining to multiple RAs (and possibly to multiple layer networks), the RCs accessing the RDB may share the routing information.
以下に注意してください。 RDBが複数のRAs(そしてことによると複数の層のネットワークに)に関係するルーティング情報を含むかもしれないので、RDBにアクセスするRCsはルーティング情報を共有するかもしれません。
Link Resource Manager (LRM): Supplies all the relevant component and Traffic Engineering (TE) link information to the RC. It informs the RC about any state changes of the link resources it controls.
資源管理プログラム(LRM)をリンクしてください: 供給のすべての関連コンポーネントとTraffic Engineering(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機能はプロトコル扶養家族です。
Brungard, Ed. Informational [Page 19] RFC 4258 GMPLS Routing for ASON November 2005
エドBrungard、2005年11月にASONのために掘る情報[19ページ]のRFC4258GMPLS
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秒間ローレルAve。 ミドルタウン、ニュージャージー 07748、米国
Phone: +1 732 4201573 EMail: dbrungard@att.com
以下に電話をしてください。 +1 732 4201573 メール: 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のシルバークリークバレー、サンノゼ、カリフォルニア 95128、第米国
Phone: +1 408 8347894 EMail: lyong@ciena.com
以下に電話をしてください。 +1 408 8347894 メール: lyong@ciena.com
Dimitri Papadimitriou Alcatel Francis Wellensplein 1, B-2018 Antwerpen, Belgium
ディミトリPapadimitriouアルカテルフランシスWellensplein1、B-2018アントウェルペン(ベルギー)
Phone: +32 3 2408491 EMail: dimitri.papadimitriou@alcatel.be
以下に電話をしてください。 +32 3 2408491 メール: dimitri.papadimitriou@alcatel.be
Jonathan Sadler 1415 W. Diehl Rd Naperville, IL 60563
イリノイ ジョナサン・サドラー1415・W.ディール・第ナパービル、60563
EMail: jonathan.sadler@tellabs.com
メール: jonathan.sadler@tellabs.com
Brungard, Ed. Informational [Page 20] RFC 4258 GMPLS Routing for ASON November 2005
エドBrungard、2005年11月にASONのために掘る情報[20ページ]のRFC4258GMPLS
Stephen Shew Nortel Networks PO Box 3511 Station C Ottawa, Ontario, CANADA K1Y 4H7
スティーブンシューノーテルはオタワ、Cオンタリオ、私書箱3511駅のカナダK1Y 4H7をネットワークでつなぎます。
Phone: +1 613 7632462 EMail: sdshew@nortelnetworks.com
以下に電話をしてください。 +1 613 7632462 メール: sdshew@nortelnetworks.com
Brungard, Ed. Informational [Page 21] RFC 4258 GMPLS Routing for ASON November 2005
エドBrungard、2005年11月にASONのために掘る情報[21ページ]のRFC4258GMPLS
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Brungard, Ed. Informational [Page 22]
Brungard、エド、情報[22ページ]
一覧
スポンサーリンク
