[要約] RFC 4394は、リンク管理プロトコル（LMP）の輸送ネットワークビューに関する情報を提供します。このRFCの目的は、LMPを使用してネットワークリンクの状態を監視し、管理する方法を説明することです。
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
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）The Internet Society（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.
リンク管理プロトコル（LMP）は、一般化されたMPLS（GMPLS）プロトコルスイートの一部として開発され、トラフィックエンジニアリング（TE）リソースとリンクを管理しています。GMPLSコントロールプレーン（ルーティングとシグナリング）は、TEリンクを使用して、ラベルスイッチ付きパス（LSP）を確立します。このメモは、LMP手順と国際通信連合（ITU-T）で定義されている「発見」と「継続的なITU-T作業」との関係について説明しています。このドキュメントは、ITU-TのコンテキストでのLMPの概要を提供します。自動的に切り替えられた光ネットワーク（ASON）と輸送ネットワーク用語を提供し、IETFとITU-の作業を進めるための共通の理解を促進するためにITU-T発見作業に関連付けます。T.
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
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]で説明されているように、いくつかのビルディングブロックで構成されています。ビルディングブロックには、LSPを確立するためのシグナリング、ルーティング、およびリンク管理が含まれます。スケーラビリティのために、複数の物理リソースを組み合わせて、パス計算と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テスト]は、SONET/SDH固有のメッセージとリンク検証の手順を定義します。
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の推奨G.8080修正1 [G.8080]は、制御プレーンの発見を2つの別々のプロセスとして定義しています。1つのプロセスは輸送機スペース内で発生し、もう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 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.7714「一般化された自動発見技術」[G.7714]を開発し、輸送機の発見の側面に関連する機能プロセスと情報交換を定義します。特定の方法とプロトコルは、推奨G.7714では定義されていません。ITU-Tの推奨G.7714.1、「SDHおよびOTNネットワークでの自動発見のためのプロトコル」[G.7714.1]は、輸送機層隣接発見のプロトコルと手順を定義します（たとえば、輸送機層エンドポイントの関係を発見し、接続性を確認する）。ITU-Tは現在、G.8080のディスカバリーフレームワークアーキテクチャの詳細と「コントロールプレーンの初期確立、再構成」に関する新しい推奨事項を提供する飛行機の側面を制御するために発見を拡張するために取り組んでいます。
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の推奨G.8080修正1 [G.8080]およびITU-T推奨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).
この作業のコンテキストでは、「輸送」はデータプレーン（輸送機またはユーザープレーンと呼ばれることもあります）に関連しており、OSIセブンレイヤーモデルの輸送層（レイヤー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」には特別な注意が必要です。
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テスト]の用語に精通していると想定されています。このドキュメントでは、次の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）：共同配置された「単方向接続ポイント」のペアで構成される「基準点」。したがって、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.
特性情報：「ネットワーク接続」に転送される特定の形式で信号。特定の形式は、技術固有の推奨事項で定義されます。トレイルの場合、特徴的な情報はペイロードとオーバーヘッドです。転送される情報は、レイヤーネットワークの特徴です。
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）：リンク全体のポート間で情報を転送する輸送エンティティ。
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'.
サブネットワーク：「特性情報」をルーティングする目的で使用できるポートのセット。
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）：ルーティングの目的でグループ化されたSNPのセット。
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）：トレイル終端ソース関数の出力またはトレイル終端シンク関数への入力を表す基準点。ネットワーク接続は、TCP間の輸送エンティティを表します。
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.
トレイル終了ソース/シンク関数：その入力でレイヤーネットワークの特徴的な情報を受け入れる「輸送処理機能」、「トレイル」監視に関連する情報を削除し、その出力で残りの情報を提示します。
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".
単方向接続ポイント：別の「単方向接続」の入力への「単方向接続」の出力の結合を表す「基準点」。
LMP: Link Management Protocol
LMP：リンク管理プロトコル
OTN: Optical Transport Network
OTN：光輸送ネットワーク
PDH: Plesiosynchronous Digital Hierarchy
PDH：plesiosiosinchronousデジタル階層
SDH: Synchronous Digital Hierarchy
SDH：同期デジタル階層
SONET: Synchronous Optical Network
SONET：同期光ネットワーク
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など）に関する一連の技術固有のアーキテクチャの推奨事項の基礎を形成します。
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つの基本的なビルディングブロックがあります：「Subnetworks」と「リンク」。サブネットワークは、「特性情報」をルーティングする目的で使用できるポートのセットとして定義されます。リンクは、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 ( )
(++++++++) (++++++++)
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は、管理プレーンとコントロールプレーンの両方で識別を目的とした一連の参照ポイントを定義します。これらの識別子は同じである必要はありません。リンク接続またはサブネットワーク接続は、接続ポイント（CPS）によって区切られています。ネットワーク接続は、終端接続ポイント（TCP）によって区切られています。クライアントレイヤーのリンク接続は、一対の適応関数とサーバーレイヤーネットワークのトレイルで表されます。トレイルは、アクセスポイント（AP）間のクライアントレイヤーネットワークの監視対象の適応特性情報の転送を表します。
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.
トレイルは、トレイルの両端に1つずつ、2つのアクセスポイントで区切られています。図2は、ネットワーク接続とリンクおよびサブネットワーク接続との関係を示しています。図2は、CPおよびTCPの参照ポイントも示しています。
|<-------Network Connection---------->|
| |
| (++++++++) (++++++++) |
|( SNC ) LC ( SNC ) |
(o)--------(o)----------(o)--------(o)|
TCP( )| CP CP |( )TCP
(++++++++) | | (++++++++)
| |
| Trail |
|<-------->|
| |
--- ---
\ / \ /
- -
AP 0 0 AP
| |
(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推奨M.3100 [M.3100]に記載されている一連の管理オブジェクトで表されます。接続終端ポイント（CTP）とトレイル終端ポイント（TTP）は、それぞれ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は、自動化された光ネットワーク（ASON）の制御プレーンの参照アーキテクチャを導入します。G.8080は、ASONコントロールプレーンに関連する一連の基準点と、輸送プレーンの対応するポイントとの関係を導入します。サブネットワークポイント（SNP）は、実際のまたは潜在的なCPまたは実際のTCPまたは潜在的なTCPを表す抽象化です。ルーティングの目的でグループ化されたSNPのセットは、SNPプール（SNPP）と呼ばれます。LCおよびSNCと同様に、SNP-SNP関係は静的で柔軟性のない場合があります（これはSNPリンク接続と呼ばれます）、または動的で柔軟な場合（これはSNPサブネットワーク接続と呼ばれます）。
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で、ディスカバリーエージェント（DA）、終了および適応パフォーマー（TAP）、およびリンクリソースマネージャー（LRM）の3つのコンポーネントを使用して説明されています。
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から：「この分離により、コントロールプレーン名は輸送プレーン名と完全に分離され、SNP-SNPリンク接続をSNPPに割り当てるために、DASにそれらの輸送名を入力するために使用される方法とは完全に独立しています。リンク、リンク接続が存在するためにはトランスポート名が必要です」。したがって、リンク接続が物理的に接続されていない限り、リンク接続をコントロールプレーンに割り当てることができます。
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-to-CPおよびTCP-to-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は輸送名スペースのみで動作し、終了および適応パフォーマー（TAP）と協力して、そのスペースとコントロールプレーン名の間の分離を提供します。ローカルDAは、それに割り当てられているCPSとTCPのみを認識しています。DAは、輸送面にCP-CPリンク接続を保持して、SNP-SNPリンク接続を後でタップでそれらにバインドできるようにします。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 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）内で完全に行われます。Link Resource Manager（LRM）は、リンク接続のコントロールプレーン名に必要なSNP-SNPバインディング情報を保持しますが、終端適応パフォーマー（TAP）は、コントロールプレーン名（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)
Figure 3: Discovery in the Control and the Transport Planes
図3：制御および輸送機の発見
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仕様に関する重要なポイントは、光学ネットワークの発見メカニズムを指定することですが、必ずしも情報の使用方法ではありません。その後、輸送管理機または輸送制御機が発見された情報を利用することを意図しています。
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は、LMPを含むIPベースのプロトコルのセットであり、光学/輸送ネットワークとそのリソース（つまり、波長、タイムスロットなど）を含む複数のデータプレーンテクノロジーの制御プレーンを提供し、制御プレーンの制限を想定せずに提供します。アーキテクチャ（[RFC3945]を参照）。一方、G.8080は、コントロールプレーンの実装を制限することなく、光/輸送ネットワークのコントロールプレーン参照アーキテクチャを定義します。別々の標準フォーラムで開発されており、異なるスコープを使用して、異なる用語と定義を使用します。
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インターフェイス_IDSおよびデータリンクIDは、コントロールプレーンのハンドルとして実際のCP名とCP対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]にあります。
+----------------+--------------------+-------------------+
| 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 |
+----------------+--------------------+-------------------+
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.
複合識別子は、RFC 4204 [LMP]で定義されています。LMPは、ローカルとリモートのインターフェイスIDのペアによってデータリンクを発見し、それらを識別します。TEリンクは、データリンクまたはコンポーネントTEリンクで構成されています。TEリンクは、ローカルリンクおよびリモートリンクIDのペアによって同様に識別されます。
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シグナリングに制約されたSPFによって使用される情報にLSRを相互接続する特定の物理リソース（およびそのプロパティ）に関する情報をグループ化/マッピングする方法を表す論理的な構成要素です」。
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リンクのコンポーネントは、LSRのペア間の異なるパスに従う場合があります。たとえば、複数のSTS-3Cを含むTEリンクでは、個々のSTS-3CSコンポーネントリンクは、LSR間の同一または異なる物理（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リンクリソースを表します。TEリンクリソースが割り当てられると、実際の容量は、別の論理TEリンク[HIER]でLSP階層（トンネル）TEリンク機能として表される場合があります。
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リンクには、転送隣接（FA）とインターフェイススイッチング機能[RFC3945]の概念も組み込まれています。FAでは、輸送リソースをTEリンクとして表現できます。インターフェイススイッチング機能は、パケットスイッチ対応（PSC）、レイヤー-2スイッチ対応（L2SC）、時間帯マルチプレックス（TDM）、ラムダスイッチ有能（LSC）、ファイバースイッチ対応（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リンクで構成されている場合があります。これは、それ自体がポイントツーポイントコンポーネントリンク[バンドル]の組み合わせで構成されています。TEリンクは、タプル（リンク識別子（32ビット番号）、コンポーネントリンク識別子（32ビット番号）、および一般化ラベル（メディア固有））によって識別されます。
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の発見の側面を理解するための鍵は、LMP手順が輸送面のIPベースのコントロールプレーンの抽象化に固有のものであることです。
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制御プレーン情報の交換に使用される制御チャネルは、管理するリンクとは独立して存在します（つまり、関連するコントロールポイントがLMPパケットを終了すると、制御チャネルが帯域内または帯域外である場合があります）。リンク管理プロトコル[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.
リンク検証は、データリンクの物理的な接続性を検証し、インターフェイスIDのリンクID（CPからSNP）へのマッピングを検証するために使用されます。ローカルとリモートの関連付けは、先験的な知識を使用して、またはリンク検証手順を使用して取得できます。
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]は、（バンド外の）トレースオブジェクトを使用して、異なる輸送および制御プレーンの名前のスペースをサポートします（[LMPテスト]を参照）。LMPトレースオブジェクトにより、トランスポートプレーン名をインターフェイス識別子[LMPテスト]に関連付けることができます。
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 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リンク検証の側面は、G.7714.1発見と同様に見えます。ただし、2つの手順は異なります。G.7714.1は、輸送機層の隣接の発見を提供します。輸送面の2つのエンドポイントの接続性を発見するための一般的な手順を提供します。一方、LMPリンク検証手順は、コントロールプレーン駆動型の手順であり、（1）関連データプレーンのローカルおよびリモートエンドポイントの接続とインターフェイス_IDのいずれかを前提としています（たとえば、管理プレーンまたはGの使用を介して。7714.1）、または（2）TRACEオブジェクトのコンテンツ（推定マッピング）に確認されているデータインターフェイスを関連付けるためのリモートノードのサポート。SONET/SDH輸送ネットワークの場合、LMP検証はSONET/SDHトレーストレース識別子を使用します（[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、ネットワークサービスアクセスプロトコル（NSAP）、またはその他のアドレス形式を持つことができます。一方、LMPはIPベースのコントロールプレーンの使用に基づいており、LMPインターフェイスIDはIPv4、IPv6、または非自称インターフェイスIDを使用します。
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 ASON規則とASONコントロールプレーンの要素とASON管理プレーンの要素の命名を使用して、輸送層CTPまたはTCPSに関して輸送機の発見を指定します。この発見は、構成の集中管理モデルと分散制御プレーンモデルをサポートしています。つまり、発見されたアイテムは、管理プレーンまたはコントロールプレーンに報告できます。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 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およびG.7714、G7714.1は、さまざまな標準組織で定義されています。それらは、さまざまな命名スキームと建築概念から進化しました。G.7714.1は、コントロールプレーンまたは管理プレーンが使用できる輸送機層隣接接続の確認をサポートしていますが、LMPはGMPLS TEリンクを管理するためのコントロールプレーン手順です（GMPLSのコントロールプレーン輸送プレーン接続の表現）。
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は、実装されているデータ通信ネットワークに関連付けられているセキュリティを提供します。
LMP is specified using IP, which provides security mechanisms associated with the IP network on which it is implemented.
LMPは、実装されているIPネットワークに関連付けられたセキュリティメカニズムを提供するIPを使用して指定されます。
[LMP] Lang, J., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[LMP] Lang、J。、「Link Management Protocol（LMP）」、RFC 4204、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テスト] Lang、J。およびD. Papadimitriou、「同期光学ネットワーク（SONET）/同期デジタル階層（SDH）リンク管理プロトコル（LMP）テストメッセージのエンコード」、RFC 4207、2005年10月。
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] Mannie、E。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）アーキテクチャ」、RFC 3945、2004年10月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、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）をサポートするルーティング拡張機能」、RFC 4202、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）階層」、2005年10月、RFC 4206、
[BUNDLE] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[バンドル] Kompella、K.、Rekhter、Y。、およびL. Berger、「MPLS Traffic Engineering（TE）のリンクバンドリング」、RFC 4201、2005年10月。
[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] Bryskin、I。およびA. Farrel、「ITU-Tの自動化された光ネットワーク（ASON）アーキテクチャのコンテキスト内の一般化マルチプロトコルラベルスイッチング（GMPLS）の用語の解釈のための辞書誌」、進行中の作業、1月2006年。
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）機器機能ブロックの特性。
[G.805] ITU-T G.805 (2000), Generic functional architecture of transport networks.
[G.805] ITU-T G.805（2000）、輸送ネットワークの一般的な機能アーキテクチャ。
[G.7714] ITU-T G.7714/Y.1705 (2001), Generalized automatic discovery techniques.
[G.7714] ITU-T G.7714/Y.1705（2001）、一般化された自動発見技術。
[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）のアーキテクチャ。
[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）、国際参照アルファベット。
The authors would like to thank Astrid Lozano, John Drake, Adrian Farrel and Stephen Shew for their valuable comments.
著者は、Astrid Lozano、John Drake、Adrian Farrel、Stephenが貴重なコメントをしてくれたことに感謝したいと思います。
The authors would like to thank ITU-T Study Group 15 Question 14 for their careful review and comments.
著者は、慎重なレビューとコメントについて、ITU-T研究グループ15質問14に感謝したいと思います。
Authors' Addresses
著者のアドレス
Don Fedyk Nortel Networks 600 Technology Park Drive Billerica, MA, 01821
Don Fedyk Nortel Networks 600 Technology Park Drive Billerica、MA、01821
Phone: +1 978 288-3041
EMail: dwfedyk@nortel.com
Osama Aboul-Magd Nortel Networks P.O. Box 3511, Station 'C' Ottawa, Ontario, Canada K1Y-4H7
Osama Aboul-Magd Nortel Networks P.O.ボックス3511、ステーション 'C'オタワ、オンタリオ州カナダK1Y-4H7
Phone: +1 613 763-5827
EMail: osama@nortel.com
Deborah Brungard AT&T Rm. D1-3C22 200 S. Laurel Ave. Middletown, NJ 07748, USA
デボラ・ブランガードAT＆T RM。D1-3C22 200 S.ローレルアベニュー、ミドルタウン、ニュージャージー州07748、米国
EMail: dbrungard@att.com
Jonathan P. Lang Sonos, Inc. 223 E. De La Guerra Santa Barbara, CA 93101
Jonathan P. Lang Sonos、Inc。223 E. de La Guerra Santa Barbara、CA 93101
EMail: jplang@ieee.org
Dimitri Papadimitriou Alcatel Francis Wellesplein, 1 B-2018 Antwerpen, Belgium
Dimitri Papadimitriou Alcatel Francis Wellesplein、1 B-2018 Antwerpen、ベルギー
Phone: +32 3 240-84-91
EMail: dimitri.papadimitriou@alcatel.be
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。