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
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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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.
キャリアの観点から、ソフト永続的な接続（SPC）とその逆に常時接続（PC）を回しの可能性が、実際にそれを介して実行されているデータプレーントラフィックに影響を与えずに、貴重なオプションです。他の面では、このような動作は、データプレーンの状態はそのまま残し、管理プレーンと制御プレーンとの間の既存の使用中のデータプレーン接続の所有権及び制御を転送する方法として見ることができます。
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は、彼らのセットアップ、ティアダウン、および保守の責任であること、など交通機関の接続の所有者です。管理プレーンによって開始され、管理され、このタイプのプロビジョニングされた接続は、永久的な接続（PCS）としても知られている[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）は、ソースユーザツーネットワーク側の永久接続セグメント、宛先ユーザツーネットワーク側の永久接続セグメント、及びコアネットワーク内の交換結合セグメントの組み合わせであります。 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.
この要件ドキュメントは、情報提供文書ではなく、プロトコル仕様、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHALL NOT"、 "SHOULD"、 "SHOULD NOT"、「推奨されますが、 」、 『この文書5月』、及び 『OPTIONAL』は、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、G.709のODUkレベル）と波長分割多重のような異なる技術に基づくネットワークにおけるLSPの作成および保守のためのシグナリングプロトコル（G.709の両方を含みますOChレベルで）。
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リソースと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は（SCにSC、SPCにPC、およびSPCにPC）も交換接続に変換することができることに留意されたいです。だから、逆マッピングも（PC、PCにSPC、およびSPCへのSCにSC）必要な場合があります。
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.
/制御/管理のMIBまたは情報に発生するから変換デバイス（例えば、クロスコネクト、ラベル割り当て、ラベルスタック）に保存され、特定の制御プロトコルによって、または手動操作（によって開始のいずれかとして識別されますすなわち、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.
変換のいずれの場合においても、管理プレーンは、変更を開始しなければなりません。 SCにPCから変換するとき、管理システムは、制御プロトコルは、現在使用される各ホップに示し、次に接続エンドポイントの制御プロトコルが必要とするデータを設定する必要があります。 PCにSCから変換するとき、管理プレーンは、各ホップの所有者を変更しなければなりません。そして、制御プレーン内のインスタンスは、データプレーンに影響を与えずに削除する必要があります。
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）手順が便利なオプションとすることができる典型的なシナリオは、既存のネットワークにおける制御プレーン展開の初期段階にあります。そのような場合には、すべてのネットワーク接続は、おそらくトラフィックを運ぶ、すでにパソコンとして設定されており、管理プレーンによって所有されています。
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.
ネットワークの一部が管理プレーンによって制御され、部分的に、制御プレーン（PCとのSC / SPCの共存）によって制御され、後者の段階で、制御プレーンを拡張することが望まれる、PC対SCの手順を使用することができますSCにPCやSPCを転送します。
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-へ-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から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-へ-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の状態は、それが通過するすべてのノード間で同期されることを保証しなければなりません。
It MUST be possible to segment an LSP such that it can be converted to or from an SPC.
それはまたはSPCから変換することができるように、LSPセグメントできなければなりません。
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:
転送手順の間に問題が失敗したり、予期しない結果を引き起こして発生した場合、それはそれを保証しなければなりません：
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の状態は最初のものに戻され、所有エンティティの制御下に十分であることを保証します。
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
ニコラスCiulla Nextworksコースイタリア116 56125ピサ、イタリアEメール：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
ハンリーチャイナモバイルコミュニケーションズ株式会社は53 A Xibianmenneiアベニュー。宣武地区Deijing 100053中華人民共和国電話：10から66006688 ext.3092 Eメール：lihan@chinamobile.com
Daniele Ceccarelli Ericsson Via A. Negrone 1/A Genova-Sestri Ponente, Italy Phone: +390106002515 EMail: daniele.ceccarelli@ericsson.com
ダニエルCeccarelliエリクソンA. Negrone 1 /ジェノバ・セストリポネンテ、イタリア電話：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.
私たちは次の方々に感謝したい（上場をランダム）：エードリアンファレル出版のため、この文書を準備する彼の編集支援のため、ディーン・チェン、ジュリアンMeuric、ディミトリPapadimitriou、デボラBrungard、イゴールBryskin、ルー・バーガー、ドンFedyk、ジョン・ドレイク、およびビジェイPandian CCAMPリスト上の彼らの提案やコメントについて。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ケース、J.、マンディ、R.、パーテイン、D.、およびB.スチュワート、 "インターネット標準の管理フレームワークのための序論と適用性声明"、RFC 3410、2002年12月。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]バーガー、L.、エド。は、 "一般化マルチプロトコルラベルスイッチング（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]バーガー、L.、エド。、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を拡張"、RFC 3473、2003年1月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]マニー、E.、エド。、 "一般化マルチプロトコルラベルスイッチング（GMPLS）アーキテクチャ"、RFC 3945、2004年10月。
[RFC4741] Enns, R., Ed., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[RFC4741]エンス、R.、エド。、 "NETCONF構成プロトコル"、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]国際電気通信連合、勧告G.8081 / Y.1353、2004年6月 "自動的に交換光ネットワーク（ASON）のための用語及び定義"。
Authors' Addresses
著者のアドレス
Diego Caviglia Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy
ディエゴ・トレス・エリクソンNegrone A. 1 / Aジェノア - セストリポネンテイタリア
EMail: diego.caviglia@ericsson.com
メールアドレス：diego.caviglia@ericsson.com
Dino Bramanti Ericsson Via Moruzzi 1 C/O Area Ricerca CNR Pisa Italy
ディノBramantiエリクソン経由Moruzzi 1つのC / OエリアCNRピサイタリア
EMail: dino.bramanti@ericsson.com
メールアドレス：dino.bramanti@ericsson.com
Dan Li Huawei Technologies Co., Ltd. Shenzhen 518129 Huawei Base, Bantian, Longgang China
ダンリットルIH UAは、技術の共同で、株式会社S 518129 HU Aは、ベースにも当てはまり、長いだけで、中国を日を禁止
EMail: danli@huawei.com
メールアドレス：danli@huawei.com
Dave McDysan Verizon Ashburn, VA USA
デイブMcDysanベライゾンアッシュバーン、VA USA
EMail: dave.mcdysan@verizon.com
メールアドレス：dave.mcdysan@verizon.com