[要約] RFC 5921は、トランスポートネットワークでのMPLSのフレームワークを提供するものであり、MPLSの導入と運用に関するガイドラインを提供します。その目的は、MPLSを使用した効率的で信頼性の高いトランスポートネットワークの構築を支援することです。
Internet Engineering Task Force (IETF) M. Bocci, Ed.
Request for Comments: 5921 Alcatel-Lucent
Category: Informational S. Bryant, Ed.
ISSN: 2070-1721 D. Frost, Ed.
Cisco Systems
L. Levrau
Alcatel-Lucent
L. Berger
LabN
July 2010
A Framework for MPLS in Transport Networks
輸送ネットワークのMPLのフレームワーク
Abstract
概要
This document specifies an architectural framework for the application of Multiprotocol Label Switching (MPLS) to the construction of packet-switched transport networks. It describes a common set of protocol functions -- the MPLS Transport Profile (MPLS-TP) -- that supports the operational models and capabilities typical of such networks, including signaled or explicitly provisioned bidirectional connection-oriented paths, protection and restoration mechanisms, comprehensive Operations, Administration, and Maintenance (OAM) functions, and network operation in the absence of a dynamic control plane or IP forwarding support. Some of these functions are defined in existing MPLS specifications, while others require extensions to existing specifications to meet the requirements of the MPLS-TP.
このドキュメントは、マルチプロトコルラベルスイッチング（MPLS）をパケットスイッチの輸送ネットワークの構築に適用するためのアーキテクチャフレームワークを指定しています。これは、共通のプロトコル関数（MPLS輸送プロファイル（MPLS-TP））の共通のセットを説明します。これは、そのようなネットワークに典型的な運用モデルと機能をサポートします。動的制御プレーンまたはIP転送サポートがない場合の運用、管理、およびメンテナンス（OAM）機能、およびネットワーク操作。これらの関数の一部は既存のMPLS仕様で定義されていますが、MPLS-TPの要件を満たすために既存の仕様の拡張を必要とするものもあります。
This document defines the subset of the MPLS-TP applicable in general and to point-to-point transport paths. The remaining subset, applicable specifically to point-to-multipoint transport paths, is outside the scope of this document.
このドキュメントでは、一般的に適用可能なMPLS-TPのサブセットと、ポイントツーポイントの輸送パスを定義します。ポイントツーマルチポイントトランスポートパスに特に適用される残りのサブセットは、このドキュメントの範囲外です。
This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.
このドキュメントは、IETF MPLSおよびPSEUDOWIREエミュレーションエッジツーエッジ（PWE3）アーキテクチャ内にMPLS輸送プロファイルを含めるための共同インターネットエンジニアリングタスクフォース（IETF） /国際電気通信連合電気通信標準化セクター（ITU-T）の製品です。ITU-Tで定義されているパケット輸送ネットワークの機能と機能をサポートする。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5921.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5921で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Motivation and Background . . . . . . . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1. Transport Network . . . . . . . . . . . . . . . . . . 7
1.3.2. MPLS Transport Profile . . . . . . . . . . . . . . . . 7
1.3.3. MPLS-TP Section . . . . . . . . . . . . . . . . . . . 7
1.3.4. MPLS-TP Label Switched Path . . . . . . . . . . . . . 7
1.3.5. MPLS-TP Label Switching Router . . . . . . . . . . . . 8
1.3.6. Customer Edge (CE) . . . . . . . . . . . . . . . . . . 10
1.3.7. Transport LSP . . . . . . . . . . . . . . . . . . . . 10
1.3.8. Service LSP . . . . . . . . . . . . . . . . . . . . . 10
1.3.9. Layer Network . . . . . . . . . . . . . . . . . . . . 10
1.3.10. Network Layer . . . . . . . . . . . . . . . . . . . . 10
1.3.11. Service Interface . . . . . . . . . . . . . . . . . . 10
1.3.12. Native Service . . . . . . . . . . . . . . . . . . . . 11
1.3.13. Additional Definitions and Terminology . . . . . . . . 11
2. MPLS Transport Profile Requirements . . . . . . . . . . . . . 11
3. MPLS Transport Profile Overview . . . . . . . . . . . . . . . 12
3.1. Packet Transport Services . . . . . . . . . . . . . . . . 12
3.2. Scope of the MPLS Transport Profile . . . . . . . . . . . 13
3.3. Architecture . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.1. MPLS-TP Native Service Adaptation Functions . . . . . 14
3.3.2. MPLS-TP Forwarding Functions . . . . . . . . . . . . . 15
3.4. MPLS-TP Native Service Adaptation . . . . . . . . . . . . 16
3.4.1. MPLS-TP Client/Server Layer Relationship . . . . . . . 16
3.4.2. MPLS-TP Transport Layers . . . . . . . . . . . . . . . 17
3.4.3. MPLS-TP Transport Service Interfaces . . . . . . . . . 18
3.4.4. Pseudowire Adaptation . . . . . . . . . . . . . . . . 25
3.4.5. Network Layer Adaptation . . . . . . . . . . . . . . . 28
3.5. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 33
3.6. Generic Associated Channel (G-ACh) . . . . . . . . . . . . 33
3.7. Operations, Administration, and Maintenance (OAM) . . . . 36
3.8. Return Path . . . . . . . . . . . . . . . . . . . . . . . 38
3.8.1. Return Path Types . . . . . . . . . . . . . . . . . . 39
3.8.2. Point-to-Point Unidirectional LSPs . . . . . . . . . . 39
3.8.3. Point-to-Point Associated Bidirectional LSPs . . . . . 40
3.8.4. Point-to-Point Co-Routed Bidirectional LSPs . . . . . 40
3.9. Control Plane . . . . . . . . . . . . . . . . . . . . . . 40
3.10. Inter-Domain Connectivity . . . . . . . . . . . . . . . . 43
3.11. Static Operation of LSPs and PWs . . . . . . . . . . . . . 43
3.12. Survivability . . . . . . . . . . . . . . . . . . . . . . 44
3.13. Sub-Path Maintenance . . . . . . . . . . . . . . . . . . . 45
3.14. Network Management . . . . . . . . . . . . . . . . . . . . 47
4. Security Considerations . . . . . . . . . . . . . . . . . . . 48
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.1. Normative References . . . . . . . . . . . . . . . . . . . 50
7.2. Informative References . . . . . . . . . . . . . . . . . . 51
This document describes an architectural framework for the application of MPLS to the construction of packet-switched transport networks. It specifies the common set of protocol functions that meet the requirements in [RFC5654], and that together constitute the MPLS Transport Profile (MPLS-TP) for point-to-point transport paths. The remaining MPLS-TP functions, applicable specifically to point-to-multipoint transport paths, are outside the scope of this document.
このドキュメントでは、Packet-Switched Transport Networksの構築にMPLを適用するためのアーキテクチャフレームワークについて説明します。[RFC5654]の要件を満たすプロトコル関数の共通セットを指定し、ポイントツーポイント輸送パスのMPLS輸送プロファイル（MPLS-TP）を一緒に構成します。残りのMPLS-TP関数は、特にポイントツーマルチポイントトランスポートパスに適用され、このドキュメントの範囲外です。
Historically, the optical transport infrastructure -- Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) and Optical Transport Network (OTN) -- has provided carriers with a high benchmark for reliability and operational simplicity. To achieve this, transport technologies have been designed with specific characteristics:
歴史的に、光学輸送インフラストラクチャ - 同期光ネットワーク/同期デジタル階層（SONET/SDH）および光輸送ネットワーク（OTN） - は、信頼性と運用上のシンプルさのための高いベンチマークをキャリアに提供しました。これを達成するために、輸送技術は特定の特性で設計されています。
o Strictly connection-oriented connectivity, which may be long-lived and may be provisioned manually, for example, by network management systems or direct node configuration using a command line interface.
o 厳密に接続指向の接続性は、長命であり、たとえばネットワーク管理システムまたはコマンドラインインターフェイスを使用した直接ノード構成によって手動でプロビジョニングされる場合があります。
o A high level of availability.
o 高いレベルの可用性。
o Quality of service.
o サービスの質。
o Extensive Operations, Administration, and Maintenance (OAM) capabilities.
o 広範な運用、管理、およびメンテナンス（OAM）機能。
Carriers wish to evolve such transport networks to take advantage of the flexibility and cost benefits of packet switching technology and to support packet-based services more efficiently. While MPLS is a maturing packet technology that already plays an important role in transport networks and services, not all MPLS capabilities and mechanisms are needed in, or consistent with, the transport network operational model. There are also transport technology characteristics that are not currently reflected in MPLS.
キャリアは、パケットスイッチングテクノロジーの柔軟性とコストのメリットを活用し、パケットベースのサービスをより効率的にサポートするために、このような輸送ネットワークを進化させたいと考えています。MPLSは、輸送ネットワークとサービスですでに重要な役割を果たしている成熟パケットテクノロジーですが、輸送ネットワークの運用モデルですべてのMPLS機能とメカニズムが必要であるか、一致しているわけではありません。また、MPLSには現在反映されていない輸送技術の特性もあります。
There are thus two objectives for MPLS-TP:
したがって、MPLS-TPには2つの目的があります。
1. To enable MPLS to be deployed in a transport network and operated in a similar manner to existing transport technologies.
1. MPLを輸送ネットワークに展開し、既存の輸送技術と同様の方法で操作できるようにする。
2. To enable MPLS to support packet transport services with a similar degree of predictability to that found in existing transport networks.
2. MPLSが既存の輸送ネットワークに見られるものと同様の予測可能性を備えたパケット輸送サービスをサポートできるようにします。
In order to achieve these objectives, there is a need to define a common set of MPLS protocol functions -- an MPLS Transport Profile -- for the use of MPLS in transport networks and applications. Some of the necessary functions are provided by existing MPLS specifications, while others require additions to the MPLS tool-set. Such additions should, wherever possible, be applicable to MPLS networks in general as well as those that conform strictly to the transport network model.
これらの目的を達成するために、輸送ネットワークとアプリケーションでMPLSを使用するために、MPLSプロトコル関数の共通セット（MPLS輸送プロファイル）を定義する必要があります。必要な関数のいくつかは、既存のMPLS仕様によって提供されますが、他の関数はMPLSツールセットへの追加を必要とします。このような追加は、可能な限り、一般的にMPLSネットワークに適用できるだけでなく、輸送ネットワークモデルに厳密に適合する必要があります。
This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.
このドキュメントは、IETF MPLSおよびPWE3アーキテクチャ内にMPLS輸送プロファイルを含めるための共同インターネットエンジニアリングタスクフォース（IETF） /国際電気通信連合電気通信標準化セクター（ITU-T）の製品です。ITU-Tで定義されている輸送ネットワーク。
This document describes an architectural framework for the application of MPLS to the construction of packet-switched transport networks. It specifies the common set of protocol functions that meet the requirements in [RFC5654], and that together constitute the MPLS Transport Profile (MPLS-TP) for point-to-point MPLS-TP transport paths. The remaining MPLS-TP functions, applicable specifically to point-to-multipoint transport paths, are outside the scope of this document.
このドキュメントでは、Packet-Switched Transport Networksの構築にMPLを適用するためのアーキテクチャフレームワークについて説明します。[RFC5654]の要件を満たすプロトコル関数の一般的なセットを指定し、ポイントツーポイントMPLS-TP輸送パスのMPLS輸送プロファイル（MPLS-TP）を構成します。残りのMPLS-TP関数は、特にポイントツーマルチポイントトランスポートパスに適用され、このドキュメントの範囲外です。
Term Definition
---------- ----------------------------------------------------------
AC Attachment Circuit
ACH Associated Channel Header
Adaptation The mapping of client information into a format suitable
for transport by the server layer
APS Automatic Protection Switching
ATM Asynchronous Transfer Mode
BFD Bidirectional Forwarding Detection
CE Customer Edge
CL-PS Connectionless - Packet Switched
CM Configuration Management
CO-CS Connection Oriented - Circuit Switched
CO-PS Connection Oriented - Packet Switched
DCN Data Communication Network
EMF Equipment Management Function
FCAPS Fault, Configuration, Accounting, Performance, and
Security
FM Fault Management
G-ACh Generic Associated Channel
GAL G-ACh Label
LER Label Edge Router
LSP Label Switched Path
LSR Label Switching Router
MAC Media Access Control
MCC Management Communication Channel
ME Maintenance Entity
MEG Maintenance Entity Group
MEP Maintenance Entity Group End Point
MIP Maintenance Entity Group Intermediate Point
MPLS Multiprotocol Label Switching
MPLS-TP MPLS Transport Profile
MPLS-TP P MPLS-TP Provider LSR
MPLS-TP PE MPLS-TP Provider Edge LSR
MS-PW Multi-Segment Pseudowire
Native The traffic belonging to the client of the MPLS-TP network
Service
OAM Operations, Administration, and Maintenance (see
[OAM-DEF])
OSI Open Systems Interconnection
OTN Optical Transport Network
PDU Protocol Data Unit
PM Performance Monitoring
PSN Packet Switching Network
PW Pseudowire
SCC Signaling Communication Channel
SDH Synchronous Digital Hierarchy
S-PE PW Switching Provider Edge
SPME Sub-Path Maintenance Element
SS-PW Single-Segment Pseudowire
T-PE PW Terminating Provider Edge
TE LSP Traffic Engineered Label Switched Path
VCCV Virtual Circuit Connectivity Verification
A Transport Network provides transparent transmission of user traffic between attached client devices by establishing and maintaining point-to-point or point-to-multipoint connections between such devices. The architecture of networks supporting point-to-multipoint connections is outside the scope of this document. A Transport Network is independent of any higher-layer network that may exist between clients, except to the extent required to supply this transmission service. In addition to client traffic, a Transport Network may carry traffic to facilitate its own operation, such as that required to support connection control, network management, and Operations, Administration, and Maintenance (OAM) functions.
トランスポートネットワークは、そのようなデバイス間でポイントツーポイントまたはポイントツーマルチポイント接続を確立および維持することにより、接続されたクライアントデバイス間のユーザートラフィックの透明な送信を提供します。ポイントツーマルチポイント接続をサポートするネットワークのアーキテクチャは、このドキュメントの範囲外です。トランスポートネットワークは、この伝送サービスを提供するために必要な範囲を除き、クライアント間で存在する可能性のある高層ネットワークとは無関係です。クライアントのトラフィックに加えて、トランスポートネットワークは、接続制御、ネットワーク管理、および運用、管理、メンテナンス（OAM）機能をサポートするために必要なものなど、独自の運用を促進するためにトラフィックを運ぶ場合があります。
See also the definition of packet transport service in Section 3.1.
セクション3.1のパケット輸送サービスの定義も参照してください。
The MPLS Transport Profile (MPLS-TP) is the subset of MPLS functions that meet the requirements in [RFC5654]. Note that MPLS is defined to include any present and future MPLS capability specified by the IETF, including those capabilities specifically added to support transport network requirements [RFC5654].
MPLS輸送プロファイル（MPLS-TP）は、[RFC5654]の要件を満たすMPLS関数のサブセットです。MPLSは、IETFによって指定された現在および将来のMPLS機能を含むように定義されていることに注意してください。
MPLS-TP sections are defined in [DATA-PLANE]. See also the definition of "section layer network" in Section 1.2.2 of [RFC5654].
MPLS-TPセクションは[データプレーン]で定義されています。[RFC5654]のセクション1.2.2の「セクションレイヤーネットワーク」の定義も参照してください。
An MPLS-TP Label Switched Path (MPLS-TP LSP) is an LSP that uses a subset of the capabilities of an MPLS LSP in order to meet the requirements of an MPLS transport network as set out in [RFC5654]. The characteristics of an MPLS-TP LSP are primarily that it:
MPLS-TPラベルスイッチ付きパス（MPLS-TP LSP）は、[RFC5654]に記載されているMPLSトランスポートネットワークの要件を満たすために、MPLS LSPの機能のサブセットを使用するLSPです。MPLS-TP LSPの特性は、主にそれです。
1. Uses a subset of the MPLS OAM tools defined in [OAM-FRAMEWORK].
1. [OAMフレームワーク]で定義されたMPLS OAMツールのサブセットを使用します。
2. Supports 1+1, 1:1, and 1:N protection functions.
2. 1 1、1：1、および1：n保護機能をサポートします。
3. Is traffic engineered.
3. トラフィックが設計されています。
4. May be established and maintained via the management plane, or using GMPLS protocols when a control plane is used.
4. 管理プレーンを介して、またはコントロールプレーンを使用したときにGMPLSプロトコルを使用して確立および維持される場合があります。
5. Is either point-to-point or point-to-multipoint. Multipoint-to-point and multipoint-to-multipoint LSPs are not supported.
5. ポイントツーポイントまたはポイントツーマルチポイントです。マルチポイントツーポイントとマルチポイントからマルチポイントLSPはサポートされていません。
6. It is either unidirectional, associated bidirectional, or co-routed bidirectional (i.e., the forward and reverse components of a bidirectional LSP follow the same path, and the intermediate nodes are aware of their association). These are further defined in [DATA-PLANE].
6. これは、単方向、関連する双方向、または同時双方向のいずれかです（すなわち、双方向LSPの前方および逆コンポーネントが同じ経路をたどり、中間ノードはその関連を認識しています）。これらは[データプレーン]でさらに定義されています。
Note that an MPLS LSP is defined to include any present and future MPLS capability, including those specifically added to support the transport network requirements.
MPLS LSPは、輸送ネットワークの要件をサポートするために特別に追加された機能を含む、現在および将来のMPLS機能を含むように定義されていることに注意してください。
See [DATA-PLANE] for further details on the types and data-plane properties of MPLS-TP LSPs.
MPLS-TP LSPのタイプとデータプレーンプロパティの詳細については、[Data-Plane]を参照してください。
The lowest server layer provided by MPLS-TP is an MPLS-TP LSP. The client layers of an MPLS-TP LSP may be network-layer protocols, MPLS LSPs, or PWs. The relationship of an MPLS-TP LSP to its client layers is described in detail in Section 3.4.
MPLS-TPによって提供される最低サーバーレイヤーは、MPLS-TP LSPです。MPLS-TP LSPのクライアントレイヤーは、ネットワーク層プロトコル、MPLS LSP、またはPWSです。MPLS-TP LSPとクライアントレイヤーとの関係については、セクション3.4で詳しく説明しています。
An MPLS-TP Label Switching Router (LSR) is either an MPLS-TP Provider Edge (PE) router or an MPLS-TP Provider (P) router for a given LSP, as defined below. The terms MPLS-TP PE router and MPLS-TP P router describe logical functions; a specific node may undertake only one of these roles on a given LSP.
MPLS-TPラベルスイッチングルーター（LSR）は、以下に定義するように、特定のLSPのMPLS-TPプロバイダーエッジ（PE）ルーターまたはMPLS-TPプロバイダー（P）ルーターのいずれかです。MPLS-TP PEルーターとMPLS-TP Pルーターという用語は、論理関数を説明しています。特定のノードは、特定のLSPでこれらの役割の1つのみを引き受ける場合があります。
Note that the use of the term "router" in this context is historic and neither requires nor precludes the ability to perform IP forwarding.
このコンテキストでの「ルーター」という用語の使用は歴史的であり、IP転送を実行する能力を必要としないことも必要としないことに注意してください。
An MPLS-TP Label Edge Router (LER) is an LSR that exists at the endpoints of an LSP and therefore pushes or pops the LSP label, i.e., does not perform a label swap on the particular LSP under consideration.
MPLS-TPラベルエッジルーター（LER）は、LSPのエンドポイントに存在するLSRであるため、LSPラベルを押したりポップしたりします。つまり、検討中の特定のLSPでラベルスワップを実行しません。
An MPLS-TP Provider Edge (PE) router is an MPLS-TP LSR that adapts client traffic and encapsulates it to be transported over an MPLS-TP LSP. Encapsulation may be as simple as pushing a label, or it may require the use of a pseudowire. An MPLS-TP PE exists at the interface between a pair of layer networks. For an MS-PW, an MPLS-TP PE may be either an S-PE or a T-PE, as defined in [RFC5659] (see below). A PE that pushes or pops an LSP label is an LER for that LSP.
MPLS-TPプロバイダーEdge（PE）ルーターは、クライアントトラフィックを適応させ、MPLS-TP LSPを介して輸送されるようにカプセル化するMPLS-TP LSRです。カプセル化は、ラベルを押すのと同じくらい簡単な場合があります。または、擬似ワイヤーの使用が必要になる場合があります。MPLS-TP PEは、レイヤーネットワークのペア間のインターフェイスに存在します。MS-PWの場合、MPLS-TP PEは、[RFC5659]で定義されているように、S-PEまたはT-PEのいずれかである場合があります（以下を参照）。LSPラベルを押したりポップしたりするPEは、そのLSPの場合です。
The term Provider Edge refers to the node's role within a provider's network. A provider edge router resides at the edge of a given MPLS-TP network domain, in which case it has links to another MPLS-TP network domain or to a CE, except for the case of a pseudowire switching provider edge (S-PE) router, which is not restricted to the edge of an MPLS-TP network domain.
プロバイダーEdgeという用語は、プロバイダーのネットワーク内でのノードの役割を指します。プロバイダーエッジルーターは、特定のMPLS-TPネットワークドメインのエッジに存在します。この場合、擬似ワイヤスイッチングプロバイダーエッジ（S-PE）の場合を除き、別のMPLS-TPネットワークドメインまたはCEへのリンクがあります。MPLS-TPネットワークドメインの端に制限されていないルーター。
An MPLS-TP Provider router is an MPLS-TP LSR that does not provide MPLS-TP PE functionality for a given LSP. An MPLS-TP P router switches LSPs that carry client traffic, but does not adapt client traffic and encapsulate it to be carried over an MPLS-TP LSP. The term Provider Router refers to the node's role within a provider's network. A provider router does not have links to other MPLS-TP network domains.
MPLS-TPプロバイダールーターは、特定のLSPにMPLS-TP PE機能を提供しないMPLS-TP LSRです。MPLS-TP Pルーターは、クライアントのトラフィックを運ぶが、クライアントトラフィックを適応させず、MPLS-TP LSPに携帯するようにカプセル化するLSPを切り替えます。プロバイダールーターという用語は、プロバイダーのネットワーク内でのノードの役割を指します。プロバイダールーターには、他のMPLS-TPネットワークドメインへのリンクがありません。
RFC 5659 [RFC5659] defines an S-PE as:
RFC 5659 [RFC5659]は、S-PEを次のように定義します。
A PE capable of switching the control and data planes of the preceding and succeeding PW segments in an MS-PW. The S-PE terminates the PSN tunnels of the preceding and succeeding segments of the MS-PW. It therefore includes a PW switching point for an MS-PW. A PW switching point is never the S-PE and the T-PE for the same MS-PW. A PW switching point runs necessary protocols to set up and manage PW segments with other PW switching points and terminating PEs. An S-PE can exist anywhere a PW must be processed or policy applied. It is therefore not limited to the edge of a provider network.
MS-PWで前後のPWセグメントの制御面とデータプレーンを切り替えることができるPE。S-PEは、MS-PWの前後のセグメントのPSNトンネルを終了します。したがって、MS-PWのPWスイッチングポイントが含まれます。PWスイッチングポイントは、同じMS-PWのS-PEとT-PEではありません。PWスイッチングポイントは、他のPWスイッチングポイントと終端PEでPWセグメントをセットアップおよび管理するために必要なプロトコルを実行します。S-PEは、PWを処理するか、ポリシーを適用する必要がある場所に存在できます。したがって、プロバイダーネットワークの端に限定されません。
Note that it was originally anticipated that S-PEs would only be deployed at the edge of a provider network where they would be used to switch the PWs of different service providers. However, as the design of MS-PW progressed, other applications for MS-PW were recognized. By this time S-PE had become the accepted term for the equipment, even though they were no longer universally deployed at the provider edge.
もともとは、S-PEがプロバイダーネットワークの端にのみ展開され、異なるサービスプロバイダーのPWSを切り替えるために使用されることが予想されていたことに注意してください。ただし、MS-PWの設計が進むにつれて、MS-PWの他のアプリケーションが認識されました。この時までに、S-PEは、プロバイダーのエッジに普遍的に展開されなくなったとしても、機器の承認された用語になりました。
RFC 5659 [RFC5659] defines a T-PE as:
RFC 5659 [RFC5659]はT-PEを次のように定義します。
A PE where the customer-facing attachment circuits (ACs) are bound to a PW forwarder. A terminating PE is present in the first and last segments of an MS-PW. This incorporates the functionality of a PE as defined in RFC 3985.
顧客向けのアタッチメント回路（ACS）がPWフォワーダーにバインドされるPE。MS-PWの最初と最後のセグメントに終了PEが存在します。これには、RFC 3985で定義されているPEの機能が組み込まれています。
A Customer Edge (CE) is the client function that sources or sinks native service traffic to or from the MPLS-TP network. CEs on either side of the MPLS-TP network are peers and view the MPLS-TP network as a single link.
カスタマーエッジ（CE）は、MPLS-TPネットワークとの間でネイティブサービストラフィックをソースまたはシンクするクライアント機能です。MPLS-TPネットワークの両側のCESはピアであり、MPLS-TPネットワークを単一のリンクと見なしています。
A Transport LSP is an LSP between a pair of PEs that may transit zero or more MPLS-TP provider routers. When carrying PWs, the Transport LSP is equivalent to the PSN tunnel LSP in [RFC3985] terminology.
トランスポートLSPは、ゼロ以上のMPLS-TPプロバイダールーターを通過する可能性のあるPESのペア間のLSPです。PWSを運ぶ場合、輸送LSPは[RFC3985]用語のPSNトンネルLSPに相当します。
A service LSP is an LSP that carries a single client service.
サービスLSPは、単一のクライアントサービスを搭載するLSPです。
A layer network is defined in [G.805] and described in [RFC5654]. 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.
レイヤーネットワークは[G.805]で定義され、[RFC5654]で説明されています。レイヤーネットワークは、クライアント情報の転送とクライアントOAMの独立した操作を提供します。レイヤーネットワークは、次のようにサービスコンテキストで説明できます。1つのレイヤーネットワークは、より高いクライアントレイヤーネットワークに（トランスポート）サービスを提供し、次に、低レイヤーネットワークのクライアントになる場合があります。レイヤーネットワークは、物理的なネットワーク要素の配置または構成から多少独立した論理構造です。特定の物理ネットワーク要素は、論理レイヤー（ラベルスタックなど）に関連付けられているカプセル化にとるアクションに応じて、複数のレイヤーネットワークに属する可能性があるため、複数の論理要素としてモデル化できます。レイヤーネットワークは、1つ以上のサブレーヤーで構成されている場合があります。
This document uses the term Network Layer in the same sense as it is used in [RFC3031] and [RFC3032]. Network-layer protocols are synonymous with those belonging to Layer 3 of the Open System Interconnect (OSI) network model [X.200].
このドキュメントでは、[RFC3031]および[RFC3032]で使用されているのと同じ意味で、ネットワークレイヤーという用語を使用します。ネットワーク層プロトコルは、Open System Interconnect（OSI）ネットワークモデル[X.200]のレイヤー3に属するものと同義です。
The packet transport service provided by MPLS-TP is provided at a service interface. Two types of service interfaces are defined:
MPLS-TPが提供するパケット輸送サービスは、サービスインターフェイスで提供されます。2種類のサービスインターフェイスが定義されています。
o User-Network Interface (UNI) (see Section 3.4.3.1).
o ユーザーネットワークインターフェイス（UNI）（セクション3.4.3.1を参照）。
o Network-Network Interface (NNI) (see Section 3.4.3.2).
o ネットワークネットワークインターフェイス（NNI）（セクション3.4.3.2を参照）。
A UNI service interface may be a Layer 2 interface that carries only network layer clients. MPLS-TP LSPs are both necessary and sufficient to support this service interface as described in Section 3.4.3. Alternatively, it may be a Layer 2 interface that carries both network-layer and non-network-layer clients. To support this service interface, a PW is required to adapt the client traffic received over the service interface. This PW in turn is a client of the MPLS-TP server layer. This is described in Section 3.4.2.
UNIサービスインターフェイスは、ネットワークレイヤークライアントのみを搭載するレイヤー2インターフェイスである場合があります。MPLS-TP LSPは、セクション3.4.3で説明されているように、このサービスインターフェイスをサポートするために必要かつ十分です。あるいは、ネットワーク層と非ネットワーク層の両方のクライアントを搭載するレイヤー2インターフェイスである場合があります。このサービスインターフェイスをサポートするには、サービスインターフェイスを介して受信したクライアントトラフィックを適応させるためにPWが必要です。このPWは、MPLS-TPサーバーレイヤーのクライアントです。これはセクション3.4.2で説明されています。
An NNI service interface may be to an MPLS LSP or a PW. To support this case, an MPLS-TP PE participates in the service interface signaling.
NNIサービスインターフェイスは、MPLS LSPまたはPWにある場合があります。このケースをサポートするために、MPLS-TP PEがサービスインターフェイスシグナリングに参加します。
The native service is the client layer network service that is transported by the MPLS-TP network, whether a pseudowire or an LSP is used for the adaptation (see Section 3.4).
ネイティブサービスは、MPLS-TPネットワークによって輸送されるクライアントレイヤーネットワークサービスです。これは、擬似ワイヤーまたはLSPが適応に使用されています（セクション3.4を参照）。
Detailed definitions and additional terminology may be found in [RFC5654] and [ROSETTA-STONE].
詳細な定義と追加の用語は、[RFC5654]および[Rosetta-Stone]に記載されている場合があります。
The requirements for MPLS-TP are specified in [RFC5654], [RFC5860], and [NM-REQ]. This section provides a brief reminder to guide the reader. It is not normative or intended as a substitute for these documents.
MPLS-TPの要件は、[RFC5654]、[RFC5860]、および[NM-Req]で指定されています。このセクションでは、読者を導くための簡単なリマインダーを提供します。それは規範的ではなく、これらのドキュメントの代替として意図されていません。
MPLS-TP must not modify the MPLS forwarding architecture and must be based on existing pseudowire and LSP constructs.
MPLS-TPは、MPLS転送アーキテクチャを変更してはならず、既存の擬似ワイヤーおよびLSPコンストラクトに基づいている必要があります。
Point-to-point LSPs may be unidirectional or bidirectional, and it must be possible to construct congruent bidirectional LSPs.
ポイントツーポイントLSPは一方向または双方向である可能性があり、一致する双方向LSPを構築することが可能である必要があります。
MPLS-TP LSPs do not merge with other LSPs at an MPLS-TP LSR and it must be possible to detect if a merged LSP has been created.
MPLS-TP LSPは、MPLS-TP LSRで他のLSPと融合せず、マージされたLSPが作成されているかどうかを検出することができなければなりません。
It must be possible to forward packets solely based on switching the MPLS or PW label. It must also be possible to establish and maintain LSPs and/or pseudowires both in the absence or presence of a dynamic control plane. When static provisioning is used, there must be no dependency on dynamic routing or signaling.
MPLSまたはPWラベルの切り替えに基づいて、パケットを転送することが可能である必要があります。また、動的コントロールプレーンの非存在下または存在の両方で、LSPおよび/または擬似動物を確立および維持することも可能でなければなりません。静的プロビジョニングを使用する場合、動的ルーティングやシグナリングに依存してはなりません。
OAM and protection mechanisms, and forwarding of data packets, must be able to operate without IP forwarding support.
OAMおよび保護メカニズム、およびデータパケットの転送は、IP転送サポートなしで動作できる必要があります。
It must be possible to monitor LSPs and pseudowires through the use of OAM in the absence of control-plane or routing functions. In this case, information gained from the OAM functions is used to initiate path recovery actions at either the PW or LSP layers.
コントロールプレーンまたはルーティング機能がない場合、OAMを使用してLSPと擬似ワイヤを監視することは可能でなければなりません。この場合、OAM関数から得られた情報は、PWまたはLSP層のいずれかでパス回復アクションを開始するために使用されます。
One objective of MPLS-TP is to enable MPLS networks to provide packet transport services with a similar degree of predictability to that found in existing transport networks. Such packet transport services exhibit a number of characteristics, defined in [RFC5654]:
MPLS-TPの目的の1つは、MPLSネットワークが既存の輸送ネットワークで見られるものと同様の程度の予測可能性をパケット輸送サービスに提供できるようにすることです。このようなパケット輸送サービスは、[RFC5654]で定義されている多くの特性を示します。
o 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 either the server or client layer network.
o MPLS-TPレイヤーネットワークがクライアントレイヤーネットワークをサポートし、MPLS-TPレイヤーネットワークがサーバーレイヤーネットワークによってサポートされている環境では、MPLS-TPレイヤーネットワークの操作は、どちらのサーバーに依存せずに可能である必要があります。またはクライアントレイヤーネットワーク。
o The service provided by the MPLS-TP network to a given client will not fall below the agreed level as a result of the traffic loading of other clients.
o MPLS-TPネットワークが特定のクライアントに提供するサービスは、他のクライアントのトラフィックロードの結果として、合意されたレベルを下回ることはありません。
o The control and management planes of any client network layer that uses the service is isolated from the control and management planes of the MPLS-TP layer network, where the client network layer is considered to be the native service of the MPLS-TP network.
o サービスを使用するクライアントネットワークレイヤーの制御および管理プレーンは、MPLSネットワークレイヤーがMPLS-TPネットワークのネイティブサービスと見なされるMPLS-TPレイヤーネットワークの制御および管理プレーンから分離されています。
o Where a client network makes use of an MPLS-TP server that provides a packet transport service, the level of coordination required between the client and server layer networks is minimal (preferably no coordination will be required).
o クライアントネットワークがパケットトランスポートサービスを提供するMPLS-TPサーバーを使用している場合、クライアントとサーバーレイヤーネットワークの間で必要な調整のレベルは最小限です（できれば調整は必要ありません）。
o The complete set of packets generated by a client MPLS(-TP) layer network using the packet transport service, which may contain packets that are not MPLS packets (e.g., IP or CLNS (Connectionless Network Service) packets used by the control/ management plane of the client MPLS(-TP) layer network), are transported by the MPLS-TP server layer network.
o クライアントMPLS（-TP）レイヤーネットワークによって生成されたパケットの完全なセットパケットトランスポートサービスを使用して、MPLSパケットではないパケット（コントロール/管理プレーンが使用するパケット（IPまたはCLNS（Connectionless Network Service）パケット）を含む場合があります。クライアントMPLS（-TP）レイヤーネットワーク）は、MPLS-TPサーバーレイヤーネットワークによって輸送されます。
o The packet transport service enables the MPLS-TP layer network addressing and other information (e.g., topology) to be hidden from any client layer networks using that service, and vice-versa.
o パケットトランスポートサービスにより、MPLS-TPレイヤーネットワークのアドレス指定やその他の情報（トポロジなど）が、そのサービスを使用してクライアントレイヤーネットワークから隠され、その逆も可能になります。
These characteristics imply that a packet transport service does not support a connectionless packet-switched forwarding mode. However, this does not preclude it carrying client traffic associated with a connectionless service.
これらの特性は、パケットトランスポートサービスがコネクションレスパケットスイッチの転送モードをサポートしていないことを意味します。ただし、これにより、Connectionless Serviceに関連するクライアントトラフィックを運ぶことはできません。
Figure 1 illustrates the scope of MPLS-TP. MPLS-TP solutions are primarily intended for packet transport applications. MPLS-TP is a strict subset of MPLS, and comprises only those functions that are necessary to meet the requirements of [RFC5654]. This includes MPLS functions that were defined prior to [RFC5654] but that meet the requirements of [RFC5654], together with additional functions defined to meet those requirements. Some MPLS functions defined before [RFC5654] such as Equal Cost Multi-Path (ECMP), LDP signaling when used in such a way that it creates multipoint-to-point LSPs, and IP forwarding in the data plane are explicitly excluded from MPLS-TP by that requirements specification.
図1は、MPLS-TPの範囲を示しています。MPLS-TPソリューションは、主にパケット輸送アプリケーションを対象としています。MPLS-TPはMPLSの厳密なサブセットであり、[RFC5654]の要件を満たすために必要な機能のみを含む。これには、[RFC5654]より前に定義されたが、[RFC5654]の要件を満たしているMPLS関数と、それらの要件を満たすために定義された追加機能が含まれます。[RFC5654]の前に定義された一部のMPLS関数[RFC5654]は、等しいコストマルチパス（ECMP）、Multipoint-to-Point LSPを作成するようにLDPシグナル伝達、およびデータプレーンでのIP転送がMPLSから明示的に除外されます。その要件仕様によるTP。
Note that MPLS as a whole will continue to evolve to include additional functions that do not conform to the MPLS Transport Profile or its requirements, and thus fall outside the scope of MPLS-TP.
MPL全体は、MPLS輸送プロファイルまたはその要件に準拠していない追加の機能を含めるために進化し続けるため、MPLS-TPの範囲外に該当することに注意してください。
|<============================== MPLS ==============================>|
{ Post-RFC5654 }
{ non-Transport }
{ Functions }
|<========== Pre-RFC5654 MPLS ===========>|
{ ECMP }
{ LDP/non-TE LSPs }
{ IP forwarding }
|<======== MPLS-TP ============>|
{ Additional }
{ Transport }
{ Functions }
Figure 1: Scope of MPLS-TP
図1：MPLS-TPの範囲
MPLS-TP can be used to construct packet networks and is therefore applicable in any packet network context. A subset of MPLS-TP is also applicable to ITU-T-defined packet transport networks, where the transport network operational model is deemed attractive.
MPLS-TPは、パケットネットワークを構築するために使用でき、したがって、パケットネットワークコンテキストに適用できます。MPLS-TPのサブセットは、輸送ネットワークの運用モデルが魅力的であると見なされるITU-T定義のパケットトランスポートネットワークにも適用できます。
MPLS-TP comprises the following architectural elements:
MPLS-TPは、次のアーキテクチャ要素で構成されています。
o A standard MPLS data plane [RFC3031] as profiled in [DATA-PLANE].
o [データプレーン]でプロファイルされている標準MPLSデータプレーン[RFC3031]。
o Sections, LSPs, and PWs that provide a packet transport service for a client network.
o クライアントネットワークにパケット輸送サービスを提供するセクション、LSP、およびPWS。
o Proactive and on-demand Operations, Administration, and Maintenance (OAM) functions to monitor and diagnose the MPLS-TP network, as outlined in [OAM-FRAMEWORK].
o [OAMフレームワーク]で概説されているように、MPLS-TPネットワークを監視および診断するために、プロアクティブおよびオンデマンドの操作、管理、およびメンテナンス（OAM）機能。
o Control planes for LSPs and PWs, as well as support for static provisioning and configuration, as outlined in [CP-FRAMEWORK].
o [CPフレームワーク]で概説されているように、LSPとPWSのプレーンを制御するだけでなく、静的プロビジョニングと構成のサポート。
o Path protection mechanisms to ensure that the packet transport service survives anticipated failures and degradations of the MPLS-TP network, as outlined in [SURVIVE-FWK].
o パケット輸送サービスが、[Survive-FWK]で概説されているように、MPLS-TPネットワークの予想される障害と分解を存続させることを保証するパス保護メカニズム。
o Control-plane-based restoration mechanisms, as outlined in [SURVIVE-FWK].
o [Survive-FWK]で概説されているように、コントロールプレーンベースの修復メカニズム。
o Network management functions, as outlined in [NM-FRAMEWORK].
o [NMフレームワーク]で概説されているように、ネットワーク管理機能。
The MPLS-TP architecture for LSPs and PWs includes the following two sets of functions:
LSPとPWSのMPLS-TPアーキテクチャには、次の2つの機能セットが含まれています。
o MPLS-TP native service adaptation
o MPLS-TPネイティブサービスの適応
o MPLS-TP forwarding
o MPLS-TP転送
The adaptation functions interface the native service (i.e., the client layer network service) to MPLS-TP. This includes the case where the native service is an MPLS-TP LSP.
適応関数は、ネイティブサービス（つまり、クライアントレイヤーネットワークサービス）をMPLS-TPにインターフェースします。これには、ネイティブサービスがMPLS-TP LSPである場合が含まれます。
The forwarding functions comprise the mechanisms required for forwarding the encapsulated native service traffic over an MPLS-TP server layer network, for example, PW and LSP labels.
転送機能は、MPLS-TPサーバーレイヤーネットワーク（PWやLSPラベルなど）を介してカプセル化されたネイティブサービストラフィックを転送するために必要なメカニズムを構成します。
The MPLS-TP native service adaptation functions interface the client layer network service to MPLS-TP. For pseudowires, these adaptation functions are the payload encapsulation described in Section 4.4 of [RFC3985] and Section 6 of [RFC5659]. For network layer client services, the adaptation function uses the MPLS encapsulation format as defined in [RFC3032].
MPLS-TPネイティブサービス適応関数は、クライアントレイヤーネットワークサービスをMPLS-TPにインターフェースします。擬似動物の場合、これらの適応関数は、[RFC3985]のセクション4.4および[RFC5659]のセクション6で説明されているペイロードカプセル化です。ネットワークレイヤークライアントサービスの場合、適応関数は[RFC3032]で定義されているMPLSカプセル化形式を使用します。
The purpose of this encapsulation is to abstract the data plane of the client layer network from the MPLS-TP data plane, thus contributing to the independent operation of the MPLS-TP network.
このカプセル化の目的は、MPLS-TPデータプレーンからクライアントレイヤーネットワークのデータプレーンを抽象化し、MPLS-TPネットワークの独立した動作に貢献することです。
MPLS-TP is itself a client of an underlying server layer. MPLS-TP is thus also bounded by a set of adaptation functions to this server layer network, which may itself be MPLS-TP. These adaptation functions provide encapsulation of the MPLS-TP frames and for the transparent transport of those frames over the server layer network. The MPLS-TP client inherits its Quality of Service (QoS) from the MPLS-TP network, which in turn inherits its QoS from the server layer. The server layer therefore needs to provide the necessary QoS to ensure that the MPLS-TP client QoS commitments can be satisfied.
MPLS-TP自体は、基礎となるサーバーレイヤーのクライアントです。したがって、MPLS-TPは、このサーバーレイヤーネットワークへの一連の適応関数によっても制限されています。これ自体がMPLS-TPである可能性があります。これらの適応関数は、MPLS-TPフレームのカプセル化と、サーバーレイヤーネットワーク上のそれらのフレームの透明な輸送を提供します。MPLS-TPクライアントは、MPLS-TPネットワークからサービス品質（QOS）を継承し、サーバーレイヤーからQOを継承します。したがって、サーバーレイヤーは、MPLS-TPクライアントQoSコミットメントが満たされるようにするために必要なQOを提供する必要があります。
The forwarding functions comprise the mechanisms required for forwarding the encapsulated native service traffic over an MPLS-TP server layer network, for example, PW and LSP labels.
転送機能は、MPLS-TPサーバーレイヤーネットワーク（PWやLSPラベルなど）を介してカプセル化されたネイティブサービストラフィックを転送するために必要なメカニズムを構成します。
MPLS-TP LSPs use the MPLS label switching operations and Time-to-Live (TTL) processing procedures defined in [RFC3031], [RFC3032], and [RFC3443], as profiled in [DATA-PLANE]. These operations are highly optimized for performance and are not modified by the MPLS-TP profile.
MPLS-TP LSPは、[データプレーン]でプロファイルされているように、[RFC3031]、[RFC3032]、および[RFC3443]で定義されているMPLSラベルスイッチング操作と寿命までの時間（TTL）処理手順を使用します。これらの操作はパフォーマンスのために高度に最適化されており、MPLS-TPプロファイルによって変更されていません。
In addition, MPLS-TP PWs use the SS-PW and optionally the MS-PW forwarding operations defined in [RFC3985] and [RFC5659].
さらに、MPLS-TP PWSは、[RFC3985]および[RFC5659]で定義されたSS-PW、およびオプションでMS-PW転送操作を使用します。
Per-platform label space is used for PWs. Either per-platform, per-interface, or other context-specific label space [RFC5331] may be used for LSPs.
プラットフォームごとのラベルスペースは、PWSに使用されます。プラットフォームごと、インターフェイスごと、またはその他のコンテキスト固有のラベル空間[RFC5331]を使用することができます。
MPLS-TP forwarding is based on the label that identifies the transport path (LSP or PW). The label value specifies the processing operation to be performed by the next hop at that level of encapsulation. A swap of this label is an atomic operation in which the contents of the packet after the swapped label are opaque to the forwarder. The only event that interrupts a swap operation is TTL expiry. This is a fundamental architectural construct of MPLS to be taken into account when designing protocol extensions (such as those for OAM) that require packets to be sent to an intermediate LSR.
MPLS-TP転送は、輸送パス（LSPまたはPW）を識別するラベルに基づいています。ラベル値は、そのレベルのカプセル化で次のホップによって実行される処理操作を指定します。このラベルの交換は、スワップされたラベルの後のパケットの内容がフォワーダーに不透明である原子操作です。スワップ操作を中断する唯一のイベントは、TTLの有効期限です。これは、パケットを中間LSRに送信する必要があるプロトコル拡張機能（OAMなど）を設計する際に考慮すべきMPLの基本的なアーキテクチャ構造です。
Further processing to determine the context of a packet occurs when a swap operation is interrupted in this manner, or a pop operation exposes a specific reserved label at the top of the stack, or the packet is received with the GAL (Section 3.6) at the top of stack. Otherwise, the packet is forwarded according to the procedures in [RFC3032].
パケットのコンテキストを決定するためのさらなる処理は、この方法でスワップ操作が中断されたときに発生し、ポップ操作がスタックの上部に特定の予約ラベルを公開するか、パケットがGAL（セクション3.6）で受信されます（セクション3.6）スタックの上部。それ以外の場合、パケットは[RFC3032]の手順に従って転送されます。
MPLS-TP supports Quality of Service capabilities via the MPLS Differentiated Services (Diffserv) architecture [RFC3270]. Both E-LSP and L-LSP MPLS Diffserv modes are supported.
MPLS-TPは、MPLS差別化されたサービス（DIFFSERV）アーキテクチャ[RFC3270]を介して、品質のサービス機能をサポートしています。E-LSPおよびL-LSP MPLS DiffServモードの両方がサポートされています。
Further details of MPLS-TP forwarding can be found in [DATA-PLANE].
MPLS-TP転送の詳細については、[Data-Plane]をご覧ください。
This document describes the architecture for two native service adaptation mechanisms, which provide encapsulation and demultiplexing for native service traffic traversing an MPLS-TP network:
このドキュメントでは、MPLS-TPネットワークを横断するネイティブサービストラフィックのカプセル化と非難を提供する2つのネイティブサービス適応メカニズムのアーキテクチャについて説明します。
o A PW
o PW
o An MPLS LSP
o MPLS LSP
MPLS-TP uses IETF-defined pseudowires to emulate certain services, for example, Ethernet, Frame Relay, or PPP / High-Level Data Link Control (HDLC). A list of PW types is maintained by IANA in the "MPLS Pseudowire Type" registry. When the native service adaptation is via a PW, the mechanisms described in Section 3.4.4 are used.
MPLS-TPは、IETF定義の擬似ワイヤを使用して、たとえばイーサネット、フレームリレー、またはPPP /高レベルのデータリンクコントロール（HDLC）など、特定のサービスをエミュレートします。PWタイプのリストは、「MPLS PSEUDOWIRE TYPE」レジストリでIANAによって維持されています。ネイティブサービスの適応がPWを介して行われる場合、セクション3.4.4で説明されているメカニズムが使用されます。
An MPLS LSP can also provide the adaptation, in which case any native service traffic type supported by [RFC3031] and [RFC3032] is allowed. Examples of such traffic types include IP packets and MPLS-labeled packets. Note that the latter case includes TE-LSPs [RFC3209] and LSP-based applications such as PWs, Layer 2 VPNs [RFC4664], and Layer 3 VPNs [RFC4364]. When the native service adaptation is via an MPLS label, the mechanisms described in Section 3.4.5 are used.
MPLS LSPは適応を提供することもできます。その場合、[RFC3031]および[RFC3032]によってサポートされるネイティブサービストラフィックタイプが許可されています。このようなトラフィックタイプの例には、IPパケットとMPLS標識パケットが含まれます。後者のケースには、TE-LSP [RFC3209]およびPWS、レイヤー2 VPNS [RFC4664]、レイヤー3 VPN [RFC4364]などのLSPベースのアプリケーションが含まれていることに注意してください。ネイティブサービスの適応がMPLSラベルを介して行われる場合、セクション3.4.5で説明されているメカニズムが使用されます。
The relationship between the client layer network and the MPLS-TP server layer network is defined by the MPLS-TP network boundary and the label context. It is not explicitly indicated in the packet. In terms of the MPLS label stack, when the native service traffic type is itself MPLS-labeled, then the S bits of all the labels in the MPLS-TP label stack carrying that client traffic are zero; otherwise, the bottom label of the MPLS-TP label stack has the S bit set to 1. In other words, there can be only one S bit set in a label stack.
クライアントレイヤーネットワークとMPLS-TPサーバーレイヤーネットワークとの関係は、MPLS-TPネットワーク境界とラベルコンテキストによって定義されます。パケットに明示的に示されていません。MPLSラベルスタックに関しては、ネイティブサービスのトラフィックタイプがMPLS標識である場合、クライアントトラフィックを運ぶMPLS-TPラベルスタックのすべてのラベルのSビットがゼロです。それ以外の場合、MPLS-TPラベルスタックの下位ラベルには、Sビットが1に設定されています。つまり、ラベルスタックに1ビットセットしか設定できません。
The data-plane behavior of MPLS-TP is the same as the best current practice for MPLS. This includes the setting of the S bit. In each case, the S bit is set to indicate the bottom (i.e., innermost) label in the label stack that is contiguous between the MPLS-TP LSP and its payload, and only one label stack entry (LSE) contains the S bit (Bottom of Stack bit) set to 1. Note that this best current practice differs slightly from [RFC3032], which uses the S bit to identify when MPLS label processing stops and network layer processing starts.
MPLS-TPのデータプレーン動作は、MPLSの最良の現在のプラクティスと同じです。これには、Sビットの設定が含まれます。いずれの場合も、Sビットは、MPLS-TP LSPとそのペイロードの間に隣接するラベルスタックの下部（つまり、最も内側）ラベルを示すように設定されており、1つのラベルスタックエントリ（LSE）のみにSビットが含まれます（スタックビットの下）1に設定します。この最良の現在のプラクティスは[RFC3032]とわずかに異なることに注意してください。これは、Sビットを使用して、MPLSラベル処理の停止とネットワークレイヤー処理が開始される時期を識別します。
The relationship of MPLS-TP to its clients is illustrated in Figure 2. Note that the label stacks shown in the figure are divided between those inside the MPLS-TP network and those within the client network when the client network is MPLS(-TP). They illustrate the smallest number of labels possible. These label stacks could also include more labels.
MPLS-TPのクライアントとの関係を図2に示します。図に示されているラベルスタックは、MPLS-TPネットワーク内のラベルスタックとクライアントネットワークがMPLS（-TP）である場合のクライアントネットワーク内のものとの間で分割されていることに注意してください。。それらは、可能な限り最小のラベルを示しています。これらのラベルスタックには、より多くのラベルを含めることもできます。
PW-Based MPLS Labeled IP
Services Services Transport
|------------| |-----------------------------| |------------|
Emulated PW over LSP IP over LSP IP
Service
+------------+
| PW Payload |
+------------+ +------------+ (CLIENTS)
|PW Lbl(S=1) | | IP |
+------------+ +------------+ +------------+ +------------+
| PW Payload | |LSP Lbl(S=0)| |LSP Lbl(S=1)| | IP |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|PW Lbl (S=1)| |LSP Lbl(S=0)| |LSP Lbl(S=0)| |LSP Lbl(S=1)|
+------------+ +------------+ +------------+ +------------+
|LSP Lbl(S=0)| . . .
+------------+ . . . (MPLS-TP)
. . . .
.
.
~~~~~~~~~~~ denotes Client <-> MPLS-TP layer boundary
Figure 2: MPLS-TP - Client Relationship
図2：MPLS -TP-クライアント関係
An MPLS-TP network consists logically of two layers: the Transport Service layer and the Transport Path layer.
MPLS-TPネットワークは、輸送サービス層と輸送パス層の2つのレイヤーで論理的に構成されています。
The Transport Service layer provides the interface between Customer Edge (CE) nodes and the MPLS-TP network. Each packet transmitted by a CE node for transport over the MPLS-TP network is associated at the receiving MPLS-TP Provider Edge (PE) node with a single logical point-to-point connection at the Transport Service layer between this (ingress) PE and the corresponding (egress) PE to which the peer CE is attached. Such a connection is called an MPLS-TP Transport Service Instance, and the set of client packets belonging to the native service associated with such an instance on a particular CE-PE link is called a client flow.
トランスポートサービスレイヤーは、顧客エッジ（CE）ノードとMPLS-TPネットワーク間のインターフェイスを提供します。MPLS-TPネットワークを介したトランスポート用のCEノードによって送信される各パケットは、この（イングレス）PE間のトランスポートサービスレイヤーで単一の論理ポイントツーポイント接続で、受信MPLS-TPプロバイダーエッジ（PE）ノードに関連付けられています。ピアCEが接続されている対応する（出口）PE。このような接続はMPLS-TP Transport Serviceインスタンスと呼ばれ、特定のCE-PEリンクのこのようなインスタンスに関連付けられているネイティブサービスに属するクライアントパケットのセットは、クライアントフローと呼ばれます。
The Transport Path layer provides aggregation of Transport Service Instances over MPLS-TP transport paths (LSPs), as well as aggregation of transport paths (via LSP hierarchy).
輸送パス層は、MPLS-TPトランスポートパス（LSP）を介した輸送サービスインスタンスの集約と、輸送パスの集約（LSP階層を介して）を提供します。
Awareness of the Transport Service layer need exist only at PE nodes. MPLS-TP Provider (P) nodes need have no awareness of this layer. Both PE and P nodes participate in the Transport Path layer. A PE terminates (i.e., is an LER with respect to) the transport paths it supports, and is responsible for multiplexing and demultiplexing of Transport Service Instance traffic over such transport paths.
輸送サービスレイヤーの認識は、PEノードにのみ存在します。MPLS-TPプロバイダー（P）ノードは、このレイヤーを認識する必要はありません。PEノードとPノードの両方が、輸送パス層に関与します。PEは、それがサポートする輸送経路を終了し（つまり、lerである）、そのような輸送経路を介した輸送サービスインスタンスのトラフィックの多重化と非複数形成を担当します。
An MPLS-TP PE node can provide two types of interface to the Transport Service layer. The MPLS-TP User-Network Interface (UNI) provides the interface between a CE and the MPLS-TP network. The MPLS-TP Network-Network Interface (NNI) provides the interface between two MPLS-TP PEs in different administrative domains.
MPLS-TP PEノードは、トランスポートサービスレイヤーに2種類のインターフェイスを提供できます。MPLS-TPユーザーネットワークインターフェイス（UNI）は、CEとMPLS-TPネットワークの間のインターフェイスを提供します。MPLS-TPネットワークネットワークインターフェイス（NNI）は、異なる管理ドメインの2つのMPLS-TP PE間のインターフェイスを提供します。
When MPLS-TP is used to provide a transport service for, e.g., IP services that are a part of a Layer 3 VPN, then packets are transported in the same manner as specified in [RFC4364].
MPLS-TPを使用して、レイヤー3 VPNの一部であるIPサービスの輸送サービスを提供する場合、[RFC4364]で指定されたものと同じ方法でパケットが輸送されます。
The MPLS-TP User-Network interface (UNI) is illustrated in Figure 3. The UNI for a particular client flow may or may not involve signaling between the CE and PE, and if signaling is used, it may or may not traverse the same attachment circuit that supports the client flow.
MPLS-TPユーザーネットワークインターフェイス（UNI）を図3に示します。特定のクライアントフローのUNIは、CEとPEの間のシグナル伝達を伴う場合としない場合があります。クライアントフローをサポートするアタッチメント回路。
: User-Network Interface : MPLS-TP
:<-------------------------------------->: Network <----->
: :
-:------------- --------------:------------------
: | | : Transport |
: | | Transport : Path |
: | | Service : Mux/Demux |
: | | Control : -- |
: | | Plane : | | Transport|
: ---------- | Signaling | ---------- : | | Path |
:|Signaling |_|___________|_|Signaling | : | | --------->
:|Controller| | | |Controller| : | | |
: ---------- | | ---------- : | | --------->
: :......|...........|......: : | | |
: | Control | : | | Transport|
: | Channel | : | | Path |
: | | : | | --------->
: | | : | | -+----------->TSI
: | | Transport : | | | --------->
: | Client | Service : | | | |
: | Traffic | Data Plane : | | | |
: ---------- | Flows | -------------- | | |Transport|
:|Signaling |-|-----------|-|Client/Service|-| |- Path |
:|Controller|=|===========|=| Traffic | | | --------->
: ---------- | | | Processing |=| |===+===========>TSI
: | | | -------------- | | --------->
: |______|___________|______| : | | |
: | Data Link | : | | |
: | | : -- |
: | | : Transport |
: | | : Service |
: | | : Data Plane|
--------------- ---------------------------------
Customer Edge Node MPLS-TP Provider Edge Node
TSI = Transport Service Instance
Figure 3: MPLS-TP PE Containing a UNI
図3：UNIを含むMPLS-TP PE
--------------From UNI-------> :
-------------------------------------------:------------------
| | Client Traffic Unit : |
| Link-Layer-Specific | Link Decapsulation : Service Instance |
| Processing | & : Transport |
| | Service Instance : Encapsulation |
| | Identification : |
-------------------------------------------:------------------
:
:
-------------------------------------------:------------------
| | : Service Instance |
| | : Transport |
| Link-Layer-Specific | Client Traffic Unit : Decapsulation |
| Processing | Link Encapsulation : & |
| | : Service Instance |
| | : Identification |
-------------------------------------------:------------------
<-------------To UNI --------- :
Figure 4: MPLS-TP UNI Client-Server Traffic Processing Stages
図4：MPLS-TP UNIクライアントサーバートラフィック処理段階
Figure 4 shows the logical processing steps involved in a PE both for traffic flowing from the CE to the MPLS-TP network (left to right), and from the network to the CE (right to left).
図4は、CEからMPLS-TPネットワーク（左から右）、およびネットワークからCE（右から左）までのトラフィックの両方のPEに関与する論理処理手順を示しています。
In the first case, when a packet from a client flow is received by the PE from the CE over the data-link, the following steps occur:
最初のケースでは、データリンクを介してCEからPEによってクライアントフローからのパケットが受信されると、次の手順が発生します。
1. Link-layer-specific pre-processing, if any, is performed. An example of such pre-processing is the PREP function illustrated in Figure 3 of [RFC3985]. Such pre-processing is outside the scope of MPLS-TP.
1. リンク層固有の前処理が実行されます。このような前処理の例は、[RFC3985]の図3に示す準備関数です。このような前処理は、MPLS-TPの範囲外です。
2. The packet is extracted from the data-link frame, if necessary, and associated with a Transport Service Instance. At this point, UNI processing has completed.
2. パケットは、必要に応じてデータリンクフレームから抽出され、輸送サービスインスタンスに関連付けられています。この時点で、UNI処理が完了しました。
3. A transport service encapsulation is associated with the packet, if necessary, for transport over the MPLS-TP network.
3. 輸送サービスのカプセル化は、必要に応じて、MPLS-TPネットワーク上の輸送のためにパケットに関連付けられています。
4. The packet is mapped to a transport path based on its associated Transport Service Instance, the transport path encapsulation is added, if necessary, and the packet is transmitted over the transport path.
4. パケットは、関連する輸送サービスインスタンスに基づいて輸送パスにマッピングされ、必要に応じて輸送パスのカプセル化が追加され、パケットは輸送経路を介して送信されます。
In the second case, when a packet associated with a Transport Service Instance arrives over a transport path, the following steps occur:
2番目のケースでは、輸送サービスインスタンスに関連付けられたパケットが輸送経路に到着すると、次の手順が発生します。
1. The transport path encapsulation is disposed of.
1. 輸送パスのカプセル化は処分されます。
2. The transport service encapsulation is disposed of and the Transport Service Instance and client flow identified.
2. 輸送サービスのカプセル化が廃棄され、輸送サービスインスタンスとクライアントフローが特定されます。
3. At this point, UNI processing begins. A data-link encapsulation is associated with the packet for delivery to the CE based on the client flow.
3. この時点で、UNI処理が開始されます。データリンクカプセル化は、クライアントフローに基づいてCEへの配信のパケットに関連付けられています。
4. Link-layer-specific postprocessing, if any, is performed. Such postprocessing is outside the scope of MPLS-TP.
4. リンク層固有のポストプロセスがある場合は、実行されます。このような後処理は、MPLS-TPの範囲外です。
The MPLS-TP NNI is illustrated in Figure 5. The NNI for a particular Transport Service Instance may or may not involve signaling between the two PEs; and if signaling is used, it may or may not traverse the same data-link that supports the service instance.
MPLS-TP NNIを図5に示します。特定の輸送サービスインスタンスのNNIは、2つのPE間のシグナル伝達を伴う場合としない場合があります。また、シグナリングが使用されている場合、サービスインスタンスをサポートする同じデータリンクを通過する場合とそうでない場合があります。
: Network-Network Interface :
:<--------------------------------->:
: :
------------:------------- -------------:------------
| Transport : | | : Transport |
| Path : Transport | | Transport : Path |
| Mux/Demux : Service | | Service : Mux/Demux |
| -- : Control | | Control : -- |
| | | : Plane |Sig- | Plane : | | |
|TP | | : ---------- | naling| ---------- : | | TP|
<--- | | :|Signaling |_|_______|_|Signaling |: | | --->
TSI<-+- | | :|Controller| | | |Controller|: | | |
<--- | | | : ---------- | | ---------- : | | --->
| | | | : :......|.......|......: : | | |
| | | | : |Control| : | | |
|TP | | | : |Channel| : | | TP|
<--- | | | : | | : | | --->
| | | | : | | : | | -+->TSI
<--- | | | : Transport | | Transport : | | | --->
| | | | : Service |Service| Service : | | | |
| | | | : Data Plane |Traffic| Data Plane : | | | |
| | | | ------------- | Flows | ------------- | | | |
|TP -| |-| Service |-|-------|-| Service |-| |- TP|
<--- | | | Traffic | | | | Traffic | | | --->
TSI<=+===| |=| Processing |=|=======|=| Processing |=| |===+=>TSI
<--- | | ------------- | | ------------- | | --->
| | | : |______|_______|______| : | | |
| | | : | Data | : | | |
| -- : | Link | : -- |
| : | | : |
-------------------------- --------------------------
MPLS-TP Provider Edge Node MPLS-TP Provider Edge Node
TP = Transport Path TSI = Transport Service Instance
TP =トランスポートパスTSI =輸送サービスインスタンス
Figure 5: MPLS-TP PE Containing an NNI
図5：NNIを含むMPLS-TP PE
:
--------------From NNI-------> :
--------------------------------------------:------------------
| | Service Traffic Unit : |
| Link-Layer-Specific | Link Decapsulation : Service Instance |
| Processing | & : Encapsulation |
| | Service Instance : Normalization |
| | Identification : |
--------------------------------------------:------------------
:
:
--------------------------------------------:------------------
| | : Service Instance |
| | : Identification |
| Link-Layer-Specific | Service Traffic Unit : & |
| Processing | Link Encapsulation : Service Instance |
| | : Encapsulation |
| | : Normalization |
--------------------------------------------:------------------
<-------------To NNI --------- :
Figure 6: MPLS-TP NNI Service Traffic Processing Stages
図6：MPLS-TP NNIサービストラフィック処理段階
Figure 6 shows the logical processing steps involved in a PE for traffic flowing both from the peer PE (left to right) and to the peer PE (right to left).
図6は、ピアPE（左から右）とピアPE（右から左）の両方から流れるトラフィックのためのPEに含まれる論理処理手順を示しています。
In the first case, when a packet from a Transport Service Instance is received by the PE from the peer PE over the data-link, the following steps occur:
最初のケースでは、輸送サービスインスタンスからのパケットがPEによってPEがデータリンク上で受信した場合、次の手順が発生します。
1. Link-layer specific pre-processing, if any, is performed. Such pre-processing is outside the scope of MPLS-TP.
1. リンク層固有の前処理（ある場合）が実行されます。このような前処理は、MPLS-TPの範囲外です。
2. The packet is extracted from the data-link frame if necessary, and associated with a Transport Service Instance. At this point, NNI processing has completed.
2. パケットは、必要に応じてデータリンクフレームから抽出され、輸送サービスインスタンスに関連付けられています。この時点で、NNI処理が完了しました。
3. The transport service encapsulation of the packet is normalized for transport over the MPLS-TP network. This step allows a different transport service encapsulation to be used over the NNI than that used in the internal MPLS-TP network. An example of such normalization is a swap of a label identifying the Transport Service Instance.
3. パケットの輸送サービスのカプセル化は、MPLS-TPネットワーク上の輸送用に正規化されます。このステップにより、内部MPLS-TPネットワークで使用されるものとは異なる輸送サービスカプセルをNNIで使用できます。このような正規化の例は、輸送サービスインスタンスを識別するラベルの交換です。
4. The packet is mapped to a transport path based on its associated Transport Service Instance, the transport path encapsulation is added, if necessary, and the packet is transmitted over the transport path.
4. パケットは、関連する輸送サービスインスタンスに基づいて輸送パスにマッピングされ、必要に応じて輸送パスのカプセル化が追加され、パケットは輸送経路を介して送信されます。
In the second case, when a packet associated with a Transport Service Instance arrives over a transport path, the following steps occur:
2番目のケースでは、輸送サービスインスタンスに関連付けられたパケットが輸送経路に到着すると、次の手順が発生します。
1. The transport path encapsulation is disposed of.
1. 輸送パスのカプセル化は処分されます。
2. The Transport Service Instance is identified from the transport service encapsulation, and this encapsulation is normalized for delivery over the NNI (see Step 3 above).
2. 輸送サービスインスタンスは、輸送サービスのカプセル化から識別され、このカプセル化はNNIを介した配信のために正規化されます（上記のステップ3を参照）。
3. At this point, NNI processing begins. A data-link encapsulation is associated with the packet for delivery to the peer PE based on the normalized Transport Service Instance.
3. この時点で、NNI処理が開始されます。データリンクのカプセル化は、正規化された輸送サービスインスタンスに基づいて、ピアPEへの配信のパケットに関連付けられています。
4. Link-layer-specific postprocessing, if any, is performed. Such postprocessing is outside the scope of MPLS-TP.
4. リンク層固有のポストプロセスがある場合は、実行されます。このような後処理は、MPLS-TPの範囲外です。
This section considers some special cases of UNI processing for particular transport service types. These are illustrative, and do not preclude other transport service types.
このセクションでは、特定の輸送サービスタイプのUNI処理の特別なケースを検討します。これらは実例であり、他の輸送サービスの種類を排除しません。
In this example the MPLS-TP network is providing a point-to-point Layer 2 transport service between attached CE nodes. This service is provided by a Transport Service Instance consisting of a PW established between the associated PE nodes. The client flows associated with this Transport Service Instance are the sets of all Layer 2 frames transmitted and received over the attachment circuits.
この例では、MPLS-TPネットワークは、接続されたCEノード間でポイントツーポイントレイヤー2輸送サービスを提供しています。このサービスは、関連するPEノード間で確立されたPWで構成される輸送サービスインスタンスによって提供されます。この輸送サービスインスタンスに関連するクライアントフローは、アタッチメントサーキット上で送信および受信されたすべてのレイヤー2フレームのセットです。
The processing steps in this case for a frame received from the CE are:
CEから受信したフレームのこの場合の処理手順は次のとおりです。
1. Link-layer specific pre-processing, if any, is performed, corresponding to the PREP function illustrated in Figure 3 of [RFC3985].
1. [RFC3985]の図3に示されているPREP関数に対応するリンク層固有の前処理が実行されます。
2. The frame is associated with a Transport Service Instance based on the attachment circuit over which it was received.
2. フレームは、受信したアタッチメント回路に基づいた輸送サービスインスタンスに関連付けられています。
3. A transport service encapsulation, consisting of the PW control word and PW label, is associated with the frame.
3. PWコントロールワードとPWラベルで構成される輸送サービスのカプセル化は、フレームに関連付けられています。
4. The resulting packet is mapped to an LSP, the LSP label is pushed, and the packet is transmitted over the outbound interface associated with the LSP.
4. 結果のパケットはLSPにマッピングされ、LSPラベルがプッシュされ、パケットはLSPに関連付けられたアウトバウンドインターフェイス上に送信されます。
For PW packets received over the LSP, the steps are performed in the reverse order.
LSPで受信したPWパケットの場合、手順は逆の順序で実行されます。
In this example, the MPLS-TP network is providing a point-to-point IP transport service between CE1, CE2, and CE3, as follows. One point-to-point Transport Service Instance delivers IPv4 packets between CE1 and CE2, and another instance delivers IPv6 packets between CE1 and CE3.
この例では、MPLS-TPネットワークは、次のように、CE1、CE2、およびCE3の間のポイントツーポイントIPトランスポートサービスを提供しています。1つのポイントツーポイントトランスポートサービスインスタンスは、CE1とCE2の間にIPv4パケットを配信し、別のインスタンスはCE1とCE3の間にIPv6パケットを提供します。
The processing steps in this case for an IP packet received from CE1 are:
CE1から受信したIPパケットのこの場合の処理手順は次のとおりです。
1. No link-layer-specific processing is performed.
1. リンク層固有の処理は実行されません。
2. The IP packet is extracted from the link-layer frame and associated with a Service LSP based on the source MAC address (CE1) and the IP protocol version.
2. IPパケットは、リンク層フレームから抽出され、ソースMACアドレス（CE1）とIPプロトコルバージョンに基づいてサービスLSPに関連付けられています。
3. A transport service encapsulation, consisting of the Service LSP label, is associated with the packet.
3. サービスLSPラベルで構成される輸送サービスのカプセル化は、パケットに関連付けられています。
4. The resulting packet is mapped to a tunnel LSP, the tunnel LSP label is pushed, and the packet is transmitted over the outbound interface associated with the LSP.
4. 結果のパケットはトンネルLSPにマッピングされ、トンネルLSPラベルがプッシュされ、パケットはLSPに関連付けられたアウトバウンドインターフェイス上に送信されます。
For packets received over a tunnel LSP carrying the Service LSP label, the steps are performed in the reverse order.
サービスLSPラベルを運ぶトンネルLSPを介して受信したパケットの場合、手順は逆の順序で実行されます。
MPLS-TP uses pseudowires to provide a Virtual Private Wire Service (VPWS), a Virtual Private Local Area Network Service (VPLS), a Virtual Private Multicast Service (VPMS), and an Internet Protocol Local Area Network Service (IPLS). VPWS, VLPS, and IPLS are described in [RFC4664]. VPMS is described in [VPMS-REQS].
MPLS-TPは、PSEUDOWIRESを使用して、仮想プライベートワイヤサービス（VPWS）、仮想プライベートローカルエリアネットワークサービス（VPLS）、仮想プライベートマルチキャストサービス（VPMS）、およびインターネットプロトコルローカルエリアネットワークサービス（IPLS）を提供します。VPW、VLP、およびIPLSは[RFC4664]で説明されています。VPMは[VPMS-Reqs]で説明されています。
If the MPLS-TP network provides a layer 2 interface (that can carry both network-layer and non-network-layer traffic) as a service interface, then a PW is required to support the service interface. The PW is a client of the MPLS-TP LSP server layer. The architecture for an MPLS-TP network that provides such services is based on the MPLS [RFC3031] and pseudowire [RFC3985] architectures. Multi-segment pseudowires may optionally be used to provide a packet transport service, and their use is consistent with the MPLS-TP architecture. The use of MS-PWs may be motivated by, for example, the requirements specified in [RFC5254]. If MS-PWs are used, then the MS-PW architecture [RFC5659] also applies.
MPLS-TPネットワークがサービスインターフェイスとしてレイヤー2インターフェイス（ネットワーク層と非ネットワーク層トラフィックの両方を運ぶことができる）を提供する場合、サービスインターフェイスをサポートするにはPWが必要です。PWは、MPLS-TP LSPサーバーレイヤーのクライアントです。このようなサービスを提供するMPLS-TPネットワークのアーキテクチャは、MPLS [RFC3031]およびPseudowire [RFC3985]アーキテクチャに基づいています。マルチセグメントの擬似動物は、オプションでパケット輸送サービスを提供するために使用される場合があり、それらの使用はMPLS-TPアーキテクチャと一致しています。MS-PWSの使用は、たとえば[RFC5254]で指定された要件によって動機付けられる場合があります。MS-PWSを使用すると、MS-PWアーキテクチャ[RFC5659]も適用されます。
Figure 7 shows the architecture for an MPLS-TP network using single-segment PWs. Note that, in this document, the client layer is equivalent to the emulated service described in [RFC3985], while the Transport LSP is equivalent to the Packet Switched Network (PSN) tunnel of [RFC3985].
図7は、単一セグメントPWSを使用したMPLS-TPネットワークのアーキテクチャを示しています。このドキュメントでは、クライアントレイヤーは[RFC3985]に記載されているエミュレートサービスと同等であり、輸送LSPは[RFC3985]のパケットスイッチネットワーク（PSN）トンネルに相当します。
|<----------------- Client Layer ------------------->|
| |
| |<-------- Pseudowire -------->| |
| | encapsulated, packet | |
| | transport service | |
| | | |
| | Transport | |
| | |<------ LSP ------->| | |
| V V V V |
V AC +----+ +-----+ +----+ AC V
+-----+ | | PE1|=======\ /========| PE2| | +-----+
| |----------|.......PW1.| \ / |............|----------| |
| CE1 | | | | | X | | | | | CE2 |
| |----------|.......PW2.| / \ |............|----------| |
+-----+ ^ | | |=======/ \========| | | ^ +-----+
^ | +----+ ^ +-----+ +----+ | ^
| | Provider | ^ Provider | |
| | Edge 1 | | Edge 2 | |
Customer | | P Router | Customer
Edge 1 | TE LSP | Edge 2
| |
| |
Native service Native service
Figure 7: MPLS-TP Architecture (Single Segment PW)
図7：MPLS-TPアーキテクチャ（単一セグメントPW）
Figure 8 shows the architecture for an MPLS-TP network when multi-segment pseudowires are used. Note that as in the SS-PW case, P-routers may also exist.
図8は、マルチセグメントの擬似ワイヤを使用した場合のMPLS-TPネットワークのアーキテクチャを示しています。SS-PWの場合と同様に、Pルーターも存在する可能性があることに注意してください。
|<--------------------- Client Layer ------------------------>|
| |
| Pseudowire encapsulated, |
| |<---------- Packet Transport Service ------------->| |
| | | |
| | Transport Transport | |
| AC | |<-------- LSP1 --------->| |<--LSP2-->| | AC |
| | V V V V V V | |
V | +----+ +-----+ +----+ +----+ | V
+---+ | |TPE1|===============\ /=====|SPE1|==========|TPE2| | +---+
| |----|......PW1-Seg1.... | \ / | ......X...PW1-Seg2......|----| |
|CE1| | | | | X | | | | | | |CE2|
| |----|......PW2-Seg1.... | / \ | ......X...PW2-Seg2......|----| |
+---+ ^ | |===============/ \=====| |==========| | | ^+---+
| +----+ ^ +-----+ +----+ ^ +----+ |
| | ^ | |
| TE LSP | TE LSP |
| P-router |
Native Service Native Service
PW1-segment1 and PW1-segment2 are segments of the same MS-PW, while PW2-segment1 and PW2-segment2 are segments of another MS-PW.
Pw1-segment1およびpw1-segment2は同じMS-PWのセグメントであり、PW2-Segment1とPw2-Segment2は別のMS-PWのセグメントです。
Figure 8: MPLS-TP Architecture (Multi-Segment PW)
図8：MPLS-TPアーキテクチャ（マルチセグメントPW）
The corresponding MPLS-TP protocol stacks including PWs are shown in Figure 9. In this figure, the Transport Service layer [RFC5654] is identified by the PW demultiplexer (Demux) label, and the Transport Path layer [RFC5654] is identified by the LSP Demux Label.
PWSを含む対応するMPLS-TPプロトコルスタックを図9に示します。この図では、輸送サービス層[RFC5654]は、PW Demultiplexer（DEMUX）ラベルによって識別され、輸送パス層[RFC5654]はLSPによって特定されています。Demuxラベル。
+-------------------+ /===================\ /===================\
| Client Layer | H OAM PDU H H OAM PDU H
/===================\ H-------------------H H-------------------H
H PW Encap H H GACh H H GACh H
H-------------------H H-------------------H H-------------------H
H PW Demux (S=1) H H PW Demux (S=1) H H GAL (S=1) H
H-------------------H H-------------------H H-------------------H
H Trans LSP Demux(s)H H Trans LSP Demux(s)H H Trans LSP Demux(s)H
\===================/ \===================/ \===================/
| Server Layer | | Server Layer | | Server Layer |
+-------------------+ +-------------------+ +-------------------+
User Traffic PW OAM LSP OAM
Note: H(ighlighted) indicates the part of the protocol stack considered in this document.
注：H（IGHLIGHTED）は、このドキュメントで検討されているプロトコルスタックの部分を示します。
Figure 9: MPLS-TP Label Stack Using Pseudowires
図9：Pseudowiresを使用したMPLS-TPラベルスタック
PWs and their associated labels may be configured or signaled. See Section 3.11 for additional details related to configured service types. See Section 3.9 for additional details related to signaled service types.
PWSとそれに関連するラベルは、構成または信号を設定できます。構成されたサービスタイプに関連する追加の詳細については、セクション3.11を参照してください。シグナル付きサービスタイプに関連する追加の詳細については、セクション3.9を参照してください。
MPLS-TP LSPs can be used to transport network-layer clients. This document uses the term Network Layer in the same sense as it is used in [RFC3031] and [RFC3032]. The network-layer protocols supported by [RFC3031] and [RFC3032] can be transported between service interfaces. Support for network-layer clients follows the MPLS architecture for support of network-layer protocols as specified in [RFC3031] and [RFC3032].
MPLS-TP LSPは、ネットワーク層クライアントの輸送に使用できます。このドキュメントでは、[RFC3031]および[RFC3032]で使用されているのと同じ意味で、ネットワークレイヤーという用語を使用します。[RFC3031]および[RFC3032]によってサポートされるネットワーク層プロトコルは、サービスインターフェイス間で輸送できます。ネットワーク層クライアントのサポートは、[RFC3031]および[RFC3032]で指定されているネットワーク層プロトコルをサポートするためのMPLSアーキテクチャに従います。
With network-layer adaptation, the MPLS-TP domain provides either a unidirectional or bidirectional point-to-point connection between two PEs in order to deliver a packet transport service to attached customer edge (CE) nodes. For example, a CE may be an IP, MPLS, or MPLS-TP node. As shown in Figure 10, there is an attachment circuit between the CE node on the left and its corresponding provider edge (PE) node (which provides the service interface), a bidirectional LSP across the MPLS-TP network to the corresponding PE node on the right, and an attachment circuit between that PE node and the corresponding CE node for this service.
ネットワーク層の適応により、MPLS-TPドメインは、2つのPE間の単方向または双方向のポイントツーポイント接続を提供し、接続された顧客エッジ（CE）ノードにパケットトランスポートサービスを提供します。たとえば、CEはIP、MPLS、またはMPLS-TPノードである場合があります。図10に示すように、左側のCEノードとその対応するプロバイダーエッジ（PE）ノード（サービスインターフェイスを提供する）の間にアタッチメント回路があります。右、およびそのPEノードとこのサービスの対応するCEノードの間のアタッチメント回路。
The attachment circuits may be heterogeneous (e.g., any combination of SDH, PPP, Frame Relay, etc.) and network-layer protocol payloads arrive at the service interface encapsulated in the Layer 1 / Layer 2 encoding defined for that access link type. It should be noted that the set of network-layer protocols includes MPLS, and hence MPLS-encoded packets with an MPLS label stack (the client MPLS stack) may appear at the service interface.
アタッチメント回路は、そのアクセスリンクタイプに定義されたレイヤー1 /レイヤー2エンコードにカプセル化されたサービスインターフェイスに到達します。ネットワーク層プロトコルのセットにはMPLSが含まれているため、MPLSラベルスタック（クライアントMPLSスタック）を備えたMPLSエンコードパケットがサービスインターフェイスに表示される場合があることに注意してください。
The following figures illustrate the reference models for network-layer adaptation. The details of these figures are described further in the following paragraphs.
次の図は、ネットワーク層適応の参照モデルを示しています。これらの数値の詳細については、次の段落でさらに説明します。
|<------------- Client Network Layer --------------->|
| |
| |<----------- Packet --------->| |
| | Transport Service | |
| | | |
| | | |
| | Transport | |
| | |<------ LSP ------->| | |
| V V V V |
V AC +----+ +-----+ +----+ AC V
+-----+ | | PE1|=======\ /========| PE2| | +-----+
| |----------|..Svc LSP1.| \ / |............|----------| |
| CE1 | | | | | X | | | | | CE2 |
| |----------|..Svc LSP2.| / \ |............|----------| |
+-----+ ^ | | |=======/ \========| | | ^ +-----+
^ | +----+ ^ +-----+ +----+ | | ^
| | Provider | ^ Provider | |
| | Edge 1 | | Edge 2 | |
Customer | | P Router | Customer
Edge 1 | TE LSP | Edge 2
| |
| |
Native service Native service
Figure 10: MPLS-TP Architecture for Network-Layer Clients
図10：ネットワーク層クライアント向けのMPLS-TPアーキテクチャ
|<--------------------- Client Layer ------------------------>|
| |
| |
| |<---------- Packet Transport Service ------------->| |
| | | |
| | Transport Transport | |
| AC | |<-------- LSP1 --------->| |<--LSP2-->| | AC |
| | V V V V V V | |
V | +----+ +-----+ +----+ +----+ | V
+---+ | | PE1|===============\ /=====| PE2|==========| PE3| | +---+
| |----|......svc-lsp1.... | \ / | .....X....svc-lsp1......|----| |
|CE1| | | | | X | | | | | | |CE2|
| |----|......svc-lsp2.... | / \ | .....X....svc-lsp2......|----| |
+---+ ^ | |===============/ \=====| |==========| | | ^+---+
| +----+ ^ +-----+ +----+ ^ +----+ |
| | ^ ^ | |
| TE LSP | | TE LSP |
| P-router | |
Native Service (LSR for | Native Service
T'port LSP1) |
|
LSR for Service LSPs
LER for Transport LSPs
Figure 11: MPLS-TP Architecture for Network Layer Adaptation, Showing Service LSP Switching
図11：ネットワークレイヤー適応のためのMPLS-TPアーキテクチャ、サービスLSPの切り替えを示す
Client packets are received at the ingress service interface. The PE pushes one or more labels onto the client packets that are then label switched over the transport network. Correspondingly, the egress PE pops any labels added by the MPLS-TP networks and transmits the packet for delivery to the attached CE via the egress service interface.
クライアントパケットは、イングレスサービスインターフェイスで受信されます。PEは、1つ以上のラベルをクライアントパケットに押し込み、その後、トランスポートネットワーク上にラベルが切り替えられます。それに対応して、出力PEはMPLS-TPネットワークによって追加されたラベルをポップし、Egressサービスインターフェイスを介して接続されたCEに配信するためにパケットを送信します。
/===================\
H OAM PDU H
+-------------------+ H-------------------H /===================\
| Client Layer | H GACh H H OAM PDU H
/===================\ H-------------------H H-------------------H
H Encap Label H H GAL (S=1) H H GACh H
H-------------------H H-------------------H H-------------------H
H SvcLSP Demux H H SvcLSP Demux (S=0)H H GAL (S=1) H
H-------------------H H-------------------H H-------------------H
H Trans LSP Demux(s)H H Trans LSP Demux(s)H H Trans LSP Demux(s)H
\===================/ \===================/ \===================/
| Server Layer | | Server Layer | | Server Layer |
+-------------------+ +-------------------+ +-------------------+
User Traffic Service LSP OAM LSP OAM
Note: H(ighlighted) indicates the part of the protocol stack considered in this document.
注：H（IGHLIGHTED）は、このドキュメントで検討されているプロトコルスタックの部分を示します。
Figure 12: MPLS-TP Label Stack for IP and LSP Clients
図12：IPおよびLSPクライアントのMPLS-TPラベルスタック
In the figures above, the Transport Service layer [RFC5654] is identified by the Service LSP (SvcLSP) demultiplexer (Demux) label, and the Transport Path layer [RFC5654] is identified by the Transport (Trans) LSP Demux Label. Note that the functions of the Encapsulation Label (Encap Label) and the Service Label (SvcLSP Demux) shown above may alternatively be represented by a single label stack entry. Note that the S bit is always zero when the client layer is MPLS-labeled. It may be necessary to swap a service LSP label at an intermediate node. This is shown in Figure 11.
上記の図では、輸送サービス層[RFC5654]は、サービスLSP（SVCLSP）Demultiplexer（DEMUX）ラベルによって識別され、輸送パス層[RFC5654]はトランスポート（Trans）LSP Demuxラベルによって識別されます。上記に示すカプセル化ラベル（capラベル）とサービスラベル（SVCLSP Demux）の関数は、あるいは単一のラベルスタックエントリで表される場合があることに注意してください。クライアントレイヤーがMPLS標識されている場合、Sビットは常にゼロであることに注意してください。中間ノードでサービスLSPラベルを交換する必要がある場合があります。これを図11に示します。
Within the MPLS-TP transport network, the network-layer protocols are carried over the MPLS-TP network using a logically separate MPLS label stack (the server stack). The server stack is entirely under the control of the nodes within the MPLS-TP transport network and it is not visible outside that network. Figure 12 shows how a client network protocol stack (which may be an MPLS label stack and payload) is carried over a network layer client service over an MPLS-TP transport network.
MPLS-TP Transport Network内では、ネットワーク層プロトコルは、論理的に個別のMPLSラベルスタック（サーバースタック）を使用してMPLS-TPネットワーク上に運ばれます。サーバースタックは、MPLS-TP Transport Network内のノードの制御下にあり、そのネットワークの外には見えません。図12は、クライアントネットワークプロトコルスタック（MPLSラベルスタックとペイロードである可能性がある）が、MPLS-TPトランスポートネットワークを介してネットワークレイヤークライアントサービスにどのように運ばれるかを示しています。
A label may be used to identify the network-layer protocol payload type. Therefore, when multiple protocol payload types are to be carried over a single service LSP, a unique label stack entry needs to be present for each payload type. Such labels are referred to as "Encapsulation Labels", one of which is shown in Figure 12. An Encapsulation Label may be either configured or signaled.
ラベルは、ネットワーク層プロトコルペイロードタイプを識別するために使用できます。したがって、複数のプロトコルペイロードタイプを単一のサービスLSPに掲載する場合、各ペイロードタイプに一意のラベルスタックエントリを存在する必要があります。このようなラベルは「カプセル化ラベル」と呼ばれ、そのうちの1つを図12に示します。カプセル化ラベルは構成または信号を設定できます。
Both an Encapsulation Label and a Service Label should be present in the label stack when a particular packet transport service is supporting more than one network-layer protocol payload type. For example, if both IP and MPLS are to be carried, then two Encapsulation Labels are mapped on to a common Service Label.
特定のパケットトランスポートサービスが複数のネットワーク層プロトコルペイロードタイプをサポートしている場合、カプセル化ラベルとサービスラベルの両方がラベルスタックに存在する必要があります。たとえば、IPとMPLの両方を携帯する場合、2つのカプセル化ラベルが共通のサービスラベルにマッピングされます。
Note: The Encapsulation Label may be omitted when the service LSP is supporting only one network-layer protocol payload type. For example, if only MPLS labeled packets are carried over a service, then the Service Label (stack entry) provides both the payload type indication and service identification. The Encapsulation Label cannot have any of the reserved label values [RFC3032].
注：サービスLSPが1つのネットワーク層プロトコルペイロードタイプのみをサポートしている場合、カプセル化ラベルは省略できます。たとえば、MPLSラベルのパケットのみがサービスに掲載されている場合、サービスラベル（スタックエントリ）は、ペイロードタイプの表示とサービス識別の両方を提供します。カプセル化ラベルには、予約されたラベル値[RFC3032]を持つことはできません。
Service labels are typically carried over an MPLS-TP Transport LSP edge-to-edge (or transport path layer). An MPLS-TP Transport LSP is represented as an LSP Transport Demux label, as shown in Figure 12. Transport LSP is commonly used when more than one service exists between two PEs.
サービスラベルは通常、MPLS-TP Transport LSP Edge-to-Edge（またはトランスポートパスレイヤー）に搭載されます。MPLS-TPトランスポートLSPは、図12に示すように、LSP Transport Demuxラベルとして表されます。トランスポートLSPは、2つのPEの間に複数のサービスが存在する場合に一般的に使用されます。
Note that, if only one service exists between two PEs, the functions of the Transport LSP label and the Service LSP Label may be combined into a single label stack entry. For example, if only one service is carried between two PEs, then a single label could be used to provide both the service indication and the MPLS-TP Transport LSP. Alternatively, if multiple services exist between a pair of PEs, then a per-client Service Label would be mapped on to a common MPLS-TP Transport LSP.
2つのPESの間に1つのサービスのみが存在する場合、Transport LSPラベルとサービスLSPラベルの機能を単一のラベルスタックエントリに結合することができることに注意してください。たとえば、2つのPESの間に1つのサービスのみが運ばれている場合、1つのラベルを使用して、サービス表示とMPLS-TPトランスポートLSPの両方を提供できます。または、PEのペア間に複数のサービスが存在する場合、クライアントごとのサービスラベルが一般的なMPLS-TPトランスポートLSPにマッピングされます。
As noted above, the Layer 2 and Layer 1 protocols used to carry the network-layer protocol over the attachment circuits are not transported across the MPLS-TP network. This enables the use of different Layer 2 and Layer 1 protocols on the two attachment circuits.
上記のように、ネットワーク層プロトコルをアタッチメント回路に携帯するために使用されるレイヤー2とレイヤー1プロトコルは、MPLS-TPネットワークを介して輸送されません。これにより、2つのアタッチメント回路で異なるレイヤー2とレイヤー1プロトコルを使用できます。
At each service interface, Layer 2 addressing needs to be used to ensure the proper delivery of a network-layer packet to the adjacent node. This is typically only an issue for LAN media technologies (e.g., Ethernet) that have Media Access Control (MAC) addresses. In cases where a MAC address is needed, the sending node sets the destination MAC address to an address that ensures delivery to the adjacent node. That is, the CE sets the destination MAC address to an address that ensures delivery to the PE, and the PE sets the destination MAC address to an address that ensures delivery to the CE. The specific address used is technology type specific and is not specified in this document. In some technologies, the MAC address will need to be configured.
各サービスインターフェイスで、レイヤー2アドレス指定を使用して、隣接するノードへのネットワーク層パケットの適切な配信を確保する必要があります。これは通常、メディアアクセス制御（MAC）アドレスを持つLANメディアテクノロジー（例：イーサネット）の問題にすぎません。MACアドレスが必要な場合、送信ノードは、隣接するノードへの配信を保証するアドレスに宛先MACアドレスを設定します。つまり、CEは宛先MACアドレスをPEへの配信を保証するアドレスに設定し、PEは宛先MACアドレスをCEへの配信を保証するアドレスに設定します。使用される特定のアドレスはテクノロジータイプ固有であり、このドキュメントでは指定されていません。一部のテクノロジーでは、MACアドレスを構成する必要があります。
Note that when two CEs, which peer with each other, operate over a network layer transport service and run a routing protocol such as IS-IS or OSPF, some care should be taken to configure the routing protocols to use point-to-point adjacencies. The specifics of such configuration is outside the scope of this document. See [RFC5309] for additional details.
互いにピアを覗く2つのCEがネットワークレイヤートランスポートサービスを操作し、IS-ISやOSPFなどのルーティングプロトコルを実行する場合、ポイントツーポイント隣接を使用するルーティングプロトコルを構成するように注意する必要があることに注意してください。。このような構成の詳細は、このドキュメントの範囲外です。詳細については、[RFC5309]を参照してください。
The CE-to-CE service types and corresponding labels may be configured or signaled.
CEからCE-CEのサービスタイプと対応するラベルは、構成または信号を設定できます。
Identifiers are used to uniquely distinguish entities in an MPLS-TP network. These include operators, nodes, LSPs, pseudowires, and their associated maintenance entities. MPLS-TP defined two types of sets of identifiers: those that are compatible with IP, and those that are compatible with ITU-T transport-based operations. The definition of these sets of identifiers is outside the scope of this document and is provided by [IDENTIFIERS].
識別子は、MPLS-TPネットワーク内のエンティティを一意に区別するために使用されます。これらには、オペレーター、ノード、LSP、擬似動物、および関連するメンテナンスエンティティが含まれます。MPLS-TPは、IPと互換性のある2種類の識別子セットと、ITU-T輸送ベースの操作と互換性のある2種類のセットを定義しました。これらの識別子セットの定義は、このドキュメントの範囲外であり、[識別子]によって提供されます。
For correct operation of OAM mechanisms, it is important that OAM packets fate-share with the data packets. In addition, in MPLS-TP it is necessary to discriminate between user data payloads and other types of payload. For example, a packet may be associated with a Signaling Communication Channel (SCC) or a channel used for a protocol to coordinate path protection state. This is achieved by carrying such packets in either:
OAMメカニズムの正しい動作のために、OAMパケットがデータパケットを使用して運命を剃ることが重要です。さらに、MPLS-TPでは、ユーザーデータのペイロードと他の種類のペイロードを区別する必要があります。たとえば、パケットは、パス保護状態を調整するためにプロトコルに使用されるシグナリング通信チャネル（SCC）またはチャネルに関連付けられている場合があります。これは、そのようなパケットをどちらにも運ぶことによって達成されます。
o A generic control channel associated to the LSP, PW, or section, with no IP encapsulation, e.g., in a similar manner to Bidirectional Forwarding Detection for Virtual Circuit Connectivity Verification (VCCV-BFD) with PW ACH encapsulation [RFC5885]).
o IPカプセル化なしのLSP、PW、またはセクションに関連付けられた一般的な制御チャネル。たとえば、PW ACHカプセル化[RFC5885]）を使用した仮想回路接続検証（VCCV-BFD）の双方向転送検出と同様の方法で。
o An IP encapsulation where IP capabilities are present, e.g., PW ACH encapsulation with IP headers for VCCV-BFD [RFC5885] or IP encapsulation for MPLS BFD [RFC5884].
o IP機能が存在するIPカプセル化、例えば、VCCV-BFD [RFC5885]のIPヘッダーによるPW ACHカプセル化またはMPLS BFD [RFC5884]のIPカプセル化。
MPLS-TP makes use of such a generic associated channel (G-ACh) to support Fault, Configuration, Accounting, Performance, and Security (FCAPS) functions by carrying packets related to OAM, a protocol used to coordinate path protection state, SCC, MCC or other packet types in-band over LSPs, PWs, or sections. The G-ACh is defined in [RFC5586] and is similar to the Pseudowire Associated Channel [RFC4385], which is used to carry OAM packets over pseudowires. The G-ACh is indicated by an Associated Channel Header (ACH), similar to the Pseudowire VCCV control word; this header is present for all sections, LSPs, and PWs that make use of FCAPS functions supported by the G-ACh.
MPLS-TPは、このような一般的な関連チャネル（G-CHACH）を使用して、Path Protetenty State、SCC、SCC、OAMに関連するパケットを運ぶことにより、障害、構成、会計、パフォーマンス、およびセキュリティ（FCAPS）関数をサポートしています。LSP、PWS、またはセクションを介したMCCまたはその他のパケットタイプ内。G-achは[RFC5586]で定義されており、擬似ワイヤーに関連するチャネル[RFC4385]に似ており、プソイドワイヤの上にOAMパケットを運ぶために使用されます。g-achは、擬似ワイヤーVCCVコントロールワードと同様の関連するチャネルヘッダー（ACh）で示されます。このヘッダーは、G-achでサポートされているFCAPS関数を使用するすべてのセクション、LSP、およびPWSに存在します。
As specified in [RFC5586], the G-ACh must only be used for channels that are an adjunct to the data service. Examples of these are OAM, a protocol used to coordinate path protection state, MCC, and SCC, but the use is not restricted to these services. The G-ACh must not be used to carry additional data for use in the forwarding path, i.e., it must not be used as an alternative to a PW control word, or to define a PW type.
[RFC5586]で指定されているように、G-achは、データサービスの補助であるチャネルにのみ使用する必要があります。これらの例は、パス保護状態、MCC、およびSCCを調整するために使用されるプロトコルであるOAMですが、これらのサービスには制限されていません。g-achは、転送パスで使用するための追加データを運ぶために使用してはなりません。つまり、PWコントロールワードの代替として使用したり、PWタイプを定義したりしてはなりません。
At the server layer, bandwidth and QoS commitments apply to the gross traffic on the LSP, PW, or section. Since the G-ACh traffic is indistinguishable from the user data traffic, protocols using the G-ACh need to take into consideration the impact they have on the user data with which they are sharing resources. Conversely, capacity needs to be made available for important G-ACh uses such as protection and OAM. In addition, the security and congestion considerations described in [RFC5586] apply to protocols using the G-ACh.
サーバーレイヤーでは、LSP、PW、またはセクションの総トラフィックに帯域幅とQoSのコミットメントが適用されます。G-achトラフィックはユーザーデータトラフィックと区別できないため、G-achを使用したプロトコルは、リソースを共有しているユーザーデータに与える影響を考慮する必要があります。逆に、保護やOAMなどの重要なG-ach使用のために容量を利用できるようにする必要があります。さらに、[RFC5586]に記載されているセキュリティと輻輳の考慮事項は、G-achを使用してプロトコルに適用されます。
Figure 13 shows the reference model depicting how the control channel is associated with the pseudowire protocol stack. This is based on the reference model for VCCV shown in Figure 2 of [RFC5085].
図13は、コントロールチャネルがPseudowireプロトコルスタックにどのように関連付けられているかを示す参照モデルを示しています。これは、[RFC5085]の図2に示すVCCVの参照モデルに基づいています。
+-------------+ +-------------+
| Payload | < FCAPS > | Payload |
+-------------+ +-------------+
| Demux / | < ACH for PW > | Demux / |
|Discriminator| |Discriminator|
+-------------+ +-------------+
| PW | < PW > | PW |
+-------------+ +-------------+
| PSN | < LSP > | PSN |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
| |
| ____ ___ ____ |
| _/ \___/ \ _/ \__ |
| / \__/ \_ |
| / \ |
+--------| MPLS-TP Network |---+
\ /
\ ___ ___ __ _/
\_/ \____/ \___/ \____/
Figure 13: PWE3 Protocol Stack Reference Model Showing the G-ACh
図13：G-achを示すPWE3プロトコルスタック参照モデル
PW-associated channel messages are encapsulated using the PWE3 encapsulation, so that they are handled and processed in the same manner (or in some cases, an analogous manner) as the PW PDUs for which they provide a control channel.
PW関連チャネルメッセージは、PWE3カプセル化を使用してカプセル化されるため、コントロールチャネルを提供するPW PDUと同じ方法（または場合によっては類似の方法）で処理および処理されます。
Figure 14 shows the reference model depicting how the control channel is associated with the LSP protocol stack.
図14は、制御チャネルがLSPプロトコルスタックにどのように関連付けられているかを示す参照モデルを示しています。
+-------------+ +-------------+
| Payload | < FCAPS > | Payload |
+-------------+ +-------------+
|Discriminator| < ACH on LSP > |Discriminator|
+-------------+ +-------------+
|Demultiplexer| < GAL on LSP > |Demultiplexer|
+-------------+ +-------------+
| PSN | < LSP > | PSN |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
| |
| ____ ___ ____ |
| _/ \___/ \ _/ \__ |
| / \__/ \_ |
| / \ |
+--------| MPLS-TP Network |---+
\ /
\ ___ ___ __ _/
\_/ \____/ \___/ \____/
Figure 14: MPLS Protocol Stack Reference Model Showing the LSP Associated Control Channel
図14：LSP関連制御チャネルを示すMPLSプロトコルスタック参照モデル
The MPLS-TP OAM architecture supports a wide range of OAM functions to check continuity, to verify connectivity, to monitor path performance, and to generate, filter, and manage local and remote defect alarms. These functions are applicable to any layer defined within MPLS-TP, i.e., to MPLS-TP sections, LSPs, and PWs.
MPLS-TP OAMアーキテクチャは、幅広いOAM関数をサポートし、連続性を確認し、接続性を確認し、パスのパフォーマンスを監視し、ローカルおよびリモートの欠陥アラームを生成、フィルタリング、および管理します。これらの関数は、MPLS-TP内で定義された任意の層、つまりMPLS-TPセクション、LSP、およびPWSに適用できます。
The MPLS-TP OAM tool-set is able to operate without relying on a dynamic control plane or IP functionality in the data path. In the case of an MPLS-TP deployment in a network in which IP functionality is available, all existing IP/MPLS OAM functions (e.g., LSP Ping, BFD, and VCCV) may be used. Since MPLS-TP can operate in environments where IP is not used in the forwarding plane, the default mechanism for OAM demultiplexing in MPLS-TP LSPs and PWs is the Generic Associated Channel (Section 3.6). Forwarding based on IP addresses for OAM or user data packets is not required for MPLS-TP.
MPLS-TP OAMツールセットは、データパスの動的制御プレーンまたはIP機能に依存せずに動作することができます。IP機能が利用可能なネットワークでのMPLS-TP展開の場合、すべての既存のIP/MPLS OAM関数（LSP Ping、BFD、VCCVなど）を使用できます。MPLS-TPは、IPが転送面で使用されない環境で動作できるため、MPLS-TP LSPおよびPWSのOAM Demultiplexingのデフォルトメカニズムは、一般的な関連チャネルです（セクション3.6）。OAMまたはユーザーデータパケットのIPアドレスに基づく転送は、MPLS-TPには必要ありません。
[RFC4379] and BFD for MPLS LSPs [RFC5884] have defined alert mechanisms that enable an MPLS LSR to identify and process MPLS OAM packets when the OAM packets are encapsulated in an IP header. These alert mechanisms are based on TTL expiration and/or use an IP destination address in the range 127/8 for IPv4 and that same range embedded as IPv4-mapped IPv6 addresses for IPv6 [RFC4379]. When the OAM packets are encapsulated in an IP header, these mechanisms are the default mechanisms for MPLS networks (in general) for identifying MPLS OAM packets, although the mechanisms defined in [RFC5586] can also be used. MPLS-TP is able to operate in environments where IP forwarding is not supported, and thus the G-ACh/GAL is the default mechanism to demultiplex OAM packets in MPLS-TP in these environments.
[RFC4379]およびMPLS LSPSのBFD [RFC5884]は、MPLS LSRがOAMパケットがIPヘッダーにカプセル化されているときにMPLS OAMパケットを識別および処理できるようにするアラートメカニズムを定義しています。これらのアラートメカニズムは、TTLの有効期限に基づいており、IPv4の範囲127/8のIP宛先アドレスを使用し、IPv6 [RFC4379]のIPv4マップIPv6アドレスと同じ範囲が埋め込まれています。OAMパケットがIPヘッダーにカプセル化されている場合、これらのメカニズムは、[RFC5586]で定義されているメカニズムも使用できますが、MPLS OAMパケットを識別するためのMPLSネットワーク（一般的に）のデフォルトメカニズムです。MPLS-TPは、IP転送がサポートされていない環境で動作することができます。したがって、G-CACH/GALは、これらの環境でMPLS-TPのDemultiplex OAMパケットのデフォルトメカニズムです。
MPLS-TP supports a comprehensive set of OAM capabilities for packet transport applications, with equivalent capabilities to those provided in SONET/SDH.
MPLS-TPは、SONET/SDHで提供されるものと同等の機能を備えたパケット輸送アプリケーションの包括的なOAM機能セットをサポートしています。
MPLS-TP requires [RFC5860] that a set of OAM capabilities is available to perform fault management (e.g., fault detection and localization) and performance monitoring (e.g., packet delay and loss measurement) of the LSP, PW, or section. The framework for OAM in MPLS-TP is specified in [OAM-FRAMEWORK].
MPLS-TPでは、LSP、PW、またはセクションの障害管理（障害検出とローカリゼーションなど）とパフォーマンス監視（パケット遅延と損失測定など）を実行するために、OAM機能のセットを使用できることが必要です。MPLS-TPのOAMのフレームワークは、[OAMフレームワーク]で指定されています。
MPLS-TP OAM packets share the same fate as their corresponding data packets, and are identified through the Generic Associated Channel mechanism [RFC5586]. This uses a combination of an Associated Channel Header (ACH) and a G-ACh Label (GAL) to create a control channel associated to an LSP, section, or PW.
MPLS-TP OAMパケットは、対応するデータパケットと同じ運命を共有し、汎用関連チャネルメカニズム[RFC5586]を通じて識別されます。これは、関連するチャネルヘッダー（ACh）とG-achラベル（GAL）の組み合わせを使用して、LSP、セクション、またはPWに関連付けられたコントロールチャネルを作成します。
OAM and monitoring in MPLS-TP is based on the concept of maintenance entities, as described in [OAM-FRAMEWORK]. A Maintenance Entity (ME) can be viewed as the association of two Maintenance Entity Group End Points (MEPs). A Maintenance Entity Group (MEG) is a collection of one or more MEs that belongs to the same transport path and that are maintained and monitored as a group. The MEPs that form an ME limit the OAM responsibilities of an OAM flow to within the domain of a transport path or segment, in the specific layer network that is being monitored and managed.
MPLS-TPのOAMと監視は、[OAMフレームワーク]で説明されているように、メンテナンスエンティティの概念に基づいています。メンテナンスエンティティ（ME）は、2つのメンテナンスエンティティグループエンドポイント（MEP）の関連付けと見なすことができます。メンテナンスエンティティグループ（MEG）は、同じ輸送パスに属し、グループとして維持および監視される1つ以上のMESのコレクションです。MEを形成するMEPは、監視および管理されている特定のレイヤーネットワークで、輸送パスまたはセグメントのドメイン内のOAMフローのOAM責任を制限します。
A MEG may also include a set of Maintenance Entity Group Intermediate Points (MIPs).
MEGには、メンテナンスエンティティグループ中間点（MIP）のセットも含まれる場合があります。
A G-ACh packet may be directed to an individual MIP along the path of an LSP or MS-PW by setting the appropriate TTL in the label stack entry for the G-ACh packet, as per the traceroute mode of LSP Ping [RFC4379] and the vccv-trace mode of [SEGMENTED-PW]. Note that this works when the location of MIPs along the LSP or PW path is known by the MEP. There may be circumstances where this is not the case, e.g., following restoration using a facility bypass LSP. In these cases, tools to trace the path of the LSP may be used to determine the appropriate setting for the TTL to reach a specific MIP.
G-CHACHパケットは、LSP Ping [RFC4379]のTracerouteモードに従って、G-achパケットのラベルスタックエントリに適切なTTLを設定することにより、LSPまたはMS-PWのパスに沿った個々のMIPに向けられます。[セグメント化されたPW]のVCCV-TRACEモード。これは、LSPまたはPWパスに沿ったMIPの位置がMEPで知られている場合に機能することに注意してください。施設バイパスLSPを使用した回復後の後に、これが当てはまらない状況があるかもしれません。これらの場合、LSPの経路を追跡するツールを使用して、TTLが特定のMIPに到達するための適切な設定を決定することができます。
Within an LSR or PE, MEPs and MIPs can only be placed where MPLS layer processing is performed on a packet. The MPLS architecture mandates that MPLS layer processing occurs at least once on an LSR.
LSRまたはPE内では、MPLSレイヤー処理がパケットで実行される場合にのみ配置できます。MPLSアーキテクチャは、MPLSレイヤー処理がLSRで少なくとも1回発生することを義務付けています。
Any node on an LSP can send an OAM packet on that LSP. Likewise, any node on a PW can send OAM packets on a PW, including S-PEs.
LSPのノードは、そのLSPにOAMパケットを送信できます。同様に、PWのノードはすべて、S-PEを含むPWにOAMパケットを送信できます。
An OAM packet can only be received to be processed at an LSP endpoint, a PW endpoint (T-PE), or on the expiry of the TTL in the LSP or PW label stack entry.
OAMパケットは、LSPエンドポイント、PWエンドポイント（T-PE）、またはLSPまたはPWラベルスタックエントリのTTLの有効期限でのみ処理されるように受信できます。
Management, control, and OAM protocol functions may require response packets to be delivered from the receiver back to the originator of a message exchange. This section provides a summary of the return path options in MPLS-TP networks. Although this section describes the case of an MPLS-TP LSP, it is also applicable to a PW.
管理、コントロール、およびOAMプロトコル関数では、レシーバーからメッセージ交換のオリジネーターに返信パケットを配信する必要があります。このセクションでは、MPLS-TPネットワークのリターンパスオプションの概要を示します。このセクションでは、MPLS-TP LSPの場合について説明しますが、PWにも適用できます。
In this description, U and D are LSRs that terminate MPLS-TP LSPs (i.e., LERs), and Y is an intermediate LSR along the LSP. Note that U is the upstream LER, and D is the downstream LER with respect to a particular direction of an LSP. This reference model is shown in Figure 15.
この説明では、UとDはMPLS-TP LSP（つまりLERS）を終了するLSRであり、YはLSPに沿った中間LSRです。Uは上流のlerであり、DはLSPの特定の方向に関して下流のlerであることに注意してください。この参照モデルを図15に示します。
LSP LSP
LSP LSP
U ========= Y ========= D
LER LSR LER
ler lsr ler
---------> Direction of user traffic flow
Figure 15: Return Path Reference Model
図15：パス参照モデルを返します
The following cases are described for the various types of LSPs:
さまざまなタイプのLSPについて、次のケースについて説明します。
Case 1 Return path packet transmission from D to U
ケース1 DからUへのパスパケット送信を返す
Case 2 Return path packet transmission from Y to U
ケース2 Yからuへのパスパケット送信を返す
Case 3 Return path packet transmission from D to Y
ケース3 DからYへのパスパケット送信を返す
Note that a return path may not always exist (or may exist but be disabled), and that packet transmission in one or more of the above cases may not be possible. In general, the existence and nature of return paths for MPLS-TP LSPs is determined by operational provisioning.
リターンパスが常に存在するとは限らない（または存在するかもしれないが無効になる可能性がある）、および上記の1つまたは複数のケースでのパケット送信は不可能であることに注意してください。一般に、MPLS-TP LSPのリターンパスの存在と性質は、運用プロビジョニングによって決定されます。
There are two types of return path that may be used for the delivery of traffic from a downstream node D to an upstream node U. Either:
ダウンストリームノードDから上流ノードUへのトラフィックの配信に使用できるリターンパスには2つのタイプがあります。どちらも次のとおりです。
a. The LSP between U and D is bidirectional, and therefore D has a path via the MPLS-TP LSP to return traffic back to U, or
a. UとDの間のLSPは双方向であるため、DにはMPLS-TP LSPを介してトラフィックをuに戻すパスがあります。
b. D has some other unspecified means of directing traffic back to U.
b. Dには、トラフィックをUに戻すための他の不特定の手段があります。
The first option is referred to as an "in-band" return path, the second as an "out-of-band" return path.
最初のオプションは、「インバンド」リターンパスと呼ばれ、2番目は「バンド外」リターンパスと呼ばれます。
There are various possibilities for "out-of-band" return paths. Such a path may, for example, be based on ordinary IP routing. In this case, packets would be forwarded as usual to a destination IP address associated with U. In an MPLS-TP network that is also an IP/MPLS network, such a forwarding path may traverse the same physical links or logical transport paths used by MPLS-TP. An out-of-band return path may also be indirect, via a distinct Data Communication Network (DCN) (provided, for example, by the method specified in [RFC5718]); or it may be via one or more other MPLS-TP LSPs.
「バンド外」のリターンパスにはさまざまな可能性があります。このようなパスは、たとえば、通常のIPルーティングに基づいている場合があります。この場合、パケットは通常どおりUに関連付けられた宛先IPアドレスに転送されます。IP/MPLSネットワークでもあるMPLS-TPネットワークで、そのような転送パスは同じ物理リンクまたは使用される論理輸送パスを通過する可能性があります。MPLS-TP。異なるデータ通信ネットワーク（DCN）を介して、バンド外のリターンパスも間接的である場合があります（たとえば、[RFC5718]で指定された方法によって提供）。または、他の1つ以上のMPLS-TP LSPを介して行われる場合があります。
Case 1 If an in-band return path is required to deliver traffic from D back to U, it is recommended for reasons of operational simplicity that point-to-point unidirectional LSPs be provisioned as associated bidirectional LSPs (which may also be co-routed) whenever return traffic from D to U is required. Note that the two directions of such an LSP may have differing bandwidth allocations and QoS characteristics. The discussion below for such LSPs applies.
ケース1 DからUにトラフィックを配信するために帯域内のリターンパスが必要な場合、ポイントツーポイント単方向LSPを関連する双方向LSPとしてプロビジョニングするという理由で推奨されます（同時に共通することもあります）DからUへのトラフィックを返すときはいつでも必要です。このようなLSPの2つの方向には、帯域幅の割り当てとQoS特性が異なる場合があることに注意してください。このようなLSPについては、以下の議論が適用されます。
As an alternative, an out-of-band return path may be used.
別の方法として、バンド外のリターンパスを使用することができます。
Case 2 In this case, only the out-of-band return path option is available. However, an additional out-of-band possibility is worthy of note here: if D is known to have a return path to U, then Y can arrange to deliver return traffic to U by first sending it to D along the original LSP. The mechanism by which D recognizes the need for and performs this forwarding operation is protocol specific.
ケース2この場合、バンド外の戻りパスオプションのみが利用可能です。ただし、ここでは追加の帯域外の可能性は注意に値します。Dがuへの戻りパスがあることが知られている場合、yは最初に元のLSPに沿ってDに送信することにより、uにリターントラフィックを配信するよう手配できます。Dがこの転送操作の必要性を認識し、実行するメカニズムはプロトコル固有です。
Case 3 In this case, only the out-of-band return path option is available. However, if D has a return path to U, then (in a manner analogous to the previous case) D can arrange to deliver return traffic to Y by first sending it to U along that return path. The mechanism by which U recognizes the need for and performs this forwarding operation is protocol specific.
ケース3この場合、バンド外の戻りパスオプションのみが利用可能です。ただし、Dにuへの戻りパスがある場合、（前のケースに類似した方法で）Dは、最初にその戻りパスに沿ってuに送信することにより、yにリターントラフィックを配信するように手配できます。Uがこの転送操作の必要性を認識し、実行するメカニズムはプロトコル固有です。
For Case 1, D has a natural in-band return path to U, the use of which is typically preferred for return traffic, although out-of-band return paths are also applicable.
ケース1の場合、Dにはuへの自然なインバンドインターンパスがあり、その使用は通常、リターントラフィックよりも好まれますが、バンド外の戻りパスも適用されます。
For Cases 2 and 3, the considerations are the same as those for point-to-point unidirectional LSPs.
ケース2および3の場合、考慮事項は、ポイントツーポイント単方向LSPの考慮事項と同じです。
For all of Cases 1, 2, and 3, a natural in-band return path exists in the form of the LSP itself, and its use is preferred for return traffic. Out-of-band return paths, however, are also applicable, primarily as an alternative means of delivery in case the in-band return path has failed.
すべてのケース1、2、および3では、LSP自体の形で自然な帯域内戻りパスが存在し、その使用はリターントラフィックに好まれます。ただし、バンド内のリターンパスが失敗した場合の代替配信手段として、バンド外のリターンパスも適用可能です。
A distributed dynamic control plane may be used to enable dynamic service provisioning in an MPLS-TP network. Where the requirements specified in [RFC5654] can be met, the MPLS Transport Profile uses existing standard control-plane protocols for LSPs and PWs.
MPLS-TPネットワークでの動的サービスプロビジョニングを有効にするために、分散型の動的制御プレーンを使用できます。[RFC5654]で指定された要件を満たすことができる場合、MPLSトランスポートプロファイルは、LSPおよびPWSに既存の標準コントロールプレーンプロトコルを使用します。
Note that a dynamic control plane is not required in an MPLS-TP network. See Section 3.11 for further details on statically configured and provisioned MPLS-TP services.
MPLS-TPネットワークでは、動的制御プレーンは必要ないことに注意してください。静的に構成され、プロビジョニングされたMPLS-TPサービスの詳細については、セクション3.11を参照してください。
Figure 16 illustrates the relationship between the MPLS-TP control plane, the forwarding plane, the management plane, and OAM for point-to-point MPLS-TP LSPs or PWs.
図16は、MPLS-TPコントロールプレーン、転送面、管理プレーン、およびポイントツーポイントMPLS-TP LSPまたはPWSのOAMの関係を示しています。
+------------------------------------------------------------------+
| |
| Network Management System and/or |
| |
| Control Plane for Point-to-Point Connections |
| |
+------------------------------------------------------------------+
| | | | | |
.............|.....|... ....|.....|.... ....|.....|............
: +---+ | : : +---+ | : : +---+ | :
: |OAM| | : : |OAM| | : : |OAM| | :
: +---+ | : : +---+ | : : +---+ | :
: | | : : | | : : | | :
\: +----+ +--------+ : : +--------+ : : +--------+ +----+ :/
--+-|Edge|<->|Forward-|<---->|Forward-|<----->|Forward-|<->|Edge|-+--
/: +----+ |ing | : : |ing | : : |ing | +----+ :\
: +--------+ : : +--------+ : : +--------+ :
''''''''''''''''''''''' ''''''''''''''' '''''''''''''''''''''''
Note: 1) NMS may be centralized or distributed. Control plane is distributed. 2) 'Edge' functions refers to those functions present at the edge of a PSN domain, e.g., native service processing or classification. 3) The control plane may be transported over the server layer, an LSP, or a G-ACh.
注：1）NMSは集中または配布される場合があります。コントロールプレーンが分散されています。2）「エッジ」関数とは、PSNドメインのエッジに存在する機能、たとえばネイティブサービスの処理または分類を指します。3）コントロールプレーンは、サーバーレイヤー、LSP、またはG-achに輸送できます。
Figure 16: MPLS-TP Control Plane Architecture Context
図16：MPLS-TPコントロールプレーンアーキテクチャのコンテキスト
The MPLS-TP control plane is based on existing MPLS and PW control plane protocols, and is consistent with the Automatically Switched Optical Network (ASON) architecture [G.8080]. MPLS-TP uses:
MPLS-TPコントロールプレーンは、既存のMPLSおよびPW制御プレーンプロトコルに基づいており、自動化された光ネットワーク（ASON）アーキテクチャ[G.8080]と一致しています。MPLS-TPの使用：
o Generalized MPLS (GMPLS) signaling ([RFC3945], [RFC3471], [RFC3473]) for LSPs, and
o 一般化されたMPLS（GMPLS）シグナル伝達（[RFC3945]、[RFC3471]、[RFC3473]）、およびLSPの場合、および
o Targeted LDP (T-LDP) signaling ([RFC4447], [SEGMENTED-PW], [DYN-MS-PW]) for pseudowires.
o 標的LDP（T-LDP）シグナル伝達（[RFC4447]、[セグメント化されたPW]、[DYN-MS-PW]）。
MPLS-TP requires that any control-plane traffic be capable of being carried over an out-of-band signaling network or a signaling control channel such as the one described in [RFC5718]. Note that while T-LDP signaling is traditionally carried in-band in IP/MPLS networks, this does not preclude its operation over out-of-band channels. References to T-LDP in this document do not preclude the definition of alternative PW control protocols for use in MPLS-TP.
MPLS-TPでは、[RFC5718]に記載されているような帯域外シグナリングネットワークまたはシグナリング制御チャネルを制御面のトラフィックを運ぶことができる必要があります。T-LDPシグナル伝達は伝統的にIP/MPLSネットワークで帯域内に搭載されていますが、これは帯域外チャネル上の動作を排除しないことに注意してください。このドキュメントのT-LDPへの参照は、MPLS-TPで使用するための代替PW制御プロトコルの定義を排除しません。
PW control (and maintenance) takes place separately from LSP tunnel signaling. The main coordination between LSP and PW control will occur within the nodes that terminate PWs. The control planes for PWs and LSPs may be used independently, and one may be employed without the other. This translates into the four possible scenarios: (1) no control plane is employed; (2) a control plane is used for both LSPs and PWs; (3) a control plane is used for LSPs, but not PWs; (4) a control plane is used for PWs, but not LSPs. The PW and LSP control planes, collectively, need to satisfy the MPLS-TP control plane requirements reviewed in the MPLS-TP Control Plane Framework [CP-FRAMEWORK]. When client services are provided directly via LSPs, all requirements must be satisfied by the LSP control plane. When client services are provided via PWs, the PW and LSP control planes operate in combination, and some functions may be satisfied via the PW control plane, while others are provided to PWs by the LSP control plane.
PWコントロール（およびメンテナンス）は、LSPトンネルシグナル伝達とは別に行われます。LSPコントロールとPW制御の主な調整は、PWSを終了するノード内で発生します。PWSおよびLSPのコントロールプレーンは独立して使用でき、一方はもう一方なしで使用される場合があります。これは、4つの可能なシナリオに変換されます。（1）制御面は採用されていません。（2）制御面は、LSPとPWの両方に使用されます。（3）制御面はLSPに使用されますが、PWSでは使用されません。（4）コントロールプレーンはPWSに使用されますが、LSPでは使用されません。PWおよびLSPコントロールプレーンは、まとめて、MPLS-TPコントロールプレーンフレームワーク[CPフレームワーク]でレビューされたMPLS-TP制御プレーン要件を満たす必要があります。クライアントサービスがLSPを介して直接提供される場合、すべての要件がLSPコントロールプレーンによって満たされる必要があります。クライアントサービスがPWSを介して提供されると、PWとLSPコントロールプレーンは組み合わせて動作し、PWコントロールプレーンを介して一部の機能が満たされる場合があり、その他はLSPコントロールプレーンによってPWSに提供されます。
Note that if MPLS-TP is being used in a multi-layer network, a number of control protocol types and instances may be used. This is consistent with the MPLS architecture, which permits each label in the label stack to be allocated and signaled by its own control protocol.
MPLS-TPがマルチレイヤーネットワークで使用されている場合、多くの制御プロトコルタイプとインスタンスを使用できることに注意してください。これは、ラベルスタック内の各ラベルを独自の制御プロトコルによって割り当てて信号することを許可するMPLSアーキテクチャと一致しています。
The distributed MPLS-TP control plane may provide the following functions:
分散型MPLS-TPコントロールプレーンは、次の機能を提供できます。
o Signaling
o シグナリング
o Routing
o ルーティング
o Traffic engineering and constraint-based path computation
o トラフィックエンジニアリングと制約ベースのパス計算
In a multi-domain environment, the MPLS-TP control plane supports different types of interfaces at domain boundaries or within the domains. These include the User-Network Interface (UNI), Internal Network-Network Interface (I-NNI), and External Network-Network Interface (E-NNI). Note that different policies may be defined that control the information exchanged across these interface types.
マルチドメイン環境では、MPLS-TPコントロールプレーンは、ドメイン境界またはドメイン内のさまざまなタイプのインターフェイスをサポートします。これらには、ユーザーネットワークインターフェイス（UNI）、内部ネットワークネットワークインターフェイス（I-NNI）、および外部ネットワークネットワークインターフェイス（E-NNI）が含まれます。これらのインターフェイスタイプで交換される情報を制御するさまざまなポリシーを定義できることに注意してください。
The MPLS-TP control plane is capable of activating MPLS-TP OAM functions as described in the OAM section of this document Section 3.7, e.g., for fault detection and localization in the event of a failure in order to efficiently restore failed transport paths.
MPLS-TPコントロールプレーンは、このドキュメントセクション3.7のOAMセクションで説明されているように、MPLS-TP OAM関数をアクティブにすることができます。
The MPLS-TP control plane supports all MPLS-TP data-plane connectivity patterns that are needed for establishing transport paths, including protected paths as described in Section 3.12.
MPLS-TPコントロールプレーンは、セクション3.12で説明されているように、保護されたパスを含む輸送パスを確立するために必要なすべてのMPLS-TPデータプレーン接続パターンをサポートします。
Examples of the MPLS-TP data-plane connectivity patterns are LSPs utilizing the fast reroute backup methods as defined in [RFC4090] and ingress-to-egress 1+1 or 1:1 protected LSPs.
MPLS-TPデータプレーン接続パターンの例は、[RFC4090]で定義されている高速リルートバックアップメソッドとイングレスからエグレス1 1または1：1の保護されたLSPを使用したLSPです。
The MPLS-TP control plane provides functions to ensure its own survivability and to enable it to recover gracefully from failures and degradations. These include graceful restart and hot redundant configurations. Depending on how the control plane is transported, varying degrees of decoupling between the control plane and data plane may be achieved. In all cases, however, the control plane is logically decoupled from the data plane such that a control-plane failure does not imply a failure of the existing transport paths.
MPLS-TPコントロールプレーンは、独自の生存性を確保し、障害や分解から優雅に回復できるように機能を提供します。これらには、優雅な再起動とホット冗長構成が含まれます。コントロールプレーンの輸送方法に応じて、制御プレーンとデータプレーンの間でさまざまな程度のデカップリングを達成できます。ただし、すべての場合において、制御面はデータプレーンから論理的に分離されているため、コントロールプレーンの故障は既存の輸送パスの障害を意味しません。
A number of methods exist to support inter-domain operation of MPLS-TP, including the data-plane, OAM, and configuration aspects, for example:
データプレーン、OAM、構成の側面など、MPLS-TPのドメイン間操作をサポートするための多くの方法が存在します。
o Inter-domain TE LSPs [RFC4726]
o ドメイン間Te LSP [RFC4726]
o Multi-segment Pseudowires [RFC5659]
o マルチセグメントの擬似動物[RFC5659]
o LSP stitching [RFC5150]
o LSPステッチ[RFC5150]
o Back-to-back attachment circuits [RFC5659]
o 背中合わせのアタッチメントサーキット[RFC5659]
An important consideration in selecting an inter-domain connectivity mechanism is the degree of layer network isolation and types of OAM required by the operator. The selection of which technique to use in a particular deployment scenario is outside the scope of this document.
ドメイン間接続メカニズムを選択する際の重要な考慮事項は、レイヤーネットワークの分離の程度とオペレーターが必要とするOAMの種類です。特定の展開シナリオで使用する手法の選択は、このドキュメントの範囲外です。
A PW or LSP may be statically configured without the support of a dynamic control plane. This may be either by direct configuration of the PEs/LSRs or via a network management system. Static operation is independent for a specific PW or LSP instance. Thus, it should be possible for a PW to be statically configured, while the LSP supporting it is set up by a dynamic control plane. When static configuration mechanisms are used, care must be taken to ensure that loops are not created. Note that the path of an LSP or PW may be dynamically computed, while the LSP or PW itself is established through static configuration.
PWまたはLSPは、動的コントロールプレーンのサポートなしで静的に構成できます。これは、PES/LSRの直接構成またはネットワーク管理システムを介してである場合があります。静的動作は、特定のPWまたはLSPインスタンスで独立しています。したがって、PWを静的に構成し、それをサポートするLSPは動的コントロールプレーンによって設定されます。静的構成メカニズムを使用する場合、ループが作成されないように注意する必要があります。LSPまたはPWの経路は動的に計算され、LSPまたはPW自体は静的構成によって確立されることに注意してください。
The survivability architecture for MPLS-TP is specified in [SURVIVE-FWK].
MPLS-TPの生存性アーキテクチャは、[Survive-FWK]で指定されています。
A wide variety of resiliency schemes have been developed to meet the various network and service survivability objectives. For example, as part of the MPLS/PW paradigms, MPLS provides methods for local repair using back-up LSP tunnels ([RFC4090]), while pseudowire redundancy [PW-REDUNDANCY] supports scenarios where the protection for the PW cannot be fully provided by the underlying LSP (i.e., where the backup PW terminates on a different target PE node than the working PW in dual-homing scenarios, or where protection of the S-PE is required). Additionally, GMPLS provides a well-known set of control-plane-driven protection and restoration mechanisms [RFC4872]. MPLS-TP provides additional protection mechanisms that are optimized for both linear topologies and ring topologies and that operate in the absence of a dynamic control plane. These are specified in [SURVIVE-FWK].
さまざまなネットワークおよびサービスの生存性目標を満たすために、さまざまな回復力スキームが開発されています。たとえば、MPLS/PWパラダイムの一部として、MPLSはバックアップLSPトンネル（[RFC4090]）を使用したローカル修理の方法を提供しますが、擬似冗長性[PW-Redundancy]はPWの保護を完全に提供できないシナリオをサポートします。基礎となるLSP（つまり、バックアップPWは、デュアルホーミングシナリオで動作するPWとは異なるターゲットPEノードで終了します。または、S-PEの保護が必要な場合）。さらに、GMPLSは、コントロールプレーン駆動型の保護および回復メカニズムのよく知られたセットを提供します[RFC4872]。MPLS-TPは、線形トポロジーと環トポロジーの両方に最適化され、動的制御プレーンがない場合に動作する追加の保護メカニズムを提供します。これらは[Survive-FWK]で指定されています。
Different protection schemes apply to different deployment topologies and operational considerations. Such protection schemes may provide different levels of resiliency, for example:
さまざまな保護スキームが、さまざまな展開トポロジと運用上の考慮事項に適用されます。このような保護スキームは、さまざまなレベルの回復力を提供する場合があります。
o two concurrent traffic paths (1+1).
o 2つの同時トラフィックパス（1 1）。
o one active and one standby path with guaranteed bandwidth on both paths (1:1).
o 両方のパス（1：1）に保証された帯域幅を備えた1つのアクティブパスと1つのスタンバイパス。
o one active path and a standby path the resources of which are shared by one or more other active paths (shared protection).
o 1つのアクティブパスと、そのリソースが1つ以上の他のアクティブパス（共有保護）によって共有されます。
The applicability of any given scheme to meet specific requirements is outside the scope of this document.
特定の要件を満たすための特定のスキームの適用性は、このドキュメントの範囲外です。
The characteristics of MPLS-TP resiliency mechanisms are as follows:
MPLS-TP回復力メカニズムの特性は次のとおりです。
o Optimized for linear, ring, or meshed topologies.
o 線形、リング、またはメッシュ化されたトポロジに最適化されています。
o Use OAM mechanisms to detect and localize network faults or service degenerations.
o OAMメカニズムを使用して、ネットワーク障害またはサービスの退行を検出およびローカライズします。
o Include protection mechanisms to coordinate and trigger protection switching actions in the absence of a dynamic control plane.
o 動的制御プレーンがない場合に保護スイッチングアクションを調整およびトリガーする保護メカニズムを含めます。
o MPLS-TP recovery schemes are applicable to all levels in the MPLS-TP domain (i.e., section, LSP, and PW) providing segment and end-to-end recovery.
o MPLS-TP回復スキームは、セグメントとエンドツーエンドの回復を提供するMPLS-TPドメイン（つまり、セクション、LSP、およびPW）のすべてのレベルに適用できます。
o MPLS-TP recovery mechanisms support the coordination of protection switching at multiple levels to prevent race conditions occurring between a client and its server layer.
o MPLS-TP回復メカニズムは、クライアントとそのサーバーレイヤーの間で発生するレース条件を防ぐために、複数のレベルでの保護スイッチングの調整をサポートします。
o MPLS-TP recovery mechanisms can be data-plane, control-plane, or management-plane based.
o MPLS-TP回復メカニズムは、データプレーン、コントロールプレーン、または管理面ベースにすることができます。
o MPLS-TP supports revertive and non-revertive behavior.
o MPLS-TPは、復帰および非反転の動作をサポートします。
In order to monitor, protect, and manage a portion (i.e., segment or concatenated segment) of an LSP, a hierarchical LSP [RFC3031] can be instantiated. A hierarchical LSP instantiated for this purpose is called a Sub-Path Maintenance Element (SPME). Note that by definition an SPME does not carry user traffic as a direct client.
LSPの一部（つまり、セグメントまたは連結セグメント）を監視、保護、および管理するために、階層LSP [RFC3031]をインスタンス化できます。この目的のためにインスタンス化された階層LSPは、サブパスメンテナンス要素（SPME）と呼ばれます。定義上、SPMEは直接クライアントとしてユーザートラフィックを運ばないことに注意してください。
An SPME is defined between the edges of the portion of the LSP that needs to be monitored, protected or managed. The SPME forms an MPLS-TP Section [DATA-PLANE] that carries the original LSP over this portion of the network as a client. OAM messages can be initiated at the edge of the SPME and sent to the peer edge of the SPME or to a MIP along the SPME by setting the TTL value of the LSE at the corresponding hierarchical LSP level. A P router only pushes or pops a label if it is at the end of a SPME. In this mode, it is an LER for the SPME.
SPMEは、監視、保護、または管理する必要があるLSPの部分のエッジの間に定義されます。SPMEは、クライアントとしてネットワークのこの部分に元のLSPを運ぶMPLS-TPセクション[データプレーン]を形成します。OAMメッセージは、SPMEの端で開始し、対応する階層LSPレベルでLSEのTTL値を設定することにより、SPMEのピアエッジまたはSPMEに沿ったMIPに送信できます。Pルーターは、SPMEの終わりにある場合にのみラベルを押したりポップしたりします。このモードでは、SPMEの場合です。
For example, in Figure 17, two SPMEs are configured to allow monitoring, protection, and management of the LSP concatenated segments. One SPME is defined between LER2 and LER3, and a second SPME is set up between LER4 and LER5. Each of these SPMEs may be monitored, protected, or managed independently.
たとえば、図17では、LSP連結セグメントの監視、保護、および管理を可能にするように2つのSPMEが構成されています。1つのSPMEはLER2とLER3の間で定義され、2番目のSPMEがLER4とLER5の間にセットアップされます。これらの各SPMEは、独立して監視、保護、または管理される場合があります。
|<============================= LSP =============================>|
|<---- Carrier 1 ---->| |<---- Carrier 2 ---->|
|LER1|---|LER2|---|LSR|---|LER3|-------|LER4|---|LSR|---|LER5|---|LER6|
|====== SPME =========| |====== SPME =========|
(Carrier 1) (Carrier 2)
Note 1: LER2, LER3, LER4, and LER5 are with respect to the SPME, but LSRs with respect to the LSP. Note 2: The LSP terminates in LERs outside of Carrier 1 and Carrier 2, for example, LER1 and LER6.
注1：LER2、LER3、LER4、およびLER5はSPMEに関してですが、LSPに関してはLSRです。注2：LSPは、キャリア1とキャリア2の外側のLERSで終了します。たとえば、LER1とLER6。
Figure 17: SPMEs in Inter-Carrier Network
図17：キャリア間ネットワークのSPMES
The end-to-end traffic of the LSP, including data traffic and control traffic (OAM, Protection Switching Control, management and signaling messages) is tunneled within the hierarchical LSP by means of label stacking as defined in [RFC3031].
データトラフィックと制御トラフィック（OAM、保護スイッチング制御、管理、シグナリングメッセージ）を含むLSPのエンドツーエンドトラフィックは、[RFC3031]で定義されているラベルスタッキングによって階層LSP内でトンネル化されています。
The mapping between an LSP and a SPME can be 1:1, in which case it is similar to the ITU-T Tandem Connection Element [G.805]. The mapping can also be 1:N to allow aggregated monitoring, protection, and management of a set of LSP segments or concatenated LSP segments. Figure 18 shows a SPME that is used to aggregate a set of concatenated LSP segments for the LSP from LERx to LERt and the LSP from LERa to LERd. Note that such a construct is useful, for example, when the LSPs traverse a common portion of the network and they have the same Traffic Class.
LSPとSPMEの間のマッピングは1：1である場合があります。その場合、ITU-Tタンデム接続要素[G.805]に似ています。マッピングは、LSPセグメントまたは連結LSPセグメントのセットの監視、保護、および管理の総合的な監視、保護、および管理を可能にする1：nです。図18は、LERXからLERT、LERAからLERDまでのLSPの連結LSPセグメントのセットを集約するために使用されるSPMEを示しています。このようなコンストラクトは、たとえば、LSPがネットワークの共通部分を通過し、同じトラフィッククラスを持っている場合に有用であることに注意してください。
The QoS aspects of a SPME are network specific. [OAM-FRAMEWORK] provides further considerations on the QoS aspects of OAM.
SPMEのQOSの側面はネットワーク固有です。[OAMフレームワーク]は、OAMのQOSの側面についてさらに考慮しています。
|LERx|--|LSRy|-+ +-|LSRz|--|LERt|
| |
| |<---------- Carrier 1 --------->| |
| +-----+ +---+ +---+ +-----+ |
+--| |---| |---| |----| |--+
|LER1 | |LSR| |LSR| |LER2 |
+--| |---| |---| |----| |--+
| +-----+ +---+ + P + +-----+ |
| |============ SPME ==============| |
|LERa|--|LSRb|-+ (Carrier 1) +-|LSRc|--|LERd|
Figure 18: SPME for a Set of Concatenated LSP Segments
図18：連結されたLSPセグメントのセットのSPME
SPMEs can be provisioned either statically or using control-plane signaling procedures. The make-before-break procedures which are supported by MPLS allow the creation of a SPME on existing LSPs in-service without traffic disruption, as described in [SURVIVE-FWK]. A SPME can be defined corresponding to one or more end-to-end LSPs. New end-to-end LSPs that are tunneled within the SPME can be set up, which may require coordination across administrative boundaries. Traffic of the existing LSPs is switched over to the new end-to-end tunneled LSPs. The old end-to-end LSPs can then be torn down.
SPMEは、静的または制御平面信号手順を使用してプロビジョニングできます。MPLSによってサポートされているメイクブレイク前の手順により、[Survive-FWK]に記載されているように、交通の混乱なしに既存のLSPインサービスでSPMEを作成することができます。SPMEは、1つ以上のエンドツーエンドLSPに対応する定義できます。SPME内でトンネル化された新しいエンドツーエンドのLSPをセットアップできます。これには、管理境界を越えて調整が必要になる場合があります。既存のLSPのトラフィックは、新しいエンドツーエンドトンネルLSPに切り替えられます。その後、古いエンドツーエンドのLSPを取り壊すことができます。
Hierarchical label stacking, in a similar manner to that described above, can be used to implement Sub-Path Maintenance Elements on pseudowires, as described in [OAM-FRAMEWORK].
上記の階層ラベルスタッキングは、上記の方法と同様の方法で、[OAMフレームワーク]で説明されているように、擬似動物にサブパスメンテナンス要素を実装するために使用できます。
The network management architecture and requirements for MPLS-TP are specified in [NM-FRAMEWORK] and [NM-REQ]. These derive from the generic specifications described in ITU-T G.7710/Y.1701 [G.7710] for transport technologies. They also incorporate the OAM requirements for MPLS Networks [RFC4377] and MPLS-TP Networks [RFC5860] and expand on those requirements to cover the modifications necessary for fault, configuration, performance, and security in a transport network.
MPLS-TPのネットワーク管理アーキテクチャと要件は、[NMフレームワーク]および[NM-Req]で指定されています。これらは、輸送技術のITU-T G.7710/Y.1701 [G.7710]に記載されている一般的な仕様に由来します。また、MPLSネットワーク[RFC4377]およびMPLS-TPネットワーク[RFC5860]のOAM要件を組み込み、輸送ネットワークの障害、構成、パフォーマンス、セキュリティに必要な変更をカバーするために、それらの要件を拡張します。
The Equipment Management Function (EMF) of an MPLS-TP Network Element (NE) (i.e., LSR, LER, PE, S-PE, or T-PE) provides the means through which a management system manages the NE. The Management Communication Channel (MCC), realized by the G-ACh, provides a logical operations channel between NEs for transferring management information. The Network Management System (NMS) can be used to provision and manage an end-to-end connection across a network. Maintenance operations are run on a connection (LSP or PW) in a manner that is independent of the provisioning mechanism. Segments may be created or managed by, for example, Netconf [RFC4741], SNMP [RFC3411], or CORBA (Common Object Request Broker Architecture) interfaces, but not all segments need to be created or managed using the same type of interface. Where an MPLS-TP NE is managed by an NMS, at least one of these standard management mechanisms is required for interoperability, but this document imposes no restriction on which of these standard management protocols is used. In MPLS-TP, the EMF needs to support statically provisioning LSPs for an LSR or LER, and PWs for a PE, as well as any associated MEPs and MIPs, as per Section 3.11.
MPLS-TPネットワーク要素（NE）（つまり、LSR、LER、PE、S-PE、またはT-PE）の機器管理機能（EMF）は、管理システムがNEを管理する手段を提供します。G-achによって実現された管理通信チャネル（MCC）は、管理情報を転送するためにNES間の論理操作チャネルを提供します。ネットワーク管理システム（NMS）を使用して、ネットワーク全体でエンドツーエンド接続をプロビジョニングおよび管理できます。メンテナンス操作は、プロビジョニングメカニズムに依存しない方法で接続（LSPまたはPW）で実行されます。セグメントは、たとえば、NetConf [RFC4741]、SNMP [RFC3411]、またはCORBA（Common Object Request Broker Architecture）インターフェイスによって作成または管理することができますが、すべてのセグメントを同じタイプのインターフェイスを使用して作成または管理する必要はありません。MPLS-TP NEがNMSによって管理されている場合、これらの標準管理メカニズムの少なくとも1つが相互運用性に必要ですが、このドキュメントは、これらの標準管理プロトコルのどれが使用されるかに制限を課しません。MPLS-TPでは、EMFは、セクション3.11に従って、LSRまたはLERのLSP、およびPE、および関連するMEPおよびMIPのPWSの静的プロビジョニングをサポートする必要があります。
Fault Management (FM) functions within the EMF of an MPLS-TP NE enable the supervision, detection, validation, isolation, correction, and alarm handling of abnormal conditions in the MPLS-TP network and its environment. FM needs to provide for the supervision of transmission (such as continuity, connectivity, etc.), software processing, hardware, and environment. Alarm handling includes alarm severity assignment, alarm suppression/aggregation/correlation, alarm reporting control, and alarm reporting.
MPLS-TP NEのEMF内の障害管理（FM）は、MPLS-TPネットワークとその環境における異常な条件の監督、検出、検証、分離、修正、およびアラーム処理を可能にします。FMは、送信（連続性、接続性など）、ソフトウェア処理、ハードウェア、環境の監督を提供する必要があります。アラーム処理には、アラームの重大度の割り当て、アラーム抑制/集約/相関、アラーム報告制御、およびアラーム報告が含まれます。
Configuration Management (CM) provides functions to control, identify, collect data from, and provide data to MPLS-TP NEs. In addition to general configuration for hardware, software protection switching, alarm reporting control, and date/time setting, the EMF of the MPLS-TP NE also supports the configuration of maintenance entity identifiers (such as Maintenance Entity Group Endpoint (MEP) ID and MEG Intermediate Point (MIP) ID). The EMF also supports the configuration of OAM parameters as a part of connectivity management to meet specific operational requirements. These may specify whether the operational mode is one-time on-demand or is periodic at a specified frequency.
Configuration Management（CM）は、MPLS-TP NESの制御、識別、データの収集、およびデータを提供する機能を提供します。ハードウェアの一般的な構成、ソフトウェア保護スイッチング、アラーム報告制御、および日付/時刻設定に加えて、MPLS-TP NEのEMFは、メンテナンスエンティティ識別子の構成（メンテナンスエンティティグループエンドポイント（MEP）IDやなどの構成もサポートしています。MEG中間点（MIP）ID）。EMFは、特定の運用要件を満たすために、接続管理の一部としてOAMパラメーターの構成もサポートしています。これらは、動作モードが1回限りのオンデマンドであるか、指定された周波数で周期的であるかを指定する場合があります。
The Performance Management (PM) functions within the EMF of an MPLS-TP NE support the evaluation and reporting of the behavior of the NEs and the network. One particular requirement for PM is to provide coherent and consistent interpretation of the network behavior in a hybrid network that uses multiple transport technologies. Packet loss measurement and delay measurements may be collected and used to detect performance degradation. This is reported via fault management to enable corrective actions to be taken (e.g., protection switching) and via performance monitoring for Service Level Agreement (SLA) verification and billing. Collection mechanisms for performance data should be capable of operating on-demand or proactively.
MPLS-TP NEのEMF内のパフォーマンス管理（PM）は、NESとネットワークの動作の評価と報告をサポートしています。PMの特定の要件の1つは、複数のトランスポートテクノロジーを使用するハイブリッドネットワークで、ネットワーク動作の一貫した一貫した解釈を提供することです。パケット損失の測定と遅延測定を収集し、パフォーマンスの劣化を検出するために使用できます。これは、障害管理を介して報告され、是正措置を講じることができます（保護スイッチングなど）、およびサービスレベル契約（SLA）の検証と請求のためのパフォーマンス監視を介して報告されます。パフォーマンスデータの収集メカニズムは、オンデマンドまたは積極的に操作できる必要があります。
The introduction of MPLS-TP into transport networks means that the security considerations applicable to both MPLS [RFC3031] and PWE3 [RFC3985] apply to those transport networks. When an MPLS function is included in the MPLS transport profile, the security considerations pertinent to that function apply to MPLS-TP. Furthermore, when general MPLS networks that utilize functionality outside of the strict MPLS Transport Profile are used to support packet transport services, the security considerations of that additional functionality also apply.
MPLS-TPの輸送ネットワークへの導入は、MPLS [RFC3031]とPWE3 [RFC3985]の両方に適用可能なセキュリティに関する考慮事項が、それらの輸送ネットワークに適用されることを意味します。MPLS関数がMPLS輸送プロファイルに含まれている場合、その機能に関連するセキュリティに関する考慮事項がMPLS-TPに適用されます。さらに、Strict MPLSトランスポートプロファイルの外で機能を利用する一般的なMPLSネットワークを使用してパケット輸送サービスをサポートする場合、その追加機能のセキュリティに関する考慮事項も適用されます。
For pseudowires, the security considerations of [RFC3985] and [RFC5659] apply.
擬似動物の場合、[RFC3985]および[RFC5659]のセキュリティ上の考慮事項が適用されます。
MPLS-TP nodes that implement the G-ACh create a Control Channel (CC) associated with a pseudowire, LSP, or section. This control channel can be signaled or statically configured. Over this control channel, control channel messages related to network maintenance functions such as OAM, signaling, or network management are sent. Therefore, three different areas are of concern from a security standpoint.
g-achを実装するMPLS-TPノードは、擬似ワイヤ、LSP、またはセクションに関連付けられたコントロールチャネル（CC）を作成します。この制御チャネルは、信号または静的に構成することができます。この制御チャネルでは、OAM、シグナリング、ネットワーク管理などのネットワークメンテナンス機能に関連する制御チャネルメッセージが送信されます。したがって、セキュリティの観点からは、3つの異なる領域が懸念されています。
The first area of concern relates to control plane parameter and status message attacks, that is, attacks that concern the signaling of G-ACh capabilities. MPLS-TP Control Plane security is discussed in [RFC5920].
懸念の最初の領域は、コントロールプレーンのパラメーターとステータスメッセージ攻撃、つまりG-ach機能のシグナル伝達に関係する攻撃に関連しています。MPLS-TPコントロールプレーンのセキュリティについては、[RFC5920]で説明しています。
A second area of concern centers on data-plane attacks, that is, attacks on the G-ACh itself. MPLS-TP nodes that implement the G-ACh mechanisms are subject to additional data-plane denial-of-service attacks as follows:
懸念の2番目の領域は、データプレーン攻撃、つまりG-ach自体に対する攻撃に焦点を当てています。G-CACHメカニズムを実装するMPLS-TPノードは、次のように追加のデータプレーン拒否攻撃の対象となります。
An intruder could intercept or inject G-ACh packets effectively disrupting the protocols carried over the G-ACh.
侵入者は、G-achを介したプロトコルを効果的に破壊するg-achパケットを傍受または挿入することができます。
An intruder could deliberately flood a peer MPLS-TP node with G-ACh messages to deny services to others.
侵入者は、他の人へのサービスを拒否するために、ピアMPLS-TPノードをG-achメッセージで意図的にあふれさせることができます。
A misconfigured or misbehaving device could inadvertently flood a peer MPLS-TP node with G-ACh messages that could result in denial of services. In particular, if a node has either implicitly or explicitly indicated that it cannot support one or all of the types of G-ACh protocol, but is sent those messages in sufficient quantity, it could result in a denial of service.
誤解されたデバイスまたは誤動作デバイスは、サービスの拒否をもたらす可能性のあるG-achメッセージでピアMPLS-TPノードに不注意にあふれている可能性があります。特に、ノードが1つまたはすべてのg-achプロトコルをサポートできないが、それらのメッセージを十分な数量で送信することができないことを暗黙的または明示的に示した場合、サービスの拒否をもたらす可能性があります。
To protect against these potential (deliberate or unintentional) attacks, multiple mitigation techniques can be employed:
これらの潜在的な（意図的または意図しない）攻撃から保護するために、複数の緩和技術を採用できます。
G-ACh message throttling mechanisms can be used, especially in distributed implementations that have a centralized control-plane processor with various line cards attached by some control-plane data path. In these architectures, G-ACh messages may be processed on the central processor after being forwarded there by the receiving line card. In this case, the path between the line card and the control processor may become saturated if appropriate G-ACh traffic throttling is not employed, which could lead to a complete denial of service to users of the particular line card. Such filtering is also useful for preventing the processing of unwanted G-ACh messages, such as those which are sent on unwanted (and perhaps unadvertised) control channel types.
G-achメッセージスロットリングメカニズムは、特に、一部のコントロールプレーンデータパスでさまざまなラインカードを備えた集中制御プレーンプロセッサを備えた分散実装で使用できます。これらのアーキテクチャでは、受信ラインカードによってそこに転送された後、G-achメッセージを中央プロセッサで処理することができます。この場合、ラインカードと制御プロセッサの間のパスは、適切なG-achトラフィックスロットリングが使用されない場合、飽和状態になる場合があり、特定のラインカードのユーザーに完全なサービスを拒否する可能性があります。このようなフィルタリングは、望ましくない（そしておそらく宣伝されていない）制御チャネルタイプで送信されるものなど、不要なG-achメッセージの処理を防ぐのにも役立ちます。
A third and last area of concern relates to the processing of the actual contents of G-ACh messages. It is necessary that the definition of the protocols using these messages carried over a G-ACh include appropriate security measures.
懸念の3番目の最後の領域は、G-achメッセージの実際の内容の処理に関連しています。これらのメッセージを使用したプロトコルの定義には、g-achが含まれていることが必要です。適切なセキュリティ対策が含まれます。
Additional security considerations apply to each MPLS-TP solution. These are discussed further in [SEC-FRAMEWORK].
各MPLS-TPソリューションには追加のセキュリティに関する考慮事項が適用されます。これらについては、[secフレームワーク]でさらに説明します。
The security considerations in [RFC5920] apply.
[RFC5920]のセキュリティ上の考慮事項が適用されます。
IANA considerations resulting from specific elements of MPLS-TP functionality will be detailed in the documents specifying that functionality.
MPLS-TP機能の特定の要素に起因するIANAの考慮事項については、その機能を指定するドキュメントで詳しく説明されています。
This document introduces no additional IANA considerations in itself.
このドキュメントでは、IANAの考慮事項自体が追加されていません。
The editors wish to thank the following for their contributions to this document:
編集者は、このドキュメントへの貢献について以下に感謝したいと思います。
o Rahul Aggarwal
o Rahul Aggarwal
o Dieter Beller
o ディーターベラー
o Malcolm Betts
o マルコム・ベッツ
o Italo Busi
o イタロビジネス
o John E Drake
o ジョンEドレイク
o Hing-Kam Lam
o hing-kam lam
o Marc Lasserre
o マーク・ラッサレ
o Vincenzo Sestito
o ヴィンチェンツォ・セスティト
o Nurit Sprecher
o Nurit Sprecher
o Martin Vigoureux
o マーティン・ヴィゴールー
o Yaacov Weingarten
o Yaacov Weingarten
o The participants of ITU-T SG15
o ITU-T SG15の参加者
[G.7710] ITU-T, "Common equipment management function requirements", ITU-T Recommendation G.7710/Y.1701, July 2007.
[G.7710] ITU-T、「一般的な機器管理機能要件」、ITU-T推奨G.7710/Y.1701、2007年7月。
[G.805] ITU-T, "Generic Functional Architecture of Transport Networks", ITU-T Recommendation G.805, November 1995.
[G.805] ITU-T、「輸送ネットワークの一般的な機能アーキテクチャ」、ITU-T推奨G.805、1995年11月。
[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月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「Mpls Label Stack Encoding」、RFC 3032、2001年1月。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P。、およびJ. Heinanen、「Multi-Protocol Label Switching」（MPLS）差別化されたサービスのサポート」、RFC 3270、2002年5月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソースリソースプロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年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月。
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090] Pan、P.、Swallow、G。、およびA. Atlas、「LSPトンネルのRSVP-TEへの高速拡張式」、RFC 4090、2005年5月。
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006.
[RFC4385] Bryant、S.、Swallow、G.、Martini、L。、およびD. McPherson、「Pseudowire Emulation Edge-to-Edge（PWE3）がMPLS PSNを介して使用するコントロールワード」、RFC 4385、2006年2月。
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447] Martini、L.、Rosen、E.、El-Aawar、N.、Smith、T.、およびG. Heron、「ラベル分布プロトコル（LDP）を使用したPseudowireのセットアップとメンテナンス」、RFC 4447、2006年4月。
[RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007.
[RFC4872] Lang、J.、Rekhter、Y。、およびD. Papadimitriou、「RSVP-TE拡張は、エンドツーエンドの一般化マルチプロトコルラベルスイッチング（GMPLS）回復をサポートする」、2007年5月、RFC 4872。
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5085] Nadeau、T。およびC. Pignataro、「Pseudowire仮想回路接続検証（VCCV）：Pseudowiresの制御チャネル」、RFC 5085、2007年12月。
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009.
[RFC5586] Bocci、M.、Vigoureux、M。、およびS. Bryant、「Mpls Generic Associated Channel」、RFC 5586、2009年6月。
[CP-FRAMEWORK] Andersson, L., Berger, L., Fang, L., Bitar, N., Takacs, A., Vigoureux, M., Bellagamba, E., and E. Gray, "MPLS-TP Control Plane Framework", Work in Progress, March 2010.
[CP-Framework] Andersson、L.、Berger、L.、Fang、L.、Bitar、N.、Takacs、A.、Vigoureux、M.、Bellagamba、E。、およびE. Gray、 "mpls-tp Control飛行機のフレームワーク」、2010年3月、進行中の作業。
[DATA-PLANE] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport Profile Data Plane Architecture", Work in Progress, July 2010.
[データプレーン] Frost、D.、Bryant、S。、およびM. Bocci、「MPLS輸送プロファイルデータプレーンアーキテクチャ」、2010年7月の作業。
[DYN-MS-PW] Martini, L., Bocci, M., Balus, F., Bitar, N., Shah, H., Aissaoui, M., Rusmisel, J., Serbest, Y., Malis, A., Metz, C., McDysan, D., Sugimoto, J., Duckett, M., Loomis, M., Doolan, P., Pan, P., Pate, P., Radoaca, V., Wada, Y., and Y. Seo, "Dynamic Placement of Multi Segment Pseudo Wires", Work in Progress, October 2009.
[Dyn-MS-PW] Martini、L.、Bocci、M.、Balus、F.、Bitar、N.、Shah、H.、Aissaoui、M.、Rusmisel、J.、Serbest、Y.、Malis、A A A A。、Metz、C.、McDysan、D.、Sugimoto、J.、Duckett、M.、Loomis、M.、Doolan、P.、Pan、P.、Pate、P.、Radoaca、V.、Wada、Y。、およびY. SEO、「マルチセグメント擬似ワイヤの動的配置」、2009年10月、進行中の作業。
[G.8080] ITU-T, "Architecture for the automatically switched optical network (ASON)", ITU-T Recommendation G.8080/Y.1304, 2005.
[G.8080] ITU-T、「自動化された光ネットワーク（ASON）のアーキテクチャ」、ITU-T推奨G.8080/Y.1304、2005。
[IDENTIFIERS] Bocci, M. and G. Swallow, "MPLS-TP Identifiers", Work in Progress, March 2010.
[識別子] Bocci、M。およびG. Swallow、「MPLS-TP Identifiers」、Work in Progress、2010年3月。
[NM-FRAMEWORK] Mansfield, S., Ed., Gray, E., Ed., and H. Lam, Ed., "MPLS-TP Network Management Framework", Work in Progress, February 2010.
[NMフレームワーク] Mansfield、S.、Ed。、Gray、E.、Ed。、およびH. Lam、ed。、「MPLS-TP Network Management Framework」、Work in Progress、2010年2月。
[NM-REQ] Mansfield, S. and K. Lam, "MPLS TP Network Management Requirements", Work in Progress, October 2009.
[NM-Req] Mansfield、S。およびK. Lam、「MPLS TPネットワーク管理要件」、2009年10月の作業。
[OAM-DEF] Andersson, L., Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "The OAM Acronym Soup", Work in Progress, June 2010.
[OAM-DEF] Andersson、L.、Helvoort、H.、Bonica、R.、Romascanu、D。、およびS. Mansfield、「The Oamの頭字語スープ」、2010年6月の作業。
[OAM-FRAMEWORK] Busi, I., Ed., Niven-Jenkins, B., Ed., and D. Allan, Ed., "MPLS-TP OAM Framework", Work in Progress, April 2010.
[OAMフレームワーク] Busi、I.、ed。、Niven-Jenkins、B.、ed。、およびD. Allan、ed。、「Mpls-TP OAM Framework」、2010年4月の作業。
[PW-REDUNDANCY] Muley, P., "Pseudowire (PW) Redundancy", Work in Progress, May 2010.
[PW-Redundancy] Muley、P。、「Pseudowire（PW）冗長性」、2010年5月の作業。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：LSP TunnelsのRSVPへの拡張"、RFC 3209、12月2001年。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411] Harrington、D.、Presuhn、R。、およびB. Wijnen、「単純なネットワーク管理プロトコル（SNMP）管理フレームワークを説明するためのアーキテクチャ」、STD 62、RFC 3411、2002年12月。
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003.
[RFC3443] Agarwal、P。およびB. Akyol、「マルチプロトコルラベルスイッチング（MPLS）ネットワークでのライブ（TTL）処理」、RFC 3443、2003年1月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、2003年1月。
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] Mannie、E。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）アーキテクチャ」、RFC 3945、2004年10月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364] Rosen、E。およびY. Rekhter、「BGP/MPLS IP仮想ネットワーク（VPNS）」、RFC 4364、2006年2月。
[RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. Matsushima, "Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, February 2006.
[RFC4377] Nadeau、T.、Morrow、M.、Swallow、G.、Allan、D。、およびS. Matsushima、「Operation and Management（OAM）要件マルチプロトコルラベルスイッチ（MPLS）ネットワーク」、RFC 4377、2006年2月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K。およびG. Swallow、「Multi-Protocol Label Switched（MPLS）データプレーン障害の検出」、RFC 4379、2006年2月。
[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
[RFC4664] Andersson、L。およびE. Rosen、「レイヤー2仮想プライベートネットワーク（L2VPNS）のフレームワーク」、RFC 4664、2006年9月。
[RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006.
[RFC4726] Farrel、A.、Vasseur、J。、およびA. Ayyangar、「ドメイン間マルチプロトコルラベルスイッチングトラフィックエンジニアリングのフレームワーク」、RFC 4726、2006年11月。
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[RFC4741] ENNS、R。、「NetConf Configuration Protocol」、RFC 4741、2006年12月。
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC 5150, February 2008.
[RFC5150] Ayyangar、A.、Kompella、K.、Vasseur、Jp。、およびA. Farrel、「一般化されたマルチプロトコルラベル交通工学（GMPLS TE）を使用したラベルスイッチングパスステッチ」、RFC 5150、2008年2月。
[RFC5254] Bitar, N., Bocci, M., and L. Martini, "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", RFC 5254, October 2008.
[RFC5254] Bitar、N.、Bocci、M。、およびL. Martini、「マルチセグメントの擬似ワイヤエミュレーションエッジとエッジ（PWE3）の要件」、RFC 5254、2008年10月。
[RFC5309] Shen, N. and A. Zinin, "Point-to-Point Operation over LAN in Link State Routing Protocols", RFC 5309, October 2008.
[RFC5309] Shen、N。およびA. Zinin、「リンク状態ルーティングプロトコルにおけるLAN上のポイントツーポイント操作」、RFC 5309、2008年10月。
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008.
[RFC5331] Aggarwal、R.、Rekhter、Y。、およびE. Rosen、「MPLS Upstream Labelの割り当てとコンテキスト固有のラベルスペース」、RFC 5331、2008年8月。
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[RFC5654] Niven-Jenkins、B.、Brungard、D.、Betts、M.、Sprecher、N。、およびS. Ueno、「MPLS輸送プロファイルの要件」、RFC 5654、2009年9月。
[RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, October 2009.
[RFC5659] Bocci、M。およびS. Bryant、「マルチセグメントの擬似ワイヤーエミュレーションエッジツーエッジのアーキテクチャ」、RFC 5659、2009年10月。
[RFC5718] Beller, D. and A. Farrel, "An In-Band Data Communication Network For the MPLS Transport Profile", RFC 5718, January 2010.
[RFC5718] Beller、D。およびA. Farrel、「MPLS輸送プロファイルの帯域データ通信ネットワーク」、RFC 5718、2010年1月。
[RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010.
[RFC5860] Vigoureux、M.、Ward、D。、およびM. Betts、「MPLS輸送ネットワークの運用、管理、およびメンテナンスの要件（OAM）」、RFC 5860、2010年5月。
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC5884] Aggarwal、R.、Kompella、K.、Nadeau、T。、およびG. Swallow、「MPLSラベルスイッチドパス（LSP）の双方向転送検出（BFD）」、RFC 5884、2010年6月。
[RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, June 2010.
[RFC5885] Nadeau、T。およびC. Pignataro、「Pseudowire仮想回路接続検証（VCCV）の双方向転送検出（BFD）」、RFC 5885、2010年6月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang、L.、ed。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。
[ROSETTA-STONE] Sprecher, N., "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, May 2010.
[Rosetta-Stone] Sprecher、N。、「マルチプロトコルラベルスイッチングトランスポートプロファイル（MPLS-TP）ドラフト/RFCSおよびITU-Tのトランスポートネットワークの推奨事項で使用される用語のシソーラス」、2010年5月の進行中。
[SEC-FRAMEWORK] Fang, L. and B. Niven-Jenkins, "Security Framework for MPLS-TP", Work in Progress, March 2010.
[Sec-Framework] Fang、L。and B. Niven-Jenkins、「MPLS-TPのセキュリティフレームワーク」、2010年3月の作業。
[SEGMENTED-PW] Martini, L., Nadeau, T., Metz, C., Bocci, M., and M. Aissaoui, "Segmented Pseudowire", Work in Progress, June 2010.
[セグメント化されたPW] Martini、L.、Nadeau、T.、Metz、C.、Bocci、M。、およびM. Aissaoui、「セグメント化されたPseudowire」、2010年6月の進行中。
[SURVIVE-FWK] Sprecher, N. and A. Farrel, "Multiprotocol Label Switching Transport Profile Survivability Framework", Work in Progress, June 2010.
[Survive-FWK] Sprecher、N。およびA. Farrel、「マルチプロトコルラベルスイッチングトランスポートプロファイルの生存可能性フレームワーク」、2010年6月の作業。
[VPMS-REQS] Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard, D., and L. Jin, "Framework and Requirements for Virtual Private Multicast Service (VPMS)", Work in Progress, October 2009.
[VPMS-Reqs] Kamite、Y.、Jounay、F.、Niven-Jenkins、B.、Brungard、D。、およびL. Jin、「Virtual Private Multicast Service（VPMS）のフレームワークと要件」、進行中の作業、2009年10月。
[X.200] ITU-T, "Information Technology - Open Systems Interconnection - Basic reference Model: The Basic Model", ITU-T Recommendation X.200, 1994.
[X.200] ITU -T、「情報技術 - オープンシステムの相互接続 - 基本的な参照モデル：基本モデル」、ITU -T推奨X.200、1994。
Authors' Addresses
著者のアドレス
Matthew Bocci (editor) Alcatel-Lucent Voyager Place, Shoppenhangers Road Maidenhead, Berks SL6 2PJ United Kingdom
Matthew Bocci（編集者）Alcatel-Lucent Voyager Place、Shoppenhangers Road Maidenhead、Berks SL6 2PJイギリス
EMail: matthew.bocci@alcatel-lucent.com
Stewart Bryant (editor) Cisco Systems 250 Longwater Ave Reading RG2 6GB United Kingdom
スチュワートブライアント（編集者）シスコシステム250ロングウォーターアベニューRG2 6GBイギリス
EMail: stbryant@cisco.com
Dan Frost (editor) Cisco Systems
Dan Frost（編集者）Cisco Systems
EMail: danfrost@cisco.com
Lieven Levrau Alcatel-Lucent 7-9, Avenue Morane Sulnier Velizy 78141 France
Lieven Levrau Alcatel-Lucent 7-9、Avenue Morane Sulnier Velizy 78141 France
EMail: lieven.levrau@alcatel-lucent.com
Lou Berger LabN Consulting, L.L.C.
Lou Berger Labn Consulting、L.L.C。
EMail: lberger@labn.net