[要約] RFC 5654は、MPLSトランスポートプロファイルの要件に関する標準化文書であり、MPLSネットワークのトランスポート機能に関する要件を定義しています。その目的は、MPLSネットワークのトランスポートプロファイルの一貫性と互換性を確保することです。
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
MPLS輸送プロファイルの要件
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.
この作業は、IETFで定義されているMPLSとPWE3アーキテクチャ、およびITU-Tで定義されているパケットトランスポートネットワークの2つの要件に基づいています。
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.
Copyright（c）2009 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 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. 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.
o イーサネット、ボイスオーバーIP（VOIP）、レイヤー2（L2） /レイヤー3（L3）仮想プライベートネットワーク（VPNS）、IPテレビ（IPTV）、ラジオアクセスネットワーク（RAN）バックホーリングなどのパケットベースのサービス。
o Applications with various bandwidth and Quality of Service (QoS) requirements.
o さまざまな帯域幅とサービス品質（QOS）要件を備えたアプリケーション。
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.
このドキュメントは、IETF MPLSおよびPWE3アーキテクチャ内にMPLS輸送プロファイルを含めるための共同ITU-TとIETFの取り組みの製品であり、ITU-Tで定義されたパケットトランスポートネットワークの機能と機能をサポートします。このドキュメントは要件仕様ですが、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].
この作業は、IETFで定義されているMPLSとPWE3アーキテクチャ、ITU-Tで定義されている2つの要件、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.
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [RFC2119]に記載されているように解釈される。このドキュメントはプロトコル仕様ではありませんが、この言語の使用は、このドキュメントで定められた要件を満たすソリューションを作成するプロトコル設計者への指示を明確にします。
Note: Mapping between the terms in this section and ITU-T terminology is described in [TP-TERMS].
注：このセクションの用語とITU-T用語のマッピングは、[TPTERMS]で説明されています。
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]で定義された回復用語を使用します。これは、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
L2：レイヤー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
OTN：光輸送ネットワーク
P2MP: Point to Multipoint
P2MP：マルチポイントをポイントします
P2P: Point to Point
P2P：ポイントツーポイント
PDU: Protocol Data Unit
PDU：プロトコルデータユニット
PSC: Protection State Coordination
PSC：保護状態調整
PW: Pseudowire
PW：Pseudowire
QoS: Quality of Service SDH: Synchronous Digital Hierarchy
QOS：サービス品質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：Voice over IP
VPN: Virtual Private Network
VPN：仮想プライベートネットワーク
WDM: Wavelength Division Multiplexing
WDM：波長分割多重化
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つ以上のサブレーヤーで構成されている場合があります。セクション1.4では、レイヤーネットワークを構成するもののより詳細な概要を示します。レイヤーネットワークがレイヤー化のOSI概念にどのように関連するかについての追加の説明については、Y.2611の付録I [ITU.Y2611.2006]を参照してください。
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またはPWSを運ぶ場合があります。リンクを入力するパケットが同じラベルスタックエントリ値で出現します。
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論理リングは、LSRSのセットと論理データリンク（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は他の2つのLSRに接続され、それぞれが単一のポイントツーポイント双方向MPLS-TP有能リンクを介して接続されています。リングは、正確に2つのリンクもある2つのLSRのみから構築できます。リングを他のLSRに接続して、より大きなネットワークを形成できます。リングの外側で発信または終了する交通は、リングの上に運ばれる場合があります。クライアントネットワークノード（CESなど）は、リング内の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つのレイヤーネットワークの1つとして定義していることに注意してください。他のレイヤーネットワークは、物理メディアレイヤーネットワークです。
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.
トランスポートパス：G.805で定義されているネットワーク接続[ITU.G805.2000]。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.
単方向パス：1つの方向のみでトラフィックフローをサポートするパス。
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.
トランスポートネットワークの重要な属性は、どのクライアントが接続サービスを使用しているか、または実行中の送信メディアを使用しているかに関係なく、機能できることです。機能的および運用上の観点から、クライアント、トランスポートネットワーク、およびサーバーレイヤーは、独立したレイヤーネットワークです。輸送ネットワークのもう1つの重要な特徴は、輸送ネットワーク全体でクライアントの完全性を維持する機能です。また、輸送ネットワークは、合意されたサービス品質の提供を検証するために、サービス監視の方法を提供する必要があります。これは、キャリアグレードの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.
A.データプレーンの相互運用性は、ゲートウェイ機能を必要としないでください。
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協調的な双方向輸送経路のエンドポイントは、双方向サービスをサポートするために使用されるフォワードパスと逆パスのペアリング関係に注意する必要があります。
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は、データプレーンからの制御および管理面の物理的な分離をサポートする必要があります。つまり、制御および管理機を帯域外に操作することは可能である必要があります。また、データプレーンチャネルの状態については、制御または管理面チャネルが不足しているときに、データプレーンチャネルの状態について仮定を立てるべきではありません。 - バンドの。
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.
21一般的な輸送層ネットワークに共通する機能的要件を満たすMPLS-TPレイヤーネットワークのメカニズム（つまり、テクノロジーとは無関係）は、他の輸送で同等のメカニズムが動作する方法に似た方法で動作可能でなければなりません。レイヤーテクノロジー。
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.
A. MPLS-TPレイヤーネットワークの構成と操作に使用される制御または管理プレーンに依存しないデータを転送します。
B. taking recovery actions independent of the control or management plane used to configure the MPLS-TP layer network.
B. MPLS-TPレイヤーネットワークの構成に使用される制御または管理プレーンとは無関係に回復アクションを実行します。
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. 1つまたは2つのポイントの相互接続を備えた任意の相互接続リングに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 MPLS-TPレイヤーネットワーク上で1つ以上のクライアントレイヤーネットワーク（MPLS-TP、IP、MPLS、イーサネット、ATM、FRなど）の輸送をサポートするために、一般的で拡張可能なソリューションを提供する必要があります。
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 1つ以上のサーバーレイヤーネットワーク（MPLS-TP、イーサネット、SONET/SDH、OTNなど）を介した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.
32 MPLS-TPレイヤーネットワークがクライアントレイヤーネットワークをサポートし、MPLS-TPレイヤーネットワークがサーバーレイヤーネットワークによってサポートされている環境では、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.
A.サーバーレイヤーは、他のクライアントによって課されるトラフィックロードがMPLS-TPレイヤーに提供される輸送サービスを合意されたレベルを下回らないことを保証する必要があります。これを達成するメカニズムは、これらの要件の範囲外です。
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).
A.クライアントとサーバーMPLS（-TP）レイヤーネットワークの間で必要な調整のレベルを最小限に抑える必要があります（できれば調整は必要ありません）。
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またはConnectionless Network Protocolではないパケットが含まれる場合があるクライアント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レイヤーネットワークのアドレス指定やその他の情報（トポロジなど）を非表示にすることができなければなりません。ただし、オペレーターのオプションで、レイヤー間で限られた量の要約情報（SRLGや到達可能性など）を漏らすことができるはずです。
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サーバー（Sub）レイヤー機能とP2Pサーバー（Sub）レイヤー機能を使用できる必要があります。
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は、G.8080 [ITU.G8080.2006]およびG.8080修正1 [ITU.G8080.2008]の自動化された光ネットワーク（ASON）のアーキテクチャを定義しました。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.
A. MPLS-TP回復手法は、実装と操作を簡素化するために既存の輸送ネットワークで既に使用されているものと同一（または可能な限り類似）する必要があります。ただし、これは他の要件を無効にしてはなりません。
B. Recovery techniques used for P2P and P2MP SHOULD be identical to simplify implementation and operation. However, this MUST NOT override any other requirement.
B. P2PおよびP2MPに使用される回復技術は、実装と動作を簡素化するために同一である必要があります。ただし、これは他の要件を無効にしてはなりません。
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.
A. MPLS-TPは、1200 km未満のネットワークでの障害検出の瞬間から50msの回復時間を保証するメカニズムを提供する必要があります。
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回復目標は、輸送パスごとに構成可能である必要があります。
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.
A.双方向1 1 P2P接続の保護をサポートする必要があります。
B. Unidirectional 1+1 protection for P2P connectivity MUST be supported.
B.単方向1 1 P2P接続の保護をサポートする必要があります。
C. Unidirectional 1+1 protection for P2MP connectivity MUST be supported.
C.単方向1 1 P2MP接続の保護をサポートする必要があります。
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).
67 MPLS-TPは1：N保護（1：1保護を含む）をサポートする必要があります。
A. Bidirectional 1:n protection for P2P connectivity MUST be supported and SHOULD be the default behavior for 1:n protection.
A.双方向1：N P2P接続の保護をサポートする必要があり、1：N保護のデフォルトの動作である必要があります。
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.
注：MPLS-TPでは、余分なトラフィック（[RFC4427]で定義されている）のサポートは不要であり、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.
83 [RFC4427]で定義されている外部コントロールをサポートする必要があります。
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.
A.外部コントロールは、優先度の高い要求（リンク/ノードの障害による管理リクエストや要求など）またはリモートエンドに信号を送信できないこと（たとえば、保護状態の調整障害のため）を削除する必要があります。
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.
A.保護/回復輸送パスの完全性を含む。
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
A.すべての回復エンティティと機能の確立とメンテナンス
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は、特定のネットワークトポロジに最適化された回復メカニズムをサポートする場合があります。これらのメカニズムは、エンドツーエンドの輸送経路の保護を可能にするために、任意のトポロジ（MESH）ネットワークで定義されたメカニズムと相互運用可能でなければなりません。
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.
e. コントロールプレーンがサポートされている場合は、保護中のシグナリングおよびルーティング情報交換への影響を最小限に抑え、他の回復メカニズムによって引き起こされる影響よりも少なくなります。
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から包括的セクション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 km未満のファイバーを持つ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)
A.輸送パスの数（線形スケーリングよりも優れている必要があります）
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.
A.実装が、優先度に基づいて保護スイッチングのために、共存するリクエストまたはトリガーを処理および調整できるメカニズムを含める必要があります。（たとえば、これには、必ずしも同時に到着するとは限らず、リング内のどこにでもある複数のリクエストが含まれます。）リングの調整は、共有保護グループの使用に相当することに注意してください。
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ハードおよび相対的なエンドツーエンド帯域幅のサポートを伴うサービスレベル仕様（SLS）のプロビジョニングと保証を有効にする。
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.
著者はまた、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、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 to chiio、evainsanderそして、マルテン・ヴィッサーのコメントとテキストの強化について。
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.
スチュワート・ブライアント、イタロ・ブシ、アンドレア・ディギリオ、リー・ファン、エイドリアン・ファレル、ジア・HE、フーブ・ヴァン・ヘルヴォルト、フェン・ファン、ハラルド・クルマン、ハン・リー、ハオ・ロング、およびヌリット・スプレッチャで構成されるアドホックディスカッショングループは、要件に貴重なインプットを提供しましたリングトポロジーの展開と生存性。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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月。
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985] Bryant、S。およびP. Pate、「Pseudo Wire Emulation Edge-to-Edge（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] Andersson、L。およびA. Farrel、「マルチプロトコルラベルスイッチング（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] International Telecommunications Union、「輸送ネットワークの一般的な機能アーキテクチャ」、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] International Telecommunications Union、「自動化された光ネットワーク（ASON）のアーキテクチャ」、ITU-T推奨G.8080、2006年6月。
[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] International Telecommunications Union、「自動的に切り替えられた光ネットワーク（ASON）修正1」のアーキテクチャ、ITU-T推奨G.8080修正1、2008年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月。
[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。、「自動化された光ネットワーク（ASON）の一般化されたマルチプロトコルラベルスイッチング（GMPLS）ルーティングの要件」、RFC 4258、2005年11月。
[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. Farrel、「ITU-Tの自動切り替え光ネットワーク（ASON）アーキテクチャのコンテキスト内の一般化マルチプロトコルラベルスイッチング（GMPLS）の用語の解釈のための辞書誌」、RFC 4397、2006年2月。
[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006.
[RFC4427] Mannie、E。およびD. Papadimitriou、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）の回復（保護および回復）用語」、RFC 4427、2006年3月。
[TP-SEC-FMWK] Fang, L. and B. Niven-Jenkins, "Security Framework for MPLS-TP", Work in Progress, July 2009.
[TP-SEC-FMWK] Fang、L。およびB. Niven-Jenkins、「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] Fang、L.、ed。、「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] Lam、H.、Mansfield、S。、およびE. Gray、「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] van Helvoort、H.、ed。、Andersson、L.、ed。、およびN. Sprecher、ed。、「マルチプロトコルラベルスイッチングトランスポートプロファイル（MPLS-TP）ドラフトで使用される用語のシソーラス/RFCSおよび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.、ed。、ed。、Ward、D.、ed。、およびM. Betts、ed。、「MPLS Transport Networksの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] Bocci、M。およびS. Bryant、「マルチセグメントの擬似ワイヤエミュレーションエッジツーエッジのアーキテクチャ」、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] International Telecommunications Union、「将来のパケットベースのネットワークの高レベルアーキテクチャ」、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
Ben Niven-Jenkins（編集者）BT PP8A、1階、Orion Building、Adastral Park Ipswich、Suffolk IP5 3RE UK
EMail: benjamin.niven-jenkins@bt.com
Deborah Brungard (editor) AT&T Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ 07748 USA
Deborah Brungard（編集者）AT＆T RM。D1-3C22-200 S.ローレルアベニュー、ミドルタウン、ニュージャージー07748 USA
EMail: dbrungard@att.com
Malcolm Betts (editor) Huawei Technologies
Malcolm Betts（編集者）Huawei Technologies
EMail: malcolm.betts@huawei.com
Nurit Sprecher Nokia Siemens Networks 3 Hanagar St. Neve Ne'eman B Hod Hasharon, 45241 Israel
Nurit Sprecher Nokia Siemens Networks 3 Hanagar St. Neve Ne'eman B Hod Hasharon、45241 Israel
EMail: nurit.sprecher@nsn.com
Satoshi Ueno NTT Communications
Satoshi Ueno ntt通信
EMail: satoshi.ueno@ntt.com