[要約] 要約：RFC 5493は、GMPLSネットワークにおける永続接続とスイッチ接続の変換に関する要件を定義しています。 目的：このRFCの目的は、GMPLSネットワークでの永続接続とスイッチ接続の間の効果的な変換を可能にするための要件を提供することです。
Network Working Group D. Caviglia
Request for Comments: 5493 D. Bramanti
Category: Informational Ericsson
D. Li
Huawei Technologies Co., Ltd.
D. McDysan
Verizon
April 2009
Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network
一般化されたマルチプロトコルラベルスイッチング（GMPLS）ネットワークでの永久接続とスイッチされた接続間の変換の要件
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Abstract
概要
From a carrier perspective, the possibility of turning a permanent connection (PC) into a soft permanent connection (SPC) and vice versa, without actually affecting data plane traffic being carried over it, is a valuable option. In other terms, such operation can be seen as a way of transferring the ownership and control of an existing and in-use data plane connection between the management plane and the control plane, leaving its data plane state untouched.
キャリアの観点から見ると、永続的な接続（PC）をソフトパーマネント接続（SPC）に変える可能性は、実際にデータプレーンのトラフィックに影響を与えることなく、その逆になりますが、貴重な選択肢です。言い換えれば、そのような操作は、管理プレーンとコントロールプレーンの間の既存および使用中のデータプレーン接続の所有権と制御を転送する方法と見なすことができ、データプレーンの状態を触れられません。
This memo sets out the requirements for such procedures within a Generalized Multiprotocol Label Switching (GMPLS) network.
このメモは、一般化されたマルチプロトコルラベルスイッチング（GMPLS）ネットワーク内のそのような手順の要件を定めています。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Label Switched Path Terminology .................................3
3. LSP within GMPLS Control Plane ..................................4
3.1. Resource Ownership .........................................4
3.2. Setting Up a GMPLS-Controlled Network ......................5
4. Typical Use Cases ...............................................6
4.1. PC-to-SC/SPC Conversion ....................................6
4.2. SC-to-PC Conversion ........................................6
5. Requirements ....................................................7
5.1. Data Plane LSP Consistency .................................7
5.2. No Disruption of User Traffic ..............................7
5.3. Transfer from Management Plane to Control Plane ............7
5.4. Transfer from Control Plane to Management Plane ............7
5.5. Synchronization of State among Nodes during Conversion .....7
5.6. Support of Soft Permanent Connections ......................8
5.7. Failure of Transfer ........................................8
6. Security Considerations .........................................8
7. Contributors ....................................................9
8. Acknowledgments .................................................9
9. References ......................................................9
9.1. Normative References .......................................9
9.2. Informational References ..................................10
In a typical, traditional transport network scenario, data plane connections between two end-points are controlled by means of a Network Management System (NMS) operating within the management plane (MP). The NMS/MP is the owner of such transport connections, being responsible of their setup, teardown, and maintenance. Provisioned connections of this type, initiated and managed by the management plane, are known as permanent connections (PCs) [G.8081].
典型的な従来の輸送ネットワークシナリオでは、2つのエンドポイント間のデータプレーン接続は、管理プレーン（MP）内で動作するネットワーク管理システム（NMS）によって制御されます。NMS/MPは、そのような輸送接続の所有者であり、セットアップ、断取り候、、メンテナンスを担当しています。管理プレーンによって開始および管理されたこのタイプのプロビジョニングされた接続は、永久接続（PC）[G.8081]として知られています。
When the setup, teardown, and maintenance of connections are achieved by means of a signaling protocol owned by the control plane (CP), such connections are known as switched connections (SCs) [G.8081].
コントロールプレーン（CP）が所有するシグナル伝達プロトコルによって接続のセットアップ、分解、およびメンテナンスが達成されると、そのような接続はスイッチ付き接続（SCS）[G.8081]として知られています。
In many deployments, a hybrid connection type will be used. A soft permanent connection (SPC) is a combination of a permanent connection segment at the source-user-to-network side, a permanent connection segment at the destination-user-to-network side, and a switched connection segment within the core network. The permanent parts of the SPC are owned by the management plane, and the switched parts are owned by the control plane [G.8081].
多くの展開では、ハイブリッド接続タイプが使用されます。ソフトパーマネント接続（SPC）は、Source-User-to-Network側の永久接続セグメント、宛先ユーザーからネットワークへの永続的な接続セグメント、およびコアネットワーク内のスイッチ付き接続セグメントの組み合わせです。。SPCの永続的な部分は管理プレーンが所有しており、切り替えされた部品はコントロールプレーン[G.8081]が所有しています。
Note, some aspects of a control-plane-initiated connection must be capable of being queried/controlled by the management plane. These aspects should be independent of how the connection was established.
注意してください。コントロール面で開始された接続のいくつかの側面は、管理プレーンが照会/制御できる必要があります。これらの側面は、接続の確立方法とは独立している必要があります。
Although this requirements document is an informational document, not a protocol specification, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] for clarity of requirement specification.
この要件ドキュメントは情報ドキュメントであり、プロトコル仕様ではありませんが、キーワードは「必須」、「必須」、「必須」、「shall」、「subly」、「not "、" not "、"を推奨してはいけません。このドキュメントの「、「5月」、および「オプション」は、要件仕様の明確さのためにRFC 2119 [RFC2119]に記載されているように解釈されます。
A Label Switched Path (LSP) has different semantics depending on the plane in which the term is used.
ラベルスイッチ付きパス（LSP）には、用語が使用される平面に応じて異なるセマンティクスがあります。
In the data plane, an LSP indicates the data plane forwarding path. It defines the forwarding or switching operations at each network entity. It is the sequence of data plane resources (links, labels, cross-connects) that achieves end-to-end data transport.
データプレーンでは、LSPはデータプレーン転送パスを示します。各ネットワークエンティティでの転送または切り替え操作を定義します。エンドツーエンドのデータ輸送を実現するのは、データプレーンリソース（リンク、ラベル、クロスコネクト）のシーケンスです。
In the management plane, an LSP is the management plane state information (such as the connection attributes and path information) associated with and necessary for the creation and maintenance of a data plane connection.
管理プレーンでは、LSPは、データプレーン接続の作成とメンテナンスに関連付けられ、必要な管理プレーンの状態情報（接続属性やパス情報など）です。
In the control plane, an LSP is the control plane state information (such as the RSVP-TE [RFC3473] Path and Resv state) associated with and necessary for the creation and maintenance of a data plane connection.
コントロールプレーンでは、LSPは、データプレーン接続の作成とメンテナンスに関連付けられ、必要なのは、コントロールプレーンの状態情報（RSVP-TE [RFC3473]パスおよびRESV状態など）です。
A permanent connection has an LSP presence in the data plane and the management plane. A switched connection has an LSP presence in the data plane and the control plane. An SPC has an LSP presence in the data plane for its entire length, but has a management plane presence for part of its length and a control plane presence for part of its length.
永続的な接続は、データプレーンと管理プレーンにLSPが存在します。スイッチされた接続は、データプレーンとコントロールプレーンにLSPの存在感を持っています。SPCは、全長のデータプレーンにLSPの存在感がありますが、その長さの一部には管理プレーンの存在があり、長さの一部にはコントロールプレーンの存在があります。
In this document, when we discuss the LSP conversion between management plane and control plane, we mainly focus on the conversion of control plane state information and management plane state information.
このドキュメントでは、管理プレーンとコントロールプレーン間のLSP変換について説明するとき、主にコントロールプレーンの状態情報と管理プレーンの状態情報の変換に焦点を当てます。
GMPLS ([RFC3471], [RFC3473], and [RFC3945]) defines a control plane architecture for transport networks. This includes both routing and signaling protocols for the creation and maintenance of LSPs in networks whose data plane is based on different technologies, such as Time Division Multiplexing (SDH/SONET, G.709 at ODUk level) and Wavelength Division Multiplexing (G.709 at OCh level).
GMPLS（[RFC3471]、[RFC3473]、および[RFC3945]）は、輸送ネットワークのコントロールプレーンアーキテクチャを定義します。これには、データプレーンがタイムディビジョンマルチプレックス（SDH/SONET、ODUKレベルでG.709）や波長分割多重化などのさまざまなテクノロジーに基づいているネットワークでのLSPの作成とメンテナンスのためのルーティングとシグナリングプロトコルの両方が含まれます（G.709OCHレベルで）。
A resource used by an LSP is said to be 'owned' by the plane that was used to set up the LSP through that part of the network. Thus, all the resources used by a permanent connection are owned by the management plane, and all the resources used by a switched connection are owned by the control plane. The resources used by an SPC are divided between the management plane (for the resources used by the permanent connection segments at the edge of the network) and the control plane (for the resources used by the switched connection segments in the middle of the network).
LSPが使用するリソースは、ネットワークのその部分を介してLSPをセットアップするために使用された平面によって「所有」されると言われています。したがって、永続的な接続で使用されるすべてのリソースは管理プレーンが所有しており、スイッチ接続で使用されるすべてのリソースはコントロールプレーンが所有しています。SPCが使用するリソースは、管理プレーン（ネットワークの端にある永続的な接続セグメントで使用されるリソース）とコントロールプレーン（ネットワークの中央のスイッチ付き接続セグメントで使用されるリソース）の間で分割されます。。
The division of resources available for ownership by the management and control planes is an architectural issue. A carrier may decide to pre-partition the resources at a network entity so that LSPs under management plane control use one set of resources and LSPs under control plane control use another set of resources. Other carriers may choose to make this distinction resource-by-resource as LSPs are established.
管理および制御機が所有権に利用できるリソースの分割は、建築上の問題です。キャリアは、ネットワークエンティティのリソースを事前に分割することを決定し、管理機の管理下でLSPが1つのリソースを使用し、制御プレーン制御下のLSPを使用して別のリソースセットを使用します。他のキャリアは、LSPが確立されているため、この区別をリソースごとに選択することを選択できます。
It should be noted, however, that even when a resource is owned by the control plane it will usually be the case that the management plane has a controlling interest in the resource. For example, consider the basic safety requirements that management commands must be able to put a laser out of service.
ただし、リソースがコントロールプレーンが所有している場合でも、管理プレーンがリソースに制御する関心がある場合があることに注意する必要があります。たとえば、管理コマンドがレーザーを使用してはならない基本的な安全要件を検討してください。
The implementation of a new network using a Generalized Multiprotocol Label Switching (GMPLS) control plane may be considered as a green field deployment. But in many cases, it is desirable to introduce a GMPLS control plane into an existing transport network that is already populated with permanent connections under management plane control.
一般化されたマルチプロトコルラベルスイッチング（GMPLS）制御プレーンを使用した新しいネットワークの実装は、グリーンフィールドの展開と見なされる場合があります。しかし、多くの場合、GMPLSコントロールプレーンを、管理プレーンの制御下で恒久的な接続がすでに入力されている既存の輸送ネットワークに導入することが望ましいです。
In a mixed scenario, permanent connections owned by the management plane and switched connections owned by the control plane have to coexist within the network.
混合シナリオでは、管理プレーンが所有し、制御プレーンが所有する接続を切り替えた永続的な接続は、ネットワーク内で共存する必要があります。
It is also desirable to transfer the control of connections from the management plane to the control plane so that connections that were originally under the control of an NMS are now under the control of the GMPLS protocols. In case such connections are in service, such conversion must be performed in a way that does not affect traffic.
また、NMSの制御下にある接続がGMPLSプロトコルの制御下にあるように、接続の制御を管理プレーンから制御プレーンに転送することも望ましいです。そのような接続が使用されている場合、そのような変換はトラフィックに影響を与えない方法で実行する必要があります。
Since attempts to move an LSP under GMPLS control might fail due to a number of reasons outside the scope of this document, it is also highly desirable to have a mechanism to convert the control of an LSP back to the management plane.
GMPLS制御の下でLSPを移動しようとすると、このドキュメントの範囲外のいくつかの理由により失敗する可能性があるため、LSPの制御を管理プレーンに変換するメカニズムがあることも非常に望ましいです。
Note that a permanent connection may be converted to a switched connection or to an SPC, and an SPC may be converted to a switched connection as well (PC to SC, PC to SPC, and SPC to SC). So the reverse mappings may also be needed (SC to PC, SPC to PC, and SC to SPC).
永続的な接続は、スイッチ接続またはSPCに変換され、SPCがスイッチ接続にも変換される場合があることに注意してください（PCからSC、PCからSPC、SPCからSC）。したがって、逆マッピングも必要になる場合があります（SCからPC、SPCからPC、SCからSPC）。
Conversion to/from control/management will occur in MIBs or in information stored on the device (e.g., cross-connect, label assignment, label stacking, etc.) and is identified as either initiated by a specific control protocol or by manual operation (i.e., via an NMS). When converting, this hop-level owner information needs to be completed for all hops. If conversion cannot be done for all hops, then the conversion must be done for no hops, the state of the hop-level information must be restored to that before the conversion was attempted, and an error condition must be reported to the management system.
制御/管理からの変換は、MIBSまたはデバイスに保存されている情報（例：クロスコネクト、ラベル割り当て、ラベルスタッキングなど）で発生し、特定のコントロールプロトコルまたは手動操作によって開始される（つまり、NMSを介して）。変換するとき、このホップレベルの所有者情報は、すべてのホップに対して完了する必要があります。すべてのホップに対して変換を行うことができない場合、ホップなしで変換を行う必要があり、コンバージョンが試行される前にホップレベルの情報の状態を復元する必要があり、エラー条件を管理システムに報告する必要があります。
In either case of conversion, the management plane shall initiate the change. When converting from a PC to an SC, the management system must indicate to each hop that a control protocol is now to be used, and then configure the data needed by the control protocol at the connection endpoints. When converting from an SC to a PC, the management plane must change the owner of each hop. Then the instance in the control plane must be removed without affecting the data plane.
どちらの場合でも変換の場合、管理面は変更を開始するものとします。PCからSCに変換する場合、管理システムは、コントロールプロトコルが使用されることを各ホップに示す必要があり、接続エンドポイントでコントロールプロトコルで必要なデータを構成する必要があります。SCからPCに変換する場合、管理プレーンは各ホップの所有者を変更する必要があります。次に、データプレーンに影響を与えることなく、コントロールプレーンのインスタンスを取り外す必要があります。
The case where the CP and/or MP fail at one or more nodes during the conversion procedure must be handled in the solution. If the network is viewed as the database of record (including data, control, and management plane elements), then a solution that has procedures similar to those of a two-phase database commit process may be needed to ensure integrity and to support the need to revert to the state prior to the conversion attempt if there is a CP and/or MP failure during the attempted conversion.
CPおよび/またはMPが変換手順中に1つまたは複数のノードで障害がある場合は、ソリューションで処理する必要があります。ネットワークがレコードのデータベース（データ、コントロール、および管理プレーン要素を含む）と見なされている場合、整合性を確保し、必要性をサポートするために、2フェーズデータベースのコミットプロセスと同様の手順を持つソリューションが必要になる場合があります。コンバージョンの試行中にCPおよび/またはMPの障害がある場合、変換の試みの前に状態に戻ります。
A typical scenario where a PC-to-SC (or SPC) procedure can be a useful option is at the initial stage of control plane deployment in an existing network. In such a case, all the network connections, possibly carrying traffic, are already set up as PCs and are owned by the management plane.
PCからSC（またはSPC）手順が有用なオプションになる可能性のある典型的なシナリオは、既存のネットワークでのコントロールプレーンの展開の初期段階にあります。このような場合、トラフィックを担当する可能性のあるすべてのネットワーク接続は、すでにPCとして設定されており、管理プレーンが所有しています。
At a latter stage, when the network is partially controlled by the management plane and partially controlled by the control plane (PCs and SCs/SPCs coexist) and it is desired to extend the control plane, a PC-to-SC procedure can be used to transfer a PC or SPC to a SC.
後半の段階では、ネットワークが管理プレーンによって部分的に制御され、制御プレーン（PCSおよびSCS/SPCが共存）によって部分的に制御され、制御プレーンを拡張することが望まれる場合、PC-to-SC手順を使用できます。PCまたはSPCをSCに転送します。
In both cases, a connection, set up and owned by the management plane, needs to be transferred to control plane control. If a connection is carrying traffic, its control transfer has to be done without any disruption to the data plane traffic.
どちらの場合も、管理プレーンがセットアップして所有する接続を制御プレーン制御に転送する必要があります。接続がトラフィックを運んでいる場合、データプレーントラフィックを混乱させることなく、制御転送を実行する必要があります。
The main need for an SC-to-PC conversion is to give an operator the capability of undoing the action of the above introduced PC-to-SC conversion.
SC-To-PC変換の主なニーズは、上記のPCからSCへの変換のアクションを元に戻す機能をオペレーターに提供することです。
In other words, the SC-to-PC conversion is a back-out procedure and as such is not specified as mandatory in this document, but it is still a highly desirable function.
言い換えれば、SC-to-PC変換はバックアウト手順であり、このドキュメントでは必須として指定されていませんが、それでも非常に望ましい機能です。
Again, it is worth stressing the requirement that such an SPC-to-PC conversion needs to be achieved without any effect on the associated data plane state so that the connection continues to be operational and to carry traffic during the transition.
繰り返しますが、関連するデータプレーン状態に影響を与えずにSPCからPCへの変換を達成する必要があることを強調する価値があり、接続が引き続き動作し、移行中にトラフィックを運ぶことができます。
This section sets out the basic requirements for procedures and processes that are used to perform the functions of this document. Notation from [RFC2119] is used to clarify the level of each requirement.
このセクションでは、このドキュメントの機能を実行するために使用される手順とプロセスの基本的な要件を説明します。[RFC2119]からの表記は、各要件のレベルを明確にするために使用されます。
The data plane LSP MUST stay in place throughout the whole control transfer process. It MUST follow the same path through the network and MUST use the same network resources.
データプレーンLSPは、制御転送プロセス全体を通して所定の位置にとどまる必要があります。ネットワークを介して同じパスをたどる必要があり、同じネットワークリソースを使用する必要があります。
The transfer process MUST NOT cause any disruption of user traffic flowing over the LSP whose control is being transferred or over any other LSP in the network.
転送プロセスは、コントロールが転送されているLSPまたはネットワーク内の他のLSPに流れるユーザートラフィックの混乱を引き起こしてはなりません。
SC-to-PC conversion and vice-versa SHALL occur without generating alarms towards the end users or the NMS.
SC-To-PCの変換とその逆も、エンドユーザーやNMSにアラームを生成せずに発生するものとします。
It MUST be possible to transfer the ownership of an LSP from the management plane to the control plane.
LSPの所有権を管理プレーンからコントロールプレーンに転送することが可能でなければなりません。
It SHOULD be possible to transfer the ownership of an LSP from the control plane to the management plane.
LSPの所有権をコントロールプレーンから管理プレーンに移すことができるはずです。
It MUST be assured that the state of the LSP is synchronized among all nodes traversed by it before the conversion is considered complete.
LSPの状態は、変換が完了すると見なされる前に、LSPの状態がそれによって移動されたすべてのノード間で同期されることを保証する必要があります。
It MUST be possible to segment an LSP such that it can be converted to or from an SPC.
LSPをSPCとの間で、またはSPCから変換できるようにセグメント化することは可能でなければなりません。
It MUST be possible for a transfer from one plane to the other to fail in a non-destructive way, leaving the ownership unchanged and without impacting traffic.
1つの飛行機から他の飛行機への移転が非破壊的な方法で故障し、所有権を変化させず、トラフィックに影響を与えないようにすることが可能でなければなりません。
If during the transfer procedure issues arise causing an unsuccessful or unexpected result, it MUST be assured that:
転送手順中に問題が発生して失敗したか予期しない結果が発生した場合、次のことを保証する必要があります。
1. Traffic over the data plane is not affected.
1. データプレーン上のトラフィックは影響を受けません。
2. The LSP status is consistent in all the network nodes involved in the procedure.
2. LSPステータスは、手順に関与するすべてのネットワークノードで一貫しています。
Point 2, above, assures that even in case of some failure during the transfer, the state of the affected LSP is brought back to the initial one and is fully under the control of the owning entity.
上記のポイント2は、転送中に何らかの失敗の場合でも、影響を受けるLSPの状態が最初のLSPに戻され、所有エンティティの管理下にあることを保証します。
Allowing control of an LSP to be taken away from a plane introduces a possible way in which services may be disrupted by malicious intervention.
LSPの制御を飛行機から奪うことを可能にすると、悪意のある介入によってサービスが中断される可能性のある方法が導入されます。
A solution to the requirements in this document will utilize the security mechanisms supported by the management plane and GMPLS control plane protocols, and no new security requirements over the general requirements described in [RFC3945] are introduced. It is expected that solution documents will include an analysis of the security issues introduced by any new protocol extensions.
このドキュメントの要件の解決策は、管理プレーンとGMPLSコントロールプレーンのプロトコルによってサポートされるセキュリティメカニズムを利用し、[RFC3945]に記載されている一般的な要件に関する新しいセキュリティ要件は導入されません。ソリューションドキュメントには、新しいプロトコル拡張によって導入されたセキュリティ問題の分析が含まれることが期待されています。
The management plane interactions MUST be supported through protocols that can offer adequate security mechanisms to secure the configuration and protect the operation of the devices that are managed. These mechanisms MUST include at least cryptographic security and the ability to ensure that the entity giving access to configuration parameters is properly configured to give access only to those principals (users) that have legitimate rights to read/create/change/delete the parameters. IETF standard management protocols (Netconf [RFC4741] and SNMPv3 [RFC3410]) offer these mechanisms.
管理プレーンの相互作用は、構成を保護し、管理されているデバイスの動作を保護するための適切なセキュリティメカニズムを提供できるプロトコルを通じてサポートする必要があります。これらのメカニズムには、少なくとも暗号化のセキュリティと、構成パラメーターへのアクセスを提供するエンティティが、パラメーターを読み取り/作成/削除する正当な権利を持つプリンシパル（ユーザー）のみにアクセスできるように適切に構成されるようにする能力を含める必要があります。IETF標準管理プロトコル（NetConf [RFC4741]およびSNMPV3 [RFC3410]）は、これらのメカニズムを提供します。
Note also that implementations may support policy components to determine whether individual LSPs may be transferred between planes.
また、実装はポリシーコンポーネントをサポートして、個々のLSPが飛行機間で転送されるかどうかを判断する場合があることに注意してください。
Nicola Ciulli NextWorks Corso Italia 116 56125 Pisa, Italy EMail: n.ciulli@nextworks.it
Nicola Ciulli NextWorks Corso Italia 116 56125 Pisa、Italyメール：n.ciulli@nextworks.it
Han Li China Mobile Communications Co. 53 A Xibianmennei Ave. Xuanwu District Deijing 100053 P.R. China Phone: 10-66006688 ext.3092 EMail: lihan@chinamobile.com
Han Li China Mobile Communications Co. 53 A Xibianmennei Ave. Xuanwu District Deijing 100053 P.R. China電話：10-66006688 ext.3092メール：lihan@chinamobile.com
Daniele Ceccarelli Ericsson Via A. Negrone 1/A Genova-Sestri Ponente, Italy Phone: +390106002515 EMail: daniele.ceccarelli@ericsson.com
Daniele ceccarelli Ericsson、A。Negrone1/A Genova-Sestri Ponente、イタリア電話：390106002515メール：daniele.ceccarelli@ericsson.com
We wish to thank the following people (listed randomly): Adrian Farrel for his editorial assistance to prepare this document for publication; Dean Cheng, Julien Meuric, Dimitri Papadimitriou, Deborah Brungard, Igor Bryskin, Lou Berger, Don Fedyk, John Drake, and Vijay Pandian for their suggestions and comments on the CCAMP list.
次の人々に感謝したいと思います（ランダムにリストされています）：Adrian Farrelは、この文書を公開するための編集支援を行ってくれました。ディーン・チェン、ジュリエン・ムリック、ディミトリ・パパジミトリウ、デボラ・ブルガード、イゴール・ブリスキン、ルー・バーガー、ドン・フェディック、ジョン・ドレイク、ヴィジェイ・パンディアンのCCAMPリストに関する提案とコメント。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,"Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410] Case、J.、Mundy、R.、Partain、D。、およびB. Stewart、「インターネット標準管理フレームワークの紹介と適用声明」、RFC 3410、2002年12月。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、2003年1月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] Mannie、E.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）アーキテクチャ」、RFC 3945、2004年10月。
[RFC4741] Enns, R., Ed., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[RFC4741] Enns、R.、ed。、「NetConf Configuration Protocol」、RFC 4741、2006年12月。
[G.8081] International Telecommunications Union, "Terms and definitions for Automatically Switched Optical Networks (ASON)", Recommendation G.8081/Y.1353, June 2004.
[G.8081] International Telecommunications Union、「自動化された光ネットワーク（ASON）の用語と定義」、推奨G.8081/Y.1353、2004年6月。
Authors' Addresses
著者のアドレス
Diego Caviglia Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy
Diego Caviglia Ericssonを介してA.ネグロン1/A Genova -Sestri Ponente Italy
EMail: diego.caviglia@ericsson.com
Dino Bramanti Ericsson Via Moruzzi 1 C/O Area Ricerca CNR Pisa Italy
モルッツィ経由のディノ・ブラマンティ・エリクソン1 c/o地域ricerca cnr pisa italy
EMail: dino.bramanti@ericsson.com
Dan Li Huawei Technologies Co., Ltd. Shenzhen 518129 Huawei Base, Bantian, Longgang China
Dan Li Huawei Technologies Co.、Ltd。Shenzhen 518129 Huawei Base、Bantian、Longgang China
EMail: danli@huawei.com
Dave McDysan Verizon Ashburn, VA USA
Dave McDysan Verizon Ashburn、VA USA
EMail: dave.mcdysan@verizon.com