Network Working Group B. Niven-Jenkins, Ed.
Request for Comments: 5654 BT
Category: Standards Track D. Brungard, Ed.
AT&T
M. Betts, Ed.
Huawei Technologies
N. Sprecher
Nokia Siemens Networks
S. Ueno
NTT Communications
September 2009
Requirements of an MPLS Transport Profile
Abstract
抽象
This document specifies the requirements of an MPLS Transport Profile (MPLS-TP). This document is a product of a joint effort of the International Telecommunications Union (ITU) and IETF to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by International Telecommunications Union - Telecommunications Standardization Sector (ITU-T).
この文書では、MPLSトランスポートプロファイル（MPLS-TP）の要件を指定します。この文書では、国際電気通信連合により定義されたパケットトランスポートネットワークの能力と機能をサポートするために、IETF MPLSとPWE3アーキテクチャ内MPLSトランスポートプロファイルを含むように国際電気通信連合（ITU）とIETFの共同の努力の産物であります - 電気通信標準化部門（ITU-T）。
This work is based on two sources of requirements: MPLS and PWE3 architectures as defined by IETF, and packet transport networks as defined by ITU-T.
ITU-Tによって定義されるようにIETFによって定義されたMPLSとPWE3アーキテクチャ、およびパケットトランスポートネットワーク：この作業は、要件の二つのソースに基づいています。
The requirements expressed in this document are for the behavior of the protocol mechanisms and procedures that constitute building blocks out of which the MPLS Transport Profile is constructed. The requirements are not implementation requirements.
この文書中で発現要件はMPLSトランスポートプロファイルが構築されるのうちのビルディングブロックを構成するプロトコルメカニズムおよび手順の動作のためのものです。要件は、実装要件ではありません。
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright and License Notice
著作権とライセンスに関するお知らせ
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (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 BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション4.eに記載されており、BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . 6
1.2.2. Definitions . . . . . . . . . . . . . . . . . . . . . 7
1.3. Transport Network Overview . . . . . . . . . . . . . . . . 10
1.4. Layer Network Overview . . . . . . . . . . . . . . . . . . 11
2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 12
2.1. General Requirements . . . . . . . . . . . . . . . . . . . 13
2.2. Layering Requirements . . . . . . . . . . . . . . . . . . 16
2.3. Data Plane Requirements . . . . . . . . . . . . . . . . . 17
2.4. Control Plane Requirements . . . . . . . . . . . . . . . . 18
2.5. Recovery Requirements . . . . . . . . . . . . . . . . . . 19
2.5.1. Data-Plane Behavior Requirements . . . . . . . . . . . 20
2.5.1.1. Protection . . . . . . . . . . . . . . . . . . . . 20
2.5.1.2. Sharing of Protection Resources . . . . . . . . . 21
2.5.2. Restoration . . . . . . . . . . . . . . . . . . . . . 21
2.5.3. Triggers for Protection, Restoration, and Reversion . 22
2.5.4. Management-Plane Operation of Protection and
Restoration . . . . . . . . . . . . . . . . . . . . . 22
2.5.5. Control Plane and In-Band OAM Operation of Recovery . 23
2.5.6. Topology-Specific Recovery Mechanisms . . . . . . . . 24
2.5.6.1. Ring Protection . . . . . . . . . . . . . . . . . 24
2.6. QoS Requirements . . . . . . . . . . . . . . . . . . . . . 27
3. Requirements Discussed in Other Documents . . . . . . . . . . 27
3.1. Network Management Requirements . . . . . . . . . . . . . 27
3.2. Operation, Administration, and Maintenance (OAM)
Requirements . . . . . . . . . . . . . . . . . . . . . . . 27
3.3. Network Performance-Monitoring Requirements . . . . . . . 28
3.4. Security Requirements . . . . . . . . . . . . . . . . . . 28
4. Security Considerations . . . . . . . . . . . . . . . . . . . 28
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1. Normative References . . . . . . . . . . . . . . . . . . . 29
6.2. Informative References . . . . . . . . . . . . . . . . . . 29
Bandwidth demand continues to grow worldwide, stimulated by the accelerating growth and penetration of new packet-based services and multimedia applications:
帯域幅の需要が加速成長と新しいパケットベースのサービスやマルチメディアアプリケーションの普及によって刺激、世界的に成長を続けて：
o Packet-based services such as Ethernet, Voice over IP (VoIP), Layer 2 (L2) / Layer 3 (L3) Virtual Private Networks (VPNs), IP television (IPTV), Radio Access Network (RAN) backhauling, etc.
など、イーサネット、ボイスオーバーIP（VoIP）の、レイヤ2（L2）/レイヤ3（L3）仮想プライベートネットワーク（VPN）、IPテレビ（IPTV）、無線アクセスネットワーク（RAN）バックホール、などのOパケットベースのサービス
o Applications with various bandwidth and Quality of Service (QoS) requirements.
様々な帯域幅とサービス品質（QoS）の要件にOアプリケーション。
This growth in demand has resulted in dramatic increases in access rates that are, in turn, driving dramatic increases in metro and core network bandwidth requirements.
需要のこの成長はメトロとコアネットワークの帯域幅要件の劇的な増加を駆動し、順番に、あるアクセス速度の劇的な増加をもたらしました。
Over the past two decades, the evolving optical transport infrastructure (Synchronous Optical Networking (SONET) / Synchronous Digital Hierarchy (SDH), Optical Transport Network (OTN)) has provided carriers with a high benchmark for reliability and operational simplicity.
過去20年間、進化の光伝送インフラストラクチャ（同期光ネットワーク（SONET）/同期デジタル階層（SDH）、光トランスポートネットワーク（OTN））は、信頼性と運用の簡素化のための高いベンチマークでキャリアを提供してきました。
With the movement towards packet-based services, the transport network has to evolve to encompass the provision of packet-aware capabilities while enabling carriers to leverage their installed, as well as planned, transport infrastructure investments.
パケット・ベースのサービスに向けた動きでは、トランスポートネットワークは、彼らがインストールされ、同様に計画された交通インフラ投資を活用するためにキャリアを可能にしながら、パケットを意識した機能の提供を包含するように進化しています。
Carriers are in need of technologies capable of efficiently supporting packet-based services and applications on their transport networks with guaranteed Service Level Agreements (SLAs). The need to increase their revenue while remaining competitive forces operators to look for the lowest network Total Cost of Ownership (TCO). Investment in equipment and facilities (Capital Expenditure (CAPEX)) and Operational Expenditure (OPEX) should be minimized.
キャリアが効率的に保証されたサービスレベル契約（SLA）とのトランスポートネットワークにパケットベースのサービスやアプリケーションをサポートできる技術を必要としています。オーナーシップ（TCO）の最低のネットワークトータルコストを探すために、競争力の力演算子を維持しながら自分の収入を増やす必要があります。機器・設備（設備投資（CAPEX））および運用経費（OPEX）への投資は最小限にすべきです。
There are a number of technology options for carriers to meet the challenge of increased service sophistication and transport efficiency, with increasing usage of hybrid packet-transport and circuit-transport technology solutions. To realize these goals, it is essential that packet-transport technology be available that can support the same high benchmarks for reliability and operational simplicity set by SDH/SONET and OTN technologies.
ハイブリッドパケット・トランスポートと回線輸送技術ソリューションの使用の増加に伴って、増加したサービスの高度化と輸送効率の課題に対応するために、キャリアのための技術オプションがいくつかあります。これらの目標を実現するためには、パケット・トランスポート・テクノロジーは、信頼性およびSDH / SONETやOTN技術によって設定された運用の簡素化のために同じ高ベンチマークをサポートできることを利用できることが不可欠です。
Furthermore, for carriers it is important that operation of such packet transport networks should preserve the look-and-feel to which carriers have become accustomed in deploying their optical transport networks, while providing common, multi-layer operations, resiliency, control, and multi-technology management.
また、キャリアのためのそのようなパケットトランスポートネットワークの動作は一般的に、マルチレイヤ・オペレーション、弾力性、制御、および複数を提供しながら、キャリアは、その光伝送ネットワークを展開に慣れているためにどのルック・アンド・フィールを維持することが重要です - 技術経営。
Transport carriers require control and deterministic usage of network resources. They need end-to-end control to engineer network paths and to efficiently utilize network resources. They require capabilities to support static (management-plane-based) or dynamic (control-plane-based) provisioning of deterministic, protected, and secured services and their associated resources.
輸送担体は、制御とネットワーク資源の決定論的な使用を必要としています。彼らは、ネットワークパスを設計すると、ネットワークリソースを効率的に利用するために、エンドツーエンドの制御を必要としています。彼らは、保護された、決定論、および固定サービス及びそれらに関連するリソースの静的（管理プレーンベース）または動的（コントロールプレーンベース）のプロビジョニングをサポートする能力を必要とします。
It is also important to ensure smooth interworking of the packet transport network with other existing/legacy packet networks, and provide mappings to enable packet transport carriage over a variety of transport network infrastructures. The latter has been termed vertical interworking, and is also known as client/server or network interworking. The former has been termed horizontal interworking, and is also known as peer-partition or service interworking. For more details on interworking and some of the issues that may arise (especially with horizontal interworking), see G.805 [ITU.G805.2000] and Y.1401 [ITU.Y1401.2008].
これは、他の既存/レガシー・パケット・ネットワークのパケットトランスポートネットワークの円滑な相互動作を確保するため、およびトランスポートネットワークインフラストラクチャのさまざまな上パケットトランスポート台車を有効にするマッピングを提供することも重要です。後者は、垂直方向のインターワーキングと呼ばれている、ともクライアント/サーバやネットワークインターワーキングとして知られています。前者は、水平インターワーキングと呼ばれており、また、ピア・パーティションまたはサービスインターワーキングとして知られています。インターワーキング（特に水平インターワーキングで）発生する可能性のある問題のいくつかの詳細については、G.805 [ITU.G805.2000]とY.1401 [ITU.Y1401.2008]参照。
Multi-Protocol Label Switching (MPLS) is a maturing packet technology and it is already playing an important role in transport networks and services. However, not all of MPLS's capabilities and mechanisms are needed and/or consistent with transport network operations. There are also transport technology characteristics that are not currently reflected in MPLS. Therefore, there is the need to define an MPLS Transport Profile (MPLS-TP) that supports the capabilities and functionalities needed for packet-transport network services and operations through combining the packet experience of MPLS with the operational experience and practices of existing transport networks.
マルチプロトコルラベルスイッチング（MPLS）は、成熟したパケットの技術であり、それはすでに輸送ネットワークとサービスで重要な役割を果たしています。ただし、すべてのMPLSの機能とメカニズムのは、必要に応じて、および/またはトランスポート・ネットワークの運用と一致しています。現在、MPLSには反映されていない技術特性を輸送もあります。そのため、既存のトランスポート・ネットワークの運用経験と実践とMPLSのパケット経験を組み合わせることによって、パケット・トランスポート・ネットワーク・サービスおよび操作に必要な能力と機能をサポートしているMPLSトランスポートプロファイル（MPLS-TP）を定義する必要があります。
MPLS-TP will enable the deployment of packet-based transport networks that will efficiently scale to support packet services in a simple and cost-effective way. MPLS-TP needs to combine the necessary existing capabilities of MPLS with additional minimal mechanisms in order that it can be used in a transport role.
MPLS-TPは、効率的にシンプルかつ費用対効果の高い方法でパケットサービスをサポートするように拡張されますパケットベースのトランスポート・ネットワークの展開を可能にします。 MPLS-TPは、トランスポートの役割で使用できるようにするために追加的な最小限のメカニズムとMPLSの必要な既存の機能を組み合わせることが必要です。
This document specifies the requirements of an MPLS Transport Profile (MPLS-TP). The requirements are for the behavior of the protocol mechanisms and procedures that constitute building blocks out of which the MPLS Transport Profile is constructed. That is, the requirements indicate what features are to be available in the MPLS toolkit for use by MPLS-TP. The requirements in this document do not describe what functions an MPLS-TP implementation supports. The purpose of this document is to identify the toolkit and any new protocol work that is required.
この文書では、MPLSトランスポートプロファイル（MPLS-TP）の要件を指定します。要件は、MPLSトランスポートプロファイルが構築されるのうちのビルディングブロックを構成するプロトコルメカニズムおよび手順の動作のためのものです。これは、要件がMPLS-TPが使用するためのMPLSツールキットで利用できるようにするためであるかの特徴を示しています。この文書の要件は、MPLS-TPの実装がサポートする機能内容を説明していません。このドキュメントの目的は、ツールキットと要求され、新しいプロトコルの仕事を識別することです。
This document is a product of a joint ITU-T and IETF effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by ITU-T. The document is a requirements specification, but is presented on the Standards Track so that it can be more easily cited as a normative reference from within the work of the ITU-T.
この文書では、ジョイントITU-TとITU-Tによって定義されるようなパケットトランスポートネットワークの能力と機能性をサポートするために、IETF MPLSとPWE3アーキテクチャ内MPLSトランスポートプロファイルを含むようにIETF努力の産物です。文書は、要求仕様であるが、それはより容易にITU-Tの作業内から規範的参照として引用することができるように標準化過程に提示されています。
This work is based on two sources of requirements, MPLS and PWE3 architectures as defined by IETF and packet transport networks as defined by ITU-T. The requirements of MPLS-TP are provided below. The relevant functions of MPLS and PWE3 are included in MPLS-TP, except where explicitly excluded. 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].
ITU-Tによって定義されたIETF、パケットトランスポートネットワークによって定義されるように、この作業は必要条件、MPLS及びPWE3アーキテクチャの二つのソースに基づいています。 MPLS-TPの要件は、以下に提供されます。 MPLSとPWE3の関連する機能は、明示的に除外された場合を除き、MPLS-TPに含まれています。 MPLS-TPの要件を満たすように定義されているすべての新しい機能は、[RFC4929]あたりとしてIETF合意プロセスを経てIETFの中で合意されなければなりません。
MPLS-TP transport paths may be established using static or dynamic configuration. It should be noted that the MPLS-TP network and its transport paths can always be operated fully (including OAM and protection capabilities) in the absence of any control plane.
MPLS-TPの搬送経路は、静的または動的な構成を使用して確立することができます。 MPLS-TPネットワークとその搬送経路が常に制御プレーンの非存在下で（OAM及び保護機能を含む）を完全に動作させることができることに留意すべきです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Although this document is not a protocol specification, the use of this language clarifies the instructions to protocol designers producing solutions that satisfy the requirements set out in this document.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [RFC2119]に記載されているように解釈されます。このドキュメントはプロトコル仕様ではありませんが、この言語の使用は、本文書に定める要件を満たすソリューションを生産するプロトコル設計者に指示を明確にしています。
Note: Mapping between the terms in this section and ITU-T terminology is described in [TP-TERMS].
注：このセクションの用語間のマッピングとITU-Tの用語は[TP-TERMS]に記載されています。
The recovery requirements in this document use the recovery terminology defined in RFC 4427 [RFC4427]; this is applied to both control-plane- and management-plane-based operations of MPLS-TP transport paths.
このドキュメントのリカバリ要件は、RFC 4427で定義されている復旧用語[RFC4427]を使用します。これは、制御plane-とMPLS-TPの搬送路の管理プレーンベースの操作の両方に適用されます。
ASON: Automatically Switched Optical Network
ASON：自動的に交換光ネットワーク
ATM: Asynchronous Transfer Mode
ATM：非同期転送モード
CAPEX: Capital Expenditure
CAPEX：設備投資
CE: Customer Edge
CE：カスタマーエッジ
FR: Frame Relay
FR：フレームリレー
GMPLS: Generalized Multi-Protocol Label Switching
GMPLS：一般マルチプロトコルラベルスイッチング
IGP: Interior Gateway Protocol
IGP：インテリアゲートウェイプロトコル
IPTV: IP Television
IPTV：IPテレビ
L2: Layer 2
番号：リア
L3: Layer 3
L3：レイヤ3
LSP: Label Switched Path
LSP：ラベルスイッチパス
LSR: Label Switching Router
LSR：ラベルスイッチングルータ
MPLS: Multi-Protocol Label Switching
MPLS：マルチプロトコルラベルスイッチング
OAM: Operations, Administration, and Maintenance
OAM：オペレーション、管理、およびメンテナンス
OPEX: Operational Expenditure
OPEX：運用経費
OSI: Open Systems Interconnection
OSI：開放型システム間相互接続
OTN: Optical Transport Network
RE：眼鏡交通Netvork
P2MP: Point to Multipoint
P2MP：ポイント対多
P2P: Point to Point
P2P：ポイントツーポイント
PDU: Protocol Data Unit
PDU：プロトコルデータユニット
PSC: Protection State Coordination
PSC：保護州立コーディネーション
PW: Pseudowire
PO：Psefdoviri
QoS: Quality of Service
QoSの：サービス品質
SDH: Synchronous Digital Hierarchy
SDH：同期デジタル階層
SLA: Service Level Agreement
SLA：サービスレベルアグリーメント
SLS: Service Level Specification
SLS：サービスレベルの仕様
S-PE: Switching Provider Edge
S-PE：スイッチングプロバイダーエッジ
SONET: Synchronous Optical Network
SONET：同期光ネットワーク
SRLG: Shared Risk Link Group
SRLG：共有リスクリンクグループ
TCO: Total Cost of Ownership
TCO：総所有コスト
T-PE: Terminating Provider Edge
T-PE：終端プロバイダエッジ
VoIP: Voice over IP
VoIPの：ボイスオーバーIP
VPN: Virtual Private Network
VPN：仮想プライベートネットワーク
WDM: Wavelength Division Multiplexing
WDM：Wavelength Division Multiplexing：波長分割多重
Note: The definition of "segment" in a GMPLS/ASON context (i.e., as defined in RFC4397 [RFC4397]) encompasses both "segment" and "concatenated segment" as defined in this document.
注：この文書で定義されているGMPLS / ASONの文脈における「セグメント」の定義（即ち、RFC4397で定義されるように[RFC4397]）は、「セグメント」及び「連結セグメント」の両方を包含する。
Associated bidirectional path: A path that supports traffic flow in both directions but that is constructed from a pair of unidirectional paths (one for each direction) that are associated with one another at the path's ingress/egress points. The forward and backward directions are setup, monitored, and protected independently. As a consequence, they may or may not follow the same route (links and nodes) across the network.
関連する双方向パス：両方向のトラフィックフローをサポートするが、それはパスの入口/出口点で互いに関連付けられている一方向のパス（各方向に1つ）の対から構成されているパス。前後方向は、セットアップ、監視し、独立して保護されています。その結果、それらは、あるいはネットワークを介して同一の経路（リンク及びノード）従わなくてもよいです。
Client layer network: In a client/server relationship (see G.805 [ITU.G805.2000]), the client layer network receives a (transport) service from the lower server layer network (usually the layer network under consideration).
クライアント層ネットワーク：クライアント/サーバ関係では（G.805 [ITU.G805.2000]を参照）、クライアントレイヤネットワークは、下位サーバレイヤネットワーク（考慮中の通常レイヤネットワーク）から（トランスポート）サービスの提供を受けます。
Concatenated Segment: A serial-compound link connection as defined in G.805 [ITU.G805.2000]. A concatenated segment is a contiguous part of an LSP or multi-segment PW that comprises a set of segments and their interconnecting nodes in sequence. See also "Segment".
連結セグメント：G.805 [ITU.G805.2000]で定義されるようにシリアル化合物リンク接続。連結セグメントは、セグメントおよび配列におけるそれらの相互接続ノードのセットを含むLSPまたはマルチセグメントPWの連続した部分です。また、「セグメント」を参照してください。
Control Plane: Within the scope of this document, the control plane performs transport path control functions. Through signalling, the control plane sets up, modifies and releases transport paths, and may recover a transport path in case of a failure. The control plane also performs other functions in support of transport path control, such as routing information dissemination.
制御プレーンは、この文書の範囲内では、制御プレーンは、搬送経路制御機能を実行します。シグナリングを介して、制御プレーンは、修正及び解放する搬送路を設定し、障害が発生した場合の搬送経路を回復することができます。制御プレーンはまた、情報発信をルーティングするよう搬送経路制御をサポートする他の機能を実行します。
Co-routed Bidirectional path: A path where the forward and backward directions follow the same route (links and nodes) across the network. Both directions are setup, monitored and protected as a single entity. A transport network path is typically co-routed.
共ルーティング双方向パス：前後方向がネットワークを介して同一の経路（リンク及びノード）に従う経路。どちらの方向は、セットアップ、監視され、単一のエンティティとして保護されています。トランスポートネットワークパスは、一般的に共同ルーティングされています。
Domain: A domain represents a collection of entities (for example network elements) that are grouped for a particular purpose, examples of which are administrative and/or managerial responsibilities, trust relationships, addressing schemes, infrastructure capabilities, aggregation, survivability techniques, distributions of control functionality, etc. Examples of such domains include IGP areas and Autonomous Systems.
ドメイン：ドメインは、特定の目的のためにグループ化されている（例えば、ネットワーク要素のための）エンティティの収集、管理、および/または経営責任、信頼関係、アドレス指定方式、インフラストラクチャー機能、凝集、生存技術の分布である例を表します制御機能、等は、このようなドメインの例はIGP領域と自律システムを含みます。
Layer network: Layer network is defined in G.805 [ITU.G805.2000]. A layer network provides for the transfer of client information and independent operation of the client OAM. A layer network may be described in a service context as follows: one layer network may provide a (transport) service to a higher client layer network and may, in turn, be a client to a lower-layer network. A layer network is a logical construction somewhat independent of arrangement or composition of physical network elements. A particular physical network element may topologically belong to more than one layer network, depending on the actions it takes on the encapsulation associated with the logical layers (e.g., the label stack), and thus could be modeled as multiple logical elements. A layer network may consist of one or more sublayers. Section 1.4 provides a more detailed overview of what constitutes a layer network. For additional explanation of how layer networks relate to the OSI concept of layering, see Appendix I of Y.2611 [ITU.Y2611.2006].
レイヤネットワーク：レイヤネットワークはG.805 [ITU.G805.2000]で定義されています。レイヤネットワークは、クライアントOAMのクライアント情報の転送と独立した動作を提供します。次のようにレイヤネットワークは、サービスコンテキストで説明することができる：1層のネットワークは、より高いクライアントレイヤネットワークに（トランスポート）サービスを提供することができると、今度は、下層ネットワークへのクライアントであってもよいです。レイヤネットワークは、物理ネットワーク要素の配列または組成物の幾分独立した論理構造です。特定の物理ネットワーク要素は、トポロジー的にそれが論理層（例えば、ラベルスタック）に関連付けられ、したがって、複数の論理要素としてモデル化することができるカプセルをとるアクションに応じて、複数のレイヤのネットワークに属していてもよいです。レイヤネットワークは、一つ以上の副層から構成することができます。セクション1.4は、レイヤネットワークを構成するもののより詳細な概要を提供します。レイヤネットワークは階層化のOSIの概念とどのように関係するかの追加的な説明については、Y.2611 [ITU.Y2611.2006]の付録Iを参照してください。
Link: A physical or logical connection between a pair of LSRs that are adjacent at the (sub)layer network under consideration. A link may carry zero, one, or more LSPs or PWs. A packet entering a link will emerge with the same label-stack entry values.
リンク：検討中の（サブ）レイヤネットワークにおける隣接しているのLSRの対の間の物理的または論理的な接続。リンクは、ゼロ、1、または複数のLSPまたはPWをを運ぶことができます。リンクに入るパケットは、同じラベルスタックエントリー値で出てきます。
MPLS-TP Logical Ring: An MPLS-TP logical ring is constructed from a set of LSRs and logical data links (such as MPLS-TP LSP tunnels or MPLS-TP pseudowires) and physical data links that form a ring topology.
MPLS-TP論理リング：MPLS-TPの論理リングのLSRと（例えば、MPLS-TP LSPトンネル又はMPLS-TPの疑似回線のような）論理データリンク及びリングトポロジを形成する物理データ・リンクのセットから構成されています。
Path: See Transport Path.
パス：搬送経路を参照してください。
MPLS-TP Physical Ring: An MPLS-TP physical ring is constructed from a set of LSRs and physical data links that form a ring topology.
MPLS-TP物理リング：MPLS-TP物理リングをのLSR及びリングトポロジを形成する物理データ・リンクのセットから構成されています。
MPLS-TP Ring Topology: In an MPLS-TP ring topology, each LSR is connected to exactly two other LSRs, each via a single point-to-point bidirectional MPLS-TP capable link. A ring may also be constructed from only two LSRs where there are also exactly two links. Rings may be connected to other LSRs to form a larger network. Traffic originating or terminating outside the ring may be carried over the ring. Client network nodes (such as CEs) may be connected directly to an LSR in the ring.
MPLS-TPリングトポロジー：MPLS-TPリングトポロジでは、各LSRが正確に二つの他のLSR、シングルポイント・ツー・ポイントの双方向MPLS-TP可能なリンクを介してそれぞれ接続されています。リングはまた、正確に二つのリンクが存在するただ2つのLSRから構成されてもよいです。リングは、大規模なネットワークを形成するために、他のLSRに接続されてもよいです。環外発信又は終端トラフィックがリング上に実施することができます。 （例えばCEのような）クライアント・ネットワーク・ノードは、リング内のLSRに直接接続されてもよいです。
Section Layer Network: A section layer is a server layer (which may be MPLS-TP or a different technology) that provides for the transfer of the section-layer client information between adjacent nodes in the transport-path layer or transport-service layer. A section layer may provide for aggregation of multiple MPLS-TP clients. Note that G.805 [ITU.G805.2000] defines the section layer as one of the two layer networks in a transmission-media layer network. The other layer network is the physical-media layer network.
セクションレイヤネットワーク：セクション層は搬送路層やトランスポート・サービス層内の隣接するノード間のセクションレイヤクライアント情報の転送を提供する（MPLS-TP又は異なる技術であってもよい）サーバ層です。セクション層は、複数のMPLS-TPクライアントの集合を提供することができます。 G.805は、[ITU.G805.2000】伝送媒体層ネットワーク内の2つの層のネットワークの一つとして、セクション層を定義することに留意されたいです。他のレイヤネットワークは、物理メディア層ネットワークです。
Segment: A link connection as defined in G.805 [ITU.G805.2000]. A segment is the part of an LSP that traverses a single link or the part of a PW that traverses a single link (i.e., that connects a pair of adjacent {Switching|Terminating} Provider Edges). See also "Concatenated Segment".
セグメント：G.805 [ITU.G805.2000]で定義されるようにリンク接続。セグメントは、単一リンク又は単一のリンクを横断PWの一部を横断するLSPの一部である（|プロバイダエッジすなわち、それは隣接{終端スイッチング}の対を接続します）。また、「連結セグメント」を参照してください。
Server Layer Network: In a client/server relationship (see G.805 [ITU.G805.2000]), the server layer network provides a (transport) service to the higher client layer network (usually the layer network under consideration).
サーバーレイヤーネットワーク：クライアント/サーバ関係で（G.805 [ITU.G805.2000]を参照）、サーバレイヤネットワークは、より高いクライアントレイヤネットワーク（検討中の通常レイヤネットワーク）に（トランスポート）サービスを提供しています。
Sublayer: Sublayer is defined in G.805 [ITU.G805.2000]. The distinction between a layer network and a sublayer is that a sublayer is not directly accessible to clients outside of its encapsulating layer network and offers no direct transport service for a higher layer (client) network.
サブレイヤ：副層はG.805 [ITU.G805.2000]で定義されています。レイヤネットワークと副層の区別はサブレイヤは、その封止層ネットワークの外部のクライアントに直接アクセスすることはできませんし、上位層（クライアント）ネットワークのための直接的な輸送サービスを提供しないということです。
Switching Provider Edge (S-PE): See [MS-PW-ARCH].
プロバイダエッジ（S-PE）を切り替える：[MS-PW-ARCH]を参照。
Terminating Provider Edge (T-PE): See [MS-PW-ARCH].
終端プロバイダエッジ（T-PE）：参照[MS-PW-ARCH]。
Transport Path: A network connection as defined in G.805 [ITU.G805.2000]. In an MPLS-TP environment, a transport path corresponds to an LSP or a PW.
トランスポートパス：[ITU.G805.2000] G.805で定義されているネットワーク接続。 MPLS-TP環境では、搬送経路は、LSPまたはPWに対応します。
Transport Path Layer: A (sub)layer network that provides point-to-point or point-to-multipoint transport paths. It provides OAM that is independent of the clients that it is transporting.
搬送路層：ポイントツーポイントまたはポイントツーマルチポイント搬送路を提供する（サブ）レイヤネットワーク。それが輸送され、クライアントから独立したOAMを提供します。
Transport Service Layer: A layer network in which transport paths are used to carry a customer's (individual or bundled) service (may be point-to-point, point-to-multipoint, or multipoint-to-multipoint services).
輸送サービス層：トランスポート・パスは、顧客の（個人またはバンドル）を運ぶために使用された層のネットワークサービス（ポイント・ツー・ポイント、ポイント・ツー・マルチポイント、またはマルチポイント・ツー・マルチポイントサービスでもよいです）。
Transmission Media Layer: A layer network, consisting of a section layer network and a physical layer network as defined in G.805 [ITU.G805.2000], that provides sections (two-port point-to-point connections) to carry the aggregate of network-transport path or network-service layers on various physical media.
伝送媒体層：レイヤネットワーク、G.805で定義されてセクションレイヤネットワークと物理層ネットワークからなる[ITU.G805.2000]、搬送するセクション（2ポートのポイントツーポイント接続）を提供様々な物理媒体上のネットワーク輸送経路またはネットワークサービス層の集合体。
Unidirectional Path: A path that supports traffic flow in only one direction.
単方向パス：一方向のみのトラフィックフローをサポートしてパス。
The connectivity service is the basic service provided by a transport network. The purpose of a transport network is to carry its customer traffic (i.e., the stream of customer PDUs or customer bits, including overhead) between end points in the transport network (typically over several intermediate nodes). The connectivity services offered to customers are typically aggregated into large transport paths with long holding times and OAM that is independent (of the client OAM), which contribute to enabling the efficient and reliable operation of the transport network. These transport paths are modified infrequently.
接続サービスは、トランスポートネットワークが提供する基本的なサービスです。トランスポートネットワークの目的は、（典型的にはいくつかの中間ノードにわたって）その顧客のトラフィックトランスポートネットワーク内のエンドポイント間（オーバーヘッドを含む顧客のPDUまたは顧客ビットの、すなわち、ストリーム）を搬送することです。顧客に提供される接続サービスは、典型的には、トランスポートネットワークの効率的かつ信頼性の高い動作を可能に寄与する（クライアントOAMの）独立している長い保持時間とOAMと大型輸送経路に集約されます。これらの搬送路はまれに修正されます。
Quality-of-service mechanisms are required in the packet transport network to ensure the prioritization of critical services, to guarantee bandwidth, and to control jitter and delay. A transport network must provide the means to meet the quality-of-service objectives of its clients. This is achieved by providing a mechanism for client network service demarcation for the network path together with an associated network resiliency mechanism.
サービス品質のメカニズムは、重要なサービスの優先順位付けを確実にするために、帯域幅を保証するために、ジッタおよび遅延を制御するパケットトランスポートネットワークで必要とされています。トランスポート・ネットワークは、顧客のサービス品質の目標を達成するための手段を提供しなければなりません。これは、関連するネットワークの復元機構と一緒にネットワーク・パスのためのクライアント・ネットワーク・サービス区分のための機構を提供することによって達成されます。
Aggregation is beneficial for achieving scalability and security since:
集計は、以来、スケーラビリティとセキュリティを実現するために有益です：
1. It reduces the number of provisioning and forwarding states in the network core.
1.これは、ネットワークコアにおけるプロビジョニングおよび転送状態の数を減少させます。
2. It reduces load and the cost of implementing service assurance and fault management.
2.それは、負荷およびサービス保証と障害管理を実現するためのコストを削減します。
3. Customer traffic is encapsulated and layer-associated OAM overhead is added. This allows complete isolation of customer traffic and its management from carrier operations.
3.お客様のトラフィックがカプセル化され、層に関連OAMオーバーヘッドが追加されます。これは、顧客のトラフィックとキャリア事業から経営を完全に分離することができます。
An important attribute of a transport network is that it is able to function regardless of which clients are using its connection service or over which transmission media it is running. From a functional and operational point of view, the client, transport network, and server layers are independent layer networks. Another key characteristic of transport networks is the capability to maintain the integrity of the client across the transport network. A transport network must also provide a method of service monitoring in order to verify the delivery of an agreed quality of service. This is enabled by means of carrier-grade OAM tools.
トランスポート・ネットワークの重要な属性は、関係なく、クライアントはその接続サービスを利用しているか、それが実行されている伝送媒体を介してその機能することができるということです。ビュー、クライアント、トランスポートネットワーク、およびサーバ層の機能と動作点からは独立した層のネットワークがあります。トランスポート・ネットワークのもう一つの重要な特徴は、トランスポートネットワークを介してクライアントの整合性を維持するための機能です。トランスポート・ネットワークは、サービスの合意された品質の配信を確認するためにサービス監視の方法を提供しなければなりません。これは、キャリアグレードのOAMツールによって有効になります。
Customer traffic is first encapsulated within the transport-service layer network. The transport service layer network signals may then be aggregated into a transport-path layer network for transport through the network in order to optimize network management. Transport-service layer network OAM is used to monitor the transport integrity of the customer traffic, and transport-path layer network OAM is used to monitor the transport integrity of the aggregates. At any hop, the aggregated signals may be further aggregated in lower-layer transport network paths for transport across intermediate shared links. The transport service layer network signals are extracted at the edges of aggregation domains, and are either delivered to the customer or forwarded to another domain. In the core of the network, only the transport path layer network signals are monitored at intermediate points; individual transport service layer network signals are monitored at the network boundary. Although the connectivity of the transport-service layer network may be point-to-point, point-to-multipoint, or multipoint-to-multipoint, the transport-path layer network only provides point-to-point or point-to-multipoint transport paths, which are used to carry aggregates of transport service layer network traffic.
カスタマートラフィックは、最初のトランスポート・サービス・レイヤネットワーク内にカプセル化されます。トランスポートサービスレイヤネットワーク信号は、次いで、ネットワーク管理を最適化するために、ネットワークを介して搬送するための搬送パスレイヤネットワークに集約することができます。トランスポートサービス層ネットワークOAMは、顧客のトラフィックの輸送健全性を監視するために使用され、およびトランスポートパスレイヤネットワークOAMは、凝集体の輸送健全性を監視するために使用されます。任意のホップで、凝集した信号は、さらに、中間共有リンクを横切って輸送するための下層トランスポートネットワーク経路に集約することができます。トランスポートサービス層ネットワーク信号は、凝集ドメインの端部で抽出され、いずれかの顧客に配送または別のドメインに転送されます。ネットワークのコアで、唯一の搬送路層ネットワーク信号は、中間点で監視されています。個々のトランスポートサービスレイヤネットワーク信号は、ネットワーク境界で監視されています。トランスポート・サービスのレイヤネットワークの接続は、ポイントツーポイント、ポイントツーマルチポイント、またはマルチポイントツーマルチポイントであってもよいが、搬送パスレイヤネットワークは、ポイントツーポイントまたはポイントツーマルチポイント提供しますトランスポートサービスレイヤネットワークトラフィックの凝集体を搬送するために使用される搬送路、。
A layer network provides its clients with a transport service and the operation of the layer network is independent of whatever client happens to use the layer network. Information that passes between any client to the layer network is common to all clients and is the minimum needed to be consistent with the definition of the transport service offered. The client layer network can be connectionless, connection-oriented packet switched, or circuit switched. The transport service transfers a payload such that the client can populate the payload without affecting any operation within the serving layer network. Here, payload means: o an individual packet payload (for connectionless networks),
レイヤネットワークは、輸送サービスを顧客に提供し、レイヤネットワークの動作は、レイヤネットワークを使用するために起こるものは何でもクライアントとは無関係です。レイヤネットワークへのクライアントの間を通過する情報は、すべてのクライアントに共通であり、提供する輸送サービスの定義と一致するために必要な最小値です。クライアントレイヤネットワークは、コネクション、接続指向のパケットを切り替えることができる、または回線交換しました。トランスポートサービスは、クライアントが提供するレイヤネットワーク内の任意の動作に影響を与えることなく、ペイロードを移入することができるように、ペイロードを転送します。ここで、ペイロード手段：個々のパケットペイロードO（コネクションレスネットワーク用）
o a sequence of packet payloads (for connection-oriented packet-switched networks), or
O（コネクション型パケット交換ネットワークの）パケットペイロードの配列、又は
o a deterministic schedule of payloads (for circuit-switched networks).
（回線交換ネットワークの）ペイロードの決定的スケジュールO。
The operations within a layer network that are independent of its clients include the control of forwarding, the control of resource reservation, the control of traffic de-merging, and the OAM and recovery of the transport service. All of these operations are internal to a layer network. By definition, a layer network does not rely on any client information to perform these operations, and therefore all information required to perform these operations is independent of whatever client is using the layer network.
そのクライアントから独立している層のネットワーク内の操作は、転送の制御、リソース予約の制御、トラフィックデマージの制御、及びOAM及び輸送サービスの回復を含みます。これらの操作はすべて、レイヤネットワークの内部にあります。定義では、レイヤネットワークは、これらの操作を実行するために、任意のクライアント情報に依存しないため、これらの操作を実行するために必要なすべての情報は、レイヤネットワークを使用しているものは何でもクライアントとは無関係です。
A layer network will have consistent features in order to support the control of forwarding, resource reservation, OAM, and recovery. For example, a layer network will have a common addressing scheme for the end points of the transport service and a common set of transport descriptors for the transport service. However, a client may use a different addressing scheme or different traffic descriptors (consistent with performance inheritance).
レイヤネットワークは、転送、リソース予約、OAM、および回復の制御をサポートするために、一貫性のある機能を備えています。例えば、レイヤネットワークは、トランスポートサービスと輸送サービスの転送記述子の共通の組のエンドポイントのための共通のアドレス指定方式を有することになります。ただし、クライアントは異なるアドレス指定方式または異なるトラフィック記述子（パフォーマンスの継承と一致）を使用することができます。
It is sometimes useful to independently monitor a smaller domain within a layer network (or the transport services that traverse this smaller domain), but the control of forwarding or the control of resource reservation involved retain their common elements. These smaller monitored domains are sublayers.
独立層ネットワーク（又はこれより小さなドメインを横切る輸送サービス）内のより小さな領域を監視することが時には便利であるが、転送の制御や関与リソース予約の制御は、それらの共通の要素を保持します。これらの小さな監視対象のドメインはサブレイヤです。
It is sometimes useful to independently control forwarding in a smaller domain within a layer network, but the control of resource reservation and OAM retain their common elements. These smaller domains are partitions of the layer network.
独立してレイヤネットワーク内の小さな領域での転送を制御するために、時には有用であるが、リソース予約及びOAMの制御は、それらの共通の要素を保持します。これらの小さなドメインは、レイヤネットワークのパーティションです。
The MPLS-TP requirements set out in this section are for the behavior of the protocol mechanisms and procedures that constitute building blocks out of which the MPLS Transport Profile is constructed. That is, the requirements indicate what features are to be available in the MPLS toolkit for use by MPLS-TP.
このセクションに記載されたMPLS-TP要件は、MPLSトランスポートプロファイルが構築されるのうちのビルディングブロックを構成するプロトコルメカニズムおよび手順の動作のためのものです。これは、要件がMPLS-TPが使用するためのMPLSツールキットで利用できるようにするためであるかの特徴を示しています。
1 The MPLS-TP data plane MUST be a subset of the MPLS data plane as defined by the IETF. When MPLS offers multiple options in this respect, MPLS-TP SHOULD select the minimum subset (necessary and sufficient subset) applicable to a transport network application.
1 MPLS-TPデータプレーンは、IETFによって定義されたMPLSデータプレーンのサブセットでなければなりません。 MPLSは、この点で複数のオプションを提供するとき、MPLS-TPは、トランスポートネットワークアプリケーションに適用可能な最小の部分集合（必要十分なサブセット）を選択すべきです。
2 The MPLS-TP design SHOULD as far as reasonably possible reuse existing MPLS standards.
2 MPLS-TPのデザインは限り合理的に可能な再利用、既存のMPLS標準規格として必要があります。
3 Mechanisms and capabilities MUST be able to interoperate with existing IETF MPLS [RFC3031] and IETF PWE3 [RFC3985] control and data planes where appropriate.
3つの機構及び機能は、既存のIETF MPLS [RFC3031]とIETF PWE3 [RFC3985]制御およびデータプレーン適切と相互運用できなければなりません。
A. Data-plane interoperability MUST NOT require a gateway
function.
4 MPLS-TP and its interfaces, both internal and external, MUST be sufficiently well-defined that interworking equipment supplied by multiple vendors will be possible both within a single domain and between domains.
内部および外部の両方4つのMPLS-TPとそのインターフェースは、複数のベンダによって供給されたインターワーキング装置は、単一のドメイン内およびドメイン間の両方が可能になることを十分に良好に定義されなければなりません。
5 MPLS-TP MUST be a connection-oriented packet-switching technology with traffic-engineering capabilities that allow deterministic control of the use of network resources.
5 MPLS-TPは、ネットワーク資源の利用の決定論的制御を可能にトラフィック・エンジニアリング機能との接続指向のパケットスイッチング技術でなければなりません。
6 MPLS-TP MUST support traffic-engineered point-to-point (P2P) and point-to-multipoint (P2MP) transport paths.
6 MPLS-TPは、トラフィックエンジニアリングのポイントツーポイント（P2P）とポイントツーマルチポイント（P2MP）トランスポートパスをサポートしなければなりません。
7 MPLS-TP MUST support unidirectional, co-routed bidirectional, and associated bidirectional point-to-point transport paths.
7 MPLS-TPは、一方向、共ルーティング双方向、および関連する双方向ポイントツーポイント搬送路をサポートしなければなりません。
8 MPLS-TP MUST support unidirectional point-to-multipoint transport paths.
8 MPLS-TPは、単方向ポイントツーマルチポイントのトランスポートパスをサポートしなければなりません。
9 The end points of a co-routed bidirectional transport path MUST be aware of the pairing relationship of the forward and reverse paths used to support the bidirectional service.
9 COルーティング双方向搬送路のエンドポイントは、順方向のペアリング関係を認識し、双方向サービスをサポートするために使用されるパスを逆にしなければなりません。
10 All nodes on the path of a co-routed bidirectional transport path in the same (sub)layer as the path MUST be aware of the pairing relationship of the forward and the backward directions of the transport path.
パスと同じ（サブ）レイヤで同時ルーティング双方向搬送路の経路上の10個のすべてのノードは、順方向のペアリング関係と搬送路の逆方向を知っていなければなりません。
11 The end points of an associated bidirectional transport path MUST be aware of the pairing relationship of the forward and reverse paths used to support the bidirectional service.
関連する双方向搬送路11個のエンドポイントは、双方向サービスをサポートするために使用される順方向および逆方向経路のペア関係を知っていなければなりません。
12 Nodes on the path of an associated bidirectional transport path where both the forward and backward directions transit the same node in the same (sub)layer as the path SHOULD be aware of the pairing relationship of the forward and the backward directions of the transport path.
パスと同じ（サブ）レイヤ内の同じノードが前方のペア関係及び搬送経路の逆方向に注意する必要があり、両方の前後方向トランジット関連する双方向搬送路の経路上の12個のノード。
13 MPLS-TP MUST support bidirectional transport paths with symmetric bandwidth requirements, i.e., the amount of reserved bandwidth is the same between the forward and backward directions.
13 MPLS-TP、すなわち、予約帯域幅の量は、前後方向の間で同じであり、対称的な帯域幅要件との双方向の搬送路をサポートしなければなりません。
14 MPLS-TP MUST support bidirectional transport paths with asymmetric bandwidth requirements, i.e., the amount of reserved bandwidth differs between the forward and backward directions.
14 MPLS-TP、すなわち、予約帯域幅の量は、前後方向の間で異なり、非対称な帯域幅の要件との双方向の搬送路をサポートしなければなりません。
15 MPLS-TP MUST support the logical separation of the control and management planes from the data plane.
15 MPLS-TPは、データプレーンからの制御および管理プレーンの論理的な分離をサポートしなければなりません。
16 MPLS-TP MUST support the physical separation of the control and management planes from the data plane. That is, it must be possible to operate the control and management planes out-of-band, 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.
16 MPLS-TPは、データプレーンからの制御および管理プレーンの物理的分離をサポートしなければなりません。すなわち、帯域外制御および管理プレーンを動作させることが可能でなければならない、と彼らが実行されているときに何の仮定は、制御又は管理プレーンチャネルの情報からデータプレーンチャネルの状態について行われるべきではありません-of-バンド。
17 MPLS-TP MUST support static provisioning of transport paths via the management plane.
17 MPLS-TPは、管理プレーンを経由して搬送路の静的プロビジョニングをサポートしなければなりません。
18 A solution MUST be defined to support dynamic provisioning and restoration of MPLS-TP transport paths via a control plane.
18溶液は、制御プレーンを介して、MPLS-TPの搬送路の動的プロビジョニングおよび復元をサポートするために定義されなければなりません。
19 Static provisioning MUST NOT depend on the presence of any element of a control plane.
19静的プロビジョニングは、制御プレーンの任意の元素の存在に依存してはなりません。
20 MPLS-TP MUST support the coexistence of statically and dynamically provisioned/managed MPLS-TP transport paths within the same layer network or domain.
20 MPLS-TPは、同一層のネットワークまたはドメイン内で静的および動的にプロビジョニング/管理MPLS-TPの搬送路の共存をサポートしなければなりません。
21 Mechanisms in an MPLS-TP layer network that satisfy functional requirements that are common to general transport-layer networks (i.e., independent of technology) SHOULD be operable in a way that is similar to the way the equivalent mechanisms are operated in other transport-layer technologies.
一般的なトランスポート層のネットワークに共通する機能要件を満たすMPLS-TP層ネットワーク21のメカニズム（すなわち、技術の独立）は、同等のメカニズムが他のtransport-で動作している方法と同様な方法で動作可能であるべきです層技術。
22 MPLS-TP MUST support the capability for network operation via the management plane (without the use of any control-plane protocols). This includes the configuration and control of OAM and recovery functions.
22 MPLS-TPは、（任意の制御プレーンプロトコルを使用することなく）管理プレーンを経由してネットワーク動作のための機能をサポートしなければなりません。これは、OAMと回復機能の構成および制御を含んでいます。
23 The MPLS-TP data plane MUST be capable of
23 MPLS-TPデータプレーンができなければなりません
A. forwarding data independent of the control or management
plane used to configure and operate the MPLS-TP layer
network.
B. taking recovery actions independent of the control or management plane used to configure the MPLS-TP layer network.
MPLS-TP層ネットワークを構成するために使用される制御や管理面の独立した回復アクションを取るB.。
C. operating normally (i.e., forwarding, OAM, and protection MUST continue to operate) if the management plane or control plane that configured the transport paths fails.
C.は、正常に動作して搬送路を構成し、管理プレーン又は制御プレーンに障害が発生した場合（即ち、転送、OAM、および保護が動作し続けなければなりません）。
24 MPLS-TP MUST support mechanisms to avoid or minimize traffic impact (e.g., packet delay, reordering, and loss) during network reconfiguration.
24 MPLS-TPは、ネットワーク再構成の間にトラフィックへの影響（例えば、パケット遅延、並べ替え、および損失）を回避または最小化するためのメカニズムをサポートしなければなりません。
25 MPLS-TP MUST support transport paths through multiple homogeneous domains.
25のMPLS-TPは、複数の均質なドメインを介して搬送経路をサポートしなければなりません。
26 MPLS-TP SHOULD support transport paths through multiple non-homogeneous domains.
26 MPLS-TPは、複数の非均質ドメインを介して搬送経路をサポートしなければなりません。
27 MPLS-TP MUST NOT dictate the deployment of any particular network topology either physical or logical, however:
27 MPLS-TPは、しかし、物理的または論理的のいずれかの任意の特定のネットワークトポロジの展開を指示してはいけません。
A. It MUST be possible to deploy MPLS-TP in rings.
A.リングにMPLS-TPを展開することも可能でなければなりません。
B. It MUST be possible to deploy MPLS-TP in arbitrarily interconnected rings with one or two points of interconnection.
B.相互接続の一つまたは二つの点で任意に相互接続されたリングでMPLS-TPを展開することができなければなりません。
C. MPLS-TP MUST support rings of at least 16 nodes in order to support the upgrade of existing Time-Division Multiplexing (TDM) rings to MPLS-TP. MPLS-TP SHOULD support rings with more than 16 nodes.
C. MPLS-TPは、MPLS-TPへの既存の時分割多重（TDM）のリングのアップグレードをサポートするために、少なくとも16個のノードのリングをサポートしなければなりません。 MPLS-TPは、16個の以上のノードを持つリングをサポートする必要があります。
28 MPLS-TP MUST be able to scale at least as well as existing transport technologies with growing and increasingly complex network topologies as well as with increasing amounts of customers, services, and bandwidth demand.
28 MPLS-TPは、拡張することができ、少なくともだけでなく、成長しており、ますます複雑なネットワークトポロジを持つだけでなく、顧客、サービス、および帯域幅の需要量の増加に伴い、既存のトランスポート技術でなければなりません。
29 MPLS-TP SHOULD support mechanisms to safeguard against the provisioning of transport paths which contain forwarding loops.
29のMPLS-TPは、転送ループを含む搬送路のプロビジョニングに対して保護するためのメカニズムをサポートしなければなりません。
30 A generic and extensible solution MUST be provided to support the transport of one or more client layer networks (e.g., MPLS-TP, IP, MPLS, Ethernet, ATM, FR, etc.) over an MPLS-TP layer network.
30ジェネリックおよび拡張可能溶液は、1つ以上のクライアント層ネットワークのトランスポートをサポートするために提供されなければならない（例えば、MPLS-TP、IP、MPLS、イーサネット、ATM、FR、等）MPLS-TP層ネットワークを介し。
31 A generic and extensible solution MUST be provided to support the transport of MPLS-TP transport paths over one or more server layer networks (such as MPLS-TP, Ethernet, SONET/SDH, OTN, etc.). Requirements for bandwidth management within a server layer network are outside the scope of this document.
31ジェネリックおよび拡張可能溶液は、（例えば、MPLS-TP、イーサネット、SONET / SDH、OTNなど）1つまたは複数のサーバレイヤネットワーク上でMPLS-TPの搬送路の搬送をサポートするために提供されなければなりません。サーバレイヤネットワーク内の帯域幅管理のための要件は、この文書の範囲外です。
32 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 operation of the MPLS-TP layer network MUST be possible without any dependencies on the server or client layer network.
MPLS-TP層ネットワークは、クライアント層ネットワークをサポートし、MPLS-TP層ネットワークはサーバレイヤネットワークによってサポートされている環境において32は、MPLS-TP層ネットワークの動作はに依存せずに可能でなければなりませんサーバーまたはクライアントレイヤネットワーク。
A. The server layer MUST guarantee that the traffic-loading
imposed by other clients does not cause the transport service
provided to the MPLS-TP layer to fall below the agreed level.
Mechanisms to achieve this are outside the scope of these
requirements.
B. It MUST be possible to isolate the control and management planes of the MPLS-TP layer network from the control and management planes of the client and server layer networks.
B.クライアントとサーバ層のネットワークの制御及び管理プレーンからMPLS-TP層ネットワークの制御及び管理プレーンを単離することができなければなりません。
33 A solution MUST be provided to support the transport of a client MPLS or MPLS-TP layer network over a server MPLS or MPLS-TP layer network.
33溶液は、サーバMPLSまたはMPLS-TP層ネットワークを介してクライアントMPLSまたはMPLS-TP層ネットワークのトランスポートをサポートするために提供されなければなりません。
A. The level of coordination required between the client and
server MPLS(-TP) layer networks MUST be minimized (preferably
no coordination will be required).
B. The MPLS(-TP) server layer network MUST be capable of transporting the complete set of packets generated by the client MPLS(-TP) layer network, which may contain packets that are not MPLS packets (e.g., IP or Connectionless Network Protocol (CNLP) packets used by the control/management plane of the client MPLS(-TP) layer network).
B.ザ・MPLS（-TP）サーバレイヤネットワークは、MPLSパケット（例えば、IPまたはコネクションレスネットワークプロトコルではないパケットを含むことができ、クライアントのMPLS（-TP）層ネットワークによって生成されたパケットの完全なセットを、輸送することができなければなりません（CNLP）クライアントMPLS（-TP）層ネットワークの制御/管理プレーンによって使用されるパケット）。
34 It MUST be possible to operate the layers of a multi-layer network that includes an MPLS-TP layer autonomously.
34自律的にMPLS-TP層を含む多層ネットワークのレイヤを操作することが可能でなければなりません。
The above are not only technology requirements, but also operational requirements. Different administrative groups may be responsible for the same layer network or different layer networks.
上記は、唯一の技術要件だけでなく、運用上の要件ではありません。別の管理グループは、同じレイヤネットワークまたは異なるレイヤネットワークを担当することがあります。
35 It MUST be possible to hide 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 SRLGs or reachability) between layers.
35クライアント層ネットワークからMPLS-TP層ネットワークアドレスおよび他の情報（例えば、トポロジー）非表示にすることができなければなりません。しかし、層の間（例えばSRLGs又は到達可能性など）要約情報の限られた量をリークするため、オペレータのオプションで、可能なはずです。
36 It MUST be possible to operate and configure the MPLS-TP data plane without any IP forwarding capability in the MPLS-TP data plane. That is, the data plane only operates on the MPLS label.
36は動作し、MPLS-TPデータプレーン内の任意のIP転送能力なしでMPLS-TPデータプレーンを構成することが可能でなければなりません。つまり、データプレーンはMPLSラベルで動作します。
37 It MUST be possible for the end points of an MPLS-TP transport path that is carrying an aggregate of client transport paths to be able to decompose the aggregate transport path into its component client transport paths.
37これは、そのコンポーネントクライアント搬送経路に集約搬送路を分解することができるように、クライアントの搬送路の集合体を運んでMPLS-TPの搬送経路のエンドポイントのために可能でなければなりません。
38 A transport path on a link MUST be uniquely identifiable by a single label on that link.
38リンク上搬送路は、そのリンク上の単一の標識によって一意に識別していなければなりません。
39 A transport path's source MUST be identifiable at its destination within its layer network.
39搬送路のソースは、そのレイヤのネットワーク内のその宛先に識別可能でなければなりません。
40 MPLS-TP MUST be capable of using P2MP server (sub)layer capabilities as well as P2P server (sub)layer capabilities when supporting P2MP MPLS-TP transport paths.
40 MPLS-TPは、P2MP MPLS-TPの搬送路を支持するときに機能レイヤP2MPサーバ（サブ）レイヤ機能と同様P2Pサーバー（サブ）を使用できなければなりません。
41 MPLS-TP MUST be extensible in order to accommodate new types of client layer networks and services.
41のMPLS-TPは、クライアント層のネットワークとサービスの新しいタイプに対応するために拡張可能でなければなりません。
42 MPLS-TP SHOULD support mechanisms to enable 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.
42 MPLS-TPは、十分なリソースを提供し、その搬送経路上の既存のトラフィックに影響を与えることなく増加させる搬送経路に関連付けられた予約帯域幅が利用可能である有効にするメカニズムをサポートしなければなりません。
43 MPLS-TP SHOULD support mechanisms to enable the reserved bandwidth of a transport path to be 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.
43 MPLS-TPは、その搬送経路上の既存のトラフィックに影響を与えることなく減少される搬送路の帯域予約を可能にするためのメカニズムをサポートする既存のトラフィックのレベルが減少次予約された帯域幅よりも小さいことを条件とするべきです。
44 MPLS-TP MUST support mechanisms that ensure the integrity of the transported customer's service traffic as required by its associated SLA. Loss of integrity may be defined as packet corruption, reordering, or loss during normal network conditions.
44 MPLS-TPは、それに関連するSLAで要求される輸送、顧客のサービストラフィックの整合性を確保するためのメカニズムをサポートしなければなりません。完全性の損失は、通常のネットワーク状態の間にパケットの破損、並べ替え、または損失として定義することができます。
45 MPLS-TP MUST support mechanisms to detect when loss of integrity of the transported customer's service traffic has occurred.
45のMPLS-TPは輸送、顧客のサービストラフィックの完全性の損失が発生したときを検出するためのメカニズムをサポートしなければなりません。
46 MPLS-TP MUST support an unambiguous and reliable means of distinguishing users' (client) packets from MPLS-TP control packets (e.g., control plane, management plane, OAM, and protection-switching packets).
46 MPLS-TPは、MPLS-TP制御パケットと区別ユーザー（クライアント）パケット（例えば、制御プレーン、管理プレーン、OAM、および保護切替パケット）の明確かつ信頼性の高い手段をサポートしなければなりません。
This section defines the requirements that apply to an MPLS-TP control plane. Note that it MUST be possible to operate an MPLS-TP network without using a control plane.
このセクションでは、MPLS-TP制御プレーンに適用される要件を定義します。制御プレーンを使用することなく、MPLS-TPネットワークを動作させることが可能でなければなりません。
The ITU-T has defined an architecture for Automatically Switched Optical Networks (ASONs) in G.8080 [ITU.G8080.2006] and G.8080 Amendment 1 [ITU.G8080.2008]. The control plane for MPLS-TP MUST fit within the ASON architecture.
ITU-Tは、[ITU.G8080.2008] G.8080 [ITU.G8080.2006]とG.8080改正1における自動交換光ネットワーク（ASONs）のためのアーキテクチャを定義しています。 MPLS-TPのための制御プレーンは、ASONアーキテクチャ内に適合しなければなりません。
An interpretation of the ASON signaling and routing requirements in the context of GMPLS can be found in [RFC4139] and [RFC4258].
GMPLSの文脈におけるASONシグナリングおよびルーティングの要件の解釈は、[RFC4139]及び[RFC4258]に見出すことができます。
Additionally:
さらに：
47 The MPLS-TP control plane MUST support control-plane topology and data-plane topology independence. As a consequence, a failure of the control plane does not imply that there has also been a failure of the data plane.
47 MPLS-TP制御プレーンは、制御プレーン・トポロジーおよびデータ・プレーン・トポロジーの独立性をサポートしなければなりません。その結果、コントロールプレーンの障害は、データプレーンの故障があったことを意味するものではありません。
48 The MPLS-TP control plane MUST be able to be operated independently of any particular client- or server-layer control plane.
48 MPLS-TP制御プレーンは、独立して、任意の特定のクライアント - サーバまたは層制御プレーンの動作できなければなりません。
49 MPLS-TP SHOULD define a solution to support 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.
49 MPLS-TPは、これらの層のネットワークが同じ管理ドメインに属している場合、サーバーとクライアント層のネットワークと一緒にMPLS-TPを網羅する統合制御プレーンをサポートするためのソリューションを定義する必要があります。
50 The MPLS-TP control plane MUST support establishing all the connectivity patterns defined for the MPLS-TP data plane (i.e., unidirectional P2P, associated bidirectional P2P, co-routed bidirectional P2P, unidirectional P2MP) including configuration of protection functions and any associated maintenance functions.
50 MPLS-TP制御プレーンは、保護機能の構成および関連するメンテナンスを含むMPLS-TPデータプレーン（すなわち、一方向P2P、関連する双方向のP2P、共ルーティング双方向P2P、一方向P2MP）に定義されたすべての接続のパターンを確立するサポートしなければなりません機能。
51 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.
51 MPLS-TP制御プレーン構成および変形OAM保守ポイントのと同様の搬送経路または輸送サービスが確立または変更されるOAMの活性化/非活性化をサポートしなければなりません。
52 An MPLS-TP control plane MUST support operation of the recovery functions described in Section 2.8.
52アンMPLS-TP制御プレーンは、セクション2.8で説明回復機能の動作をサポートしなければなりません。
53 An MPLS-TP control plane MUST scale gracefully to support a large number of transport paths, nodes, and links.
53アンMPLS-TP制御プレーンは、トランスポート経路、ノード、及び多数のリンクをサポートするために、正常に拡張しなければなりません。
54 If a control plane is used for MPLS-TP, following a control-plane failure, the control plane MUST be capable of restarting and relearning its previous state without impacting forwarding.
54コントロールプレーンがMPLS-TPに使用される場合、制御プレーン障害の後、制御プレーンは、転送に影響を与えることなく、以前の状態を再起動し、再学習できなければなりません。
55 An 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).
55アンMPLS-TP制御プレーンは、管理プレーンからの制御プレーンおよびその逆へのMPLS-TPの搬送路の制御の動的所有権移転のための機構を提供しなければなりません。データプレーンに必要な再構成の数を最小限に抑えなければならない（好ましくはデータプレーンの再構成は不要であろう）。
Network survivability plays a critical role in the delivery of reliable services. Network availability is a significant contributor to revenue and profit. Service guarantees in the form of SLAs require a resilient network that rapidly detects facility or node failures and restores network operation in accordance with the terms of the SLA.
ネットワークサバイバビリティは、信頼性の高いサービスの提供に重要な役割を果たしています。ネットワークの可用性は、収益と利益に多大な貢献です。 SLAの形でサービス保証が急速施設またはノードの障害を検出し、SLAの条件に従ってネットワーク動作を復元弾性ネットワークを必要とします。
56 MPLS-TP MUST provide protection and restoration mechanisms.
56 MPLS-TPは、保護及び修復メカニズムを提供しなければなりません。
A. MPLS-TP recovery techniques 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.
B. Recovery techniques used for P2P and P2MP SHOULD be identical to simplify implementation and operation. However, this MUST NOT override any other requirement.
P2PとP2MPに使用B.回収技術は、実装及び操作を簡略化するために同一でなければなりません。しかし、これは他の要件を上書きしてはなりません。
57 MPLS-TP recovery mechanisms MUST be applicable at various levels throughout the network including support for link, transport path, segment, concatenated segment, and end-to-end recovery.
57 MPLS-TP回復機構は、リンク、搬送路、セグメント、連結セグメント、およびエンドツーエンドの回復のためのサポートを含むネットワーク全体の様々なレベルで適用していなければなりません。
58 MPLS-TP recovery paths MUST meet the SLA protection objectives of the service.
58 MPLS-TPの回復パスは、サービスのSLA保護目標を達成しなければなりません。
A. MPLS-TP MUST provide mechanisms to guarantee 50ms recovery
times from the moment of fault detection in networks with
spans less than 1200 km.
B. For protection it MUST be possible to require protection of 100% of the traffic on the protected path.
B.保護のためには、保護されたパス上のトラフィックの100％の保護を必要とすることは可能でなければなりません。
C. Recovery MUST meet SLA requirements over multiple domains.
C.回復は、複数のドメインを超えるSLAの要件を満たす必要があります。
59 Recovery objectives SHOULD be configurable per transport path.
59の復旧の目的は、搬送経路ごとに設定すべきである（SHOULD）。
60 The recovery mechanisms SHOULD be applicable to any topology.
60回復メカニズムは、任意のトポロジに適用可能であるべきです。
61 The recovery mechanisms MUST support the means to operate in synergy with (including coordination of timing) the recovery mechanisms present in any client or server transport networks (for example, Ethernet, SDH, OTN, WDM) to avoid race conditions between the layers.
61回収機構は、層の間の競合状態を回避するために（例えば、イーサネット（登録商標）、SDH、OTN、WDM）（タイミングの調整を含む）との相乗効果で動作するための手段、任意のクライアントまたはサーバのトランスポートネットワーク内に存在する回復メカニズムをサポートしなければなりません。
62 MPLS-TP recovery and reversion mechanisms MUST prevent frequent operation of recovery in the event of an intermittent defect.
62 MPLS-TP回復及び復帰機構は間欠欠陥の場合に回復を頻繁に操作することを防止しなければなりません。
General protection and survivability requirements are expressed in terms of the behavior in the data plane.
一般的な保護と存続性の要件は、データプレーンでの動作で表現されています。
Note: Only nodes that are aware of the pairing relationship between the forward and backward directions of an associated bidirectional transport path can be used as end points to protect all or part of that transport path.
注：関連する双方向搬送路の前後方向との間のペア関係を知っているだけのノードは、その搬送経路の全部または一部を保護するためのエンドポイントとして使用することができます。
63 It MUST be possible to provide protection for the MPLS-TP data plane without any IP forwarding capability in the MPLS-TP data plane. That is, the data plane only operates on the MPLS label.
63 MPLS-TPデータ・プレーン内の任意のIPフォワーディング機能のないMPLS-TPのデータプレーンの保護を提供することが可能でなければなりません。つまり、データプレーンはMPLSラベルで動作します。
64 MPLS-TP protection mechanisms MUST support revertive and non-revertive behavior.
64 MPLS-TPの保護メカニズムは、リバーティブおよび非リバーティブ動作をサポートしなければなりません。
65 MPLS-TP MUST support 1+1 protection.
65 MPLS-TPは、1つの+ 1保護をサポートしなければなりません。
A. Bidirectional 1+1 protection for P2P connectivity MUST be
supported.
B. Unidirectional 1+1 protection for P2P connectivity MUST be supported.
P2P接続用B.単方向1 + 1保護をサポートしなければなりません。
C. Unidirectional 1+1 protection for P2MP connectivity MUST be supported.
P2MP接続のためのC.単方向1 + 1保護をサポートしなければなりません。
66 MPLS-TP MUST support the ability to share protection resources amongst a number of transport paths.
66 MPLS-TPは、搬送経路の数の中で保護リソースを共有する機能をサポートしなければなりません。
67 MPLS-TP MUST support 1:n protection (including 1:1 protection).
（1を含む：1プロテクション）N保護：67 MPLS-TP 1をサポートしなければなりません。
A. Bidirectional 1:n protection for P2P connectivity MUST be
supported and SHOULD be the default behavior for 1:n
protection.
B. Unidirectional 1:n protection for P2MP connectivity MUST be supported.
B.単方向1：nのP2MP接続のための保護をサポートしなければなりません。
C. Unidirectional 1:n protection for P2P connectivity is not required and MAY be omitted from the MPLS-TP specifications.
C.単方向1：nのP2P接続用の保護が必要とされていないとMPLS-TPの仕様から省略されるかもしれません。
D. The action of protection-switching MUST NOT cause the user data to enter an uncontrolled loop. The protection-switching system MAY cause traffic to pass over a given link more than once, but it must do so in a controlled way such that uncontrolled loops do not form.
D.は、保護切り替えの動作は、ユーザデータが制御されていないループを入力することがあってはなりません。保護切り替えシステムは、トラフィックが複数回指定されたリンク上を通過することがありますが、それは制御不能なループを形成しないよう制御された方法で行う必要があります。
Note: Support for extra traffic (as defined in [RFC4427]) is not required in MPLS-TP and MAY be omitted from the MPLS-TP specifications.
注：余分なトラフィックのサポートは、（[RFC4427]で定義される）MPLS-TPで必要とされていないとMPLS-TPの仕様から省略されるかもしれません。
68 MPLS-TP SHOULD support 1:n (including 1:1) shared mesh recovery.
68 MPLS-TP 1をサポートするべきである：N（1を含む：1）共有メッシュ回復。
69 MPLS-TP MUST support sharing of protection resources such that protection paths that are known not to be required concurrently can share the same resources.
69のMPLS-TPは、同時に必要とされることがないことが知られている保護パスが同じリソースを共有することができるように、保護リソースの共有をサポートしなければなりません。
70 The restoration transport path MUST be able to share resources with the transport path being replaced (sometimes known as soft rerouting).
70復元搬送路は、置換されて搬送路（時にはソフト再ルーティングと呼ばれる）とリソースを共有できなければなりません。
71 Restoration priority MUST be supported so that an implementation can determine the order in which transport paths should be restored (to minimize service restoration time as well as to gain access to available spare capacity on the best paths).
実装は、トランスポートパスが（サービス復旧時間を最小限にするために、ならびに最良のパス上で利用可能な予備容量にアクセスするために）復元されるべき順序を決定することができるように、71復元の優先度をサポートしなければなりません。
72 Preemption priority MUST be supported to allow restoration to displace other transport paths in the event of resource constraint.
72先取り優先権は、リソース制約の場合には他の輸送経路を変位させる復元を可能にするためにサポートしなければなりません。
73 MPLS-TP restoration mechanisms MUST support revertive and non-revertive behavior.
73 MPLS-TPの回復メカニズムは、リバーティブと非リバーティブ動作をサポートしなければなりません。
Recovery actions may be triggered from different places as follows:
次のように回復アクションは、別の場所からトリガすることができます。
74 MPLS-TP MUST support fault indication triggers from lower layers. This includes faults detected and reported by lower-layer protocols, and faults reported directly by the physical medium (for example, loss of light).
障害表示をサポートしなければならない74 MPLS-TPは、下位層からトリガー。これは、（例えば、光の損失）物理媒体によって直接報告検出及び下位層プロトコルによって報告された障害、および障害を含みます。
75 MPLS-TP MUST support OAM-based triggers.
75 MPLS-TPは、OAMベースのトリガをサポートしなければなりません。
76 MPLS-TP MUST support management-plane triggers (e.g., forced switch, etc.).
76 MPLS-TPは、管理プレーントリガ（例えば、強制的なスイッチ、など）をサポートしなければなりません。
77 There MUST be a mechanism to distinguish administrative recovery actions from recovery actions initiated by other triggers.
77他のトリガーによって開始され、回復アクションから管理回復アクションを区別するための機構が存在しなければなりません。
78 Where a control plane is present, MPLS-TP SHOULD support control-plane restoration triggers.
制御プレーンが存在する場合78は、MPLS-TPは、制御プレーン復元トリガをサポートしなければなりません。
79 MPLS-TP protection mechanisms 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).
79 MPLS-TP保護メカニズムが交渉し、保護スイッチングのための共存要求（すなわち、複数の要求）を収容するために優先ロジックをサポートしなければならない（例えば、管理要求及び/ノード障害をリンクによる要求）。
All functions described here are for control by the operator.
ここで説明するすべての機能は、オペレータによる制御のためのものです。
80 It MUST be possible to configure protection paths and protection-to-working path relationships (sometimes known as protection groups).
80保護パスとプロテクション・ツー・ワーキングパス関係を（時には保護基として知られている）を構成することができなければなりません。
81 There MUST be support for pre-calculation of recovery paths.
81リカバリー・パスの事前計算のためのサポートがあるに違いありません。
82 There MUST be support for pre-provisioning of recovery paths.
82リカバリー・パスの事前プロビジョニングのためのサポートがあるに違いありません。
83 The external controls as defined in [RFC4427] MUST be supported.
[RFC4427]で定義されるように83本の外部制御をサポートしなければなりません。
A. 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.,
due to a coordination failure of the protection state) MUST
be dropped.
84 It MUST be possible to test and validate any protection/ restoration mechanisms and protocols:
84任意の保護/回復のメカニズムとプロトコルをテストして検証することは可能でなければなりません。
A. Including the integrity of the protection/recovery transport
path.
B. Without triggering the actual protection/restoration.
実際の保護/回復をトリガすることなくB.。
C. While the working path is in service.
C.作業パスがサービスされている間。
D. While the working path is out of service.
D.現用パスがアウトオブサービスですが。
85 Restoration resources MAY be pre-planned and selected a priori, or computed after failure occurrence.
85の修復リソースは、事前に計画し、事前に選択され、または障害発生後に計算することができます。
86 When preemption is supported for restoration purposes, it MUST be possible for the operator to configure it.
プリエンプションは、復元のためにサポートされている場合は86、それを構成するためのオペレータのために可能でなければなりません。
87 The management plane MUST provide indications of protection events and triggers.
87管理プレーンは、保護イベントとトリガの指示を提供しなければなりません。
88 The management plane MUST allow the current protection status of all transport paths to be determined.
88管理プレーンは、すべてのトランスポートパスの現在の保護ステータスを決定することを可能にしなければなりません。
89 The MPLS-TP control plane (which is not mandatory in an MPLS-TP implementation) MUST be capable of supporting:
89（MPLS-TPの実装では必須ではない）、MPLS-TP制御プレーンはサポートすることが可能でなければなりません。
A. establishment and maintenance of all recovery entities and
functions
B. signaling of administrative control
管理制御のB.シグナリング
C. protection state coordination (PSC). Since control plane network topology is independent from the data plane network topology, the PSC 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).
C.保護状態の調整（PSC）。制御プレーンネットワークトポロジーは、データプレーンのネットワークトポロジから独立しているため、MPLS-TP制御プレーンによって支持PSCは、回収機構（例えば、バックアップ）内で処理データプレーンリソースとは異なるリソース上で実行することができます。
90 In-band OAM MUST be capable of supporting:
90帯域内OAMをサポートすることができなければなりません。
A. signaling of administrative control
管理制御のA.シグナリング
B. protection state coordination (PSC). Since in-band OAM tools share the data plane with the carried transport service, in order to optimize the usage of network resources, the PSC supported by in-band OAM MUST run on protection resources.
B.保護状態の調整（PSC）。帯域内OAMツールが搭載輸送サービスとデータプレーンを共有しているため、ネットワークリソースの使用を最適化するためには、インバンドOAMでサポートされているPSCは保護リソース上で実行する必要があります。
91 MPLS-TP MAY 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.
91 MPLS-TPは、特定のネットワーク・トポロジのために最適化されたリカバリ・メカニズムをサポートするかもしれません。これらのメカニズムは、エンドツーエンドの搬送路の保護を可能にするために、任意のトポロジー（メッシュ）ネットワークのために定義されたメカニズムと相互運用していなければなりません。
Several service providers have expressed a high level of interest in operating MPLS-TP in ring topologies and require a high level of survivability function in these topologies. The requirements listed below have been collected from these service providers and from the ITU-T.
いくつかのサービスプロバイダは、リングトポロジで運転MPLS-TPへの関心の高さを表現し、これらのトポロジでサバイバビリティ機能の高いレベルを必要としています。下記に記載された要件は、これらのサービスプロバイダからとITU-Tから集めてきました。
The main objective in considering a specific topology (such as a ring) is to determine whether it is possible to optimize any mechanisms such that the performance of those mechanisms within the topology is significantly better than the performance of the generic mechanisms in the same topology. The benefits of such optimizations are traded against the costs of developing, implementing, deploying, and operating the additional optimized mechanisms noting that the generic mechanisms MUST continue to be supported.
（このような環のような）特定のトポロジを考慮に主な目的は、トポロジ内のそれらのメカニズムの性能は同じトポロジ内の汎用メカニズムの性能よりも著しく良好であるような任意のメカニズムを最適化することが可能であるかどうかを決定することです。このような最適化の利点は、一般的なメカニズムがサポートされ続けなければならないことを指摘し、追加の最適化のメカニズムを開発、導入、展開、および操作するのコストに対して取引されています。
Within the context of recovery in MPLS-TP networks, the optimization criteria considered in ring topologies are as follows:
次のようにMPLS-TPネットワークの回復の文脈では、リングトポロジで考慮最適化基準は以下のとおりです。
a. Minimize the number of OAM entities that are needed to trigger the recovery operation, such that it is less than is required by other recovery mechanisms.
A。それは他の回復メカニズムによって必要とされるよりも小さくなるように、回復操作をトリガーするために必要なOAMエンティティの数を最小限に抑えます。
b. Minimize the number of elements of recovery in the ring, such that it is less than is required by other recovery mechanisms.
B。それは他の回収機構によって必要とされるよりも小さくなるように、リングの回復の要素の数を最小限に抑えます。
c. Minimize the number of labels required for the protection paths across the ring, such that it is less than is required by other recovery mechanisms.
C。他の回収機構によって必要とされるよりも小さくなるように、リングの両端の予備パスのために必要なラベルの数を最小限に抑えます。
d. Minimize the amount of control and management-plane transactions during a maintenance operation (e.g., ring upgrade), such that it is less than the amount required by other recovery mechanisms.
D。それは他の回収機構によって必要とされる量よりも少なくなるように、メンテナンス動作（例えば、リングアップグレード）中に制御及び管理プレーントランザクションの量を最小限に抑えます。
e. When a control plane is supported, minimize the impact on signaling and routing information exchange during protection, such that it is less than the impact caused by other recovery mechanisms.
電子。制御プレーンがサポートされている場合、それは他の回収機構による衝撃未満であるように、保護の間の情報交換をシグナリングおよびルーティングへの影響を最小限に抑えます。
It may be observed that the requirements in Section 2.5.6.1 are fully compatible with the generic requirements expressed in Section 2.5 through Section 2.5.6 inclusive, and that no requirements that are specific to ring topologies have been identified.
セクション2.5.6.1における要件は包括セクション2.5.6を介して2.5節で発現ジェネリック要件と完全に互換性があり、リングトポロジに固有のいかなる要件が同定されていないことをことを観察することができます。
92 MPLS-TP MUST include recovery mechanisms that operate in any single ring supported in MPLS-TP, and continue to operate within the single rings even when the rings are interconnected.
92 MPLS-TPは、MPLS-TPでサポートされる任意の単環で動作する回収機構を含み、リングが相互接続されている場合でも、単一の環内で動作し続けなければなりません。
93 When a network is constructed from interconnected rings, MPLS-TP MUST support recovery mechanisms that protect user data that traverses more than one ring. This includes the possibility of failure of the ring-interconnect nodes and links.
ネットワークが相互接続されたリングで構成されている場合は93、MPLS-TPは、複数のリングを横断し、ユーザーデータを保護し、回復メカニズムをサポートしなければなりません。これは、リング相互接続ノードとリンクの故障の可能性を含みます。
94 MPLS-TP recovery in a ring MUST protect unidirectional and bidirectional P2P transport paths.
リングで94 MPLS-TPの回復は、単方向および双方向P2Pの搬送経路を保護する必要があります。
95 MPLS-TP recovery in a ring MUST protect unidirectional P2MP transport paths.
リングで95 MPLS-TPの回復は、一方向のP2MP搬送路を保護する必要があります。
96 MPLS-TP 1+1 and 1:1 protection in a ring MUST support switching time within 50 ms from the moment of fault detection in a network with a 16-node ring with less than 1200 km of fiber.
96 MPLS-TP 1 + 1及び1：リング1保護は、繊維の未満1200キロで16ノードのリングを有するネットワークにおける故障検出の時点から50ミリ秒以内の時間を切り替えサポートしなければなりません。
97 The protection switching time in a ring MUST be independent of the number of LSPs crossing the ring.
97リングに時間を切り替える保護リングを横切るLSPの数の独立していなければなりません。
98 The configuration and operation of recovery mechanisms in a ring MUST scale well with:
98リングの回復機構の構成及び動作とよくスケーリングしなければなりません。
A. the number of transport paths (MUST be better than linear
scaling)
B. the number of nodes on the ring (MUST be at least as good as linear scaling)
B.リング上のノードの数（線形スケーリングと少なくとも同程度に良好でなければなりません）
C. the number of ring interconnects (MUST be at least as good as linear scaling)
C.リング相互接続の数（線形スケーリングと少なくとも同程度に良好でなければなりません）
99 Recovery techniques used in a ring MUST NOT prevent the ring from being connected to a general MPLS-TP network in any arbitrary way, and MUST NOT prevent the operation of recovery techniques in the rest of the network.
リングに使用される99のリカバリ技術は、任意の方法で、一般的なMPLS-TPネットワークに接続されるの環を妨げてはならない、とネットワークの残りの部分で回収技術の動作を妨げてはなりません。
100 Recovery techniques in a ring SHOULD be identical (or as similar as possible) to those in general transport networks to simplify implementation and operations. However, this MUST NOT override any other requirement.
リング100のリカバリ技術は、実装及び操作を簡略化するために、一般的なトランスポート・ネットワークと同一（又はできるだけ類似している）であるべきです。しかし、これは他の要件を上書きしてはなりません。
101 Recovery techniques in logical and physical rings SHOULD be identical to simplify implementation and operation. However, this MUST NOT override any other requirement.
論理的および物理的なリング101のリカバリ技術は、実装及び操作を簡略化するために同一でなければなりません。しかし、これは他の要件を上書きしてはなりません。
102 The default recovery scheme in a ring MUST be bidirectional recovery in order to simplify the recovery operation.
102リングのデフォルトの回復方式は、回復動作を簡略化するために、双方向回復していなければなりません。
103 The recovery mechanism in a ring MUST support revertive switching, which MUST be the default behavior. This allows optimization of the use of the ring resources, and restores the preferred quality conditions for normal traffic (e.g., delay) when the recovery mechanism is no longer needed.
リングで103回復メカニズムは、デフォルトの動作でなければなら復元切り替えを、サポートしなければなりません。これは、リング・リソースの使用を最適化することができ、回収機構が不要になった通常のトラフィック（例えば、遅延）のための好ましい品質状態を復元します。
104 The recovery mechanisms in a ring MUST support ways to distinguish administrative protection-switching from protection-switching initiated by other triggers.
リングで104の回復メカニズムは、保護切り替え他のトリガーによって開始から管理保護切り替えを区別するための方法をサポートしなければなりません。
105 It MUST be possible to lockout (disable) protection mechanisms on selected links (spans) in a ring (depending on the operator's need). This may require lockout mechanisms to be applied to intermediate nodes within a transport path.
105（事業者のニーズに応じて）リング内で選択リンク（スパン）上（無効）保護機構をロックアウトすることができなければなりません。これは、搬送経路内の中間ノードに印加するロックアウト機構を必要とし得ます。
106 MPLS-TP recovery mechanisms in a ring:
リング106 MPLS-TP回復機構。
A. MUST include a mechanism to allow an implementation to
handle and coordinate coexisting requests or triggers for
protection-switching based on priority. (For example, this
includes multiple requests that are not necessarily arriving
simultaneously and that are located anywhere in the ring.)
Note that such coordination of the ring is equivalent to the
use of shared protection groups.
B. SHOULD protect against multiple failures
B.は、複数の障害から保護すべきです
107 MPLS-TP recovery and reversion mechanisms in a ring MUST offer a way to prevent frequent operation of recovery in the event of an intermittent defect.
リング107 MPLS-TP回復及び復帰機構は間欠欠陥の場合に回復を頻繁に操作することを防止する方法を提供しなければなりません。
108 MPLS-TP MUST support the sharing of protection bandwidth in a ring by allowing best-effort traffic.
108 MPLS-TPは、ベストエフォート型トラフィックを許可することで、リングで保護帯域幅の共有をサポートしなければなりません。
109 MPLS-TP MUST support sharing of ring protection resources such that protection paths that are known not to be required concurrently can share the same resources.
109のMPLS-TPは、同時に必要とされることがないことが知られている保護パスが同じリソースを共有することができるように、リング保護リソースの共有をサポートしなければなりません。
Carriers require advanced traffic-management capabilities to enforce and guarantee the QoS parameters of customers' SLAs.
キャリアは、顧客のSLAのQoSパラメータを適用し、保証するために高度なトラフィック管理機能が必要です。
Quality-of-service mechanisms are REQUIRED in an MPLS-TP network to ensure:
サービス品質のメカニズムが保証するために、MPLS-TPネットワークで必要とされています。
110 Support for differentiated services and different traffic types with traffic class separation associated with different traffic.
差別化サービスと異なるトラフィックに関連付けられているトラフィッククラス分離を有する異なるトラフィックタイプの110のサポート。
111 Enabling the provisioning and the guarantee of Service Level Specifications (SLSs), with support for hard and relative end-to-end bandwidth guaranteed.
111は、保証のハードと相対エンドツーエンドの帯域幅をサポートして、プロビジョニングとサービスレベルの仕様（SLSS）の保証を有効にします。
112 Support of services, which are sensitive to jitter and delay.
ジッタおよび遅延に敏感なサービス、の112をサポート。
113 Guarantee of fair access, within a particular class, to shared resources.
特定のクラス内で、共有リソースへの公平なアクセスの113保証、。
114 Guaranteed resources for in-band control and management-plane traffic, regardless of the amount of data-plane traffic.
帯域内制御および管理プレーントラフィックのための保証114個のリソースに関係なく、データプレーントラフィックの量。
115 Carriers are provided with the capability to efficiently support service demands over the MPLS-TP network. This MUST include support for a flexible bandwidth allocation scheme.
115のキャリアを効率的にMPLS-TPネットワーク上のサービス要求をサポートする機能を備えています。これは、柔軟な帯域幅割り当て方式をサポートしている必要があり。
For requirements related to network management functionality (Management Plane in ITU-T terminology) for MPLS-TP, see the MPLS-TP Network Management requirements document [TP-NM-REQ].
MPLS-TPの管理機能（ITU-T用語で管理面）ネットワークに関連する要件のために、MPLS-TPネットワーク管理要件文書[TP-NM-REQ]を参照。
For requirements related to OAM functionality for MPLS-TP, see the MPLS-TP OAM requirements document [TP-OAM-REQS].
MPLS-TPのためのOAM機能に関連する要件については、MPLS-TP OAM要件ドキュメント[TP-OAM-REQS]を参照してください。
For requirements related to performance-monitoring functionality for MPLS-TP, see the MPLS-TP OAM requirements document [TP-OAM-REQS].
MPLS-TPのパフォーマンス監視機能に関連する要件については、MPLS-TP OAM要件ドキュメント[TP-OAM-REQS]を参照してください。
For a description of the security threats relevant in the context of MPLS and GMPLS and the defensive techniques to combat those threats, see "Security Framework for MPLS and GMPLS Networks" [G/MPLS-SEC].
MPLSとGMPLSと、それらの脅威に対抗するための防御的な技術の文脈における関連するセキュリティの脅威の説明については、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」[G / MPLS-SEC]を参照してください。
For a description of additional security threats relevant in the context of MPLS-TP and the defensive techniques to combat those threats see "Security Framework for MPLS-TP" [TP-SEC-FMWK].
MPLS-TPの文脈では、関連する追加のセキュリティの脅威とそれらの脅威は、「MPLS-TPのためのセキュリティ・フレームワーク」[TP-SEC-FMWK]を参照対抗するための防御的な技術の説明について。
See Section 3.4.
3.4節を参照してください。
The authors would like to thank all members of the teams (the Joint Working Team, the MPLS Interoperability Design Team in the IETF, and the T-MPLS Ad Hoc Group in the ITU-T) involved in the definition and specification of the MPLS Transport Profile.
著者は、MPLSトランスポートの定義や仕様に関わるチーム（合同ワーキングチーム、IETFでのMPLSの相互運用性設計チーム、およびITU-TでT-MPLSアドホックグループ）のすべてのメンバーに感謝したいと思いますプロフィール。
The authors would also like to thank Loa Andersson, Dieter Beller, Lou Berger, Italo Busi, John Drake, Adrian Farrel, Annamaria Fulignoli, Pietro Grandi, Eric Gray, Neil Harrison, Jia He, Huub van Helvoort, Enrique Hernandez-Valencia, Wataru Imajuku, Kam Lam, Andy Malis, Alan McGuire, Julien Meuric, Greg Mirsky, Tom Nadeau, Hiroshi Ohta, Tom Petch, Andy Reid, Vincenzo Sestito, George Swallow, Lubo Tancevski, Tomonori Takeda, Yuji Tochio, Alexander Vainshtein, Eve Varma, and Maarten Vissers for their comments and enhancements to the text.
著者らはまた、ロア・アンダーソン、ディーターBeller、ルー・バーガー、イタロBUSI、ジョン・ドレイク、エードリアンファレル、Annamaria Fulignoli、ピエトロ・グランディ、エリックグレー、ニールハリソン、嘉氏、HuubバンHelvoort、エンリケ・ヘルナンデス - バレンシア、渉に感謝したいと思いますImajuku、カムラム、アンディMalis、アラン・マクガイア、ジュリアンMeuric、グレッグMirsky、トム・ナドー、太田洋、トム・ペッチ、アンディー・リード、ヴィンチェンツォSestito、ジョージくん、Lubo Tancevski、友則武田雄二栃尾、アレクサンダーVainshtein、イブヴァルマ、テキストへのコメントや機能強化のためとマールテンVissers。
An ad hoc discussion group consisting of Stewart Bryant, Italo Busi, Andrea Digiglio, Li Fang, Adrian Farrel, Jia He, Huub van Helvoort, Feng Huang, Harald Kullman, Han Li, Hao Long, and Nurit Sprecher provided valuable input to the requirements for deployment and survivability in ring topologies.
スチュワートブライアント、イタロBUSI、アンドレアDigiglio、リチウム牙、エードリアンファレル、嘉氏、HuubバンHelvoort、風水黄、ハラルドKullman、ハンリー、ハオロング、およびNurit Sprecherからなるアドホックディスカッショングループは、要件に貴重な入力を提供しましたリングトポロジでの展開とサバイバビリティのために。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985]ブライアント、S.とP.パテ、 "疑似ワイヤーエミュレーション端から端まで（PWE3）アーキテクチャ"、RFC 3985、2005年3月。
[RFC4929] Andersson, L. and A. Farrel, "Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures", BCP 129, RFC 4929, June 2007.
[RFC4929]アンデション、L.とA.ファレル、 "（MPLS）をマルチプロトコルラベルスイッチングのための変更処理と一般化MPLS（GMPLS）プロトコルおよび手順"、BCP 129、RFC 4929、2007年6月。
[ITU.G805.2000] International Telecommunications Union, "Generic functional architecture of transport networks", ITU-T Recommendation G.805, March 2000.
[ITU.G805.2000]国際電気通信連合、ITU-T勧告G.805、2000年3月 "交通網の一般的な機能アーキテクチャ"。
[ITU.G8080.2006] International Telecommunications Union, "Architecture for the automatically switched optical network (ASON)", ITU-T Recommendation G.8080, June 2006.
[ITU.G8080.2006]国際電気通信連合は、ITU-T勧告G.8080、2006年6月 "アーキテクチャのためには、自動的に光ネットワーク（ASON）を切り替えます"。
[ITU.G8080.2008] International Telecommunications Union, "Architecture for the automatically switched optical network (ASON) Amendment 1", ITU-T Recommendation G.8080 Amendment 1, March 2008.
[ITU.G8080.2008]国際電気通信連合は、ITU-T勧告G.8080改正1、2008年3月 "のアーキテクチャは、自動的に光ネットワーク（ASON）改正1を切り替えます"。
[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.、ドレイク、J.、灰、J.、ファレル、A.、およびL.オング、 "自動交換光ネットワーク（ASON）のための一般化MPLS（GMPLS）使用をシグナリングおよび拡張のための要件"、 RFC 4139、2005年7月。
[RFC4258] Brungard, D., "Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON)", RFC 4258, November 2005.
[RFC4258] Brungard、D.、2005年11月、RFC 4258。 "一般マルチプロトコルラベルのための要件は、自動的に光ネットワークを（ASON）スイッチのルーティング（GMPLS）を切り替えます"
[RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture", RFC 4397, February 2006.
[RFC4397] Bryskin、I.およびA.ファレル、「スイッチング一般マルチプロトコルラベルの解釈のための辞書編集（GMPLS）ITU-Tさんの自動交換光ネットワーク（ASON）アーキテクチャのコンテキスト内で用語」2006 RFC 4397、2月。
[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006.
[RFC4427]マニー、E.およびD. Papadimitriou、RFC 4427、2006月 "一般化マルチプロトコルラベルスイッチング（GMPLS）の回復（保護と回復）用語"。
[TP-SEC-FMWK] Fang, L. and B. Niven-Jenkins, "Security Framework for MPLS-TP", Work in Progress, July 2009.
[TP-SEC-FMWK]牙、L.とB.ニーヴン・ジェンキンス、 "MPLS-TPのためのセキュリティフレームワーク" が進歩、2009年7月での作業。
[G/MPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", Work in Progress, July 2009.
[G / MPLS-SEC]牙、L.、エド。、 "MPLSおよびGMPLSネットワークのセキュリティフレームワーク" が進歩、2009年7月での作業。
[TP-NM-REQ] Lam, H., Mansfield, S., and E. Gray, "MPLS TP Network Management Requirements", Work in Progress, June 2009.
[TP-NM-REQ]ラム、H.、マンスフィールド、S.、およびE.グレー、 "MPLS TPネットワーク管理の要件"、進歩、2009年6月に作業。
[TP-TERMS] van Helvoort, H., Ed., Andersson, L., Ed., and N. Sprecher, Ed., "A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport Network Recommendations", Work in Progress, June 2009.
[TP-TERMS]バンHelvoort、H.編、アンダーソン、L.、エド。、及びN. Sprecher、編、「シソーラストランスポートプロファイル（MPLS-TP）ドラフトをマルチプロトコルラベルスイッチングに使用される用語のために/ RFCとITU-Tのトランスポートネットワークの推奨事項」、進歩、2009年6月での作業。
[TP-OAM-REQS] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., "Requirements for OAM in MPLS Transport Networks", Work in Progress, June 2009.
[TP-OAM-REQS] Vigoureux、M.、エド。、ウォード、D.、エド。、およびM.ベッツ、エド。、 "MPLS交通ネットワークにおけるOAMの要件"、進歩、2009年6月での作業。
[MS-PW-ARCH] Bocci, M. and S. Bryant, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", Work in Progress, July 2009.
[MS-PW-ARCH]ボッチ、M.およびS.ブライアント、 "マルチセグメント疑似回線エミュレーションエッジ・ツー・エッジのためのアーキテクチャ"、進歩、2009年7月ワーク。
[ITU.Y1401.2008] International Telecommunications Union, "Principles of interworking", ITU-T Recommendation Y.1401, February 2008.
[ITU.Y1401.2008]国際電気通信連合、 "インターワーキングの原則"、ITU-T勧告Y.1401、2008年2月。
[ITU.Y2611.2006] International Telecommunications Union, "High-level architecture of future packet-based networks", ITU-T Recommendation Y.2611, December 2006.
[ITU.Y2611.2006]国際電気通信連合、ITU-T勧告Y.2611、2006年12月 "未来のパケットベースのネットワークのハイレベルアーキテクチャ"。
Authors' Addresses
著者のアドレス
Ben Niven-Jenkins (editor) BT PP8a, 1st Floor, Orion Building, Adastral Park Ipswich, Suffolk IP5 3RE UK
ベン・ニーヴン・ジェンキンス（エディタ）BT PP8a、1階、オリオンビル、Adastral公園サフォーク州イプスウィッチIP5 3RE英国
EMail: benjamin.niven-jenkins@bt.com
メールアドレス：benjamin.niven-jenkins@bt.com
Deborah Brungard (editor) AT&T Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ 07748 USA
デボラBrungard（エディタ）AT＆T Rmの。 D1-3C22 - 200 S.ローレルアベニュー。ミドルタウン、NJ 07748 USA
EMail: dbrungard@att.com
メールアドレス：dbrungard@att.com
Malcolm Betts (editor) Huawei Technologies
マルコムベッツ（エディタ）華為技術
EMail: malcolm.betts@huawei.com
メールアドレス：malcolm.betts@huawei.com
Nurit Sprecher Nokia Siemens Networks 3 Hanagar St. Neve Ne'eman B Hod Hasharon, 45241 Israel
Nuritのスポークスマンノキアシーメンスネットワークス3 HanagarセントネベNe'emanホッドHasharon B、45241イスラエル
EMail: nurit.sprecher@nsn.com
メールアドレス：nurit.sprecher@nsn.com
Satoshi Ueno NTT Communications
さとし うえの んっｔ こっむにかちおんｓ
EMail: satoshi.ueno@ntt.com
メールアドレス：satoshi.ueno@ntt.com