RFC 5951

Network Management Requirements for MPLS-based Transport Networks

📅 published September 2010, from ietf

RFC 5951 🎀 Part 1 of 4

Okay bestie, this is RFC 5951, titled Network Management Requirements for MPLS-based Transport Networks ✨ It's a Standards Track document from the IETF, dated September 2010, and its ISSN is 2070-1721. The authors are K. Lam from Alcatel-Lucent, S. Mansfield, and E. Gray from Ericsson 💅 The header doesn't list any RFCs it obsoletes or updates, so it's not replacing or patching anything else 🌸

Status of This Memo 🌈

This is an Internet Standards Track document 🔥 It's a product of the IETF, which means it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741 💖

For the current status of this document, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc5951 🦋

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, which you can find at http://trustee.ietf.org/license-info. These rules are the ones in effect on the date of publication. Read them carefully, because they spell out your rights and restrictions for this document 📜 Any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come without warranty, as the Simplified BSD License says 💜

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 💖

Okay so this section sets the scene ✨ The document lays out the management requirements for equipment used in networks that support an MPLS Transport Profile (MPLS-TP) 🦋 It spells out the requirements for the network management side of the protocol mechanisms and procedures that the MPLS Transport Profile is built from. In other words, it tells you what management capabilities need to exist in MPLS so you can manage MPLS-TP 🧚 It's meant to pin down the essential network management capabilities, not to say what functions any particular MPLS implementation actually supports 💅

This document also builds on the management requirements in ITU-T G.7710/Y.1701 [1] and RFC 4377 [2]. It also tries to follow the guidelines in RFC 5706 [15] 🫶

G.7710/Y.1701 gives generic management requirements for transport networks 🌸 RFC 4377 covers the operations and management requirements for MPLS networks, including the network management requirements that are about operations and management 🍓

This document is the product of a joint ITU-T and IETF effort 🌈 The goal is to bring an MPLS Transport Profile (MPLS-TP) into the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures, so they can support the capabilities and functions of a transport network as the ITU-T defines them 👑

The requirements here come from two places:

  1. MPLS and PWE3 architectures, as the IETF defines them, and
  2. packet transport networks, as the ITU-T defines them.

Requirements for managing equipment in MPLS-TP networks are defined in this document 🔥 Related MPLS and PWE3 functions are defined somewhere else, so they're out of scope here 🙈

This document expands on the requirements in G.7710/Y.1701 [1] and RFC 4377 [2] so they cover fault, configuration, performance, and security management for MPLS-TP networks. It also covers the requirements for the object and information models needed to manage MPLS-TP networks and network elements 🌈

When writing this, the authors assumed the reader already knows RFC 5921 [8] and RFC 5950 [9] 📚

1.1. Terminology 🧠

Here's the keyword bit 🎀 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in RFC 2119 [5]. This document isn't a protocol spec, but using this language still makes the instructions clearer for protocol designers building solutions that meet the requirements here 💜

Now the definitions, bestie 📖

Anomaly: The smallest discrepancy you can observe between the actual and desired characteristics of an item. One anomaly alone doesn't interrupt an item's ability to perform a required function. Anomalies feed into the Performance Monitoring (PM) process and into detecting defects (from [21], Section 3.7) 🔍

Communication Channel (CCh): A logical channel between network elements (NEs) that can be used for things like management or control plane applications. The physical channel that supports the CCh depends on the technology. 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. It handles distributed management communications for the management plane, distributed signaling communications for the control plane, and other operations communications, like order-wire/voice communications and software downloads 📡

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, for controlling the actions that follow, and for figuring out the fault cause (from [21], Section 3.24) 🚨

Failure: The fault cause lasted long enough that the item's ability to perform a required function is considered terminated. The item may be considered failed, and a fault has now been detected (from [21], Section 3.25) 💀

Fault: A fault is when a function can't perform a required action. This doesn't include an inability caused by preventive maintenance, a lack of external resources, or planned actions (from [21], Section 3.26) 🙈

Fault Cause: One disturbance or fault can lead to several defects being detected. The fault cause is the result of a correlation process that tries to find the defect that represents the disturbance or fault 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 to management plane communications 🔧

Management Communication Network (MCN): A DCN that supports management plane communication is called a Management Communication Network (MCN) 🌐

MPLS-TP NE: A network element (NE) that supports the MPLS functions it needs to take part in an MPLS-TP based transport service. See RFC 5645 [7] for more on the functionality needed to support MPLS-TP 🫶

MPLS-TP network: A network where MPLS-TP NEs are deployed 🦋

Operations, Administration and Maintenance (OAM), On-Demand and Proactive: One part of OAM that's mostly a management issue is controlling OAM. On-demand and proactive are modes of OAM mechanism operation, defined in Y.1731 ([22] - Sections 3.45 and 3.44, respectively) for example, as:

  • On-demand OAM - OAM actions that are started by manual intervention for a limited time to carry out diagnostics. On-demand OAM can produce singular or periodic OAM actions during the diagnostic time interval.
  • Proactive OAM - OAM actions that run continuously to allow timely reporting of fault and/or performance status.

(Note that some specific OAM mechanisms only make sense in either on-demand or proactive mode 💭)

Operations System (OS): A system that performs the functions supporting the processing of information related to operations, administration, maintenance, and provisioning (OAM&P) for networks. That includes surveillance and testing functions that support customer access maintenance 🖥️

Signaling Communication Channel (SCC): A CCh dedicated to control plane communications. The SCC can be used for GMPLS/ASON signaling and/or other control plane messages, like routing messages 🚦

Signaling Communication Network (SCN): A DCN that supports control plane communication is called a Signaling Communication Network (SCN) ✨

Part 1 of 4 is done, bestie 💜 Let's keep going! 🌈

2. Management Interface Requirements ✨

Okay so, this doc is NOT picking a favorite management protocol for MPLS-TP networks 🙈 That's the vibe. You're totally allowed to manage one end-to-end connection across multiple operator domains, where one domain is run with NETCONF [16] or SNMP [17] and another with CORBA [18]. Iconic flexibility 💅

  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 to configure an MPLS-TP NE and a different one to monitor it. Which protocols get supported is totally up to the operator 🫶

3. Management Communication Channel (MCC) Requirements 🎀

  1. Specifications SHOULD define support for management connectivity with remote MPLS-TP domains and NEs, plus termination points sitting in NEs that belong to a third-party network operator. Check out ITU-T G.8601 [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 (for example, through a software, hardware, or proprietary protocol connection) or indirect (through another MPLS-TP NE). In this document, any management connection that isn't going through another MPLS-TP NE counts as a direct management connection. When an MPLS-TP NE connects to an OS indirectly, an MCC MUST be supported between that MPLS-TP NE and any MPLS-TP NE(s) used to provide the connection to an OS. Main character energy, the relay NEs have to keep up too 👑

4. Management Communication Network (MCN) Requirements 🧚

Okay, so the MPLS-TP management plane talks over a DCN, or more specifically over the MCN 📡 The MCN connects management systems to management systems, management systems to MPLS-TP NEs, and (in the indirect connectivity case from Section 3) MPLS-TP NEs to other MPLS-TP NEs.

RFC 5586 [14] defines a Generic Associated Channel (G-ACh), which makes a communication channel (CCh) between adjacent MPLS-TP NEs possible for management and control ✨ RFC 5718 [10] then explains how the G-ACh can be used to build infrastructure that forms part of the MCN and SCN. It also covers how MCN and SCN messages get encapsulated, carried over the G-ACh, and decapsulated so they can reach management or signaling/routing control plane components on a label switching router (LSR). It's giving well-organized 🍓

Section 7 of ITU-T G.7712/Y.1703 [6] lays out the transport DCN architecture and requirements, and here's the breakdown:

  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 7.1.2.3;
    • c) MPLS-TP MCC data-link layer termination functions specified in Section 7.1.2.4;
    • 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 🏠 For more on that, check the section on Identifiers in RFC 5921 [8].

To get the MCN running properly, a bunch of management functions are needed for it, including:

  • Retrieval of DCN network parameters so everything works together nicely, e.g., packet size, timeouts, quality of service, window size, etc.;
  • Establishment of message routing between DCN nodes;
  • Management of DCN network addresses;
  • Retrieval of operational status of the DCN at a given node;
  • Capability to enable/disable access by an NE to the DCN. Note that this exists so a malfunctioning NE can be isolated and kept from messing up the rest of the network 🙅‍♀️

5. Fault Management Requirements 🚨

The Fault Management functions inside an MPLS-TP NE handle the supervision, detection, validation, isolation, correction, and reporting of abnormal operation in the MPLS-TP network and its environment. It's the network's little bodyguard team 💪

5.1. Supervision Function 👀

The supervision function looks at when a disturbance or fault actually happens, so it can give maintenance personnel and operations systems the right indication of performance and/or detected fault condition 🔍

  1. The MPLS-TP NE MUST support supervision of the OAM mechanisms that are deployed to meet the OAM requirements defined in RFC 5860 [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 (loops cause non-delivery of traffic, wasted 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 run on-demand or proactively.
  4. The MPLS-TP NE MUST support supervision for software processing -- for example processing faults, storage capacity, version mismatch, corrupted data, out of memory problems, and so on.
  5. The MPLS-TP NE MUST support hardware-related supervision for interchangeable and non-interchangeable units, cable, and power problems ⚡
  6. The MPLS-TP NE SHOULD support environment-related supervision for temperature, humidity, etc. 🌡️

5.2. Validation Function 🧐

Validation is the process of combining Fault Cause indications into Failures. A Fault Cause Indication (FCI) shows a limited interruption of the required transport function. A Fault Cause isn't reported to maintenance personnel, because it might only exist for a super short time ⏱️ Some of these events get added up in the Performance Monitoring process (see Section 7), and when that total goes over a configured value, a threshold crossing alert (report) can be generated.

When the Fault Cause lasts long enough, the required transport function can't be performed, and that's a failure condition. It's subject to reporting to maintenance personnel and/or an OS, because corrective action might be needed. On the flip side, when the Fault Cause stops after a certain time, clearing 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 the control parameters used in 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 [1].

  1. MIBs (or other object management semantics specifications) defined to let you configure 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 not be good enough. Also, such specifications SHOULD define the level of granularity at which tables of these values are to be defined 📋
  2. Implementations MUST provide the ability to configure the preceding set of timers, and SHOULD provide default values so rapid configuration is possible. Suitable default values, timer ranges, and level of granularity are out of scope for this document and are part of the fault management details specification 🙌 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.
  3. 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.1. Alarm Severity Assignment

Failures can be sorted by how severe or urgent the fault is 🚦

  1. An MPLS-TP NE SHOULD support the ability to assign severity (for example Critical, Major, Minor, Warning) to alarm conditions through configuration.

See G.7710 [1], Section 7.2.2 for more detail on alarm severity assignment. For more discussion on Alarm Severity management, check out RFC 3877 [11].

5.3.2. Alarm Suppression

Alarms can come from lots of places, including OAM, device status, and more 📣

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

5.3.3. Alarm Reporting

Alarm Reporting is all about reporting the relevant events and conditions that happen in the network (including the NE, incoming signal, and external environment) 📢

Local reporting is automatic alarming through 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.
  3. An MPLS-TP NE supporting one or more other networking technologies (for example Ethernet, SDH/SONET, MPLS) over MPLS-TP MUST be capable of translating MPLS-TP defects into failure conditions that make sense to the client layer, as described in RFC 4377 [2], Section 4.7. 🔁

5.3.4. Alarm Reporting Control

Alarm Reporting Control (ARC) supports an automatic in-service provisioning capability. Alarm reporting can be turned off on a per-managed-entity basis (for example, per LSP) so there's enough time for customer service testing and other maintenance in an "alarm free" state. Once a managed entity is ready, alarm reporting is turned back on automatically 🎉

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

See G.7710 [1] (Section 7.1.3.2) and RFC 3878 [24] for more info about ARC 📚

6. Configuration Management Requirements ⚙️

Configuration Management is the set of functions that identify, collect data from, provide data to, and control NEs 🎀 Specific configuration tasks that need network management support include hardware and software configuration, configuring NEs to support transport paths (including required working and protection paths), and configuring required path integrity/connectivity and performance monitoring (i.e., OAM). Bestie, that's a lot of moving parts, and they all need managing 🫶

Part 2 of 4 done, more coming soon 🦋

6.1. System Configuration 🔧

  1. okay so the MPLS-TP NE MUST support the configuration requirements from G.7710 [1], Section 8.1, for hardware 💖
  2. the MPLS-TP NE MUST also support the configuration requirements in G.7710 [1], Section 8.2, for software ✨
  3. next up, the MPLS-TP NE MUST support the configuration requirements in G.7710 [1], Section 8.13.2.1, for the local real-time clock functions ⏰
  4. the MPLS-TP NE MUST support the configuration requirements in G.7710 [1], Section 8.13.2.2, for aligning the local real-time clock with an external time reference 🕰️
  5. and the MPLS-TP NE MUST support the configuration requirements in G.7710 [1], Section 8.13.2.3, for performance monitoring of the clock function 📈

6.2. Control Plane Configuration 🧚

  1. if an implementation supports a control plane for MPLS-TP, the MPLS-TP NE MUST support the management plane configuring the MPLS-TP control plane functions. More detailed requirements will show up as the MPLS-TP control plane gets defined in the right specifications 🌸

6.3. Path Configuration 🦋

  1. on top of supporting static provisioning of transport paths (defined in RFC 5645 [7], Section 2.1 -- General Requirements, requirement 18), an MPLS-TP NE MUST support configuring the required path performance thresholds (e.g., Loss Measurement <LM>, Delay Measurement <DM> thresholds) that are needed for performance monitoring of the MPLS-TP service(s) 📊
  2. to make that happen, an MPLS-TP NE MUST support configuring LSP information (such as an LSP identifier of some kind) and/or any other information needed to retrieve LSP status information, performance attributes, and so on 🔍
  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 managing the hand-off of Path control. For example, see RFCs 5943 [19] and 5852 [20] 🤝
  4. further detailed requirements SHALL be provided as the MPLS-TP control plane is defined in the appropriate specifications 📝
  5. if MPLS-TP transport paths can't be statically provisioned using MPLS LSP and pseudowire management tools (either already defined in standards or still under development), further management specifications MUST be provided as needed 🛠️

6.4. Protection Configuration 🛡️

  1. the MPLS-TP NE MUST support configuring the required path protection information as follows:
    • designate specifically identified LSPs as working or protecting LSPs 👑
    • define associations of working and protecting paths 💞
    • operate/release manual protection switching 🎛️
    • operate/release force protection switching 💪
    • operate/release protection lockout 🔒
    • set/retrieve Automatic Protection Switching (APS) parameters, including
      • Wait to Restore time,
      • Protection Switching threshold information. ✨

6.5. OAM Configuration 🔎

  1. the MPLS-TP NE MUST support configuring the OAM entities and functions specified in RFC 5860 [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 🌈
  5. the MPLS-TP NE MUST support configuring maintenance entity identifiers (e.g., MEP ID and MIP ID) for the purpose of LSP connectivity checking 🆔
  6. the MPLS-TP NE MUST support configuring 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 enabling and disabling 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. Performance Management Requirements 📊✨

Performance Management is all about the functions for maintenance, bring-into-service, quality of service, and statistics gathering 💖

This info could be used, for example, to compare how the equipment, the MPLS-TP NE, or the network behaves at different moments in time, so you can see how network performance changes 🕰️

ITU-T Recommendation G.7710 [1] lays out transport performance monitoring requirements for packet-switched and circuit-switched transport networks. The goal is a coherent, consistent way to read network behavior in a multi-technology environment, and the performance management requirements in this document are driven by that goal 🌍

7.1. Path Characterization Performance Metrics 📉

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

From a performance point of view, a service is unavailable if there's an indication that performance has degraded enough that a configurable performance threshold has been crossed, and the degradation sticks around long enough (the indication persists for some amount of time, which is either configurable or well-known) to be sure it isn't a measurement anomaly 🙈

How exactly unavailability gets determined, based on collecting raw performance data, is out of scope for this document 🚫

  1. the MPLS-TP NE MUST support collecting and reporting raw performance data that MAY be used in determining the unavailability of a transport service 📥
  2. MPLS-TP MUST support determining the unavailability of the transport service. The result of this determination MUST be available via the MPLS-TP NE (at service termination points), and determining 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 putting together definitions of unavailability that work generically for packet transport technologies, including MPLS-TP, based on SES and UAS. SES and UAS are already defined for Ethernet transport networks in ITU-T Recommendation Y.1563 [25] 🤓

  1. the MPLS-TP NE MUST support collecting loss measurement (LM) statistics 📦
  2. the MPLS-TP NE MUST support collecting delay measurement (DM) statistics ⏱️
  3. the MPLS-TP NE MUST support reporting performance degradation via fault management so corrective actions can happen 🚨

"Reporting" here could mean things like:

  • reporting to an autonomous protection component to trigger protection switching 🔁
  • reporting via a craft interface so a faulty component can be replaced (or some similar manual intervention) 🛠️
  • etc. 💁
  1. the MPLS-TP NE MUST support reporting performance statistics on request from a management system 📨

7.2. Performance Measurement Instrumentation 🔬

7.2.1. Measurement Frequency ⏲️

  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 🎯

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 connections (P2P and point-to-multipoint (P2MP)), proactive measurement of packet loss and loss ratio is REQUIRED. 📉

On Delay measurement:

  1. for a unidirectional connection (P2P and P2MP), on-demand measurement of delay measurement is REQUIRED ⏱️
  2. for a co-routed bidirectional (P2P) connection, on-demand measurement of one-way and two-way delay is REQUIRED 🔁
  3. 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 🛡️

8.1. Management Communication Channel Security 🗝️

  1. secure communication channels MUST be supported for all network traffic and protocols used to support management functions. This MUST include, at a minimum, 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]) 🧠
    • b) authentication, which means allowing management connectivity only from authenticated entities 🪪
    • c) authorization, which means allowing management activity originated by an authorized entity, using (for example) an Access Control List (ACL) 📋
    • d) port access control, which means allowing management activity received on an authorized (management) port 🚪

8.2. Signaling Communication Channel Security 📡

Security requirements for the SCC are driven by considerations similar to the 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 🌊

A denial-of-service (DoS) attack is an attack that tries to stop 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 as topologically (and potentially geographically) distributed attack sources. It's 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] gives background on DoS in the context of the Internet 🌐

DoS and DDoS attacks are seriously dangerous for the management component of an NE, so treat these requirements with real care 🚨
  1. an MPLS-TP NE MUST support secure management protocols and SHOULD do so in a manner that reduces the 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 🔐

Okay bestie, this section is a big deal 💅. Section 8 has the security requirements for MPLS-TP network management, so go re-read that too 🫶.

  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 pulls out a lot of info about how the network is built, and the network operator might consider that private 🙈. Protect it like it's your diary 📔✨.

10. Acknowledgments 🎀

The authors and 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. Thank you all, you're literally the reason this spec slaps 👑🫶.

11. References 📚

11.1. Normative References

  • [1] ITU-T Recommendation G.7710/Y.1701, "Common equipment management function requirements", July, 2007.
  • [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.
  • [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.
  • [4] Jones, G., Ed., "Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure", RFC 3871, September 2004.
  • [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [6] ITU-T Recommendation G.7712/Y.1703, "Architecture and specification of data communication network", June 2008.
  • [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.
  • [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.
  • [9] Mansfield, S. Ed., Gray, E., Ed., and K. Lam, Ed., "Network Management Framework for MPLS-based Transport Networks", RFC 5950, September 2010.

12.2. Informative References

  • [10] Beller, D. and A. Farrel, "An In-Band Data Communication Network For the MPLS Transport Profile", RFC 5718, January 2010.
  • [11] Chisholm, S. and D. Romascanu, "Alarm Management Information Base (MIB)", RFC 3877, September 2004.
  • [12] ITU-T Recommendation M.20, "Maintenance philosophy for telecommunication networks", October 1992.
  • [13] Telcordia, "Network Maintenance: Network Element and Transport Surveillance Messages" (GR-833-CORE), Issue 5, August 2004.
  • [14] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.
  • [15] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, November 2009.
  • [16] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", Work in Progress, July 2010.
  • [17] Presuhn, R., Ed., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002.
  • [18] OMG Document formal/04-03-12, "The Common Object Request Broker: Architecture and Specification", Revision 3.0.3. March 12, 2004.
  • [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.
  • [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.
  • [21] ITU-T Recommendation G.806, "Characteristics of transport equipment - Description methodology and generic functionality", January, 2009.
  • [22] ITU-T Recommendation Y.1731, "OAM functions and mechanisms for Ethernet based networks", February, 2008.
  • [23] ITU-T Recommendation G.8601, "Architecture of service management in multi bearer, multi carrier environment", June 2006.
  • [24] Lam, H., Huynh, A., and D. Perkins, "Alarm Reporting Control Management Information Base (MIB)", RFC 3878, September 2004.
  • [25] ITU-T Recommendation Y.1563, "Ethernet frame transfer and availability performance", January 2009.
  • [26] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.

Appendix A. Communication Channel (CCh) Examples 🧚

A CCh can be realized in a number of ways, and honestly there are so many options it's giving buffet 🍓.

  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.

This is a "physically distinct out-of-band CCh".

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

This is a "physically shared out-of-band CCh."

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

This is a "shared interface out-of-band CCh".

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

This is an "overhead-based CCh".

This alternative is not available in MPLS-TP because there is no overhead available. 🙅‍♀️

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

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.

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

This is a "data channel associated CCh".

  1. The CCh can be provided by mixing the management traffic with the user traffic such that it 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 [11], ITU-T M.20 [12], and Telcordia document GR-833-CORE [13] for further information.

Contributor's Address 💌

Adrian Farrel
Old Dog Consulting
EMail: adrian@olddog.co.uk

Authors' Addresses 🦋

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

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

Hing-Kam (Kam) Lam
Alcatel-Lucent
600-700 Mountain Ave
Murray Hill, NJ, 07974
Phone: +1 908 582 0672
EMail: Kam.Lam@Alcatel-Lucent.com
📦 where this page comes from