[要約] 要約：RFC 5951は、MPLSベースのトランスポートネットワークのネットワーク管理要件についてのガイドラインです。 目的：このRFCの目的は、MPLSベースのトランスポートネットワークの効果的なネットワーク管理を実現するための要件と手法を提供することです。
Internet Engineering Task Force (IETF) K. Lam
Request for Comments: 5951 Alcatel-Lucent
Category: Standards Track S. Mansfield
ISSN: 2070-1721 E. Gray
Ericsson
September 2010
Network Management Requirements for MPLS-based Transport Networks
MPLSベースの輸送ネットワークのネットワーク管理要件
Abstract
概要
This document specifies the requirements for the management of equipment used in networks supporting an MPLS Transport Profile (MPLS-TP). The requirements are defined for specification of network management aspects of protocol mechanisms and procedures that constitute the building blocks out of which the MPLS Transport Profile is constructed. That is, these requirements indicate what management capabilities need to be available in MPLS for use in managing the MPLS-TP. This document is intended to identify essential network management capabilities, not to specify what functions any particular MPLS implementation supports.
このドキュメントは、MPLS輸送プロファイル（MPLS-TP）をサポートするネットワークで使用される機器の管理の要件を指定します。要件は、MPLS輸送プロファイルが構築されている構成要素を構成するプロトコルメカニズムと手順のネットワーク管理の側面の仕様のために定義されています。つまり、これらの要件は、MPLS-TPの管理に使用するためにMPLSで利用できる管理機能を示しています。このドキュメントは、特定のMPLS実装サポートが機能する機能を指定するのではなく、必須のネットワーク管理機能を特定することを目的としています。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（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/rfc5951.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5951で取得できます。
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. Terminology ................................................5
2. Management Interface Requirements ...............................7
3. Management Communication Channel (MCC) Requirements .............7
4. Management Communication Network (MCN) Requirements .............7
5. Fault Management Requirements ...................................9
5.1. Supervision Function .......................................9
5.2. Validation Function .......................................10
5.3. Alarm Handling Function ...................................11
5.3.1. Alarm Severity Assignment ..........................11
5.3.2. Alarm Suppression ..................................11
5.3.3. Alarm Reporting ....................................11
5.3.4. Alarm Reporting Control ............................12
6. Configuration Management Requirements ..........................12
6.1. System Configuration ......................................12
6.2. Control Plane Configuration ...............................13
6.3. Path Configuration ........................................13
6.4. Protection Configuration ..................................14
6.5. OAM Configuration .........................................14
7. Performance Management Requirements ............................15
7.1. Path Characterization Performance Metrics .................15
7.2. Performance Measurement Instrumentation ...................16
7.2.1. Measurement Frequency ..............................16
7.2.2. Measurement Scope ..................................17
8. Security Management Requirements ...............................17
8.1. Management Communication Channel Security .................17
8.2. Signaling Communication Channel Security ..................18
8.3. Distributed Denial of Service .............................18
9. Security Considerations ........................................19
10. Acknowledgments ...............................................19
11. References ....................................................19
11.1. Normative References .....................................19
12.2. Informative References ...................................20
Appendix A. Communication Channel (CCh) Examples..................22
Contributor's Address .............................................24
This document specifies the requirements for the management of equipment used in networks supporting an MPLS Transport Profile (MPLS-TP). The requirements are defined for specification of network management aspects of protocol mechanisms and procedures that constitute the building blocks out of which the MPLS Transport Profile is constructed. That is, these requirements indicate what management capabilities need to be available in MPLS for use in managing the MPLS-TP. This document is intended to identify essential network management capabilities, not to specify what functions any particular MPLS implementation supports.
このドキュメントは、MPLS輸送プロファイル（MPLS-TP）をサポートするネットワークで使用される機器の管理の要件を指定します。要件は、MPLS輸送プロファイルが構築されている構成要素を構成するプロトコルメカニズムと手順のネットワーク管理の側面の仕様のために定義されています。つまり、これらの要件は、MPLS-TPの管理に使用するためにMPLSで利用できる管理機能を示しています。このドキュメントは、特定のMPLS実装サポートが機能する機能を指定するのではなく、必須のネットワーク管理機能を特定することを目的としています。
This document also leverages management requirements specified in ITU-T G.7710/Y.1701 [1] and RFC 4377 [2], and attempts to comply with the guidelines defined in RFC 5706 [15].
また、このドキュメントは、ITU-T G.7710/Y.1701 [1]およびRFC 4377 [2]で指定された管理要件を活用し、RFC 5706 [15]で定義されたガイドラインに準拠しようとします。
ITU-T G.7710/Y.1701 defines generic management requirements for transport networks. RFC 4377 specifies the operations and management requirements, including operations-and-management-related network management requirements, for MPLS networks.
ITU-T G.7710/Y.1701輸送ネットワークの一般的な管理要件を定義します。RFC 4377 MPLSネットワークの運用と管理関連のネットワーク管理要件を含む運用および管理要件を指定します。
This document is a product of a joint ITU-T and IETF effort to include an MPLS Transport Profile (MPLS-TP) within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support capabilities and functionality of a transport network as defined by the ITU-T.
このドキュメントは、IETF MPLS内にMPLSトランスポートプロファイル（MPLS-TP）を含めるためのITU-TとIETFの努力の製品であり、輸送ネットワークの機能と機能をサポートするために、エッジツーエッジ（PWE3）アーキテクチャの擬似ワイヤエミュレーションエッジ（PWE3）アーキテクチャITU-Tで定義されています。
The requirements in this document derive from two sources:
このドキュメントの要件は、2つのソースから派生しています。
1) MPLS and PWE3 architectures as defined by the IETF, and
1) IETFで定義されているMPLSおよびPWE3アーキテクチャ、および
2) packet transport networks as defined by the ITU-T.
2) ITU-Tで定義されているパケットトランスポートネットワーク。
Requirements for management of equipment in MPLS-TP networks are defined herein. Related functions of MPLS and PWE3 are defined elsewhere (and are out of scope in this document).
MPLS-TPネットワークの機器の管理の要件は、本明細書で定義されています。MPLSとPWE3の関連関数は他の場所で定義されています（このドキュメントでは範囲外です）。
This document expands on the requirements in ITU-T G.7710/Y.1701 [1] and RFC 4377 [2] to cover fault, configuration, performance, and security management for MPLS-TP networks, and the requirements for object and information models needed to manage MPLS-TP networks and network elements.
このドキュメントは、MPLS-TPネットワークの障害、構成、パフォーマンス、セキュリティ管理、およびオブジェクトと情報の要件をカバーするために、ITU-T G.7710/Y.1701 [1]およびRFC 4377 [2]の要件を拡張します。MPLS-TPネットワークとネットワーク要素を管理するために必要なモデル。
In writing this document, the authors assume the reader is familiar with RFCs 5921 [8] and 5950 [9].
この文書を書く際、著者は、読者がRFCS 5921 [8]および5950 [9]に精通していると想定しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [5]. Although this document is not a protocol specification, the use of this language clarifies the instructions to protocol designers producing solutions that satisfy the requirements set out in this document.
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [5]に記載されているように解釈される。このドキュメントはプロトコル仕様ではありませんが、この言語の使用は、このドキュメントで定められた要件を満たすソリューションを作成するプロトコル設計者への指示を明確にします。
Anomaly: The smallest discrepancy that can be observed between actual and desired characteristics of an item. The occurrence of a single anomaly does not constitute an interruption in ability to perform a required function. Anomalies are used as the input for the Performance Monitoring (PM) process and for detection of defects (from [21], Section 3.7).
異常：アイテムの実際の特性と望ましい特性の間に観察できる最小の矛盾。単一の異常の発生は、必要な関数を実行する能力の中断を構成するものではありません。異常は、パフォーマンス監視（PM）プロセスの入力として、および欠陥の検出のための入力として使用されます（[21]、セクション3.7）。
Communication Channel (CCh): A logical channel between network elements (NEs) that can be used (for example) for management or control plane applications. The physical channel supporting the CCh is technology specific. See Appendix A.
通信チャネル（CCH）：管理プレーンアプリケーションや制御プレーンアプリケーションに（たとえば）使用できるネットワーク要素（NES）間の論理チャネル。CCHをサポートする物理チャネルはテクノロジー固有です。付録Aを参照してください。
Data Communication Network (DCN): 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 signaling communications related to the control plane, and other operations communications (e.g., order-wire/voice communications, software downloads, etc.).
データ通信ネットワーク（DCN）：レイヤー1（物理レイヤー）、レイヤー2（データリンクレイヤー）、およびレイヤー3（ネットワークレイヤー）機能をサポートするネットワーク管理プレーンに関連する分散管理通信のための、分散シグナリング通信関連コントロールプレーン、およびその他の操作通信（例：注文/音声通信、ソフトウェアのダウンロードなど）。
Defect: 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, the control of consequent actions, and the determination of fault cause (from [21], Section 3.24).
欠陥：異常の密度は、必要な関数を実行する能力が中断されているレベルに達しました。欠陥は、パフォーマンス監視、結果としてのアクションの制御、および障害原因の決定の入力として使用されます（[21]、セクション3.24から）。
Failure: The fault cause persisted long enough to consider the ability of an item to perform a required function to be terminated. The item may be considered as failed; a fault has now been detected (from [21], Section 3.25).
障害：障害の原因は、必要な関数を実行する能力を終了する能力を考慮するのに十分な長さで持続しました。アイテムは失敗したと見なされる場合があります。現在、障害が検出されています（[21]、セクション3.25から）。
Fault: A fault is the inability of a function to perform a required action. This does not include an inability due to preventive maintenance, lack of external resources, or planned actions (from [21], Section 3.26).
障害：障害とは、必要なアクションを実行できないことです。これには、予防的なメンテナンス、外部リソースの不足、または計画されたアクションによる不能（[21]、セクション3.26）は含まれません。
Fault Cause: A single disturbance or fault may lead to the detection of multiple defects. A fault cause is the result of a correlation process that is intended to identify the defect that is representative of the disturbance or fault that is causing the problem (from [21], Section 3.27).
障害原因：単一の妨害または障害は、複数の欠陥の検出につながる可能性があります。障害の原因とは、問題を引き起こしている外乱または障害を表す欠陥を特定することを目的とした相関プロセスの結果です（[21]、セクション3.27から）。
Fault Cause Indication (FCI): An indication of a fault cause.
障害原因表示（FCI）：障害原因の表示。
Management Communication Channel (MCC): A CCh dedicated for management plane communications.
管理通信チャネル（MCC）：管理機コミュニケーション専用のCCH。
Management Communication Network (MCN): A DCN supporting management plane communication is referred to as a Management Communication Network (MCN).
管理通信ネットワーク（MCN）：管理機関通信をサポートするDCNは、管理通信ネットワーク（MCN）と呼ばれます。
MPLS-TP NE: A network element (NE) that supports the functions of MPLS necessary to participate in an MPLS-TP based transport service. See RFC 5645 [7] for further information on functionality required to support MPLS-TP.
MPLS-TP NE：MPLS-TPベースの輸送サービスに参加するために必要なMPLSの機能をサポートするネットワーク要素（NE）。MPLS-TPをサポートするために必要な機能の詳細については、RFC 5645 [7]を参照してください。
MPLS-TP network: a network in which MPLS-TP NEs are deployed.
MPLS-TPネットワーク：MPLS-TP NESが展開されるネットワーク。
Operations, Administration and Maintenance (OAM), On-Demand and Proactive: One feature of OAM that is largely a management issue is control of OAM; on-demand and proactive are modes of OAM mechanism operation defined in (for example) Y.1731 ([22] - Sections 3.45 and 3.44, respectively) as:
運用、管理およびメンテナンス（OAM）、オンデマンドおよびプロアクティブ：主に管理上の問題であるOAMの特徴の1つは、OAMの制御です。オンデマンドおよびプロアクティブは、（たとえば）Y.1731（[22] - セクション3.45および3.44）で定義されたOAMメカニズム操作のモードです。
o On-demand OAM - OAM actions that are initiated via manual intervention for a limited time to carry out diagnostics. On-demand OAM can result in singular or periodic OAM actions during the diagnostic time interval.
o オンデマンドOAM-診断を実行するために期間限定の手動介入によって開始されるOAMアクション。オンデマンドOAMは、診断時間間隔中に特異または定期的なOAMアクションをもたらす可能性があります。
o Proactive OAM - OAM actions that are carried on continuously to permit timely reporting of fault and/or performance status.
o プロアクティブなOAM-障害および/またはパフォーマンスステータスのタイムリーな報告を可能にするために継続的に実行されるOAMアクション。
(Note that it is possible for specific OAM mechanisms to only have a sensible use in either on-demand or proactive mode.)
（特定のOAMメカニズムは、オンデマンドモードまたはプロアクティブモードでのみ賢明な使用を行うことができることに注意してください。）
Operations System (OS): 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.
オペレーションシステム（OS）：顧客アクセスメンテナンスをサポートするための監視やテスト機能を含む、ネットワークの運用、管理、メンテナンス、およびプロビジョニング（OAM＆P）に関連する情報の処理をサポートする機能を実行するシステム。
Signaling Communication Channel (SCC): A CCh dedicated for control plane communications. The SCC can be used for GMPLS/ASON signaling and/or other control plane messages (e.g., routing messages).
シグナリング通信チャネル（SCC）：コントロールプレーン通信専用のCCH。SCCは、GMPLS/ASONシグナル伝達および/またはその他のコントロールプレーンメッセージ（ルーティングメッセージなど）に使用できます。
Signaling Communication Network (SCN): A DCN supporting control plane communication is referred to as a Signaling Communication Network (SCN).
シグナリング通信ネットワーク（SCN）：コントロールプレーン通信をサポートするDCNは、シグナリング通信ネットワーク（SCN）と呼ばれます。
This document does not specify a preferred management interface protocol to be used as the standard protocol for managing MPLS-TP networks. Managing an end-to-end connection across multiple operator domains where one domain is managed (for example) via NETCONF [16] or SNMP [17], and another domain via CORBA [18], is allowed.
このドキュメントでは、MPLS-TPネットワークを管理するための標準プロトコルとして使用する優先管理インターフェイスプロトコルを指定していません。NetConf [16]またはSNMP [17]を介して1つのドメイン（たとえば）およびCorba [18]を介した別のドメインを介して（たとえば）管理される複数の演算子ドメインでエンドツーエンド接続を管理することが許可されます。
1) For the management interface to the management system, an MPLS-TP NE MAY actively support more than one management protocol in any given deployment.
1) 管理システムへの管理インターフェイスの場合、MPLS-TP NEは、特定の展開で複数の管理プロトコルを積極的にサポートする場合があります。
For example, an operator can use one protocol for configuration of an MPLS-TP NE and another for monitoring. The protocols to be supported are at the discretion of the operator.
たとえば、オペレーターはMPLS-TP NEの構成に1つのプロトコルを使用し、監視に別のプロトコルを使用できます。サポートされるプロトコルは、オペレーターの裁量にあります。
1) Specifications SHOULD define support for management connectivity with remote MPLS-TP domains and NEs, as well as with termination points located in NEs under the control of a third party network operator. See ITU-T G.8601 [23] for example scenarios in multi-carrier, multi-transport technology environments.
1) 仕様は、リモートMPLS-TPドメインとNES、およびサードパーティネットワークオペレーターの制御下にあるNESにある終了ポイントとの管理接続のサポートを定義する必要があります。たとえば、マルチキャリア、マルチ輸送技術環境のシナリオなど、ITU-T G.8601 [23]を参照してください。
2) For management purposes, every MPLS-TP NE MUST connect to an OS. The connection MAY be direct (e.g., via a software, hardware, or proprietary protocol connection) or indirect (via another MPLS-TP NE). In this document, any management connection that is not via another MPLS-TP NE is a direct management connection. When an MPLS-TP NE is connected indirectly to an OS, an MCC MUST be supported between that MPLS-TP NE and any MPLS-TP NE(s) used to provide the connection to an OS.
2) 管理目的では、すべてのMPLS-TP NEがOSに接続する必要があります。接続は、直接（たとえば、ソフトウェア、ハードウェア、または独自のプロトコル接続を介して）または間接（別のMPLS-TP NEを介して）にする場合があります。このドキュメントでは、別のMPLS-TP NEを介していない管理接続は、直接的な管理接続です。MPLS-TP NEが間接的にOSに接続されている場合、MPLS-TP NEとOSへの接続を提供するために使用されるMPLS-TP NE（s）の間でMCCをサポートする必要があります。
Entities of the MPLS-TP management plane communicate via a DCN, or more specifically via the MCN. The MCN connects management systems with management systems, management systems with MPLS-TP NEs, and (in the indirect connectivity case discussed in section 3) MPLS-TP NEs with MPLS-TP NEs.
MPLS-TP管理プレーンのエンティティは、DCNを介して、またはより具体的にはMCNを介して通信します。MCNは、管理システムを管理システム、MPLS-TP NESを備えた管理システム、および（セクション3で説明した間接接続性の場合）MPLS-TP NESをMPLS-TP NESと接続します。
RFC 5586 [14] defines a Generic Associated Channel (G-ACh) to enable the realization of a communication channel (CCh) between adjacent MPLS-TP NEs for management and control. RFC 5718 [10] describes how the G-ACh can be used to provide infrastructure that forms part of the MCN and SCN. It also explains how MCN and SCN messages are encapsulated, carried on the G-ACh, and decapsulated for delivery to management or signaling/routing control plane components on a label switching router (LSR).
RFC 5586 [14]は、管理と制御のために隣接するMPLS-TP NES間の通信チャネル（CCH）の実現を可能にするための汎用関連チャネル（G-CHACH）を定義します。RFC 5718 [10]は、G-achを使用してMCNとSCNの一部を形成するインフラストラクチャを提供する方法を説明しています。また、MCNおよびSCNメッセージがどのようにカプセル化され、G-achに携帯され、ラベルスイッチングルーター（LSR）の管理またはシグナリング/ルーティング制御プレーンコンポーネントへの配信のために脱カプセル化されている方法についても説明します。
Section 7 of ITU-T G.7712/Y.1703 [6] describes the transport DCN architecture and requirements as follows:
ITU-T G.7712/Y.1703 [6]のセクション7では、輸送DCNアーキテクチャと要件について次のように説明しています。
1) The MPLS-TP MCN MUST support the requirements for:
1) MPLS-TP MCNは、次の要件をサポートする必要があります。
a) CCh access functions specified in Section 7.1.1;
a) セクション7.1.1で指定されたCCHアクセス関数。
b) MPLS-TP SCC data-link layer termination functions specified in Section 7.1.2.3;
b) セクション7.1.2.3で指定されたMPLS-TP SCCデータリンクレイヤー終了関数。
c) MPLS-TP MCC data-link layer termination functions specified in Section 7.1.2.4;
c) セクション7.1.2.4で指定されたMPLS-TP MCCデータリンクレイヤー終了関数。
d) Network layer PDU into CCh data-link frame encapsulation functions specified in Section 7.1.3;
d) セクション7.1.3で指定されたネットワークレイヤーPDUへのCCHデータリンクフレームカプセル化関数。
e) Network layer PDU forwarding (Section 7.1.6), interworking (Section 7.1.7), and encapsulation (Section 7.1.8) functions, as well as tunneling (Section 7.1.9) and routing (Section 7.1.10) functions.
e) ネットワークレイヤーPDU転送（セクション7.1.6）、インターワーキング（セクション7.1.7）、およびカプセル化（セクション7.1.8）関数、およびトンネリング（セクション7.1.9）およびルーティング（セクション7.1.10）機能。
As a practical matter, MCN connections will typically have addresses. See the section on Identifiers in RFC 5921 [8] for further information.
実際の問題として、MCN接続には通常、アドレスがあります。詳細については、RFC 5921 [8]の識別子に関するセクションを参照してください。
In order to have the MCN operate properly, a number of management functions for the MCN are needed, including:
MCNを適切に動作させるには、以下を含むMCNの多くの管理機能が必要です。
o Retrieval of DCN network parameters to ensure compatible functioning, e.g., packet size, timeouts, quality of service, window size, etc.;
o 互換性のある機能、パケットサイズ、タイムアウト、サービスの品質、ウィンドウサイズなどを確保するためのDCNネットワークパラメーターの取得。
o Establishment of message routing between DCN nodes;
o DCNノード間のメッセージルーティングの確立。
o Management of DCN network addresses;
o DCNネットワークアドレスの管理。
o Retrieval of operational status of the DCN at a given node;
o 特定のノードでのDCNの動作ステータスの取得。
o Capability to enable/disable access by an NE to the DCN. Note that this is to allow the isolation of a malfunctioning NE to keep it from impacting the rest of the network.
o DCNへのNEによるアクセスを有効/無効にする機能。これは、誤動作しているNEの分離がネットワークの残りの部分に影響を与えないようにするためであることに注意してください。
The Fault Management functions within an MPLS-TP NE enable the supervision, detection, validation, isolation, correction, and reporting of abnormal operation of the MPLS-TP network and its environment.
MPLS-TP NE内の障害管理機能により、MPLS-TPネットワークとその環境の異常な動作の監督、検出、検証、分離、修正、および報告が可能になります。
The supervision function analyzes the actual occurrence of a disturbance or fault for the purpose of providing an appropriate indication of performance and/or detected fault condition to maintenance personnel and operations systems.
監督機能は、パフォーマンスおよび/または検出された障害条件をメンテナンス担当者と運用システムに提供する目的で、妨害または障害の実際の発生を分析します。
1) The MPLS-TP NE MUST support supervision of the OAM mechanisms that are deployed for supporting the OAM requirements defined in RFC 5860 [3].
1) MPLS-TP NEは、RFC 5860で定義されているOAM要件をサポートするために展開されているOAMメカニズムの監督をサポートする必要があります[3]。
2) The MPLS-TP NE MUST support the following data-plane forwarding path supervision functions:
2) MPLS-TP NEは、次のデータプレーン転送パス監督機能をサポートする必要があります。
a) Supervision of loop-checking functions used to detect loops in the data-plane forwarding path (which result in non-delivery of traffic, wasting of forwarding resources, and unintended self-replication of traffic);
a) ループチェック関数の監督機能の監督データプレーン転送パスのループを検出するために使用される機能（トラフィックの非配信、転送リソースの浪費、および意図しないトラフィックの自己過剰）;
b) Supervision of failure detection;
b) 障害検出の監督。
3) The MPLS-TP NE MUST support the capability to configure data-plane forwarding path related supervision mechanisms to perform on-demand or proactively.
3) MPLS-TP NEは、オンデマンドまたは積極的に実行するために、データ平面転送パス関連の監督メカニズムを構成する機能をサポートする必要があります。
4) The MPLS-TP NE MUST support supervision for software processing -- e.g., processing faults, storage capacity, version mismatch, corrupted data, and out of memory problems, etc.
4) MPLS-TP NEは、ソフトウェア処理の監督をサポートする必要があります - 処理障害、ストレージ容量、バージョンの不一致、破損したデータ、メモリ問題など
5) The MPLS-TP NE MUST support hardware-related supervision for interchangeable and non-interchangeable unit, cable, and power problems.
5) MPLS-TP NEは、交換可能なユニット、ケーブル、電源の問題のハードウェア関連の監督をサポートする必要があります。
6) The MPLS-TP NE SHOULD support environment-related supervision for temperature, humidity, etc.
6) MPLS-TP NEは、温度、湿度などの環境関連の監督をサポートする必要があります。
Validation is the process of integrating Fault Cause indications into Failures. A Fault Cause Indication (FCI) indicates a limited interruption of the required transport function. A Fault Cause is not reported to maintenance personnel because it might exist only for a very short period of time. Note that some of these events are summed up in the Performance Monitoring process (see Section 7), and when this sum exceeds a configured value, a threshold crossing alert (report) can be generated.
検証とは、障害原因の表示を障害に統合するプロセスです。障害原因表示（FCI）は、必要な輸送機能の限られた中断を示します。障害の原因は、非常に短期間だけ存在する可能性があるため、メンテナンス担当者には報告されません。これらのイベントの一部はパフォーマンス監視プロセスで要約されており（セクション7を参照）、この合計が構成された値を超えると、しきい値の交差アラート（レポート）を生成できることに注意してください。
When the Fault Cause lasts long enough, an inability to perform the required transport function arises. This failure condition is subject to reporting to maintenance personnel and/or an OS because corrective action might be required. Conversely, when the Fault Cause ceases after a certain time, clearing of the Failure condition is also subject to reporting.
障害の原因が十分に長く続くと、必要な輸送機能を実行できないことが発生します。この障害条件は、是正措置が必要になる可能性があるため、メンテナンス担当者および/またはOSに報告される可能性があります。逆に、障害が特定の時間の後に停止する場合、故障状態のクリアも報告の対象となります。
1) The MPLS-TP NE MUST perform persistency checks on fault causes before it declares a fault cause a failure.
1) MPLS-TP NEは、障害の原因を宣言する前に、障害の原因で永続性チェックを実行する必要があります。
2) The MPLS-TP NE SHOULD provide a configuration capability for control parameters associated with performing the persistency checks described above.
2) MPLS-TP NEは、上記の永続性チェックの実行に関連する制御パラメーターの構成機能を提供する必要があります。
3) An MPLS-TP NE MAY provide configuration parameters to control reporting and clearing of failure conditions.
3) MPLS-TP NEは、障害条件の報告とクリアを制御するための構成パラメーターを提供する場合があります。
4) A data-plane forwarding path failure MUST be declared if the fault cause persists continuously for a configurable time (Time-D). The failure MUST be cleared if the fault cause is absent continuously for a configurable time (Time-C).
4) 障害原因が構成可能な時間（TIME-D）の継続的に持続する場合、データ平面転送パスの障害を宣言する必要があります。構成可能な時間（TIME-C）の間、障害原因が継続的に存在しない場合、障害をクリアする必要があります。
Note: As an example, the default time values might be as follows:
注：例として、デフォルトの時間値は次のとおりです。
Time-D = 2.5 +/- 0.5 seconds
Time-D = 2.5 /-0.5秒
Time-C = 10 +/- 0.5 seconds
Time-C = 10 /-0.5秒
These time values are as defined in G.7710 [1].
これらの時間値は、G.7710 [1]で定義されています。
5) MIBs - or other object management semantics specifications - defined to enable configuration of these timers SHOULD explicitly provide default values and MAY provide guidelines on ranges and value determination methods for scenarios where the default value chosen might be inadequate. In addition, such specifications SHOULD define the level of granularity at which tables of these values are to be defined.
5) MIBS-またはその他のオブジェクト管理セマンティクス仕様 - これらのタイマーの構成を有効にするために定義されたデフォルト値を明示的に提供し、選択したデフォルト値が不十分なシナリオの範囲と値決定方法に関するガイドラインを提供する場合があります。さらに、このような仕様は、これらの値の表の表を定義する粒度のレベルを定義する必要があります。
6) Implementations MUST provide the ability to configure the preceding set of timers and SHOULD provide default values to enable rapid configuration. Suitable default values, timer ranges, and level of granularity are out of scope in this document and form part of the specification of fault management details. Timers SHOULD be configurable per NE for broad categories (for example, defects and/or fault causes), and MAY be configurable per-interface on an NE and/or per individual defect/fault cause.
6) 実装は、前述のタイマーセットを構成する機能を提供する必要があり、迅速な構成を有効にするためにデフォルト値を提供する必要があります。適切なデフォルト値、タイマー範囲、および粒度のレベルは、このドキュメントでは範囲外であり、障害管理の詳細の仕様の一部を形成します。タイマーは、幅広いカテゴリ（例えば、欠陥や障害の原因など）に対してNEごとに構成可能である必要があり、NEおよび/または個々の欠陥/障害原因でインターフェイスごとに構成可能である場合があります。
7) The failure declaration and clearing MUST be time stamped. The time-stamp MUST indicate the time at which the fault cause is activated at the input of the fault cause persistency (i.e., defect-to-failure integration) function, and the time at which the fault cause is deactivated at the input of the fault cause persistency function.
7) 故障宣言とクリアリングはタイムスタンプを付ける必要があります。タイムスタンプは、障害の入力で障害原因がアクティブ化される時間を、持続性（つまり、欠陥から障害の統合）関数、および障害原因の入力で障害原因が非アクティブ化される時間を示す必要があります。障害は持続性関数を引き起こします。
Failures can be categorized to indicate the severity or urgency of the fault.
障害は、障害の重症度または緊急性を示すために分類できます。
1) An MPLS-TP NE SHOULD support the ability to assign severity (e.g., Critical, Major, Minor, Warning) to alarm conditions via configuration.
1) MPLS-TP NEは、構成を介してアラーム条件に重大度（批判、メジャー、マイナー、警告など）を割り当てる機能をサポートする必要があります。
See G.7710 [1], Section 7.2.2 for more detail on alarm severity assignment. For additional discussion of Alarm Severity management, see discussion of alarm severity in RFC 3877 [11].
アラームの重大度割り当ての詳細については、G.7710 [1]、セクション7.2.2を参照してください。アラームの重症度管理に関する追加の議論については、RFC 3877のアラーム重症度の議論を参照してください[11]。
Alarms can be generated from many sources, including OAM, device status, etc.
アラームは、OAM、デバイスステータスなど、多くのソースから生成できます。
1) An MPLS-TP NE MUST support suppression of alarms based on configuration.
1) MPLS-TP NEは、構成に基づいてアラームの抑制をサポートする必要があります。
Alarm Reporting is concerned with the reporting of relevant events and conditions, which occur in the network (including the NE, incoming signal, and external environment).
アラームレポートは、ネットワーク（NE、着信信号、および外部環境を含む）で発生する関連するイベントと条件の報告に関係しています。
Local reporting is concerned with automatic alarming by means of audible and visual indicators near the failed equipment.
ローカルレポートは、故障した機器の近くの可聴および視覚インジケーターによる自動アラージングに関係しています。
1) An MPLS-TP NE MUST support local reporting of alarms.
1) MPLS-TP NEは、アラームのローカルレポートをサポートする必要があります。
2) The MPLS-TP NE MUST support reporting of alarms to an OS. These reports are either autonomous reports (notifications) or reports on request by maintenance personnel. The MPLS-TP NE SHOULD report local (environmental) alarms to a network management system.
2) MPLS-TP NEは、OSへのアラームの報告をサポートする必要があります。これらのレポートは、自律レポート（通知）またはメンテナンス担当者による要求に応じてレポートのいずれかです。MPLS-TP NEは、ローカル（環境）アラームをネットワーク管理システムに報告する必要があります。
3) An MPLS-TP NE supporting one or more other networking technologies (e.g., Ethernet, SDH/SONET, MPLS) over MPLS-TP MUST be capable of translating MPLS-TP defects into failure conditions that are meaningful to the client layer, as described in RFC 4377 [2], Section 4.7.
3) MPLS-TPを介した1つ以上の他のネットワーキングテクノロジー（例：イーサネット、SDH/SONET、MPLS）をサポートするMPLS-TP NEは、MPLS-TP欠陥をクライアントレイヤーにとって意味のある故障条件に変換できる必要があります。RFC 4377 [2]、セクション4.7。
Alarm Reporting Control (ARC) supports an automatic in-service provisioning capability. Alarm reporting can be turned off on a per-managed entity basis (e.g., LSP) to allow sufficient time for customer service testing and other maintenance activities in an "alarm free" state. Once a managed entity is ready, alarm reporting is automatically turned on.
アラームレポートコントロール（ARC）は、自動インサービスプロビジョニング機能をサポートします。アラームレポートは、「アラームフリー」状態で顧客サービステストやその他のメンテナンスアクティビティに十分な時間を確保するために、管理されたエンティティごと（LSPなど）でオフにすることができます。マネージドエンティティの準備ができたら、アラームレポートが自動的にオンになります。
1) An MPLS-TP NE SHOULD support the Alarm Reporting Control function for controlling the reporting of alarm conditions.
1) MPLS-TP NEは、アラーム条件の報告を制御するためのアラームレポート制御機能をサポートする必要があります。
See G.7710 [1] (Section 7.1.3.2) and RFC 3878 [24] for more information about ARC.
ARCの詳細については、G.7710 [1]（セクション7.1.3.2）およびRFC 3878 [24]を参照してください。
Configuration Management provides functions to identify, collect data from, provide data to, and control NEs. Specific configuration tasks requiring network management support include hardware and software configuration, configuration of NEs to support transport paths (including required working and protection paths), and configuration of required path integrity/connectivity and performance monitoring (i.e., OAM).
Configuration Managementは、NESからデータを識別、収集、データの提供、および制御する機能を提供します。ネットワーク管理サポートを必要とする特定の構成タスクには、ハードウェアとソフトウェアの構成、輸送パス（必要な作業と保護パスを含む）をサポートするNESの構成、必要なパスの整合性/接続性とパフォーマンス監視の構成（つまり、OAM）が含まれます。
1) The MPLS-TP NE MUST support the configuration requirements specified in G.7710 [1], Section 8.1 for hardware.
1) MPLS-TP NEは、ハードウェアのG.7710 [1]、セクション8.1で指定された構成要件をサポートする必要があります。
2) The MPLS-TP NE MUST support the configuration requirements specified in G.7710 [1], Section 8.2 for software.
2) MPLS-TP NEは、G.7710 [1]、セクション8.2で指定された構成要件をサポートする必要があります。
3) The MPLS-TP NE MUST support the configuration requirements specified in G.7710 [1], Section 8.13.2.1 for local real-time clock functions.
3) MPLS-TP NEは、ローカルリアルタイムクロック関数について、G.7710 [1]、セクション8.13.2.1で指定された構成要件をサポートする必要があります。
4) The MPLS-TP NE MUST support the configuration requirements specified in G.7710 [1], Section 8.13.2.2 for local real-time clock alignment with external time reference.
4) MPLS-TP NEは、外部時間参照とローカルリアルタイムクロックアライメントについて、G.7710 [1]、セクション8.13.2.2で指定された構成要件をサポートする必要があります。
5) The MPLS-TP NE MUST support the configuration requirements specified in G.7710 [1], Section 8.13.2.3 for performance monitoring of the clock function.
5) MPLS-TP NEは、クロック関数のパフォーマンス監視については、G.7710 [1]、セクション8.13.2.3で指定された構成要件をサポートする必要があります。
1) If a control plane is supported in an implementation of MPLS-TP, the MPLS-TP NE MUST support the configuration of MPLS-TP control plane functions by the management plane. Further detailed requirements will be provided along with progress in defining the MPLS-TP control plane in appropriate specifications.
1) MPLS-TPの実装でコントロールプレーンがサポートされている場合、MPLS-TP NEは、管理プレーンによるMPLS-TP制御プレーン機能の構成をサポートする必要があります。さらに詳細な要件が提供され、適切な仕様でMPLS-TP制御プレーンを定義する際の進捗状況が提供されます。
1) In addition to the requirement to support static provisioning of transport paths (defined in RFC 5645 [7], Section 2.1 -- General Requirements, requirement 18), an MPLS-TP NE MUST support the configuration of required path performance characteristic thresholds (e.g., Loss Measurement <LM>, Delay Measurement <DM> thresholds) necessary to support performance monitoring of the MPLS-TP service(s).
1) 輸送パスの静的プロビジョニングをサポートする要件に加えて（RFC 5645 [7]、セクション2.1-一般的な要件、要件18で定義）、MPLS-TP NEは、必要なパフォーマンス特性しきい値の構成をサポートする必要があります（例えば、MPLS-TPサービスのパフォーマンス監視をサポートするために必要な損失測定<LM>、遅延測定<DM>しきい値）。
2) In order to accomplish this, an MPLS-TP NE MUST support configuration of LSP information (such as an LSP identifier of some kind) and/or any other information needed to retrieve LSP status information, performance attributes, etc.
2) これを達成するために、MPLS-TP NEは、LSP情報の構成（何らかのLSP識別子など）および/またはLSPステータス情報、パフォーマンス属性などを取得するために必要なその他の情報をサポートする必要があります。
3) If a control plane is supported, and that control plane includes support for control-plane/management-plane hand-off for LSP setup/maintenance, the MPLS-TP NE MUST support management of the hand-off of Path control. For example, see RFCs 5943 [19] and 5852 [20].
3) コントロールプレーンがサポートされており、そのコントロールプレーンには、LSPセットアップ/メンテナンスのコントロールプレーン/管理面ハンドオフのサポートが含まれている場合、MPLS-TP NEはパス制御のハンドオフの管理をサポートする必要があります。たとえば、RFCS 5943 [19]および5852 [20]を参照してください。
4) Further detailed requirements SHALL be provided along with progress in defining the MPLS-TP control plane in appropriate specifications.
4) さらなる詳細な要件は、適切な仕様でMPLS-TP制御プレーンを定義する際の進捗状況とともに提供されるものとします。
5) If MPLS-TP transport paths cannot be statically provisioned using MPLS LSP and pseudowire management tools (either already defined in standards or under development), further management specifications MUST be provided as needed.
5) MPLS-TPトランスポートパスをMPLS LSPおよび擬似化管理ツール（既に標準または開発中に定義している）を使用して静的にプロビジョニングできない場合、必要に応じてさらなる管理仕様を提供する必要があります。
1) The MPLS-TP NE MUST support configuration of required path protection information as follows:
1) MPLS-TP NEは、次のように、必要なパス保護情報の構成をサポートする必要があります。
o designate specifically identified LSPs as working or protecting LSPs;
o 特異的に特定されたLSPを、LSPの動作または保護として指定します。
o define associations of working and protecting paths;
o パスの作業と保護の関連性を定義します。
o operate/release manual protection switching;
o 手動保護の切り替えを操作/リリースします。
o operate/release force protection switching;
o 力の保護スイッチングを操作/放出します。
o operate/release protection lockout;
o 保護ロックアウトを操作/リリースします。
o set/retrieve Automatic Protection Switching (APS) parameters, including
o 自動保護スイッチング（APS）パラメーターを含む設定/取得
o Wait to Restore time,
o 時間を回復するのを待ち、
o Protection Switching threshold information.
o 保護スイッチングしきい値情報。
1) The MPLS-TP NE MUST support configuration of the OAM entities and functions specified in RFC 5860 [3].
1) MPLS-TP NEは、RFC 5860で指定されたOAMエンティティと機能の構成をサポートする必要があります[3]。
2) The MPLS-TP NE MUST support the capability to choose which OAM functions are enabled.
2) MPLS-TP NEは、有効になっているOAM関数を選択する機能をサポートする必要があります。
3) For enabled OAM functions, the MPLS-TP NE MUST support the ability to associate OAM functions with specific maintenance entities.
3) 有効なOAM関数の場合、MPLS-TP NEは、OAM関数を特定のメンテナンスエンティティと関連付ける機能をサポートする必要があります。
4) The MPLS-TP NE MUST support the capability to configure the OAM entities/functions as part of LSP setup and tear-down, including co-routed bidirectional point-to-point, associated bidirectional point-to-point, and uni-directional (both point-to-point and point-to-multipoint) connections.
4) MPLS-TP neは、協調的な双方向から偏向ポイント、関連する双方向のポイントツーポイント、および一方向（および一方向）を含む、LSPセットアップおよび裂け目の一部としてOAMエンティティ/関数を構成する機能をサポートする必要があります（ポイントツーポイントとポイントツーマルチポイントの両方）接続。
5) The MPLS-TP NE MUST support the configuration of maintenance entity identifiers (e.g., MEP ID and MIP ID) for the purpose of LSP connectivity checking.
5) MPLS-TP NEは、LSP接続チェックを目的として、メンテナンスエンティティ識別子の構成（MEP IDおよびMIP IDなど）をサポートする必要があります。
6) The MPLS-TP NE MUST support configuration of OAM parameters to meet their specific operational requirements, such as
6) MPLS-TP NEは、OAMパラメーターの構成をサポートする必要があります。
a) one-time on-demand immediately or
a) すぐに1回限りのオンデマンドまたは
b) one-time on-demand pre-scheduled or
b) 1回限りのオンデマンド事前スケジュールまたは
c) on-demand periodically based on a specified schedule or
c) 指定されたスケジュールに基づいて定期的にオンデマンドまたは
d) proactive on-going.
d) 積極的な進行中。
7) The MPLS-TP NE MUST support the enabling/disabling of the connectivity check processing. The connectivity check process of the MPLS-TP NE MUST support provisioning of the identifiers to be transmitted and the expected identifiers.
7) MPLS-TP NEは、接続チェック処理の有効化/無効化をサポートする必要があります。MPLS-TP NEの接続チェックプロセスは、送信される識別子のプロビジョニングと予想される識別子をサポートする必要があります。
Performance Management provides functions for the purpose of maintenance, bring-into-service, quality of service, and statistics gathering.
パフォーマンスマネジメントは、メンテナンス、供給者のサービス、サービスの質、統計の収集を目的とした機能を提供します。
This information could be used, for example, to compare behavior of the equipment, MPLS-TP NE, or network at different moments in time to evaluate changes in network performance.
この情報は、たとえば、ネットワークパフォーマンスの変化を評価するために、さまざまな瞬間に機器、MPLS-TP NE、またはネットワークの動作を比較するために使用できます。
ITU-T Recommendation G.7710 [1] provides transport performance monitoring requirements for packet-switched and circuit-switched transport networks with the objective of providing a coherent and consistent interpretation of the network behavior in a multi-technology environment. The performance management requirements specified in this document are driven by such an objective.
ITU-Tの推奨G.7710 [1]は、マルチテクノロジー環境におけるネットワーク動作の一貫した一貫した解釈を提供する目的で、パケットスイッチおよびサーキットスイッチの輸送ネットワークのトランスポートパフォーマンス監視要件を提供します。このドキュメントで指定されているパフォーマンス管理要件は、そのような目的によって駆動されます。
1) It MUST be possible to determine when an MPLS-TP-based transport service is available and when it is unavailable.
1) MPLS-TPベースの輸送サービスがいつ利用可能か、いつ利用できないかを判断することは可能である必要があります。
From a performance perspective, a service is unavailable if there is an indication that performance has degraded to the extent that a configurable performance threshold has been crossed and the degradation persists long enough (i.e., the indication persists for some amount of time, which is either configurable or well-known) to be certain it is not a measurement anomaly.
パフォーマンスの観点から見ると、設定可能なパフォーマンスのしきい値が交差し、劣化が十分に長く持続する範囲でパフォーマンスが低下したことを示している場合、サービスは利用できません（つまり、適応症はある程度持続します。構成可能またはよく知られている）確かに、それが測定の異常ではないことを確認してください。
Methods, mechanisms, and algorithms for exactly how unavailability is to be determined -- based on collection of raw performance data -- are out of scope for this document.
生のパフォーマンスデータの収集に基づいて、利用不能性を正確に決定する方法の方法、メカニズム、およびアルゴリズムは、このドキュメントの範囲外です。
2) The MPLS-TP NE MUST support collection and reporting of raw performance data that MAY be used in determining the unavailability of a transport service.
2) MPLS-TP NEは、輸送サービスの利用不能を決定する際に使用できる生のパフォーマンスデータの収集とレポートをサポートする必要があります。
3) MPLS-TP MUST support the determination of the unavailability of the transport service. The result of this determination MUST be available via the MPLS-TP NE (at service termination points), and determination of unavailability MAY be supported by the MPLS-TP NE directly. To support this requirement, the MPLS-TP NE management information model MUST include objects corresponding to the availability-state of services.
3) MPLS-TPは、輸送サービスの利用不能の決定をサポートする必要があります。この決定の結果は、MPLS-TP NE（サービス終了点）を介して利用可能でなければならず、利用不能の決定はMPLS-TP NEによって直接サポートされる場合があります。この要件をサポートするには、MPLS-TP NE管理情報モデルには、サービスの可用性状態に対応するオブジェクトを含める必要があります。
Transport network unavailability is based on Severely Errored Seconds (SES) and Unavailable Seconds (UAS). The ITU-T is establishing definitions of unavailability that are generically applicable to packet transport technologies, including MPLS-TP, based on SES and UAS. Note that SES and UAS are already defined for Ethernet transport networks in ITU-T Recommendation Y.1563 [25].
トランスポートネットワークの利用不能は、重度のエラーのある秒（SES）と利用できない秒（UAS）に基づいています。ITU-Tは、SESおよびUASに基づいて、MPLS-TPを含むパケット輸送技術に一般的に適用可能な利用不能の定義を確立しています。SESとUASは、ITU-T推奨Y.1563 [25]のイーサネット輸送ネットワークのために既に定義されていることに注意してください。
4) The MPLS-TP NE MUST support collection of loss measurement (LM) statistics.
4) MPLS-TP NEは、損失測定（LM）統計の収集をサポートする必要があります。
5) The MPLS-TP NE MUST support collection of delay measurement (DM) statistics.
5) MPLS-TP NEは、遅延測定（DM）統計の収集をサポートする必要があります。
6) The MPLS-TP NE MUST support reporting of performance degradation via fault management for corrective actions.
6) MPLS-TP NEは、是正措置のために障害管理を介したパフォーマンスの劣化の報告をサポートする必要があります。
"Reporting" in this context could mean:
この文脈での「報告」は、次のことを意味する可能性があります。
o reporting to an autonomous protection component to trigger protection switching,
o 保護スイッチングをトリガーするための自律保護コンポーネントへの報告、
o reporting via a craft interface to allow replacement of a faulty component (or similar manual intervention),
o 故障したコンポーネント（または同様の手動介入）の交換を可能にするために、クラフトインターフェイスを介して報告する、
o etc.
o 等
7) The MPLS-TP NE MUST support reporting of performance statistics on request from a management system.
7) MPLS-TP NEは、管理システムからの要求に応じて、パフォーマンス統計のレポートをサポートする必要があります。
1) For performance measurement mechanisms that support both proactive and on-demand modes, the MPLS-TP NE MUST support the capability to be configured to operate on-demand or proactively.
1) プロアクティブモードとオンデマンドモードの両方をサポートするパフォーマンス測定メカニズムの場合、MPLS-TP NEは、オンデマンドまたは積極的に動作するように構成する機能をサポートする必要があります。
On measurement of packet loss and loss ratio:
パケット損失と損失比の測定について：
1) For bidirectional (both co-routed and associated) point-to-point (P2P) connections
1) 双方向（共同ルートと関連する両方）ポイントツーポイント（P2P）接続の場合
a) on-demand measurement of single-ended packet loss and loss ratio measurement is REQUIRED;
a) シングルエンドパケット損失および損失比測定のオンデマンド測定が必要です。
b) proactive measurement of packet loss and loss ratio measurement for each direction is REQUIRED.
b) 各方向のパケット損失と損失比測定の積極的な測定が必要です。
2) For unidirectional (P2P and point-to-multipoint (P2MP)) connection, proactive measurement of packet loss and loss ratio is REQUIRED.
2) 単方向（P2Pおよびポイントツーマルチポイント（P2MP））接続の場合、パケット損失と損失比のプロアクティブな測定が必要です。
On Delay measurement:
遅延測定時：
3) For a unidirectional (P2P and P2MP) connection, on-demand measurement of delay measurement is REQUIRED.
3) 単方向（P2PおよびP2MP）接続の場合、遅延測定のオンデマンド測定が必要です。
4) For a co-routed bidirectional (P2P) connection, on-demand measurement of one-way and two-way delay is REQUIRED.
4) 同時双方向（P2P）接続の場合、一方向および双方向遅延のオンデマンド測定が必要です。
5) For an associated bidirectional (P2P) connection, on-demand measurement of one-way delay is REQUIRED.
5) 関連する双方向（P2P）接続の場合、一元配置遅延のオンデマンド測定が必要です。
1) The MPLS-TP NE MUST support secure management and control planes.
1) MPLS-TP NEは、安全な管理および制御プレーンをサポートする必要があります。
1) Secure communication channels MUST be supported for all network traffic and protocols used to support management functions. This MUST include, at least, protocols used for configuration, monitoring, configuration backup, logging, time synchronization, authentication, and routing.
1) 安全な通信チャネルは、管理機能をサポートするために使用されるすべてのネットワークトラフィックおよびプロトコルに対してサポートする必要があります。これには、少なくとも、構成、監視、構成のバックアップ、ロギング、時間同期、認証、およびルーティングに使用されるプロトコルが含まれている必要があります。
2) The MCC MUST support application protocols that provide confidentiality and data-integrity protection.
2) MCCは、機密性とデータ積分保護を提供するアプリケーションプロトコルをサポートする必要があります。
3) The MPLS-TP NE MUST support the following:
3) MPLS-TP neは以下をサポートする必要があります。
a) Use of open cryptographic algorithms (see RFC 3871 [4]).
a) オープン暗号化アルゴリズムの使用（RFC 3871 [4]を参照）。
b) Authentication - allow management connectivity only from authenticated entities.
b) 認証 - 認証されたエンティティからのみ管理接続を許可します。
c) Authorization - allow management activity originated by an authorized entity, using (for example) an Access Control List (ACL).
c) 認可 - アクセス制御リスト（ACL）を使用して、認定エンティティから発信される管理アクティビティを許可します。
d) Port Access Control - allow management activity received on an authorized (management) port.
d) ポートアクセス制御 - 許可された（管理）ポートで受信した管理アクティビティを許可します。
Security requirements for the SCC are driven by considerations similar to MCC requirements described in Section 8.1.
SCCのセキュリティ要件は、セクション8.1で説明されているMCC要件と同様の考慮事項によって推進されます。
Security Requirements for the control plane are out of scope for this document and are expected to be defined in the appropriate control plane specifications.
コントロールプレーンのセキュリティ要件は、このドキュメントの範囲外であり、適切な制御プレーンの仕様で定義されることが期待されています。
1) Management of control plane security MUST be defined in the appropriate control plane specifications.
1) 制御プレーンのセキュリティの管理は、適切な制御プレーンの仕様で定義する必要があります。
A denial-of-service (DoS) attack is an attack that tries to prevent a target from performing an assigned task, or providing its intended service(s), through any means. A Distributed DoS (DDoS) can multiply attack severity (possibly by an arbitrary amount) by using multiple (potentially compromised) systems to act as topologically (and potentially geographically) distributed attack sources. It is possible to lessen the impact and potential for DoS and DDoS by using secure protocols, turning off unnecessary processes, logging and monitoring, and ingress filtering. RFC 4732 [26] provides background on DoS in the context of the Internet.
サービス拒否（DOS）攻撃は、ターゲットが割り当てられたタスクを実行したり、意図したサービスを提供したりするのを防ぐ攻撃です。分散DOS（DDOS）は、複数の（潜在的に侵害された）システムを使用して、トポロジカル（および潜在的に地理的に）分散攻撃ソースとして機能することにより、攻撃の重症度（おそらく任意の量）を掛けることができます。安全なプロトコルを使用し、不要なプロセスをオフにし、ロギングと監視をオフにし、フィルタリングをイングレスすることにより、DOSおよびDDOの影響と可能性を軽減することができます。RFC 4732 [26]は、インターネットのコンテキストでDOSの背景を提供します。
1) An MPLS-TP NE MUST support secure management protocols and SHOULD do so in a manner that reduces potential impact of a DoS attack.
1) MPLS-TP NEは、安全な管理プロトコルをサポートする必要があり、DOS攻撃の潜在的な影響を減らす方法でそうする必要があります。
2) An MPLS-TP NE SHOULD support additional mechanisms that mitigate a DoS (or DDoS) attack against the management component while allowing the NE to continue to meet its primary functions.
2) MPLS-TP NEは、NEが主要な機能を引き続き満たすことを可能にしながら、管理コンポーネントに対するDOS（またはDDO）攻撃を緩和する追加のメカニズムをサポートする必要があります。
Section 8 includes a set of security requirements that apply to MPLS-TP network management.
セクション8には、MPLS-TPネットワーク管理に適用されるセキュリティ要件のセットが含まれています。
1) Solutions MUST provide mechanisms to prevent unauthorized and/or unauthenticated access to management capabilities and private information by network elements, systems, or users.
1) ソリューションは、ネットワーク要素、システム、またはユーザーによる管理機能および個人情報への不正および/または不正なアクセスを防ぐためのメカニズムを提供する必要があります。
Performance of diagnostic functions and path characterization involves extracting a significant amount of information about network construction that the network operator might consider private.
診断機能のパフォーマンスとパスの特性評価には、ネットワークオペレーターがプライベートと見なす可能性のあるネットワーク構造に関するかなりの量の情報を抽出することが含まれます。
The authors/editors gratefully acknowledge the thoughtful review, comments, and explanations provided by Adrian Farrel, Alexander Vainshtein, Andrea Maria Mazzini, Ben Niven-Jenkins, Bernd Zeuner, Dan Romascanu, Daniele Ceccarelli, Diego Caviglia, Dieter Beller, He Jia, Leo Xiao, Maarten Vissers, Neil Harrison, Rolf Winter, Yoav Cohen, and Yu Liang.
著者/編集者は、Adrian Farrel、Alexander Vainshtein、Andrea Maria Mazzini、Ben Niven-Jenkins、Bernd Zeuner、Dan Romascanu、Daniele Ceccarelli、Diego Caviglia、Diegoer Beller、彼のJia、Leo、Leo、Leo、Leo、Leo、Leo、Leo、Leo、Leo、Leo、Leo、Leo、Leo、Leo、Leo、Leoの思慮深いレビュー、コメント、説明に感謝して認めています。Xiao、Maarten Vissers、Neil Harrison、Rolf Winter、Yoav Cohen、Yu Liang。
[1] ITU-T Recommendation G.7710/Y.1701, "Common equipment management function requirements", July, 2007.
[1] ITU-Tの推奨G.7710/Y.1701、「一般的な機器管理機能要件」、2007年7月。
[2] 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.
[2] Nadeau、T.、Morrow、M.、Swallow、G.、Allan、D。、およびS. Matsushima、「Multi-Protocol Label Switched（MPLS）ネットワークの運用および管理（OAM）要件」、RFC 4377、2006年2月。
[3] 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.
[3] Vigoureux、M.、Ed。、ed。、Ward、D.、ed。、およびM. Betts、ed。、「MPLS輸送ネットワークの運用、管理、およびメンテナンスの要件（OAM）」、RFC 5860、2010年5月。
[4] Jones, G., Ed., "Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure", RFC 3871, September 2004.
[4] Jones、G.、ed。、「大規模なインターネットサービスプロバイダー（ISP）IPネットワークインフラストラクチャの運用セキュリティ要件」、RFC 3871、2004年9月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[6] ITU-T Recommendation G.7712/Y.1703, "Architecture and specification of data communication network", June 2008.
[6] ITU-Tの推奨G.7712/Y.1703、「データ通信ネットワークのアーキテクチャと仕様」、2008年6月。
[7] 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.
[7] Niven-Jenkins、B.、Ed。、Brungard、D.、Ed。、Betts、M.、Ed。、Sprecher、N.、およびS. Ueno、「MPLS輸送プロファイルの要件」、RFC 5654、2009年9月。
[8] 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.
[8] Bocci、M.、Ed。、Bryant、S.、Ed。、Frost、D.、Ed。、Levrau、L.、およびL. Berger、「輸送ネットワークにおけるMPLのフレームワーク」、RFC 5921、2010年7月。
[9] Mansfield, S. Ed., Gray, E., Ed., and K. Lam, Ed., "Network Management Framework for MPLS-based Transport Networks", RFC 5950, September 2010.
[9] Mansfield、S。Ed。、Gray、E.、Ed。、およびK. Lam、ed。、「MPLSベースの輸送ネットワークのネットワーク管理フレームワーク」、RFC 5950、2010年9月。
[10] Beller, D. and A. Farrel, "An In-Band Data Communication Network For the MPLS Transport Profile", RFC 5718, January 2010.
[10] Beller、D。およびA. Farrel、「MPLS輸送プロファイルのインバンドデータ通信ネットワーク」、RFC 5718、2010年1月。
[11] Chisholm, S. and D. Romascanu, "Alarm Management Information Base (MIB)", RFC 3877, September 2004.
[11] Chisholm、S。and D. Romascanu、「Alarm Management Information Base（MIB）」、RFC 3877、2004年9月。
[12] ITU-T Recommendation M.20, "Maintenance philosophy for telecommunication networks", October 1992.
[12] ITU-Tの推奨M.20、「通信ネットワークのメンテナンス哲学」、1992年10月。
[13] Telcordia, "Network Maintenance: Network Element and Transport Surveillance Messages" (GR-833-CORE), Issue 5, August 2004.
[13] Telcordia、「ネットワークメンテナンス：ネットワーク要素と輸送監視メッセージ」（GR-833-CORE）、2004年8月5日。
[14] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.
[14] Bocci、M.、ed。、vigoureux、M.、ed。、およびS. Bryant、ed。、「Mpls Generic Associated Channel」、RFC 5586、2009年6月。
[15] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, November 2009.
[15] Harrington、D。、「新しいプロトコルとプロトコル拡張の運用と管理を検討するためのガイドライン」、RFC 5706、2009年11月。
[16] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", Work in Progress, July 2010.
[16] Enns、R.、ed。、Bjorklund、M.、ed。、Schoenwaelder、J.、ed。、およびA. Bierman、ed。、「Network Configuration Protocol（NetConf）」、2010年7月の作業。
[17] Presuhn, R., Ed., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002.
[17] Presuhn、R.、ed。、「Simple Network Management Protocol（SNMP）のプロトコル操作のバージョン2」、STD 62、RFC 3416、2002年12月。
[18] OMG Document formal/04-03-12, "The Common Object Request Broker: Architecture and Specification", Revision 3.0.3. March 12, 2004.
[18] OMG Document Formal/04-03-12、「Common Object Request Broker：Architecture and Specification」、Revision 3.0.3。2004年3月12日。
[19] Caviglia, D., Bramanti, D., Li, D., and D. McDysan, "Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network", RFC 5493, April 2009.
[19] Caviglia、D.、Bramanti、D.、Li、D。、およびD. McDysan、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）ネットワークでの永久接続とスイッチング接続の間の変換の要件」、RFC 5493、2009年4月。
[20] Caviglia, D., Ceccarelli, D., Bramanti, D., Li, D., and S. Bardalai, "RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network", RFC 5852, April 2010.
[20] Caviglia、D.、Ceccarelli、D.、Bramanti、D.、Li、D.、およびS. Bardalai、「GMPLS対応輸送ネットワークの管理プレーンからコントロールプレーンへのLSPハンドオーバーのRSVP-TEシグナリング拡張」、RFC 5852、2010年4月。
[21] ITU-T Recommendation G.806, "Characteristics of transport equipment - Description methodology and generic functionality", January, 2009.
[21] ITU -Tの推奨G.806、「輸送機器の特性 - 説明方法と一般的な機能」、2009年1月。
[22] ITU-T Recommendation Y.1731, "OAM functions and mechanisms for Ethernet based networks", February, 2008.
[22] ITU-T推奨Y.1731、「イーサネットベースのネットワークのOAM機能とメカニズム」、2008年2月。
[23] ITU-T Recommendation G.8601, "Architecture of service management in multi bearer, multi carrier environment", June 2006.
[23] ITU-Tの推奨G.8601、「マルチベアラー、マルチキャリア環境におけるサービス管理のアーキテクチャ」、2006年6月。
[24] Lam, H., Huynh, A., and D. Perkins, "Alarm Reporting Control Management Information Base (MIB)", RFC 3878, September 2004.
[24] Lam、H.、Huynh、A。、およびD. Perkins、「アラーム報告制御管理情報ベース（MIB）」、RFC 3878、2004年9月。
[25] ITU-T Recommendation Y.1563, "Ethernet frame transfer and availability performance", January 2009.
[25] ITU-Tの推奨Y.1563、「イーサネットフレームの転送と可用性パフォーマンス」、2009年1月。
[26] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[26] Handley、M.、ed。、Rescorla、E.、ed。、およびIAB、「インターネット拒否の考慮事項」、RFC 4732、2006年12月。
Appendix A. Communication Channel (CCh) Examples
付録A. 通信チャネル（CCH）の例
A CCh can be realized in a number of ways.
CCHはさまざまな方法で実現できます。
1. The CCh can be provided by a link in a physically distinct network, that is, a link that is not part of the transport network that is being managed. For example, the nodes in the transport network can be interconnected in two distinct physical networks: the transport network and the DCN.
1. CCHは、物理的に異なるネットワークのリンク、つまり、管理されている輸送ネットワークの一部ではないリンクによって提供できます。たとえば、トランスポートネットワークのノードは、トランスポートネットワークとDCNという2つの異なる物理ネットワークで相互接続できます。
This is a "physically distinct out-of-band CCh".
これは「物理的に異なる帯域外cch」です。
2. The CCh can be provided by a link in the transport network that is terminated at the ends of the DCC and that is capable of encapsulating and terminating packets of the management protocols. For example, in MPLS-TP, a single-hop LSP might be established between two adjacent nodes, and that LSP might be capable of carrying IP traffic. Management traffic can then be inserted into the link in an LSP parallel to the LSPs that carry user traffic.
2. CCHは、DCCの端で終了し、管理プロトコルのパケットをカプセル化および終了することができる輸送ネットワークのリンクによって提供できます。たとえば、MPLS-TPでは、2つの隣接するノードの間にシングルホップLSPが確立される可能性があり、そのLSPはIPトラフィックを運ぶことができます。その後、管理トラフィックをリンクに挿入して、ユーザートラフィックを運ぶLSPと並行してLSPで挿入できます。
This is a "physically shared out-of-band CCh."
これは、「物理的に共有されている帯域外CCH」です。
3. The CCh can be supported as its native protocol on the interface alongside the transported traffic. For example, if an interface is capable of sending and receiving both MPLS-TP and IP, the IP-based management traffic can be sent as native IP packets on the interface.
3. CCHは、輸送されたトラフィックに加えて、インターフェイス上のネイティブプロトコルとしてサポートできます。たとえば、インターフェイスがMPLS-TPとIPの両方を送信および受信できる場合、IPベースの管理トラフィックはインターフェイス上のネイティブIPパケットとして送信できます。
This is a "shared interface out-of-band CCh".
これは「共有インターフェイス外部CCH」です。
4. The CCh can use overhead bytes available on a transport connection. For example, in TDM networks there are overhead bytes associated with a data channel, and these can be used to provide a CCh. It is important to note that the use of overhead bytes does not reduce the capacity of the associated data channel.
4. CCHは、輸送接続で使用可能なオーバーヘッドバイトを使用できます。たとえば、TDMネットワークでは、データチャネルに関連付けられたオーバーヘッドバイトがあり、これらを使用してCCHを提供できます。オーバーヘッドバイトを使用しても、関連するデータチャネルの容量が低下しないことに注意することが重要です。
This is an "overhead-based CCh".
これは「オーバーヘッドベースのCCH」です。
This alternative is not available in MPLS-TP because there is no overhead available.
この代替手段は、オーバーヘッドが利用できないため、MPLS-TPでは利用できません。
5. The CCh can be provided by a dedicated channel associated with the data link. For example, the generic associated label (GAL) [14] can be used to label DCC traffic being exchanged on a data link between adjacent transport nodes, potentially in the absence of any data LSP between those nodes.
5. CCHは、データリンクに関連付けられた専用チャネルで提供できます。たとえば、一般的な関連ラベル（GAL）[14]を使用して、隣接する輸送ノード間のデータリンクでDCCトラフィックを交換することができます。
This is a "data link associated CCh".
これは「データリンクに関連するCCH」です。
It is very similar to case 2, and by its nature can only span a single hop in the transport network.
これはケース2と非常に似ており、その性質上、輸送ネットワークの1つのホップしか及ばない可能性があります。
6. The CCh can be provided by a dedicated channel associated with a data channel. For example, in MPLS-TP, the GAL [14] can be imposed under the top label in the label stack for an MPLS-TP LSP to create a channel associated with the LSP that can carry management traffic. This CCh requires the receiver to be capable of demultiplexing management traffic from user traffic carried on the same LSP by use of the GAL.
6. CCHは、データチャネルに関連付けられた専用チャネルで提供できます。たとえば、MPLS-TPでは、GAL [14]をMPLS-TP LSPのラベルスタックのトップラベルの下に課すことができ、管理トラフィックを運ぶことができるLSPに関連付けられたチャネルを作成できます。このCCHでは、GALを使用して同じLSPで運ばれたユーザートラフィックから管理トラフィックを非難することができるように受信者が必要です。
This is a "data channel associated CCh".
これは「データチャネルに関連するCCH」です。
7. The CCh can be provided by mixing the management traffic with the user traffic such that is indistinguishable on the link without deep-packet inspection. In MPLS-TP, this could arise if there is a data-carrying LSP between two nodes, and management traffic is inserted into that LSP. This approach requires that the termination point of the LSP be able to demultiplex the management and user traffic. This might be possible in MPLS-TP if the MPLS-TP LSP is carrying IP user traffic.
7. CCHは、管理トラフィックとユーザートラフィックを混合することで提供できます。これにより、ディープパケット検査なしでリンクで区別できません。MPLS-TPでは、2つのノードの間にデータを運ぶLSPがある場合にこれが発生する可能性があり、そのLSPに管理トラフィックが挿入されます。このアプローチでは、LSPの終了点が管理とユーザーのトラフィックを非難することができることが必要です。これは、MPLS-TP LSPがIPユーザートラフィックを運んでいる場合、MPLS-TPで可能です。
This is an "in-band CCh".
これは「インバンドCCH」です。
These realizations can be categorized as:
これらの実現は、次のように分類できます。
A. Out-of-fiber, out-of-band (types 1 and 2) B. In-fiber, out-of-band (types 2, 3, 4, and 5) C. In-band (types 6 and 7)
A.繊維外、帯域外（タイプ1および2）B。繊維、帯域外（タイプ2、3、4、および5）C。インバンド（タイプ6およびタイプ6および7）
The MCN and SCN are logically separate networks and can be realized by the same DCN or as separate networks. In practice, that means that, between any pair of nodes, the MCC and SCC can be the same link or separate links.
MCNとSCNは論理的に個別のネットワークであり、同じDCNまたは個別のネットワークとして実現できます。実際には、それは、ノードのペア間で、MCCとSCCが同じリンクまたは個別のリンクになる可能性があることを意味します。
It is also important to note that the MCN and SCN do not need to be categorised as in-band, out-of-band, etc. This definition only applies to the individual links, and it is possible for some nodes to be connected in the MCN or SCN by one type of link, and other nodes by other types of link. Furthermore, a pair of adjacent nodes can be connected by multiple links of different types.
また、MCNとSCNをインバンド、バンド外などに分類する必要はないことに注意することも重要です。この定義は個々のリンクにのみ適用され、一部のノードが接続される可能性があります。あるタイプのリンクによるMCNまたはSCN、および他のタイプのリンクによる他のノード。さらに、隣接するノードのペアは、異なるタイプの複数のリンクで接続できます。
Lastly, note that the division of DCN traffic between links between a pair of adjacent nodes is purely an implementation choice. Parallel links can be deployed for DCN resilience or load sharing. Links can be designated for specific use. For example, so that some links carry management traffic and some carry control plane traffic, or so that some links carry signaling protocol traffic while others carry routing protocol traffic.
最後に、隣接するノードのペア間のリンク間のDCNトラフィックの分割は、純粋に実装の選択であることに注意してください。並列リンクは、DCNレジリエンスまたは負荷共有のために展開できます。リンクは、特定の使用のために指定できます。たとえば、一部のリンクが管理トラフィックを持ち、一部のリンクには制御プレーントラフィックがある場合、または一部のリンクがシグナリングプロトコルトラフィックを運ぶ場合、他のリンクがルーティングプロトコルトラフィックを運ぶ場合があります。
It is important to note that the DCN can be a routed network with forwarding capabilities, but that this is not a requirement. The ability to support forwarding of management or control traffic within the DCN can substantially simplify the topology of the DCN and improve its resilience, but does increase the complexity of operating the DCN.
DCNは転送機能を備えたルーティングネットワークになる可能性があることに注意することが重要ですが、これは要件ではないことです。DCN内の管理または制御トラフィックの転送をサポートする能力は、DCNのトポロジを大幅に簡素化し、その回復力を改善できますが、DCNの操作の複雑さを高めます。
See also RFC 3877 [11], ITU-T M.20 [12], and Telcordia document GR-833-CORE [13] for further information.
詳細については、RFC 3877 [11]、ITU-T M.20 [12]、およびTelcordia Document GR-833-CORE [13]も参照してください。
Contributor's Address
貢献者の住所
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
Adrian Farrel Old Dog Consultingメール：adrian@olddog.co.uk
Authors' Addresses
著者のアドレス
Eric Gray Ericsson 900 Chelmsford Street Lowell, MA, 01851 Phone: +1 978 275 7470 EMail: Eric.Gray@Ericsson.com
エリック・グレイ・エリクソン900 Chelmsford Street Lowell、MA、01851電話：1 978 275 7470メール：eric.gray@ericsson.com
Scott Mansfield Ericsson 250 Holger Way San Jose CA, 95134 +1 724 931 9316 EMail: Scott.Mansfield@Ericsson.com
スコットマンスフィールドエリクソン250ホルガーウェイサンノゼCA、95134 1 724 931 9316メール：scott.mansfield@ericsson.com
Hing-Kam (Kam) Lam Alcatel-Lucent 600-700 Mountain Ave Murray Hill, NJ, 07974 Phone: +1 908 582 0672 EMail: Kam.Lam@Alcatel-Lucent.com
Hing-kam（Kam）Lam Alcatel-Lucent 600-700 Mountain Ave Murray Hill、NJ、07974電話：1 908 582 0672メール：kam.lam@alcatel-lucent.com