RFC4394 日本語訳
4394 A Transport Network View of the Link Management Protocol (LMP).D. Fedyk, O. Aboul-Magd, D. Brungard, J. Lang, D. Papadimitriou. February 2006. (Format: TXT=40812 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Fedyk
Request for Comments: 4394 O. Aboul-Magd
Category: Informational Nortel Networks
D. Brungard
AT&T
J. Lang
Sonos, Inc.
D. Papadimitriou
Alcatel
February 2006
Fedykがコメントのために要求するワーキンググループD.をネットワークでつないでください: 4394年のO.Aboul-Magdカテゴリ: 情報のノーテルはSonos Inc.D.Papadimitriouアルカテル2006年2月にD.Brungard AT&TのJ.ラングをネットワークでつなぎます。
A Transport Network View of the Link Management Protocol (LMP)
リンク管理プロトコルの転送ネットワーク視点(LMP)
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
The Link Management Protocol (LMP) has been developed as part of the Generalized MPLS (GMPLS) protocol suite to manage Traffic Engineering (TE) resources and links. The GMPLS control plane (routing and signaling) uses TE links for establishing Label Switched Paths (LSPs). This memo describes the relationship of the LMP procedures to 'discovery' as defined in the International Telecommunication Union (ITU-T), and ongoing ITU-T work. This document provides an overview of LMP in the context of the ITU-T Automatically Switched Optical Networks (ASON) and transport network terminology and relates it to the ITU-T discovery work to promote a common understanding for progressing the work of IETF and ITU-T.
Traffic Engineering(TE)リソースとリンクを管理するためにGeneralized MPLS(GMPLS)プロトコル群の一部としてLink Managementプロトコル(LMP)を開発してあります。 GMPLS制御飛行機(ルーティングとシグナリング)は、Label Switched Paths(LSPs)を設立するのにTEリンクを使用します。 このメモは国際電気通信連合(ITU-T)、および進行中のITU-T仕事で定義されるようにLMP手順の関係について'発見'に説明します。 このドキュメントは、ITU-T Automatically Switched Optical Networks(ASON)と転送ネットワーク用語の文脈にLMPの概要を提供して、IETFとITU-Tの仕事を進行するための一般的な理解を促進するためにITU-T発見仕事にそれに関連します。
Fedyk, et al. Informational [Page 1] RFC 4394 Transport Network View of LMP February 2006
Fedyk、他 LMP2006年2月の情報[1ページ]のRFC4394転送ネットワーク視点
Table of Contents
目次
1. Introduction ....................................................2
2. ASON Terminology and Abbreviations Related to Discovery .........3
2.1. Terminology ................................................3
2.2. Abbreviations ..............................................4
3. Transport Network Architecture ..................................5
3.1. G.8080 Discovery Framework .................................7
4. Discovery Technologies ..........................................9
4.1. Generalized Automatic Discovery Techniques G.7714 ..........9
4.2. LMP and G.8080 Terminology Mapping .........................9
4.2.1. TE Link Definition and Scope .......................12
4.3. LMP and G.8080 Discovery Relationship .....................13
4.4. Comparing LMP and G.8080 ..................................14
5. Security Considerations ........................................15
6. Informative References .........................................15
7. Acknowledgements ...............................................16
1. 序論…2 2. ASON用語と略語は発見に関連しました…3 2.1. 用語…3 2.2. 略語…4 3. ネットワークアーキテクチャを輸送してください…5 3.1. G.8080発見フレームワーク…7 4. 発見技術…9 4.1. 自動発見テクニックG.7714を一般化します…9 4.2. LMPとG.8080用語マッピング…9 4.2.1. Teリンク定義と範囲…12 4.3. LMPとG.8080発見関係…13 4.4. LMPとG.8080を比較します…14 5. セキュリティ問題…15 6. 有益な参照…15 7. 承認…16
1. Introduction
1. 序論
The GMPLS control plane consists of several building blocks as described in [RFC3945]. The building blocks include signaling, routing, and link management for establishing LSPs. For scalability purposes, multiple physical resources can be combined to form a single TE link for the purposes of path computation and GMPLS control plane signaling.
GMPLS制御飛行機は[RFC3945]で説明されるようにいくつかのブロックから成ります。 ブロックはLSPsを設立するためのシグナリング、ルーティング、およびリンク管理を含めます。 スケーラビリティ目的において、経路計算とGMPLSコントロール飛行機シグナリングの目的のために単一のTEリンクを形成するために複数の物理資源を結合できます。
As manual provisioning and management of these links are impractical in large networks, LMP was specified to manage TE links. Two mandatory management capabilities of LMP are control channel management and TE link property correlation. Additional optional capabilities include verifying physical connectivity and fault management. [LMP] defines the messages and procedures for GMPLS TE link management. [LMP-TEST] defines SONET/SDH-specific messages and procedures for link verification.
これらのリンクの手動の食糧を供給するのと管理が大きいネットワークで非実用的であるので、LMPはTEリンクを管理するために指定されました。 LMPの2つの義務的な管理能力が、コントロールチャンネル管理とTEリンク特性の相関関係です。 追加任意の能力は、物理的な接続性と障害管理について確かめるのを含んでいます。 [LMP]はGMPLS TEリンク管理のためのメッセージと手順を定義します。 [LMP-TEST]はリンク検証のためのSDH Sonet/特有のメッセージと手順を定義します。
ITU-T Recommendation G.8080 Amendment 1 [G.8080] defines control plane discovery as two separate processes; one process occurs within the transport plane space and the other process occurs within the control plane space.
ITU-T Recommendation G.8080 Amendment1[G.8080]はコントロール飛行機発見を2つの別々のプロセスと定義します。 1つのプロセスが輸送機スペースの中に起こります、そして、もう片方のプロセスはコントロール飛行機スペースの中に起こります。
The ITU-T has developed Recommendation G.7714, "Generalized automatic discovery techniques" [G.7714], defining the functional processes and information exchange related to transport plane discovery aspects, i.e., layer adjacency discovery and physical media adjacency discovery. Specific methods and protocols are not defined in Recommendation G.7714. ITU-T Recommendation G.7714.1, "Protocol for automatic discovery in SDH and OTN networks" [G.7714.1], defines a
ITU-TはRecommendation G.7714を開発しました、「一般化された自動発見のテクニック」[G.7714]、機能的なプロセス、すなわち、輸送機発見局面、層の隣接番組発見に関連する情報交換、および物理的なメディア隣接番組発見を定義して。 特定のメソッドとプロトコルはRecommendation G.7714で定義されません。 「SDHでの自動発見とOTNネットワークのためのプロトコル」[G.7714.1]というITU-T Recommendation G.7714.1はaを定義します。
Fedyk, et al. Informational [Page 2] RFC 4394 Transport Network View of LMP February 2006
Fedyk、他 LMP2006年2月の情報[2ページ]のRFC4394転送ネットワーク視点
protocol and procedure for transport plane layer adjacency discovery (e.g., discovering the transport plane layer endpoint relationships and verifying their connectivity). The ITU-T is currently working to extend discovery to control plane aspects providing detail on a discovery framework architecture in G.8080 and a new Recommendation on "Control plane initial establishment, reconfiguration".
議定書を作ってください。そうすれば、輸送機のための手順は隣接番組発見(例えば、輸送機層の終点関係を発見して、それらの接続性について確かめる)を層にします。 ITU-Tは、現在、G.8080の発見フレームワークアーキテクチャと「飛行機当初設定を制御してください、再構成」の新しいRecommendationに関する詳細を明らかにしながら飛行機局面を制御するために発見を広げるために働いています。
2. ASON Terminology and Abbreviations Related to Discovery
2. ASON用語と発見に関連する略語
ITU-T Recommendation G.8080 Amendment 1 [G.8080] and ITU-T Recommendation G.7714 [G.7714] provide definitions and mechanisms related to transport plane discovery.
ITU-T Recommendation G.8080 Amendment1[G.8080]とITU-T Recommendation G.7714[G.7714]は輸送機発見に関連する定義とメカニズムを提供します。
Note that in the context of this work, "Transport" relates to the data plane (sometimes called the transport plane or the user plane) and does not refer to the transport layer (layer 4) of the OSI seven layer model, nor to the concept of transport intended by protocols such as the Transmission Control Protocol (TCP).
「輸送」がこの仕事の文脈では、データ飛行機(時々輸送機かユーザ飛行機と呼ばれる)に関連して、OSI7階層モデルのトランスポート層(層4)、および通信制御プロトコル(TCP)などのプロトコルで意図する輸送の概念を参照しないことに注意してください。
Special care must be taken with the acronym "TCP", which within the context of the rest of this document means "Termination Connection Point" and does not indicate the Transmission Control Protocol.
頭文字語"TCP"と共に特別な注意を払わなければなりません。(それは、このドキュメントの残りの文脈の中に「終了接続ポイント」を意味して、通信制御プロトコルを示しません)。
2.1. Terminology
2.1. 用語
The reader is assumed to be familiar with the terminology in [LMP] and [LMP-TEST]. The following ITU-T terminology/abbreviations are used in this document:
読者が[LMP]と[LMP-TEST]の用語によく知られさせると思われます。 以下のITU-T用語/略語は本書では使用されます:
Connection Point (CP): A "reference point" that consists of a pair of co-located "unidirectional connection points" and therefore represents the binding of two paired bidirectional "connections".
接続拠点(CP): 1組の共同見つけられた「単方向の接続拠点」から成って、したがって2の結合を表す「基準点」は双方向の「接続」を対にしました。
Connection Termination Point (CTP): A connection termination point represents the state of a CP [M.3100].
接続終了ポイント(CTP): 接続終了ポイントはCP[M.3100]の州を代表します。
Characteristic Information: Signal with a specific format, which is transferred on "network connections". The specific formats will be defined in the technology-specific recommendations. For trails, the Characteristic Information is the payload plus the overhead. The information transferred is characteristic of the layer network.
独特の情報: 特定の形式で合図してください。(それは、「ネットワーク接続」のときに移されます)。 特定の書式は技術特有の推薦で定義されるでしょう。 道に関しては、Characteristic情報は、ペイロードとオーバーヘッドです。 移された情報は層のネットワークで独特です。
Link: A subset of ports at the edge of a subnetwork or access group that are associated with a corresponding subset of ports at the edge of another subnetwork or access group.
以下をリンクしてください。 別のサブネットワークかアクセス・グループの縁でポートの対応する部分集合に関連しているサブネットワークかアクセス・グループの縁のポートの部分集合。
Link Connection (LC): A transport entity that transfers information between ports across a link.
接続(LC)をリンクしてください: リンクの向こう側にポートの間に情報を移す輸送実体。
Fedyk, et al. Informational [Page 3] RFC 4394 Transport Network View of LMP February 2006
Fedyk、他 LMP2006年2月の情報[3ページ]のRFC4394転送ネットワーク視点
Network Connection (NC): A concatenation of link and subnetwork connections.
接続(NC)をネットワークでつないでください: リンクとサブネットワーク接続の連結。
Subnetwork: A set of ports that are available for the purpose of routing 'characteristic information'.
サブネットワーク: 1セットの'独特の情報'を発送する目的に利用可能なポート。
Subnetwork Connection (SNC): A flexible connection that is set up and released using management or control plane procedures.
サブネットワーク接続(SNC): 管理かコントロール飛行機手順を用いることでセットアップされて、釈放されるフレキシブルな接続。
Subnetwork Point (SNP): SNP is an abstraction that represents an actual or potential underlying connection point (CP) or termination connection point (TCP) for the purpose of control plane representation.
サブネットワークポイント(SNP): SNPは規制飛行機表現の目的のために、実際の、または、潜在的の基本的な接続拠点(CP)か終了接続拠点(TCP)を表す抽象化です。
Subnetwork Point Pool (SNPP): A set of SNPs that are grouped together for the purpose of routing.
サブネットワークポイントプール(SNPP): ルーティングの目的のために一緒に分類されるSNPsの1セット。
Termination Connection Point (TCP): A reference point that represents the output of a Trail Termination source function or the input to a Trail Termination sink function. A network connection represents a transport entity between TCPs.
終了接続拠点(TCP): Trail Terminationソース機能か入力の出力をTrail Termination流し台機能に表す基準点。 ネットワーク接続はTCPsの間の輸送実体を表します。
Trail Termination source/sink function: A "transport processing function" that accepts the characteristic information of the layer network at its input, removes the information related to "trail" monitoring, and presents the remaining information at its output.
Terminationソース/流し台機能を引きずってください: 入力のときに層のネットワークの独特の情報を受け入れる「輸送処理機能」は、「道」モニターに関連する情報を取り除いて、出力のときに残っている情報を提示します。
Unidirectional Connection: A "transport entity" that transfers information transparently from input to output.
単方向の接続: 出力する情報から透過的に移動する「輸送実体」入力。
Unidirectional Connection Point: A "reference point" that represents the binding of the output of a "unidirectional connection" to the input of another "unidirectional connection".
単方向の接続ポイント: 「単方向の接続」の出力の結合を別の「単方向の接続」の入力に表す「基準点。」
2.2. Abbreviations
2.2. 略語
LMP: Link Management Protocol
LMP: リンク管理プロトコル
OTN: Optical Transport Network
OTN: 光学転送ネットワーク
PDH: Plesiosynchronous Digital Hierarchy
PDH: Plesiosynchronousのデジタル階層構造
SDH: Synchronous Digital Hierarchy
SDH: 同期デジタルハイアラーキ
SONET: Synchronous Optical Network
Sonet: 同期式光通信網
Fedyk, et al. Informational [Page 4] RFC 4394 Transport Network View of LMP February 2006
Fedyk、他 LMP2006年2月の情報[4ページ]のRFC4394転送ネットワーク視点
3. Transport Network Architecture
3. 転送ネットワークアーキテクチャ
A generic functional architecture for transport networks is defined in International Telecommunication Union (ITU-T) Recommendation [G.805]. This recommendation describes the functional architecture of transport networks in a technology-independent way. This architecture forms the basis for a set of technology-specific architectural recommendations for transport networks (e.g., SDH, PDH, OTN, etc.).
転送ネットワークのためのジェネリック機能的な建築は国際電気通信連合(ITU-T)の推薦[G.805]で定義されます。 この推薦は技術から独立している方法で転送ネットワークの機能的な建築について説明します。 このアーキテクチャは転送ネットワーク(例えば、SDH、PDH、OTNなど)のために1セットの技術特有の建築推薦の基礎を形成します。
The architecture defined in G.805 is designed using a layered model with a client-server relationship between layers. The architecture is recursive in nature; a network layer is both a server to the client layer above it and a client to the server layer below it. There are two basic building blocks defined in G.805: "subnetworks" and "links". A subnetwork is defined as a set of ports that are available for the purpose of routing "characteristic information". A link consists of a subset of ports at the edge of one subnetwork (or "access group") and is associated with a corresponding subset of ports at the edge of another subnetwork or access group.
G.805で定義されたアーキテクチャは、層の間のクライアント/サーバー関係と共に層にされたモデルを使用することで設計されています。 アーキテクチャは現実に再帰的です。 ネットワーク層はクライアント層へのそれの上のサーバとサーバ層へのそれの下のクライアントの両方です。 G.805で定義された2つの基本的なブロックがあります: 「サブネットワーク」と「リンク。」 サブネットワークは1セットの「独特の情報」を発送する目的に利用可能なポートと定義されます。 リンクは、1つのサブネットワーク(または、「アクセス・グループ」)の縁でポートの部分集合から成って、別のサブネットワークかアクセス・グループの縁でポートの対応する部分集合に関連しています。
Two types of connections are defined in G.805: link connection (LC) and subnetwork connection (SNC). A link connection is a fixed and inflexible connection, while a subnetwork connection is flexible and is set up and released using management or control plane procedures. A network connection is defined as a concatenation of subnetwork and link connections. Figure 1 illustrates link and subnetwork connections.
2つのタイプの接続はG.805で定義されます: 接続(LC)とサブネットワーク接続(SNC)をリンクしてください。 リンク結合は修理されて堅い接続です、サブネットワーク接続は、管理かコントロール飛行機手順を用いることでフレキシブルであり、セットアップされて、釈放されますが。 ネットワーク接続はサブネットワークとリンク結合の連結と定義されます。 図1はリンクとサブネットワーク接続を例証します。
(++++++++) (++++++++)
( SNC ) LC ( SNC )
(o)--------(o)----------(o)--------(o)
( ) CP CP ( )
(++++++++) (++++++++)
(+ + + + + + + +) (+ + + + + + + +)(SNC)LC(SNC)(o)--------(o)----------(o)--------(o) ( ) CP CP( )(+ + + + + + + +)(++++++++)
subnetwork subnetwork
サブネットワークサブネットワーク
Figure 1: Subnetwork and Link Connections
図1: サブネットワークとリンク結合
G.805 defines a set of reference points for the purpose of identification in both the management and the control planes. These identifiers are NOT required to be the same. A link connection or a subnetwork connection is delimited by connection points (CPs). A network connection is delimited by a termination connection point (TCP). A link connection in the client layer is represented by a pair of adaptation functions and a trail in the server layer network. A trail represents the transfer of monitored adapted characteristics information of the client layer network between access points (APs).
G.805は識別の目的のために管理と制御飛行機の両方で1セットの基準点を定義します。 これらの識別子は、同じになるのに必要ではありません。 接続拠点(CPs)によってリンク結合かサブネットワーク接続が区切られます。 終了接続拠点(TCP)によってネットワーク接続は区切られます。 クライアント層のリンク結合は1組の適合機能と道によってサーバ層のネットワークで代理をされます。 道はアクセスポイント(APs)の間のクライアント層ネットワークのモニターされた適合している特性の情報の転送を表します。
Fedyk, et al. Informational [Page 5] RFC 4394 Transport Network View of LMP February 2006
Fedyk、他 LMP2006年2月の情報[5ページ]のRFC4394転送ネットワーク視点
A trail is delimited by two access points, one at each end of the trail. Figure 2 shows a network connection and its relationship with link and subnetwork connections. Figure 2 also shows the CP and TCP reference points.
道は2つのアクセスポイント、道の各端の1までに区切られます。 図2はリンクとサブネットワーク接続とのネットワーク接続とその関係を示しています。 また、図2はCPとTCPに基準点を示しています。
|<-------Network Connection---------->|
| |
| (++++++++) (++++++++) |
|( SNC ) LC ( SNC ) |
(o)--------(o)----------(o)--------(o)|
TCP( )| CP CP |( )TCP
(++++++++) | | (++++++++)
| |
| Trail |
|<-------->|
| |
--- ---
\ / \ /
- -
AP 0 0 AP
| |
(oo)------(oo)
| <。-------ネットワーク接続---------->|、|、|、| (++++++++) (++++++++) | |(SNC) LC(SNC)| (o)--------(o)----------(o)--------(o)| TCP( )| CP CP|( )TCP(+ + + + + + + +)| | (++++++++) | | | 道| | <、-、-、-、-、-、-、--、>|、|、| --- --- \/\/----AP0 0AP| | (oo)------(oo)
Figure 2: Network Connection with Link and Subnetwork Connections
図2: リンクとのネットワーク接続とサブネットワークコネクションズ
For management plane purposes, the G.805 reference points are represented by a set of management objects described in ITU-T Recommendation M.3100 [M.3100]. Connection termination points (CTPs) and trail termination points (TTPs) are the management plane objects for CP and TCP, respectively.
管理飛行機目的のために、G.805基準点はITU-T Recommendation M.3100[M.3100]で説明された1セットの管理オブジェクトによって表されます。 接続終了ポイント(CTPs)と道の終了ポイント(TTPs)はそれぞれCPとTCPのための管理飛行機オブジェクトです。
In the same way as in M.3100, the transport resources in G.805 are identified for the purposes of the control plane by entities suitable for connection control. G.8080 introduces the reference architecture for the control plane of the Automatically Switched Optical Networks (ASONs). G.8080 introduces a set of reference points relevant to the ASON control plane and their relationship to the corresponding points in the transport plane. A subnetwork point (SNP) is an abstraction that represents an actual or potential underlying CP or an actual or potential TCP. A set of SNPs that are grouped together for the purpose of routing is called SNP pool (SNPP). Similar to LC and SNC, the SNP-SNP relationship may be static and inflexible (this is referred to as an SNP link connection), or it can be dynamic and flexible (this is referred to as an SNP subnetwork connection).
M.3100と同様に、G.805の輸送リソースは制御飛行機の目的のために接続コントロールに適した実体によって特定されます。 G.8080はAutomatically Switched Optical Networks(ASONs)の制御飛行機のために参照アーキテクチャを紹介します。 G.8080はASON制御飛行機に関連している基準点と輸送機の対応するポイントとのそれらの関係の1セットを導入します。 サブネットワークポイント(SNP)は実際の、または、潜在的の基本的なCPか実際の、または、潜在的のTCPを表す抽象化です。 ルーティングの目的のために一緒に分類されるSNPsの1セットはSNPプール(SNPP)と呼ばれます。 それは、LCとSNCと同様です、SNP-SNP関係が、静的であって、融通がきかないかもしれませんか(これはSNPリンク結合と呼ばれます)、ダイナミック、またはフレキシブルである場合があります(これはSNPサブネットワーク接続と呼ばれます)。
Fedyk, et al. Informational [Page 6] RFC 4394 Transport Network View of LMP February 2006
Fedyk、他 LMP2006年2月の情報[6ページ]のRFC4394転送ネットワーク視点
3.1. G.8080 Discovery Framework
3.1. G.8080発見フレームワーク
G.8080 provides a reference control plane architecture based on the descriptive use of functional components representing abstract entities and abstract component interfaces. The description is generic, and no particular physical partitioning of functions is implied. The input/output information flows associated with the functional components serve for defining the functions of the components and are considered to be conceptual, not physical. Components can be combined in different ways, and the description is not intended to limit implementations. Control plane discovery is described in G.8080 by using three components: Discovery Agent (DA), Termination and Adaptation Performer (TAP), and Link Resource Manager (LRM).
G.8080は抽象的実体と抽象的なコンポーネントインタフェースを表す機能部品の記述的用法に基づく参照規制飛行機アーキテクチャを提供します。 記述はジェネリックです、そして、機能の特定の物理的な仕切りは含意されません。 入力/出力情報流れは、コンポーネントの機能を定義するための機能部品サーブと交際して、物理的であるのではなく、概念的であると考えられます。 異なった方法でコンポーネントを結合できます、そして、記述が実装を制限することを意図しません。 コントロール飛行機発見はG.8080で3つのコンポーネントを使用することによって、説明されます: 発見エージェント(DA)、終了、適合パフォーマー(蛇口)、およびリンク資源管理プログラム(LRM)。
The objective of the discovery framework in G.8080 is to establish the relationship between CP-CP link connections (transport plane) and SNP-SNP link connections (control plane). The fundamental characteristics of G.8080 discovery framework is the functional separation between the control and the transport plane discovery processes and name spaces. From G.8080: "This separation allows control plane names to be completely separate from transport plane names, and completely independent of the method used to populate the DAs with those transport names. In order to assign an SNP-SNP link connection to an SNPP link, it is only necessary for the transport name for the link connection to exist". Thus, it is possible to assign link connections to the control plane without the link connection being physically connected.
G.8080の発見フレームワークの目的はCP-CPリンク結合(輸送機)とSNP-SNPリンク結合(制御飛行機)との関係を確立することです。 G.8080発見フレームワークの基本的な特性はコントロールと、輸送機発見プロセスと名前空間の間の機能分離です。 G.8080から: 「この分離は、規制飛行機名が輸送機名、完全にそれらの輸送名でDAsに居住するのに使用されるメソッドおよびの如何にかかわらず完全に別々であることを許容します。」 「SNPPリンクにSNP-SNPリンク結合を選任するために、リンク結合が存在するのが単に輸送名に必要です。」 したがって、物理的に接されるリンク結合なしで制御飛行機にリンク結合を選任するのは可能です。
Discovery encompasses two separate processes: (1) transport plane discovery, i.e., CP-to-CP and TCP-to-TCP connectivity; and (2) control plane discovery, i.e., SNP-to-SNP and SNPP links.
発見は2つの別々のプロセスを取り囲みます: (1) すなわち、輸送機発見、CPへのCPとTCPへのTCPの接続性。 (2) そして、飛行機発見、すなわち、SNPからSNPとSNPPリンクを制御してください。
G.8080 Amendment 1 defines the Discovery Agent (DA) as the entity responsible for discovery in the transport plane. The DA operates in the transport name space only and in cooperation with the Termination and Adaptation Performer (TAP), provides the separation between that space and the control plane names. A local DA is only aware of the CPs and TCPs that are assigned to it. The DA holds the CP-CP link connection in the transport plane to enable SNP-SNP link connections to be bound to them at a later time by the TAP. The CP-CP relationship may be discovered (e.g., per G.7714.1) or provided by a management system.
G.8080修正1はディスカバリーエージェント(DA)を輸送機での発見に原因となる実体と定義します。 DAは単に、そして、TerminationとAdaptation Performer(TAP)と提携してスペースという輸送名で作動して、そのスペースと規制飛行機名の間に分離を提供します。 地方のDAはそれに割り当てられるCPsとTCPsを意識しているだけです。 DAは、SNP-SNPリンク結合が後でTAPによって彼らに縛られるのを可能にするために輸送機にCP-CPリンク結合を保持します。 マネージメントシステムはCP-CP関係を発見するか(例えば、G.7714.1単位で)、または提供するかもしれません。
Control plane discovery takes place entirely within the control plane name space (SNPs). The Link Resource Manager (LRM) holds the SNP-SNP binding information necessary for the control plane name of the link connection, while the termination adaptation performer (TAP) holds
コントロール飛行機発見はコントロール飛行機名前スペース(SNPs)の中で完全に行われます。 Link Resourceマネージャ(LRM)はリンク結合の規制飛行機名に必要であるとしてSNP-SNPの拘束力がある情報を保持します、終了適合パフォーマー(TAP)は成立しますが
Fedyk, et al. Informational [Page 7] RFC 4394 Transport Network View of LMP February 2006
Fedyk、他 LMP2006年2月の情報[7ページ]のRFC4394転送ネットワーク視点
the relation between the control plane name (SNP) and the transport plane name (CP) of the resource. Figure 3 shows the relationship and the different entities for transport and control discoveries.
規制飛行機名(SNP)とリソースの輸送機名(CP)との関係。 図3は輸送とコントロール発見のために関係と異なった実体を示しています。
LRM LRM
+-----+ holds SNP-SNP Relation +-----+
| |-------------------------| |
+-----+ +-----+
| |
v v
+-----+ +-----+
| o | SNPs in SNPP | o |
| | | |
| o | | o |
| | | |
| o | | o |
+-----+ +-----+
| |
v v Control Plane
+-----+ +-----+ Discovery
| | Termination and | |
---|-----|-------------------------|-----|---------
| | Adaptation Performer | |
+-----+ (TAP) +-----+ Transport Plane
| \ / | Discovery
| \ / |
| +-----+ +-----+ |
| | DA | | DA | |
| | | | | |
| +-----+ +-----+ |
| / \ |
V/ \V
O CP (Transport Name) O CP (Transport Name)
LRM LRM+-----SNP-SNP Relationは+が+を保持します。-----+ | |-------------------------| | +-----+ +-----+ | | v対+-----+ +-----+ | o | SNPPのSNPs| o | | | | | | o | | o | | | | | | o | | o | +-----+ +-----+ | | v Control Plane+に対して-----+ +-----+ 発見| | そして終了。| | ---|-----|-------------------------|-----|--------- | | 適合パフォーマー| | +-----+ (叩きます)+-----+ 輸送機| \ / | 発見| \ / | | +-----+ +-----+ | | | DA| | DA| | | | | | | | | +-----+ +-----+ | | / \ | V/\V O CP(輸送名)O CP(輸送名)
Figure 3: Discovery in the Control and the Transport Planes
図3: コントロールと輸送機での発見
Fedyk, et al. Informational [Page 8] RFC 4394 Transport Network View of LMP February 2006
Fedyk、他 LMP2006年2月の情報[8ページ]のRFC4394転送ネットワーク視点
4. Discovery Technologies
4. 発見技術
4.1. Generalized Automatic Discovery Techniques G.7714
4.1. 一般化された自動発見テクニックG.7714
Generalized automatic discovery techniques are described in G.7714 to aid resource management and routing for G.8080. The term routing here is described in the transport context of routing connections in an optical network as opposed to the routing context typically associated in packet networks.
一般化された自動発見のテクニックは、G.8080のために資源管理とルーティングを支援するためにG.7714で説明されます。 ここでの用語ルーティングはパケット網で通常関連しているルーティング文脈と対照的にルーティング接続の輸送文脈で光学ネットワークで説明されます。
G.7714 is concerned with two types of discovery:
G.7714は2つのタイプの発見に関係があります:
- Layer adjacency discovery - Physical media adjacency discovery
- 層の隣接番組発見--物理的なメディア隣接番組発見
Layer adjacency discovery can be used to correlate physical connections with management configured attributes. Among other features this capability allows reduction in configuration and the detection of mis-wired equipment.
管理の構成された属性との物理接続を関連させるのに層の隣接番組発見を使用できます。 この能力が中の減少に構成と検出を許す他の特徴、誤配線、設備。
Physical media adjacency discovery is a process that allows the physical testing of the media for the purpose of inventory capacity and verifying the port characteristics of physical media adjacent networks.
物理的なメディア隣接番組発見は目録容量とネットワークに隣接して物理的なメディアのポートの特性について確かめる目的のためのメディアの物理的なテストを許すプロセスです。
G.7714 does not specify specific protocols but rather the type of techniques that can be used. G.7714.1 specifies a protocol for layer adjacency with respect to SDH and OTN networks for layer adjacency discovery. A GMPLS method for layer discovery using elements of LMP is included in this set of procedures.
G.7714は特定のプロトコルではなく、むしろ使用できるテクニックのタイプを指定します。 G.7714.1は層の隣接番組発見としてSDHとOTNネットワークに関して層の隣接番組にプロトコルを指定します。 LMPの要素を使用する層の発見のためのGMPLSメソッドはこのセットの手順に含まれています。
An important point about the G.7714 specification is that it specifies a discovery mechanism for optical networks but not necessarily how the information will be used. It is intended that the transport management plane or a transport control plane may subsequently make use of the discovered information.
G.7714仕様に関する重要なポイントは情報が必ずどう使用されるだろうかではなく、光学ネットワークに発見メカニズムを指定するということです。 輸送管理飛行機か輸送制御飛行機が次に発見された情報を利用するかもしれないことを意図します。
4.2. LMP and G.8080 Terminology Mapping
4.2. LMPとG.8080用語マッピング
GMPLS is a set of IP-based protocols, including LMP, providing a control plane for multiple data plane technologies, including optical/transport networks and their resources (i.e., wavelengths, timeslots, etc.) and without assuming any restriction on the control plane architecture (see [RFC3945]). On the other hand, G.8080 defines a control plane reference architecture for optical/transport networks without any restriction on the control plane implementation. Being developed in separate standards forums, and with different scopes, they use different terms and definitions.
GMPLSは1セットのIPベースのプロトコルです、LMPを含んでいて、複数のデータ飛行機技術に制御飛行機を提供して、光学/転送ネットワーク、それらのリソース(すなわち、波長、timeslotsなど)、およびどんな制限も進行中であると仮定することのない規制飛行機アーキテクチャを含んでいて([RFC3945]を見てください)。 他方では、G.8080は光学/転送ネットワークのために無制限にコントロール飛行機実装で規制飛行機参照アーキテクチャを定義します。 別々の規格フォーラム、および異なった範囲で開発されて、それらは異なった用語と定義を使用します。
Fedyk, et al. Informational [Page 9] RFC 4394 Transport Network View of LMP February 2006
Fedyk、他 LMP2006年2月の情報[9ページ]のRFC4394転送ネットワーク視点
Terminology mapping between LMP and ASON (G.805/G.8080) is an important step towards the understanding of the two architectures and allows for potential cooperation in areas where cooperation is possible. To facilitate this mapping, we differentiate between the two types of data links in LMP. According to LMP, a data link may be considered by each node that it terminates on as either a 'port' or a 'component link'. The LMP notions of port and component link are supported by the G.805/G.8080 architecture. G.8080's variable adaptation function is broadly equivalent to LMP's component link, i.e., a single server-layer trail dynamically supporting different multiplexing structures. Note that when the data plane delivers its own addressing space, LMP Interface_IDs and Data Links IDs are used as handles by the control plane to the actual CP Name and CP-to-CP Name, respectively.
LMPとASONの間で(G.805/G.8080)を写像する用語が、2つのアーキテクチャの理解に向かった重要なステップであり、協力が可能である領域で潜在的協力を考慮します。 このマッピングを容易にするために、私たちはLMPで2つのタイプのデータ・リンクを区別します。 LMPによると、データ・リンクはそれが'ポート'か'コンポーネントリンク'のどちらかとして終わる各ノードによって考えられるかもしれません。 ポートとコンポーネントリンクのLMP概念はG.805/G.8080アーキテクチャによってサポートされます。 G.8080の可変適合機能はLMPのコンポーネントリンク(すなわち、ダイナミックに異なったマルチプレクシング構造を支える単一のサーバ層の道)に広く同等です。 データ飛行機が、それ自身がスペースを扱うのを提供するとき、LMP Interface_IDとDataリンクスIDsがハンドルとして実際のCP Nameへの制御飛行機とCP NameへのCPによってそれぞれ使用されることに注意してください。
The terminology mapping is summarized in the following table: Note that the table maps ASON terms to GMPLS terms that refer to equivalent objects, but in many cases there is not a one-to-one mapping. Additional information beyond discovery terminology can be found in [LEXICO].
用語マッピングは以下のテーブルにまとめられます: テーブルがASON用語から同等なオブジェクトについて言及するGMPLS用語を写像することに注意しなさい、ただし、多くの場合、1〜1つのマッピングがありません。 [LEXICO]で発見用語を超えた追加情報を見つけることができます。
Fedyk, et al. Informational [Page 10] RFC 4394 Transport Network View of LMP February 2006
Fedyk、他 LMP2006年2月の情報[10ページ]のRFC4394転送ネットワーク視点
+----------------+--------------------+-------------------+ | ASON Terms | GMPLS/LMP Terms | GMPLS/LMP Terms | | | Port | Component Link | +----------------+--------------------+-------------------+ | CP | TE Resource; | TE Resource; | | | Interface (Port) | Interface. | | | |(Comp. link) | +----------------+--------------------+-------------------+ | CP Name | Interface ID | Interface ID(s) | | | no further sub- | resources (such as| | | division for(label)| timeslots, etc.) | | | resource allocation| on this interface | | | | are identified by | | | | set of labels | +----------------+--------------------+-------------------+ | CP-to-CP Link | Data Link | Data Link | +----------------+--------------------+-------------------+ | CP-to-CP Name | Data Link ID | Data Link ID | +----------------+--------------------+-------------------+ | SNP | TE Resource | TE Resource | +----------------+--------------------+-------------------+ | SNP Name | Link ID | Link ID | +----------------+--------------------+-------------------+ | SNP LC | TE Link | TE Link | +----------------+--------------------+-------------------+ | SNP LC Name | TE Link ID | TE Link ID | +----------------+--------------------+-------------------+ | SNPP | TE Link End | TE Link End | | | (Port) | (Comp. Link) | +----------------+--------------------+-------------------+ | SNPP Name | Link ID | Link ID | +----------------+--------------------+-------------------+ | SNPP Link | TE Link | TE Link | +----------------+--------------------+-------------------+ | SNPP Link Name | TE Link ID | TE Link ID | +----------------+--------------------+-------------------+
+----------------+--------------------+-------------------+ | ASON用語| GMPLS/LMP用語| GMPLS/LMP用語| | | ポート| コンポーネントリンク| +----------------+--------------------+-------------------+ | CP| Teリソース。 | Teリソース。 | | | インタフェース(ポート)| 連結してください。 | | | |(コンピュータリンク) | +----------------+--------------------+-------------------+ | CP名| インタフェースID| インタフェースID(s)| | | これ以上、サブ| リソース(| | | (ラベル)| timeslotsなどのための分割などの) | | | 資源配分| このインタフェースに関して| | | | 特定されます。| | | | ラベルのセット| +----------------+--------------------+-------------------+ | CPからCPへのリンク| データ・リンク| データ・リンク| +----------------+--------------------+-------------------+ | CPからCPへの名| データ・リンクID| データ・リンクID| +----------------+--------------------+-------------------+ | SNP| Teリソース| Teリソース| +----------------+--------------------+-------------------+ | SNP名| IDをリンクしてください。| IDをリンクしてください。| +----------------+--------------------+-------------------+ | SNP LC| Teリンク| Teリンク| +----------------+--------------------+-------------------+ | SNP LC名| TeリンクID| TeリンクID| +----------------+--------------------+-------------------+ | SNPP| Teリンクエンド| Teリンクエンド| | | (ポート) | (コンピュータ。 リンク) | +----------------+--------------------+-------------------+ | SNPP名| IDをリンクしてください。| IDをリンクしてください。| +----------------+--------------------+-------------------+ | SNPPリンク| Teリンク| Teリンク| +----------------+--------------------+-------------------+ | SNPPリンク名| TeリンクID| TeリンクID| +----------------+--------------------+-------------------+
where composite identifiers are:
合成しているところでは、識別子は以下の通りです。
- Data Link ID: <Local Interface ID; Remote Interface ID> - TE Link ID: <Local Link ID; Remote Link ID>
- データはIDをリンクします: <局所界面ID。 リモートインタフェースID>--TeリンクID: <の地方のリンクID。 リモートリンクID>。
Composite Identifiers are defined in the RFC 4204 [LMP]. LMP discovers data links and identifies them by the pair of local and remote interface IDs. TE links are composed of data links or component TE links. TE links are similarly identified by pair of local and remote link ID.
合成IdentifiersはRFC4204[LMP]で定義されます。 LMPは地方の、そして、リモートなインタフェースIDの組でデータ・リンクを発見して、それらを特定します。 TEリンクはデータ・リンクかコンポーネントTEリンクで構成されます。 TEリンクは地方の、そして、リモートなリンクIDの組によって同様に特定されます。
Fedyk, et al. Informational [Page 11] RFC 4394 Transport Network View of LMP February 2006
Fedyk、他 LMP2006年2月の情報[11ページ]のRFC4394転送ネットワーク視点
4.2.1. TE Link Definition and Scope
4.2.1. Teリンク定義と範囲
In the table, TE link/resource is equated with the concept of SNP, SNP LC, SNPP, and SNPP link. The definition of the TE link is broad in scope, and it is useful to repeat it here. The original definition appears in [GMPLS-RTG]:
テーブルでは、TEリンク/リソースはSNP、SNP LC、SNPP、およびSNPPリンクの概念と同一視されます。 TEリンクの定義は範囲で広いです、そして、ここでそれを繰り返すのは役に立ちます。 オリジナルの定義は[GMPLS-RTG]に現れます:
"A TE link is a logical construct that represents a way to group/map the information about certain physical resources (and their properties) that interconnects LSRs into the information that is used by Constrained SPF for GMPLS path computation, and GMPLS signaling".
「TEリンクはGMPLS経路計算、およびGMPLSシグナリングにConstrained SPFによって使用される情報とLSRsとインタコネクトするある物理資源(そして、彼らの特性)の情報を分類するか、または写像する方法を表す論理的な構造物です。」
While this definition is concise, it is probably worth pointing out some of the implications of the definition.
この定義は簡潔ですが、定義の含意のいくつかを指摘するたぶん価値があります。
A component of the TE link may follow different paths between the pair of LSRs. For example, a TE link comprising multiple STS-3cs, the individual STS-3cs component links may take identical or different physical (OC-3 and/or OC-48) paths between LSRs.
TEリンクの部品はLSRsの組の間の異なった経路に続くかもしれません。 例えば、TEリンクが複数のSTS-3csを包括する場合、個々のSTS-3csコンポーネントリンクはLSRsの間の同じであるか異なった物理的な(OC-3、そして/または、OC-48)経路を取るかもしれません。
The TE link construct is a logical construction encompassing many layers in networks [RFC3471]. A TE link can represent either unallocated potential or allocated actual resources. Further allocation is represented by bandwidth reservation, and the resources may be real or, in the case of packets, virtual to allow for overbooking or other forms of statistical multiplexing schemes.
TEリンク構造物はネットワーク[RFC3471]における多くの層を取り囲む論理的構成です。 TEリンクは「非-割り当て」られた可能性か割り当てられた実際のリソースのどちらかを表すことができます。 さらなる配分は帯域幅の予約で表されます、そして、リソースは本当の、または、オーバーブックすると考慮するためにはパケットのケースにおける仮想の、または、他のフォームの統計的多重化大要であるかもしれません。
Since TE links may represent large numbers of parallel resources, they can be bundled for efficient summarization of resource capacity. Typically, bundling represents a logical TE link resource at a particular Interface Switching Capability. Once TE link resources are allocated, the actual capacity may be represented as LSP hierarchical (tunneled) TE link capability in another logical TE link [HIER].
TEリンクが多くの平行なリソースを表すかもしれないので、リソース容量の効率的な総括のためにそれらを添付することができます。 通常、バンドリングは特定のInterface Switching Capabilityに論理的なTEリンクリソースを表します。 いったんTEリンクリソースを割り当てると、LSPの階層的な(トンネルを堀られる)TEが別の論理的なTEリンク[HIER]で能力をリンクするとき、実能力を表すかもしれません。
TE links also incorporate the notion of a Forwarding Adjacency (FA) and Interface Switching Capability [RFC3945]. The FA allows transport resources to be represented as TE links. The Interface Switching Capability specifies the type of transport capability such as Packet Switch Capable (PSC), Layer-2 Switch Capable (L2SC), Time- Division Multiplex (TDM), Lambda Switch Capable (LSC), and Fiber- Switch Capable (FSC).
また、TEリンクはForwarding Adjacency(FA)とInterface Switching Capability[RFC3945]の概念を取り入れます。 TEがリンクするとき、FAは、輸送リソースが表されるのを許容します。 Interface Switching CapabilityはPacket Switch Capable(PSC)や、Layer-2 Switch Capable(L2SC)や、Time事業部Multiplex(TDM)や、Lambda Switch Capable(LSC)や、FiberスイッチCapable(FSC)などの輸送能力のタイプを指定します。
A TE link between GMPLS-controlled optical nodes may consist of a bundled TE link, which itself consists of a mix of point-to-point component links [BUNDLE]. A TE link is identified by the tuple (link Identifier (32-bit number), Component link Identifier (32-bit number), and generalized label (media specific)).
GMPLSによって制御された光学ノードの間のTEリンクは添付されたTEリンクから成るかもしれません。(それ自体で、それは、二地点間コンポーネントリンク[BUNDLE]のミックスから成ります)。 TEリンクはtuple(リンクIdentifier(32ビットの数)、ComponentリンクIdentifier(32ビットの数)、および一般化されたラベル(メディア詳細))によって特定されます。
Fedyk, et al. Informational [Page 12] RFC 4394 Transport Network View of LMP February 2006
Fedyk、他 LMP2006年2月の情報[12ページ]のRFC4394転送ネットワーク視点
4.3. LMP and G.8080 Discovery Relationship
4.3. LMPとG.8080発見関係
LMP currently consists of four primary procedures, of which the first two are mandatory and the last two are optional:
LMPは現在、4つのプライマリ手順から成ります:(そこでは、最初の2が義務的であり、最後の2は任意です)。
1. Control channel management
2. Link property correlation
3. Link verification
4. Fault management
1. チャンネル管理2を制御してください。 特性の相関関係3をリンクしてください。 検証4をリンクしてください。 障害管理
LMP procedures that are relevant to G.8080 control plane discovery are control channel management, link property correlation, and link verification. Key to understanding G.8080 discovery aspects in relation to [LMP] is that LMP procedures are specific for an IP-based control plane abstraction of the transport plane.
G.8080コントロール飛行機発見に関連しているLMP手順は、コントロールチャンネル管理であり、特性の相関関係をリンクして、検証をリンクします。 [LMP]と関連してG.8080発見局面を理解するキーによる輸送機のIPベースのコントロール飛行機抽象化に、LMP手順が特定であるということです。
LMP control channel management is used to establish and maintain control channel connectivity between LMP adjacent nodes. In GMPLS, the control channels between two adjacent nodes are not required to use the same physical medium as the TE links between those nodes. The control channels that are used to exchange the GMPLS control plane information exist independently of the TE links they manage (i.e., control channels may be in-band or out-of-band, provided the associated control points terminate the LMP packets). The Link Management Protocol [LMP] was designed to manage TE links, independently of the physical medium capabilities of the data links.
LMPコントロールチャンネル管理は、LMP隣接しているノードの間のコントロールチャンネルの接続性を確立して、維持するのに使用されます。 GMPLSでは、2つの隣接しているノードの間の制御チャンネルは、それらのノードの間のTEリンクと同じ物理的な媒体を使用するのに必要ではありません。 GMPLSコントロール飛行機情報を交換するのに使用される制御チャンネルはそれらが管理するTEリンクの如何にかかわらず存在しています(バンドかバンドの外ですなわち、制御チャンネルがそうです、関連制御点がLMPパケットを終えるなら)。 Link Managementプロトコル[LMP]はTEリンクを管理するように設計されました、データ・リンクの物理的な媒体能力の如何にかかわらず。
Link property correlation is used to aggregate multiple data links into a single TE link and to synchronize the link properties.
リンク特性の相関関係は、単一のTEリンクへの複数のデータ・リンクに集めて、リンクの特性を同期させるのに使用されます。
Link verification is used to verify the physical connectivity of the data links and verify the mapping of the Interface-ID to Link-ID (CP to SNP). The local-to-remote associations can be obtained using a priori knowledge or using the link verification procedure.
リンク検証は、Link-ID(SNPへのCP)にデータ・リンクの物理的な接続性について確かめて、Interface-IDに関するマッピングについて確かめるのに使用されます。 先験的な知識を使用するか、またはリンク検証手続を使用することで遠隔連合への地方を得ることができます。
Fault management is primarily used to suppress alarms and to localize failures. It is an optional LMP procedure; its use will depend on the specific technology's capabilities.
障害管理は、アラームを抑圧して、失敗をローカライズするのに主として使用されます。 それは任意のLMP手順です。 使用は独自技術の能力によるでしょう。
[LMP] supports distinct transport and control plane name spaces with the (out-of-band) TRACE object (see [LMP-TEST]). The LMP TRACE object allows transport plane names to be associated with interface identifiers [LMP-TEST].
[LMP]は、(バンドの外)TRACEオブジェクトで異なった輸送とコントロールが飛行機名前空間であるとサポートします([LMP-TEST]を見てください)。 LMP TRACEオブジェクトは、輸送機名がインタフェース識別子[LMP-TEST]に関連しているのを許容します。
Aspects of LMP link verification appear similar to G.7714.1 discovery; however, the two procedures are different. G.7714.1 provides discovery of the transport plane layer adjacencies. It provides a generic procedure to discover the connectivity of two
LMPリンク検証の局面はG.7714.1発見と同様に見えます。 しかしながら、2つの手順が異なっています。 G.7714.1は輸送機層の隣接番組の発見を提供します。 それは、2の接続性を発見するためにジェネリック手順を提供します。
Fedyk, et al. Informational [Page 13] RFC 4394 Transport Network View of LMP February 2006
Fedyk、他 LMP2006年2月の情報[13ページ]のRFC4394転送ネットワーク視点
endpoints in the transport plane. On the other hand, the LMP link verification procedure is a control-plane-driven procedure and assumes either (1) a priori knowledge of the associated data plane's local and remote endpoint connectivity and Interface_IDs (e.g., via management plane or use of G.7714.1), or (2) support of the remote node for associating the data interface being verified with the content of the TRACE object (inferred mapping). For SONET/SDH transport networks, LMP verification uses the SONET/SDH Trail Trace identifier (see [G.783]).
輸送機の終点。 他方では、LMPリンク検証手続は、(1) 関連データの機のローカルの、そして、リモートな終点の接続性とInterface_ID(例えば、G.7714.1の管理飛行機か使用を通した)に関する先験的な知識か(2) 交際するための遠隔ノードのサポートのどちらかがTRACEオブジェクト(マッピングを推論する)の内容で確かめられるデータインタフェースであると、運転された制御飛行機手順であり、仮定します。 Sonet/SDH転送ネットワークのために、LMP検証はSonet/SDH Trail Trace識別子を使用します([G.783]を見てください)。
G.7714.1 supports the use of transport plane discovery independent of the platform using the capability. Furthermore, G.7714.1 specifies the use of a Discovery Agent that could be located in an external system and the need to support the use of text-oriented man-machine language to provide the interface. Therefore, G.7714.1 limits the discovery messages to printable characters defined by [T.50] and requires Base64 encoding for the TCP-ID and DA ID. External name- servers may be used to resolve the G.7714.1 TCP name, allowing the TCP to have an IP, Network Service Access Protocol (NSAP), or any other address format. On the other hand, LMP is based on the use of an IP-based control plane, and the LMP interface ID uses IPv4, IPv6, or unnumbered interface IDs.
G.7714.1は、プラットホームの如何にかかわらず能力を使用することで輸送機発見の使用をサポートします。 その上、G.7714.1は外的システムに位置できたディスカバリーエージェントの使用とインタフェースを提供するためにテキスト指向の男性機械語の使用をサポートする必要性を指定します。 したがって、G.7714.1は発見メッセージを[T.50]によって定義された印刷可能なキャラクタに制限して、TCP-IDとDA IDのためのBase64コード化を必要とします。 外部名サーバはG.7714.1 TCP名を決議するのに使用されるかもしれません、TCPにはIP、Network Service Accessプロトコル(NSAP)、またはいかなる他のアドレス形式もあるのを許容して。 他方では、LMPはIPベースの制御飛行機の使用に基づいています、そして、LMPインタフェースIDはIPv4、IPv6、または無数のインタフェースIDを使用します。
4.4. Comparing LMP and G.8080
4.4. LMPとG.8080を比較します。
LMP exists to support GMPLS TE resource and TE link discovery. In section 4.2.1, we elaborated on the definition of the TE link. LMP enables the aspects of TE links to be discovered and reported to the control plane, more specifically, the routing plane. G.8080 and G.7714 are agnostic to the type of control plane and discovery protocol used. LMP is a valid realization of a control plane discovery process under a G.8080 model.
LMPは、GMPLS TEリソースとTEがリンク発見であるとサポートするために存在しています。 セクション4.2.1では、私たちはTEリンクの定義について詳しく説明しました。 LMPは、TEリンクの局面が、より明確に制御飛行機に発見されて、報告されるのを可能にします、ルーティング飛行機。 制御飛行機と使用される発見プロトコルのタイプにおいて、G.8080とG.7714は不可知論者です。 LMPはG.8080モデルの下におけるコントロール飛行機発見プロセスの有効な実現です。
G.7714 specifies transport plane discovery with respect to the transport layer CTPs or TCPs using ASON conventions and naming for the elements of the ASON control plane and the ASON management plane. This discovery supports a centralized management model of configuration as well as a distributed control plane model; in other words, discovered items can be reported to the management plane or the control plane. G.7714.1 provides one realization of a transport plane discovery process.
G.7714は、CTPsかTCPsトランスポート層に関してASON制御飛行機とASON管理飛行機の要素にASONコンベンションと命名を使用することで輸送機発見を指定します。 この発見は構成の集中的管理モデルと分散制御飛行機モデルをサポートします。 言い換えれば、管理飛行機か制御飛行機に発見された項目を報告できます。 G.7714.1は輸送機発見プロセスの1つの実現を提供します。
Today, LMP and G.7714, G7714.1 are defined in different standards organizations. They have evolved out of different naming schemes and architectural concepts. Whereas G.7714.1 supports a transport plane layer adjacency connectivity verification that can be used by a
今日、LMPとG.7714、G7714.1は異なった規格組織で定義されます。 それらは異なった命名体系とアーキテクチャ概念から発展しました。 G.7714.1は、輸送機層の隣接番組がaで使用できる接続性検証であるとサポートしますが
Fedyk, et al. Informational [Page 14] RFC 4394 Transport Network View of LMP February 2006
Fedyk、他 LMP2006年2月の情報[14ページ]のRFC4394転送ネットワーク視点
control plane or a management plane, LMP is a control plane procedure for managing GMPLS TE links (GMPLS's control plane representation of the transport plane connections).
制御飛行機か管理飛行機、LMPは、GMPLS TEリンク(GMPLSの輸送機接続の規制飛行機表現)を管理するためのコントロール飛行機手順です。
5. Security Considerations
5. セキュリティ問題
Since this document is purely descriptive in nature, it does not introduce any security issues.
このドキュメントが純粋に現実に描写的であるので、それは少しの安全保障問題も紹介しません。
G.8080 and G.7714/G.7714.1 provide security as associated with the Data Communications Network on which they are implemented.
G.8080とG.7714/G.7714.1はそれらが実装されるData Communications Networkに関連づけられるようにセキュリティを提供します。
LMP is specified using IP, which provides security mechanisms associated with the IP network on which it is implemented.
LMPは、IP(それが実装されるIPネットワークに関連しているセキュリティー対策を提供する)を使用することで指定されます。
6. Informative References
6. 有益な参照
[LMP] Lang, J., "Link Management Protocol (LMP)", RFC 4204,
October 2005.
[LMP] ラング、J.、「リンク管理プロトコル(LMP)」、RFC4204、2005年10月。
[LMP-TEST] Lang, J. and D. Papadimitriou, "Synchronous Optical
Network (SONET)/Synchronous Digital Hierarchy (SDH)
Encoding for Link Management Protocol (LMP) Test
Messages", RFC 4207, October 2005.
[LMP-テスト] ラング、J.とD.Papadimitriou、「リンク管理プロトコル(LMP)のためにテストメッセージをコード化する同期式光通信網(Sonet)/同期デジタルハイアラーキ(SDH)」RFC4207(2005年10月)。
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] マニー、E.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)アーキテクチャ」、RFC3945、2004年10月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3471] バーガー、L.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)のシグナリングの機能的な記述」、RFC3471、2003年1月。
[GMPLS-RTG] Kompella, K. and Y. Rekhter, "Routing Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005.
[GMPLS-RTG] KompellaとK.とY.Rekhter、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)を支持したルート設定拡大」、RFC4202、2005年10月。
[HIER] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October
2005.
[HIER]Kompella(K.とY.Rekhter)は「一般化されたマルチプロトコルラベルスイッチング(GMPLS)交通工学(Te)で切り換えられた経路(LSP)を階層構造とラベルします」、RFC4206、2005年10月。
[BUNDLE] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October
2005.
[バンドル]Kompella、K.、Rekhter、Y.、およびL.バーガー、「MPLS交通工学(Te)におけるリンクバンドリング」、RFC4201、2005年10月。
Fedyk, et al. Informational [Page 15] RFC 4394 Transport Network View of LMP February 2006
Fedyk、他 LMP2006年2月の情報[15ページ]のRFC4394転送ネットワーク視点
[LEXICO] Bryskin, I. and A. Farrel, "A Lexicography for the
Interpretation of Generalized Multiprotocol Label
Switching (GMPLS) Terminology within The Context of the
ITU-T's Automatically Switched Optical Network (ASON)
Architecture", Work in Progress, January 2006.
[LEXICO] 「ITU-Tの自動的に切り換えられた光学ネットワーク(ASON)アーキテクチャの文脈の中の一般化されたMultiprotocolラベルの切り換え(GMPLS)用語の解釈のための辞書編集」というBryskin、I.、およびA.ファレルは進行中(2006年1月)で働いています。
For information on the availability of the ITU-T documents, please see http://www.itu.int.
ITU-Tドキュメントの有用性の情報に関しては、 http://www.itu.int を見てください。
[G.783] ITU-T G.783 (2004), Characteristics of synchronous
digital hierarchy (SDH) equipment functional blocks.
[G.783]ITU-T G.783(2004)、同期デジタル階層構造(SDH)設備機能ブロックのCharacteristics。
[G.805] ITU-T G.805 (2000), Generic functional architecture of
transport networks.
[G.805]ITU-T G.805(2000)、転送ネットワークのGeneric機能的な建築。
[G.7714] ITU-T G.7714/Y.1705 (2001), Generalized automatic
discovery techniques.
[G.7714]ITU-T G.7714/Y.1705(2001)、Generalizedの自動発見のテクニック。
[G.7714.1] ITU-T G.7714.1/Y.1705.1 (2003), Protocol for automatic
discovery in SDH and OTN networks.
[G.7714.1]ITU-T G.7714.1/Y.1705.1(2003)、SDHでの自動発見とOTNネットワークのためのプロトコル。
[G.8080] ITU-T G.8080/Y.1304 (2001), Architecture for the
automatically switched optical network (ASON).
[G.8080]ITU-T G.8080/Y.1304(2001)、自動的に切り換えられた光学ネットワーク(ASON)のためのArchitecture。
[M.3100] ITU-T M.3100 (1995), Generic Network Information Model.
[M.3100]ITU-T M.3100(1995)、ジェネリックネットワーク情報モデル。
[T.50] ITU-T T.50 (1992), International Reference Alphabet.
[T.50]ITU-T T.50(1992)、国際参照アルファベット。
7. Acknowledgements
7. 承認
The authors would like to thank Astrid Lozano, John Drake, Adrian Farrel and Stephen Shew for their valuable comments.
作者は彼らの貴重なコメントについてAstridロサーノ、ジョン・ドレイク、エードリアン・ファレル、およびスティーブン・シューに感謝したがっています。
The authors would like to thank ITU-T Study Group 15 Question 14 for their careful review and comments.
作者は彼らの慎重なレビューとコメントについてITU-T Study Group15Question14に感謝したがっています。
Fedyk, et al. Informational [Page 16] RFC 4394 Transport Network View of LMP February 2006
Fedyk、他 LMP2006年2月の情報[16ページ]のRFC4394転送ネットワーク視点
Authors' Addresses
作者のアドレス
Don Fedyk Nortel Networks 600 Technology Park Drive Billerica, MA, 01821
Driveビルリカ、ドンFedykのノーテルネットワーク600技術Park MA 01821
Phone: +1 978 288-3041 EMail: dwfedyk@nortel.com
以下に電話をしてください。 +1 978 288-3041 メールしてください: dwfedyk@nortel.com
Osama Aboul-Magd Nortel Networks P.O. Box 3511, Station 'C' Ottawa, Ontario, Canada K1Y-4H7
駅の'C'オタワ、オンタリオ(カナダ)K1Y-4H7、オサマAboul-Magdノーテルは私書箱3511をネットワークでつなぎます。
Phone: +1 613 763-5827 EMail: osama@nortel.com
以下に電話をしてください。 +1 613 763-5827 メールしてください: osama@nortel.com
Deborah Brungard AT&T Rm. D1-3C22 200 S. Laurel Ave. Middletown, NJ 07748, USA
デボラBrungard AT&T Rm。 D1-3C22200秒間ローレルAve。 ミドルタウン、ニュージャージー 07748、米国
EMail: dbrungard@att.com
メール: dbrungard@att.com
Jonathan P. Lang Sonos, Inc. 223 E. De La Guerra Santa Barbara, CA 93101
ジョナサンP.ラングSonos Inc.223E.De Laグェルラ・サンタバーバラ、カリフォルニア 93101
EMail: jplang@ieee.org
メール: jplang@ieee.org
Dimitri Papadimitriou Alcatel Francis Wellesplein, 1 B-2018 Antwerpen, Belgium
ディミトリPapadimitriouアルカテルフランシスWellesplein、1B-2018のアントウェルペン(ベルギー)
Phone: +32 3 240-84-91 EMail: dimitri.papadimitriou@alcatel.be
以下に電話をしてください。 +32 3 240-84-91 メールしてください: dimitri.papadimitriou@alcatel.be
Fedyk, et al. Informational [Page 17] RFC 4394 Transport Network View of LMP February 2006
Fedyk、他 LMP2006年2月の情報[17ページ]のRFC4394転送ネットワーク視点
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントは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 provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Fedyk, et al. Informational [Page 18]
Fedyk、他 情報[18ページ]
一覧
スポンサーリンク
