Network Management Requirements for MPLS-based Transport Networks
Extracted elements (27)
Overhead-based Communication Channels (e.g., TDM overhead bytes) are explicitly not available in MPLS-TP because there are no overhead bytes in MPLS-TP transport connections, making this CCh realization type inapplicable to the MPLS-TP environment.
The CCh can be realized in seven ways categorized as: out-of-fiber out-of-band (physically distinct or shared network), in-fiber out-of-band (shared interface, overhead-based, or data-link-associated using GAL), and in-band (data-channel-associated using GAL under top label, or mixed with user traffic). Different node pairs in the same MCN/SCN can use different CCh types.
This document does not mandate a preferred management interface protocol; operators may use NETCONF, SNMP, CORBA, or other protocols across different domains and even mix protocols for configuration versus monitoring within the same domain. The choice of protocol is at the operator's discretion.
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 meaningful to the client layer, as described in RFC 4377 Section 4.7.
Specifications SHOULD define support for management connectivity with remote MPLS-TP domains and NEs, including termination points in NEs under third-party operator control. Multi-carrier, multi-transport technology environments are addressed by ITU-T G.8601 scenarios.
An MPLS-TP NE MUST support local reporting of alarms and MUST support reporting of alarms to an OS both autonomously and on request. An NE supporting client-layer technologies over MPLS-TP MUST be capable of translating MPLS-TP defects into client-layer failure conditions.
An MPLS-TP NE MUST support secure management protocols and SHOULD do so in a manner that reduces potential impact of a DoS attack. The NE SHOULD support additional mechanisms that mitigate DoS/DDoS attacks against the management component while allowing the NE to continue its primary functions.
An MPLS-TP NE MUST support suppression of alarms based on configuration, and SHOULD support the Alarm Reporting Control (ARC) function to allow per-managed-entity (e.g., per-LSP) alarm reporting control.
Every MPLS-TP NE MUST connect to an Operations System (OS). The connection MAY be direct or indirect via another MPLS-TP NE. When connected indirectly, an MCC MUST be supported between the NE and the NE(s) providing the connection to the OS.
Failure declaration and clearing MUST be time-stamped; the timestamp MUST indicate the time at which the fault cause is activated and deactivated at the input of the fault cause persistency function.
For bidirectional P2P connections, on-demand single-ended packet loss and loss ratio measurement is REQUIRED and proactive per-direction loss measurement is REQUIRED. For unidirectional P2P and P2MP connections, proactive loss measurement is REQUIRED.
For unidirectional P2P and P2MP connections, on-demand delay measurement is REQUIRED. For co-routed bidirectional P2P, on-demand one-way and two-way delay measurement is REQUIRED. For associated bidirectional P2P, on-demand one-way delay measurement is REQUIRED.
MIBs or other object management semantics specifications defined to configure persistency timers SHOULD explicitly provide default values and SHOULD define the level of granularity for timer tables. Implementations MUST provide the ability to configure these timers.
Secure communication channels MUST be supported for all network traffic and protocols used for management functions, including configuration, monitoring, backup, logging, time synchronization, authentication, and routing. The MCC MUST support application protocols providing confidentiality and data-integrity protection.
The MPLS-TP MCN MUST support CCh access functions, data-link layer termination for MCC and SCC, network layer PDU encapsulation, PDU forwarding, interworking, tunneling, and routing functions as specified in ITU-T G.7712/Y.1703 Section 7.
The MPLS-TP NE MUST perform persistency checks on fault causes before declaring a failure. A data-plane forwarding path failure MUST be declared if the fault cause persists continuously for configurable Time-D, and MUST be cleared if absent continuously for configurable Time-C.
The MPLS-TP NE MUST support collection of loss measurement (LM) and delay measurement (DM) statistics, MUST support reporting of performance degradation via fault management, and MUST support reporting of performance statistics on request from a management system.
The MPLS-TP NE MUST support configuration of OAM entities and functions per RFC 5860, including the ability to choose which OAM functions are enabled, associate OAM functions with specific maintenance entities, and configure maintenance entity identifiers (MEP ID and MIP ID) for connectivity checking.
The MPLS-TP NE MUST support hardware-related supervision for interchangeable and non-interchangeable units, cable, and power problems, and MUST support software supervision for processing faults, storage capacity, version mismatch, corrupted data, and out-of-memory conditions.
The MPLS-TP NE MUST support supervision of all OAM mechanisms deployed for the OAM requirements defined in RFC 5860, including loop-checking and failure detection supervision of the data-plane forwarding path.
The MPLS-TP NE MUST support the capability to configure data-plane forwarding path supervision mechanisms to operate either on-demand or proactively.
The MPLS-TP NE MUST support use of open cryptographic algorithms (per RFC 3871), authentication to allow management connectivity only from authenticated entities, authorization via ACL, and port access control for management traffic.
Fault management for MPLS-TP NEs encompasses a Supervision Function (detecting anomalies and defects), a Validation Function (integrating fault cause indications into failures via persistency checks), and an Alarm Handling Function (severity assignment, suppression, reporting, and reporting control).
The Management Communication Channel (MCC) is a Communication Channel (CCh) dedicated for management plane communications between MPLS-TP NEs and between NEs and Operations Systems. The MCC is logically distinct from the Signaling Communication Channel (SCC) used for control plane communications.
The Management Communication Network (MCN) is the portion of the Data Communication Network (DCN) supporting management plane communication; it connects management systems with NEs and NEs with NEs. The MCN and SCN are logically separate networks but may share the same physical DCN.
The Validation Function uses two configurable timers: Time-D (default ~2.5 ± 0.5 seconds) for fault cause persistency before declaring a failure, and Time-C (default ~10 ± 0.5 seconds) for fault cause absence before clearing a failure, as defined in ITU-T G.7710.
Solutions MUST provide mechanisms to prevent unauthorized and/or unauthenticated access to management capabilities and private information by network elements, systems, or users. Diagnostic functions and path characterization expose significant network construction information that operators may consider private.