doc: Add RFC documents

1 files changed, 1347 insertions, 0 deletions

diff --git a/doc/rfc/rfc5951.txt b/doc/rfc/rfc5951.txt
new file mode 100644
index 0000000..1c25e22
--- /dev/null
+++ b/doc/rfc/rfc5951.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+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
+
+Abstract
+
+   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.
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lam, et al.                  Standards Track                    [Page 1]
+
+RFC 5951        NM Requirements for MPLS-based Transport  September 2010
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lam, et al.                  Standards Track                    [Page 2]
+
+RFC 5951        NM Requirements for MPLS-based Transport  September 2010
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lam, et al.                  Standards Track                    [Page 3]
+
+RFC 5951        NM Requirements for MPLS-based Transport  September 2010
+
+
+1.  Introduction
+
+   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.
+
+   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 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 [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.
+
+   In writing this document, the authors assume the reader is familiar
+   with RFCs 5921 [8] and 5950 [9].
+
+
+
+
+
+Lam, et al.                  Standards Track                    [Page 4]
+
+RFC 5951        NM Requirements for MPLS-based Transport  September 2010
+
+
+1.1.  Terminology
+
+   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.
+
+   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.
+
+   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).
+
+
+
+
+
+
+Lam, et al.                  Standards Track                    [Page 5]
+
+RFC 5951        NM Requirements for MPLS-based Transport  September 2010
+
+
+   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 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:
+
+   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.
+
+
+
+
+
+
+
+Lam, et al.                  Standards Track                    [Page 6]
+
+RFC 5951        NM Requirements for MPLS-based Transport  September 2010
+
+
+   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).
+
+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.
+
+   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.
+
+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.
+
+   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.
+
+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.
+
+
+
+Lam, et al.                  Standards Track                    [Page 7]
+
+RFC 5951        NM Requirements for MPLS-based Transport  September 2010
+
+
+   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).
+
+   Section 7 of ITU-T G.7712/Y.1703 [6] 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 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.
+   See the section on Identifiers in RFC 5921 [8] 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;
+
+
+
+
+
+Lam, et al.                  Standards Track                    [Page 8]
+
+RFC 5951        NM Requirements for MPLS-based Transport  September 2010
+
+
+   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.
+
+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.
+
+5.1.  Supervision Function
+
+   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].
+
+   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.
+
+
+
+
+
+Lam, et al.                  Standards Track                    [Page 9]
+
+RFC 5951        NM Requirements for MPLS-based Transport  September 2010
+
+
+5.2.  Validation Function
+
+   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.
+
+   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].
+
+   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.
+
+
+
+Lam, et al.                  Standards Track                   [Page 10]
+
+RFC 5951        NM Requirements for MPLS-based Transport  September 2010
+
+
+   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.1.  Alarm Severity Assignment
+
+   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.
+
+   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].
+
+5.3.2.  Alarm Suppression
+
+   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
+
+   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.
+
+
+
+
+Lam, et al.                  Standards Track                   [Page 11]
+
+RFC 5951        NM Requirements for MPLS-based Transport  September 2010
+
+
+   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 [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 (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 7.1.3.2) and RFC 3878 [24] for more
+   information about ARC.
+
+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
+
+   1) The MPLS-TP NE MUST support the configuration requirements
+      specified in G.7710 [1], Section 8.1 for hardware.
+
+   2) The MPLS-TP NE MUST support the configuration requirements
+      specified in G.7710 [1], Section 8.2 for software.
+
+
+
+
+
+
+Lam, et al.                  Standards Track                   [Page 12]
+
+RFC 5951        NM Requirements for MPLS-based Transport  September 2010
+
+
+   3) The MPLS-TP NE MUST support the configuration requirements
+      specified in G.7710 [1], Section 8.13.2.1 for local real-time
+      clock functions.
+
+   4) The MPLS-TP NE MUST support the configuration requirements
+      specified in G.7710 [1], Section 8.13.2.2 for local real-time
+      clock alignment with external time reference.
+
+   5) The MPLS-TP NE MUST support the configuration requirements
+      specified in G.7710 [1], Section 8.13.2.3 for performance
+      monitoring of the clock function.
+
+6.2.  Control Plane Configuration
+
+   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
+
+   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).
+
+   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].
+
+   4) Further detailed requirements SHALL be provided along with
+      progress in defining the MPLS-TP control plane in appropriate
+      specifications.
+
+
+
+
+
+
+
+Lam, et al.                  Standards Track                   [Page 13]
+
+RFC 5951        NM Requirements for MPLS-based Transport  September 2010
+
+
+   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.
+
+6.4.  Protection Configuration
+
+   1) The MPLS-TP NE MUST support configuration of required path
+      protection information as follows:
+
+      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  operate/release force protection switching;
+
+      o  operate/release protection lockout;
+
+      o  set/retrieve Automatic Protection Switching (APS) parameters,
+         including
+
+         o  Wait to Restore time,
+
+         o  Protection Switching threshold information.
+
+6.5.  OAM Configuration
+
+   1) The MPLS-TP NE MUST support configuration of 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 the configuration of maintenance
+      entity identifiers (e.g., MEP ID and MIP ID) for the purpose of
+      LSP connectivity checking.
+
+
+
+Lam, et al.                  Standards Track                   [Page 14]
+
+RFC 5951        NM Requirements for MPLS-based Transport  September 2010
+
+
+   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.  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.
+
+   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.
+
+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 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.
+
+
+
+Lam, et al.                  Standards Track                   [Page 15]
+
+RFC 5951        NM Requirements for MPLS-based Transport  September 2010
+
+
+   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 [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.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.
+
+
+
+Lam, et al.                  Standards Track                   [Page 16]
+
+RFC 5951        NM Requirements for MPLS-based Transport  September 2010
+
+
+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 (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.
+
+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 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]).
+
+
+
+
+
+Lam, et al.                  Standards Track                   [Page 17]
+
+RFC 5951        NM Requirements for MPLS-based Transport  September 2010
+
+
+      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.
+
+8.2.  Signaling Communication Channel Security
+
+   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
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+Lam, et al.                  Standards Track                   [Page 18]
+
+RFC 5951        NM Requirements for MPLS-based Transport  September 2010
+
+
+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
+
+   [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.
+
+
+
+
+Lam, et al.                  Standards Track                   [Page 19]
+
+RFC 5951        NM Requirements for MPLS-based Transport  September 2010
+
+
+   [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.
+
+
+
+
+
+
+Lam, et al.                  Standards Track                   [Page 20]
+
+RFC 5951        NM Requirements for MPLS-based Transport  September 2010
+
+
+   [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lam, et al.                  Standards Track                   [Page 21]
+
+RFC 5951        NM Requirements for MPLS-based Transport  September 2010
+
+
+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.
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+
+Lam, et al.                  Standards Track                   [Page 22]
+
+RFC 5951        NM Requirements for MPLS-based Transport  September 2010
+
+
+   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.
+
+   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
+
+
+
+Lam, et al.                  Standards Track                   [Page 23]
+
+RFC 5951        NM Requirements for MPLS-based Transport  September 2010
+
+
+   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
+
+
+
+
+
+
+
+
+
+Lam, et al.                  Standards Track                   [Page 24]
+