[要約] RFC 7087は、MPLS Transport Profile（MPLS-TP）のインターネットドラフトやRFCの用語解釈のためのシソーラスであり、ITU-Tのトランスポートネットワーク勧告の文脈で使用されます。このRFCの目的は、MPLS-TP関連の文書の用語を統一し、相互運用性を向上させることです。
Internet Engineering Task Force (IETF) H. van Helvoort, Ed.
Request for Comments: 7087 L. Andersson, Ed.
Category: Informational Huawei Technologies
ISSN: 2070-1721 N. Sprecher, Ed.
Nokia Solutions and Networks
December 2013
A Thesaurus for the Interpretation of Terminology Used in MPLS Transport Profile (MPLS-TP) Internet-Drafts and RFCs in the Context of the ITU-T's Transport Network Recommendations
ITU-Tのトランスポートネットワークの推奨事項のコンテキストでMPLSトランスポートプロファイル（MPLS-TP）インターネットドラフトおよびRFCで使用される用語の解釈のためのシソーラス
Abstract
概要
The MPLS Transport Profile (MPLS-TP) is based on a profile of the MPLS and Pseudowire (PW) procedures as specified in the MPLS Traffic Engineering (MPLS-TE), PW, and Multi-Segment Pseudowire (MS-PW) architectures developed by the Internet Engineering Task Force (IETF). The International Telecommunication Union Telecommunication Standardization Sector (ITU-T) has specified a Transport Network architecture.
MPLSトランスポートプロファイル（MPLS-TP）は、開発されたMPLSトラフィックエンジニアリング（MPLS-TE）、PW、およびマルチセグメント疑似配線（MS-PW）アーキテクチャで指定されているMPLSおよび疑似配線（PW）手順のプロファイルに基づいています。 Internet Engineering Task Force（IETF）による。国際電気通信連合電気通信標準化部門（ITU-T）は、トランスポートネットワークアーキテクチャを指定しています。
This document provides a thesaurus for the interpretation of MPLS-TP terminology within the context of the ITU-T Transport Network Recommendations.
このドキュメントは、ITU-Tトランスポートネットワークの推奨事項のコンテキスト内でMPLS-TP用語を解釈するためのシソーラスを提供します。
It is important to note that MPLS-TP is applicable in a wider set of contexts than just Transport Networks. The definitions presented in this document do not provide exclusive or complete interpretations of MPLS-TP concepts. This document simply allows the MPLS-TP terms to be applied within the Transport Network context.
MPLS-TPは、トランスポートネットワークだけでなく、より幅広いコンテキストに適用できることに注意してください。このドキュメントに示されている定義は、MPLS-TP概念の排他的または完全な解釈を提供するものではありません。このドキュメントでは、MPLS-TPの用語をトランスポートネットワークコンテキスト内で適用することを許可しています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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/rfc7087.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7087で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Abbreviations ..............................................4
2. Terminology .....................................................5
2.1. MPLS-TP Terminology Sources ................................5
2.2. ITU-T Transport Network Terminology Sources ................6
2.3. Common Terminology Sources .................................6
3. Thesaurus .......................................................6
3.1. Associated Bidirectional Path ..............................6
3.2. Bidirectional Path .........................................6
3.3. Client-Layer Network .......................................6
3.4. Communication Channel ......................................7
3.5. Concatenated Segment .......................................7
3.6. Control Plane ..............................................7
3.7. Co-Routed Bidirectional Path ...............................7
3.8. Data Communication Network (DCN) ...........................7
3.9. Defect .....................................................8
3.10. Domain ....................................................8
3.11. Embedded Communication Channel (ECC) ......................8
3.12. Equipment Management Function (EMF) .......................8
3.13. Failure ...................................................8
3.14. Fault .....................................................8
3.15. Layer Network .............................................9
3.16. Link ......................................................9
3.17. Maintenance Entity (ME) ...................................9
3.18. Maintenance Entity Group (MEG) ...........................10
3.19. Maintenance Entity Group End Point (MEP) .................10
3.20. Maintenance Entity Group Intermediate Point (MIP) ........11
3.21. Management Communication Channel (MCC) ...................11
3.22. Management Communication Network (MCN) ...................11
3.23. Monitoring ...............................................11
3.23.1. Path Segment Tunnel (PST) .........................11
3.23.2. Sub-Path Maintenance Element (SPME) ...............12
3.23.3. Tandem Connection .................................12
3.24. MPLS Section .............................................12
3.25. MPLS Transport Profile (MPLS-TP) .........................12
3.26. MPLS-TP NE ...............................................13
3.27. MPLS-TP Network ..........................................13
3.28. MPLS-TP Recovery .........................................13
3.28.1. End-to-End Recovery ...............................13
3.28.2. Link Recovery .....................................13
3.28.3. Segment Recovery ..................................13
3.29. MPLS-TP Ring Topology ....................................13
3.29.1. MPLS-TP Logical Ring ..............................14
3.29.2. MPLS-TP Physical Ring .............................14
3.30. OAM Flow .................................................14
3.31. Operations Support System (OSS) ..........................14
3.32. Path .....................................................14
3.33. Protection Priority ......................................14
3.34. Section-Layer Network ....................................14
3.35. Segment ..................................................15
3.36. Server Layer .............................................15
3.37. Server MEPs ..............................................15
3.38. Signaling Communication Channel (SCC) ....................16
3.39. Signaling Communication Network (SCN) ....................16
3.40. Span .....................................................16
3.41. Sublayer .................................................16
3.42. Transport Entity .........................................16
3.42.1. Working Entity ....................................16
3.42.2. Protection Entity .................................16
3.42.3. Recovery Entity ...................................16
3.43. Transmission Media Layer .................................17
3.44. Transport Network ........................................17
3.45. Transport Path ...........................................17
3.46. Transport-Path Layer .....................................17
3.47. Transport-Service Layer ..................................17
3.48. Unidirectional Path ......................................17
4. Guidance on the Application of This Thesaurus ..................18
5. Management Considerations ......................................18
6. Security Considerations ........................................18
7. Acknowledgments ................................................18
8. Contributors ...................................................18
9. References .....................................................19
9.1. Normative References ......................................19
9.2. Informative References ....................................20
The MPLS Transport Profile (MPLS-TP) has been developed by the IETF to facilitate the Operations, Administration, and Maintenance (OAM) of Label Switched Paths (LSPs) to be used in a Transport Network environment as defined by the ITU-T.
MPLSトランスポートプロファイル（MPLS-TP）は、ITU-Tで定義されているトランスポートネットワーク環境で使用されるラベルスイッチドパス（LSP）の運用、管理、および保守（OAM）を容易にするためにIETFによって開発されました。
The ITU-T has specified a Transport Network architecture for the transfer of signals from different technologies. This architecture forms the basis of many Recommendations within the ITU-T.
ITU-Tは、さまざまなテクノロジーからの信号を転送するためのトランスポートネットワークアーキテクチャを指定しています。このアーキテクチャは、ITU-T内の多くの勧告の基礎を形成します。
Because of the difference in historic background of MPLS, and inherently MPLS-TP (the Internet) and the Transport Network (ITU Telecommunication Sector), the terminology used is different.
MPLSの歴史的背景、および本質的にMPLS-TP（インターネット）とトランスポートネットワーク（ITUテレコミュニケーションセクター）の違いにより、使用される用語は異なります。
This document provides a thesaurus (the analogy to the Rosetta Stone has been used within the working groups) for the interpretation of MPLS-TP terminology within the context of the ITU-T Transport Network Recommendations. This allows MPLS-TP documents to be generally understood by those familiar with MPLS RFCs. The definitions presented in this document do not provide exclusive or complete interpretations of the ITU-T Transport Network concepts.
このドキュメントは、ITU-Tトランスポートネットワークの推奨事項のコンテキスト内でMPLS-TP用語を解釈するためのシソーラス（Rosetta Stoneに類似したものがワーキンググループ内で使用されています）を提供します。これにより、MPLS-TPドキュメントは一般にMPLS RFCに精通した人々に理解されます。このドキュメントに記載されている定義は、ITU-Tトランスポートネットワークの概念の排他的または完全な解釈を提供するものではありません。
CE Customer Edge
CEカスタマーエッジ
DCC Data Communication Channel
DCCデータ通信チャネル
DCN Data Communication Network
DCNデータ通信ネットワーク
ECC Embedded Communication Channel
ECC組み込み通信チャネル
EMF Equipment Management Function
EMF機器管理機能
EMS Element Management System
EMS要素管理システム
GAL Generic Associated Channel Label
GAL汎用関連チャネルラベル
LER Label Edge Router
LERラベルエッジルーター
LSR Label Switching Router
LSRラベルスイッチングルータ
MCC Management Communication Channel
クライアントセンター管理通信チャネル
MCN Management Communication Network
MCN管理通信ネットワーク
ME Maintenance Entity MEG Maintenance Entity Group
MEメンテナンスエンティティMEGメンテナンスエンティティグループ
MEP Maintenance Entity Group End Point
MEPメンテナンスエンティティグループのエンドポイント
MIP Maintenance Entity Group Intermediate Point
MIPメンテナンスエンティティグループ中間ポイント
MPLS Multiprotocol Label Switching
MPLSマルチプロトコルラベルスイッチング
MPLS-TP MPLS Transport Profile
MPLS-TP MPLSトランスポートプロファイル
MS-PW Multi-Segment Pseudowire
MS-PWマルチセグメント疑似配線
NE Network Element
ネットワーク要素ではありません
NEF Network Element Function
NEFネットワーク要素機能
OAM Operations, Administration, and Maintenance
OAMの運用、管理、保守
OSS Operations Support System
OSS運用支援システム
PM Performance Monitoring
PMパフォーマンスモニタリング
PST Path Segment Tunnel
PSTパスセグメントトンネル
PW Pseudowire
ΠΩpseudovir
S-PE Switching Provider Edge
S-PEスイッチングプロバイダーエッジ
SCC Signaling Communication Channel
SCCシグナリング通信チャネル
SCN Signaling Communication Network
SCNシグナリング通信ネットワーク
SPME Sub-Path Maintenance Element
SPMEサブパスメンテナンス要素
T-PE Terminating Provider Edge
T-PE終端プロバイダーエッジ
TCM Tandem Connection Monitoring
TCMタンデム接続モニタリング
This section provides an overview regarding terminology used in this document.
このセクションでは、このドキュメントで使用されている用語に関する概要を説明します。
MPLS-TP terminology is principally defined in [RFC3031]. Other documents, including [RFC4397], provide further key definitions.
MPLS-TPの用語は、主に[RFC3031]で定義されています。 [RFC4397]を含む他のドキュメントは、さらに重要な定義を提供します。
The ITU-T Transport Network is specified in a number of Recommendations: generic functional architectures and requirements are specified in [ITU-T_G.805], [ITU-T_G.806], and [ITU-T_G.872]. ITU-T Recommendation G.8101/Y.1355 [ITU-T_G.8101] contains an overview of the terms and definitions for transport MPLS.
ITU-Tトランスポートネットワークは、いくつかの推奨事項で指定されています。一般的な機能アーキテクチャと要件は、[ITU-T_G.805]、[ITU-T_G.806]、および[ITU-T_G.872]で指定されています。 ITU-T勧告G.8101 / Y.1355 [ITU-T_G.8101]には、トランスポートMPLSの用語と定義の概要が含まれています。
The work in this document builds on the shared view of MPLS requirements. It is intended to provide a source for common MPLS-TP terminology. In general, the original terminology is used.
このドキュメントの作業は、MPLS要件の共有ビューに基づいています。一般的なMPLS-TP用語のソースを提供することを目的としています。一般に、元の用語が使用されます。
The following sources are used:
次のソースが使用されます。
o IETF framework and requirements RFCs: [RFC6371], [RFC6372], [RFC5654], [RFC5921], [RFC5860], [RFC5951], [RFC3031], and [RFC4397].
o IETFフレームワークと要件のRFC：[RFC6371]、[RFC6372]、[RFC5654]、[RFC5921]、[RFC5860]、[RFC5951]、[RFC3031]、および[RFC4397]。
o ITU-T architecture and requirements Recommendations: [ITU-T_G.8101], [ITU-T_G.805], [ITU-T_G.806], [ITU-T_G.872], [ITU-T_G.7710], and [ITU-T_Y.2611].
o ITU-Tアーキテクチャと要件推奨事項：[ITU-T_G.8101]、[ITU-T_G.805]、[ITU-T_G.806]、[ITU-T_G.872]、[ITU-T_G.7710]、および[ ITU-T_Y.2611]。
An associated bidirectional path is a path that supports traffic flow in both directions but that is constructed from a pair of unidirectional paths (one for each direction) that are associated with one another at the path's ingress/egress points. An associated bidirectional path need not be a single management and operational entity. The forward and backward directions are set up, monitored, and protected independently. As a consequence, they may or may not follow the same route (links and nodes) across the network.
関連する双方向パスは、両方向のトラフィックフローをサポートするパスですが、パスの入力/出力ポイントで相互に関連付けられている一方向のパスのペア（各方向に1つ）から構成されます。関連する双方向パスは、単一の管理および運用エンティティである必要はありません。順方向と逆方向は、個別に設定、監視、保護されます。その結果、ネットワーク全体で同じルート（リンクとノード）をたどる場合とそうでない場合があります。
A bidirectional path refers to a path that supports traffic flow in two opposite directions, i.e., the forward and backward direction.
双方向パスは、2つの反対方向、つまり順方向と逆方向のトラフィックフローをサポートするパスを指します。
In a client/server relationship (see [ITU-T_G.805]), the client-layer network receives a (transport) service from the lower server-layer network (usually the layer network under consideration).
クライアント/サーバー関係（[ITU-T_G.805]を参照）では、クライアント層ネットワークは、下位サーバー層ネットワーク（通常、検討中の層ネットワーク）から（トランスポート）サービスを受け取ります。
A Communication Channel is a logical channel between network elements (NEs) that can be used, e.g., for management-plane applications or control-plane applications. The physical channel supporting the Communication Channel is technology specific. See [RFC5951], Appendix A.
通信チャネルは、ネットワーク要素（NE）間の論理チャネルであり、たとえば、管理プレーンアプリケーションやコントロールプレーンアプリケーションに使用できます。通信チャネルをサポートする物理チャネルはテクノロジー固有です。 [RFC5951]、付録Aを参照してください。
A concatenated segment is a serial-compound link connection as defined in [ITU-T_G.805]. A concatenated segment is a contiguous part of an LSP or MS-PW that comprises a set of segments and their interconnecting nodes in sequence. See also "Segment" (Section 3.35).
連結セグメントは、[ITU-T_G.805]で定義されているシリアル複合リンク接続です。連結セグメントは、一連のセグメントとそれらの相互接続ノードを順番に含むLSPまたはMS-PWの連続した部分です。 「セグメント」（セクション3.35）も参照してください。
Within the scope of [RFC5654], the control plane performs transport path control functions. Through signaling, the control plane sets up, modifies, and releases transport paths and may recover a transport path in case of a failure. The control plane also performs other functions in support of transport path control, such as routing information dissemination. It is possible to operate an MPLS-TP network without using a control plane.
[RFC5654]の範囲内で、コントロールプレーンはトランスポートパス制御機能を実行します。シグナリングを通じて、コントロールプレーンはトランスポートパスをセットアップ、変更、および解放し、障害が発生した場合にトランスポートパスを回復します。コントロールプレーンは、ルーティング情報の配布など、トランスポートパス制御をサポートする他の機能も実行します。コントロールプレーンを使用せずにMPLS-TPネットワークを運用できます。
A co-routed bidirectional path is a path where the forward and backward directions follow the same route (links and nodes) across the network. A co-routed bidirectional path is managed and operated as a single entity. Both directions are set up, monitored, and protected as a single entity. A Transport Network path is typically co-routed.
共経路の双方向パスは、順方向と逆方向がネットワーク上の同じルート（リンクとノード）をたどるパスです。共同ルーティングされた双方向パスは、単一のエンティティとして管理および運用されます。両方向は、単一のエンティティとしてセットアップ、監視、保護されます。トランスポートネットワークパスは通常、同じルートにあります。
A DCN is a network that supports Layer 1 (physical layer), Layer 2 (data-link layer), and Layer 3 (network layer) functionality for distributed management communications related to the management plane, for distributed routing and signaling communications related to the control plane, and for other operations communications (e.g., order-wire/voice communications, software downloads, etc.).
DCNは、管理プレーンに関連する分散管理通信、分散ルーティングおよび関連するシグナリング通信のためのレイヤー1（物理レイヤー）、レイヤー2（データリンクレイヤー）、およびレイヤー3（ネットワークレイヤー）機能をサポートするネットワークです。コントロールプレーン、およびその他の運用通信（オーダーワイヤ/音声通信、ソフトウェアのダウンロードなど）。
"Defect" refers to the situation for which the density of anomalies has reached a level where the ability to perform a required function has been interrupted. Defects are used as input for Performance Monitoring (PM), the control of consequent actions, and the determination of fault cause. See also [ITU-T_G.806].
「欠陥」とは、異常の密度が、必要な機能を実行する機能が中断されたレベルに達した状況を指します。欠陥は、パフォーマンスモニタリング（PM）、結果として生じるアクションの制御、および障害の原因の特定のための入力として使用されます。 [ITU-T_G.806]も参照してください。
A domain represents a collection of entities (for example, network elements) that are grouped for a particular purpose, examples of which are administrative and/or managerial responsibilities, trust relationships, addressing schemes, infrastructure capabilities, aggregation, survivability techniques, distributions of control functionality, etc. Examples of such domains include IGP areas and Autonomous Systems.
ドメインは、特定の目的のためにグループ化されたエンティティ（ネットワーク要素など）のコレクションを表します。その例としては、管理および/または管理の責任、信頼関係、アドレッシングスキーム、インフラストラクチャ機能、集約、存続可能性手法、制御の分散があります。そのようなドメインの例には、IGPエリアや自律システムなどがあります。
An ECC is a logical operations channel between network elements (NEs) that can be utilized by multiple applications (e.g., management-plane applications, control-plane applications, etc.). The physical channel supporting the ECC is technology specific. An example of a physical channel supporting the ECC is a Data Communication Channel (DCC) within the Synchronous Digital Hierarchy (SDH).
ECCは、複数のアプリケーション（管理プレーンアプリケーション、コントロールプレーンアプリケーションなど）で利用できるネットワーク要素（NE）間の論理操作チャネルです。 ECCをサポートする物理チャネルはテクノロジー固有です。 ECCをサポートする物理チャネルの例は、同期デジタル階層（SDH）内のデータ通信チャネル（DCC）です。
The equipment management function (EMF) provides the means through which an element management system (EMS) and other managing entities manage the network element function (NEF). See [ITU-T_G.7710].
機器管理機能（EMF）は、要素管理システム（EMS）およびその他の管理エンティティがネットワーク要素機能（NEF）を管理する手段を提供します。 [ITU-T_G.7710]を参照してください。
A failure is a detected fault. A failure will be declared when the fault cause persisted long enough to consider that a required transport function cannot be performed. The item may be considered as failed; a fault has now been detected. See also [ITU-T_G.806]. A failure can be used as a trigger for corrective actions.
障害は検出された障害です。障害の原因が、必要なトランスポート機能を実行できないと見なすのに十分長い間続くと、障害が宣言されます。アイテムは失敗したと見なされます。障害が検出されました。 [ITU-T_G.806]も参照してください。障害は、修正アクションのトリガーとして使用できます。
A fault is the inability of a transport function to perform a required action. This does not include an inability due to preventive maintenance, lack of external resources, or planned actions. See also [ITU-T_G.806].
障害は、トランスポート機能が必要なアクションを実行できないことです。これには、予防保守、外部リソースの不足、または計画されたアクションによる障害は含まれません。 [ITU-T_G.806]も参照してください。
"Layer network" is defined in [ITU-T_G.805]. 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. For additional explanation of how layer networks relate to the OSI concept of layering, see Appendix I of [ITU-T_Y.2611].
「レイヤーネットワーク」は[ITU-T_G.805]で定義されています。レイヤネットワークは、クライアント情報の転送とクライアントOAMの独立した操作を提供します。レイヤネットワークは、サービスコンテキストで次のように説明できます。1つのレイヤネットワークは、上位のクライアントレイヤネットワークに（トランスポート）サービスを提供し、下位レイヤのネットワークのクライアントになる場合があります。レイヤーネットワークは、物理的なネットワーク要素の配置や構成からある程度独立した論理的な構造です。特定の物理ネットワーク要素は、論理レイヤー（ラベルスタックなど）に関連付けられたカプセル化で実行されるアクションに応じて、トポロジ的に複数のレイヤーネットワークに属し、複数の論理エレメントとしてモデル化できます。レイヤーネットワークは、1つ以上のサブレイヤーで構成されます。レイヤーネットワークがOSIのレイヤー化の概念とどのように関連するかについては、[ITU-T_Y.2611]の付録Iを参照してください。
A link as discussed in this document refers to a physical or logical connection between a pair of Label Switching Routers (LSRs) that are adjacent at the (sub)layer network under consideration. A link may carry zero, one, or more LSPs or PWs. A packet entering a link will emerge with the same label-stack entry values.
このドキュメントで説明するリンクは、検討中の（サブ）レイヤーネットワークで隣接しているラベルスイッチングルーター（LSR）のペア間の物理的または論理的な接続を指します。リンクは、0、1、またはそれ以上のLSPまたはPWを伝送できます。リンクに入るパケットは、同じラベルスタックエントリ値で出現します。
A link as defined in [ITU-T_G.805] is used to describe a fixed relationship between two ports.
[ITU-T_G.805]で定義されているリンクは、2つのポート間の固定関係を記述するために使用されます。
A Maintenance Entity (ME) can be viewed as the association of two (or more) Maintenance Entity Group End Points (MEPs) that should be configured and managed in order to bound the OAM responsibilities of an OAM flow across a network or sub-network, i.e., a transport path or segment in the specific layer network that is being monitored and managed. See also Section 3.1 of [RFC6371] and Clause 6.1 of [ITU-T_G.8113.1] and [ITU-T_G.8113.2].
メンテナンスエンティティ（ME）は、ネットワークまたはサブネットワーク全体のOAMフローのOAM責任をバインドするために構成および管理する必要がある2つ（またはそれ以上）のメンテナンスエンティティグループエンドポイント（MEP）の関連付けと見なすことができます。 、つまり、監視および管理されている特定のレイヤネットワークのトランスポートパスまたはセグメント。 [RFC6371]のセクション3.1、[ITU-T_G.8113.1]の句6.1、および[ITU-T_G.8113.2]も参照してください。
A Maintenance Entity may be defined to monitor and manage bidirectional or unidirectional point-to-point connectivity or point-to-multipoint connectivity in an MPLS-TP layer network.
メンテナンスエンティティは、MPLS-TPレイヤーネットワークで双方向または単方向のポイントツーポイント接続またはポイントツーマルチポイント接続を監視および管理するように定義できます。
Therefore, in the context of an MPLS-TP LSP ME or PW ME, Label Edge Routers (LERs) and PW Terminating Provider Edges (T-PEs) can be MEPs, while LSRs and PW Switching Provider Edges (S-PEs) can be MIPs. In the case of an ME for a tandem connection, LSRs and S-PEs can be either MEPs or MIPs.
したがって、MPLS-TP LSP MEまたはPW MEのコンテキストでは、ラベルエッジルーター（LER）およびPWターミネーションプロバイダーエッジ（T-PE）をMEPにでき、LSRおよびPWスイッチングプロバイダーエッジ（S-PE）をMEPにできます。 MIP。タンデム接続のMEの場合、LSRおよびS-PEはMEPまたはMIPのいずれかになります。
The following properties apply to all MPLS-TP MEs:
次のプロパティは、すべてのMPLS-TP MEに適用されます。
- OAM entities can be nested but not overlapped.
- OAMエンティティはネストできますが、オーバーラップできません。
- Each OAM flow is associated with a unique Maintenance Entity.
- 各OAMフローは、一意のメンテナンスエンティティに関連付けられています。
- OAM packets are subject to the same forwarding treatment as the data traffic, but they are distinct from the data traffic by the Generic Associated Channel Label (GAL).
- OAMパケットは、データトラフィックと同じ転送処理の対象となりますが、Generic Associated Channel Label（GAL）によってデータトラフィックとは異なります。
A Maintenance Entity Group is defined, for the purpose of connection monitoring, between a set of connection points within a connection. This set of connection points may be located at the boundary of one administrative domain or a protection domain or the boundaries of two adjacent administrative domains. The MEG may consist of one or more Maintenance Entities (MEs). See also Section 3.1 of [RFC6371] and Clause 6.2 of [ITU-T_G.8113.1] and [ITU-T_G.8113.2].
メンテナンスエンティティグループは、接続監視のために、接続内の一連の接続ポイント間で定義されます。この接続ポイントのセットは、1つの管理ドメインまたは保護ドメインの境界、または2つの隣接する管理ドメインの境界に配置できます。 MEGは、1つ以上のメンテナンスエンティティ（ME）で構成されます。 [RFC6371]のセクション3.1、[ITU-T_G.8113.1]の6.2項、および[ITU-T_G.8113.2]も参照してください。
In an MPLS-TP layer network, a MEG consists of only one ME.
MPLS-TP層ネットワークでは、MEGは1つのMEのみで構成されます。
Maintenance Entity Group End Points (MEPs) are the end points of a pre-configured (through the management or control planes) ME. MEPs are responsible for activating and controlling all of the OAM functionality for the ME. A source MEP may initiate an OAM packet to be transferred to its corresponding peer MEP (called the sink MEP) or to an intermediate MIP that is part of the ME. See also Section 3.3 of [RFC6371] and Clause 6.3 of [ITU-T_G.8113.1] and [ITU-T_G.8113.2].
メンテナンスエンティティグループのエンドポイント（MEP）は、（管理またはコントロールプレーンを介して）事前に構成されたMEのエンドポイントです。 MEPは、MEのすべてのOAM機能のアクティブ化と制御を担当します。ソースMEPは、対応するピアMEP（シンクMEPと呼ばれる）またはMEの一部である中間MIPに転送されるOAMパケットを開始できます。 [RFC6371]のセクション3.3、[ITU-T_G.8113.1]の句6.3、および[ITU-T_G.8113.2]も参照してください。
A sink MEP terminates all the OAM packets that it receives corresponding to its ME and does not forward them further along the path.
シンクMEPは、MEに対応して受信したすべてのOAMパケットを終了し、パスに沿ってそれ以上転送しません。
All OAM packets coming into a source MEP are tunneled via label stacking and are not processed within the ME as they belong either to the client network layers or to a higher Tandem Connection Monitoring (TCM) level.
ソースMEPに着信するすべてのOAMパケットは、ラベルスタッキングを介してトンネリングされ、クライアントネットワークレイヤーまたはより高いタンデム接続モニタリング（TCM）レベルに属するため、ME内では処理されません。
A MEP in a tandem connection is not coincident with the termination of the MPLS-TP transport path (LSP or PW), though it can monitor its connectivity (e.g., counts packets). A MEP of an MPLS-TP network transport path is coincident with transport path termination and monitors its connectivity (e.g., counts packets).
タンデム接続のMEPは、MPLS-TPトランスポートパス（LSPまたはPW）の終端と一致していませんが、接続を監視できます（パケットのカウントなど）。 MPLS-TPネットワークトランスポートパスのMEPは、トランスポートパスの終端と一致し、その接続を監視します（パケットのカウントなど）。
An MPLS-TP sink MEP can notify a fault condition to its MPLS-TP client-layer network.
MPLS-TPシンクMEPは、MPLS-TPクライアント層ネットワークに障害状態を通知できます。
A Maintenance Entity Group Intermediate Point (MIP) is a point between the two MEPs in an ME and is capable of responding to some OAM packets and forwarding all OAM packets while ensuring fate sharing with data-plane packets. A MIP responds only to OAM packets that are sent on the ME it belongs to and that are addressed to the MIP; it does not initiate OAM messages. See also Section 3.4 of [RFC6371] and Clause 6.4 of [ITU-T_G.8113.1] and [ITU-T_G.8113.2].
メンテナンスエンティティグループ中間ポイント（MIP）は、ME内の2つのMEP間のポイントであり、データプレーンパケットとの運命の共有を確保しながら、一部のOAMパケットに応答し、すべてのOAMパケットを転送できます。 MIPは、所属するMEで送信され、MIPにアドレス指定されたOAMパケットにのみ応答します。 OAMメッセージは開始されません。 [RFC6371]のセクション3.4、[ITU-T_G.8113.1]の句6.4、および[ITU-T_G.8113.2]も参照してください。
A Communication Channel dedicated to management-plane communications is referred to as a Management Communication Channel (MCC).
管理プレーン通信専用の通信チャネルは、管理通信チャネル（MCC）と呼ばれます。
A DCN supporting management-plane communication is referred to as a Management Communication Network (MCN).
管理プレーン通信をサポートするDCNは、管理通信ネットワーク（MCN）と呼ばれます。
Monitoring is applying OAM functionality to verify and to maintain the performance and the quality guarantees of a transport path. There is a need to not only monitor the whole transport path (e.g., LSP or MS-PW), but also arbitrary parts of transport paths. The connection between any two arbitrary points along a transport path is described in one of three ways:
監視では、OAM機能を適用して、トランスポートパスのパフォーマンスと品質の保証を確認および維持します。トランスポートパス全体（LSPやMS-PWなど）だけでなく、トランスポートパスの任意の部分も監視する必要があります。トランスポートパスに沿った任意の2つのポイント間の接続は、次の3つの方法のいずれかで説明されます。
- as a Path Segment Tunnel,
- パスセグメントトンネルとして
- as a Sub-Path Maintenance Element, or
- サブパスメンテナンス要素として、または
- as a Tandem Connection.
- タンデム接続として。
A path segment is either a segment or a concatenated segment. Path Segment Tunnels (PSTs) are instantiated to provide monitoring of a portion of a set of co-routed transport paths (LSPs or MS-PWs). PSTs can also be employed to meet the requirement to provide Tandem Connection Monitoring. See "Tandem Connection" (Section 3.23.3).
パスセグメントは、セグメントまたは連結セグメントです。パスセグメントトンネル（PST）はインスタンス化され、一連の共同ルーティングされたトランスポートパス（LSPまたはMS-PW）の一部を監視します。 PSTは、タンデム接続モニタリングを提供するための要件を満たすために使用することもできます。 「タンデム接続」（3.23.3項）を参照してください。
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 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. A P router only pushes or pops a label if it is at the end of an SPME. In this mode, it is an LER for the SPME.
SPMEは、LSPの監視、保護、または管理が必要な部分のエッジ間に定義されます。 SPMEは、ネットワークのこの部分を介してクライアントとして元のLSPを伝送するMPLS-TPセクションを形成します。 OAMメッセージは、SPMEのエッジで開始し、SPMEのピアエッジまたはSPMEに沿ったMIPに送信できます。 Pルーターは、ラベルがSPMEの最後にある場合にのみ、ラベルをプッシュまたはポップします。このモードでは、SPMEのLERです。
A tandem connection is an arbitrary part of a transport path that can be monitored (via OAM) independently from the end-to-end monitoring (OAM). It may be a monitored segment, a monitored concatenated segment, or any other monitored ordered sequence of contiguous hops and/or segments (and their interconnecting nodes) of a transport path.
タンデム接続は、エンドツーエンド監視（OAM）とは独立して（OAM経由で）監視できるトランスポートパスの任意の部分です。これは、監視対象のセグメント、監視対象の連結セグメント、またはトランスポートパスの隣接するホップやセグメント（およびそれらの相互接続ノード）のその他の監視対象の順序付けられたシーケンスである場合があります。
Tandem Connection Monitoring (TCM) for a given path segment of a transport path is implemented by creating a Path Segment Tunnel that has a 1:1 association with the path segment of the transport path that is to be uniquely monitored. This means that the PST used to provide TCM can carry one and only one transport path, thus allowing direct correlation between all fault-management and performance-monitoring information gathered for the PST and the monitored path segment of the end-to-end transport path. The PST is monitored using normal LSP monitoring. See also Section 3.2 of [RFC6371] and Clause 6.2.1 of [ITU-T_G.8113.1] and [ITU-T_G.8113.2].
トランスポートパスの特定のパスセグメントのタンデム接続監視（TCM）は、一意に監視されるトランスポートパスのパスセグメントと1：1の関連付けを持つパスセグメントトンネルを作成することによって実装されます。つまり、TCMを提供するために使用されるPSTは1つだけのトランスポートパスを伝送できるため、PSTについて収集されたすべての障害管理およびパフォーマンス監視情報と、エンドツーエンドのトランスポートパスの監視対象パスセグメントとを直接相関させることができます。 PSTは、通常のLSP監視を使用して監視されます。 [RFC6371]のセクション3.2、[ITU-T_G.8113.1]の6.2.1項、および[ITU-T_G.8113.2]も参照してください。
An MPLS Section is a network segment between two LSRs that are immediately adjacent at the MPLS layer.
MPLSセクションは、MPLS層で直接隣接する2つのLSR間のネットワークセグメントです。
An MPLS Transport Profile refers to the set of MPLS functions used to support packet transport services and network operations.
MPLSトランスポートプロファイルは、パケットトランスポートサービスとネットワーク操作をサポートするために使用されるMPLS機能のセットを指します。
A network element (NE) that supports MPLS-TP functions is referred to as an MPLS-TP NE.
MPLS-TP機能をサポートするネットワーク要素（NE）は、MPLS-TP NEと呼ばれます。
An MPLS-TP network is a network in which MPLS-TP NEs are deployed.
MPLS-TPネットワークは、MPLS-TP NEが展開されているネットワークです。
MPLS-TP end-to-end recovery refers to the recovery of an entire LSP, from its ingress to its egress node.
MPLS-TPエンドツーエンドリカバリとは、入力ノードから出力ノードまでのLSP全体のリカバリを指します。
MPLS-TP link recovery refers to the recovery of an individual link (and hence all or a subset of the LSPs routed over the link) between two MPLS-TP nodes. For example, link recovery may be provided by server-layer recovery.
MPLS-TPリンクの回復とは、2つのMPLS-TPノード間の個々のリンク（したがって、リンクを介してルーティングされるLSPのすべてまたはサブセット）の回復を指します。たとえば、リンク回復はサーバー層回復によって提供されるかもしれません。
MPLS-TP segment recovery refers to the recovery of an LSP segment (i.e., segment and concatenated segment) between two nodes and is used to recover from the failure of one or more links or nodes.
MPLS-TPセグメント回復は、2つのノード間のLSPセグメント（つまり、セグメントと連結セグメント）の回復を指し、1つ以上のリンクまたはノードの障害からの回復に使用されます。
An LSP segment comprises one or more contiguous hops on the path of the LSP. [RFC5654] defines two terms: a "segment" is a single hop along the path of an LSP, while a "concatenated segment" is more than one hop along the path of an LSP.
LSPセグメントは、LSPのパス上の1つ以上の連続したホップで構成されます。 [RFC5654]は2つの用語を定義します。「セグメント」はLSPのパスに沿った単一のホップであり、「連結セグメント」はLSPのパスに沿った複数のホップです。
In an MPLS-TP ring topology, each LSR is connected to exactly two other LSRs, each via a single point-to-point bidirectional MPLS-TP capable link. A ring may also be constructed from only two LSRs where there are also exactly two links. Rings may be connected to other LSRs to form a larger network. Traffic originating or terminating outside the ring may be carried over the ring. Client network nodes (such as Customer Edges (CEs)) may be connected directly to an LSR in the ring.
MPLS-TPリングトポロジでは、各LSRは、それぞれ1つのポイントツーポイント双方向MPLS-TP対応リンクを介して、他の2つのLSRに接続されます。リングは、2つのLSRだけで構成することもできます。リングを他のLSRに接続して、より大きなネットワークを形成できます。リングの外で発信または終了するトラフィックは、リングを介して伝送されます。クライアントネットワークノード（カスタマーエッジ（CE）など）は、リング内のLSRに直接接続できます。
An MPLS-TP logical ring is constructed from a set of LSRs and logical data links (such as MPLS-TP LSP tunnels or MPLS-TP pseudowires) and physical data links that form a ring topology.
MPLS-TP論理リングは、LSRのセットと論理データリンク（MPLS-TP LSPトンネルやMPLS-TP疑似配線など）、およびリングトポロジを形成する物理データリンクから構成されます。
An MPLS-TP physical ring is constructed from a set of LSRs and physical data links that form a ring topology.
MPLS-TP物理リングは、LSRのセットとリングトポロジを形成する物理データリンクから構成されます。
An OAM flow is the set of all OAM packets originating with a specific source MEP that measure the performance of one direction of a MEG (or possibly both in the special case of data-plane loopback).
OAMフローは、MEGの1方向（またはデータプレーンループバックの特殊なケースでは両方）のパフォーマンスを測定する特定のソースMEPで発生するすべてのOAMパケットのセットです。
An OSS is a system that performs the functions that support processing of information related to Operations, Administration, Maintenance, and Provisioning (OAM&P) for the networks, including surveillance and testing functions to support customer access maintenance.
OSSは、ネットワークの運用、管理、保守、プロビジョニング（OAM＆P）に関連する情報の処理をサポートする機能を実行するシステムです。これには、顧客アクセスの保守をサポートする監視およびテスト機能が含まれます。
See "Transport Path" (Section 3.45).
「トランスポートパス」（3.45節）を参照してください。
Fault conditions (e.g., signal failed), external commands (e.g, forced switch, manual switch), and protection states (e.g., no request) are defined to have a relative priority with respect to each other. Priority is applied to these conditions/command/states locally at each end point and between the two end points.
障害状態（信号の障害など）、外部コマンド（強制切り替え、手動切り替えなど）、および保護状態（要求なしなど）は、互いに対して相対的な優先順位を持つように定義されています。優先度は、これらの条件/コマンド/状態に、各エンドポイントでローカルに、および2つのエンドポイント間で適用されます。
A section layer is a server layer (which may be MPLS-TP or a different technology) that provides for the transfer of the section-layer client information between adjacent nodes in the transport-path layer or transport-service layer. A section layer may provide for aggregation of multiple MPLS-TP clients. Note that [ITU-T_G.805] defines the section layer as one of the two layer networks in a transmission-media-layer network. The other layer network is the physical-media-layer network.
セクションレイヤーは、トランスポートパスレイヤーまたはトランスポートサービスレイヤーの隣接ノード間でセクションレイヤークライアント情報の転送を提供するサーバーレイヤー（MPLS-TPまたは別のテクノロジの場合があります）です。セクション層は、複数のMPLS-TPクライアントの集約を提供する場合があります。 [ITU-T_G.805]は、セクションメディアを伝送メディアレイヤーネットワークの2つのレイヤーネットワークの1つとして定義することに注意してください。もう1つの層のネットワークは、物理メディア層のネットワークです。
Section-layer networks are concerned with all the functions that provide for the transfer of information between locations in path-layer networks.
セクションレイヤーネットワークは、パスレイヤーネットワーク内のロケーション間での情報の転送を提供するすべての機能に関係しています。
Physical-media-layer networks are concerned with the actual fibers, metallic wires, or radio frequency channels that support a section-layer network.
物理メディア層ネットワークは、セクション層ネットワークをサポートする実際のファイバー、金属線、または無線周波数チャネルに関係しています。
A segment is a link connection as defined in [ITU-T_G.805]. A segment is the part of an LSP that traverses a single link or the part of a PW that traverses a single link (i.e., that connects a pair of adjacent S-PEs and/or T-PEs). See also "Concatenated Segment" (Section 3.5).
セグメントは、[ITU-T_G.805]で定義されているリンク接続です。セグメントは、単一のリンクを通過するLSPの一部、または単一のリンクを通過する（つまり、隣接するS-PEやT-PEのペアを接続する）PWの一部です。 「連結セグメント」（セクション3.5）も参照してください。
A server layer is a layer network in which transport paths are used to carry a customer's (individual or bundled) service (may be point-to-point, point-to-multipoint, or multipoint-to-multipoint services).
サーバーレイヤーは、顧客の（個別またはバンドルされた）サービス（ポイントツーポイント、ポイントツーマルチポイント、またはマルチポイントツーマルチポイントサービス）を伝送するためにトランスポートパスが使用されるレイヤーネットワークです。
In a client/server relationship (see [ITU-T_G.805]), the server-layer network provides a (transport) service to the higher client-layer network (usually the layer network under consideration).
クライアント/サーバー関係（[ITU-T_G.805]を参照）では、サーバー層ネットワークが上位のクライアント層ネットワーク（通常、検討中の層ネットワーク）に（トランスポート）サービスを提供します。
A server MEP is a MEP of an ME that is defined in a layer network below the MPLS-TP layer network being referenced. A server MEP coincides with either a MIP or a MEP in the client-layer (MPLS-TP) network. See also Section 3.5 of [RFC6371] and Clause 6.5 of [ITU-T_G.8113.1].
サーバーMEPは、参照されるMPLS-TPレイヤーネットワークの下のレイヤーネットワークで定義されるMEのMEPです。サーバーMEPは、クライアント層（MPLS-TP）ネットワークのMIPまたはMEPと一致します。 [RFC6371]のセクション3.5と[ITU-T_G.8113.1]の6.5項もご覧ください。
For example, a server MEP can be one of the following:
たとえば、サーバーMEPは次のいずれかになります。
o A termination point of a physical link (e.g., IEEE 802.3), an SDH Virtual Circuit (VC), or OTN Optical Data Unit (ODU) for the MPLS-TP Section layer network, defined in [RFC6371], Section 4.1;
o [RFC6371]のセクション4.1で定義されている、MPLS-TPセクションレイヤーネットワークの物理リンク（IEEE 802.3など）、SDH仮想回路（VC）、またはOTN光データユニット（ODU）の終端ポイント。
o An MPLS-TP Section MEP for MPLS-TP LSPs, defined in [RFC6371], Section 4.2;
o [RFC6371]のセクション4.2で定義されているMPLS-TP LSPのMPLS-TPセクションMEP。
o An MPLS-TP LSP MEP for MPLS-TP PWs, defined in [RFC6371], Section 4.3; or
o [RFC6371]のセクション4.3で定義されているMPLS-TP PWのMPLS-TP LSP MEP。または
o An MPLS-TP TCM MEP for higher-level TCMs, defined in [RFC6371], Section 3.2.
o [RFC6371]のセクション3.2で定義されている、上位レベルのTCM用のMPLS-TP TCM MEP。
The server MEP can run appropriate OAM functions for fault detection and notifies a fault indication to the MPLS-TP layer network.
サーバーMEPは、障害検出のために適切なOAM機能を実行し、MPLS-TPレイヤーネットワークに障害表示を通知します。
A Signaling Communication Channel is a Communication Channel dedicated to control-plane communications. The SCC may be used for GMPLS / Automatically Switched Optical Network (ASON) signaling and/or other control-plane messages (e.g., routing messages).
シグナリング通信チャネルは、コントロールプレーン通信専用の通信チャネルです。 SCCは、GMPLS /自動スイッチ光ネットワーク（ASON）シグナリングおよび/またはその他のコントロールプレーンメッセージ（ルーティングメッセージなど）に使用できます。
A DCN supporting control-plane communication is referred to as a Signaling Communication Network (SCN).
コントロールプレーン通信をサポートするDCNは、Signaling Communication Network（SCN）と呼ばれます。
A span is synonymous with a link.
スパンはリンクと同義です。
"Sublayer" is defined in [ITU-T_G.805]. The distinction between a layer network and a sublayer is that a sublayer is not directly accessible to clients outside of its encapsulating layer network and offers no direct transport service for a higher-layer (client) network.
「サブレイヤー」は、[ITU-T_G.805]で定義されています。レイヤーネットワークとサブレイヤーの違いは、サブレイヤーはカプセル化レイヤーネットワークの外部のクライアントから直接アクセスできず、上位レイヤー（クライアント）ネットワークに直接転送サービスを提供しないことです。
A transport entity is a node, link, transport path segment, concatenated transport path segment, or entire transport path.
トランスポートエンティティは、ノード、リンク、トランスポートパスセグメント、連結トランスポートパスセグメント、またはトランスポートパス全体です。
A working entity is a transport entity that carries traffic during normal network operation.
動作中のエンティティは、通常のネットワーク操作中にトラフィックを運ぶトランスポートエンティティです。
A protection entity is a transport entity that is pre-allocated and used to protect and transport traffic when the working entity fails.
保護エンティティは、事前に割り当てられたトランスポートエンティティであり、稼働エンティティに障害が発生したときにトラフィックを保護およびトランスポートするために使用されます。
A recovery entity is a transport entity that is used to recover and transport traffic when the working entity fails.
リカバリエンティティは、動作中のエンティティに障害が発生したときにトラフィックをリカバリして転送するために使用されるトランスポートエンティティです。
A transmission media layer is a layer network, consisting of a section-layer network and a physical-layer network as defined in [ITU-T_G.805], that provides sections (two-port point-to-point connections) to carry the aggregate of network-transport path or network-service layers on various physical media.
伝送メディア層は、[ITU-T_G.805]で定義されているセクション層ネットワークと物理層ネットワークで構成される層ネットワークであり、セクション（2ポートのポイントツーポイント接続）を提供して、さまざまな物理メディア上のネットワーク転送パスまたはネットワークサービスレイヤーの集合体。
A Transport Network provides transmission of traffic between attached client devices by establishing and maintaining point-to-point or point-to-multipoint connections between such devices. 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 OAM functions.
トランスポートネットワークは、接続されたクライアントデバイス間のポイントツーポイントまたはポイントツーマルチポイント接続を確立および維持することにより、接続されたクライアントデバイス間のトラフィックの伝送を提供します。トランスポートネットワークは、この伝送サービスを提供するために必要な範囲を除いて、クライアント間に存在する可能性のある上位層ネットワークから独立しています。トランスポートネットワークは、クライアントトラフィックに加えて、接続制御、ネットワーク管理、OAM機能をサポートするために必要なトラフィックなど、独自の操作を容易にするためにトラフィックを運ぶ場合があります。
A transport path is a network connection as defined in [ITU-T_G.805]. In an MPLS-TP environment, a transport path corresponds to an LSP or a PW.
トランスポートパスは、[ITU-T_G.805]で定義されているネットワーク接続です。 MPLS-TP環境では、トランスポートパスはLSPまたはPWに対応します。
A transport-path layer is a (sub)layer network that provides point-to-point or point-to-multipoint transport paths. It provides OAM that is independent of the clients that it is transporting.
トランスポートパスレイヤーは、ポイントツーポイントまたはポイントツーマルチポイントのトランスポートパスを提供する（サブ）レイヤーネットワークです。トランスポートするクライアントから独立したOAMを提供します。
A transport-service layer is a layer network in which transport paths are used to carry a customer's (individual or bundled) service (may be point-to-point, point-to-multipoint, or multipoint-to-multipoint services).
トランスポートサービスレイヤーは、顧客の（個別またはバンドルされた）サービス（ポイントツーポイント、ポイントツーマルチポイント、またはマルチポイントツーマルチポイントサービス）を運ぶためにトランスポートパスが使用されるレイヤーネットワークです。
A unidirectional path is a path that supports traffic flow in only one direction.
単方向パスは、一方向のみのトラフィックフローをサポートするパスです。
As discussed in the introduction to this document, this thesaurus is intended to bring the concepts and terms associated with MPLS-TP into the context of the ITU-T's Transport Network architecture. Thus, it should help those familiar with MPLS to see how they may use the features and functions of the Transport Network in order to meet the requirements of MPLS-TP.
このドキュメントの概要で説明したように、このシソーラスは、MPLS-TPに関連する概念と用語をITU-Tのトランスポートネットワークアーキテクチャのコンテキストに組み込むことを目的としています。したがって、MPLS-TPの要件を満たすために、MPLSに精通しているユーザーがトランスポートネットワークの機能を使用する方法を理解するのに役立ちます。
Networks based on MPLS-TP require management. The MPLS-TP specifications described in [RFC5654], [RFC5860], [RFC5921], [RFC5951], [RFC6371], [RFC6372], [ITU-T_G.8110.1], and [ITU-T_G.7710] include considerable efforts to provide operator control and monitoring as well as OAM functionality.
MPLS-TPに基づくネットワークには管理が必要です。 [RFC5654]、[RFC5860]、[RFC5921]、[RFC5951]、[RFC6371]、[RFC6372]、[ITU-T_G.8110.1]、および[ITU-T_G.7710]で説明されているMPLS-TP仕様には、かなりの努力が含まれていますオペレーターによる制御と監視、およびOAM機能を提供します。
These concepts are, however, out of the scope of this document.
ただし、これらの概念はこのドキュメントの範囲外です。
Security is a significant requirement of MPLS-TP. See [RFC6941] for more information.
セキュリティは、MPLS-TPの重要な要件です。詳細については、[RFC6941]を参照してください。
However, this informational document is intended only to provide a lexicography, and the security concerns are, therefore, out of the scope of this document.
ただし、この情報ドキュメントは辞書編集を提供することのみを目的としているため、セキュリティ上の懸念はこのドキュメントの範囲外です。
The authors would like to thank all members of the teams (the Joint Working Team, the MPLS Interoperability Design Team in the IETF, and the MPLS-TP Ad Hoc Group in the ITU-T) involved in the definition and specification of the MPLS Transport Profile. We would in particular like to acknowledge the contributions by Tom Petch to improve the quality of this document. Abdussalam Baryun also reviewed this document.
著者は、MPLSトランスポートの定義と仕様に関係するチーム（ジョイントワーキングチーム、IETFのMPLS相互運用設計チーム、およびITU-TのMPLS-TPアドホックグループ）のすべてのメンバーに感謝します。プロフィール。特に、このドキュメントの品質を向上させるためのTom Petchの貢献に感謝します。 Abdussalam Baryunもこのドキュメントをレビューしました。
The following individuals contributed to this document: Italo Busi, Ben Niven-Jenkins, Enrique Hernandez-Valencia, Lieven Levrau, Dinesh Mohan, Stewart Bryant, Dan Frost, Matthew Bocci, Vincenzo Sestito, Martin Vigoureux, and Yaacov Weingarten.
次の個人がこのドキュメントに貢献しました：Italo Busi、Ben Niven-Jenkins、Enrique Hernandez-Valencia、Lieven Levrau、Dinesh Mohan、Stewart Bryant、Dan Frost、Matthew Bocci、Vincenzo Sestito、Martin Vigoureux、およびYaacov Weingarten。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E。、ヴィスワナサン、A。、およびR.キャロン、「マルチプロトコルラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[RFC5654] Niven-Jenkins、B.、Ed。、Brungard、D.、Ed。、Betts、M.、Ed。、Sprecher、N.、and S. Ueno、 "Requirements of an MPLS Transport Profile"、RFC 5654 、2009年9月。
[RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010.
[RFC5860] Vigoureux、M.、Ed。、Ward、D.、Ed。、and M. Betts、Ed。、 "Requirements for Operations、Administration、and Maintenance（OAM）in MPLS Transport Networks"、RFC 5860、May 2010 。
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
[RFC5921] Bocci、M.、Ed。、Bryant、S.、Ed。、Frost、D.、Ed。、Levrau、L.、and L. Berger、 "A Framework for MPLS in Transport Networks"、RFC 5921、 2010年7月。
[RFC5951] Lam, K., Mansfield, S., and E. Gray, "Network Management Requirements for MPLS-based Transport Networks", RFC 5951, September 2010.
[RFC5951]ラム、K。、マンスフィールド、S。、およびE.グレイ、「MPLSベースのトランスポートネットワークのネットワーク管理要件」、RFC 5951、2010年9月。
[RFC6371] Busi, I., Ed., and D. Allan, Ed., "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011.
[RFC6371] Busi、I.、Ed。およびD. Allan、Ed。、「Operations、Administration、and Maintenance Framework for MPLS-Based Transport Networks」、RFC 6371、2011年9月。
[RFC6372] Sprecher, N., Ed., and A. Farrel, Ed., "MPLS Transport Profile (MPLS-TP) Survivability Framework", RFC 6372, September 2011.
[RFC6372] Sprecher、N.、Ed。、and A. Farrel、Ed。、 "MPLS Transport Profile（MPLS-TP）Survivability Framework"、RFC 6372、September 2011。
[ITU-T_G.805] ITU-T Recommendation G.805, "Generic functional architecture of transport networks", March 2000, <http://www.itu.int/rec/T-REC/>.
[ITU-T_G.805] ITU-T勧告G.805、「トランスポートネットワークの汎用機能アーキテクチャ」、2000年3月、<http://www.itu.int/rec/T-REC/>。
[ITU-T_G.806] ITU-T Recommendation G.806, "Characteristics of transport equipment - Description methodology and generic functionality", March 2006, <http://www.itu.int/rec/T-REC/>.
[ITU-T_G.806] ITU-T勧告G.806、「輸送機器の特性-記述方法論および一般的な機能」、2006年3月、<http://www.itu.int/rec/T-REC/>。
[ITU-T_G.872] ITU-T Recommendation G.872, "Architecture of optical transport networks", November 2001, <http://www.itu.int/rec/T-REC/>.
[ITU-T_G.872] ITU-T勧告G.872、「Architecture of Optical Transport Networks」、2001年11月、<http://www.itu.int/rec/T-REC/>。
[ITU-T_G.7710] ITU-T Recommendation G.7710, "Common equipment management function requirements", July 2007, <http://www.itu.int/rec/T-REC/>.
[ITU-T_G.7710] ITU-T勧告G.7710、「Common Equipment Management Function Requirements」、2007年7月、<http://www.itu.int/rec/T-REC/>。
[ITU-T_G.8101] ITU-T Recommendation G.8101/Y.1355, "Terms and definitions for MPLS Transport Profile", September 2013, <http://www.itu.int/rec/T-REC/>.
[ITU-T_G.8101] ITU-T勧告G.8101 / Y.1355、「MPLSトランスポートプロファイルの用語と定義」、2013年9月、<http://www.itu.int/rec/T-REC/> 。
[ITU-T_G.8110.1] ITU-T Recommendation G.8110.1/Y.1370.1, "Architecture of the Multi-Protocol Label Switching transport profile layer network", December 2011, <http://www.itu.int/rec/T-REC/>.
[ITU-T_G.8110.1] ITU-T勧告G.8110.1 / Y.1370.1、「Architecture of the Multi-Protocol Label Switching Transport Profile Layer Network」、2011年12月、<http://www.itu.int/rec/ T-REC />。
[ITU-T_G.8113.1] ITU-T Recommendation G.8113.1/Y.1372.1, "Operations, administration and maintenance mechanism for MPLS-TP in packet transport network (PTN)", November 2012, <http://www.itu.int/rec/T-REC/>.
[ITU-T_G.8113.1] ITU-T勧告G.8113.1 / Y.1372.1、「パケット転送ネットワーク（PTN）におけるMPLS-TPの運用、管理、および保守メカニズム」、2012年11月、<http：//www.itu .int / rec / T-REC />。
[ITU-T_G.8113.2] ITU-T Recommendation G.8113.2/Y.1372.2, "Operations, administration and maintenance mechanisms for MPLS-TP networks using the tools defined for MPLS", November 2012, <http://www.itu.int/rec/T-REC/>.
[ITU-T_G.8113.2] ITU-T勧告G.8113.2 / Y.1372.2、「MPLS用に定義されたツールを使用したMPLS-TPネットワークの操作、管理、およびメンテナンスメカニズム」、2012年11月、<http：//www.itu .int / rec / T-REC />。
[ITU-T_Y.2611] ITU-T Recommendation Y.2611, "High-level architecture of future packet-based networks", December 2006, <http://www.itu.int/rec/T-REC/>.
[ITU-T_Y.2611] ITU-T勧告Y.2611、「将来のパケットベースネットワークの高レベルアーキテクチャ」、2006年12月、<http://www.itu.int/rec/T-REC/>。
[RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture", RFC 4397, February 2006.
[RFC4397] Bryskin、I。およびA. Farrel、「ITU-Tの自動スイッチ光ネットワーク（ASON）アーキテクチャーのコンテキスト内での一般化マルチプロトコルラベルスイッチング（GMPLS）用語の解釈のための辞書編集」、RFC 4397、2006年2月。
[RFC6941] Fang, L., Ed., Niven-Jenkins, B., Ed., Mansfield, S., Ed., and R. Graveman, Ed., "MPLS Transport Profile (MPLS-TP) Security Framework", RFC 6941, April 2013.
[RFC6941] Fang、L.、Ed。、Niven-Jenkins、B.、Ed。、Mansfield、S.、Ed。、and R. Graveman、Ed。、 "MPLS Transport Profile（MPLS-TP）Security Framework"、 RFC 6941、2013年4月。
Authors' Addresses
著者のアドレス
Huub van Helvoort (editor) Huawei Technologies Co., Ltd.
Huub van Helvoort（編集者）Huawei Technologies Co.、Ltd.
EMail: Huub.van.Helvoort@huawei.com
Loa Andersson (editor) Huawei Technologies Co., Ltd.
ロア・アンダーソン（編者）Huawei Technologies Co.、Ltd.
EMail: loa@mail01.huawei.com
Nurit Sprecher (editor) Nokia Solutions and Networks
Nurit Sprecher（編集者）Nokiaソリューションおよびネットワーク
EMail: nurit.sprecher@nsn.com