Internet Engineering Task Force (IETF) S. Mansfield, Ed.
Request for Comments: 5950 E. Gray, Ed.
Category: Informational Ericsson
ISSN: 2070-1721 K. Lam, Ed.
Alcatel-Lucent
September 2010
Network Management Framework for MPLS-based Transport Networks
Abstract
抽象
This document provides the network management framework for the Transport Profile for Multi-Protocol Label Switching (MPLS-TP).
この文書では、マルチプロトコルラベルスイッチング（MPLS-TP）のためのトランスポートプロファイルのネットワーク管理フレームワークを提供します。
This framework relies on the management terminology from the ITU-T to describe the management architecture that could be used for an MPLS-TP management network.
このフレームワークは、MPLS-TP管理ネットワークのために使用することができる管理アーキテクチャを説明するためのITU-Tから管理用語に依存しています。
The management of the MPLS-TP network could be based on multi-tiered distributed management systems. This document provides a description of the network and element management architectures that could be applied and also describes heuristics associated with fault, configuration, and performance aspects of the management system.
MPLS-TPネットワークの管理は、多層分散管理システムに基づくことができます。この文書では、適用することができるネットワーク要素管理アーキテクチャの記述を提供し、障害、設定、及び管理システムのパフォーマンスの側面に関連付けられたヒューリスティックを記述する。
This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network.
この文書は、共同IETF（Internet Engineering Task Force）のパケットの能力と機能をサポートするために、IETF MPLSとPWE3アーキテクチャ内のMPLSトランスポートプロファイルを含むように/国際電気通信連合電気通信標準化部門（ITU-T）の努力の産物でありますトランスポートネットワーク。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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/rfc5950.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5950で取得することができます。
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Management Architecture . . . . . . . . . . . . . . . . . . . 5
2.1. Network Management Architecture . . . . . . . . . . . . . 5
2.2. Element Management Architecture . . . . . . . . . . . . . 6
2.3. Standard Management Interfaces . . . . . . . . . . . . . . 10
2.4. Management- and Control-Specific Terminology . . . . . . . 11
2.5. Management Channel . . . . . . . . . . . . . . . . . . . . 11
3. Fault Management . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Supervision . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Validation . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3. Alarm Handling . . . . . . . . . . . . . . . . . . . . . . 13
4. Configuration Management . . . . . . . . . . . . . . . . . . . 13
4.1. LSP Ownership Handover . . . . . . . . . . . . . . . . . . 14
5. Performance Management . . . . . . . . . . . . . . . . . . . . 15
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . . 17
This document provides the network management framework for the Transport Profile for Multi-Protocol Label Switching (MPLS-TP). Requirements for network management in an MPLS-TP network are documented in "Network Management Requirements for MPLS-based Transport Networks" [3], and this document explains how network elements and networks that support MPLS-TP can be managed using solutions that satisfy those requirements. The relationship between Operations, Administration, and Maintenance (OAM), management, and other framework documents is described in the MPLS-TP framework [4] document.
この文書では、マルチプロトコルラベルスイッチング（MPLS-TP）のためのトランスポートプロファイルのネットワーク管理フレームワークを提供します。 MPLS-TPネットワーク内のネットワーク管理のための要件は、「MPLSベースのトランスポート・ネットワークのネットワーク管理の要件」[3]に記載されていて、このドキュメントは、MPLS-TPをサポートするネットワーク要素とネットワークは、それらを満たすソリューションを使用して管理する方法を説明します要件。運用、管理、および保守（OAM）、管理、および他のフレームワークのドキュメントとの関係は、MPLS-TPフレームワーク[4]の文書に記載されています。
This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network.
この文書は、共同IETF（Internet Engineering Task Force）のパケットの能力と機能をサポートするために、IETF MPLSとPWE3アーキテクチャ内のMPLSトランスポートプロファイルを含むように/国際電気通信連合電気通信標準化部門（ITU-T）の努力の産物でありますトランスポートネットワーク。
This framework relies on the management terminology from the ITU-T to describe the management architecture that could be used for an MPLS-TP management network. The terminology listed below are taken from/based on the definitions found in ITU-T G.7710 [6], ITU-T G.7712 [7], and ITU-T M.3013 [13].
このフレームワークは、MPLS-TP管理ネットワークのために使用することができる管理アーキテクチャを説明するためのITU-Tから管理用語に依存しています。下記の用語は、ITU-T G.7710に見出される定義に基づいて/から取得され[6]、ITU-T G.7712 [7]、およびITU-T M.3013 [13]。
o Communication Channel (CCh): A logical channel between network elements (NEs) that can be used in (for example) management plane applications or control plane applications. For MPLS-TP, the physical channel supporting the CCh is the MPLS-TP Management Communication Channel (MCC).
O通信チャネル（CChによって）、（例えば）管理プレーンアプリケーション又は制御プレーン用途に使用することができるネットワーク要素（NES）との間の論理チャネル。 MPLS-TPの場合は、CChによってをサポートする物理チャネルは、MPLS-TP管理通信チャネル（MCC）です。
o Data Communication Network (DCN): A network that supports Layer 1 (physical), Layer 2 (data-link), and Layer 3 (network) 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.). See ITU-T G.7712 [7].
レイヤ1（物理）、レイヤ2（データリンク）をサポートするネットワーク、とに関連する分散シグナリング通信用管理プレーンに関連する分散管理通信のためのレイヤ3（ネットワーク）機能、：Oデータ通信ネットワーク（DCN）制御プレーン、およびその他の操作の通信（例えば、オーダーワイヤ/音声通信、ソフトウェアのダウンロード、など）。 ITU-T G.7712 [7]を参照。
o Equipment Management Function (EMF): The management functions within an NE. See ITU-T G.7710 [6].
O機器管理機能（EMF）：NE内の管理機能。 ITU-T G.7710 [6]を参照。
o Local Craft Terminal (LCT): An out-of-band device that connects to an NE for management purposes. See ITU-T G.7710 [6].
Oローカルクラフトターミナル（LCT）：管理目的のためにNEに接続するアウトオブバンドデバイス。 ITU-T G.7710 [6]を参照。
o Label Switched Path (LSP): An MPLS-TP LSP is an LSP that uses a subset of the capabilities of an MPLS LSP in order to meet the requirements of an MPLS transport network as described in the MPLS-TP framework [4].
Oラベルスイッチパス（LSP）は：MPLS-TP LSPは、MPLS-TPフレームワーク[4]で説明されるようにMPLSトランスポートネットワークの要件を満たすためにMPLS LSPの機能のサブセットを使用するLSPです。
o Management Application Function (MAF): An application process that participates in system management. See ITU-T G.7710 [6].
O管理アプリケーション機能（MAF）：システム管理に参加するアプリケーションプロセス。 ITU-T G.7710 [6]を参照。
o Management Communication Channel (MCC): A CCh dedicated for management plane communications. See ITU-T G.7712 [7].
O管理通信チャネル（MCC）：管理プレーン通信用に専用のCChによって。 ITU-T G.7712 [7]を参照。
o Message Communication Function (MCF): The communications process that performs functions such as information interchange and relay. See ITU-T M.3013 [13].
Oメッセージ通信機能（MCF）：そのような情報交換及びリレーとしての機能を実行する通信プロセス。 ITU-T M.3013 [13]を参照。
o Management Communication Network (MCN): A DCN supporting management plane communication is referred to as a Management Communication Network (MCN). See ITU-T G.7712 [7].
O管理通信ネットワーク（MCN）は：DCN支持管理プレーン通信は、管理通信ネットワーク（MCN）と呼ばれます。 ITU-T G.7712 [7]を参照。
o MPLS-TP NE: A network element (NE) that supports MPLS-TP functions. Another term that is used for a network element is node. In terms of this document, the term node is equivalent to NE.
O MPLS-TPのNE：MPLS-TPの機能をサポートするネットワークエレメント（NE）。ネットワーク要素のために使用される他の用語は、ノードです。このドキュメントの面では、ノードという用語は、NEと同等です。
o MPLS-TP network: A network in which MPLS-TP NEs are deployed.
O MPLS-TPネットワーク：MPLS-TPのNEが展開されるネットワーク。
o Network Element Function (NEF): The set of functions necessary to manage a network element. See ITU-T M.3010 [11].
Oネットワーク要素関数（NEF）：ネットワーク要素を管理するために必要な機能のセット。 ITU-T M.3010 [11]を参照。
o Operations, Administration, and Maintenance (OAM): For the MPLS-TP effort the term OAM means the set of tools that consist of "operation" activities that are undertaken to keep the network up and running, "administration" activities that keep track of resources in the network and how they are used, and "maintenance" activities that facilitate repairs and upgrades. For a complete expansion of the acronym, see "The OAM Acronym Soup" [15].
O操作、管理、および保守（OAM）：MPLS-TPの努力のために用語OAMが稼働中のネットワークを維持するために行われ、「操作」の活動で構成されてツールのセットを意味し、追跡するため、「管理」活動ネットワーク内のリソースとそれらがどのように使用され、「メンテナンス」の活動の修理やアップグレードを容易にします。頭字語の完全な拡張のために、「OAM頭字スープ」[15]を参照。
o Operations System (OS): A system that performs the functions that support processing of information related to operations, administration, maintenance, and provisioning (OAM&P) (see "The OAM Acronym Soup" [15]) for the networks, including surveillance and testing functions to support customer access maintenance. See ITU-T M.3010 [11].
Oオペレーションシステム（OS）：監視を含むネットワークの動作に関連する情報の処理をサポートする機能を実行するシステム、管理、保守、および（OAM＆P）をプロビジョニング（「OAM頭文字スープ」[15]を参照）、および顧客のアクセスの維持をサポートするための機能をテストします。 ITU-T M.3010 [11]を参照。
o Signaling Communication Network (SCN): A DCN supporting control plane communication is referred to as a Signaling Communication Network (SCN). See ITU-T G.7712 [7].
Oシグナリング通信ネットワーク（SCN）は：DCN支援制御プレーン通信は、シグナリング通信ネットワーク（SCN）と呼ばれます。 ITU-T G.7712 [7]を参照。
o Signaling Communication Channel (SCC): A CCh dedicated for control plane communications. The SCC may be used for GMPLS/ASON signaling and/or other control plane messages (e.g., routing messages). See ITU-T G.7712 [7].
Oシグナリング通信チャネル（SCC）：コントロールプレーンの通信に専用のCChによって。 SCCは、GMPLS / ASONシグナリングおよび/または他の制御プレーンメッセージ（例えば、メッセージルーティング）のために使用することができます。 ITU-T G.7712 [7]を参照。
The management of the MPLS-TP network could be based on a multi-tiered distributed management systems, for example as described in ITU-T M.3010 [11] and ITU-T M.3060/Y.2401 [12]. Each tier provides a predefined level of network management capabilities. The lowest tier of this organization model includes the MPLS-TP network element that provides the transport service and the Operations System (OS) at the Element Management Level. The Management Application Function (MAF) within the NEs and OSs provides the management support. The MAF at each entity can include agents only, managers only, or both agents and managers. The MAF that includes managers is capable of managing an agent included in other MAF.
ITU-T M.3010 [11]とITU-T M.3060 / Y.2401 [12]に記載されているように、MPLS-TPネットワークの管理は、例えば、多階層分散管理システムに基づくことができます。各層は、ネットワーク管理機能の所定のレベルを提供します。この組織モデルの最下層には、要素管理レベルでの輸送サービスおよびオペレーションシステム（OS）を提供MPLS-TPネットワーク要素を含んでいます。管理アプリケーション機能（MAF）のNEとOS内の管理サポートを提供します。各エンティティにおけるMAFは、エージェントのみ、マネージャのみ、または両方のエージェントとマネージャを含むことができます。マネージャを含むMAF MAFは、他に含まれるエージェントを管理することが可能です。
The management communication to peer NEs and/or OSs is provided via the Message Communication Function (MCF) within each entity (e.g., NE and OS). The user can access the management of the MPLS-TP transport network via a Local Craft Terminal (LCT) attached to the NE or via a Work Station (WS) attached to the OS.
管理通信は、NEをピア及び/またはOSが各エンティティ（例えば、NE及びOS）内のメッセージ通信機能（MCF）を介して提供されます。ユーザーは、NEやOSに付属のワークステーション（WS）を介して接続されているローカルクラフトターミナル（LCT）を介してMPLS-TPのトランスポートネットワークの管理にアクセスすることができます。
A transport Management Network (MN) may consist of several transport-technology-specific Management Networks. Management network partitioning (Figure 1) below (based on ITU-T G.7710 [6]) shows the management network partitioning. Notation used in G.7710 for a transport-technology-specific MN is x.MN, where x is the transport-specific technology. An MPLS-TP-specific MN is abbreviated as MT.MN. Where there is no ambiguity, we will use "MN" for an MPLS-TP-specific MN. In the figure below, O.MSN is equivalent to an OTN management Subnetwork.
輸送管理ネットワーク（MN）は、いくつかのトランスポートテクノロジ固有の管理ネットワークからなるものであってもよいです。 （ITU-T G.7710に基づいて、[6]）以下管理ネットワーク分割（図1）は、管理ネットワークの分割を示します。トランスポート技術特有のMNのためにG.7710で使用される表記は、xはトランスポート固有技術であるx.MN、です。 MPLS-TP-特有のMNはMT.MN.と略記されますあいまいがない場合は、我々は、MPLS-TP-特定MNのための「MN」を使用します。下の図では、O.MSNは、OTN管理サブネットワークと同等です。
______________________________ _________________________________
|.-------.-------.----.-------.||.--------.--------.----.--------.|
|: : : : :||: : : : :|
|:O.MSN-1:O.MSN-2: .. :O.MSN-n:||:MT.MSN-1:MT.MSN-2: .. :MT.MSN-n:|
|: : : : :||: : : : :|
'-============================-''-===============================-'
_______________________________
|.-------.-------.-----.-------.|
|: : : : :|
|:x.MSN-1:x.MSN-2: ... :x.MSN-n:|
|: : : : :|
'-=============================-'
Management Network Partitioning
管理ネットワークパーティション
Figure 1
図1
The management of the MPLS-TP network is separable from the management of the other technology-specific networks, and it operates independently of any particular client- or server-layer management plane.
MPLS-TPネットワークの管理は、他の技術特有のネットワークの管理から分離可能であり、それは独立して、任意の特定のクライアント - サーバまたはレイヤ管理プレーンの動作します。
An MPLS-TP Management Network (MT.MN) could be partitioned into MPLS-TP Management SubNetworks ("MT.MSN" or "MPLS-TP MSN", or just "MSN" where usage is unambiguous) for consideration of scalability (e.g., geographic or load balancing) or administration (e.g., operation or ownership).
MPLS-TP管理ネットワーク（MT.MN）は、拡張性の検討のためにMPLS-TP管理サブネットワーク（「MT.MSN」または「MPLS-TP MSN」、または使用があいまいで、単に「MSN」）に分割することができた（例えば、地理的またはロードバランシング）または投与（例えば、操作または所有権）。
The MPLS-TP MSN could be connected to other parts of the MN through one or more LCTs and/or OSs. The Message Communication Function (MCF) of an MPLS-TP NE initiates/terminates, routes, or otherwise processes management messages over CChs or via an external interface.
MPLS-TPのMSNは、一つ以上のLCTs及び/またはOSを介してMNの他の部分に接続することができます。 MPLS-TP NEのメッセージ通信機能（MCF）は、開始/終了、経路、または他の方法でCCHS上または外部インターフェースを介して管理メッセージを処理します。
Multiple addressable MPLS-TP NEs could be present at a single physical location (i.e., site or office). The inter-site communications link between the MPLS-TP NEs will normally be provided by the CChs. Within a particular site, the NEs could communicate via an intra-site CCh or via a LAN.
複数のアドレス指定可能MPLS-TPのNEは、単一の物理的な場所（すなわち、サイトまたはオフィス）に存在し得ます。 MPLS-TP NE間のサイト間の通信リンクは、通常、CCHSによって提供されます。特定のサイト内で、NEがイントラサイトCChによって介して、またはLANを介して通信することができます。
The Equipment Management Function (EMF) of an MPLS-TP NE provides the means through which a management system manages the NE.
MPLS-TP NEの機器管理機能（EMF）は、管理システムがNEの管理を行う手段を提供します。
The EMF interacts with the NE's transport functions by exchanging Management Information (MI) across the Management Point (MP) Reference Points. The EMF may contain a number of functions that provide a data reduction mechanism on the information received across the MP Reference Points.
EMFは、管理ポイント（MP）参照ポイント間で管理情報（MI）を交換することにより、NEのトランスポート機能と相互に作用します。 EMFは、MP基準点を横切って受信した情報にデータ減速機構を提供する多数の機能を含んでいてもよいです。
The EMF includes functions such as Date and Time, FCAPS (Fault, Configuration, Accounting, Performance, and Security) management, and Control Plane functions. The EMF provides event message processing, data storage, and logging. The management Agent, a component of the EMF, converts internal management information (MI signals) into Management Application messages and vice versa. The Agent responds to Management Application messages from the Message Communication Function (MCF) by performing the appropriate operations on (for example) the Managed Objects in a Management Information Base (MIB), as necessary. The MCF contains communications functions related to the world outside of the NE (i.e., Date and Time source, Management Plane, Control Plane, Local Craft Terminal, and Local Alarms).
EMFは、日付と時刻、FCAPS（障害、設定、アカウンティング、パフォーマンス、セキュリティ）管理、およびコントロールプレーン機能などの機能が含まれています。 EMFは、イベントメッセージ処理、データストレージ、およびロギングを提供します。管理エージェント、EMFのコンポーネントは、管理アプリケーション・メッセージとその逆に内部管理情報（MI信号）に変換します。エージェントは、必要に応じて管理情報ベース（MIB）、中（例えば）の管理対象オブジェクトに適切な操作を行うことで、メッセージ通信機能（MCF）から管理アプリケーションのメッセージに応答します。 MCFは、NE（すなわち、日付と時刻のソース、管理プレーン、コントロールプレーン、ローカルクラフトターミナル、ローカルアラーム）の外の世界に関連する通信機能が含まれています。
The Date and Time functions keep track of the NE's date/time, which is used by the FCAPS management functions to e.g., time stamp event reports.
日付と時刻の関数は、例えばするFCAPS管理機能で使用されているNEの日付/時刻、タイムスタンプイベントレポートを追跡します。
Below are diagrams that illustrate the components of the Equipment Management Function (EMF) of a Network Element (NE). The high-level decomposition of the Network Element Function (NEF) picture (Figure 2) provides the breakdown of the NEF, then the EMF picture (Figure 3) provides the details of Equipment Management Function, and finally the Message Communication Function (MCF) picture (Figure 4) details the MCF.
以下は、ネットワーク要素（NE）の機器管理機能（EMF）の構成要素を示す図です。ネットワーク要素関数（NEF）画像（図2）の高レベルの分解はNEFの内訳を提供し、その後、EMFピクチャ（図3）は、機器管理機能の詳細を提供し、最終的にメッセージ通信機能（MCF）画像（図4）は、MCFを詳述します。
____________________________________________________
| Network Element Function (NEF) |
| _________________________________________ |
|| | |
|| Transport Plane Atomic Functions | |
||_________________________________________| |
| | |
| | Management |
| | Information |
| ___________________|_________________ |
| | (from date/time)<-----------+ |
| | Equipment | | |
| | Management (to/from management)<--------+ | |
| | Function | | | |
| | (EMF) (to/from control)<-----+ | | |
| | | | | | |
| | (to local alarm)---+ | | | |
| |_____________________________________| | | | | |
| | | | | |
| +--------------------------------------+ | | | |
| | +---------------------------------------+ | | |
| | | +----------------------------------------+ | |
| | | | +-----------------------------------------+ |external
| | | | | Date & Time _________________ |time
| | | | | Interface | Message | |source
| | | | +-------------- Communication <-----------------------
| | | | | Function (MCF) | |
| | | | Management | | |management
| | | +----------------> | |plane
| | | Plane Interface <---------------------->
| | | | | |local
| | | | | |craft
| | | Control Plane | | |terminal
| | +------------------> <---------------------->
| | Interface | | |control
| | | | |plane
| | Local Alarm | <---------------------->
| +--------------------> | |
| Interface | | |to local
| | | |alarms
| |_________________--------------------->
|____________________________________________________|
High-Level Decomposition of NEF
NEFのハイレベルの分解
Figure 2
図2
______________________________________________________
| _______________________________________ |
| Equipment | Management Application ||
| Management | Function (MAF) ||
| Function | _________________ ||
| (EMF) || | __________________||
| ___________||_______________ | | ||
| | | | | Date & Time ||
| | Date & Time Functions | | | Interface ||<-- 1
| |____________________________| | |__________________||
| ___________||_______________ | __________________||
| | | | | ||
| | Fault Management | | | Management ||
| |____________________________| | | Plane Interface ||<-> 2
| ___________||_______________ | |__________________||
| | | | ||
| | Configuration Management | | __________________||
| |____________________________| | | ||
| ___________||_______________ | | Control ||
| | | | | Plane Interface ||<-> 3
| | Account Management | | |__________________||
| |____________________________| | ||
| ___________||_______________ | ||
| | | | ||
| | Performance Management | | ||
| |____________________________| | ||
| ___________||_______________ | ||
| | | | ||
| | Security Management | | ||
| |____________________________| | ||
| ___________||_______________ | ||
| | | | ||
| | Control Plane Function | | ||
| |____________________________| | ||
| || | __________________||
| || | | ||
| || | | Local Alarm ||
| +----->| Agent | | Interface ||--> 4
| v ||_________________| |__________________||
| .-===-. |_______________________________________||
| | MIB | |
| `-._.-' |
|______________________________________________________|
Equipment Management Function
機器管理機能
Figure 3
図3
_________________
| |
| Message |
| Communication |
| Function (MCF) |
| _______________ |
Date & Time || || external
1 <--------------|| Date & Time ||<--------------
Information || Communication || time source
||_______________||
| |
| _______________ |
Management || || management
Plane || Management || plane
2 <------------->|| Plane ||<------------->
Information || Communication || (e.g. - EMS,
||_______________|| peer NE)
| |
| _______________ | control
Control Plane || || plane
3 <------------->|| Control Plane ||<------------->
Information || Communication || (e.g. - EMS,
||_______________|| peer NE)
| : |
| : | local craft
| : | terminal
| : |<------------->
| _______________ |
Local Alarm || || to local
4 -------------->|| Local Alarm ||-------------->
Information || Communication || alarms...
||_______________||
|_________________|
Message Communication Function
メッセージ通信機能
Figure 4
図4
The "Network Management Requirements for MPLS-based Transport Networks" document [3] places no restriction on which management interface is to be used for managing an MPLS-TP network. It is possible to provision and manage an end-to-end connection across a network where some segments are created/managed/deleted, for example by NETCONF or SNMP and other segments by CORBA interfaces. Use of any network management interface for one management-related purpose does not preclude use of another network management interface for other management-related purposes, or the same purpose at another time. The protocol(s) to be supported are at the discretion of the operator.
文書「MPLSベースのトランスポート・ネットワークのネットワーク管理要件」[3]管理インターフェイスは、MPLS-TPネットワークを管理するために使用されるべきでは制限を配置しません。それは規定することができ、NETCONFまたはSNMPおよびCORBAインタフェースによって他のセグメントによって、例えば、いくつかのセグメントが作成される/削除/管理ネットワークを介してエンド・ツー・エンドの接続を管理します。一つの管理に関連した目的のために任意のネットワーク管理インターフェースの使用は、他の管理に関連する目的、または別の時に同じ目的のために他のネットワーク管理インターフェースの使用を排除するものではありません。サポートするプロトコル（単数または複数）は、オペレータの裁量です。
Data Communication Network (DCN) is the common term for the network used to transport Management and Signaling information between: management systems and network elements, management systems to other management systems, and networks elements to other network elements. The Management Communications Network (MCN) is the part of the DCN that supports the transport of Management information for the Management Plane. The Signaling Communications Network (SCN) is the part of the DCN that supports transport of signaling information for the Control Plane. As shown in , the communication channel terminology picture (Figure 5) each technology has its own terminology that is used for the channels that support the transfer of management and control plane information. For MPLS-TP, the management plane uses the Management Communication Channel (MCC), and the control plane uses the Signaling Communication Channel (SCC).
他のネットワーク要素への管理システムとネットワーク要素、他の管理システムへの管理システム、およびネットワーク・エレメント：データ通信ネットワーク（DCN）は、間の管理とシグナリング情報を転送するために使用されるネットワークのための一般的な用語です。管理通信ネットワーク（MCN）管理プレーンのための経営情報の転送をサポートDCNの一部です。シグナリング通信ネットワーク（SCN）は、制御プレーンのシグナリング情報の転送をサポートDCNの一部です。示すように、通信チャネルの用語画像（図5）各技術は、管理及び制御プレーン情報の転送をサポートするチャネルのために使用される独自の用語を持っています。 MPLS-TPの場合は、管理プレーンは、管理通信チャネル（MCC）を使用し、コントロールプレーンは、シグナリング通信チャネル（SCC）を使用しています。
The Communication Channel (CCh) provides a logical channel between NEs for transferring Management and/or Signaling information. Note that some technologies provide separate communication channels for Management (MCC) and Signaling (SCC).
通信チャネルには管理を転送および/または情報をシグナリングするためにNE間の論理チャネルを提供します。いくつかの技術は管理（MCC）とシグナリング（SCC）のための別々の通信チャネルを提供することに注意してください。
MPLS-TP NEs communicate via the DCN. The DCN connects NEs with management systems, NEs with NEs, and management systems with management systems.
MPLS-TPのNEは、DCNを介して通信します。 DCNは、管理システムと管理システムのNEとのNE、及び管理システムとNEを接続します。
Common Terminology ____
__________ __________ | |
| | | | /->| NE | \ ____
|Management| |Operations| / |____| \ | |
|Station | <---> |System | |(CCh) | NE |
|__________| |__________| \ _|__ / |____|
\->| | /
| NE |
|____|
Network Elements use a Communication
Channel (CCh) for Transport of Information
Management Terminology ____
__________ __________ | |
| | | | /->| NE | \ ____
|Management| |Operations| / |____| \ | |
|Station | <---> |System | |(MCC) | NE |
|__________| |__________| \ _|__ / |____|
\->| | /
| NE |
|____|
Network Elements use a Management
Communication Channel (MCC) for Transport
of Management Information
Control Terminology ____
__________ __________ | |
| | | | /->| NE | \ ____
|Management| |Operations| / |____| \ | |
|Station | <---> |System | |(SCC) | NE |
|__________| |__________| \ _|__ / |____|
\->| | /
| NE |
|____|
Network Elements use a Control/Signaling
Communication Channel (SCC) for Transport
of Signaling Information
Communication Channel Terminology
通信チャネルの用語
Figure 5
図5
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. Fault management provides the mechanisms to detect, verify, isolate, notify, and recover from the fault.
障害が必要なアクションを実行するための機能のできないことです。これは、予防保守、外部リソースの不足、または計画されたアクションにできないことが含まれていません。障害管理は、検出検証、切り分け、通知、および障害から回復するためのメカニズムを提供します。
ITU-T G.7710 [6] lists five basic categories of supervision that provide the functionality necessary to detect, verify, and notify a fault. The categories are: Transmission Supervision, Quality of Service Supervision, Processing Supervision, Hardware Supervision, and Environment Supervision. Each of the categories provides a set of recommendations to ensure that the fault management process is fulfilled.
ITU-T G.7710 [6]は、検出を確認し、障害を通知するために必要な機能を提供する監督の5つの基本的なカテゴリを示します。カテゴリは次のとおりです。トランスミッション監督、サービス監督の品質、加工監督、ハードウェアの監督、および環境監督。カテゴリーのそれぞれには、障害管理プロセスが満たされることを保証するための推奨のセットを提供します。
ITU-T G.7710 [6] describes a fault cause as a limited interruption of the required function. It is not reasonable for every fault cause to be reported to maintenance personnel. The validation process is used to turn fault causes (events) into failures (alarms).
ITU-T G.7710 [6]は、必要な機能の限られた中断として、障害の原因を説明しています。すべての障害の原因は、保守要員に報告されることは合理的ではありません。検証プロセスは失敗（アラーム）に、故障の原因（イベント）を回すために使用されています。
Within an element management system, it is important to consider mechanisms to support severity assignment, alarm reporting control, and logging.
要素管理システムの中では、それは重要度の割り当て、警報報告制御、およびロギングをサポートするための仕組みを検討することが重要です。
Configuration management provides the mechanisms to:
構成管理はへのメカニズムを提供します。
o provision the MPLS-TP services
Oの提供MPLS-TPサービス
o set up security for the MPLS-TP services and MPLS-TP network elements
O MPLS-TPサービスとMPLS-TPネットワーク要素のセキュリティを設定
o provide the destination for fault notifications and performance parameters
O障害通知と性能パラメータの保存先を提供
o configure and control OAM
O configureと制御OAM
Also associated with configuration management are hardware and software provisioning and inventory reporting.
また、構成管理に関連するハードウェアとソフトウェアのプロビジョニングおよびインベントリレポートです。
MPLS-TP networks can be managed not only by Network Management Systems (i.e., Management Plane (MP)), but also by Control Plane (CP) protocols. The utilization of the control plane is not a mandatory requirement (see MPLS-TP Requirements [2]), but it is often used by network operators in order to make network configuration and Label Switched Path (LSP) recovery both faster and simpler.
MPLS-TPネットワークは、ネットワーク管理システム（すなわち、管理プレーン（MP））によって、だけでなく、制御プレーン（CP）プロトコルによってだけでなく、管理することができます。コントロールプレーンの利用が必須要件ではなく、両方の高速かつシンプルなネットワーク構成やラベルスイッチパス（LSP）の回復を作るために、それは多くの場合、ネットワークオペレータによって使用されている（[2] MPLS-TPの要件を参照してください）。
In networks where both CP and MP are provided, an LSP could be created by either (CP or MP). The entity creating an LSP owns the data plane resources comprising that LSP. Only the owner of an LSP is typically able to modify/delete it. This results in a need for interaction between the MP and CP to allow either to manage all the resources of a network.
両方CPとMPが設けられているネットワークにおいて、LSPは、（CPまたはMP）によって作成することができます。 LSPを作成エンティティは、そのLSPを含むデータプレーンリソースを所有しています。 LSPの所有者のみが一般的にそれを削除/変更することができます。これは、どちらかは、ネットワークのすべてのリソースを管理することを可能にするMPとCPの間の相互作用のために必要になります。
Network operators might prefer to have full control of the network resources during the set-up phase and then allow the network to be automatically maintained by the Control Plane. This can be achieved by creating LSPs via the Management Plane and subsequently transferring LSP ownership to the Control Plane. This is referred to as "ownership handover" RFC 5493 [10]. MP to CP ownership handover is then considered a requirement where a Control Plane is in use that supports it. The converse (CP to MP ownership handover) is a feature that is recommended -- but not required -- for (G)MPLS networks because it has only minor applications (for example, moving LSPs from one path to another as a maintenance operation).
ネットワークオペレータは、セットアップフェーズ中にネットワークリソースの完全な制御を持っているし、ネットワークを自動的に制御プレーンによって維持されることを可能にすることを好むかもしれません。これは、管理プレーンを経由してLSPを作成し、その後、コントロールプレーンにLSPの所有権を移転することによって達成することができます。これは、「所有ハンドオーバ」RFC 5493 [10]と呼ばれています。 CPの所有権へのハンドオーバMPはその後、コントロールプレーンがそれをサポートして使用されている要件と考えられています。それはわずかなアプリケーション（例えば、メンテナンス動作として別のパスからLSPを移動する）を有しているので、（G）MPLSネットワークの - 必須ではない - 逆（MP所有ハンドオーバCP）が推奨される特徴であります。
The LSP handover procedure has already been standardized for GMPLS networks, where the signaling protocol used is RSVP-TE (RFC 3209 [1]). The utilization of RSVP-TE enhancements are defined in [5].
LSPハンドオーバ手順が既に使用されるシグナリングプロトコルはRSVP-TEであるGMPLSネットワークのための標準化されている（RFC 3209 [1]）。 RSVP-TE拡張機能の利用が[5]で定義されています。
MP and CP interworking also includes the exchange of information that is either requested by the MP, or a notification by the CP as a consequence of a request from the MP or an automatic action (for example, a failure occurs or an operation is performed). The CP is asked to notify the MP in a reliable manner about the status of the operations it performs and to provide a mechanism to monitor the status of Control Plane objects (e.g., TE Link status, available resources), and to log operations related to Control Plane LSP. Logging is one of the most critical aspects because the MP always needs to have an accurate history and status of each LSP and all Data Plane resources involved in it.
MPとCPインターワーキングは、（例えば、障害が発生したり、操作が行われた）MPによって要求されるか、情報の交換、またはMPからの要求または自動アクションの結果としてCPによる通知を含みます。 CPは、それが実行する動作の状態に関する確実にMPに通知し、制御プレーンのオブジェクト（例えば、TEリンクステータス、利用可能なリソース）の状態を監視するための機構を提供すること、およびに関連する操作を記録するように求められコントロールプレーンLSP。 MPは、常に正確な歴史や各LSPの状態とそれに関係するすべてのデータプレーンのリソースを持っている必要があるため、ロギングは最も重要な側面の一つです。
Performance statistics could overwhelm a Management Network, so it is important to provide flexible instrumentation that enables control over the amount of performance data to be collected. Mechanisms for limiting the quantity of information collected are well known and deployed in IETF standards (see RFC 2819 (RMON) [8] and RFC 4502 (RMON2) [9]). The details of the performance data collected (including loss and delay measurement data) are found in the "Network Management Requirements for MPLS-based Transport Networks" document [3].
パフォーマンス統計は、管理ネットワークを圧倒できたので、収集するパフォーマンスデータの量の制御を可能にする柔軟な機器を提供することが重要です。収集された情報の量を制限するためのメカニズムは周知であり、IETF規格で展開されている（RFC 2819（RMONを参照）[8]、RFC 4502（RMON2）[9]）。 （損失および遅延測定データを含む）を収集した性能データの詳細は、「MPLSベースのトランスポートネットワークのためのネットワーク管理要件」に見出される文書[3]。
A distinction is made between performance data that is collected on-demand and data that is collected proactively. The definitions of on-demand and proactive measurement are provided for OAM in the "Network Management Requirements for MPLS-based Transport Networks" document [3].
区別がオンデマンドで積極的に収集され、データ収集されたパフォーマンスデータとの間で行われます。オンデマンドと積極的な測定の定義は、「MPLSベースのトランスポート・ネットワークのネットワーク管理要件」にOAMのために提供されている文書[3]。
On-demand measurement provides the operator with the ability to do performance measurement for maintenance purpose, such as diagnosis or to provide detailed verification of proactive measurement. It is used typically on specific LSP service instances for a limited time, thus limiting its impact on network performance under normal operations. Therefore, on-demand measurement does not result in scaling issues.
オンデマンド測定は、診断など、メンテナンスの目的のためにパフォーマンス測定を行うためか、積極的な測定の詳細な検証を提供する能力をオペレータに提供します。したがって、通常動作中のネットワークのパフォーマンスへの影響を制限する、限られた時間の間、特定のLSPサービスインスタンスで一般的に使用されます。そのため、オンデマンドの測定は、問題のスケーリングにはなりません。
Proactive measurement is used continuously over time after being configured with periodicity and storage information. Data collected from proactive measurement are usually used for verifying the performance of the service. Proactive performance monitoring has the potential to overwhelm both the process of collecting performance data at a network element (for some arbitrary number of service instances traversing the NE), and the process of reporting this information to the OS. As a consequence of these considerations, operators would typically limit the services to which proactive performance measurement would be applied to a very selective subset of the services being provided and would limit the reporting of this information to statistical summaries (as opposed to raw or detailed performance statistics).
積極的な測定が周期とストレージ情報で構成された後に時間をかけて連続的に使用されます。積極的な測定から収集されたデータは、通常、サービスのパフォーマンスを検証するために使用されています。プロアクティブなパフォーマンスモニタリングは（NEを横断するサービスインスタンスの一部の任意の数の）ネットワーク要素に性能データを収集する工程、およびOSにこの情報を報告するプロセスの両方を圧倒する可能性を有します。これらの考慮事項の結果として、オペレータは、典型的には、積極的な性能測定が提供されるサービスの非常に選択的なサブセットに適用されると、統計的要約にこの情報の報告を制限するれるサービスを制限する（生または詳細なパフォーマンスとは対照的に統計）。
The authors/editors gratefully acknowledge the thoughtful review, comments and explanations provided by Diego Caviglia, Bernd Zeuner and Dan Romascanu.
著者/編集者は感謝サンディエゴCaviglia、ベルントZeunerとダンRomascanuが提供する思慮深いレビュー、コメントや説明を認めます。
The ability for the authorized network operator to access EMF interfaces (Section 2.3) when needed is critical to proper operation. Therefore, the EMF interfaces need to be protected from denial-of-service conditions or attack. The EMF interfaces that use or access private information should be protected from eavesdropping, mis-configuration, and/or mal-configuration by unauthorized network elements, systems, or users.
必要EMFインターフェースにアクセスするために許可されたネットワークオペレータの能力（セクション2.3）は、適切な動作にとって重要です。したがって、EMFインタフェースはサービス拒否状態または攻撃から保護する必要があります。使用EMFインターフェースまたはアクセス個人情報が不正なネットワーク要素、システム、またはユーザによって盗聴、誤構成、および/またはMAL-構成から保護されなければなりません。
Performance of diagnostic functions and path characterization involves extracting a significant amount of information about network construction that the network operator considers private.
診断機能のパフォーマンスとパスの特性は、ネットワークオペレータは、プライベートと考えるネットワーク構築に関する大量の情報を抽出することが含まれます。
Section 4.3 of the "Security Framework for MPLS and GMPLS Networks" document [14] provides a description of the attacks on the Operation and Management Plane and also discusses the background necessary to understand security practices in Internet Service Provider environments. The security practices described are applicable to MPLS-TP environments.
「MPLSとGMPLSネットワークのセキュリティフレームワーク」文書[14]のセクション4.3は、運用および管理プレーンへの攻撃の記述を提供し、またインターネット・サービス・プロバイダー環境でのセキュリティ対策を理解するのに必要な背景を説明します。説明セキュリティ対策は、MPLS-TPの環境に適用されています。
[1] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[1] Awduche、D.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月2001。
[2] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[2]ニーブン - ジェンキンス、B.、Brungard、D.、ベッツ、M.、Sprecher、N.、およびS.上野、 "MPLSトランスポートプロファイルの要件"、RFC 5654、2009年9月。
[3] Lam, K., Mansfield, S., and E. Gray, "Network Management Requirements for MPLS-based Transport Networks", RFC 5951, September 2010.
[3]ラム、K.、マンスフィールド、S.、およびE.グレー、 "MPLSベースのトランスポートネットワークのネットワーク管理の要件"、RFC 5951、2010年9月。
[4] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
[4]ボッチ、M.、ブライアント、S.、フロスト、D.、Levrau、L.、およびL.バーガー、 "トランスポートネットワークにおけるMPLSのための枠組み"、RFC 5921、2010年7月。
[5] 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.
[5] Caviglia、D.、Ceccarelli、D.、Bramanti、D.、李、D.、およびS. Bardalai、「管理プレーンからLSPハンドオーバのためのRSVP-TEシグナリング拡張GMPLSが有効にコントロールプレーンにトランスポートネットワーク」、RFC 5852、2010年4月。
[6] International Telecommunication Union, "Common equipment management function requirements", ITU-T Recommendation G.7710/ Y.1701, July 2007.
[6]国際電気通信連合、 "共通機器管理機能の要件"、ITU-T勧告G.7710 / Y.1701、2007年7月。
[7] International Telecommunication Union, "Architecture and specification of data communication network", ITU-T Recommendation G.7712/Y.1703, June 2008.
[7]国際電気通信連合、 "建築とデータ通信網の仕様"、ITU-T勧告G.7712 / Y.1703、2008年6月。
[8] Waldbusser, S., "Remote Network Monitoring Management Information Base", STD 59, RFC 2819, May 2000.
[8] Waldbusser、S.、 "リモートネットワーク監視管理情報ベース"、STD 59、RFC 2819、2000年5月。
[9] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2", RFC 4502, May 2006.
[9] Waldbusser、S.、 "リモートネットワーク監視管理情報ベースバージョン2"、RFC 4502、2006年5月。
[10] 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.
[10] Caviglia、D.、Bramanti、D.、李、D.、およびD. McDysan、 "（GMPLS）ネットワークスイッチング汎用マルチプロトコルラベルに永久接続およびスイッチ接続との間の変換のための要件"、RFC 5493年4月2009。
[11] International Telecommunication Union, "Principles for a telecommunication management network", ITU-T Recommendation M.3010, April 2005.
[11]国際電気通信連合、ITU-T勧告M.3010、2005年4月 "電気通信管理ネットワークのための原則"。
[12] International Telecommunication Union, "Principles for the Management of Next Generation Networks", ITU-T Recommendation M.3060/Y.2401, March 2006.
[12]国際電気通信連合、 "次世代ネットワークの管理のための原則"、ITU-T勧告M.3060 / Y.2401、2006年3月。
[13] International Telecommunication Union, "Considerations for a telecommunication management network", ITU-T Recommendation M.3013, February 2000.
、ITU-T勧告M.3013、2000年2月[13]国際電気通信連合、 "電気通信管理ネットワークのための考慮事項"。
[14] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[14]牙、L.、 "MPLSおよびGMPLSネットワークのセキュリティフレームワーク"、RFC 5920、2010年7月。
[15] Andersson, L., Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, ""The OAM Acronym Soup"", Work in progress, June 2010.
[15]アンダーソン、L.、Helvoort、H.、Bonica、R.、Romascanu、D.、およびS.マンスフィールド "" OAM頭文字スープ ""、進行中の作業2010年6月。
Authors' Addresses
著者のアドレス
Scott Mansfield (editor) Ericsson 300 Holger Way San Jose, CA 95134 US
スコット・マンスフィールド（エディタ）エリクソン300ホルガー・ウェイサンノゼ、CA 95134米国
Phone: +1 724 931 9316 Email: scott.mansfield@ericsson.com
電話：+1 724 931 9316 Eメール：scott.mansfield@ericsson.com
Eric Gray (editor) Ericsson 900 Chelmsford Street Lowell, MA 01851 US
エリック・グレー（エディタ）エリクソン900チェルムズフォードストリートローウェル、マサチューセッツ州01851米国
Phone: +1 978 275 7470 Email: eric.gray@ericsson.com
電話：+1 978 275 7470 Eメール：eric.gray@ericsson.com
Hing-Kam Lam (editor) Alcatel-Lucent 600-700 Mountain Ave Murray Hill, NJ 07974 US
興・カム・ラム（編集者）アルカテル・ルーセント600-700マウンテンアベニューマレーヒル、NJ 07974米国
Phone: +1 908 582 0672 Email: Kam.Lam@alcatel-lucent.com
電話：+1 908 582 0672 Eメール：Kam.Lam@alcatel-lucent.com