Internet Engineering Task Force (IETF) K. Lam Request for Comments: 5951 Alcatel-Lucent Category: Standards Track S. Mansfield ISSN: 2070-1721 E. Gray Ericsson September 2010 Network Management Requirements for MPLS-based Transport Networks
AbstractThis 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. 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. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5951.
Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 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.
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] and RFC 4377 , and attempts to comply with the guidelines defined in RFC 5706 . 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. 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. 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). This document expands on the requirements in ITU-T G.7710/Y.1701  and RFC 4377  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. In writing this document, the authors assume the reader is familiar with RFCs 5921  and 5950 .
RFC 2119 . 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. 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 , 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. 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 , 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 , 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 , 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 , 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  for further information on functionality required to support MPLS-TP. 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 ( - Sections 3.45 and 3.44, respectively) as: 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 Proactive OAM - OAM actions that are carried on continuously to permit timely reporting of fault and/or performance status. (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). Signaling Communication Network (SCN): A DCN supporting control plane communication is referred to as a Signaling Communication Network (SCN). 16] or SNMP , and another domain via CORBA , is allowed. 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. 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. 23] for example scenarios in multi- carrier, multi-transport technology environments. 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. section 3) MPLS-TP NEs with MPLS-TP NEs.
RFC 5586  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  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). Section 7 of ITU-T G.7712/Y.1703  describes the transport DCN architecture and requirements as follows: 1) The MPLS-TP MCN MUST support the requirements for: a) CCh access functions specified in Section 7.1.1; b) MPLS-TP SCC data-link layer termination functions specified in Section 18.104.22.168; c) MPLS-TP MCC data-link layer termination functions specified in Section 22.214.171.124; 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  for further information. 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 Establishment of message routing between DCN nodes; o Management of DCN network addresses; 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. RFC 5860 . 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. 5) The MPLS-TP NE MUST support hardware-related supervision for interchangeable and non-interchangeable unit, cable, and power problems. 6) The MPLS-TP NE SHOULD support environment-related supervision for temperature, humidity, etc.
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. 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 Time-C = 10 +/- 0.5 seconds These time values are as defined in G.7710 . 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.
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. 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 .
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. 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 , Section 4.7. 1] (Section 126.96.36.199) and RFC 3878  for more information about ARC. 1], Section 8.1 for hardware. 2) The MPLS-TP NE MUST support the configuration requirements specified in G.7710 , Section 8.2 for software.
3) The MPLS-TP NE MUST support the configuration requirements specified in G.7710 , Section 188.8.131.52 for local real-time clock functions. 4) The MPLS-TP NE MUST support the configuration requirements specified in G.7710 , Section 184.108.40.206 for local real-time clock alignment with external time reference. 5) The MPLS-TP NE MUST support the configuration requirements specified in G.7710 , Section 220.127.116.11 for performance monitoring of the clock function. RFC 5645 , 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). 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  and 5852 . 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. RFC 5860 . 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. 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.
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. 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.
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. 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 . 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.
b) Authentication - allow management connectivity only from authenticated entities. c) Authorization - allow management activity originated by an authorized entity, using (for example) an Access Control List (ACL). d) Port Access Control - allow management activity received on an authorized (management) port. 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. RFC 4732  provides background on DoS in the context of the Internet. 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.
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.  ITU-T Recommendation G.7710/Y.1701, "Common equipment management function requirements", July, 2007.  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.  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.  Jones, G., Ed., "Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure", RFC 3871, September 2004.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  ITU-T Recommendation G.7712/Y.1703, "Architecture and specification of data communication network", June 2008.
 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.  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.  Mansfield, S. Ed., Gray, E., Ed., and K. Lam, Ed., "Network Management Framework for MPLS-based Transport Networks", RFC 5950, September 2010.  Beller, D. and A. Farrel, "An In-Band Data Communication Network For the MPLS Transport Profile", RFC 5718, January 2010.  Chisholm, S. and D. Romascanu, "Alarm Management Information Base (MIB)", RFC 3877, September 2004.  ITU-T Recommendation M.20, "Maintenance philosophy for telecommunication networks", October 1992.  Telcordia, "Network Maintenance: Network Element and Transport Surveillance Messages" (GR-833-CORE), Issue 5, August 2004.  Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.  Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, November 2009.  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", Work in Progress, July 2010.  Presuhn, R., Ed., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002.  OMG Document formal/04-03-12, "The Common Object Request Broker: Architecture and Specification", Revision 3.0.3. March 12, 2004.
 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.  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.  ITU-T Recommendation G.806, "Characteristics of transport equipment - Description methodology and generic functionality", January, 2009.  ITU-T Recommendation Y.1731, "OAM functions and mechanisms for Ethernet based networks", February, 2008.  ITU-T Recommendation G.8601, "Architecture of service management in multi bearer, multi carrier environment", June 2006.  Lam, H., Huynh, A., and D. Perkins, "Alarm Reporting Control Management Information Base (MIB)", RFC 3878, September 2004.  ITU-T Recommendation Y.1563, "Ethernet frame transfer and availability performance", January 2009.  Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial- of-Service Considerations", RFC 4732, December 2006.
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.
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  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. 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. 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. See also RFC 3877 , ITU-T M.20 , and Telcordia document GR-833-CORE  for further information.