[要約] RFC 6373は、MPLS-TP制御プレーンフレームワークに関するものであり、MPLS-TPネットワークの制御プレーンの設計と動作に関するガイドラインを提供しています。その目的は、MPLS-TPネットワークの制御プレーンの標準化と相互運用性の向上です。
Internet Engineering Task Force (IETF) L. Andersson, Ed.
Request for Comments: 6373 Ericsson
Category: Informational L. Berger, Ed.
ISSN: 2070-1721 LabN
L. Fang, Ed.
Cisco
N. Bitar, Ed.
Verizon
E. Gray, Ed.
Ericsson
September 2011
MPLS Transport Profile (MPLS-TP) Control Plane Framework
MPLS輸送プロファイル（MPLS-TP）制御プレーンフレームワーク
Abstract
概要
The MPLS Transport Profile (MPLS-TP) supports static provisioning of transport paths via a Network Management System (NMS) and dynamic provisioning of transport paths via a control plane. This document provides the framework for MPLS-TP dynamic provisioning and covers control-plane addressing, routing, path computation, signaling, traffic engineering, and path recovery. MPLS-TP uses GMPLS as the control plane for MPLS-TP Label Switched Paths (LSPs). MPLS-TP also uses the pseudowire (PW) control plane for pseudowires. Management-plane functions are out of scope of this document.
MPLSトランスポートプロファイル（MPLS-TP）は、ネットワーク管理システム（NMS）を介した輸送パスの静的プロビジョニングと、制御プレーンを介した輸送パスの動的プロビジョニングをサポートしています。このドキュメントは、MPLS-TP動的プロビジョニングのフレームワークを提供し、コントロールプレーンアドレス指定、ルーティング、パス計算、シグナル、トラフィックエンジニアリング、パスリカバリをカバーします。MPLS-TPは、GMPLSをMPLS-TPラベルスイッチ付きパス（LSP）のコントロールプレーンとして使用します。MPLS-TPは、擬似ワイヤに擬似具体（PW）制御プレーンも使用しています。管理面関数は、このドキュメントの範囲外です。
This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.
このドキュメントは、IETF MPLSおよびPSEUDOWIREエミュレーションエッジ（PWE3）アーキテクチャ内にMPLS輸送プロファイルを含めるための共同インターネットエンジニアリングタスクフォース（IETF） /国際電気通信連合電気通信標準化セクター（ITU-T）の製品です。ITU-Tで定義されているパケット輸送ネットワークの機能と機能をサポートする。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6373.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6373で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Scope ......................................................4
1.2. Basic Approach .............................................4
1.3. Reference Model ............................................6
2. Control-Plane Requirements ......................................9
2.1. Primary Requirements .......................................9
2.2. Requirements Derived from the MPLS-TP Framework ...........18
2.3. Requirements Derived from the OAM Framework ...............20
2.4. Security Requirements .....................................25
2.5. Identifier Requirements ...................................25
3. Relationship of PWs and TE LSPs ................................26
4. TE LSPs ........................................................27
4.1. GMPLS Functions and MPLS-TP LSPs ..........................27
4.1.1. In-Band and Out-of-Band Control ....................27
4.1.2. Addressing .........................................29
4.1.3. Routing ............................................29
4.1.4. TE LSPs and Constraint-Based Path Computation ......29
4.1.5. Signaling ..........................................30
4.1.6. Unnumbered Links ...................................30
4.1.7. Link Bundling ......................................30
4.1.8. Hierarchical LSPs ..................................31
4.1.9. LSP Recovery .......................................31
4.1.10. Control-Plane Reference Points (E-NNI,
I-NNI, UNI) .......................................32
4.2. OAM, MEP (Hierarchy), MIP Configuration and Control .......32
4.2.1. Management-Plane Support ...........................33
4.3. GMPLS and MPLS-TP Requirements Table ......................34
4.4. Anticipated MPLS-TP-Related Extensions and Definitions ....37
4.4.1. MPLS-TE to MPLS-TP LSP Control-Plane Interworking ..37
4.4.2. Associated Bidirectional LSPs ......................38
4.4.3. Asymmetric Bandwidth LSPs ..........................38
4.4.4. Recovery for P2MP LSPs .............................38
4.4.5. Test Traffic Control and Other OAM Functions .......38
4.4.6. Diffserv Object Usage in GMPLS .....................39
4.4.7. Support for MPLS-TP LSP Identifiers ................39
4.4.8. Support for MPLS-TP Maintenance Identifiers ........39
5. Pseudowires ....................................................39
5.1. LDP Functions and Pseudowires .............................39
5.1.1. Management-Plane Support ...........................40
5.2. PW Control (LDP) and MPLS-TP Requirements Table ...........40
5.3. Anticipated MPLS-TP-Related Extensions ....................44
5.3.1. Extensions to Support Out-of-Band PW Control .......44
5.3.2. Support for Explicit Control of PW-to-LSP Binding ..45
5.3.3. Support for Dynamic Transfer of PW
Control/Ownership ..................................45
5.3.4. Interoperable Support for PW/LSP Resource
Allocation .........................................46
5.3.5. Support for PW Protection and PW OAM
Configuration ......................................46
5.3.6. Client Layer and Cross-Provider Interfaces
to PW Control ......................................47
5.4. ASON Architecture Considerations ..........................47
6. Security Considerations ........................................47
7. Acknowledgments ................................................48
8. References .....................................................48
8.1. Normative References ......................................48
8.2. Informative References ....................................51
9. Contributing Authors ...........................................56
The Multiprotocol Label Switching Transport Profile (MPLS-TP) is defined as a joint effort between the International Telecommunication Union (ITU) and the IETF. The requirements for MPLS-TP are defined in the requirements document, see [RFC5654]. These requirements state that "A solution MUST be defined to support dynamic provisioning of MPLS-TP transport paths via a control plane". This document provides the framework for such dynamic provisioning. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functions of a packet transport network as defined by the ITU-T.
マルチプロトコルラベルスイッチングトランスポートプロファイル（MPLS-TP）は、国際電気通信連合（ITU）とIETFの共同の取り組みとして定義されます。MPLS-TPの要件は要件文書で定義されています。[RFC5654]を参照してください。これらの要件は、「コントロールプレーンを介したMPLS-TP輸送パスの動的プロビジョニングをサポートするために、ソリューションを定義する必要がある」と述べています。このドキュメントは、このような動的プロビジョニングのフレームワークを提供します。このドキュメントは、IETF MPLSおよびPSEUDOWIREエミュレーションエッジ（PWE3）アーキテクチャ内にMPLS輸送プロファイルを含めるための共同インターネットエンジニアリングタスクフォース（IETF） /国際電気通信連合電気通信標準化セクター（ITU-T）の製品です。ITU-Tで定義されているパケット輸送ネットワークの機能と機能をサポートする。
This document covers the control-plane functions involved in establishing MPLS-TP Label Switched Paths (LSPs) and pseudowires (PWs). The control-plane requirements for MPLS-TP are defined in the MPLS-TP requirements document [RFC5654]. These requirements define the role of the control plane in MPLS-TP. In particular, Section 2.4 of [RFC5654] and portions of the remainder of Section 2 of [RFC5654] provide specific control-plane requirements.
このドキュメントは、MPLS-TPラベルスイッチ付きパス（LSP）と擬似動物（PWS）の確立に関与するコントロールプレーン関数をカバーしています。MPLS-TPの制御面要件は、MPLS-TP要件ドキュメント[RFC5654]で定義されています。これらの要件は、MPLS-TPにおけるコントロールプレーンの役割を定義します。特に、[RFC5654]のセクション2.4および[RFC5654]のセクション2の残りの部分は、特定のコントロール面要件を提供します。
The LSPs provided by MPLS-TP are used as a server layer for IP, MPLS, and PWs, as well as other tunneled MPLS-TP LSPs. The PWs are used to carry client signals other than IP or MPLS. The relationship between PWs and MPLS-TP LSPs is exactly the same as between PWs and MPLS LSPs in an MPLS Packet Switched Network (PSN). The PW encapsulation over MPLS-TP LSPs used in MPLS-TP networks is also the same as for PWs over MPLS in an MPLS network. MPLS-TP also defines protection and restoration (or, collectively, recovery) functions; see [RFC5654] and [RFC4427]. The MPLS-TP control plane provides methods to establish, remove, and control MPLS-TP LSPs and PWs. This includes control of Operations, Administration, and Maintenance (OAM), data-plane, and recovery functions.
MPLS-TPによって提供されるLSPは、IP、MPLS、およびPWSのサーバーレイヤーとして使用され、他のトンネルMPLS-TP LSPが使用されます。PWは、IPまたはMPLS以外のクライアント信号を運ぶために使用されます。PWSとMPLS-TP LSPの関係は、MPLSパケットスイッチネットワーク（PSN）のPWSとMPLS LSPの間の関係とまったく同じです。MPLS-TPネットワークで使用されるMPLS-TP LSPを介したPWカプセル化は、MPLSネットワークのMPLS上のPWSの場合と同じです。MPLS-TPは、保護と回復（または総称する）機能も定義しています。[RFC5654]および[RFC4427]を参照してください。MPLS-TPコントロールプレーンは、MPLS-TP LSPおよびPWSを確立、削除、および制御する方法を提供します。これには、運用、管理、メンテナンス（OAM）、データプレーン、および回復機能の制御が含まれます。
A general framework for MPLS-TP has been defined in [RFC5921], and a survivability framework for MPLS-TP has been defined in [RFC6372]. These documents scope the approaches and protocols that are the foundation of MPLS-TP. Notably, Section 3.5 of [RFC5921] scopes the IETF protocols that serve as the foundation of the MPLS-TP control plane. The PW control plane is based on the existing PW control plane (see [RFC4447]) and the PWE3 architecture (see [RFC3985]). The LSP control plane is based on GMPLS (see [RFC3945]), which is built on MPLS Traffic Engineering (TE) and its numerous extensions. [RFC6372] focuses on the recovery functions that must be supported within MPLS-TP. It does not specify which control-plane mechanisms are to be used.
MPLS-TPの一般的なフレームワークは[RFC5921]で定義されており、MPLS-TPの生存可能性フレームワークは[RFC6372]で定義されています。これらのドキュメントは、MPLS-TPの基礎であるアプローチとプロトコルを範囲します。特に、[RFC5921]のセクション3.5は、MPLS-TPコントロールプレーンの基礎として機能するIETFプロトコルを範囲します。PWコントロールプレーンは、既存のPWコントロールプレーン（[RFC447]を参照）およびPWE3アーキテクチャ（[RFC3985]を参照）に基づいています。LSPコントロールプレーンは、GMPLS（[RFC3945]を参照）に基づいており、MPLSトラフィックエンジニアリング（TE）とその多数の拡張に基づいています。[RFC6372]は、MPLS-TP内でサポートする必要がある回復関数に焦点を当てています。使用するコントロールプレーンメカニズムを指定しません。
The remainder of this document discusses the impact of the MPLS-TP requirements on the GMPLS signaling and routing protocols that are used to control MPLS-TP LSPs, and on the control of PWs as specified in [RFC4447], [RFC6073], and [MS-PW-DYNAMIC].
このドキュメントの残りの部分では、MPLS-TP LSPを制御するために使用されるGMPLSシグナリングおよびルーティングプロトコル、および[RFC4447]、[RFC6073]で指定されているPWSの制御に対するMPLS-TP要件の影響について説明します。ms-pw-dynamic]。
The basic approach taken in defining the MPLS-TP control-plane framework includes the following:
MPLS-TPコントロールプレーンフレームワークを定義する際に取られた基本的なアプローチには、以下が含まれます。
1) MPLS technology as defined by the IETF is the foundation for the MPLS Transport Profile.
1) IETFで定義されているMPLSテクノロジーは、MPLS輸送プロファイルの基礎です。
2) The data plane for MPLS-TP is a standard MPLS data plane [RFC3031] as profiled in [RFC5960].
2) MPLS-TPのデータプレーンは、[RFC5960]でプロファイルされているように、標準のMPLSデータプレーン[RFC3031]です。
3) MPLS PWs are used by MPLS-TP including the use of targeted Label Distribution Protocol (LDP) as the foundation for PW signaling [RFC4447]. This also includes the use of Open Shortest Path First with Traffic Engineering (OSPF-TE), Intermediate System to Intermediate System (IS-IS) with Traffic Engineering (ISIS-TE), or Multiprotocol Border Gateway Protocol (MP-BGP) as they apply for Multi-Segment Pseudowire (MS-PW) routing. However, the PW can be encapsulated over an MPLS-TP LSP (established using methods and procedures for MPLS-TP LSP establishment) in addition to the presently defined methods of carrying PWs over LSP-based PSNs. That is, the MPLS-TP domain is a PSN from a PWE3 architecture perspective [RFC3985].
3) MPLS PWは、PWシグナル伝達の基礎としてターゲットラベル分布プロトコル（LDP）の使用を含むMPLS-TPで使用されます[RFC4447]。これには、トラフィックエンジニアリング（OSPF-TE）で最初にオープンな最短パスの使用、トラフィックエンジニアリング（ISIS-TE）を備えた中間システム（IS-IS）、またはマルチプロトコルボーダーゲートウェイプロトコル（MP-BGP）の使用も含まれます。マルチセグメントPseudowire（MS-PW）ルーティングを申請します。ただし、PWは、LSPベースのPSNSを介してPWSを運ぶ現在定義されている方法に加えて、MPLS-TP LSP（MPLS-TP LSP確立の方法と手順を使用して確立されている）でカプセル化できます。つまり、MPLS-TPドメインは、PWE3アーキテクチャの観点からのPSNです[RFC3985]。
4) The MPLS-TP LSP control plane builds on the GMPLS control plane as defined by the IETF for transport LSPs. The protocols within scope are Resource Reservation Protocol with Traffic Engineering (RSVP-TE) [RFC3473], OSPF-TE [RFC4203] [RFC5392], and ISIS-TE [RFC5307] [RFC5316]. Automatically Switched Optical Network (ASON) signaling and routing requirements in the context of GMPLS can be found in [RFC4139] and [RFC4258].
4) MPLS-TP LSPコントロールプレーンは、輸送LSPのIETFで定義されているように、GMPLSコントロールプレーンの上に構築されます。範囲内のプロトコルは、トラフィックエンジニアリング（RSVP-TE）[RFC3473]、OSPF-TE [RFC4203] [RFC5392]、およびISIS-TE [RFC5307] [RFC5316]を備えたリソース予約プロトコルです。GMPLSのコンテキストで自動的に切り替えられた光ネットワーク（ASON）シグナルとルーティング要件は、[RFC4139]および[RFC4258]にあります。
5) Existing IETF MPLS and GMPLS RFCs and evolving Working Group Internet-Drafts should be reused wherever possible.
5) 既存のIETF MPLSおよびGMPLS RFCSおよび進化するワーキンググループのインターネットドラフトは、可能な限り再利用する必要があります。
6) If needed, extensions for the MPLS-TP control plane should first be based on the existing and evolving IETF work, and secondly be based on work by other standard bodies only when IETF decides that the work is out of the IETF's scope. New extensions may be defined otherwise.
6) 必要に応じて、MPLS-TPコントロールプレーンの拡張機能は、最初に既存および進化するIETF作業に基づいている必要があり、次にIETFがIETFの範囲外であると判断した場合にのみ、他の標準体による作業に基づいています。それ以外の場合は、新しい拡張機能を定義できます。
7) Extensions to the control plane may be required in order to fully automate functions related to MPLS-TP LSPs and PWs.
7) MPLS-TP LSPおよびPWSに関連する機能を完全に自動化するには、コントロールプレーンへの拡張が必要になる場合があります。
8) Control-plane software upgrades to existing equipment are acceptable and expected.
8) 既存の機器へのコントロールプレーンソフトウェアのアップグレードは許容され、期待されます。
9) It is permissible for functions present in the GMPLS and PW control planes to not be used in MPLS-TP networks.
9) GMPLSおよびPWコントロールプレーンに存在する関数がMPLS-TPネットワークで使用されないことが許されます。
10) One possible use of the control plane is to configure, enable, and generally control OAM functionality. This will require extensions to existing control-plane specifications that will be usable in MPLS-TP as well as MPLS networks.
10）コントロールプレーンの使用の1つは、OAM機能を構成、有効化、および一般的に制御することです。これには、MPLS-TPおよびMPLSネットワークで使用できる既存のコントロールプレーン仕様への拡張が必要です。
11) The foundation for MPLS-TP control-plane requirements is primarily found in Section 2.4 of [RFC5654] and relevant portions of the remainder of Section 2 of [RFC5654].
11）MPLS-TPコントロールプレーン要件の基礎は、主に[RFC5654]のセクション2.4および[RFC5654]のセクション2の残りの関連部分に見られます。
The control-plane reference model is based on the general MPLS-TP reference model as defined in the MPLS-TP framework [RFC5921] and further refined in [RFC6215] on the MPLS-TP User-to-Network and Network-to-Network Interfaces (UNI and NNI, respectively). Per the MPLS-TP framework [RFC5921], the MPLS-TP control plane is based on GMPLS with RSVP-TE for LSP signaling and targeted LDP for PW signaling. In both cases, OSPF-TE or ISIS-TE with GMPLS extensions is used for dynamic routing within an MPLS-TP domain.
コントロールプレーン参照モデルは、MPLS-TPフレームワーク[RFC5921]で定義されている一般的なMPLS-TP参照モデルに基づいており、MPLS-TPユーザーからネットワークおよびネットワークへのネットワークの[RFC6215]でさらに洗練されていますインターフェイス（それぞれUNIとNNI）。MPLS-TPフレームワーク[RFC5921]に従って、MPLS-TPコントロールプレーンは、LSPシグナル伝達のRSVP-TEを備えたGMPLSとPWシグナル伝達の標的LDPに基づいています。どちらの場合も、GMPLS拡張機能を備えたOSPF-TEまたはISIS-TEは、MPLS-TPドメイン内の動的ルーティングに使用されます。
Note that in this context, "targeted LDP" (or T-LDP) means LDP as defined in RFC 5036, using Targeted Hello messages. See Section 2.4.2 ("Extended Discovery Mechanism") of [RFC5036]. Use of the extended discovery mechanism is specified in Section 5 ("LDP") of [RFC4447].
このコンテキストでは、「ターゲットLDP」（またはT-LDP）は、ターゲットを絞ったハローメッセージを使用して、RFC 5036で定義されているLDPを意味することに注意してください。[RFC5036]のセクション2.4.2（「拡張発見メカニズム」）を参照してください。拡張された発見メカニズムの使用は、[RFC4447]のセクション5（「LDP」）で指定されています。
From a service perspective, MPLS-TP client services may be supported via both PWs and LSPs. PW client interfaces, or adaptations, are defined on an interface-technology basis, e.g., Ethernet over PW [RFC4448]. In the context of MPLS-TP LSP, the client interface is provided at the network layer and may be controlled via a GMPLS-based UNI, see [RFC4208], or statically provisioned. As discussed in [RFC5921] and [RFC6215], MPLS-TP also presumes an NNI reference point.
サービスの観点から、MPLS-TPクライアントサービスは、PWSとLSPの両方を介してサポートされる場合があります。PWクライアントインターフェイス、または適応は、PW [RFC4448]のイーサネットなど、インターフェイステクノロジーベースで定義されます。MPLS-TP LSPのコンテキストでは、クライアントインターフェイスがネットワークレイヤーで提供され、GMPLSベースのUNI、[RFC4208]を参照、または静的プロビジョニングを介して制御できます。[RFC5921]および[RFC6215]で説明したように、MPLS-TPはNNI参照ポイントも推定します。
The MPLS-TP end-to-end control-plane reference model is shown in Figure 1. The figure shows the control-plane protocols used by MPLS-TP, as well as the UNI and NNI reference points, in the case of a Single-Segment PW supported by an end-to-end LSP without any hierarchical LSPs. (The MS-PW case is not shown.) Each service provider node's participation in routing and signaling (both GMPLS RSVP-TE and PW LDP) is represented. Note that only the service end points participate in PW LDP signaling, while all service provider nodes participate in GMPLS TE LSP routing and signaling.
MPLS-TPエンドツーエンドコントロールプレーン参照モデルを図1に示します。図は、単一の場合のMPLS-TPとUNIおよびNNIの参照ポイントで使用されるコントロールプレーンプロトコルを示しています。 - 階層LSPのないエンドツーエンドLSPによってサポートされるセグメントPW。（MS-PWのケースは表示されません。）各サービスプロバイダーノードのルーティングとシグナリングへの参加（GMPLS RSVP-TEとPW LDPの両方）が表されています。サービスエンドポイントのみがPW LDPシグナリングに参加し、すべてのサービスプロバイダーノードはGMPLS TE LSPルーティングとシグナリングに参加していることに注意してください。
|< ---- client signal (e.g., IP / MPLS / L2) -------- >|
|< --------- SP1 ---------- >|< ------- SP2 ----- >|
|< ---------- MPLS-TP End-to-End PW --------- >|
|< -------- MPLS-TP End-to-End LSP ------ >|
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
|CE1|-|-|PE1|--|P1 |--|P2 |--|PE2|-|-|PEa|--|Pa |--|PEb|-|-|CE2|
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
UNI NNI UNI
GMPLS
TE-RTG, |<-----|------|------|-------|------|----->|
& RSVP-TE
PW LDP |< ---------------------------------------- >|
Figure 1. End-to-End MPLS-TP Control-Plane Reference Model
図1.エンドツーエンドのMPLS-TPコントロールプレーン参照モデル
Legend: CE: Customer Edge Client signal: defined in MPLS-TP Requirements L2: Any layer 2 signal that may be carried over a PW, e.g., Ethernet NNI: Network-to-Network Interface P: Provider PE: Provider Edge SP: Service Provider TE-RTG: GMPLS OSPF-TE or ISIS-TE UNI: User-to-Network Interface
凡例：CE：CEMEDGEクライアント信号：MPLS-TP要件で定義されていますL2：PWに掲載されるレイヤー2信号、例えばイーサネットNNI：ネットワークツーネットワークインターフェイスP：プロバイダーPE：プロバイダーEDGE SP：サービスプロバイダーTE-RTG：GMPLS OSPF-TEまたはISIS-TE UNI：ユーザー間インターフェイス
Note: The MS-PW case is not shown.
注：MS-PWケースは表示されません。
Figure 2 adds three hierarchical LSP segments, labeled as "H-LSPs". These segments are present to support scaling, OAM, and Maintenance Entity Group End Points (MEPs), see [RFC6371], within each provider domain and across the inter-provider NNI. (H-LSPs are used to implement Sub-Path Maintenance Elements (SPMEs) as defined in [RFC5921].) The MEPs are used to collect performance information, support diagnostic and fault management functions, and support OAM triggered survivability schemes as discussed in [RFC6372]. Each H-LSP may be protected or restored using any of the schemes discussed in [RFC6372]. End-to-end monitoring is supported via MEPs at the end-to-end LSP and PW end points. Note that segment MEPs may be co-located with MIPs of the next higher-layer (e.g., end-to-end) LSPs. (The MS-PW case is not shown.)
図2は、「H-LSP」とラベル付けされた3つの階層LSPセグメントを追加します。これらのセグメントは、スケーリング、OAM、およびメンテナンスエンティティグループエンドポイント（MEP）をサポートするために存在します。各プロバイダードメイン内およびプロバイダー間NNI全体で[RFC6371]を参照してください。（H-LSPは、[RFC5921]で定義されているようにサブパスメンテナンス要素（SPME）を実装するために使用されます。）MEPは、パフォーマンス情報を収集し、診断および障害管理機能をサポートし、[[で説明]で説明したOAMトリガーされた生存性スキームをサポートするために使用されます。RFC6372]。各H-LSPは、[RFC6372]で説明されているスキームのいずれかを使用して保護または復元できます。エンドツーエンドモニタリングは、エンドツーエンドのLSPおよびPWエンドポイントでMEPを介してサポートされています。セグメントMEPは、次の高層（例：エンドツーエンド）LSPのMIPと共同住宅される可能性があることに注意してください。（MS-PWのケースは表示されません。）
|< ------- client signal (e.g., IP / MPLS / L2) ----- >|
|< -------- SP1 ----------- >|< ------- SP2 ----- >|
|< ----------- MPLS-TP End-to-End PW -------- >|
|< ------- MPLS-TP End-to-End LSP ------- >|
|< -- H-LSP1 ---- >|<-H-LSP2->|<- H-LSP3 ->|
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
|CE1|-|-|PE1|--|P1 |--|P2 |--|PE2|-|-|PEa|--|Pa |--|PEb|-|-|CE2|
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
UNI NNI UNI
..... .....
End2end |MEP|--------------------------------------|MEP|
PW OAM ''''' '''''
..... ..... ..... .....
End2end |MEP|----------------|MIP|---|MIP|---------|MEP|
LSP OAM ''''' ''''' ''''' '''''
..... ..... ..... ......... ......... ..... .....
Segment |MEP|-|MIP|-|MIP|-|MEP|MEP|-|MEP|MEP|-|MIP|-|MEP|
LSP OAM ''''' ''''' ''''' ''''''''' ''''''''' ''''' '''''
H-LSP GMPLS
TE-RTG |<-----|------|----->||<---->||<-----|----->|
&RSVP-TE (within an MPLS-TP network)
E2E GMPLS
TE-RTG |< ------------------|--------|------------>|
&RSVP-TE
PW LDP |< ---------------------------------------- >|
Figure 2. MPLS-TP Control-Plane Reference Model with OAM
図2. OAMを使用したMPLS-TPコントロールプレーン参照モデル
Legend: CE: Customer Edge Client signal: defined in MPLS-TP Requirements E2E: End-to-End L2: Any layer 2 signal that may be carried over a PW, e.g., Ethernet H-LSP: Hierarchical LSP MEP: Maintenance Entity Group End Point MIP: Maintenance Entity Group Intermediate Point NNI: Network-to-Network Interface P: Provider PE: Provider Edge SP: Service Provider TE-RTG: GMPLS OSPF-TE or ISIS-TE
凡例：CE：顧客エッジクライアント信号：MPLS-TP要件で定義E2E：エンドツーエンドL2：PWを介して持ち運ばれるレイヤー2信号、例えばイーサネットH-LSP：階層LSP MEP：メンテナンスエンティティグループグループエンドポイントMIP：メンテナンスエンティティグループ中間点NNI：ネットワーク間インターフェイスP：プロバイダーPE：プロバイダーEDGE SP：サービスプロバイダーTE-RTG：GMPLS OSPF-TEまたはISIS-TE
Note: The MS-PW case is not shown.
注：MS-PWケースは表示されません。
While not shown in the figures above, the MPLS-TP control plane must support the addressing separation and independence between the data, control, and management planes. Address separation between the planes is already included in GMPLS. Such separation is also already included in LDP as LDP session end point addresses are never automatically associated with forwarding.
上記の図には示されていませんが、MPLS-TPコントロールプレーンは、データ、コントロール、および管理プレーン間のアドレス指定と独立性をサポートする必要があります。面間のアドレス分離は、すでにGMPLに含まれています。LDPセッションエンドポイントアドレスが転送に自動的に関連付けられていないため、このような分離もLDPにも含まれています。
The requirements for the MPLS-TP control plane are derived from the MPLS-TP requirements and framework documents, specifically [RFC5654], [RFC5921], [RFC5860], [RFC6371], and [RFC6372]. The requirements are summarized in this section, but do not replace those documents. If there are differences between this section and those documents, those documents shall be considered authoritative.
MPLS-TPコントロールプレーンの要件は、MPLS-TP要件とフレームワークドキュメント、特に[RFC5654]、[RFC5860]、[RFC5860]、[RFC6371]、および[RFC6372]から派生しています。要件はこのセクションで要約されていますが、これらのドキュメントを置き換えないでください。このセクションとそれらのドキュメントの間に違いがある場合、これらの文書は権威あると見なされます。
These requirements are based on Section 2 of [RFC5654]:
これらの要件は、[RFC5654]のセクション2に基づいています。
1. Any new functionality that is defined to fulfill the requirements for MPLS-TP must be agreed within the IETF through the IETF consensus process as per [RFC4929] and Section 1, paragraph 15 of [RFC5654].
1. MPLS-TPの要件を満たすために定義された新しい機能は、[RFC4929]およびセクション1、[RFC5654]の第15項に従って、IETFコンセンサスプロセスを通じてIETF内で合意する必要があります。
2. The MPLS-TP control-plane design should as far as reasonably possible reuse existing MPLS standards ([RFC5654], requirement 2).
2. MPLS-TPコントロールプレーン設計は、既存のMPLS標準（[RFC5654]、要件2）を合理的に再利用する可能性がある限りです。
3. The MPLS-TP control plane must be able to interoperate with existing IETF MPLS and PWE3 control planes where appropriate ([RFC5654], requirement 3).
3. MPLS-TPコントロールプレーンは、必要に応じて既存のIETF MPLSとPWE3制御プレーンと相互運用できる必要があります（[RFC5654]、要件3）。
4. The MPLS-TP control plane must be sufficiently well-defined to ensure that the interworking between equipment supplied by multiple vendors will be possible both within a single domain and between domains ([RFC5654], requirement 4).
4. MPLS-TPコントロールプレーンは、複数のベンダーが提供する機器間のインターワーキングが単一のドメイン内およびドメイン間の両方で可能になるように十分に定義されている必要があります（[RFC5654]、要件4）。
5. The MPLS-TP control plane must support a connection-oriented packet switching model with traffic engineering capabilities that allow deterministic control of the use of network resources ([RFC5654], requirement 5).
5. MPLS-TP制御プレーンは、ネットワークリソースの使用の決定論的制御を可能にするトラフィックエンジニアリング機能を備えた接続指向のパケットスイッチングモデルをサポートする必要があります（[RFC5654]、要件5）。
6. The MPLS-TP control plane must support traffic-engineered point-to-point (P2P) and point-to-multipoint (P2MP) transport paths ([RFC5654], requirement 6).
6. MPLS-TPコントロールプレーンは、トラフィックエンジニアリングポイントツーポイント（P2P）およびポイントツーマルチポイント（P2MP）輸送パス（[RFC5654]、要件6）をサポートする必要があります。
7. The MPLS-TP control plane must support unidirectional, associated bidirectional and co-routed bidirectional point-to-point transport paths ([RFC5654], requirement 7).
7. MPLS-TPコントロールプレーンは、単方向、関連する双方向および共有の双方向のポイントツーポイント輸送パス（[RFC5654]、要件7）をサポートする必要があります。
8. The MPLS-TP control plane must support unidirectional point-to-multipoint transport paths ([RFC5654], requirement 8).
8. MPLS-TPコントロールプレーンは、単方向のポイントツーマルチポイント輸送パス（[RFC5654]、要件8）をサポートする必要があります。
9. The MPLS-TP control plane must enable all nodes (i.e., ingress, egress, and intermediate) to be aware about the pairing relationship of the forward and the backward directions belonging to the same co-routed bidirectional transport path ([RFC5654], requirement 10).
9. MPLS-TPコントロールプレーンは、すべてのノード（つまり、イングレス、出口、および中間体）が、同じ共逆方向の双方向輸送経路（[RFC5654]、要件に属する前方方向と後方方向の組み合わせ関係について認識できるようにする必要があります。10）。
10. The MPLS-TP control plane must enable edge nodes (i.e., ingress and egress) to be aware of the pairing relationship of the forward and the backward directions belonging to the same associated bidirectional transport path ([RFC5654], requirement 11).
10. MPLS-TPコントロールプレーンは、エッジノード（つまり、イングレスと出口）が、同じ関連する双方向輸送経路（[RFC5654]、要件11）に属する前方方向と後方方向のペアリング関係を認識できるようにする必要があります。
11. The MPLS-TP control plane should enable common transit nodes to be aware of the pairing relationship of the forward and the backward directions belonging to the same associated bidirectional transport path ([RFC5654], requirement 12).
11. MPLS-TPコントロールプレーンは、一般的なトランジットノードが、同じ関連する双方向輸送経路（[RFC5654]、要件12）に属する前方方向と後方方向のペアリング関係を認識できるようにする必要があります。
12. The MPLS-TP control plane must support bidirectional transport paths with symmetric bandwidth requirements, i.e., the amount of reserved bandwidth is the same in the forward and backward directions ([RFC5654], requirement 13).
12. MPLS-TPコントロールプレーンは、対称帯域幅要件を持つ双方向輸送経路をサポートする必要があります。つまり、予約された帯域幅の量は、順方向と後方方向で同じです（[RFC5654]、要件13）。
13. The MPLS-TP control plane must support bidirectional transport paths with asymmetric bandwidth requirements, i.e., the amount of reserved bandwidth differs in the forward and backward directions ([RFC5654], requirement 14).
13. MPLS-TPコントロールプレーンは、非対称帯域幅要件を備えた双方向輸送経路をサポートする必要があります。つまり、予約された帯域幅の量は、前方向と後方向に異なります（[RFC5654]、要件14）。
14. The MPLS-TP control plane must support the logical separation of the control plane from the management and data planes ([RFC5654], requirement 15). Note that this implies that the addresses used in the control plane are independent from the addresses used in the management and data planes.
14. MPLS-TPコントロールプレーンは、管理プレーンとデータプレーンからの制御プレーンの論理的分離をサポートする必要があります（[RFC5654]、要件15）。これは、コントロールプレーンで使用されるアドレスが、管理面およびデータプレーンで使用されるアドレスから独立していることを意味することに注意してください。
15. The MPLS-TP control plane must support the physical separation of the control plane from the management and data plane, and no assumptions should be made about the state of the data-plane channels from information about the control- or management-plane channels when they are running out-of-band ([RFC5654], requirement 16).
15. MPLS-TPコントロールプレーンは、管理プレーンの管理プレーンの物理的分離を管理およびデータプレーンからサポートする必要があります。また、コントロールまたは管理面チャネルに関する情報からデータプレーンチャネルの状態の状態について仮定を立てないでください。帯域外で走っています（[RFC5654]、要件16）。
16. A control plane must be defined to support dynamic provisioning and restoration of MPLS-TP transport paths, but its use is a network operator's choice ([RFC5654], requirement 18).
16. MPLS-TPトランスポートパスの動的プロビジョニングと回復をサポートするために制御プレーンを定義する必要がありますが、その使用はネットワークオペレーターの選択です（[RFC5654]、要件18）。
17. The presence of a control plane must not be required for static provisioning of MPLS-TP transport paths ([RFC5654], requirement 19).
17. MPLS-TP輸送パスの静的プロビジョニングには、コントロールプレーンの存在を必要としないでください（[RFC5654]、要件19）。
18. The MPLS-TP control plane must permit the coexistence of statically and dynamically provisioned/managed MPLS-TP transport paths within the same layer network or domain ([RFC5654], requirement 20).
18. MPLS-TP制御プレーンは、同じレイヤーネットワークまたはドメイン内の静的および動的にプロビジョニング/管理されたMPLS-TPトランスポートパス（[RFC5654]、要件20）の共存を許可する必要があります。
19. The MPLS-TP control plane should be operable in a way that is similar to the way the control plane operates in other transport-layer technologies ([RFC5654], requirement 21).
19. MPLS-TPコントロールプレーンは、コントロールプレーンが他の輸送層技術で動作する方法に似た方法で動作可能である必要があります（[RFC5654]、要件21）。
20. The MPLS-TP control plane must avoid or minimize traffic impact (e.g., packet delay, reordering, and loss) during network reconfiguration ([RFC5654], requirement 24).
20. MPLS-TPコントロールプレーンは、ネットワーク再構成中（[RFC5654]、要件24）中に、トラフィックの影響（パケットの遅延、並べ替え、損失など）を回避または最小化する必要があります。
21. The MPLS-TP control plane must work across multiple homogeneous domains ([RFC5654], requirement 25), i.e., all domains use the same MPLS-TP control plane.
21. MPLS-TPコントロールプレーンは、複数の均一なドメイン（[RFC5654]、要件25）で動作する必要があります。つまり、すべてのドメインは同じMPLS-TPコントロールプレーンを使用します。
22. The MPLS-TP control plane should work across multiple non-homogeneous domains ([RFC5654], requirement 26), i.e., some domains use the same control plane and other domains use static provisioning at the domain boundary.
22. MPLS-TPコントロールプレーンは、複数の非均一なドメイン（[RFC5654]、要件26）にわたって動作する必要があります。つまり、一部のドメインは同じコントロールプレーンを使用し、他のドメインはドメイン境界で静的プロビジョニングを使用します。
23. The MPLS-TP control plane must not dictate any particular physical or logical topology ([RFC5654], requirement 27).
23. MPLS-TPコントロールプレーンは、特定の物理的または論理トポロジを決定してはなりません（[RFC5654]、要件27）。
24. The MPLS-TP control plane must include support of ring topologies that may be deployed with arbitrary interconnection and support of rings of at least 16 nodes ([RFC5654], requirements 27.A, 27.B, and 27.C).
24. MPLS-TPコントロールプレーンには、少なくとも16のノード（[RFC5654]、要件27.A、27.B、および27.C）のリングの任意の相互接続とサポートで展開できるリングトポロジのサポートを含める必要があります。
25. The MPLS-TP control plane must scale gracefully to support a large number of transport paths, nodes, and links. That is, it must be able to scale at least as well as control planes in existing transport technologies with growing and increasingly complex network topologies as well as with increasing bandwidth demands, number of customers, and number of services ([RFC5654], requirements 53 and 28).
25. MPLS-TPコントロールプレーンは、多数の輸送パス、ノード、およびリンクをサポートするために優雅にスケーリングする必要があります。つまり、少なくとも成長し、ますます複雑なネットワークトポロジ、および帯域幅の需要、顧客の数、およびサービスの数を増やすことで、既存の輸送技術の平面を制御できるようにすることができなければなりません（[RFC5654]、要件53および28）。
26. The MPLS-TP control plane should not provision transport paths that contain forwarding loops ([RFC5654], requirement 29).
26. MPLS-TPコントロールプレーンは、転送ループを含む輸送パスを提供してはなりません（[RFC5654]、要件29）。
27. The MPLS-TP control plane must support multiple client layers (e.g., MPLS-TP, IP, MPLS, Ethernet, ATM, Frame Relay, etc.) ([RFC5654], requirement 30).
27. MPLS-TPコントロールプレーンは、複数のクライアントレイヤー（MPLS-TP、IP、MPLS、イーサネット、ATM、フレームリレーなど）をサポートする必要があります（[RFC5654]、要件30）。
28. The MPLS-TP control plane must provide a generic and extensible solution to support the transport of MPLS-TP transport paths over one or more server-layer networks (such as MPLS-TP, Ethernet, Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH), Optical Transport Network (OTN), etc.). Requirements for bandwidth management within a server-layer network are outside the scope of this document ([RFC5654], requirement 31).
28. MPLS-TPコントロールプレーンは、1つ以上のサーバー層ネットワーク（MPLS-TP、イーサネット、同期光ネットワーク /同期デジタル階層（SONET / SONET /など）を介したMPLS-TP輸送パスの輸送をサポートするための一般的で拡張可能なソリューションを提供する必要があります。SDH）、光輸送ネットワーク（OTN）など）。サーバー層ネットワーク内の帯域幅管理の要件は、このドキュメントの範囲外です（[RFC5654]、要件31）。
29. In an environment where an MPLS-TP layer network is supporting a client-layer network, and the MPLS-TP layer network is supported by a server-layer network, then the control-plane operation of the MPLS-TP layer network must be possible without any dependencies on the server or client-layer network ([RFC5654], requirement 32).
29. MPLS-TPレイヤーネットワークがクライアントレイヤーネットワークをサポートし、MPLS-TPレイヤーネットワークがサーバー層ネットワークによってサポートされている環境では、MPLS-TPレイヤーネットワークの制御面操作が可能でなければなりませんサーバーまたはクライアントレイヤーネットワークに依存せず（[RFC5654]、要件32）。
30. The MPLS-TP control plane must allow for the transport of a client MPLS or MPLS-TP layer network over a server MPLS or MPLS-TP layer network ([RFC5654], requirement 33).
30. MPLS-TP制御プレーンは、サーバーMPLSまたはMPLS-TPレイヤーネットワーク（[RFC5654]、要件33）上のクライアントMPLSまたはMPLS-TPレイヤーネットワークの輸送を許可する必要があります。
31. The MPLS-TP control plane must allow the autonomous operation of the layers of a multi-layer network that includes an MPLS-TP layer ([RFC5654], requirement 34).
31. MPLS-TP制御プレーンは、MPLS-TP層（[RFC5654]、要件34）を含む多層ネットワークの層の自律運転を許可する必要があります。
32. The MPLS-TP control plane must allow the hiding of MPLS-TP layer network addressing and other information (e.g., topology) from client-layer networks. However, it should be possible, at the option of the operator, to leak a limited amount of summarized information, such as Shared Risk Link Groups (SRLGs) or reachability, between layers ([RFC5654], requirement 35).
32. MPLS-TPコントロールプレーンは、クライアント層ネットワークからのMPLS-TPレイヤーネットワークのアドレス指定やその他の情報（トポロジなど）を隠すことを許可する必要があります。ただし、レイヤー間（[RFC5654]、要件35）間で、共有リスクリンクグループ（SRLG）または到達可能性など、限られた量の要約情報を漏らすことができるはずです。
33. The MPLS-TP control plane must allow for the identification of a transport path on each link within and at the destination (egress) of the transport network ([RFC5654], requirements 38 and 39).
33. MPLS-TPコントロールプレーンは、輸送ネットワーク内および宛先（[RFC5654]、要件38および39）内の各リンク（出力）の輸送経路の識別を可能にする必要があります。
34. The MPLS-TP control plane must allow for the use of P2MP server (sub-)layer capabilities as well as P2P server (sub-)layer capabilities when supporting P2MP MPLS-TP transport paths ([RFC5654], requirement 40).
34. MPLS-TPコントロールプレーンは、P2MP MPLS-TP輸送パス（[RFC5654]、要件40）をサポートする際に、P2MPサーバー（サブ）レイヤー機能とP2Pサーバー（サブ）レイヤー機能の使用を許可する必要があります。
35. The MPLS-TP control plane must be extensible in order to accommodate new types of client-layer networks and services ([RFC5654], requirement 41).
35. MPLS-TP制御プレーンは、新しいタイプのクライアント層ネットワークとサービスに対応するために拡張可能でなければなりません（[RFC5654]、要件41）。
36. The MPLS-TP control plane should support the reserved bandwidth associated with a transport path to be increased without impacting the existing traffic on that transport path, provided enough resources are available ([RFC5654], requirement 42)).
36. MPLS-TPコントロールプレーンは、十分なリソースが利用可能であれば、その輸送パスの既存のトラフィックに影響を与えることなく、輸送経路に関連する予約帯域幅をサポートする必要があります（[RFC5654]、要件42））。
37. The MPLS-TP control plane should support the reserved bandwidth of a transport path being decreased without impacting the existing traffic on that transport path, provided that the level of existing traffic is smaller than the reserved bandwidth following the decrease ([RFC5654], requirement 43).
37. MPLS-TPコントロールプレーンは、既存のトラフィックのレベルが減少後の予約帯域幅よりも小さい場合（[RFC5654]、要件43である限り、その輸送経路の既存のトラフィックに影響を与えることなく、輸送経路の予約帯域幅をサポートする必要があります。）。
38. The control plane for MPLS-TP must fit within the ASON (control-plane) architecture. The ITU-T has defined an architecture for ASONs in G.8080 [ITU.G8080.2006] and G.8080 Amendment 1 [ITU.G8080.2008]. An interpretation of the ASON signaling and routing requirements in the context of GMPLS can be found in [RFC4139], [RFC4258], and Section 2.4, paragraphs 2 and 3 of [RFC5654].
38. MPLS-TPのコントロールプレーンは、ASON（コントロールプレーン）アーキテクチャに収まる必要があります。ITU-Tは、G.8080 [ITU.G8080.2006]およびG.8080修正1 [ITU.G8080.2008]のAsonsのアーキテクチャを定義しました。GMPLSのコンテキストでのASONシグナルとルーティングの要件の解釈は、[RFC4139]、[RFC4258]、およびセクション2.4、[RFC5654]のパラグラフ2および3に記載されています。
39. The MPLS-TP control plane must support control-plane topology and data-plane topology independence ([RFC5654], requirement 47).
39. MPLS-TPコントロールプレーンは、コントロールプレーントポロジとデータプレーントポロジの独立性をサポートする必要があります（[RFC5654]、要件47）。
40. A failure of the MPLS-TP control plane must not interfere with the delivery of service or recovery of established transport paths ([RFC5654], requirement 47).
40. MPLS-TP制御プレーンの障害は、確立された輸送経路のサービスの提供または回復を妨害してはなりません（[RFC5654]、要件47）。
41. The MPLS-TP control plane must be able to operate independent of any particular client- or server-layer control plane ([RFC5654], requirement 48).
41. MPLS-TPコントロールプレーンは、特定のクライアントまたはサーバー層制御プレーン（[RFC5654]、要件48）とは無関係に動作できる必要があります。
42. The MPLS-TP control plane should support, but not require, an integrated control plane encompassing MPLS-TP together with its server- and client-layer networks when these layer networks belong to the same administrative domain ([RFC5654], requirement 49).
42. MPLS-TPコントロールプレーンは、これらのレイヤーネットワークが同じ管理ドメイン（[RFC5654]、要件49）に属している場合、MPLS-TPをサーバーおよびクライアント層ネットワークとともに含む統合制御プレーンをサポートする必要はありませんが、必要ありません。
43. The MPLS-TP control plane must support configuration of protection functions and any associated maintenance (OAM) functions ([RFC5654], requirements 50 and 7).
43. MPLS-TP制御プレーンは、保護機能の構成と関連するメンテナンス（OAM）関数（[RFC5654]、要件50および7）をサポートする必要があります。
44. The MPLS-TP control plane must support the configuration and modification of OAM maintenance points as well as the activation/deactivation of OAM when the transport path or transport service is established or modified ([RFC5654], requirement 51).
44. MPLS-TP制御プレーンは、OAMメンテナンスポイントの構成と変更、および輸送パスまたは輸送サービスが確立または変更された場合のOAMの活性化/非活性化をサポートする必要があります（[RFC5654]、要件51）。
45. The MPLS-TP control plane must be capable of restarting and relearning its previous state without impacting forwarding ([RFC5654], requirement 54).
45. MPLS-TPコントロールプレーンは、転送に影響を与えることなく以前の状態を再開および再学習できる必要があります（[RFC5654]、要件54）。
46. The MPLS-TP control plane must provide a mechanism for dynamic ownership transfer of the control of MPLS-TP transport paths from the management plane to the control plane and vice versa. The number of reconfigurations required in the data plane must be minimized; preferably no data-plane reconfiguration will be required ([RFC5654], requirement 55). Note, such transfers cover all transport path control functions including control of recovery and OAM.
46. MPLS-TP制御プレーンは、MPLS-TP輸送経路の制御の動的な所有権移動のメカニズムを、管理プレーンから、その逆のメカニズムを提供する必要があります。データプレーンに必要な再構成の数を最小限に抑える必要があります。できれば、データプレーンの再構成は必要ありません（[RFC5654]、要件55）。このような転送は、回復とOAMの制御を含むすべての輸送パス制御機能をカバーしています。
47. The MPLS-TP control plane must support protection and restoration mechanisms, i.e., recovery ([RFC5654], requirement 52).
47. MPLS-TP制御プレーンは、保護および回復メカニズム、つまり回復（[RFC5654]、要件52）をサポートする必要があります。
Note that the MPLS-TP survivability framework document [RFC6372] provides additional useful information related to recovery.
MPLS-TP Survivability Frameworkドキュメント[RFC6372]は、回復に関連する追加の有用な情報を提供することに注意してください。
48. The MPLS-TP control-plane mechanisms should be identical (or as similar as possible) to those already used in existing transport networks to simplify implementation and operations. However, this must not override any other requirement ([RFC5654], requirement 56 A).
48. MPLS-TPコントロールプレーンメカニズムは、実装と操作を簡素化するために既存の輸送ネットワークで既に使用されているものと同一（または可能な限り類似）する必要があります。ただし、これは他の要件を無効にしてはなりません（[RFC5654]、要件56 A）。
49. The MPLS-TP control-plane mechanisms used for P2P and P2MP recovery should be identical to simplify implementation and operation. However, this must not override any other requirement ([RFC5654], requirement 56 B).
49. P2PおよびP2MP回復に使用されるMPLS-TP制御面機メカニズムは、実装と動作を簡素化するために同一でなければなりません。ただし、これは他の要件を無効にしてはなりません（[RFC5654]、要件56 b）。
50. The MPLS-TP control plane must support recovery mechanisms that are applicable at various levels throughout the network including support for link, transport path, segment, concatenated segment, and end-to-end recovery ([RFC5654], requirement 57).
50. MPLS-TP制御プレーンは、リンク、輸送パス、セグメント、連結セグメント、エンドツーエンドの回復（[RFC5654]、要件57）のサポートなど、ネットワーク全体でさまざまなレベルで適用できる回復メカニズムをサポートする必要があります。
51. The MPLS-TP control plane must support recovery paths that meet the Service Level Agreement (SLA) protection objectives of the service ([RFC5654], requirement 58). These include:
51. MPLS-TP制御プレーンは、サービスのサービスレベル契約（SLA）保護目標を満たす回復パスをサポートする必要があります（[RFC5654]、要件58）。これらには以下が含まれます：
a. Guarantee 50-ms recovery times from the moment of fault detection in networks with spans less than 1200 km.
a. 1200 km未満のネットワークでの障害検出の瞬間から50 msの回復時間を保証します。
b. Protection of 100% of the traffic on the protected path.
b. 保護されたパス上のトラフィックの100％の保護。
c. Recovery must meet SLA requirements over multiple domains.
c. 回復は、複数のドメインでSLA要件を満たす必要があります。
52. The MPLS-TP control plane should support per-transport-path recovery objectives ([RFC5654], requirement 59).
52. MPLS-TPコントロールプレーンは、輸送ごとの回復目標（[RFC5654]、要件59）をサポートする必要があります。
53. The MPLS-TP control plane must support recovery mechanisms that are applicable to any topology ([RFC5654], requirement 60).
53. MPLS-TPコントロールプレーンは、トポロジに適用できる回復メカニズムをサポートする必要があります（[RFC5654]、要件60）。
54. The MPLS-TP control plane must operate in synergy with (including coordination of timing/timer settings) the recovery mechanisms present in any client or server transport networks (for example, Ethernet, SDH, OTN, Wavelength Division Multiplexing (WDM)) to avoid race conditions between the layers ([RFC5654], requirement 61).
54. MPLS-TPコントロールプレーンは、クライアントまたはサーバートランスポートネットワーク（たとえば、イーサネット、SDH、OTN、波長分割マルチプレックス（WDM））に存在する回復メカニズムを（タイミング/タイマー設定の調整を含む）相乗的に動作する必要があります。レイヤー間の人種条件（[RFC5654]、要件61）。
55. The MPLS-TP control plane must support recovery and reversion mechanisms that prevent frequent operation of recovery in the event of an intermittent defect ([RFC5654], requirement 62).
55. MPLS-TPコントロールプレーンは、断続的な欠陥が発生した場合に頻繁に回復の動作を防ぐ回復および逆転メカニズムをサポートする必要があります（[RFC5654]、要件62）。
56. The MPLS-TP control plane must support revertive and non-revertive protection behavior ([RFC5654], requirement 64).
56. MPLS-TPコントロールプレーンは、リバートバージョンおよび非反転保護挙動をサポートする必要があります（[RFC5654]、要件64）。
57. The MPLS-TP control plane must support 1+1 bidirectional protection for P2P transport paths ([RFC5654], requirement 65 A).
57. MPLS-TPコントロールプレーンは、P2P輸送パスの1 1双方向保護をサポートする必要があります（[RFC5654]、要件65 a）。
58. The MPLS-TP control plane must support 1+1 unidirectional protection for P2P transport paths ([RFC5654], requirement 65 B).
58. MPLS-TP制御プレーンは、P2P輸送経路の1 1方向保護をサポートする必要があります（[RFC5654]、要件65 b）。
59. The MPLS-TP control plane must support 1+1 unidirectional protection for P2MP transport paths ([RFC5654], requirement 65 C).
59. MPLS-TP制御プレーンは、P2MP輸送経路の1 1方向保護をサポートする必要があります（[RFC5654]、要件65 C）。
60. The MPLS-TP control plane must support the ability to share protection resources amongst a number of transport paths ([RFC5654], requirement 66).
60. MPLS-TPコントロールプレーンは、多くの輸送パスの間で保護リソースを共有する機能をサポートする必要があります（[RFC5654]、要件66）。
61. The MPLS-TP control plane must support 1:n bidirectional protection for P2P transport paths. Bidirectional 1:n protection should be the default for 1:n protection ([RFC5654], requirement 67 A).
61. MPLS-TPコントロールプレーンは、P2P輸送経路の1：N双方向保護をサポートする必要があります。双方向1：n保護は、1：n保護のデフォルトである必要があります（[RFC5654]、要件67 a）。
62. The MPLS-TP control plane must support 1:n unidirectional protection for P2MP transport paths ([RFC5654], requirement 67 B).
62. MPLS-TPコントロールプレーンは、P2MP輸送経路の1つの単方向保護をサポートする必要があります（[RFC5654]、要件67 b）。
63. The MPLS-TP control plane may support 1:n unidirectional protection for P2P transport paths ([RFC5654], requirement 65 C).
63. MPLS-TPコントロールプレーンは、P2P輸送経路の1つの単方向保護（[RFC5654]、要件65 C）をサポートする場合があります。
64. The MPLS-TP control plane may support the control of extra-traffic type traffic ([RFC5654], note after requirement 67).
64. MPLS-TPコントロールプレーンは、トラフィック以外のトラフィックの制御をサポートする場合があります（[RFC5654]、要件67の後に注意してください）。
65. The MPLS-TP control plane should support 1:n (including 1:1) shared mesh recovery ([RFC5654], requirement 68).
65. MPLS-TPコントロールプレーンは、1：N（1：1を含む）共有メッシュ回復（[RFC5654]、要件68）をサポートする必要があります。
66. The MPLS-TP control plane must support sharing of protection resources such that protection paths that are known not to be required concurrently can share the same resources ([RFC5654], requirement 69).
66. MPLS-TP制御プレーンは、同時に必要でないことが知られている保護パスが同じリソースを共有できるように、保護リソースの共有をサポートする必要があります（[RFC5654]、要件69）。
67. The MPLS-TP control plane must support the sharing of resources between a restoration transport path and the transport path being replaced ([RFC5654], requirement 70).
67. MPLS-TPコントロールプレーンは、復元輸送経路と交換される輸送経路との間のリソースの共有をサポートする必要があります（[RFC5654]、要件70）。
68. The MPLS-TP control plane must support restoration priority so that an implementation can determine the order in which transport paths should be restored ([RFC5654], requirement 71).
68. MPLS-TP制御プレーンは、実装が輸送パスを復元する順序を決定できるように、回復の優先度をサポートする必要があります（[RFC5654]、要件71）。
69. The MPLS-TP control plane must support preemption priority in order to allow restoration to displace other transport paths in the event of resource constraints ([RFC5654], requirements 72 and 86).
69. MPLS-TPコントロールプレーンは、リソースの制約（[RFC5654]、要件72および86）が発生した場合に、修復が他の輸送パスを置き換えることを可能にするために、先制の優先度をサポートする必要があります。
70. The MPLS-TP control plane must support revertive and non-revertive restoration behavior ([RFC5654], requirement 73).
70. MPLS-TPコントロールプレーンは、リバートバージョンおよび非リバートの修復挙動をサポートする必要があります（[RFC5654]、要件73）。
71. The MPLS-TP control plane must support recovery being triggered by physical (lower) layer fault indications ([RFC5654], requirement 74).
71. MPLS-TPコントロールプレーンは、物理的な（低い）層障害適応症によってトリガーされる回復をサポートする必要があります（[RFC5654]、要件74）。
72. The MPLS-TP control plane must support recovery being triggered by OAM ([RFC5654], requirement 75).
72. MPLS-TPコントロールプレーンは、OAMによってトリガーされる回復をサポートする必要があります（[RFC5654]、要件75）。
73. The MPLS-TP control plane must support management-plane recovery triggers (e.g., forced switch, etc.) ([RFC5654], requirement 76).
73. MPLS-TPコントロールプレーンは、管理プレーンリカバリトリガー（たとえば、強制スイッチなど）をサポートする必要があります（[RFC5654]、要件76）。
74. The MPLS-TP control plane must support the differentiation of administrative recovery actions from recovery actions initiated by other triggers ([RFC5654], requirement 77).
74. MPLS-TPコントロールプレーンは、他のトリガーによって開始された回復アクション（[RFC5654]、要件77）との管理回復アクションの差別化をサポートする必要があります。
75. The MPLS-TP control plane should support control-plane restoration triggers (e.g., forced switch, etc.) ([RFC5654], requirement 78).
75. MPLS-TPコントロールプレーンは、コントロールプレーンの修復トリガー（たとえば、強制スイッチなど）をサポートする必要があります（[RFC5654]、要件78）。
76. The MPLS-TP control plane must support priority logic to negotiate and accommodate coexisting requests (i.e., multiple requests) for protection switching (e.g., administrative requests and requests due to link/node failures) ([RFC5654], requirement 79).
76. MPLS-TPコントロールプレーンは、保護スイッチングの共存リクエスト（つまり、複数のリクエスト）を交渉および対応するための優先ロジックをサポートする必要があります（例：リンク/ノード障害による管理要求と要求）（[RFC5654]、要件79）。
77. The MPLS-TP control plane must support the association of protection paths and working paths (sometimes known as protection groups) ([RFC5654], requirement 80).
77. MPLS-TP制御プレーンは、保護パスと作業経路の関連付け（保護グループと呼ばれることもある）をサポートする必要があります（[RFC5654]、要件80）。
78. The MPLS-TP control plane must support pre-calculation of recovery paths ([RFC5654], requirement 81).
78. MPLS-TP制御プレーンは、回復パスの事前計算をサポートする必要があります（[RFC5654]、要件81）。
79. The MPLS-TP control plane must support pre-provisioning of recovery paths ([RFC5654], requirement 82).
79. MPLS-TPコントロールプレーンは、回復パスの事前プロビジョニングをサポートする必要があります（[RFC5654]、要件82）。
80. The MPLS-TP control plane must support the external commands defined in [RFC4427]. External controls overruled by higher priority requests (e.g., administrative requests and requests due to link/node failures) or unable to be signaled to the remote end (e.g., because of a protection state coordination fail) must be ignored/dropped ([RFC5654], requirement 83).
80. MPLS-TPコントロールプレーンは、[RFC4427]で定義されている外部コマンドをサポートする必要があります。より高い優先順位要求（例：リンク/ノードの障害による管理要求と要求など）によって却下された、またはリモートエンドに信号を送信できない外部コントロール（たとえば、保護状態の調整の失敗のため）は無視/ドロップする必要があります（[RFC5654]、要件83）。
81. The MPLS-TP control plane must permit the testing and validation of the integrity of the protection/recovery transport path ([RFC5654], requirement 84 A).
81. MPLS-TP制御プレーンは、保護/回復輸送パスの整合性のテストと検証を許可する必要があります（[RFC5654]、要件84 a）。
82. The MPLS-TP control plane must permit the testing and validation of protection/restoration mechanisms without triggering the actual protection/restoration ([RFC5654], requirement 84 B).
82. MPLS-TP制御プレーンは、実際の保護/修復をトリガーせずに保護/修復メカニズムのテストと検証を許可する必要があります（[RFC5654]、要件84 b）。
83. The MPLS-TP control plane must permit the testing and validation of protection/restoration mechanisms while the working path is in service ([RFC5654], requirement 84 C).
83. MPLS-TPコントロールプレーンは、作業経路が使用されている間に保護/修復メカニズムのテストと検証を許可する必要があります（[RFC5654]、要件84 C）。
84. The MPLS-TP control plane must permit the testing and validation of protection/restoration mechanisms while the working path is out of service ([RFC5654], requirement 84 D).
84. MPLS-TPコントロールプレーンは、作業経路が使用されている間（[RFC5654]、要件84 D）、保護/修復メカニズムのテストと検証を許可する必要があります。
85. The MPLS-TP control plane must support the establishment and maintenance of all recovery entities and functions ([RFC5654], requirement 89 A).
85. MPLS-TP制御プレーンは、すべての回復エンティティと機能の確立とメンテナンスをサポートする必要があります（[RFC5654]、要件89 a）。
86. The MPLS-TP control plane must support signaling of recovery administrative control ([RFC5654], requirement 89 B).
86. MPLS-TP制御プレーンは、回復管理制御のシグナル伝達をサポートする必要があります（[RFC5654]、要件89 b）。
87. The MPLS-TP control plane must support protection state coordination. Since control-plane network topology is independent from the data-plane network topology, the protection state coordination supported by the MPLS-TP control plane may run on resources different than the data-plane resources handled within the recovery mechanism (e.g., backup) ([RFC5654], requirement 89 C).
87. MPLS-TP制御プレーンは、保護状態調整をサポートする必要があります。コントロールプレーンネットワークトポロジーはデータプレーンネットワークトポロジから独立しているため、MPLS-TP制御プレーンがサポートする保護状態調整は、回復メカニズム内で処理されるデータプレーンリソース（例：バックアップ）とは異なるリソースで実行できます。[RFC5654]、要件89 C）。
88. When present, the MPLS-TP control plane must support recovery mechanisms that are optimized for specific network topologies. These mechanisms must be interoperable with the mechanisms defined for arbitrary topology (mesh) networks to enable protection of end-to-end transport paths ([RFC5654], requirement 91).
88. 存在する場合、MPLS-TP制御プレーンは、特定のネットワークトポロジに最適化された回復メカニズムをサポートする必要があります。これらのメカニズムは、任意のトポロジ（MESH）ネットワークで定義されたメカニズムと相互運用可能でなければならないため、エンドツーエンドの輸送パス（[RFC5654]、要件91）の保護を可能にします。
89. When present, the MPLS-TP control plane must support the control of ring-topology-specific recovery mechanisms ([RFC5654], Section 2.5.6.1).
89. 存在する場合、MPLS-TPコントロールプレーンは、リングトポロジ固有の回復メカニズムの制御をサポートする必要があります（[RFC5654]、セクション2.5.6.1）。
90. The MPLS-TP control plane must include support for differentiated services and different traffic types with traffic class separation associated with different traffic ([RFC5654], requirement 110).
90. MPLS-TPコントロールプレーンには、異なるトラフィックに関連するトラフィッククラスの分離を伴う異なるトラフィックタイプのサポートを含める必要があります（[RFC5654]、要件110）。
91. The MPLS-TP control plane must support the provisioning of services that provide guaranteed Service Level Specifications (SLSs), with support for hard ([RFC3209] style) and relative ([RFC3270] style) end-to-end bandwidth guarantees ([RFC5654], requirement 111).
91. MPLS-TPコントロールプレーンは、ハード（[RFC3209]スタイル）と相対的な（[RFC3270]スタイル）エンドツーエンドの帯域幅保証（[RFC565444スタイル）をサポートして、保証されたサービスレベル仕様（SLSS）を提供するサービスのプロビジョニングをサポートする必要があります。]、要件111）。
92. The MPLS-TP control plane must support the provisioning of services that are sensitive to jitter and delay ([RFC5654], requirement 112).
92. MPLS-TP制御プレーンは、ジッターと遅延に敏感なサービスのプロビジョニングをサポートする必要があります（[RFC5654]、要件112）。
The following additional requirements are based on [RFC5921], [TP-P2MP-FWK], and [RFC5960]:
以下の追加要件は、[RFC5921]、[TP-P2MP-FWK]、および[RFC5960]に基づいています。
93. Per-packet Equal Cost Multi-Path (ECMP) load balancing is currently outside the scope of MPLS-TP ([RFC5960], Section 3.1.1, paragraph 6).
93. パケットごとの等しいコストマルチパス（ECMP）負荷分散は現在、MPLS-TP（[RFC5960]、セクション3.1.1、パラグラフ6）の範囲外です。
94. Penultimate Hop Popping (PHP) must be disabled on MPLS-TP LSPs by default ([RFC5960], Section 3.1.1, paragraph 7).
94. Penultimate Hop Popping（PHP）は、デフォルトでMPLS-TP LSPで無効にする必要があります（[RFC5960]、セクション3.1.1、パラグラフ7）。
95. The MPLS-TP control plane must support both E-LSP (Explicitly TC-encoded-PSC LSP) and L-LSP (Label-Only-Inferred-PSC LSP) MPLS Diffserv modes as specified in [RFC3270], [RFC5462], and Section 3.3.2, paragraph 12 of [RFC5960].
95. MPLS-TPコントロールプレーンは、[RFC3270]、[RFC5462]、および[RFC5462]で指定されているように、E-LSP（明示的にTCエンコード-PSC LSP）とL-LSP（ラベルのみの有名-PSC LSP）MPLS Diffservモードの両方をサポートする必要があります。セクション3.3.2、[RFC5960]のパラグラフ12。
96. Both Single-Segment PWs (see [RFC3985]) and Multi-Segment PWs (see [RFC5659]) shall be supported by the MPLS-TP control plane. MPLS-TP shall use the definition of Multi-Segment PWs as defined by the IETF ([RFC5921], Section 3.4.4).
96. 単一セグメントPW（[RFC3985]を参照）とマルチセグメントPW（[RFC5659を参照]を参照）は、MPLS-TPコントロールプレーンによってサポートされるものとします。MPLS-TPは、IETF（[RFC5921]、セクション3.4.4）で定義されているように、マルチセグメントPWSの定義を使用するものとします。
97. The MPLS-TP control plane must support the control of PWs and their associated labels ([RFC5921], Section 3.4.4).
97. MPLS-TPコントロールプレーンは、PWSとそれに関連するラベルの制御をサポートする必要があります（[RFC5921]、セクション3.4.4）。
98. The MPLS-TP control plane must support network-layer clients, i.e., clients whose traffic is transported over an MPLS-TP network without the use of PWs ([RFC5921], Section 3.4.5).
98. MPLS-TP制御プレーンは、ネットワーク層クライアント、つまり、PWSを使用せずにMPLS-TPネットワークを介してトラフィックが輸送されるクライアント（[RFC5921]、セクション3.4.5）をサポートする必要があります。
a. The MPLS-TP control plane must support the use of network-layer protocol-specific LSPs and labels ([RFC5921], Section 3.4.5).
a. MPLS-TPコントロールプレーンは、ネットワーク層プロトコル固有のLSPおよびラベルの使用をサポートする必要があります（[RFC5921]、セクション3.4.5）。
b. The MPLS-TP control plane must support the use of a client-service-specific LSPs and labels ([RFC5921], Section 3.4.5).
b. MPLS-TPコントロールプレーンは、クライアントサービス固有のLSPとラベルの使用をサポートする必要があります（[RFC5921]、セクション3.4.5）。
99. The MPLS-TP control plane for LSPs must be based on the GMPLS control plane. More specifically, GMPLS RSVP-TE [RFC3473] and related extensions are used for LSP signaling, and GMPLS OSPF-TE [RFC5392] and ISIS-TE [RFC5316] are used for routing ([RFC5921], Section 3.9).
99. LSPのMPLS-TPコントロールプレーンは、GMPLSコントロールプレーンに基づいている必要があります。より具体的には、GMPLS RSVP-TE [RFC3473]および関連する拡張はLSPシグナル伝達に使用され、GMPLS OSPF-TE [RFC5392]およびISIS-TE [RFC5316]がルーティングに使用されます（[RFC5921]、セクション3.9）。
100. The MPLS-TP control plane for PWs must be based on the MPLS control plane for PWs, and more specifically, targeted LDP (T-LDP) [RFC4447] is used for PW signaling ([RFC5921], Section 3.9, paragraph 5).
100. PWSのMPLS-TPコントロールプレーンは、PWSのMPLS制御プレーンに基づいている必要があり、より具体的には、標的LDP（T-LDP）[RFC4447]はPWシグナル伝達に使用されます（[RFC5921]、セクション3.9、パラグラフ5）。
101. The MPLS-TP control plane must ensure its own survivability and be able to recover gracefully from failures and degradations. These include graceful restart and hot redundant configurations ([RFC5921], Section 3.9, paragraph 16).
101. MPLS-TPコントロールプレーンは、独自の生存性を確保し、障害や分解から優雅に回復できる必要があります。これらには、優雅な再起動とホット冗長構成（[RFC5921]、セクション3.9、パラグラフ16）が含まれます。
102. The MPLS-TP control plane must support linear, ring, and meshed protection schemes ([RFC5921], Section 3.12, paragraph 3).
102. MPLS-TPコントロールプレーンは、線形、リング、およびメッシュ化された保護スキームをサポートする必要があります（[RFC5921]、セクション3.12、パラグラフ3）。
103. The MPLS-TP control plane must support the control of SPMEs (hierarchical LSPs) for new or existing end-to-end LSPs ([RFC5921], Section 3.12, paragraph 7).
103. MPLS-TP制御面は、新規または既存のエンドツーエンドLSP（[RFC5921]、セクション3.12、パラグラフ7）のSPMES（階層LSP）の制御をサポートする必要があります。
The following additional requirements are based on [RFC5860] and [RFC6371]:
以下の追加要件は、[RFC5860]および[RFC6371]に基づいています。
104. The MPLS-TP control plane must support the capability to enable/disable OAM functions as part of service establishment ([RFC5860], Section 2.1.6, paragraph 1. Note that OAM functions are applicable regardless of the label stack depth (i.e., level of LSP hierarchy or PW) ([RFC5860], Section 2.1.1, paragraph 3).
104. MPLS-TPコントロールプレーンは、サービス確立の一部としてOAM機能を有効/無効にする機能をサポートする必要があります（[RFC5860]、セクション2.1.6、パラグラフ1. OAM関数はラベルスタックの深さに関係なく適用可能であることに注意してください（つまり、、LSP階層またはPWのレベル）（[RFC5860]、セクション2.1.1、パラグラフ3）。
105. The MPLS-TP control plane must support the capability to enable/disable OAM functions after service establishment. In such cases, the customer must not perceive service degradation as a result of OAM enabling/disabling ([RFC5860], Section 2.1.6, paragraphs 1 and 2).
105. MPLS-TP制御プレーンは、サービス施設後にOAM機能を有効/無効にする機能をサポートする必要があります。そのような場合、顧客は、OAMが有効化/無効化された結果としてサービスの劣化を認識してはなりません（[RFC5860]、セクション2.1.6、パラグラフ1および2）。
106. The MPLS-TP control plane must support dynamic control of any of the existing IP/MPLS and PW OAM protocols, e.g., LSP-Ping [RFC4379], MPLS-BFD [RFC5884], VCCV [RFC5085], and VCCV-BFD [RFC5885] ([RFC5860], Section 2.1.4, paragraph 2).
106. MPLS-TP制御面は、既存のIP/MPLSおよびPW OAMプロトコルの動的制御をサポートする必要があります。[RFC5885]（[RFC5860]、セクション2.1.4、パラグラフ2）。
107. The MPLS-TP control plane must allow for the ability to support experimental OAM functions. These functions must be disabled by default ([RFC5860], Section 2.2, paragraph 2).
107. MPLS-TPコントロールプレーンは、実験的なOAM機能をサポートする能力を可能にする必要があります。これらの関数は、デフォルトで無効にする必要があります（[RFC5860]、セクション2.2、パラグラフ2）。
108. The MPLS-TP control plane must support the choice of which (if any) OAM function(s) to use and to which PW, LSP or Section it applies ([RFC5860], Section 2.2, paragraph 3).
108. MPLS-TPコントロールプレーンは、使用する（もしあれば）OAM関数の選択と、それが適用されるPW、LSP、またはセクションの選択をサポートする必要があります（[RFC5860]、セクション2.2、パラグラフ3）。
109. The MPLS-TP control plane must allow (e.g., enable/disable) mechanisms that support the localization of faults and the notification of appropriate nodes ([RFC5860], Section 2.2.1, paragraph 1).
109. MPLS-TP制御面は、障害の局在化と適切なノードの通知（[RFC5860]、セクション2.2.1、パラグラフ1）をサポートするメカニズムを許可する必要があります（例：有効化/無効）。
110. The MPLS-TP control plane may support mechanisms that permit the service provider to be informed of a fault or defect affecting the service(s) it provides, even if the fault or defect is located outside of his domain ([RFC5860], Section 2.2.1, paragraph 2).
110. MPLS-TPコントロールプレーンは、障害または欠陥がドメインの外側に配置されていても、サービスに影響するサービスに影響を与える障害または欠陥をサービスプロバイダーに通知できるようにするメカニズムをサポートする場合があります（[RFC5860]、セクション2.2.1、パラグラフ2）。
111. Information exchange between various nodes involved in the MPLS-TP control plane should be reliable such that, for example, defects or faults are properly detected or that state changes are effectively known by the appropriate nodes ([RFC5860], Section 2.2.1, paragraph 3).
111. MPLS-TPコントロールプレーンに関与するさまざまなノード間の情報交換は、たとえば、欠陥または障害が適切に検出されるか、状態の変更が適切なノードによって効果的に知られているように信頼できる必要があります（[RFC5860]、セクション2.2.1、パラグラフ3）。
112. The MPLS-TP control plane must provide functionality to control an end point's ability to monitor the liveness of a PW, LSP, or Section ([RFC5860], Section 2.2.2, paragraph 1).
112. MPLS-TPコントロールプレーンは、PW、LSP、またはセクション（[RFC5860]、セクション2.2.2、パラグラフ1）の活性を監視するエンドポイントの能力を制御する機能を提供する必要があります。
113. The MPLS-TP control plane must provide functionality to control an end point's ability to determine whether or not it is connected to specific end point(s) by means of the expected PW, LSP, or Section ([RFC5860], Section 2.2.3, paragraph 1).
113. MPLS-TPコントロールプレーンは、予想されるPW、LSP、またはセクション（[RFC5860]、セクション2.2によって特定のエンドポイントに接続されているかどうかを判断するエンドポイントの能力を制御する機能を提供する必要があります。.3、パラグラフ1）。
a. The MPLS-TP control plane must provide mechanisms to control an end point's ability to perform this function proactively ([RFC5860], Section 2.2.3, paragraph 2).
a. MPLS-TPコントロールプレーンは、この関数を積極的に実行するエンドポイントの能力を制御するメカニズムを提供する必要があります（[RFC5860]、セクション2.2.3、パラグラフ2）。
b. The MPLS-TP control plane must provide mechanisms to control an end point's ability to perform this function on-demand ([RFC5860], Section 2.2.3, paragraph 3).
b. MPLS-TPコントロールプレーンは、この関数をオンデマンドで実行するエンドポイントの能力を制御するメカニズムを提供する必要があります（[RFC5860]、セクション2.2.3、パラグラフ3）。
114. The MPLS-TP control plane must provide functionality to control diagnostic testing on a PW, LSP or Section ([RFC5860], Section 2.2.5, paragraph 1).
114. MPLS-TPコントロールプレーンは、PW、LSP、またはセクション（[RFC5860]、セクション2.2.5、パラグラフ1）での診断テストを制御する機能を提供する必要があります。
a. The MPLS-TP control plane must provide mechanisms to control the performance of this function on-demand ([RFC5860], Section 2.2.5, paragraph 2).
a. MPLS-TPコントロールプレーンは、この関数のオンデマンド（[RFC5860]、セクション2.2.5、パラグラフ2）を制御するメカニズムを提供する必要があります。
115. The MPLS-TP control plane must provide functionality to enable an end point to discover the Intermediate Point(s) (if any) and end point(s) along a PW, LSP, or Section, and more generally to trace (record) the route of a PW, LSP, or Section ([RFC5860], Section 2.2.4, paragraph 1).
115. MPLS-TPコントロールプレーンは、PW、LSP、またはセクションに沿って中間点（S）とエンドポイント（s）を発見できるようにするための機能を提供する必要があります。）PW、LSP、またはセクション（[RFC5860]、セクション2.2.4、パラグラフ1）のルート。
a. The MPLS-TP control plane must provide mechanisms to control the performance of this function on-demand ([RFC5860], Section 2.2.4, paragraph 2).
a. MPLS-TPコントロールプレーンは、この関数のオンデマンド（[RFC5860]、セクション2.2.4、パラグラフ2）を制御するメカニズムを提供する必要があります。
116. The MPLS-TP control plane must provide functionality to enable an end point of a PW, LSP, or Section to instruct its associated end point(s) to lock the PW, LSP, or Section ([RFC5860], Section 2.2.6, paragraph 1).
116. MPLS-TPコントロールプレーンは、PW、LSP、またはセクションのエンドポイントを有効にする機能を提供し、関連するエンドポイント（S）にPW、LSP、またはセクション（[RFC5860]、セクション2.2をロックするよう指示する必要があります。6、パラグラフ1）。
a. The MPLS-TP control plane must provide mechanisms to control the performance of this function on-demand ([RFC5860], Section 2.2.6, paragraph 2).
a. MPLS-TPコントロールプレーンは、この関数のオンデマンド（[RFC5860]、セクション2.2.6、パラグラフ2）を制御するメカニズムを提供する必要があります。
117. The MPLS-TP control plane must provide functionality to enable an Intermediate Point of a PW or LSP to report, to an end point of that same PW or LSP, a lock condition indirectly affecting that PW or LSP ([RFC5860], Section 2.2.7, paragraph 1).
117. MPLS-TPコントロールプレーンは、PWまたはLSPの中間点が同じPWまたはLSPのエンドポイントに報告できるように機能を提供する必要があります。2.2.7、パラグラフ1）。
a. The MPLS-TP control plane must provide mechanisms to control the performance of this function proactively ([RFC5860], Section 2.2.7, paragraph 2).
a. MPLS-TP制御プレーンは、この関数のパフォーマンスを積極的に制御するメカニズムを提供する必要があります（[RFC5860]、セクション2.2.7、パラグラフ2）。
118. The MPLS-TP control plane must provide functionality to enable an Intermediate Point of a PW or LSP to report, to an end point of that same PW or LSP, a fault or defect condition affecting that PW or LSP ([RFC5860], Section 2.2.8, paragraph 1).
118. MPLS-TPコントロールプレーンは、PWまたはLSPの中間点が同じPWまたはLSPのエンドポイントに報告できるように機能を提供する必要があります。セクション2.2.8、パラグラフ1）。
a. The MPLS-TP control plane must provide mechanisms to control the performance of this function proactively ([RFC5860], Section 2.2.8, paragraph 2).
a. MPLS-TP制御プレーンは、この関数のパフォーマンスを積極的に制御するメカニズムを提供する必要があります（[RFC5860]、セクション2.2.8、パラグラフ2）。
119. The MPLS-TP control plane must provide functionality to enable an end point to report, to its associated end point, a fault or defect condition that it detects on a PW, LSP, or Section for which they are the end points ([RFC5860], Section 2.2.9, paragraph 1).
119. MPLS-TPコントロールプレーンは、関連するエンドポイント、PW、LSP、またはそれらがエンドポイントであるセクションで検出する障害または欠陥条件を報告できるように機能を提供する必要があります（[[]RFC5860]、セクション2.2.9、パラグラフ1）。
a. The MPLS-TP control plane must provide mechanisms to control the performance of this function proactively ([RFC5860], Section 2.2.9, paragraph 2).
a. MPLS-TP制御プレーンは、この関数のパフォーマンスを積極的に制御するメカニズムを提供する必要があります（[RFC5860]、セクション2.2.9、パラグラフ2）。
120. The MPLS-TP control plane must provide functionality to enable the propagation, across an MPLS-TP network, of information pertaining to a client defect or fault condition detected at an end point of a PW or LSP, if the client-layer mechanisms do not provide an alarm notification/propagation mechanism ([RFC5860], Section 2.2.10, paragraph 1).
120. MPLS-TPコントロールプレーンは、クライアントレイヤーメカニズムの場合、PWまたはLSPのエンドポイントで検出されたクライアントの欠陥または障害状態に関連する情報の伝播を有効にするための機能を提供する必要があります。アラーム通知/伝播メカニズムを提供しないでください（[RFC5860]、セクション2.2.10、パラグラフ1）。
a. The MPLS-TP control plane must provide mechanisms to control the performance of this function proactively ([RFC5860], Section 2.2.10, paragraph 2).
a. MPLS-TP制御プレーンは、この関数のパフォーマンスを積極的に制御するメカニズムを提供する必要があります（[RFC5860]、セクション2.2.10、パラグラフ2）。
121. The MPLS-TP control plane must provide functionality to enable the control of quantification of packet loss ratio over a PW, LSP, or Section ([RFC5860], Section 2.2.11, paragraph 1).
121. MPLS-TP制御面は、PW、LSP、またはセクション（[RFC5860]、セクション2.2.11、パラグラフ1）にわたってパケット損失比の定量化の制御を可能にする機能を提供する必要があります。
a. The MPLS-TP control plane must provide mechanisms to control the performance of this function proactively and on-demand ([RFC5860], Section 2.2.11, paragraph 4).
a. MPLS-TPコントロールプレーンは、この関数のパフォーマンスを積極的かつオンデマンド制御するメカニズムを提供する必要があります（[RFC5860]、セクション2.2.11、パラグラフ4）。
122. The MPLS-TP control plane must provide functionality to control the quantification and reporting of the one-way, and if appropriate, the two-way, delay of a PW, LSP, or Section ([RFC5860], Section 2.2.12, paragraph 1).
122. MPLS-TPコントロールプレーンは、一方向の定量化と報告を制御する機能を提供する必要があります。必要に応じて、双方向、PW、LSP、またはセクションの遅延（[RFC5860]、セクション2.2.12、 段落1）。
a. The MPLS-TP control plane must provide mechanisms to control the performance of this function proactively and on-demand ([RFC5860], Section 2.2.12, paragraph 6).
a. MPLS-TPコントロールプレーンは、この関数のパフォーマンスを積極的かつオンデマンド制御するメカニズムを提供する必要があります（[RFC5860]、セクション2.2.12、パラグラフ6）。
123. The MPLS-TP control plane must support the configuration of OAM functional components that include Maintenance Entities (MEs) and Maintenance Entity Groups (MEGs) as instantiated in MEPs, MIPs, and SPMEs ([RFC6371], Section 3.6).
123. MPLS-TP制御面は、MEP、MIP、およびSPME（[RFC6371]、セクション3.6）にインスタンス化されたメンテナンスエンティティ（MES）およびメンテナンスエンティティグループ（MEG）を含むOAM機能コンポーネントの構成をサポートする必要があります。
124. For dynamically established transport paths, the control plane must support the configuration of OAM operations ([RFC6371], Section 5).
124.動的に確立された輸送パスの場合、制御面はOAM操作の構成をサポートする必要があります（[RFC6371]、セクション5）。
a. The MPLS-TP control plane must provide mechanisms to configure proactive monitoring for a MEG at, or after, transport path creation time.
a. MPLS-TPコントロールプレーンは、輸送パスの作成時間でのMEGのプロアクティブ監視を構成するためのメカニズムを提供する必要があります。
b. The MPLS-TP control plane must provide mechanisms to configure the operational characteristics of in-band measurement transactions (e.g., Connectivity Verification (CV), Loss Measurement (LM), etc.) at MEPs (associated with a transport path).
b. MPLS-TP制御プレーンは、MEPS（輸送経路に関連付けられている）で、帯域測定トランザクション（例：接続検証（CV）、損失測定（LM）など）の運用特性を構成するメカニズムを提供する必要があります。
c. The MPLS-TP control plane may provide mechanisms to configure server-layer event reporting by intermediate nodes.
c. MPLS-TPコントロールプレーンは、中間ノードでサーバー層イベントレポートを構成するメカニズムを提供する場合があります。
d. The MPLS-TP control plane may provide mechanisms to configure the reporting of measurements resulting from proactive monitoring.
d. MPLS-TPコントロールプレーンは、プロアクティブモニタリングに起因する測定の報告を構成するメカニズムを提供する場合があります。
125. The MPLS-TP control plane must support the control of the loss of continuity (LOC) traffic block consequent action ([RFC6371], Section 5.1.2, paragraph 4).
125. MPLS-TPコントロールプレーンは、連続性の喪失（LOC）トラフィックブロックの結果として生じるアクションの制御をサポートする必要があります（[RFC6371]、セクション5.1.2、パラグラフ4）。
126. For dynamically established transport paths that have a proactive Continuity Check and Connectivity Verification (CC-V) function enabled, the control plane must support the signaling of the following MEP configuration information ([RFC6371], Section 5.1.3):
126.プロアクティブな連続性チェックと接続検証（CC-V）関数が有効になっている動的に確立された輸送パスの場合、コントロールプレーンは、次のMEP構成情報（[RFC6371]、セクション5.1.3）の信号をサポートする必要があります。
a. The MPLS-TP control plane must provide mechanisms to configure the MEG identifier to which the MEP belongs.
a. MPLS-TPコントロールプレーンは、MEPが属するMEG識別子を構成するメカニズムを提供する必要があります。
b. The MPLS-TP control plane must provide mechanisms to configure a MEP's own identity inside a MEG.
b. MPLS-TPコントロールプレーンは、MEG内でMEP独自のアイデンティティを構成するメカニズムを提供する必要があります。
c. The MPLS-TP control plane must provide mechanisms to configure the list of the other MEPs in the MEG.
c. MPLS-TPコントロールプレーンは、MEGの他のMEPのリストを構成するメカニズムを提供する必要があります。
d. The MPLS-TP control plane must provide mechanisms to configure the CC-V transmission rate / reception period (covering all application types).
d. MPLS-TPコントロールプレーンは、CC-V送信速度 /受信期間を構成するためのメカニズムを提供する必要があります（すべてのアプリケーションタイプをカバー）。
127. The MPLS-TP control plane must provide mechanisms to configure the generation of Alarm Indication Signal (AIS) packets for each MEG ([RFC6371], Section 5.3, paragraph 9).
127. MPLS-TP制御面は、各MEG（[RFC6371]、セクション5.3、パラグラフ9）のアラーム表示信号（AIS）パケットの生成を構成するメカニズムを提供する必要があります。
128. The MPLS-TP control plane must provide mechanisms to configure the generation of Lock Report (LKR) packets for each MEG ([RFC6371], Section 5.4, paragraph 9).
128. MPLS-TPコントロールプレーンは、各MEG（[RFC6371]、セクション5.4、パラグラフ9）の生成ロックレポート（LKR）パケットを構成するメカニズムを提供する必要があります。
129. The MPLS-TP control plane must provide mechanisms to configure the use of proactive Packet Loss Measurement (LM), and the transmission rate and Per-Hop Behavior (PHB) class associated with the LM OAM packets originating from a MEP ([RFC6371], Section 5.5.1, paragraph 1).
129. MPLS-TPコントロールプレーンは、プロアクティブパケット損失測定（LM）の使用を構成するメカニズムを提供する必要があります。]、セクション5.5.1、パラグラフ1）。
130. The MPLS-TP control plane must provide mechanisms to configure the use of proactive Packet Delay Measurement (DM), and the transmission rate and PHB class associated with the DM OAM packets originating from a MEP ([RFC6371], Section 5.6.1, paragraph 1).
130. MPLS-TPコントロールプレーンは、MEP（[RFC6371]、セクション5.6.1に由来するDM OAMパケットに関連するプロアクティブパケット遅延測定（DM）、および伝送速度とPHBクラスの使用を構成するメカニズムを提供する必要があります。、 段落1）。
131. The MPLS-TP control plane must provide mechanisms to configure the use of Client Failure Indication (CFI), and the transmission rate and PHB class associated with the CFI OAM packets originating from a MEP ([RFC6371], Section 5.7.1, paragraph 1).
131. MPLS-TPコントロールプレーンは、クライアント障害表示（CFI）の使用を構成するメカニズムを提供する必要があります（CFI）、およびMEPに由来するCFI OAMパケット（[RFC6371]、セクション5.7.1、段落1）。
132. The MPLS-TP control plane should provide mechanisms to control the use of on-demand CV packets ([RFC6371], Section 6.1).
132. MPLS-TP制御面は、オンデマンドCVパケットの使用を制御するメカニズムを提供する必要があります（[RFC6371]、セクション6.1）。
a. The MPLS-TP control plane should provide mechanisms to configure the number of packets to be transmitted/received in each burst of on-demand CV packets and their packet size ([RFC6371], Section 6.1.1, paragraph 1).
a. MPLS-TPコントロールプレーンは、オンデマンドCVパケットの各バーストとそのパケットサイズ（[RFC6371]、セクション6.1.1、パラグラフ1）で送信/受信するパケットの数を構成するメカニズムを提供する必要があります。
b. When an on-demand CV packet is used to check connectivity toward a target MIP, the MPLS-TP control plane should provide mechanisms to configure the number of hops to reach the target MIP ([RFC6371], Section 6.1.1, paragraph 2).
b. オンデマンドCVパケットを使用してターゲットMIPに向かって接続を確認する場合、MPLS-TPコントロールプレーンは、ターゲットMIPに到達するホップ数を構成するメカニズムを提供する必要があります（[RFC6371]、セクション6.1.1、パラグラフ2）。
c. The MPLS-TP control plane should provide mechanisms to configure the PHB of on-demand CV packets ([RFC6371], Section 6.1.1, paragraph 3).
c. MPLS-TPコントロールプレーンは、オンデマンドCVパケットのPHBを構成するメカニズムを提供する必要があります（[RFC6371]、セクション6.1.1、パラグラフ3）。
133. The MPLS-TP control plane should provide mechanisms to control the use of on-demand LM, including configuration of the beginning and duration of the LM procedures, the transmission rate, and PHB associated with the LM OAM packets originating from a MEP ([RFC6371], Section 6.2.1).
133. MPLS-TPコントロールプレーンは、LM手順の開始と持続時間の構成、伝送速度、およびMEPから発生するLM OAMパケットに関連するPHBを含む、オンデマンドLMの使用を制御するメカニズムを提供する必要があります（MEPからのLM OAMパケット（[RFC6371]、セクション6.2.1）。
134. The MPLS-TP control plane should provide mechanisms to control the use of throughput estimation ([RFC6371], Section 6.3.1).
134. MPLS-TP制御面は、スループット推定の使用を制御するメカニズムを提供する必要があります（[RFC6371]、セクション6.3.1）。
135. The MPLS-TP control plane should provide mechanisms to control the use of on-demand DM, including configuration of the beginning and duration of the DM procedures, the transmission rate, and PHB associated with the DM OAM packets originating from a MEP ([RFC6371], Section 6.5.1).
135. MPLS-TPコントロールプレーンは、DM手順の開始と持続時間の構成、伝送速度、およびMEPから発生するDM OAMパケットに関連付けられたPHBを含む、オンデマンドDMの使用を制御するメカニズムを提供する必要があります（MEPからのDM OAMパケット（[RFC6371]、セクション6.5.1）。
There are no specific MPLS-TP control-plane security requirements. The existing framework for MPLS and GMPLS security is documented in [RFC5920], and that document applies equally to MPLS-TP.
特定のMPLS-TPコントロールプレーンセキュリティ要件はありません。MPLSおよびGMPLSセキュリティの既存のフレームワークは[RFC5920]に文書化されており、そのドキュメントはMPLS-TPに等しく適用されます。
The following are requirements based on [RFC6370]:
以下は[RFC6370]に基づく要件です。
136. The MPLS-TP control plane must support MPLS-TP point-to-point tunnel identifiers of the forms defined in Section 5.1 of [RFC6370].
136. MPLS-TP制御面は、[RFC6370]のセクション5.1で定義されているフォームのMPLS-TPポイントツーポイントトンネル識別子をサポートする必要があります。
137. The MPLS-TP control plane must support MPLS-TP LSP identifiers of the forms defined in Section 5.2 of [RFC6370], and the mappings to GMPLS as defined in Section 5.3 of [RFC6370].
137. MPLS-TP制御面は、[RFC6370]のセクション5.2で定義されているフォームのMPLS-TP LSP識別子、および[RFC6370]のセクション5.3で定義されているGMPLSへのマッピングをサポートする必要があります。
138. The MPLS-TP control plane must support pseudowire path identifiers of the form defined in Section 6 of [RFC6370].
138. MPLS-TPコントロールプレーンは、[RFC6370]のセクション6で定義されているフォームの擬似動物経路識別子をサポートする必要があります。
139. The MPLS-TP control plane must support MEG_IDs for LSPs and PWs as defined in Section 7.1.1 of [RFC6370].
139. MPLS-TP制御面は、[RFC6370]のセクション7.1.1で定義されているように、LSPとPWSのMEG_IDSをサポートする必要があります。
140. The MPLS-TP control plane must support IP-compatible MEG_IDs for LSPs and PWs as defined in Section 7.1.2 of [RFC6370].
140. MPLS-TPコントロールプレーンは、[RFC6370]のセクション7.1.2で定義されているように、LSPおよびPWSのIP互換MEG_IDSをサポートする必要があります。
141. The MPLS-TP control plane must support MEP_IDs for LSPs and PWs of the forms defined in Section 7.2.1 of [RFC6370].
141. MPLS-TP制御面は、[RFC6370]のセクション7.2.1で定義されているフォームのLSPおよびPWSのMEP_IDSをサポートする必要があります。
142. The MPLS-TP control plane must support IP-based MEP_IDs for MPLS-TP LSP of the forms defined in Section 7.2.2.1 of [RFC6370].
142. MPLS-TPコントロールプレーンは、[RFC6370]のセクション7.2.2.1で定義されているフォームのMPLS-TP LSPのIPベースのMEP_IDSをサポートする必要があります。
143. The MPLS-TP control plane must support IP-based MEP_IDs for Pseudowires of the form defined in Section 7.2.2.2 of [RFC6370].
143. MPLS-TPコントロールプレーンは、[RFC6370]のセクション7.2.2.2で定義されているフォームの擬似動物のIPベースのMEP_IDSをサポートする必要があります。
The data-plane relationship between PWs and LSPs is inherited from standard MPLS and is reviewed in the MPLS-TP framework [RFC5921]. Likewise, the control-plane relationship between PWs and LSPs is inherited from standard MPLS. This relationship is reviewed in this document. The relationship between the PW and LSP control planes in MPLS-TP is the same as the relationship found in the PWE3 Maintenance Reference Model as presented in the PWE3 architecture; see Figure 6 of [RFC3985]. The PWE3 architecture [RFC3985] states: "The PWE3 protocol-layering model is intended to minimize the differences between PWs operating over different PSN types". Additionally, PW control (maintenance) takes place separately from LSP signaling. [RFC4447] and [MS-PW-DYNAMIC] provide such extensions for the use of LDP as the control plane for PWs. This control can provide PW control without providing LSP control.
PWSとLSP間のデータプレーン関係は、標準MPLSから継承され、MPLS-TPフレームワーク[RFC5921]でレビューされています。同様に、PWSとLSPの間のコントロール面の関係は、標準のMPLSから継承されます。この関係は、このドキュメントでレビューされています。MPLS-TPのPWとLSPコントロールプレーンの関係は、PWE3アーキテクチャに示されているPWE3メンテナンス参照モデルに見られる関係と同じです。[RFC3985]の図6を参照してください。PWE3アーキテクチャ[RFC3985]は次のように述べています。「PWE3プロトコルレイアリングモデルは、異なるPSNタイプで動作するPWS間の違いを最小限に抑えることを目的としています」。さらに、PWコントロール（メンテナンス）は、LSPシグナル伝達とは別に行われます。[RFC4447]および[MS-PW-Dynamic]は、PWSのコントロールプレーンとしてLDPを使用するためのこのような拡張機能を提供します。この制御は、LSP制御を提供せずにPW制御を提供できます。
In the context of MPLS-TP, LSP tunnel signaling is provided via GMPLS RSVP-TE. While RSVP-TE could be extended to support PW control much as LDP was extended in [RFC4447], such extensions are out of scope of this document. This means that the control of PWs and LSPs will operate largely independently. The main coordination between LSP and PW control will occur within the nodes that terminate PWs or PW segments. See Section 5.3.2 for an additional discussion on such coordination.
MPLS-TPのコンテキストでは、LSPトンネルシグナル伝達はGMPLS RSVP-TEを介して提供されます。[RFC4447]でLDPが拡張されたため、PW制御をサポートするためにRSVP-TEを拡張することができますが、このような拡張はこのドキュメントの範囲外です。これは、PWSとLSPの制御がほぼ独立して動作することを意味します。LSPコントロールとPW制御の主な調整は、PWSまたはPWセグメントを終了するノード内で発生します。このような調整に関する追加の議論については、セクション5.3.2を参照してください。
It is worth noting that the control planes for PWs and LSPs may be used independently, and that one may be employed without the other. This translates into four possible scenarios: (1) no control plane is employed; (2) a control plane is used for both LSPs and PWs; (3) a control plane is used for LSPs, but not PWs; (4) a control plane is used for PWs, but not LSPs.
PWSおよびLSPのコントロールプレーンは独立して使用され、一方が他方なしで使用される可能性があることは注目に値します。これは、4つの可能なシナリオに変換されます。（1）制御面は採用されていません。（2）制御面は、LSPとPWの両方に使用されます。（3）制御面はLSPに使用されますが、PWSでは使用されません。（4）コントロールプレーンはPWSに使用されますが、LSPでは使用されません。
The PW and LSP control planes, collectively, must satisfy the MPLS-TP control-plane requirements reviewed in this document. When client services are provided directly via LSPs, all requirements must be satisfied by the LSP control plane. When client services are provided via PWs, the PW and LSP control planes can operate in combination, and some functions may be satisfied via the PW control plane while others are provided to PWs by the LSP control plane. For
PWおよびLSPコントロールプレーンは、集合的に、このドキュメントでレビューされたMPLS-TP制御プレーン要件を満たす必要があります。クライアントサービスがLSPを介して直接提供される場合、すべての要件がLSPコントロールプレーンによって満たされる必要があります。クライアントサービスがPWSを介して提供されると、PWとLSPコントロールプレーンは組み合わせて動作し、PWコントロールプレーンを介して一部の機能が満たされ、他の機能はLSPコントロールプレーンによってPWSに提供されます。為に
example, to support the recovery functions described in [RFC6372], this document focuses on the control of the recovery functions at the LSP layer. PW-based recovery is under development at this time and may be used once defined.
たとえば、[RFC6372]で説明されている回復関数をサポートするために、このドキュメントはLSP層での回復関数の制御に焦点を当てています。PWベースの回復は現時点では開発中であり、定義されると使用できます。
MPLS-TP uses Generalized MPLS (GMPLS) signaling and routing, see [RFC3945], as the control plane for LSPs. The GMPLS control plane is based on the MPLS control plane. GMPLS includes support for MPLS labeled data and transport data planes. GMPLS includes most of the transport-centric features required to support MPLS-TP LSPs. This section will first review the features of GMPLS relevant to MPLS-TP LSPs, then identify how specific requirements can be met using existing GMPLS functions, and will conclude with extensions that are anticipated to support the remaining MPLS-TP control-plane requirements.
MPLS-TPは、一般化されたMPLS（GMPLS）シグナル伝達とルーティングを使用します。LSPのコントロールプレーンとして[RFC3945]を参照してください。GMPLSコントロールプレーンは、MPLSコントロールプレーンに基づいています。GMPLSには、データラベル付きのMPLSおよび輸送データプレーンのサポートが含まれています。GMPLには、MPLS-TP LSPをサポートするために必要な輸送中心のほとんどの機能が含まれます。このセクションでは、最初にMPLS-TP LSPに関連するGMPLSの機能を確認し、次に既存のGMPLS関数を使用して特定の要件をどのように満たすことができるかを特定し、残りのMPLS-TPコントロールプレーン要件をサポートすることが予想される拡張機能で終了します。
This section reviews how existing GMPLS functions can be applied to MPLS-TP.
このセクションでは、既存のGMPLS関数をMPLS-TPに適用する方法を確認します。
GMPLS supports both in-band and out-of-band control. The terms "in-band" and "out-of-band", in the context of this document, refer to the relationship of the control plane relative to the management and data planes. The terms may be used to refer to the control plane independent of the management plane, or to both of them in concert. The remainder of this section describes the relationship of the control plane to the management and data planes.
GMPLSは、インバンドおよびバンド外の両方のコントロールをサポートします。このドキュメントのコンテキストでの「インバンド」および「バンド外」という用語は、管理プレーンとデータプレーンに対する制御プレーンの関係を参照しています。この用語は、管理プレーンとは無関係に、またはコンサートで両方のコントロールプレーンを参照するために使用できます。このセクションの残りの部分では、管理プレーンと管理面とデータ面との関係について説明します。
There are multiple uses of both terms "in-band" and "out-of-band". The terms may relate to a channel, a path, or a network. Each of these can be used independently or in combination. Briefly, some typical usage of the terms is as follows:
「インバンド」と「バンド外」の両方の用語の複数の用途があります。用語は、チャネル、パス、またはネットワークに関連する場合があります。これらのそれぞれは、独立してまたは組み合わせて使用できます。簡単に言えば、用語の典型的な使用法は次のとおりです。
o In-band This term is used to refer to cases where control-plane traffic is sent in the same communication channel used to transport associated user data or management traffic. IP, MPLS, and Ethernet networks are all examples where control traffic is typically sent in-band with the data traffic. An example of this case in the context of MPLS-TP is where control-plane traffic is sent via the MPLS Generic Associated Channel (G-ACh), see [RFC5586], using the same LSP as controlled user traffic.
o インバンドこの用語は、関連するユーザーデータまたは管理トラフィックの輸送に使用される同じ通信チャネルでコントロールプレーントラフィックが送信される場合を指すために使用されます。IP、MPLS、およびイーサネットネットワークはすべて、コントロールトラフィックが通常、データトラフィックでバンド内で送信される例です。MPLS-TPのコンテキストでのこのケースの例は、制御されたユーザートラフィックと同じLSPを使用して、[RFC5586]を参照して、[RFC5586]を参照して、MPLSジェネリック関連チャネル（G-CHACH）を介してコントロールプレーントラフィックが送信される場所です。
o Out-of-band, in-fiber (same physical connection) This term is used to refer to cases where control-plane traffic is sent using a different communication channel from the associated data or management traffic, and the control communication channel resides in the same fiber as either the management or data traffic. An example of this case in the context of MPLS-TP is where control-plane traffic is sent via the G-ACh using a dedicated LSP on the same link (interface) that carries controlled user traffic.
o 帯域外の繊維（同じ物理的接続）この用語は、関連するデータまたは管理トラフィックから異なる通信チャネルを使用してコントロールプレーントラフィックが送信され、制御通信チャネルが存在する場合を指すために使用されます。管理またはデータトラフィックのいずれかと同じファイバー。MPLS-TPのコンテキストでのこのケースの例は、制御されたユーザートラフィックを運ぶ同じリンク（インターフェイス）上の専用LSPを使用して、G-achを介してコントロールプレーントラフィックが送信される場所です。
o Out-of-band, aligned topology This term is used to refer to the cases where control-plane traffic is sent using a different communication channel from the associated data or management traffic, and the control traffic follows the same node-to-node path as either the data or management traffic.
o 帯域外の整列トポロジこの用語は、関連するデータまたは管理トラフィックから異なる通信チャネルを使用してコントロールプレーントラフィックが送信され、コントロールトラフィックが同じノードからノードへのパスに従う場合を指すために使用されます。データまたは管理トラフィックのいずれか。
Such topologies are usually supported using a parallel fiber or other configurations where multiple data channels are available and one is (dynamically) selected as the control channel. An example of this case in the context of MPLS-TP is where control-plane traffic is sent along the same nodal path, but not necessarily the same links (interfaces), as the corresponding controlled user traffic.
このようなトポロジは通常、複数のデータチャネルが利用可能になり、制御チャネルとして（動的に）選択される並列ファイバーまたはその他の構成を使用してサポートされます。MPLS-TPのコンテキストでのこのケースの例は、対応する制御されたユーザートラフィックと同じノードパス（インターフェイス）と同じノードパスに沿ってコントロールプレーントラフィックが送信される場所です。
o Out-of-band, independent topology This term is used to refer to the cases where control-plane traffic is sent using a different communication channel from the associated data or management traffic, and the control traffic may follow a path that is completely independent of the data traffic.
o 帯域外の独立トポロジこの用語は、関連するデータまたは管理トラフィックから異なる通信チャネルを使用してコントロールプレーントラフィックが送信され、制御トラフィックが完全に独立したパスに従うことができる場合を指すために使用されます。データトラフィック。
Such configurations are a superset of the other cases and do not preclude the use of in-fiber or aligned topology links, but alignment is not required. An example of this case in the context of MPLS-TP is where control-plane traffic is sent between controlling nodes using any available path and links, completely without regard for the path(s) taken by corresponding management or user traffic.
このような構成は、他のケースのスーパーセットであり、繊維またはアラインドトポロジリンクの使用を排除するものではありませんが、アラインメントは必要ありません。MPLS-TPのコンテキストでのこのケースの例は、対応する管理またはユーザートラフィックによって取られたパスに関係なく、利用可能なパスとリンクを使用して制御ノード間でコントロールプレーントラフィックが送信される場所です。
In the context of MPLS-TP requirements, requirement 14 (see Section 2 above) can be met using out-of-band in-fiber or aligned topology types of control. Requirement 15 can only be met by using out-of-band, independent topology. G-ACh is likely to be used extensively in MPLS-TP networks to support the MPLS-TP control (and management) planes.
MPLS-TP要件のコンテキストでは、要件14（上記のセクション2を参照）を満たすことができます。要件15は、帯域外の独立したトポロジを使用することによってのみ満たすことができます。G-achは、MPLS-TPコントロール（および管理）平面をサポートするために、MPLS-TPネットワークで広く使用される可能性があります。
MPLS-TP reuses and supports the addressing mechanisms supported by MPLS. The MPLS-TP identifiers document (see [RFC6370]) provides additional context on how IP addresses are used within MPLS-TP. MPLS, and consequently MPLS-TP, uses the IPv4 and IPv6 address families to identify MPLS-TP nodes by default for network management and signaling purposes. The address spaces and neighbor adjacencies in the control, management, and data planes used in an MPLS-TP network may be completely separated or combined at the discretion of an MPLS-TP operator and based on the equipment capabilities of a vendor. The separation of the control and management planes from the data plane allows each plane to be independently addressable. Each plane may use addresses that are not mutually reachable, e.g., it is likely that the data plane will not be able to reach an address from the management or control planes and vice versa. Each plane may also use a different address family. It is even possible to reuse addresses in each plane, but this is not recommended as it may lead to operational confusion. As previously mentioned, the G-ACh mechanism defined in [RFC5586] is expected to be used extensively in MPLS-TP networks to support the MPLS-TP control (and management) planes.
MPLS-TPは、MPLSによってサポートされるアドレス指定メカニズムを再利用およびサポートします。 MPLS-TP識別子ドキュメント（[RFC6370]を参照）は、MPLS-TP内でIPアドレスの使用方法に関する追加のコンテキストを提供します。 MPLS、およびその結果、MPLS-TPは、IPv4およびIPv6アドレスファミリを使用して、ネットワーク管理とシグナリングの目的でデフォルトでMPLS-TPノードを特定します。 MPLS-TPネットワークで使用される制御、管理、およびデータプレーンのアドレススペースと近隣の隣接は、MPLS-TPオペレーターの裁量で、およびベンダーの機器機能に基づいて完全に分離または組み合わせることができます。データプレーンからの制御および管理面を分離すると、各平面が独立してアドレス指定できるようになります。各飛行機は、相互に到達できないアドレスを使用する場合があります。たとえば、データプレーンが管理プレーンまたはコントロールプレーンの住所に到達できず、その逆も同様です。各飛行機は、別のアドレスファミリを使用することもあります。各平面でアドレスを再利用することさえ可能ですが、これは運用上の混乱につながる可能性があるため推奨されません。前述のように、[RFC5586]で定義されているG-CHACHメカニズムは、MPLS-TPコントロール（および管理）平面をサポートするためにMPLS-TPネットワークで広く使用されると予想されます。
Routing support for MPLS-TP LSPs is based on GMPLS routing. GMPLS routing builds on TE routing and has been extended to support multiple switching technologies per [RFC3945] and [RFC4202] as well as multiple levels of packet switching within a single network. IS-IS extensions for GMPLS are defined in [RFC5307] and [RFC5316], which build on the TE extensions to IS-IS defined in [RFC5305]. OSPF extensions for GMPLS are defined in [RFC4203] and [RFC5392], which build on the TE extensions to OSPF defined in [RFC3630]. The listed RFCs should be viewed as a starting point rather than a comprehensive list as there are other IS-IS and OSPF extensions, as defined in IETF RFCs, that can be used within an MPLS-TP network.
MPLS-TP LSPのルーティングサポートは、GMPLSルーティングに基づいています。GMPLSルーティングはTEルーティングに基づいて構築されており、[RFC3945]および[RFC4202]ごとに複数のスイッチングテクノロジーをサポートし、単一のネットワーク内で複数のレベルのパケットスイッチングをサポートしています。GMPLのIS拡張機能は[RFC5307]および[RFC5316]で定義されており、[RFC5305]で定義されているIS-I-I-I-ISのTE拡張機能に基づいています。GMPLのOSPF拡張は[RFC4203]および[RFC5392]で定義されており、[RFC3630]で定義されたOSPFのTE拡張機能に基づいています。リストされているRFCは、MPLS-TPネットワーク内で使用できるIETF RFCSで定義されている他のIS-ISおよびOSPF拡張機能があるため、包括的なリストではなく出発点として表示する必要があります。
Both MPLS and GMPLS allow for traffic engineering and constraint-based path computation. MPLS path computation provides paths for MPLS-TE unidirectional P2P and P2MP LSPs. GMPLS path computation adds bidirectional LSPs, explicit recovery path computation, as well as support for the other functions discussed in this section.
MPLとGMPLの両方が、トラフィックエンジニアリングと制約ベースのパス計算を可能にします。MPLSパス計算は、MPLS-TE単方向P2PおよびP2MP LSPのパスを提供します。GMPLSパス計算により、双方向LSP、明示的な回復パス計算、およびこのセクションで説明した他の機能のサポートが追加されます。
Both MPLS and GMPLS path computation allow for the restriction of path selection based on the use of Explicit Route Objects (EROs) and other LSP attributes; see [RFC3209] and [RFC3473]. In all cases, no
MPLSとGMPLSパス計算の両方により、明示的なルートオブジェクト（ERO）およびその他のLSP属性の使用に基づいて、パス選択の制限が可能になります。[RFC3209]および[RFC3473]を参照してください。すべての場合において、いいえ
specific algorithm is standardized by the IETF. This is anticipated to continue to be the case for MPLS-TP LSPs.
特定のアルゴリズムは、IETFによって標準化されています。これは、MPLS-TP LSPの場合も続くと予想されています。
Path Computation Element (PCE)-based approaches, see [RFC4655], may be used for path computation of a GMPLS LSP, and consequently an MPLS-TP LSP, across domains and in a single domain. In cases where PCE is used, the PCE Communication Protocol (PCEP), see [RFC5440], will be used to communicate PCE-related requests and responses. MPLS-TP-specific extensions to PCEP are currently out of scope of the MPLS-TP project and this document.
パス計算要素（PCE）ベースのアプローチ[RFC4655]を参照して、GMPLS LSPのパス計算に使用でき、その結果、ドメイン全体および単一ドメイン内のMPLS-TP LSPのパス計算に使用できます。PCEが使用される場合、PCE通信プロトコル（PCEP）[RFC5440]を参照して、PCE関連のリクエストと応答を通信するために使用されます。PCEPへのMPLS-TP固有の拡張は現在、MPLS-TPプロジェクトとこのドキュメントの範囲外です。
GMPLS signaling is defined in [RFC3471] and [RFC3473] and is based on RSVP-TE [RFC3209]. Constraint-based Routed LDP (CR-LDP) GMPLS (see [RFC3472]) is no longer under active development within the IETF, i.e., it is deprecated (see [RFC3468]) and must not be used for MPLS nor MPLS-TP consequently. In general, all RSVP-TE extensions that apply to MPLS may also be used for GMPLS and consequently MPLS-TP. Most notably, this includes support for P2MP signaling as defined in [RFC4875].
GMPLSシグナル伝達は[RFC3471]および[RFC3473]で定義され、RSVP-TE [RFC3209]に基づいています。制約ベースのルーティングLDP（CR-LDP）GMPLS（[RFC3472]を参照）は、IETF内で積極的に開発されなくなりました。。一般に、MPLSに適用されるすべてのRSVP-TE拡張機能は、GMPLSおよびその結果、MPLS-TPにも使用できます。最も注目すべきは、これには[RFC4875]で定義されているP2MPシグナル伝達のサポートが含まれます。
GMPLS signaling includes a number of MPLS-TP required functions -- notably, support for out-of-band control, bidirectional LSPs, and independent control- and data-plane fault management. There are also numerous other GMPLS and MPLS extensions that can be used to provide specific functions in MPLS-TP networks. Specific references are provided below.
GMPLSシグナル伝達には、多くのMPLS-TPが必要な関数、特にバンド外の制御、双方向LSP、および独立した制御およびデータ面障害管理のサポートが含まれます。また、MPLS-TPネットワークで特定の機能を提供するために使用できる他の多くのGMPLSおよびMPLS拡張機能もあります。特定の参照を以下に示します。
Support for unnumbered links (i.e., links that do not have IP addresses) is permitted in MPLS-TP and its usage is at the discretion of the network operator. Support for unnumbered links is included for routing using OSPF [RFC4203] and IS-IS [RFC5307], and for signaling in [RFC3477].
MPLS-TPでは、番号のないリンク（つまり、IPアドレスを持たないリンク）のサポートが許可されており、その使用法はネットワークオペレーターの裁量で行われます。USPF [RFC4203]およびIS-IS [RFC5307]を使用したルーティング、および[RFC3477]のシグナル伝達には、番号のないリンクのサポートが含まれています。
Link bundling provides a local construct that can be used to improve scaling of TE routing when multiple data links are shared between node pairs. Link bundling for MPLS and GMPLS networks is defined in [RFC4201]. Link bundling may be used in MPLS-TP networks, and its use is at the discretion of the network operator.
Link Bundlingは、複数のデータリンクがノードペア間で共有されたときにTEルーティングのスケーリングを改善するために使用できるローカルコンストラクトを提供します。MPLSおよびGMPLSネットワークのリンクバンドリングは、[RFC4201]で定義されています。リンクバンドリングはMPLS-TPネットワークで使用される場合があり、その使用はネットワークオペレーターの裁量で行われます。
This section reuses text from [RFC6107].
このセクションでは、[RFC6107]からテキストを再利用します。
[RFC3031] describes how MPLS labels may be stacked so that LSPs may be nested with one LSP running through another. This concept of hierarchical LSPs (H-LSPs) is formalized in [RFC4206] with a set of protocol mechanisms for the establishment of a hierarchical LSP that can carry one or more other LSPs.
[RFC3031]は、MPLSラベルを積み重ねる方法を説明して、LSPが1つのLSPを別のLSPを実行してネストすることができるようにします。階層LSP（H-LSP）のこの概念は、[RFC4206]で形式化されており、1つ以上の他のLSPを運ぶことができる階層LSPの確立のための一連のプロトコルメカニズムがあります。
[RFC4206] goes on to explain that a hierarchical LSP may carry other LSPs only according to their switching types. This is a function of the way labels are carried. In a packet switch capable network, the hierarchical LSP can carry other packet switch capable LSPs using the MPLS label stack.
[RFC4206]さらに、階層的なLSPは、スイッチングタイプに従って他のLSPSのみを運ぶ可能性があることを説明しています。これは、ラベルが運ばれる方法の関数です。パケットスイッチ対応ネットワークでは、階層LSPは、MPLSラベルスタックを使用して他のパケットスイッチ対応LSPを運ぶことができます。
Signaling mechanisms defined in [RFC4206] allow a hierarchical LSP to be treated as a single hop in the path of another LSP. This mechanism is also sometimes known as "non-adjacent signaling", see [RFC4208].
[RFC4206]で定義されているシグナル伝達メカニズムにより、階層LSPを別のLSPの経路で単一のホップとして扱うことができます。このメカニズムは、「非隣接シグナル伝達」としても知られていることもあります。[RFC4208]を参照してください。
A Forwarding Adjacency (FA) is defined in [RFC4206] as a data link created from an LSP and advertised in the same instance of the control plane that advertises the TE links from which the LSP is constructed. The LSP itself is called an FA-LSP. FA-LSPs are analogous to MPLS-TP Sections as discussed in [RFC5960].
フォワーディング隣接（FA）は、[RFC4206]でLSPから作成されたデータリンクとして定義され、LSPが構築されているTEリンクを宣伝するコントロールプレーンの同じインスタンスで宣伝されています。LSP自体はFA-LSPと呼ばれます。FA-LSPは、[RFC5960]で説明されているように、MPLS-TPセクションに類似しています。
Thus, a hierarchical LSP may form an FA such that it is advertised as a TE link in the same instance of the routing protocol as was used to advertise the TE links that the LSP traverses.
したがって、階層LSPはFAを形成し、LSPが横断するTEリンクを宣伝するために使用されたルーティングプロトコルの同じインスタンスでTEリンクとして宣伝されるようになります。
As observed in [RFC4206], the nodes at the ends of an FA would not usually have a routing adjacency.
[RFC4206]で観察されているように、FAの端にあるノードには通常、ルーティング隣接がありません。
LSP hierarchy is expected to play an important role in MPLS-TP networks, particularly in the context of scaling and recovery as well as supporting SPMEs.
LSP階層は、特にSPMEのサポートと同様に、MPLS-TPネットワーク、特にスケーリングと回復のコンテキストで重要な役割を果たすことが期待されています。
GMPLS defines RSVP-TE extensions in support for end-to-end GMPLS LSPs recovery in [RFC4872] and segment recovery in [RFC4873]. GMPLS segment recovery provides a superset of the function in end-to-end recovery. End-to-end recovery can be viewed as a special case of segment recovery where there is a single recovery domain whose borders coincide with the ingress and egress of the LSP, although specific procedures are defined.
GMPLSは、[RFC4872]のエンドツーエンドGMPLS LSP Recoveryと[RFC4873]のセグメント回復をサポートするRSVP-TE拡張機能を定義します。GMPLSセグメントリカバリは、エンドツーエンドの回復における関数のスーパーセットを提供します。エンドツーエンドの回復は、特定の手順が定義されていますが、LSPの侵入と出口と境界が一致する単一の回復ドメインがあるセグメント回復の特別なケースと見なすことができます。
The five defined types of recovery defined in GMPLS are:
GMPLで定義されている5つの定義されたタイプの回復は次のとおりです。
- 1+1 bidirectional protection for P2P LSPs - 1+1 unidirectional protection for P2MP LSPs - 1:n (including 1:1) protection with or without extra traffic - Rerouting without extra traffic (sometimes known as soft rerouting), including shared mesh restoration - Full LSP rerouting
- 1 1 P2P LSPSの双方向保護-1 1 P2MP LSPS -1：N（1：1を含む）余分なトラフィックの有無にかかわらず保護 - 追加のトラフィックなしで再ルーティング（時にはソフトリアウトと呼ばれることもあります） - 共有メッシュの回復を含む - フルフルLSPルーティング
Recovery for MPLS-TP LSPs, as discussed in [RFC6372], is signaled using the mechanism defined in [RFC4872] and [RFC4873]. Note that when MEPs are required for the OAM CC function and the MEPs exist at LSP transit nodes, each MEP is instantiated at a hierarchical LSP end point, and protection is provided end-to-end for the hierarchical LSP. (Protection can be signaled using either [RFC4872] or [RFC4873] defined procedures.) The use of Notify messages to trigger protection switching and recovery is not required in MPLS-TP, as this function is expected to be supported via OAM. However, its use is not precluded.
[RFC6372]で説明されているように、MPLS-TP LSPの回復は、[RFC4872]および[RFC4873]で定義されたメカニズムを使用してシグナル伝えられます。OAM CC関数にMEPが必要であり、MEPがLSPトランジットノードに存在する場合、各MEPは階層LSPエンドポイントでインスタンス化され、保護が階層LSPのエンドツーエンドで提供されることに注意してください。（[RFC4872]または[RFC4873]の定義された手順のいずれかを使用して保護を合図できます。）この機能はOAMを介してサポートされると予想されるため、MPLS-TPでは、MPLS-TPでは、通知メッセージを使用するための[保護]スイッチングと回復をトリガーする必要はありません。ただし、その使用は排除されていません。
The majority of RFCs about the GMPLS control plane define the control plane from the context of an internal Network-to-Network Interface (I-NNI). In the MPLS-TP context, some operators may choose to deploy signaled interfaces across User-to-Network Interfaces (UNIs) and across inter-provider, external Network-to-Network Interfaces (E-NNIs). Such support is embodied in [RFC4208] for UNIs and in [RFC5787] for routing areas in support of E-NNIs. This work may require extensions in order to meet the specific needs of an MPLS-TP UNI and E-NNI.
GMPLSコントロールプレーンに関するRFCの大部分は、内部ネットワーク間インターフェイス（I-NNI）のコンテキストからコントロールプレーンを定義します。MPLS-TPコンテキストでは、一部のオペレーターは、ユーザー間インターフェイス（UNIS）およびプロバイダー間の外部ネットワーク間インターフェイス（ENNI）を介して信号インターフェイスを展開することを選択できます。このようなサポートは、UNISの[RFC4208]およびENNIをサポートするルーティングエリアの[RFC5787]で具体化されています。この作業は、MPLS-TP UNIおよびE-NNIの特定のニーズを満たすために拡張機能を必要とする場合があります。
MPLS-TP is defined to support a comprehensive set of MPLS-TP OAM functions. The MPLS-TP control plane will not itself provide OAM functions, but it will be used to instantiate and otherwise control MPLS-TP OAM functions.
MPLS-TPは、MPLS-TP OAM関数の包括的なセットをサポートするために定義されています。MPLS-TPコントロールプレーン自体はOAM機能を提供しませんが、MPLS-TP OAM関数をインスタンス化および制御するために使用されます。
Specific OAM requirements for MPLS-TP are documented in [RFC5860]. This document also states that it is required that the control plane be able to configure and control OAM entities. This requirement is not yet addressed by the existing RFCs, but such work is now under way, e.g., [CCAMP-OAM-FWK] and [CCAMP-OAM-EXT].
MPLS-TPの特定のOAM要件は、[RFC5860]で文書化されています。また、このドキュメントでは、制御プレーンがOAMエンティティを構成および制御できることが必要であると述べています。この要件は既存のRFCSによってまだ対処されていませんが、そのような作業は現在、[CCAMP-OAM-FWK]および[CCAMP-OAM-EXT]です。
Many OAM functions occur on a per-LSP basis, are typically in-band, and are initiated immediately after LSP establishment. Hence, it is desirable that such functions be established and activated via the
多くのOAM関数は、LSPごとに発生し、通常は帯域内であり、LSPの確立直後に開始されます。したがって、そのような機能が確立され、
same control-plane signaling used to set up the LSP, as this effectively synchronizes OAM with the LSP lifetime and avoids the extra overhead and potential errors associated with separate OAM configuration mechanisms.
LSPのセットアップに使用される同じ制御面シグナル伝達は、OAMがLSP寿命と効果的に同期し、個別のOAM構成メカニズムに関連する追加のオーバーヘッドと潜在的なエラーを回避するためです。
There is no MPLS-TP requirement for a standardized management interface to the MPLS-TP control plane. That said, MPLS and GMPLS support a number of standardized management functions. These include the MPLS-TE/GMPLS TE Database Management Information Base [TE-MIB]; the MPLS-TE MIB [RFC3812]; the MPLS LSR MIB [RFC3813]; the GMPLS TE MIB [RFC4802]; and the GMPLS LSR MIB [RFC4803]. These MIB modules may be used in MPLS-TP networks. A general overview of MPLS-TP related MIB modules can be found in [TP-MIB]. Network management requirements for MPLS-based transport networks are provided in [RFC5951].
MPLS-TPコントロールプレーンへの標準化された管理インターフェイスのMPLS-TP要件はありません。とはいえ、MPLSとGMPLSは、多くの標準化された管理機能をサポートしています。これらには、MPLS-TE/GMPLS TEデータベース管理情報ベース[TE-MIB]が含まれます。MPLS-TE MIB [RFC3812];MPLS LSR MIB [RFC3813];gmpls te mib [rfc4802];およびGMPLS LSR MIB [RFC4803]。これらのMIBモジュールは、MPLS-TPネットワークで使用できます。MPLS-TP関連のMIBモジュールの一般的な概要は、[TP-MIB]に記載されています。MPLSベースの輸送ネットワークのネットワーク管理要件は、[RFC5951]で提供されています。
The GMPLS control plane allows for management-plane recovery triggers and directly supports control-plane recovery triggers. Support for control-plane recovery triggers is defined in [RFC4872], which refers to the triggers as "Recovery Commands". These commands can be used with both end-to-end and segment recovery, but are always controlled on an end-to-end basis. The recovery triggers/commands defined in [RFC4872] are:
GMPLSコントロールプレーンは、管理面回復トリガーを可能にし、コントロールプレーンリカバリトリガーを直接サポートします。コントロールプレーンリカバリトリガーのサポートは、[RFC4872]で定義されています。これは、トリガーを「回復コマンド」と呼んでいます。これらのコマンドは、エンドツーエンドとセグメントの両方の回復で使用できますが、常にエンドツーエンドベースで制御されます。[RFC4872]で定義されている回復トリガー/コマンドは次のとおりです。
a. Lockout of recovery LSP
a. リカバリLSPのロックアウト
b. Lockout of normal traffic
b. 通常のトラフィックのロックアウト
c. Forced switch for normal traffic
c. 通常のトラフィック用の強制スイッチ
d. Requested switch for normal traffic
d. 通常のトラフィックのスイッチを要求しました
e. Requested switch for recovery LSP
e. リカバリLSPの要求されたスイッチ
Note that control-plane triggers are typically invoked in response to a management-plane request at the ingress.
通常、コントロールプレーントリガーは、イングレスでの管理面リクエストに応じて呼び出されることに注意してください。
In networks where both the control plane and management plane are provided, LSP provisioning can be done either by the control plane or management plane. As mentioned in the requirements section above, it must be possible to transfer, or handover, a management-plane-created LSP to the control-plane domain and vice versa. [RFC5493] defines
コントロールプレーンと管理プレーンの両方が提供されるネットワークでは、LSPプロビジョニングを制御プレーンまたは管理プレーンのいずれかで実行できます。上記の要件セクションで述べたように、管理面で作成されたLSPをコントロールプレーンドメインに転送または引き渡すことができなければなりません。[RFC5493]定義します
the specific requirements for an LSP ownership handover procedure. It must be possible for the control plane to provide the management plane, in a reliable manner, with the status or result of an operation performed by the management plane. This notification may be either synchronous or asynchronous with respect to the operation. Moreover, it must be possible for the management plane to monitor the status of the control plane, for example, the status of a TE link, its available resources, etc. This monitoring may be based on queries initiated by the management plane or on notifications generated by the control plane. A mechanism must be made available by the control plane to the management plane to log operation of a control-plane LSP; that is, it must be possible from the NMS to have a clear view of the life (traffic hit, action performed, signaling, etc.) of a given LSP. The LSP handover procedure for MPLS-TP LSPs is supported via [RFC5852].
LSPの所有権ハンドオーバー手順の特定の要件。管理プレーンが、管理プレーンが管理プレーンによって実行された操作のステータスまたは結果を備えた管理プレーンを信頼できる方法で提供できる必要があります。この通知は、操作に関して同期または非同期のいずれかです。さらに、管理プレーンが制御プレーンのステータス、たとえばTEリンクのステータス、利用可能なリソースなどを監視することが可能である必要があります。この監視は、管理プレーンまたは通知で開始されるクエリに基づいている場合があります。コントロールプレーンによって生成されます。コントロールプレーンLSPの操作を記録するには、管理プレーンが管理プレーンに制御プレーンが利用できるようにする必要があります。つまり、NMSから、特定のLSPの生命（トラフィックヒット、アクションが実行され、シグナル伝達など）を明確に見えることができなければなりません。MPLS-TP LSPのLSPハンドオーバー手順は、[RFC5852]を介してサポートされています。
The following table shows how the MPLS-TP control-plane requirements can be met using the existing GMPLS control plane (which builds on the MPLS control plane). Areas where additional specifications are required are also identified. The table lists references based on the control-plane requirements as identified and numbered above in Section 2.
次の表は、既存のGMPLSコントロールプレーン（MPLSコントロールプレーンに構築される）を使用して、MPLS-TPコントロールプレーン要件をどのように満たすことができるかを示しています。追加の仕様が必要な領域も特定されています。この表には、セクション2で上記で識別および番号が付けられた制御面要件に基づいて参照がリストされています。
+=======+===========================================================+
| Req # | References |
+-------+-----------------------------------------------------------+
| 1 | Generic requirement met by using Standards Track RFCs |
| 2 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 3 | [RFC5145] + Formal Definition (See Section 4.4.1) |
| 4 | Generic requirement met by using Standards Track RFCs |
| 5 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 6 | [RFC3471], [RFC3473], [RFC4875] |
| 7 | [RFC3471], [RFC3473] + |
| | Associated bidirectional LSPs (See Section 4.4.2) |
| 8 | [RFC4875] |
| 9 | [RFC3473] |
| 10 | Associated bidirectional LSPs (See Section 4.4.2) |
| 11 | Associated bidirectional LSPs (See Section 4.4.2) |
| 12 | [RFC3473] |
| 13 | [RFC5467] (Currently Experimental; See Section 4.4.3) |
| 14 | [RFC3945], [RFC3473], [RFC4202], [RFC4203], [RFC5307] |
| 15 | [RFC3945], [RFC3473], [RFC4202], [RFC4203], [RFC5307] |
| 16 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 17 | [RFC3945], [RFC4202] + proper vendor implementation |
| 18 | [RFC3945], [RFC4202] + proper vendor implementation |
| 19 | [RFC3945], [RFC4202] |
| 20 | [RFC3473] |
| 21 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307], |
| | [RFC5151] |
| 22 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307], |
| | [RFC5151] |
| 23 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 24 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 25 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307], |
| | [RFC6107] |
| 26 | [RFC3473], [RFC4875] |
| 27 | [RFC3473], [RFC4875] |
| 28 | [RFC3945], [RFC3471], [RFC4202] |
| 29 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 30 | [RFC3945], [RFC3471], [RFC4202] |
| 31 | [RFC3945], [RFC3471], [RFC4202] |
| 32 | [RFC4208], [RFC4974], [RFC5787], [RFC6001] |
| 33 | [RFC3473], [RFC4875] |
| 34 | [RFC4875] |
| 35 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 36 | [RFC3473], [RFC3209] (Make-before-break) |
| 37 | [RFC3473], [RFC3209] (Make-before-break) |
| 38 | [RFC4139], [RFC4258], [RFC5787] |
| 39 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 40 | [RFC3473], [RFC5063] |
| 41 | [RFC3945], [RFC3471], [RFC4202], [RFC4208] |
| 42 | [RFC3945], [RFC3471], [RFC4202] |
| 43 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 44 | [RFC6107], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 45 | [RFC3473], [RFC4203], [RFC5307], [RFC5063] |
| 46 | [RFC5493] |
| 47 | [RFC4872], [RFC4873] |
| 48 | [RFC3945], [RFC3471], [RFC4202] |
| 49 | [RFC4872], [RFC4873] + Recovery for P2MP (see Sec. 4.4.4) |
| 50 | [RFC4872], [RFC4873] |
| 51 | [RFC4872], [RFC4873] + proper vendor implementation |
| 52 | [RFC4872], [RFC4873], [GMPLS-PS] |
| 53 | [RFC4872], [RFC4873] |
| 54 | [RFC3473], [RFC4872], [RFC4873], [GMPLS-PS] |
| | Timers are a local implementation matter |
| 55 | [RFC4872], [RFC4873], [GMPLS-PS] + |
| | implementation of timers |
| 56 | [RFC4872], [RFC4873], [GMPLS-PS] |
| 57 | [RFC4872], [RFC4873] |
| 58 | [RFC4872], [RFC4873] |
| 59 | [RFC4872], [RFC4873] |
| 60 | [RFC4872], [RFC4873], [RFC6107] |
| 61 | [RFC4872], [RFC4873] |
| 62 | [RFC4872], [RFC4873] + Recovery for P2MP (see Sec. 4.4.4) |
| 63 | [RFC4872], [RFC4873] |
| 64 | [RFC4872], [RFC4873] |
| 65 | [RFC4872], [RFC4873] |
| 66 | [RFC4872], [RFC4873], [RFC6107] |
| 67 | [RFC4872], [RFC4873] |
| 68 | [RFC3473], [RFC4872], [RFC4873] |
| 69 | [RFC3473] |
| 70 | [RFC3473], [RFC4872], [GMPLS-PS] |
| 71 | [RFC3473], [RFC4872] |
| 72 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 73 | [RFC4426], [RFC4872], [RFC4873] |
| 74 | [RFC4426], [RFC4872], [RFC4873] |
| 75 | [RFC4426], [RFC4872], [RFC4873] |
| 76 | [RFC4426], [RFC4872], [RFC4873] |
| 77 | [RFC4426], [RFC4872], [RFC4873] |
| 78 | [RFC4426], [RFC4872], [RFC4873] + vendor implementation |
| 79 | [RFC4426], [RFC4872], [RFC4873] |
| 80 | [RFC4426], [RFC4872], [RFC4873] |
| 81 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) |
| 82 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) |
| 83 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) |
| 84 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) |
| 85 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 86 | [RFC4872], [RFC4873] |
| 87 | [RFC4872], [RFC4873] |
| 88 | [RFC4872], [RFC4873], [TP-RING] |
| 89 | [RFC4872], [RFC4873], [TP-RING] |
| 90 | [RFC3270], [RFC3473], [RFC4124] + GMPLS Usage (See 4.4.6) |
| 91 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 92 | [RFC3945], [RFC3473], [RFC2210], [RFC2211], [RFC2212] |
| 93 | Generic requirement on data plane (correct implementation)|
| 94 | [RFC3473], [NO-PHP] |
| 95 | [RFC3270], [RFC3473], [RFC4124] + GMPLS Usage (See 4.4.6) |
| 96 | PW only requirement; see PW Requirements Table (5.2) |
| 97 | PW only requirement; see PW Requirements Table (5.2) |
| 98 | [RFC3945], [RFC3473], [RFC6107] |
| 99 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] + |
| | [RFC5392] and [RFC5316] |
| 100 | PW only requirement; see PW Requirements Table (5.2) |
| 101 | [RFC3473], [RFC4203], [RFC5307], [RFC5063] |
| 102 | [RFC4872], [RFC4873], [TP-RING] |
| 103 | [RFC3945], [RFC3473], [RFC6107] |
| 104 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 105 | [RFC3473], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 106 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 107 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 108 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 109 | [RFC3473], [RFC4872], [RFC4873] |
| 110 | [RFC3473], [RFC4872], [RFC4873] |
| 111 | [RFC3473], [RFC4783] |
| 112 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 113 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 114 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 115 | [RFC3473] |
| 116 | [RFC4426], [RFC4872], [RFC4873] |
| 117 | [RFC3473], [RFC4872], [RFC4873] |
| 118 | [RFC3473], [RFC4783] |
| 119 | [RFC3473] |
| 120 | [RFC3473], [RFC4783] |
| 121 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 122 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 123 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT], [RFC6107] |
| 124 - | |
| 135 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 136a | [RFC3473] |
| 136b | [RFC3473] + (See Sec. 4.4.7) |
| 137a | [RFC3473] |
| 137b | [RFC3473] + (See Sec. 4.4.7) |
| 138 | PW only requirement; see PW Requirements Table (5.2) |
| 139 - | |
| 143 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.8) |
+=======+===========================================================+
Table 1: GMPLS and MPLS-TP Requirements Table
表1：GMPLSおよびMPLS-TP要件テーブル
This section identifies the extensions and other documents that have been identified as likely to be needed to support the full set of MPLS-TP control-plane requirements.
このセクションでは、MPLS-TPコントロールプレーン要件の完全なセットをサポートするために必要であると特定された拡張機能とその他のドキュメントを識別します。
While no interworking function is expected in the data plane to support the interconnection of MPLS-TE and MPLS-TP networking, this is not the case for the control plane. MPLS-TE networks typically use LSP signaling based on [RFC3209], while MPLS-TP LSPs will be signaled using GMPLS RSVP-TE, i.e., [RFC3473]. [RFC5145] identifies a set of solutions that are aimed to aid in the interworking of MPLS-TE and GMPLS control planes. [RFC5145] work will serve as the foundation for a formal definition of MPLS to MPLS-TP control-plane interworking.
MPLS-TEおよびMPLS-TPネットワーキングの相互接続をサポートするために、データプレーンではインターワーキング関数は予想されていませんが、これはコントロールプレーンの場合ではありません。MPLS-TEネットワークは通常、[RFC3209]に基づいたLSPシグナル伝達を使用しますが、MPLS-TP LSPはGMPLS RSVP-TE、つまり[RFC3473]を使用してシグナル伝達されます。[RFC5145]は、MPLS-TEおよびGMPLS制御プレーンのインターワーキングを支援することを目的とした一連のソリューションを識別します。[RFC5145]作業は、MPLS-TPコントロールプレーンインターワーキングに対するMPLSの正式な定義の基礎として機能します。
GMPLS signaling, [RFC3473], supports unidirectional and co-routed, bidirectional point-to-point LSPs. MPLS-TP also requires support for associated bidirectional point-to-point LSPs. Such support will require an extension or a formal definition of how the LSP end points supporting an associated bidirectional service will coordinate the two LSPs used to provide such a service. Per requirement 11, transit nodes that support an associated bidirectional service should be aware of the association of the LSPs used to support the service when both LSPs are supported on that transit node. There are several existing protocol mechanisms on which to base such support, including, but not limited to:
GMPLSシグナル伝達、[RFC3473]は、単方向および共有された双方向のポイントツーポイントLSPをサポートします。MPLS-TPでは、関連する双方向のポイントツーポイントLSPのサポートも必要です。このようなサポートには、関連する双方向サービスをサポートするLSPエンドポイントが、そのようなサービスを提供するために使用される2つのLSPを調整する方法の拡張または正式な定義が必要です。要件11によれば、関連する双方向サービスをサポートするトランジットノードは、両方のLSPがそのトランジットノードでサポートされている場合に使用されるLSPの関連性を認識する必要があります。以下を含むがこれらに限定されない、そのようなサポートの基礎となるいくつかの既存のプロトコルメカニズムがあります。
o GMPLS calls [RFC4974].
o GMPLSは[RFC4974]を呼び出します。
o The ASSOCIATION object [RFC4872].
o アソシエーションオブジェクト[RFC4872]。
o The LSP_TUNNEL_INTERFACE_ID object [RFC6107].
o lsp_tunnel_interface_idオブジェクト[rfc6107]。
[RFC5467] defines support for bidirectional LSPs that have different (asymmetric) bandwidth requirements for each direction. That RFC can be used to meet the related MPLS-TP technical requirement, but it is currently an Experimental RFC. To fully satisfy the MPLS-TP requirement, RFC 5467 will need to become a Standards Track RFC.
[RFC5467]は、各方向に異なる（非対称の）帯域幅要件を持つ双方向LSPのサポートを定義します。そのRFCは、関連するMPLS-TPの技術的要件を満たすために使用できますが、現在は実験的なRFCです。MPLS-TP要件を完全に満たすには、RFC 5467がRFCを追跡する標準化する必要があります。
The definitions of P2MP, [RFC4875], and GMPLS recovery, [RFC4872] and [RFC4873], do not explicitly cover their interactions. MPLS-TP requires a formal definition of recovery techniques for P2MP LSPs. Such a formal definition will be based on existing RFCs and may not require any new protocol mechanisms but, nonetheless, must be documented.
P2MP、[RFC4875]、およびGMPLS回復[RFC4872]および[RFC4873]の定義は、それらの相互作用を明示的にカバーしていません。MPLS-TPには、P2MP LSPの回復手法の正式な定義が必要です。このような正式な定義は、既存のRFCに基づいており、新しいプロトコルメカニズムを必要としない場合がありますが、それでも文書化する必要があります。
[CCAMP-OAM-FWK] and [CCAMP-OAM-EXT] are examples of OAM-related control extensions to GMPLS. These extensions cover a portion of, but not all, OAM-related control functions that have been identified in the context of MPLS-TP. As discussed above, the MPLS-TP control plane must support the selection of which OAM function(s) (if any) to use (including support to select experimental OAM functions) and what OAM functionality to run, including Continuity Check (CC),
[CCAMP-OAM-FWK]および[CCAMP-OAM-EXT]は、GMPLSへのOAM関連の制御拡張の例です。これらの拡張機能は、MPLS-TPのコンテキストで特定されたOAM関連の制御機能の一部をカバーしています。上記で説明したように、MPLS-TPコントロールプレーンは、使用するOAM関数（存在する場合）の選択（実験的なOAM関数を選択するためのサポートを含む）と、継続性チェック（CC）を含む実行するOAM機能の選択をサポートする必要があります。
Connectivity Verification (CV), packet loss, delay quantification, and diagnostic testing of a service. Such support may be included in the listed documents or in other documents.
接続検証（CV）、パケット損失、遅延定量化、およびサービスの診断テスト。このようなサポートは、リストされたドキュメントまたは他のドキュメントに含まれる場合があります。
[RFC3270] and [RFC4124] define support for Diffserv-enabled MPLS LSPs. While [RFC4124] references GMPLS signaling, there is no explicit discussion on the use of the Diffserv-related objects in GMPLS signaling. A (possibly Informational) document on how GMPLS supports Diffserv LSPs is likely to prove useful in the context of MPLS-TP.
[RFC3270]および[RFC4124]は、DiffServ対応MPLS LSPのサポートを定義します。[RFC4124]はGMPLSシグナル伝達を参照していますが、GMPLSシグナリングでのDifFServ関連オブジェクトの使用に関する明示的な議論はありません。GMPLSがDIFFSERV LSPをサポートする方法に関する（おそらく情報）ドキュメントは、MPLS-TPのコンテキストで有用であると証明される可能性があります。
MPLS-TP uses two forms of LSP identifiers, see [RFC6370]. One form is based on existing GMPLS fields. The other form is based on either the globally unique Attachment Interface Identifier (AII) defined in [RFC5003] or the ITU Carrier Code (ICC) defined in ITU-T Recommendation M.1400. Neither form is currently supported in GMPLS, and such extensions will need to be documented.
MPLS-TPは、2つの形式のLSP識別子を使用します。[RFC6370]を参照してください。1つのフォームは、既存のGMPLSフィールドに基づいています。他のフォームは、[RFC5003]で定義されているグローバルに一意のアタッチメントインターフェイス識別子（AII）またはITU-T推奨M.1400で定義されているITUキャリアコード（ICC）のいずれかに基づいています。どちらのフォームもGMPLSでサポートされていないため、そのような拡張機能を文書化する必要があります。
MPLS-TP defines several forms of maintenance-entity-related identifiers. Both node-unique and global forms are defined. Extensions will be required to GMPLS to support these identifiers. These extensions may be added to existing works in progress, such as [CCAMP-OAM-FWK] and [CCAMP-OAM-EXT], or may be defined in independent documents.
MPLS-TPは、いくつかの形式のメンテナンスエンティティ関連識別子を定義します。ノードユニークとグローバルフォームの両方が定義されています。これらの識別子をサポートするために、GMPLSに拡張機能が必要になります。これらの拡張機能は、[ccamp-oam-fwk]や[ccamp-oam-ext]などの進行中の既存の作業に追加される場合もあれば、独立した文書で定義される場合もあります。
MPLS PWs are defined in [RFC3985] and [RFC5659], and provide for emulated services over an MPLS Packet Switched Network (PSN). Several types of PWs have been defined: (1) Ethernet PWs providing for Ethernet port or Ethernet VLAN transport over MPLS [RFC4448], (2) High-Level Data Link Control (HDLC) / PPP PW providing for HDLC/PPP leased line transport over MPLS [RFC4618], (3) ATM PWs [RFC4816], (4) Frame Relay PWs [RFC4619], and (5) circuit Emulation PWs [RFC4553].
MPLS PWは[RFC3985]および[RFC5659]で定義されており、MPLSパケットスイッチネットワーク（PSN）を介したエミュレートサービスを提供します。（1）MPLSを介したイーサネットポートまたはイーサネットVLAN輸送を提供するイーサネットPW [RFC4448]、（2）高レベルのデータリンクコントロール（HDLC） / PPP PWがHDLC / PPP貸し出しライントランスポートを提供するイーサネットPWSが定義されています。MPLS [RFC4618]、（3）ATM PWS [RFC4816]、（4）フレームリレーPWS [RFC4619]、および（5）回路エミュレーションPWS [RFC4553]
Today's transport networks based on Plesiochronous Digital Hierarchy (PDH), WDM, or SONET/SDH provide transport for PDH or SONET (e.g., ATM over SONET or Packet PPP over SONET) client signals with no payload awareness. Implementing PW capability allows for the use of an existing technology to substitute the Time-Division Multiplexing
プレシオクロナスデジタル階層（PDH）、WDM、またはSONET/SDHに基づく今日の輸送ネットワークは、PDHまたはSONET（例えば、SONET上のATMまたはSONET上のATMまたはパケットPPP）の輸送を提供します。PW機能を実装すると、既存のテクノロジーを使用して時間帯のマルチプレックスを置き換えることができます
(TDM) transport with packet-based transport, using well-defined PW encapsulation methods for carrying various packet services over MPLS, and providing for potentially better bandwidth utilization.
（TDM）Packetベースのトランスポートを使用したトランスポート、MPLSよりもさまざまなパケットサービスを運ぶための明確に定義されたPWカプセル化方法を使用し、潜在的により良い帯域幅の利用を提供します。
There are two general classes of PWs: (1) Single-Segment Pseudowires (SS-PWs) [RFC3985] and (2) Multi-segment Pseudowires (MS-PWs) [RFC5659]. An MPLS-TP network domain may transparently transport a PW whose end points are within a client network. Alternatively, an MPLS-TP edge node may be the Terminating PE (T-PE) for a PW, performing adaptation from the native attachment circuit technology (e.g., Ethernet 802.1Q) to an MPLS PW that is then transported in an LSP over an MPLS-TP network. In this way, the PW is analogous to a transport channel in a TDM network, and the LSP is equivalent to a container of multiple non-concatenated channels, albeit they are packet containers. An MPLS-TP network may also contain Switching PEs (S-PEs) for a Multi-Segment PW whereby the T-PEs may be at the edge of an MPLS-TP network or in a client network. In the latter case, a T-PE in a client network performs the adaptation of the native service to MPLS and the MPLS-TP network performs pseudowire switching.
PWSには2つの一般的なクラスがあります。（1）単一セグメントの擬似動物（SS-PWS）[RFC3985]と（2）マルチセグメントプソイドワイヤ（MS-PWS）[RFC5659]。MPLS-TPネットワークドメインは、エンドポイントがクライアントネットワーク内にあるPWを透過的に輸送できます。あるいは、MPLS-TPエッジノードは、PWの終端PE（T-PE）であり、ネイティブアタッチメント回路技術（例：イーサネット802.1Q）からMPLS PWへの適応を実行し、その後LSPでLSPで輸送されます。MPLS-TPネットワーク。このように、PWはTDMネットワーク内の輸送チャネルに類似しており、LSPはパケットコンテナではありますが、複数の非結合チャネルのコンテナと同等です。MPLS-TPネットワークには、T-PEがMPLS-TPネットワークまたはクライアントネットワークの端にあるマルチセグメントPWのスイッチングPE（S-PE）が含まれている場合があります。後者の場合、クライアントネットワークのT-PEがネイティブサービスのMPLSへの適応を実行し、MPLS-TPネットワークは擬似ワイヤースイッチングを実行します。
The SS-PW signaling control plane is based on targeted LDP (T-LDP) with specific procedures defined in [RFC4447]. The MS-PW signaling control plane is also based on T-LDP as allowed for in [RFC5659], [RFC6073], and [MS-PW-DYNAMIC]. An MPLS-TP network shall use the same PW signaling protocols and procedures for placing SS-PWs and MS-PWs. This will leverage existing technology as well as facilitate interoperability with client networks with native attachment circuits or PW segments that are switched across an MPLS-TP network.
SS-PWシグナルコントロールプレーンは、[RFC4447]で定義されている特定の手順を持つターゲットLDP（T-LDP）に基づいています。MS-PWシグナルコントロールプレーンは、[RFC5659]、[RFC6073]、および[MS-PW-Dynamic]で許可されているT-LDPにも基づいています。MPLS-TPネットワークは、SS-PWSおよびMS-PWSを配置するために、同じPWシグナル伝達プロトコルと手順を使用するものとします。これにより、既存のテクノロジーが活用され、MPLS-TPネットワーク全体に切り替えられたネイティブアタッチメントサーキットまたはPWセグメントを備えたクライアントネットワークとの相互運用性が促進されます。
There is no MPLS-TP requirement for a standardized management interface to the MPLS-TP control plane. A general overview of MPLS-TP-related MIB modules can be found in [TP-MIB]. Network management requirements for MPLS-based transport networks are provided in [RFC5951].
MPLS-TPコントロールプレーンへの標準化された管理インターフェイスのMPLS-TP要件はありません。MPLS-TP関連MIBモジュールの一般的な概要は、[TP-MIB]にあります。MPLSベースの輸送ネットワークのネットワーク管理要件は、[RFC5951]で提供されています。
The following table shows how the MPLS-TP control-plane requirements can be met using the existing LDP control plane for pseudowires (targeted LDP). Areas where additional specifications are required are also identified. The table lists references based on the control-plane requirements as identified and numbered above in Section 2.
次の表は、MPLS-TPコントロールプレーン要件を、擬似動物用の既存のLDPコントロールプレーン（ターゲットLDP）を使用してどのように満たすことができるかを示しています。追加の仕様が必要な領域も特定されています。この表には、セクション2で上記で識別および番号が付けられた制御面要件に基づいて参照がリストされています。
In the table below, several of the requirements shown are addressed -- in part or in full -- by the use of MPLS-TP LSPs to carry pseudowires. This is reflected by including "TP-LSPs" as a reference for those requirements. Section 5.3.2 provides additional context for the binding of PWs to TP-LSPs.
以下の表では、示されている要件のいくつかが、MPLS-TP LSPを使用して擬似動物を運ぶことにより、部分的または完全に対処されています。これは、これらの要件の参照として「TP-LSP」を含めることによって反映されます。セクション5.3.2は、PWSのTP-LSPへの結合のための追加のコンテキストを提供します。
+=======+===========================================================+
| Req # | References |
+-------+-----------------------------------------------------------+
| 1 | Generic requirement met by using Standards Track RFCs |
| 2 | [RFC3985], [RFC4447], Together with TP-LSPs (Sec. 4.3) |
| 3 | [RFC3985], [RFC4447] |
| 4 | Generic requirement met by using Standards Track RFCs |
| 5 | [RFC3985], [RFC4447], Together with TP-LSPs |
| 6 | [RFC3985], [RFC4447], [PW-P2MPR], [PW-P2MPE] + TP-LSPs |
| 7 | [RFC3985], [RFC4447], + TP-LSPs |
| 8 | [PW-P2MPR], [PW-P2MPE] |
| 9 | [RFC3985], end-node only involvement for PW |
| 10 | [RFC3985], proper vendor implementation |
| 11 | [RFC3985], end-node only involvement for PW |
| 12-13 | [RFC3985], [RFC4447], See Section 5.3.4 |
| 14 | [RFC3985], [RFC4447] |
| 15 | [RFC4447], [RFC3478], proper vendor implementation |
| 16 | [RFC3985], [RFC4447] |
| 17-18 | [RFC3985], proper vendor implementation |
| 19-26 | [RFC3985], [RFC4447], [RFC5659], implementation |
| 27 | [RFC4448], [RFC4816], [RFC4618], [RFC4619], [RFC4553] |
| | [RFC4842], [RFC5287] |
| 28 | [RFC3985] |
| 29-31 | [RFC3985], [RFC4447] |
| 32 | [RFC3985], [RFC4447], [RFC5659], See Section 5.3.6 |
| 33 | [RFC4385], [RFC4447], [RFC5586] |
| 34 | [PW-P2MPR], [PW-P2MPE] |
| 35 | [RFC4863] |
| 36-37 | [RFC3985], [RFC4447], See Section 5.3.4 |
| 38 | Provided by TP-LSPs |
| 39 | [RFC3985], [RFC4447], + TP-LSPs |
| 40 | [RFC3478] |
| 41-42 | [RFC3985], [RFC4447] |
| 43-44 | [RFC3985], [RFC4447], + TP-LSPs - See Section 5.3.5 |
| 45 | [RFC3985], [RFC4447], [RFC5659] + TP-LSPs |
| 46 | [RFC3985], [RFC4447], + TP-LSPs - See Section 5.3.3 |
| 47 | [PW-RED], [PW-REDB] |
| 48-49 | [RFC3985], [RFC4447], + TP-LSPs, implementation |
| 50-52 | Provided by TP-LSPs, and Section 5.3.5 |
| 53-55 | [RFC3985], [RFC4447], See Section 5.3.5 |
| 56 | [PW-RED], [PW-REDB] |
| | revertive/non-revertive behavior is a local matter for PW |
| 57-58 | [PW-RED], [PW-REDB] |
| 59-81 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 |
| 82-83 | [RFC5085], [RFC5586], [RFC5885] |
| 84-89 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 |
| 90-95 | [RFC3985], [RFC4447], + TP-LSPs, implementation |
| 96 | [RFC4447], [MS-PW-DYNAMIC] |
| 97 | [RFC4447] |
| 98 - | |
| 99 | Not Applicable to PW |
| 100 | [RFC4447] |
| 101 | [RFC3478] |
| 102 | [RFC3985], + TP-LSPs |
| 103 | Not Applicable to PW |
| 104 | [PW-OAM] |
| 105 | [PW-OAM] |
| 106 - | |
| 108 | [RFC5085], [RFC5586], [RFC5885] |
| 109 | [RFC5085], [RFC5586], [RFC5885] |
| | fault reporting and protection triggering is a local |
| | matter for PW |
| 110 | [RFC5085], [RFC5586], [RFC5885] |
| | fault reporting and protection triggering is a local |
| | matter for PW |
| 111 | [RFC4447] |
| 112 | [RFC4447], [RFC5085], [RFC5586], [RFC5885] |
| 113 | [RFC5085], [RFC5586], [RFC5885] |
| 114 | [RFC5085], [RFC5586], [RFC5885] |
| 115 | path traversed by PW is determined by LSP path; see |
| | GMPLS and MPLS-TP Requirements Table, Section 4.3 |
| 116 | [PW-RED], [PW-REDB], administrative control of redundant |
| | PW is a local matter at the PW head-end |
| 117 | [PW-RED], [PW-REDB], [RFC5085], [RFC5586], [RFC5885] |
| 118 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 |
| 119 | [RFC4447] |
| 120 - | |
| 125 | [RFC5085], [RFC5586], [RFC5885] |
| 126 - | |
| 130 | [PW-OAM] |
| 131 | Section 5.3.5 |
| 132 | [PW-OAM] |
| 133 | [PW-OAM] |
| 134 | Section 5.3.5 |
| 135 | [PW-OAM] |
| 136 | Not Applicable to PW |
| 137 | Not Applicable to PW |
| 138 | [RFC4447], [RFC5003], [MS-PW-DYNAMIC] |
| 139 - | |
| 143 | [PW-OAM] |
+=======+===========================================================+
Table 2: PW Control (LDP) and MPLS-TP Requirements Table
表2：PWコントロール（LDP）およびMPLS-TP要件テーブル
Existing control protocol and procedures will be reused as much as possible to support MPLS-TP. However, when using PWs in MPLS-TP, a set of new requirements is defined that may require extensions of the existing control mechanisms. This section clarifies the areas where extensions are needed based on the requirements that are related to the PW control plane and documented in [RFC5654].
既存の制御プロトコルと手順は、MPLS-TPをサポートするために可能な限り再利用されます。ただし、MPLS-TPでPWSを使用する場合、既存の制御メカニズムの拡張を必要とする可能性のある一連の新しい要件が定義されています。このセクションでは、[RFC5654]で文書化されたPW制御プレーンに関連する要件に基づいて、拡張が必要な領域を明確にします。
Table 2 lists how requirements defined in [RFC5654] are expected to be addressed.
表2に、[RFC5654]で定義されている要件が対処されることが予想される方法を示します。
The baseline requirement for extensions to support transport applications is that any new mechanisms and capabilities must be able to interoperate with existing IETF MPLS [RFC3031] and IETF PWE3 [RFC3985] control and data planes where appropriate. Hence, extensions of the PW control plane must be in-line with the procedures defined in [RFC4447], [RFC6073], and [MS-PW-DYNAMIC].
輸送アプリケーションをサポートするための拡張機能のベースライン要件は、必要に応じて既存のIETF MPLS [RFC3031]およびIETF PWE3 [RFC3985]制御およびデータプレーンと相互運用できる必要があることです。したがって、PWコントロールプレーンの拡張は、[RFC4447]、[RFC6073]、および[MS-PW-Dynamic]で定義されている手順とインラインでなければなりません。
For MPLS-TP, it is required that the data and control planes can be both logically and physically separated. That is, the PW control plane must be able to operate out-of-band (OOB). This separation ensures, among other things, that in the case of control-plane failures the data plane is not affected and can continue to operate normally. This was not a design requirement for the current PW control plane. However, due to the PW concept, i.e., PWs are connecting logical entities ('forwarders'), and the operation of the PW control protocol, i.e., only edge PE nodes (T-PE, S-PE) take part in the signaling exchanges: moving T-LDP out-of-band seems to be, theoretically, a straightforward exercise.
MPLS-TPの場合、データと制御プレーンを論理的および物理的に分離できることが必要です。つまり、PWコントロールプレーンは、帯域外（OOB）を動作させることができなければなりません。この分離により、とりわけ、コントロールプレーン障害の場合、データプレーンが影響を受けず、普通に動作し続けることができます。これは、現在のPWコントロールプレーンの設計要件ではありませんでした。ただし、PWの概念のため、つまりPWSは論理エンティティ（「転送者」）を接続しており、PWコントロールプロトコルの動作、つまりエッジPEノードのみ（T-PE、S-PE）がシグナリングに参加しています。交換：T-LDPの外側の移動は、理論的には、簡単な運動であるようです。
In fact, as a strictly local matter, ensuring that targeted LDP (T-LDP) uses out-of-band signaling requires only that the local implementation is configured in such a way that reachability for a target LSR address is via the out-of-band channel.
実際、厳密にローカルな問題として、ターゲットを絞ったLDP（T-LDP）が帯域外シグナリングを使用することを保証するには、ローカル実装がターゲットLSRアドレスの到達可能性が外れているような方法で構成されることのみが必要です。 - バンドチャネル。
More precisely, if IP addressing is used in the MPLS-TP control plane, then T-LDP addressing can be maintained, although all addresses will refer to control-plane entities. Both the PWid Forwarding Equivalence Class (FEC) and Generalized PWid FEC Elements can possibly be used in an OOB case as well. (Detailed evaluation is outside the scope of this document.) The PW label allocation and exchange mechanisms should be reused without change.
より正確には、MPLS-TPコントロールプレーンでIPアドレス指定が使用される場合、すべてのアドレスはコントロールプレーンエンティティを参照しますが、T-LDPアドレス指定を維持できます。PWID転送等価クラス（FEC）と一般化されたPWID FEC要素の両方が、OOBケースでも使用できる可能性があります。（詳細な評価は、このドキュメントの範囲外です。）PWラベルの割り当てと交換メカニズムは、変更せずに再利用する必要があります。
Binding a PW to an LSP, or PW segments to LSPs, is left to nodes acting as T-PEs and S-PEs or a control-plane entity that may be the same one signaling the PW. However, an extension of the PW signaling protocol is required to allow the LSR at the signal initiation end to inform the targeted LSR (at the signal termination end) to which LSP the resulting PW is to be bound, in the event that more than one such LSP exists and the choice of LSPs is important to the service being setup (for example, if the service requires co-routed bidirectional paths). This is also particularly important to support transport path (symmetric and asymmetric) bandwidth requirements.
PWをLSPに結合し、PWセグメントをLSPに結合することは、T-PESおよびS-PESとして機能するノードに任され、PWを通知するのと同じコントロールプレーンエンティティに任されます。ただし、信号の開始端でLSRを許可するには、PWシグナル伝達プロトコルの拡張が必要です。このようなLSPが存在し、LSPの選択はセットアップされるサービスにとって重要です（たとえば、サービスが共同で双方向のパスを必要とする場合）。これは、輸送パス（対称および非対称）帯域幅要件をサポートするために特に重要です。
For transport services, MPLS-TP requires support for bidirectional traffic that follows congruent paths. Currently, each direction of a PW or a PW segment is bound to a unidirectional LSP that extends between two T-PEs, two S-PEs, or a T-PE and an S-PE. The unidirectional LSPs in both directions are not required to follow congruent paths, and therefore both directions of a PW may not follow congruent paths, i.e., they are associated bidirectional paths. The only requirement in [RFC5659] is that a PW or a PW segment shares the same T-PEs in both directions and the same S-PEs in both directions.
輸送サービスの場合、MPLS-TPでは、一致するパスに続く双方向トラフィックのサポートが必要です。現在、PWまたはPWセグメントの各方向は、2つのT-PE、2つのS-PE、またはT-PEとS-PEの間に伸びる単方向LSPに結合しています。両方向の単方向LSPは、合同経路をたどるために必要ではないため、PWの両方向は合同経路に従わない場合があります。つまり、関連する双方向パスです。[RFC5659]の唯一の要件は、PWまたはPWセグメントが両方向に同じT-PEと両方向で同じS-PEを共有することです。
MPLS-TP imposes new requirements on the PW control plane, in requiring that both end points map the PW or PW segment to the same transport path for the case where this is an objective of the service. When a bidirectional LSP is selected on one end to transport the PW, a mechanism is needed that signals to the remote end which LSP has been selected locally to transport the PW. This would be accomplished by adding a new TLV to PW signaling.
MPLS-TPは、PWコントロールプレーンに新しい要件を課し、両方のエンドポイントがPWまたはPWセグメントを同じ輸送パスにマッピングすることを要求します。これがサービスの目的である場合。双方向LSPがPWを輸送するために一端に選択されると、PWを輸送するためにLSPがローカルに選択されたリモートエンドに信号を送るメカニズムが必要です。これは、PWシグナル伝達に新しいTLVを追加することで達成されます。
Note that this coincides with the gap identified for OOB support: a new mechanism is needed to allow explicit binding of a PW to the supporting transport LSP.
これは、OOBサポートのために識別されたギャップと一致することに注意してください。PWのサポートトランスポートLSPへの明示的な結合を可能にするために、新しいメカニズムが必要であることに注意してください。
The case of unidirectional transport paths may also require additional protocol mechanisms, as today's PWs are always bidirectional. One potential approach for providing a unidirectional PW-based transport path is for the PW to associate different (asymmetric) bandwidths in each direction, with a zero or minimal bandwidth for the return path. This approach is consistent with Section 3.8.2 of [RFC5921] but does not address P2MP paths.
今日のPWは常に双方向であるため、単方向輸送経路の場合には追加のプロトコルメカニズムが必要になる場合があります。一方向のPWベースの輸送パスを提供するための潜在的なアプローチの1つは、PWが各方向に異なる（非対称の）帯域幅を関連付け、リターンパスの帯状または最小帯域幅を使用することです。このアプローチは、[RFC5921]のセクション3.8.2と一致していますが、P2MPパスには対処されていません。
In order to satisfy requirement 47 (as defined in Section 2), it will be necessary to specify methods for transfer of PW ownership from the management to the control plane (and vice versa).
要件47を満たすために（セクション2で定義されている）、管理面からコントロールプレーンへのPW所有権を転送する方法を指定する必要があります（その逆も同様です）。
Transport applications may require resource guarantees. For such transport LSPs, resource reservation mechanisms are provided via RSVP-TE and the use of Diffserv. If multiple PWs are multiplexed into the same transport LSP resources, contention may occur. However, local policy at PEs should ensure proper resource sharing among PWs mapped into a resource-guaranteed LSP. In the case of MS-PWs, signaling carries the PW traffic parameters [MS-PW-DYNAMIC] to enable admission control of a PW segment over a resource-guaranteed LSP.
輸送アプリケーションには、リソース保証が必要になる場合があります。このような輸送LSPの場合、リソース予約メカニズムはRSVP-TEとDiffServの使用を介して提供されます。複数のPWが同じ輸送LSPリソースに多重化されている場合、競合が発生する可能性があります。ただし、PESのローカルポリシーは、リソース保証LSPにマッピングされたPWS間の適切なリソース共有を確保する必要があります。MS-PWSの場合、シグナリングはPWトラフィックパラメーター[MS-PW-Dynamic]を運び、リソース保証LSPを介したPWセグメントの入場制御を可能にします。
In conjunction with explicit PW-to-LSP binding, existing mechanisms may be sufficient; however, this needs to be verified in detailed evaluation.
明示的なPWからLSPの結合に関連して、既存のメカニズムで十分かもしれません。ただし、これは詳細な評価で検証する必要があります。
Many of the requirements listed in Section 2 are intended to support connectivity and performance monitoring (grouped together as OAM), as well as protection conformant with the transport services model.
セクション2にリストされている要件の多くは、接続とパフォーマンスの監視（OAMとしてグループ化された）をサポートすることを目的としています。
In general, protection of MPLS-TP transported services is provided by way of protection of transport LSPs. PW protection requires that mechanisms be defined to support redundant pseudowires, including a mechanism already described above for associating such pseudowires with specific protected ("working" and "protection") LSPs. Also required are definitions of local protection control functions, to include test/verification operations, and protection status signals needed to ensure that PW termination points are in agreement as to which of a set of redundant pseudowires are in use for which transport services at any given point in time.
一般に、MPLS-TP輸送サービスの保護は、輸送LSPの保護によって提供されます。PW保護では、そのような擬似ワイヤを特定の保護（「作業」および「保護」）LSPに関連付けるために上記のメカニズムを含む、冗長性の擬似動物をサポートするためにメカニズムを定義する必要があります。また、テスト/検証操作を含めるために、ローカル保護制御機能の定義、およびPW終端ポイントが特定の輸送サービスのどの輸送サービスに使用されているかについて、PW終端ポイントがどのセットで使用されているかを確認するために必要な保護ステータス信号も必要です。時間内。
Much of this work is currently being done in documents [PW-RED] and [PW-REDB] that define, respectively, how to establish redundant pseudowires and how to indicate which is in use. Additional work may be required.
この作業の多くは、現在、それぞれ冗長化された擬似ワイヤを確立する方法と使用していることを示す方法を定義する文書[PW-RED]および[PW-REDB]で行われています。追加の作業が必要になる場合があります。
Protection switching may be triggered manually by the operator, or as a result of loss of connectivity (detected using the mechanisms of [RFC5085] and [RFC5586]), or service degradation (detected using mechanisms yet to be defined).
保護スイッチングは、オペレーターによって手動でトリガーされる場合、または接続性の喪失（[RFC5085]および[RFC5586]のメカニズムを使用して検出）またはサービス劣化（まだ定義されていないメカニズムを使用して検出）の結果としてトリガーされる場合があります。
Automated protection switching is just one of the functions for which a transport service requires OAM. OAM is generally referred to as either "proactive" or "on-demand", where the distinction is whether a specific OAM tool is being used continuously over time (for the purpose of detecting a need for protection switching, for example) or
自動保護スイッチングは、輸送サービスがOAMを必要とする機能の1つにすぎません。OAMは一般に「プロアクティブ」または「オンデマンド」のいずれかと呼ばれます。この場合、特定のOAMツールが時間の経過とともに継続的に使用されているかどうか（たとえば、保護スイッチングの必要性を検出する目的で）または
is only used -- either a limited number of times or over a short period of time -- when explicitly enabled (for diagnostics, for example).
明示的に有効になっている場合（たとえば、診断用）、限られた回数または短期間のいずれかで使用されます。
PW OAM currently consists of connectivity verification defined by [RFC5085]. Work is currently in progress to extend PW OAM to include bidirectional forwarding detection (BFD) in [RFC5885], and work has begun on extending BFD to include performance-related monitor functions.
PW OAMは現在、[RFC5085]で定義された接続検証で構成されています。現在、PW OAMを拡張して[RFC5885]に双方向転送検出（BFD）を含める作業が進行中であり、BFDを拡張してパフォーマンス関連のモニター機能を含めるように作業を開始しました。
Additional work is likely to be required to define consistent access by a client-layer network, as well as between provider networks, to control information available to each type of network, for example, about the topology of an MS-PW. This information may be required by the client-layer network in order to provide hints that may help to avoid establishment of fate-sharing alternate paths. Such work will need to fit within the ASON architecture; see requirement 38 above.
クライアント層ネットワークによる一貫したアクセス、およびプロバイダーネットワーク間で、MS-PWのトポロジに関する各タイプのネットワークで利用可能な情報を制御するために、追加の作業が必要になる可能性があります。この情報は、運命共有の代替パスの確立を避けるのに役立つヒントを提供するために、クライアント層ネットワークによって必要とされる場合があります。このような作業は、ASONアーキテクチャに収まる必要があります。上記の要件38を参照してください。
MPLS-TP PWs are always transported using LSPs, and these LSPs will either have been statically provisioned or signaled using GMPLS.
MPLS-TP PWは常にLSPを使用して輸送され、これらのLSPはGMPLSを使用して静的にプロビジョニングまたはシグナルにされています。
For LSPs signaled using the MPLS-TP LSP control plane (GMPLS), conformance with the ASON architecture is as described in Section 1.2 ("Basic Approach"), bullet 4, of this framework document.
MPLS-TP LSPコントロールプレーン（GMPLS）を使用してシグナル伝達されたLSPの場合、ASONアーキテクチャへの適合は、このフレームワークドキュメントのセクション1.2（「基本アプローチ」）であるBullet 4に記載されているとおりです。
As discussed above in Section 5.3, there are anticipated extensions in the following areas that may be related to ASON architecture:
上記のセクション5.3で説明したように、ASONアーキテクチャに関連する可能性のある次の領域には、予想される拡張があります。
- PW-to-LSP binding (Section 5.3.2) - PW/LSP resource allocation (Section 5.3.4) - PW protection and OAM configuration (Section 5.3.5) - Client-layer interfaces for PW control (Section 5.3.6)
- PW -to -LSPバインディング（セクション5.3.2） - PW/LSPリソース割り当て（セクション5.3.4） - PW保護とOAM構成（セクション5.3.5） - PWコントロール用のクライアントレイヤーインターフェイス（セクション5.3.6）
This work is expected to be consistent with ASON architecture and may require additional specification in order to achieve this goal.
この作業は、ASONアーキテクチャと一致すると予想されており、この目標を達成するために追加の仕様が必要になる場合があります。
This document primarily describes how existing mechanisms can be used to meet the MPLS-TP control-plane requirements. The documents that describe each mechanism contain their own security considerations sections. For a general discussion on MPLS- and GMPLS-related
このドキュメントでは、主に、既存のメカニズムを使用してMPLS-TPコントロールプレーン要件を満たす方法を説明しています。各メカニズムを説明するドキュメントには、独自のセキュリティに関する考慮事項セクションが含まれています。MPLSおよびGMPLS関連に関する一般的な議論のために
security issues, see the MPLS/GMPLS security framework [RFC5920]. As mentioned above in Section 2.4, there are no specific MPLS-TP control-plane security requirements.
セキュリティの問題、MPLS/GMPLSセキュリティフレームワーク[RFC5920]を参照してください。セクション2.4で上記のように、特定のMPLS-TPコントロールプレーンセキュリティ要件はありません。
This document also identifies a number of needed control-plane extensions. It is expected that the documents that define such extensions will also include any appropriate security considerations.
このドキュメントは、必要な多くのコントロールプレーン拡張機能も識別します。このような拡張機能を定義するドキュメントには、適切なセキュリティに関する考慮事項も含まれることが期待されています。
The authors would like to acknowledge the contributions of Yannick Brehon, Diego Caviglia, Nic Neate, Dave Mcdysan, Dan Frost, and Eric Osborne to this work. We also thank Dan Frost in his help responding to Last Call comments.
著者は、この作品へのヤニック・ブレホン、ディエゴ・カビリア、ニック・ニート、デイブ・マクディーン、ダン・フロスト、エリック・オズボーンの貢献を認めたいと考えています。また、ラストコールコメントに応答する彼の助けにダンフロストに感謝します。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J。、「IETF統合サービスでのRSVPの使用」、RFC 2210、1997年9月。
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[RFC2211] Wroclawski、J。、「制御されたロードネットワーク要素サービスの仕様」、RFC 2211、1997年9月。
[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC2212] Shenker、S.、Partridge、C。、およびR. Guerin、「保証されたサービス品質の仕様」、RFC 2212、1997年9月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：LSP TunnelsのRSVPへの拡張"、RFC 3209、12月2001年。
[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月。
[RFC3478] Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful Restart Mechanism for Label Distribution Protocol", RFC 3478, February 2003.
[RFC3478] Leelanivas、M.、Rekhter、Y。、およびR. Aggarwal、「ラベル分布プロトコルの優雅な再起動メカニズム」、RFC 3478、2003年2月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering（TE）Extensions to OSPFバージョン2」、RFC 3630、2003年9月。
[RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005.
[RFC4124] Le Faucheur、F.、ed。、「Diffserv-Aware MPLS Traffic Engineeringのサポートのためのプロトコル拡張」、RFC 4124、2005年6月。
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4202] Kompella、K.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするルーティング拡張機能」、RFC 4202、2005年10月。
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
[RFC4203] Kompella、K.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするOSPF拡張」、RFC 4203、2005年10月。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206] Kompella、K。およびY. Rekhter、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）を備えたラベルスイッチ付きパス（LSP）階層」、2005年10月。
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006.
[RFC4385] Bryant、S.、Swallow、G.、Martini、L。、およびD. McPherson、「Pseudowire Emulation Edge-to-Edge（PWE3）がMPLS PSNを介して使用するコントロールワード」、RFC 4385、2006年2月。
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447] Martini、L.、Ed。、Ed。、Rosen、E.、El-Aawar、N.、Smith、T.、およびG. Heron、「ラベル分布プロトコル（LDP）を使用した擬似ワイヤーのセットアップとメンテナンス」、RFC 4447、2006年4月。
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006.
[RFC4448] Martini、L.、Ed。、Rosen、E.、El-Aawar、N。、およびG. Heron、「MPLSネットワークを介したイーサネットの輸送のためのカプセル化方法」、RFC 4448、2006年4月。
[RFC4842] Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig, "Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)", RFC 4842, April 2007.
[RFC4842] Malis、A.、Pate、P.、Cohen、R.、Ed。、およびD. Zelig、「同期光ネットワーク/同期デジタル階層（SONET/SDH）回路エミュレーション（CEP）（CEP）（CEP）（CEP）（CEP））、RFC 4842、2007年4月。
[RFC4863] Martini, L. and G. Swallow, "Wildcard Pseudowire Type", RFC 4863, May 2007.
[RFC4863] Martini、L。およびG. Swallow、「WildCard Pseudowire Type」、RFC 4863、2007年5月。
[RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007.
[RFC4872] Lang、J.、Ed。、Rekhter、Y.、ed。、およびD. Papadimitriou、ed。、「RSVP-TE拡張機能エンドツーエンド一般化マルチプロトコルラベルスイッチング（GMPLS）回復をサポートする"、RFC 4872、2007年5月。
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC4873] Berger、L.、Bryskin、I.、Papadimitriou、D。、およびA. Farrel、「Gmplsセグメントリカバリー」、RFC 4873、2007年5月。
[RFC4929] Andersson, L., Ed., and A. Farrel, Ed., "Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures", BCP 129, RFC 4929, June 2007.
[RFC4929] Andersson、L.、Ed。、およびA. Farrel、Ed。、「マルチプロトコルラベルスイッチング（MPLS）および一般化MPLS（GMPLS）プロトコルと手順の変更プロセス」、BCP 129、RFC 4929、2007年6月。
[RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls", RFC 4974, August 2007.
[RFC4974] Papadimitriou、D。およびA. Farrel、「一般化されたMPLS（GMPLS）RSVP-TEシグナル伝達拡張機能」、RFC 4974、2007年8月。
[RFC5063] Satyanarayana, A., Ed., and R. Rahman, Ed., "Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart", RFC 5063, October 2007.
[RFC5063] Satyanarayana、A.、ed。、およびR. Rahman、ed。、「GMPLSリソース予約プロトコル（RSVP）Graceful Restartへの拡張」、RFC 5063、2007年10月。
[RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 5151, February 2008.
[RFC5151] Farrel、A.、ed。、Ayyangar、A。、およびJp。Vasseur、「ドメイン間MPLSおよびGMPLSトラフィックエンジニアリング - リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 5151、2008年2月。
[RFC5287] Vainshtein, A. and Y(J). Stein, "Control Protocol Extensions for the Setup of Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks", RFC 5287, August 2008.
[RFC5287] Vainshtein、A。およびY（J）。Stein、「MPLSネットワークにおけるタイムディビジョンマルチプレックス（TDM）擬似ワイヤのセットアップのための制御プロトコル拡張」、RFC 5287、2008年8月。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008.
[RFC5305] Li、T。およびH. Smit、「IS-IS Traffic Engineering for Traffic Engineering」、RFC 5305、2008年10月。
[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008.
[RFC5307] Kompella、K.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするIS-IS拡張機能」、RFC 5307、2008年10月。
[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5316, December 2008.
[RFC5316] Chen、M.、Zhang、R。、およびX. Duan、「ISIS拡張は、自律システム（AS）MPLSおよびGMPLSトラフィックエンジニアリングをサポートする」、RFC 5316、2008年12月。
[RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5392, January 2009.
[RFC5392] Chen、M.、Zhang、R。、およびX. Duan、「自律システム（AS）MPLSおよびGMPLSトラフィックエンジニアリングをサポートするOSPF拡張」、RFC 5392、2009年1月。
[RFC5467] Berger, L., Takacs, A., Caviglia, D., Fedyk, D., and J. Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)", RFC 5467, March 2009.
[RFC5467] Berger、L.、Takacs、A.、Caviglia、D.、Fedyk、D。、およびJ. Meuric、「Gmpls非対称帯域幅の双方向ラベルスイッチドパス（LSP）」、RFC 5467、2009年3月。
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.
[RFC5586] Bocci、M.、Ed。、Vigoureux、M.、ed。、およびS. Bryant、ed。、「Mpls Generic Associated Channel」、RFC 5586、2009年6月。
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[RFC5654] Niven-Jenkins、B.、Ed。、Brungard、D.、Ed。、Betts、M.、Ed。、Sprecher、N.、およびS. Ueno、「MPLS輸送プロファイルの要件」、RFC 5654、2009年9月。
[RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010.
[RFC5860] Vigoureux、M.、Ed。、Ward、D.、Ed。、およびM. Betts、ed。、「MPLS輸送ネットワークの運用、管理、およびメンテナンスの要件（OAM）」、RFC 5860、2010年5月。
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
[RFC5921] Bocci、M.、ed。、Bryant、S.、ed。、Frost、D.、ed。、Levrau、L。、およびL. Berger、「輸送ネットワークのMPLSのフレームワーク」、RFC 5921、2010年7月。
[RFC5960] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS Transport Profile Data Plane Architecture", RFC 5960, August 2010.
[RFC5960] Frost、D.、Ed。、Bryant、S.、Ed。、およびM. Bocci、ed。、「MPLS Transport Profile Data Plane Architecture」、RFC 5960、2010年8月。
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
[RFC6370] Bocci、M.、Swallow、G。、およびE. Gray、「MPLS輸送プロファイル（MPLS-TP）識別子」、RFC 6370、2011年9月。
[RFC6371] Busi, I., Ed., and D. Allan, Ed., "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011.
[RFC6371] Busi、I.、ed。、およびD. Allan、ed。、「MPLSベースの輸送ネットワークの運用、管理、およびメンテナンスフレームワーク」、RFC 6371、2011年9月。
[RFC6372] Sprecher, N., Ed., and A. Farrel, Ed., "MPLS Transport Profile (MPLS-TP) Survivability Framework", RFC 6372, September 2011.
[RFC6372] Sprecher、N.、ed。、およびA. Farrel、ed。、「MPLS Transport Profile（MPLS-TP）Survivability Framework」、RFC 6372、2011年9月。
[CCAMP-OAM-EXT] Bellagamba, E., Ed., Andersson, L., Ed., Skoldstrom, P., Ed., Ward, D., and A. Takacs, "Configuration of Pro-Active Operations, Administration, and Maintenance (OAM) Functions for MPLS-based Transport Networks using RSVP-TE", Work in Progress, July 2011.
[CCAMP-OAM-EXT] Bellagamba、E.、ed。、Andersson、L.、ed。、Skoldstrom、P.、ed。、Ward、D.、およびA. Takacs、「プロイティブ運用の構成、管理、管理、およびRSVP-TEを使用したMPLSベースの輸送ネットワークのメンテナンス（OAM）機能 "、2011年7月の進行中の作業。
[CCAMP-OAM-FWK] Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE extensions for OAM Configuration", Work in Progress, July 2011.
[CCAMP-OAM-FWK] Takacs、A.、Fedyk、D。、およびJ. He、「GMPLS RSVP-TE拡張機能用の拡張機能」、2011年7月、作業中。
[GMPLS-PS] Takacs, A., Fondelli, F., and B. Tremblay, "GMPLS RSVP-TE Recovery Extension for data plane initiated reversion and protection timer signalling", Work in Progress, April 2011.
[GMPLS-PS] Takacs、A.、Fondelli、F。、およびB. Tremblay、「GMPLSデータプレーンのRSVP-TEリカバリエクステンションは、回復と保護タイマーシグナリングを開始した」、2011年4月の進行中。
[ITU.G8080.2006] International Telecommunication Union, "Architecture for the automatically switched optical network (ASON)", ITU-T Recommendation G.8080, June 2006.
[ITU.G8080.2006] International Telecommunication Union、「自動化された光ネットワーク（ASON）のアーキテクチャ」、ITU-T推奨G.8080、2006年6月。
[ITU.G8080.2008] International Telecommunication Union, "Architecture for the automatically switched optical network (ASON) Amendment 1", ITU-T Recommendation G.8080 Amendment 1, March 2008.
[ITU.G8080.2008] International Telecommunication Union、「自動的に切り替えられた光ネットワーク（ASON）修正1」のアーキテクチャ、ITU-T推奨G.8080修正1、2008年3月。
[MS-PW-DYNAMIC] Martini, L., Ed., Bocci, M., Ed., and F. Balus, Ed., "Dynamic Placement of Multi Segment Pseudowires", Work in Progress, July 2011.
[MS-PW-Dynamic] Martini、L.、Ed。、Bocci、M.、ed。、およびF. Balus編、「マルチセグメントPseudowiresの動的な配置」、2011年7月の進行中。
[NO-PHP] Ali, z., et al, "Non Penultimate Hop Popping Behavior and out-of-band mapping for RSVP-TE Label Switched Paths", Work in Progress, August 2011.
[No-PHP] Ali、Z。、et al、「RSVP-TEラベルの切り替えパスの非2番目のホップポップ動作と帯域外マッピング」、2011年8月の作業。
[PW-OAM] Zhang, F., Ed., Wu, B., Ed., and E. Bellagamba, Ed., " Label Distribution Protocol Extensions for Proactive Operations, Administration and Maintenance Configuration of Dynamic MPLS Transport Profile PseudoWire", Work in Progress, August 2011.
[PW-OAM] Zhang、F.、ed。、Wu、B.、ed。、およびE. Bellagamba、ed。、「ダイナミックMPLS輸送プロファイルPseudowireの積極的な運用、管理およびメンテナンス構成のためのラベル分布プロトコル拡張」、2011年8月に進行中の作業。
[PW-P2MPE] Aggarwal, R. and F. Jounay, "Point-to-Multipoint Pseudo-Wire Encapsulation", Work in Progress, March 2010.
[PW-P2MPE] Aggarwal、R。およびF. Jounay、「ポイントツーマルチポイント擬似ワイヤーカプセル化」、2010年3月、進行中の作業。
[PW-P2MPR] Jounay, F., Ed., Kamite, Y., Heron, G., and M. Bocci, "Requirements and Framework for Point-to-Multipoint Pseudowire", Work in Progress, July 2011.
[PW-P2MPR] Jounay、F.、Ed。、Kamite、Y.、Heron、G。、およびM. Bocci、「ポイントツーマルチポイントPseudowireの要件とフレームワーク」、2011年7月の作業。
[PW-RED] Muley, P., Ed., Aissaoui, M., Ed., and M. Bocci, "Pseudowire Redundancy", Work in Progress, July 2011.
[Pw-Red] Muley、P.、ed。、Aissaoui、M.、ed。、およびM. Bocci、「Pseudowire Redundancy」、2011年7月の作業。
[PW-REDB] Muley, P., Ed., and M. Aissaoui, Ed., "Preferential Forwarding Status Bit", Work in Progress, March 2011.
[Pw-Redb] Muley、P.、ed。、およびM. Aissaoui ed。、「優先転送ステータスビット」、2011年3月、進行中の作業。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P。、およびJ. Heinanen、「Multi-Protocol Label Switching」（MPLS）差別化されたサービスのサポート」、RFC 3270、2002年5月。
[RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols", RFC 3468, February 2003.
[RFC3468] Andersson、L。およびG. Swallow、「MPLOTOCOLラベルスイッチング（MPLS）ワーキンググループのMPLSシグナル伝達プロトコルに関するワーキンググループの決定」、RFC 3468、2003年2月。
[RFC3472] Ashwood-Smith, P., Ed., and L. Berger, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003.
[RFC3472] Ashwood-Smith、P.、ed。、およびL. Berger、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリング制約ベースのルーティングラベル分布プロトコル（CR-LDP）拡張機能」、RFC 3472、2003年1月。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3477] Kompella、K。およびY. Rekhter、「リソース予約プロトコルにおける非番号のリンク - トラフィックエンジニアリング（RSVP -TE）」、RFC 3477、2003年1月。
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.
[RFC3812] Srinivasan、C.、Viswanathan、A。、およびT. Nadeau、「マルチプロトコルラベルスイッチング（MPLS）トラフィックエンジニアリング（TE）管理情報ベース（MIB）」、RFC 3812、2004年6月。
[RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004.
[RFC3813] Srinivasan、C.、Viswanathan、A。、およびT. Nadeau、「マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチングルーター（LSR）管理情報ベース（MIB）」、RFC 3813、2004年6月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] Mannie、E.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）アーキテクチャ」、RFC 3945、2004年10月。
[RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985] Bryant、S.、ed。、およびP. Pate、ed。、「Pseudo Wire Emulation Edge-to-Edge（PWE3）Architecture」、RFC 3985、2005年3月。
[RFC4139] Papadimitriou, D., Drake, J., Ash, J., Farrel, A., and L. Ong, "Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON)", RFC 4139, July 2005.
[RFC4139] Papadimitriou、D.、Drake、J.、Ash、J.、Farrel、A。、およびL. Ong、「一般化されたMPLS（GMPLS）シグナリングの使用法および自動切り替え光ネットワーク（ASON）の拡張機能」の要件」RFC 4139、2005年7月。
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4201] Kompella、K.、Rekhter、Y.、およびL. Berger、「MPLS Traffic Engineering（TE）のリンクバンドリング」、RFC 4201、2005年10月。
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005.
[RFC4208] Swallow、G.、Drake、J.、Ishimatsu、H。、およびY. Rekhter、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）ユーザーネットワークインターフェイス（UNI）：リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）オーバーレイモデルのサポート」、RFC 4208、2005年10月。
[RFC4258] Brungard, D., Ed., "Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON)", RFC 4258, November 2005.
[RFC4258] Brungard、D.、ed。、「自動化された光ネットワーク（ASON）の一般化されたマルチプロトコルラベルスイッチング（GMPLS）ルーティングの要件」、RFC 4258、2005年11月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K。およびG. Swallow、「Multi-Protocol Label Switched（MPLS）データプレーン障害の検出」、RFC 4379、2006年2月。
[RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification", RFC 4426, March 2006.
[RFC4426] Lang、J.、Ed。、Rajagopalan、B.、ed。、およびD. Papadimitriou、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）回復機能仕様」、RFC 4426、2006年3月。
[RFC4427] Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006.
[RFC4427] Mannie、E.、ed。、およびD. Papadimitriou、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）のリカバリ（保護および回復）用語」、RFC 4427、2006年3月。
[RFC4553] Vainshtein, A., Ed., and YJ. Stein, Ed., "Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)", RFC 4553, June 2006.
[RFC4553] Vainshtein、A.、ed。、およびYJ。Stein、ed。、「パケット（TDM）（TDM）（SATOP）を超える構造と存在時の時間師団多重化（TDM）」、RFC 4553、2006年6月。
[RFC4618] Martini, L., Rosen, E., Heron, G., and A. Malis, "Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks", RFC 4618, September 2006.
[RFC4618] Martini、L.、Rosen、E.、Heron、G。、およびA. Malis、「MPLSネットワーク上のPPP/高レベルデータリンク制御（HDLC）の輸送のためのカプセル化方法」、RFC 4618、2006年9月。
[RFC4619] Martini, L., Ed., Kawa, C., Ed., and A. Malis, Ed., "Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks", RFC 4619, September 2006.
[RFC4619] Martini、L.、ed。、Kawa、C.、Ed。、およびA. Malis、ed。、「マルチプロトコルラベルスイッチング（MPLS）ネットワークを介したフレームリレーの輸送のためのカプセル化方法」、RFC 4619、2006年9月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「パス計算要素（PCE）ベースのアーキテクチャ」、RFC 4655、2006年8月。
[RFC4783] Berger, L., Ed., "GMPLS - Communication of Alarm Information", RFC 4783, December 2006.
[RFC4783] Berger、L.、ed。、「Gmpls-アラーム情報の通信」、RFC 4783、2006年12月。
[RFC4802] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", RFC 4802, February 2007.
[RFC4802] Nadeau、T.、ed。、およびA. Farrel、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング管理情報ベース」、RFC 4802、2007年2月。
[RFC4803] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base", RFC 4803, February 2007.
[RFC4803] Nadeau、T.、ed。、およびA. Farrel、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）ラベルスイッチングルーター（LSR）管理情報ベース」、RFC 4803、2007年2月。
[RFC4816] Malis, A., Martini, L., Brayley, J., and T. Walsh, "Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service", RFC 4816, February 2007.
[RFC4816] Malis、A.、Martini、L.、Brayley、J。、およびT. Walsh、「Pseudowire Emulation Edge-to-Edge（PWE3）非同期転送モード（ATM）透明細胞輸送サービス」、RFC 4816、2月2007年。
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC4875] Aggarwal、R.、ed。、ed。、Papadimitriou、D.、ed。、およびS. Yasukawa、ed。、「リソース予約プロトコルへの拡張 - ポイントツーマルチポイントTEラベルの交通工学（RSVP-TE）スイッチPaths（LSP） "、RFC 4875、2007年5月。
[RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto, "Attachment Individual Identifier (AII) Types for Aggregation", RFC 5003, September 2007.
[RFC5003] Metz、C.、Martini、L.、Balus、F。、およびJ. Sugimoto、「集約のためのアタッチメント個体識別子（AII）タイプ」、RFC 5003、2007年9月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、ed。、Minei、I.、ed。、およびB. Thomas、ed。、「LDP仕様」、RFC 5036、2007年10月。
[RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5085] Nadeau、T.、ed。、およびC. Pignataro、ed。、「Pseudowire Virtual Curned Connectivity Verification（VCCV）：Pseudowiresの制御チャネル」、RFC 5085、2007年12月。
[RFC5145] Shiomoto, K., Ed., "Framework for MPLS-TE to GMPLS Migration", RFC 5145, March 2008.
[RFC5145] Shiomoto、K。、ed。、「MPLS-TEからGMPLS移行のフレームワーク」、RFC 5145、2008年3月。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440] Vasseur、Jp。、ed。、およびJl。Le Roux、ed。、「パス計算要素（PCE）通信プロトコル（PCEP）」、RFC 5440、2009年3月。
[RFC5493] Caviglia, D., Bramanti, D., Li, D., and D. McDysan, "Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network", RFC 5493, April 2009.
[RFC5493] Caviglia、D.、Bramanti、D.、Li、D.、およびD. McDysan、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）ネットワークでの永続的な接続とスイッチ接続の変換の要件」、RFC 5493、4月2009年。
[RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, October 2009.
[RFC5659] Bocci、M。およびS. Bryant、「マルチセグメントの擬似ワイヤーエミュレーションエッジツーエッジのアーキテクチャ」、RFC 5659、2009年10月。
[RFC5787] Papadimitriou, D., "OSPFv2 Routing Protocols Extensions for Automatically Switched Optical Network (ASON) Routing", RFC 5787, March 2010.
[RFC5787] Papadimitriou、D。、「OSPFV2ルーティングプロトコル拡張機能の拡張機能（ASON）ルーティング」、RFC 5787、2010年3月。
[RFC5852] Caviglia, D., Ceccarelli, D., Bramanti, D., Li, D., and S. Bardalai, "RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network", RFC 5852, April 2010.
[RFC5852] Caviglia、D.、Ceccarelli、D.、Bramanti、D.、Li、D.、およびS. Bardalai、「GMPLS対応のコントロールプレーンへのLSPハンドオーバーのRSVP-TEシグナル伝達拡張輸送ネットワーク」、RFC 5852、2010年4月。
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC5884] Aggarwal、R.、Kompella、K.、Nadeau、T。、およびG. Swallow、「MPLSラベルスイッチドパス（LSP）の双方向転送検出（BFD）」、RFC 5884、2010年6月。
[RFC5885] Nadeau, T., Ed., and C. Pignataro, Ed., "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, June 2010.
[RFC5885] Nadeau、T.、ed。、およびC. Pignataro、ed。、「擬似ワイヤー仮想回路接続検証（VCCV）の双方向転送検出（BFD）」、RFC 5885、2010年6月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang、L.、ed。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。
[RFC5951] Lam, K., Mansfield, S., and E. Gray, "Network Management Requirements for MPLS-based Transport Networks", RFC 5951, September 2010.
[RFC5951] Lam、K.、Mansfield、S。、およびE. Gray、「MPLSベースの輸送ネットワークのネットワーク管理要件」、RFC 5951、2010年9月。
[RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)", RFC 6001, October 2010.
[RFC6001] Papadimitriou、D.、Vigoureux、M.、Shiomoto、K.、Brungard、D。、およびJl。Le Roux、「マルチレイヤーおよびマルチリージョンネットワーク（MLN/MRN）の一般化MPLS（GMPLS）プロトコル拡張」、RFC 6001、2010年10月。
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011.
[RFC6073] Martini、L.、Metz、C.、Nadeau、T.、Bocci、M。、およびM. Aissaoui、「セグメント化されたPseudowire」、RFC 6073、2011年1月。
[RFC6107] Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures for Dynamically Signaled Hierarchical Label Switched Paths", RFC 6107, February 2011.
[RFC6107] Shiomoto、K.、ed。、およびA. Farrel、ed。、「動的に信号された階層ラベルの切り替えパスの手順」、RFC 6107、2011年2月。
[RFC6215] Bocci, M., Levrau, L., and D. Frost, "MPLS Transport Profile User-to-Network and Network-to-Network Interfaces", RFC 6215, April 2011.
[RFC6215] Bocci、M.、Levrau、L。、およびD. Frost、「MPLS Transport Profileユーザーからネットワークへのインターフェイス」、RFC 6215、2011年4月。
[TE-MIB] Miyazawa, M., Otani, T., Kumaki, K., and T. Nadeau, "Traffic Engineering Database Management Information Base in support of MPLS-TE/GMPLS", Work in Progress, July 2011.
[Te-Mib] Miyazawa、M.、Otani、T.、Kumaki、K。、およびT. Nadeau、「MPLS-TE/GMPLSをサポートするトラフィックエンジニアリングデータベース管理情報ベース」、2011年7月の進行中。
[TP-MIB] King, D., Ed., and M. Venkatesan, Ed., "Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-based Management Overview", Work in Progress, August 2011.
[TP-Mib] King、D.、ed。、およびM. Venkatesan、ed。、「Multiprotocol Label Switching Transport Profepomer（MPLS-TP）MIBベースの管理の概要」、2011年8月の作業。
[TP-P2MP-FWK] Frost, D., Ed., Bocci, M., Ed., and L. Berger, Ed., "A Framework for Point-to-Multipoint MPLS in Transport Networks", Work in Progress, July 2011.
[TP-P2MP-FWK] Frost、D.、Ed。、Bocci、M.、ed。、およびL. Berger、ed。、「輸送ネットワークにおけるポイントツーマルチポイントMPLのフレームワーク」、進行中の作業、2011年7月。
[TP-RING] Weingarten, Y., Ed., "MPLS-TP Ring Protection", Work in Progress, June 2011
[TP-Ring] Weingarten、Y.、ed。、「MPLS-TP Ring Protection」、2011年6月の作業
Attila Takacs Ericsson 1. Laborc u. Budapest 1037 HUNGARY EMail: attila.takacs@ericsson.com
Attila Takacs Ericsson 1. Laborc u。Budapest 1037ハンガリーメール：attila.takacs@ericsson.com
Martin Vigoureux Alcatel-Lucent EMail: martin.vigoureux@alcatel-lucent.fr
Martin Vigoureux Alcatel-Lucentメール：martin.vigoureux@alcatel-lucent.fr
Elisa Bellagamba Ericsson Farogatan, 6 164 40, Kista, Stockholm SWEDEN EMail: elisa.bellagamba@ericsson.com
Elisa Bellagamba Ericsson Farogatan、6 164 40、Kista、ストックホルムスウェーデンメール：Elisa.bellagamba@ericsson.com
Authors' Addresses
著者のアドレス
Loa Andersson (editor) Ericsson Phone: +46 10 717 52 13 EMail: loa.andersson@ericsson.com
Loa Andersson（編集者）Ericsson電話：46 10 717 52 13メール：loa.andersson@ericsson.com
Lou Berger (editor) LabN Consulting, L.L.C. Phone: +1-301-468-9228 EMail: lberger@labn.net
Lou Berger（編集者）Labn Consulting、L.L.C。電話：1-301-468-9228メール：lberger@labn.net
Luyuan Fang (editor) Cisco Systems, Inc. 111 Wood Avenue South Iselin, NJ 08830 USA EMail: lufang@cisco.com
Luyuan Fang（編集者）Cisco Systems、Inc。111 Wood Avenue South Iselin、NJ 08830 USAメール：lufang@cisco.com
Nabil Bitar (editor) Verizon 60 Sylvan Road Waltham, MA 02451 USA EMail: nabil.n.bitar@verizon.com
Nabil Bitar（編集者）Verizon 60 Sylvan Road Waltham、MA 02451 USAメール：nabil.n.bitar@verizon.com
Eric Gray (editor) Ericsson 900 Chelmsford Street Lowell, MA 01851 USA Phone: +1 978 275 7470 EMail: Eric.Gray@Ericsson.com
エリック・グレイ（編集者）エリクソン900チェルムスフォード・ストリート・ローウェル、マサチューセッツ州01851 USA電話：1 978 275 7470メール：eric.gray@ericsson.com