Internet Engineering Task Force (IETF)                            K. Lam
Request for Comments: 5951                                Alcatel-Lucent
Category: Standards Track                                   S. Mansfield
ISSN: 2070-1721                                                  E. Gray
                                                          September 2010

Network Management Requirements for MPLS-based Transport Networks




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


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 ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント(に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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
1. Introduction
1. はじめに

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:


1) MPLS and PWE3 architectures as defined by the IETF, and


2) packet transport networks as defined by the 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に精通していると仮定する。

1.1. Terminology
1.1. 用語

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).


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.).


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).


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).


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).


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).


Fault Cause Indication (FCI): An indication of a fault cause.


Management Communication Channel (MCC): A CCh dedicated for management plane communications.


Management Communication Network (MCN): A DCN supporting management plane communication is referred to as a Management Communication Network (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.


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.4​​4)で定義された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.)


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.


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).


2. Management Interface Requirements

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.


3. Management Communication Channel (MCC) Requirements

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への接続を提供するために使用されます。

4. Management Communication Network (MCN) Requirements

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;


b) MPLS-TP SCC data-link layer termination functions specified in Section;

B)セクション7.1.2.3で指定されたMPLS-TP SCCデータリンク層終端機能。

c) MPLS-TP MCC data-link layer termination functions specified in Section;

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;


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.


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:


o Retrieval of DCN network parameters to ensure compatible functioning, e.g., packet size, timeouts, quality of service, window size, etc.;

O DCNネットワークパラメータの取得は、互換性のある機能、例えば、パケット・サイズ、タイムアウト、サービスの品質、ウィンドウサイズなどを確保するため.;

o Establishment of message routing between DCN nodes;

O DCNノード間のメッセージルーティングの確立。

o Management of DCN network addresses;

O DCNネットワークアドレスの管理;

o Retrieval of operational status of the DCN at a given node;


o 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の単離を可能にするためであることに注意してください。

5. Fault Management Requirements

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ネットワークとその環境の異常動作の監視、検出、検証、分離、修正、およびレポートを可能にします。

5.1. Supervision Function
5.1. 監督機能

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:


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);


b) Supervision of failure detection;


3) The MPLS-TP NE MUST support the capability to configure data-plane forwarding path related supervision mechanisms to perform on-demand or proactively.


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.


5.2. Validation Function
5.2. 検証機能

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.


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.


1) The MPLS-TP NE MUST perform persistency checks on fault causes before it declares a fault cause a failure.


2) The MPLS-TP NE SHOULD provide a configuration capability for control parameters associated with performing the persistency checks described above.


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).


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].


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.


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.


5.3. Alarm Handling Function
5.3. アラーム処理機能
5.3.1. Alarm Severity Assignment
5.3.1. アラーム重大度の割り当て

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]のアラーム重大度の説明を参照してください。

5.3.2. Alarm Suppression
5.3.2. アラームの抑制

Alarms can be generated from many sources, including OAM, device status, etc.


1) An MPLS-TP NE MUST support suppression of alarms based on configuration.


5.3.3. Alarm Reporting
5.3.3. アラームのレポート

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).


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.


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。

5.3.4. Alarm Reporting Control
5.3.4. アラームレポートコントロール

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.


1) An MPLS-TP NE SHOULD support the Alarm Reporting Control function for controlling the reporting of alarm conditions.


See G.7710 [1] (Section and RFC 3878 [24] for more information about ARC.

ARCの詳細については、G.7710 [1](セクション7.1.3.2)とRFC 3878 [24]参照。

6. Configuration Management Requirements

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).


6.1. System Configuration
6.1. システム構成

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 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 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 for performance monitoring of the clock function.

5)MPLS-TP NEがG.7710 [1]、時計機能のパフォーマンス監視のための第8.13.2.3で指定された構成要件をサポートしなければなりません。

6.2. Control Plane Configuration
6.2. コントロールプレーンの設定

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.


6.3. Path Configuration
6.3. パスの設定

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.


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.


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)、さらに管理仕様を提供しなければなりません。

6.4. Protection Configuration
6.4. 保護設定

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 define associations of working and protecting paths;


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 Wait to Restore time,


o Protection Switching threshold information.


6.5. OAM Configuration
6.5. OAMの設定

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.


3) For enabled OAM functions, the MPLS-TP NE MUST support the ability to associate OAM functions with specific maintenance entities.


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


a) one-time on-demand immediately or


b) one-time on-demand pre-scheduled or


c) on-demand periodically based on a specified schedule or


d) proactive on-going.


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の接続性チェック処理は、送信する識別子と予想される識別子のプロビジョニングをサポートしなければなりません。

7. Performance Management Requirements

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]複合技術環境でネットワーク動作のコヒーレント及び一貫した解釈を提供することを目的とパケット交換と回線交換伝送ネットワークのためのトランスポート・パフォーマンス監視の要件を提供します。この文書で指定されたパフォーマンス管理の要件は、そのような目的によって駆動されます。

7.1. Path Characterization Performance Metrics
7.1. パスの特性評価パフォーマンス・メトリック

1) It MUST be possible to determine when an MPLS-TP-based transport service is available and when it is unavailable.


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.


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.


5) The MPLS-TP NE MUST support collection of delay measurement (DM) statistics.


6) The MPLS-TP NE MUST support reporting of performance degradation via fault management for corrective actions.


"Reporting" in this context could mean:


o reporting to an autonomous protection component to trigger protection switching,


o reporting via a craft interface to allow replacement of a faulty component (or similar manual intervention),


o etc.


7) The MPLS-TP NE MUST support reporting of performance statistics on request from a management system.


7.2. Performance Measurement Instrumentation
7.2. パフォーマンス測定計装
7.2.1. Measurement Frequency
7.2.1. 測定周波数

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.


7.2.2. Measurement Scope
7.2.2. 測定範囲

On measurement of packet loss and loss ratio:


1) For bidirectional (both co-routed and associated) point-to-point (P2P) connections


a) on-demand measurement of single-ended packet loss and loss ratio measurement is REQUIRED;


b) proactive measurement of packet loss and loss ratio measurement for each direction is REQUIRED.


2) For unidirectional (P2P and point-to-multipoint (P2MP)) connection, proactive measurement of packet loss and loss ratio is REQUIRED.


On Delay measurement:


3) For a unidirectional (P2P and P2MP) connection, on-demand measurement of delay measurement is REQUIRED.


4) For a co-routed bidirectional (P2P) connection, on-demand measurement of one-way and two-way delay is REQUIRED.


5) For an associated bidirectional (P2P) connection, on-demand measurement of one-way delay is REQUIRED.


8. Security Management Requirements

1) The MPLS-TP NE MUST support secure management and control planes.

1)MPLS-TP NEは安全な管理と制御プレーンをサポートしなければなりません。

8.1. Management Communication Channel Security
8.1. 管理通信チャネルのセキュリティ

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.


2) The MCC MUST support application protocols that provide confidentiality and data-integrity protection.


3) The MPLS-TP NE MUST support the following:


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)のポートアクセス制御 - 許可管理活動は、許可(管理)ポートで受信しました。

8.2. Signaling Communication Channel Security
8.2. シグナリング通信チャネルのセキュリティ

Security requirements for the SCC are driven by considerations similar to MCC requirements described in Section 8.1.


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.


8.3. Distributed Denial of Service
8.3. 分散型サービス拒否

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.


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.


9. Security Considerations

Section 8 includes a set of security requirements that apply to MPLS-TP network management.


1) Solutions MUST provide mechanisms to prevent unauthorized and/or unauthenticated access to management capabilities and private information by network elements, systems, or users.


Performance of diagnostic functions and path characterization involves extracting a significant amount of information about network construction that the network operator might consider private.


10. Acknowledgments

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.


11. References
11.1. Normative References
11.1. 引用規格

[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ベースのトランスポートネットワークのためのネットワーク管理フレームワーク"。

12.2. Informative References
12.2. 参考文献

[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 can be realized in a number of ways.


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".


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."


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".


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".


This alternative is not available in MPLS-TP because there is no overhead available.


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".


It is very similar to case 2, and by its nature can only span a single hop in the transport network.


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".


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".


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)


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.


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.


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.


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:


Authors' Addresses


Eric Gray Ericsson 900 Chelmsford Street Lowell, MA, 01851 Phone: +1 978 275 7470 EMail:

エリック・グレー・エリクソン900チ​​ェルムズフォードストリートローウェル、MA、01851電話:+1 978 275 7470 Eメール

Scott Mansfield Ericsson 250 Holger Way San Jose CA, 95134 +1 724 931 9316 EMail:

スコット・マンスフィールドエリクソン250ホルガー・ウェイサンノゼCA、95134 +1 724 931 9316 Eメール

Hing-Kam (Kam) Lam Alcatel-Lucent 600-700 Mountain Ave Murray Hill, NJ, 07974 Phone: +1 908 582 0672 EMail:

興・カム(カム)ラムアルカテル・ルーセント600-700マウンテンアベニューマレーヒル、NJ、07974電話:+1 908 582 0672 Eメール