[要約] RFC 5950は、MPLSベースのトランスポートネットワークのためのネットワーク管理フレームワークに関するものであり、その目的は、MPLSネットワークの管理と運用を効果的に行うためのガイドラインを提供することです。
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
MPLSベースのトランスポートネットワークのネットワーク管理フレームワーク
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 MPLSおよびPWE3アーキテクチャ内にMPLS輸送プロファイルを含めるための共同インターネットエンジニアリングタスクフォース（IETF） /国際電気通信連合電気通信標準化セクター（ITU-T）の製品です。輸送ネットワーク。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5950.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 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 MPLSおよびPWE3アーキテクチャ内にMPLS輸送プロファイルを含めるための共同インターネットエンジニアリングタスクフォース（IETF） /国際電気通信連合電気通信標準化セクター（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].
o データ通信ネットワーク（DCN）：管理プレーンに関連する分散管理通信のレイヤー1（物理）、レイヤー2（データリンク）、およびレイヤー3（ネットワーク）機能をサポートするネットワーク。飛行機、およびその他の運用通信（注文ワイヤ/音声通信、ソフトウェアのダウンロードなど）。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 NESが展開されるネットワーク。
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.
MPLS-TPネットワークの管理は、たとえばITU-T M.3010 [11]およびITU-T M.3060/Y.2401 [12]に記載されているように、マルチ層分布管理システムに基づいている可能性があります。各層は、事前定義されたレベルのネットワーク管理機能を提供します。この組織モデルの最低層には、要素管理レベルで輸送サービスとオペレーションシステム（OS）を提供するMPLS-TPネットワーク要素が含まれます。NESおよびOSS内の管理アプリケーション関数（MAF）は、管理サポートを提供します。各エンティティの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.
ピアNESおよび/またはOSSへの管理通信は、各エンティティ内のメッセージ通信関数（MCF）を介して提供されます（たとえば、NEおよびOS）。ユーザーは、NEに接続されたローカルクラフトターミナル（LCT）またはOSに接続されたワークステーション（WS）を介して、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）は、いくつかのトランスポートテクノロジー固有の管理ネットワークで構成されている場合があります。以下の管理ネットワークパーティション（図1）（ITU-T G.7710 [6]に基づく）は、管理ネットワークのパーティション化を示しています。輸送技術固有のMnでG.7710で使用される表記法はx.mnで、xは輸送固有の技術です。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 Management SubNetWorks（「Mt.MSN」または「MPLS-TP 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は、1つ以上のLCTおよび/またはOSSを介して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 NESは、単一の物理的な場所（つまり、サイトまたはオフィス）に存在する可能性があります。MPLS-TP NES間のサイト間通信リンクは、通常CCHSによって提供されます。特定のサイト内では、NESはサイト内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の一部です。Signaling Communications Network（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).
通信チャネル（CCH）は、管理情報および/またはシグナリング情報を転送するためのNES間の論理チャネルを提供します。一部のテクノロジーは、管理（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 NESはDCNを介して通信します。DCNは、NESを管理システムと、NESを使用したNES、および管理システムを備えた管理システムを接続します。
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 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）プロトコルによっても管理できます。制御プレーンの利用は必須要件ではありません（MPLS-TP要件[2]を参照）が、ネットワークオペレーターがネットワーク構成とラベルスイッチパス（LSP）の回復をより速く、よりシンプルにするためによく使用します。
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]。MPからCP所有権のハンドオーバーは、コントロールプレーンが使用されている要件と見なされます。Converse（CPからMPの所有権のハンドオーバー）は、（g）MPLSネットワークに推奨される機能ですが、マイナーアプリケーションのみを備えているため（たとえば、LSPをあるパスから別のパスに移動してメンテナンス操作として移動します）。
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（RFC 3209 [1]）であるGMPLSネットワーク向けに既に標準化されています。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。ロギングは、各LSPおよびそれに関連するすべてのデータプレーンリソースの正確な履歴とステータスを常に持つ必要があるため、最も重要な側面の1つです。
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ベースの輸送ネットワークのネットワーク管理要件」ドキュメント[3]のOAMに対して提供されています。
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.
著者/編集者は、Diego Caviglia、Bernd Zeuner、Dan 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インターフェイスは、不正なネットワーク要素、システム、またはユーザーによって盗聴、誤った構成、および/または不正行為から保護する必要があります。
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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：LSPトンネルのRSVPへの拡張」、RFC 3209、2001年12月。
[2] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[2] Niven-Jenkins、B.、Brungard、D.、Betts、M.、Sprecher、N。、およびS. Ueno、「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] Lam、K.、Mansfield、S。、およびE. Gray、「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] Bocci、M.、Bryant、S.、Frost、D.、Levrau、L。、およびL. Berger、「輸送ネットワークにおける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.、Li、D.、およびS. Bardalai、「GMPLS対応輸送ネットワークの管理プレーンからコントロールプレーンへのLSPハンドオーバーのRSVP-TEシグナリング拡張」、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] International Telecommunication Union、「データ通信ネットワークのアーキテクチャと仕様」、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.、Li、D。、およびD. McDysan、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）ネットワークでの永久接続とスイッチング接続の間の変換の要件」、RFC 5493、2009年4月。
[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.
[13] 国際電気通信連合、「通信管理ネットワークの考慮事項」、ITU-T推奨M.3013、2000年2月。
[14] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[14] Fang、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] Andersson、L.、Helvoort、H.、Bonica、R.、Romascanu、D。、およびS. Mansfield、「The Oamの頭字語スープ」、2010年6月の作業。
Authors' Addresses
著者のアドレス
Scott Mansfield (editor) Ericsson 300 Holger Way San Jose, CA 95134 US
スコット・マンスフィールド（編集者）エリクソン300ホルガーウェイサンノゼ、カリフォルニア州95134米国
Phone: +1 724 931 9316
Email: 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
Hing-Kam Lam (editor) Alcatel-Lucent 600-700 Mountain Ave Murray Hill, NJ 07974 US
Hing-Kam Lam（編集者）Alcatel-Lucent 600-700 Mountain Ave Murray Hill、NJ 07974 US
Phone: +1 908 582 0672
Email: Kam.Lam@alcatel-lucent.com