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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この文書では、ジョイントITU-Tの積であり、IETF努力が機能および伝送ネットワークの機能をサポートするために、IETF MPLSと疑似回線エミュレーションエッジ・ツー・エッジ（PWE3）アーキテクチャ内のMPLSトランスポートプロファイル（MPLS-TP）を含むように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.
この文書では、ITU-T G.7710 / Y.1701における要件に拡大[1]、RFC 4377 [2] MPLS-TPネットワークの障害、設定、性能、およびセキュリティ管理をカバーするために、及びオブジェクト情報のための要件モデルは、MPLS-TPネットワークとネットワーク要素を管理するために必要。
In writing this document, the authors assume the reader is familiar with RFCs 5921 [8] and 5950 [9].
この文書を書いにおいて、著者らは、[9] [8]、5950読者がRFCの5921に精通していると仮定する。
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.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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).
異常：アイテムの実際と所望の特性との間で観察することができる最小の不一致。単一の異常の発生が必要な機能を実行する能力の中断を構成しません。異常は（[21]から、3.7節）性能監視（PM）プロセスのための欠陥の検出のための入力として使用されます。
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.).
分散シグナリング通信関連のレイヤ1（物理レイヤ）、レイヤ2（データリンク層）をサポートするネットワーク、およびレイヤ3（ネットワーク層）管理プレーンに関連する分散管理通信のための機能：データ通信ネットワーク（DCN）制御プレーン、およびその他の操作の通信（例えば、オーダーワイヤ/音声通信、ソフトウェアのダウンロード、など）。
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).
失敗：障害原因が終了するために必要な機能を実行するためのアイテムの能力を検討するのに十分な長持続しました。失敗した項目を考慮することができます。障害は、現在（セクション3.25、[21]から）を検出しました。
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).
原因障害：単一妨害または障害が複数の欠陥の検出につながる可能性があります。故障原因（セクション3.27、[21]からの）問題の原因となっている妨害または障害の代表である欠陥を識別することを意図している相関処理の結果です。
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：ネットワークエレメント（NE）MPLS-TPベースのトランスポート・サービスに参加するために必要なMPLSの機能をサポートしています。 MPLS-TPをサポートするために必要とされる機能の詳細については、RFC 5645 [7]を参照。
MPLS-TP network: a network in which MPLS-TP NEs are deployed.
MPLS-TPネットワーク：MPLS-TPのNEが展開されたネットワーク。
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の特徴の一つは、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.
顧客アクセスメンテナンスをサポートするために監視およびテスト機能を含むネットワークのための運用、管理、保守に関連する情報の処理をサポートする機能を実行するシステム、およびプロビジョニング（OAM＆P）：オペレーションシステム（OS）。
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ネットワークを管理するための標準プロトコルとして使用される好適な管理インタフェースプロトコルを指定していません。 CORBA [18]を介してNETCONF [16]またはSNMP [17]を介して、（例えば）一つのドメインを管理している複数のオペレータドメイン間でエンドツーエンドの接続を管理し、別のドメイン、許容されます。
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) 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ドメインとNEと管理接続のためのサポートを定義し、ならびに第3者ネットワークオペレータの制御下でのNEに位置する終端点を有するべきです。マルチキャリア、マルチ転送技術環境の例のシナリオのための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に間接的に接続されている場合、MCCは、間に支持されなければならないMPLS-TPをNE及び任意MPLS-TP NE（複数可）OSへの接続を提供するために使用されます。
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管理プレーンのエンティティはMCNを介して、より具体的にDCNを介して通信する、または。 MCNは、MPLS-TPのNEと管理システム、管理システムと管理システムとを接続し、MPLS-TPのNEとMPLS-TPのNE（セクション3で説明した間接的な接続の場合）。
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 NE間の通信チャネル（CChによって）の実現を可能にするために一般的な関連するチャネル（G-ACH）を定義します。 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のセクション7次のように[6]輸送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で指定されたCChによってデータリンクフレームのカプセル化機能にネットワーク層PDU。
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の接続は、通常のアドレスを持っています。 [8]詳細については、RFC 5921に識別子のセクションを参照。
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;
所与のノードにおけるDCNの動作状態の取得O。
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.
/ DCNにNEによって無効のアクセスを可能にするためにO機能。これは、ネットワークの他の部分に影響を与えるから、それを維持するために誤動作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).
故障原因が設定時間（時間D）連続続く場合4）データプレーン転送経路障害が宣言されなければなりません。障害の原因は、設定時間（時間-C）のために継続的に存在しない場合、障害はクリアされなければなりません。
Note: As an example, the default time values might be as follows:
注意：以下のような例として、デフォルトの時間値は、次のようになります。
Time-D = 2.5 +/- 0.5 seconds
時間D = 2.5 +/- 0.5秒
Time-C = 10 +/- 0.5 seconds
時間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）のMIB - または他のオブジェクト管理セマンティクス仕様 - これらのタイマの設定を可能にするために定義は、明示的にデフォルト値を提供するべきであり、範囲および選択されたデフォルト値が不十分かもしれないシナリオの値の決定方法に関するガイドラインを提供することができます。加えて、そのような仕様は、これらの値のテーブルが定義されるべきでは粒度のレベルを定義する必要があります。
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）1種以上の他のネットワーク技術をサポートするMPLS-TPのNE（例えば、イーサネット、MPLS-TPオーバーSDH / SONET、MPLS）のように、クライアント層に意味のある障害状態に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).
構成管理は、特定のデータを収集し、にデータを提供し、制御のNEする機能を提供します。ネットワーク管理サポートを必要とする特定の構成タスクは、ハードウェアとソフトウェアの構成、（必要な現用と予備パスを含む）の輸送経路をサポートするためのNEの構成、および必要なパスの整合性/接続性とパフォーマンスのモニタリング（すなわち、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.
制御プレーンは、MPLS-TPの実装でサポートされている場合1）、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は、（必要なパスの性能特性の閾値の設定をサポートしなければなりません例えば、損失測定<LM>、遅延測定<DM>しきい値）に必要なMPLS-TPサービス（複数可）のパフォーマンス監視をサポートします。
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）制御プレーンはサポートされ、その制御プレーンは、MPLS-TP NEが経路制御のハンドオフの管理をサポートしなければならないLSPセットアップ/保守のための制御プレーン/管理プレーンハンドオフに対するサポートが含まれている場合。例えば、のRFC 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.
MPLS-TPの搬送路が静的MPLS LSPと疑似回線管理ツールを（既に規格で定義されている又は開発中のいずれか）を使用してプロビジョニングすることができない場合、必要に応じ5）、さらに管理仕様を提供しなければなりません。
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）の一回は、オンデマンド事前にスケジュールや
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]).
オープン暗号アルゴリズム（RFC 3871を参照のA）を使用する[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）攻撃の任意の手段を介して、割り当てられたタスクを実行する、またはその意図されたサービス（S）を提供するから標的を防止しようとする攻撃です。分散DoS攻撃（DDoS攻撃）は、分散攻撃源として位相的作用（及び潜在的に地理的に）するために、複数の（潜在的に損なわ）システムを使用して、（おそらく任意の量だけ）攻撃の重大度を掛けることができます。不要なプロセス、ロギングおよびモニタリング、およびイングレスフィルタリングをオフにする、安全なプロトコルを使用して、DoS攻撃とDDoS攻撃のための影響と可能性を少なくすることができます。 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（またはDDoS攻撃）攻撃を軽減するための追加のメカニズムをサポートしなければなりません。
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.
著者/編集者は感謝エードリアンファレル、アレクサンダーVainshtein、アンドレア・マリア・マッツィーニ、ベン・ニーヴン・ジェンキンス、ベルントZeuner、ダンRomascanu、ダニエルCeccarelli、ディエゴ・Caviglia、ディーターBeller、彼嘉、レオが提供する思慮深いレビュー、コメント、説明を認めますシャオ、マールテンVissers、ニールハリソン、ロルフ・冬、ヨアフコーエン、とゆう梁。
[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]ナドー、T.、モロー、M.、ツバメ、G.、アラン、D.、およびS.松島を、RFC 4377 "を運用管理（OAM）の要件は、マルチプロトコルラベル（MPLS）ネットワークを交換するための" 、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.、エド。、ウォード、D.、エド。、およびM.ベッツ、エド。、 "運用、管理、および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]・ジョーンズ、G.、エド。、RFC 3871 "大規模なインターネットサービスプロバイダー（ISP）IPネットワークインフラの運用セキュリティ要件"、2004年9月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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]ニーヴン、ジェンキンス、B.、編。、Brungard、D.、編、ベッツ、M.編、Sprecher、N.、およびS.上野、 "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]ボッチ、M.編、ブライアント、S.、エド。、霜、D.、編、Levrau、L.、およびL.バーガー、 "トランスポートネットワークにおけるMPLSのための枠組み"、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]マンスフィールド、S.編、グレー、E.、エド。、およびK.ラム、エド。、RFC 5950、2010年9月、 "MPLSベースのトランスポートネットワークのためのネットワーク管理フレームワーク"。
[10] Beller, D. and A. Farrel, "An In-Band Data Communication Network For the MPLS Transport Profile", RFC 5718, January 2010.
[10]、RFC 5718 "MPLSトランスポートプロファイルのインバンドデータ通信ネットワーク" Beller、D.とA.ファレル、2010年1月。
[11] Chisholm, S. and D. Romascanu, "Alarm Management Information Base (MIB)", RFC 3877, September 2004.
[11]チザム、S.およびD. Romascanu、 "アラーム管理情報ベース（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）、5号、2004年8月。
[14] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.
[14]ボッチ、M.、エド。、Vigoureux、M.、エド。、およびS.ブライアント、エド。、 "MPLSジェネリック関連チャンネル"、RFC 5586、2009年6月。
[15] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, November 2009.
[15]ハリントン、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]エンス、R.、編、Bjorklund、M.、編、Schoenwaelder、J.、編、及びA. Bierman、編、 "ネットワーク構成プロトコル（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.、エド。、STD 62、RFC 3416、2002年12月 "簡易ネットワーク管理プロトコル（SNMP）のためのプロトコル操作のバージョン2"。
[18] OMG Document formal/04-03-12, "The Common Object Request Broker: Architecture and Specification", Revision 3.0.3. March 12, 2004.
[18] OMGドキュメントの正式/ 04-03-12、「共通オブジェクト・リクエスト・ブローカー：アーキテクチャおよび仕様」、改訂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.、李、D.、およびD. McDysan、 "（GMPLS）ネットワークスイッチング汎用マルチプロトコルラベルに永久接続およびスイッチ接続との間の変換のための要件"、RFC 5493年4月2009。
[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.、李、D.、およびS. Bardalai、「LSPハンドオーバのためのRSVP-TEシグナリング拡張管理プレーンからでコントロールプレーンにGMPLS対応しますトランスポートネットワーク」、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]ラム、H.、フイン、A.、およびD.パーキンス、 "アラーム報告コントロール管理情報ベース（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]ハンドリー、M.、エド。、レスコラ、E.、エド。、および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において、シングルホップのLSPは、2つの隣接ノード間で確立されるかもしれない、その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]は、潜在的にそれらのノードの間で任意のデータLSPが存在しない場合に、隣接する伝送装置間のデータリンク上で交換される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と非常に類似しており、その性質によってのみトランスポートネットワーク内の複数のホップにまたがることができます。
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]管理トラフィックを運ぶことができるLSPに関連するチャネルを作成するために、MPLS-TP 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がディープパケットインスペクション無しリンク上区別できないようなユーザトラフィックと管理トラフィックを混合することによって提供することができます。データ搬送LSPを2つのノード間に存在する場合、MPLS-TPでは、これが発生する可能性があり、管理トラフィックは、その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及び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ドキュメントGR-833-CORE [13]。
Contributor's Address
寄稿者の住所
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
エードリアンファレル老犬のコンサルティングメール：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チェルムズフォードストリートローウェル、MA、01851電話：+1 978 275 7470 Eメール：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 Eメール：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
興・カム（カム）ラムアルカテル・ルーセント600-700マウンテンアベニューマレーヒル、NJ、07974電話：+1 908 582 0672 Eメール：Kam.Lam@Alcatel-Lucent.com