draft-ietf-mpls-tp-nm-req-06.txt   rfc5951.txt 
Network Working Group Hing-Kam Lam Internet Engineering Task Force (IETF) K. Lam
Internet Draft Alcatel-Lucent Request for Comments: 5951 Alcatel-Lucent
Expires: March, 2010 Scott Mansfield Category: Standards Track S. Mansfield
Intended Status: Standards Track Eric Gray ISSN: 2070-1721 E. Gray
Ericsson Ericsson
October 21, 2009 September 2010
MPLS TP Network Management Requirements
draft-ietf-mpls-tp-nm-req-06.txt
Status of this Memo Network Management Requirements for MPLS-based Transport Networks
This Internet-Draft is submitted to IETF in full conformance with Abstract
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document specifies the requirements for the management of
Task Force (IETF), its areas, and its working groups. Note that equipment used in networks supporting an MPLS Transport Profile
other groups may also distribute working documents as Internet- (MPLS-TP). The requirements are defined for specification of
Drafts. 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.
Internet-Drafts are draft documents valid for a maximum of six Status of This Memo
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html (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.
This Internet-Draft will expire on April 21, 2010. 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.
Abstract Copyright Notice
This document specifies the requirements for the management of Copyright (c) 2010 IETF Trust and the persons identified as the
equipment used in networks supporting an MPLS Transport Profile document authors. All rights reserved.
(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.
Table of Contents This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
1. Introduction................................................3 Table of Contents
1.1. Terminology............................................4
2. Management Interface Requirements...........................6
3. Management Communication Channel (MCC) Requirements.........6
4. Management Communication Network (MCN) Requirements.........7
5. Fault Management Requirements...............................8
5.1. Supervision Function...................................8
5.2. Validation Function....................................9
5.3. Alarm Handling Function...............................10
5.3.1. Alarm Severity Assignment........................10
5.3.2. Alarm Suppression................................11
5.3.3. Alarm Reporting..................................11
5.3.4. Alarm Reporting Control..........................11
6. Configuration Management Requirements......................12
6.1. System Configuration..................................12
6.2. Control Plane Configuration...........................12
6.3. Path Configuration....................................12
6.4. Protection Configuration..............................13
6.5. OAM Configuration.....................................14
7. Performance Management Requirements........................14
7.1. Path Characterization Performance Metrics.............15
7.2. Performance Measurement Instrumentation...............16
7.2.1. Measurement Frequency............................16
7.2.2. Measurement Scope................................16
8. Security Management Requirements...........................17
8.1. Management Communication Channel Security.............17
8.2. Signaling Communication Channel Security..............17
8.3. Distributed Denial of Service.........................18
9. Security Considerations....................................18
10. IANA Considerations.......................................19
11. Acknowledgments...........................................19
12. References................................................19
12.1. Normative References.................................19
12.2. Informative References...............................20
Author's Addresses............................................21
Copyright Statement...........................................22
Acknowledgment................................................22
Appendix A - Communication Channel (CCh) Examples.............23
1. Introduction 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
This document specifies the requirements for the management of 1. Introduction
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 This document specifies the requirements for the management of
ITU-T G.7710/Y.1701 [1] and RFC 4377 [2], and attempts to comply equipment used in networks supporting an MPLS Transport Profile
with best common practice as defined in [15]. (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.
ITU-T G.7710/Y.1701 defines generic management requirements for This document also leverages management requirements specified in
transport networks. RFC 4377 specifies the OAM requirements, ITU-T G.7710/Y.1701 [1] and RFC 4377 [2], and attempts to comply with
including OAM-related network management requirements, for MPLS the guidelines defined in RFC 5706 [15].
networks.
This document is a product of a joint ITU-T and IETF effort to ITU-T G.7710/Y.1701 defines generic management requirements for
include an MPLS Transport Profile (MPLS-TP) within the IETF MPLS transport networks. RFC 4377 specifies the operations and management
and PWE3 architectures to support capabilities and functionality requirements, including operations-and-management-related network
of a transport network as defined by ITU-T. management requirements, for MPLS networks.
The requirements in this document derive from two sources: 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.
1) MPLS and PWE3 architectures as defined by IETF, and The requirements in this document derive from two sources:
2) packet transport networks as defined by ITU-T. 1) MPLS and PWE3 architectures as defined by the IETF, and
Requirements for management of equipment in MPLS-TP networks are 2) packet transport networks as defined by the ITU-T.
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 [1] and [2] to cover Requirements for management of equipment in MPLS-TP networks are
fault, configuration, performance, and security management for defined herein. Related functions of MPLS and PWE3 are defined
MPLS-TP networks, and the requirements for object and information elsewhere (and are out of scope in this document).
models needed to manage MPLS-TP Networks and Network Elements.
In writing this document, the authors assume the reader is This document expands on the requirements in ITU-T G.7710/Y.1701 [1]
familiar with references [8] and [9]. 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.
1.1. Terminology In writing this document, the authors assume the reader is familiar
with RFCs 5921 [8] and 5950 [9].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 1.1. Terminology
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 which can be observed between The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
actual and desired characteristics of an item. The occurrence of "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
a single anomaly does not constitute an interruption in ability document are to be interpreted as described in RFC 2119 [5].
to perform a required function. Anomalies are used as the input Although this document is not a protocol specification, the use of
for the Performance Monitoring (PM) process and for detection of this language clarifies the instructions to protocol designers
defects (from [21], 3.7). producing solutions that satisfy the requirements set out in this
document.
Communication Channel (CCh): A logical channel between network Anomaly: The smallest discrepancy that can be observed between actual
elements (NEs) that can be used - e.g. - for management or and desired characteristics of an item. The occurrence of a single
control plane applications. The physical channel supporting the anomaly does not constitute an interruption in ability to perform a
CCh is technology specific. See Appendix 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).
Data Communication Network (DCN): A network that supports Layer 1 Communication Channel (CCh): A logical channel between network
(physical layer), Layer 2 (data-link layer), and Layer 3 (network elements (NEs) that can be used (for example) for management or
layer) functionality for distributed management communications control plane applications. The physical channel supporting the CCh
related to the management plane, for distributed signaling is technology specific. See Appendix A.
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 Data Communication Network (DCN): A network that supports Layer 1
ability to perform a required function has been interrupted. (physical layer), Layer 2 (data-link layer), and Layer 3 (network
Defects are used as input for performance monitoring, the control layer) functionality for distributed management communications
of consequent actions, and the determination of fault cause (from related to the management plane, for distributed signaling
[21], 3.24). communications related to the control plane, and other operations
communications (e.g., order-wire/voice communications, software
downloads, etc.).
Failure: The fault cause persisted long enough to consider the Defect: The density of anomalies has reached a level where the
ability of an item to perform a required function to be ability to perform a required function has been interrupted. Defects
terminated. The item may be considered as failed; a fault has now are used as input for performance monitoring, the control of
been detected (from [21], 3.25). consequent actions, and the determination of fault cause (from [21],
Section 3.24).
Fault: A fault is the inability of a function to perform a Failure: The fault cause persisted long enough to consider the
required action. This does not include an inability due to ability of an item to perform a required function to be terminated.
preventive maintenance, lack of external resources, or planned The item may be considered as failed; a fault has now been detected
actions (from [21], 3.26). (from [21], Section 3.25).
Fault Cause: A single disturbance or fault may lead to the Fault: A fault is the inability of a function to perform a required
detection of multiple defects. A fault cause is the result of a action. This does not include an inability due to preventive
correlation process which is intended to identify the defect that maintenance, lack of external resources, or planned actions (from
is representative of the disturbance or fault that is causing the [21], Section 3.26).
problem (from [21], 3.27).
Fault Cause Indication (FCI): An indication of a fault cause. 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).
Management Communication Channel (MCC): A CCh dedicated for Fault Cause Indication (FCI): An indication of a fault cause.
management plane communications.
Management Communication Network (MCN): A DCN supporting Management Communication Channel (MCC): A CCh dedicated for
management plane communication is referred to as a Management management plane communications.
Communication Network (MCN).
MPLS-TP NE: A network element (NE) that supports the functions of Management Communication Network (MCN): A DCN supporting management
MPLS necessary to participate in an MPLS-TP based transport plane communication is referred to as a Management Communication
service. See [7] for further information on functionality Network (MCN).
required to support MPLS-TP.
MPLS-TP network: a network in which MPLS-TP NEs are deployed. 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.
OAM, On-Demand and Proactive: One feature of OAM that is largely MPLS-TP network: a network in which MPLS-TP NEs are deployed.
a management issue is control of OAM; on-demand and proactive are
modes of OAM mechanism operation defined - for example - in
Y.1731 ([22] - 3.45 and 3.44 respectively) as:
. On-demand OAM - OAM actions which are initiated via manual Operations, Administration and Maintenance (OAM), On-Demand and
intervention for a limited time to carry out diagnostics. Proactive: One feature of OAM that is largely a management issue is
On-demand OAM can result in singular or periodic OAM actions control of OAM; on-demand and proactive are modes of OAM mechanism
during the diagnostic time interval. operation defined in (for example) Y.1731 ([22] - Sections 3.45 and
3.44, respectively) as:
. Proactive OAM - OAM actions which are carried on o On-demand OAM - OAM actions that are initiated via manual
continuously to permit timely reporting of fault and/or intervention for a limited time to carry out diagnostics.
performance status. On-demand OAM can result in singular or periodic OAM actions
during the diagnostic time interval.
(Note that it is possible for specific OAM mechanisms to only o Proactive OAM - OAM actions that are carried on continuously to
have a sensible use in either on-demand or proactive mode.) permit timely reporting of fault and/or performance status.
Operations System (OS): A system that performs the functions that (Note that it is possible for specific OAM mechanisms to only have a
support processing of information related to operations, sensible use in either on-demand or proactive mode.)
administration, maintenance, and provisioning (OAM&P) for the
networks, including surveillance and testing functions to support
customer access maintenance.
Signaling Communication Channel (SCC): A CCh dedicated for Operations System (OS): A system that performs the functions that
control plane communications. The SCC can be used for GMPLS/ASON support processing of information related to operations,
signaling and/or other control plane messages (e.g., routing administration, maintenance, and provisioning (OAM&P) for the
messages). networks, including surveillance and testing functions to support
customer access maintenance.
Signaling Communication Network (SCN): A DCN supporting control Signaling Communication Channel (SCC): A CCh dedicated for control
plane communication is referred to as a Signaling Communication plane communications. The SCC can be used for GMPLS/ASON signaling
Network (SCN). and/or other control plane messages (e.g., routing messages).
2. Management Interface Requirements Signaling Communication Network (SCN): A DCN supporting control plane
communication is referred to as a Signaling Communication Network
(SCN).
This document does not specify a preferred management interface 2. Management Interface Requirements
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 This document does not specify a preferred management interface
MPLS-TP NE MAY actively support more than one management protocol to be used as the standard protocol for managing MPLS-TP
protocol in any given deployment. 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.
For example, an operator can use one protocol for configuration 1) For the management interface to the management system, an MPLS-TP
of an MPLS-TP NE and another for monitoring. The protocols to be NE MAY actively support more than one management protocol in any
supported are at the discretion of the operator. given deployment.
3. Management Communication Channel (MCC) Requirements 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.
1) Specifications SHOULD define support for management 3. Management Communication Channel (MCC) Requirements
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 purpose, every MPLS-TP NE MUST connect to an 1) Specifications SHOULD define support for management connectivity
OS. The connection MAY be direct (e.g. - via a software, with remote MPLS-TP domains and NEs, as well as with termination
hardware or proprietary protocol connection) or indirect points located in NEs under the control of a third party network
(via another MPLS-TP NE). In this document, any management operator. See ITU-T G.8601 [23] for example scenarios in multi-
connection that is not via another MPLS-TP NE is a direct carrier, multi-transport technology environments.
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 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.
Entities of the MPLS-TP management plane communicate via a DCN, 4. Management Communication Network (MCN) Requirements
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.
RFC 5586 [14] defines a Generic Associated Channel (G-ACh) to Entities of the MPLS-TP management plane communicate via a DCN, or
enable the realization of a communication channel (CCh) between more specifically via the MCN. The MCN connects management systems
adjacent MPLS-TP NEs for management and control. Reference [10] with management systems, management systems with MPLS-TP NEs, and (in
describes how the G-ACh can be used to provide infrastructure the indirect connectivity case discussed in section 3) MPLS-TP NEs
that forms part of the MCN and SCN. It also explains how MCN and with MPLS-TP NEs.
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).
ITU-T G.7712/Y.1703 [6], section 7, describes the transport DCN RFC 5586 [14] defines a Generic Associated Channel (G-ACh) to enable
architecture and requirements. 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).
1) The MPLS-TP MCN MUST support the requirements (in reference Section 7 of ITU-T G.7712/Y.1703 [6] describes the transport DCN
[6]) for: architecture and requirements as follows:
a) CCh access functions specified in section 7.1.1; 1) The MPLS-TP MCN MUST support the requirements for:
b) MPLS-TP SCC data-link layer termination functions a) CCh access functions specified in Section 7.1.1;
specified in section 7.1.2.3;
c) MPLS-TP MCC data-link layer termination functions b) MPLS-TP SCC data-link layer termination functions specified in
specified in section 7.1.2.4; Section 7.1.2.3;
d) Network layer PDU into CCh data-link frame encapsulation c) MPLS-TP MCC data-link layer termination functions specified in
functions specified in section 7.1.3; Section 7.1.2.4;
e) Network layer PDU forwarding (7.1.6), interworking (7.1.7) d) Network layer PDU into CCh data-link frame encapsulation
and encapsulation (7.1.8) functions, as well as tunneling functions specified in Section 7.1.3;
(7.1.9) and routing (7.1.10) functions specified in [6].
As a practical matter, MCN connections will typically have e) Network layer PDU forwarding (Section 7.1.6), interworking
addresses. See the section on Identifiers in [8] for further (Section 7.1.7), and encapsulation (Section 7.1.8) functions,
information. as well as tunneling (Section 7.1.9) and routing (Section
7.1.10) functions.
In order to have the MCN operate properly, a number of management As a practical matter, MCN connections will typically have addresses.
functions for the MCN are needed, including: See the section on Identifiers in RFC 5921 [8] for further
information.
. Retrieval of DCN network parameters to ensure compatible In order to have the MCN operate properly, a number of management
functioning, e.g. packet size, timeouts, quality of service, functions for the MCN are needed, including:
window size, etc.;
. Establishment of message routing between DCN nodes; o Retrieval of DCN network parameters to ensure compatible
functioning, e.g., packet size, timeouts, quality of service,
window size, etc.;
. Management of DCN network addresses; o Establishment of message routing between DCN nodes;
. Retrieval of operational status of the DCN at a given node; o Management of DCN network addresses;
. Capability to enable/disable access by an NE to the DCN. o Retrieval of operational status of the DCN at a given node;
Note that this is to allow isolating a malfunctioning NE o Capability to enable/disable access by an NE to the DCN. Note
from impacting the rest of the network. 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 5. Fault Management Requirements
The Fault Management functions within an MPLS-TP NE enable the The Fault Management functions within an MPLS-TP NE enable the
supervision, detection, validation, isolation, correction, and supervision, detection, validation, isolation, correction, and
reporting of abnormal operation of the MPLS-TP network and its reporting of abnormal operation of the MPLS-TP network and its
environment. environment.
5.1. Supervision Function 5.1. Supervision Function
The supervision function analyses the actual occurrence of a The supervision function analyzes the actual occurrence of a
disturbance or fault for the purpose of providing an appropriate disturbance or fault for the purpose of providing an appropriate
indication of performance and/or detected fault condition to indication of performance and/or detected fault condition to
maintenance personnel and operations systems. maintenance personnel and operations systems.
1) The MPLS-TP NE MUST support supervision of the OAM 1) The MPLS-TP NE MUST support supervision of the OAM mechanisms that
mechanisms that are deployed for supporting the OAM are deployed for supporting the OAM requirements defined in RFC
requirements defined in [3]. 5860 [3].
2) The MPLS-TP NE MUST support the following data-plane 2) The MPLS-TP NE MUST support the following data-plane forwarding
forwarding path supervision functions: path supervision functions:
a) Supervision of loop-checking functions used to detect a) Supervision of loop-checking functions used to detect loops in
loops in the data-plane forwarding path (which result in the data-plane forwarding path (which result in non-delivery of
non-delivery of traffic, wasting of forwarding resources traffic, wasting of forwarding resources, and unintended self-
and unintended self-replication of traffic); replication of traffic);
b) Supervision of failure detection; b) Supervision of failure detection;
3) The MPLS-TP NE MUST support the capability to configure 3) The MPLS-TP NE MUST support the capability to configure data-plane
data-plane forwarding path related supervision mechanisms to forwarding path related supervision mechanisms to perform
perform on-demand or proactively. on-demand or proactively.
4) The MPLS-TP NE MUST support supervision for software 4) The MPLS-TP NE MUST support supervision for software processing --
processing - e.g., processing faults, storage capacity, e.g., processing faults, storage capacity, version mismatch,
version mismatch, corrupted data and out of memory problems, corrupted data, and out of memory problems, etc.
etc.
5) The MPLS-TP NE MUST support hardware-related supervision for 5) The MPLS-TP NE MUST support hardware-related supervision for
interchangeable and non-interchangeable unit, cable, and interchangeable and non-interchangeable unit, cable, and power
power problems. problems.
6) The MPLS-TP NE SHOULD support environment-related 6) The MPLS-TP NE SHOULD support environment-related supervision for
supervision for temperature, humidity, etc. temperature, humidity, etc.
5.2. Validation Function 5.2. Validation Function
Validation is the process of integrating Fault Cause indications Validation is the process of integrating Fault Cause indications into
into Failures. A Fault Cause Indication (FCI) indicates a limited Failures. A Fault Cause Indication (FCI) indicates a limited
interruption of the required transport function. A Fault Cause is interruption of the required transport function. A Fault Cause is
not reported to maintenance personnel because it might exist only not reported to maintenance personnel because it might exist only for
for a very short time. Note that some of these events are summed a very short period of time. Note that some of these events are
up in the Performance Monitoring process (see section 7), and summed up in the Performance Monitoring process (see Section 7), and
when this sum exceeds a configured value, a threshold crossing when this sum exceeds a configured value, a threshold crossing alert
alert (report) can be generated. (report) can be generated.
When the Fault Cause lasts long enough, an inability to perform When the Fault Cause lasts long enough, an inability to perform the
the required transport function arises. This failure condition is required transport function arises. This failure condition is
subject to reporting to maintenance personnel and/or an OS subject to reporting to maintenance personnel and/or an OS because
because corrective action might be required. Conversely, when the corrective action might be required. Conversely, when the Fault
Fault Cause ceases after a certain time, clearing of the Failure Cause ceases after a certain time, clearing of the Failure condition
condition is also subject to reporting. is also subject to reporting.
1) The MPLS-TP NE MUST perform persistency checks on fault 1) The MPLS-TP NE MUST perform persistency checks on fault causes
causes before it declares a fault cause a failure. before it declares a fault cause a failure.
2) The MPLS-TP NE SHOULD provide a configuration capability for 2) The MPLS-TP NE SHOULD provide a configuration capability for
control parameters associated with performing the control parameters associated with performing the persistency
persistency checks described above. checks described above.
3) An MPLS-TP NE MAY provide configuration parameters to 3) An MPLS-TP NE MAY provide configuration parameters to control
control reporting, and clearing, of failure conditions. reporting and clearing of failure conditions.
4) A data-plane forwarding path failure MUST be declared if the 4) A data-plane forwarding path failure MUST be declared if the fault
fault cause persists continuously for a configurable time cause persists continuously for a configurable time (Time-D). The
(Time-D). The failure MUST be cleared if the fault cause is failure MUST be cleared if the fault cause is absent continuously
absent continuously for a configurable time (Time-C). for a configurable time (Time-C).
Note: As an example, the default time values might be as follows: Note: As an example, the default time values might be as follows:
Time-D = 2.5 +/- 0.5 seconds Time-D = 2.5 +/- 0.5 seconds
Time-C = 10 +/- 0.5 seconds Time-C = 10 +/- 0.5 seconds
These time values are as defined in G.7710 [1]. These time values are as defined in G.7710 [1].
5) MIBs - or other object management semantics specifications - 5) MIBs - or other object management semantics specifications -
defined to enable configuration of these timers SHOULD defined to enable configuration of these timers SHOULD explicitly
explicitly provide default values and MAY provide guidelines provide default values and MAY provide guidelines on ranges and
on ranges and value determination methods for scenarios value determination methods for scenarios where the default value
where the default value chosen might be inadequate. In chosen might be inadequate. In addition, such specifications
addition, such specifications SHOULD define the level of SHOULD define the level of granularity at which tables of these
granularity at which tables of these values are to be values are to be defined.
defined.
6) Implementations MUST provide the ability to configure the 6) Implementations MUST provide the ability to configure the
preceding set of timers, and SHOULD provide default values preceding set of timers and SHOULD provide default values to
to enable rapid configuration. Suitable default values, enable rapid configuration. Suitable default values, timer
timer ranges, and level of granularity are out of scope in ranges, and level of granularity are out of scope in this document
this document and form part of the specification of fault and form part of the specification of fault management details.
management details. Timers SHOULD be configurable per NE for Timers SHOULD be configurable per NE for broad categories (for
broad categories (for example, defects and/or fault causes), example, defects and/or fault causes), and MAY be configurable
and MAY be configurable per-interface on an NE and/or per per-interface on an NE and/or per individual defect/fault cause.
individual defect/fault cause.
7) The failure declaration and clearing MUST be time stamped. 7) The failure declaration and clearing MUST be time stamped. The
The time-stamp MUST indicate the time at which the fault time-stamp MUST indicate the time at which the fault cause is
cause is activated at the input of the fault cause activated at the input of the fault cause persistency (i.e.,
persistency (i.e. defect-to-failure integration) function, defect-to-failure integration) function, and the time at which the
and the time at which the fault cause is deactivated at the fault cause is deactivated at the input of the fault cause
input of the fault cause persistency function. persistency function.
5.3. Alarm Handling Function 5.3. Alarm Handling Function
5.3.1. Alarm Severity Assignment 5.3.1. Alarm Severity Assignment
Failures can be categorized to indicate the severity or urgency Failures can be categorized to indicate the severity or urgency of
of the fault. the fault.
1) An MPLS-TP NE SHOULD support the ability to assign severity 1) An MPLS-TP NE SHOULD support the ability to assign severity (e.g.,
(e.g., Critical, Major, Minor, Warning) to alarm conditions Critical, Major, Minor, Warning) to alarm conditions via
via configuration. configuration.
See G.7710 [1], section 7.2.2 for more detail on alarm severity See G.7710 [1], Section 7.2.2 for more detail on alarm severity
assignment. For additional discussion of Alarm Severity assignment. For additional discussion of Alarm Severity management,
management, see discussion of alarm severity in RFC 3877 [11]. see discussion of alarm severity in RFC 3877 [11].
5.3.2. Alarm Suppression 5.3.2. Alarm Suppression
Alarms can be generated from many sources, including OAM, device Alarms can be generated from many sources, including OAM, device
status, etc. status, etc.
1) An MPLS-TP NE MUST support suppression of alarms based on 1) An MPLS-TP NE MUST support suppression of alarms based on
configuration. configuration.
5.3.3. Alarm Reporting 5.3.3. Alarm Reporting
Alarm Reporting is concerned with the reporting of relevant Alarm Reporting is concerned with the reporting of relevant events
events and conditions, which occur in the network (including the and conditions, which occur in the network (including the NE,
NE, incoming signal, and external environment). incoming signal, and external environment).
Local reporting is concerned with automatic alarming by means of Local reporting is concerned with automatic alarming by means of
audible and visual indicators near the failed equipment. audible and visual indicators near the failed equipment.
1) An MPLS-TP NE MUST support local reporting of alarms. 1) An MPLS-TP NE MUST support local reporting of alarms.
2) The MPLS-TP NE MUST support reporting of alarms to an OS. 2) The MPLS-TP NE MUST support reporting of alarms to an OS. These
These reports are either autonomous reports (notifications) reports are either autonomous reports (notifications) or reports
or reports on request by maintenance personnel. The MPLS-TP on request by maintenance personnel. The MPLS-TP NE SHOULD report
NE SHOULD report local (environmental) alarms to a network local (environmental) alarms to a network management system.
management system.
3) An MPLS-TP NE supporting one or more other networking 3) An MPLS-TP NE supporting one or more other networking technologies
technologies (e.g. - Ethernet, SDH/SONET, MPLS) over MPLS-TP (e.g., Ethernet, SDH/SONET, MPLS) over MPLS-TP MUST be capable of
MUST be capable of translating an MPLS-TP defects into translating MPLS-TP defects into failure conditions that are
failure conditions that are meaningful to the client layer, meaningful to the client layer, as described in RFC 4377 [2],
as described in RFC 4377 [2], section 4.7. Section 4.7.
5.3.4. Alarm Reporting Control 5.3.4. Alarm Reporting Control
Alarm Reporting Control (ARC) supports an automatic in-service Alarm Reporting Control (ARC) supports an automatic in-service
provisioning capability. Alarm reporting can be turned off on a provisioning capability. Alarm reporting can be turned off on a per-
per-managed entity (e.g., LSP) basis to allow sufficient time for managed entity basis (e.g., LSP) to allow sufficient time for
customer service testing and other maintenance activities in an customer service testing and other maintenance activities in an
"alarm free" state. Once a managed entity is ready, alarm "alarm free" state. Once a managed entity is ready, alarm reporting
reporting is automatically turned on. is automatically turned on.
1) An MPLS-TP NE SHOULD support the Alarm Reporting Control 1) An MPLS-TP NE SHOULD support the Alarm Reporting Control function
function for controlling the reporting of alarm conditions. for controlling the reporting of alarm conditions.
See G.7710 [1] (section 7.1.3.2) and RFC 3878 [24] for more See G.7710 [1] (Section 7.1.3.2) and RFC 3878 [24] for more
information about ARC. information about ARC.
6. Configuration Management Requirements 6. Configuration Management Requirements
Configuration Management provides functions to identify, collect Configuration Management provides functions to identify, collect data
data from, provide data to and control NEs. Specific from, provide data to, and control NEs. Specific configuration tasks
configuration tasks requiring network management support include requiring network management support include hardware and software
hardware and software configuration, configuration of NEs to configuration, configuration of NEs to support transport paths
support transport paths (including required working and (including required working and protection paths), and configuration
protection paths), and configuration of required path of required path integrity/connectivity and performance monitoring
integrity/connectivity and performance monitoring (i.e. - OAM). (i.e., OAM).
6.1. System Configuration 6.1. System Configuration
1) The MPLS-TP NE MUST support the configuration requirements 1) The MPLS-TP NE MUST support the configuration requirements
specified in G.7710 [1] section 8.1 for hardware. specified in G.7710 [1], Section 8.1 for hardware.
2) The MPLS-TP NE MUST support the configuration requirements 2) The MPLS-TP NE MUST support the configuration requirements
specified in G.7710 [1] section 8.2 for software. specified in G.7710 [1], Section 8.2 for software.
3) The MPLS-TP NE MUST support the configuration requirements 3) The MPLS-TP NE MUST support the configuration requirements
specified in G.7710 [1] section 8.13.2.1 for local real time specified in G.7710 [1], Section 8.13.2.1 for local real-time
clock functions. clock functions.
4) The MPLS-TP NE MUST support the configuration requirements 4) The MPLS-TP NE MUST support the configuration requirements
specified in G.7710 [1] section 8.13.2.2 for local real time specified in G.7710 [1], Section 8.13.2.2 for local real-time
clock alignment with external time reference. clock alignment with external time reference.
5) The MPLS-TP NE MUST support the configuration requirements 5) The MPLS-TP NE MUST support the configuration requirements
specified in G.7710 [1] section 8.13.2.3 for performance specified in G.7710 [1], Section 8.13.2.3 for performance
monitoring of the clock function. monitoring of the clock function.
6.2. Control Plane Configuration 6.2. Control Plane Configuration
1) If a control plane is supported in an implementation of 1) If a control plane is supported in an implementation of MPLS-TP,
MPLS-TP, the MPLS-TP NE MUST support the configuration of the MPLS-TP NE MUST support the configuration of MPLS-TP control
MPLS-TP control plane functions by the management plane. plane functions by the management plane. Further detailed
Further detailed requirements will be provided along with requirements will be provided along with progress in defining the
progress in defining the MPLS-TP control plane in MPLS-TP control plane in appropriate specifications.
appropriate specifications.
6.3. Path Configuration 6.3. Path Configuration
1) In addition to the requirement to support static 1) In addition to the requirement to support static provisioning of
provisioning of transport paths (defined in [7], section 2.1 transport paths (defined in RFC 5645 [7], Section 2.1 -- General
- General Requirements - requirement 18), an MPLS-TP NE MUST Requirements, requirement 18), an MPLS-TP NE MUST support the
support the configuration of required path performance configuration of required path performance characteristic
characteristic thresholds (e.g. - Loss Measurement <LM>, thresholds (e.g., Loss Measurement <LM>, Delay Measurement <DM>
Delay Measurement <DM> thresholds) necessary to support thresholds) necessary to support performance monitoring of the
performance monitoring of the MPLS-TP service(s). MPLS-TP service(s).
2) In order to accomplish this, an MPLS-TP NE MUST support 2) In order to accomplish this, an MPLS-TP NE MUST support
configuration of LSP information (such as an LSP identifier configuration of LSP information (such as an LSP identifier of
of some kind) and/or any other information needed to some kind) and/or any other information needed to retrieve LSP
retrieve LSP status information, performance attributes, status information, performance attributes, etc.
etc.
3) If a control plane is supported, and that control plane 3) If a control plane is supported, and that control plane includes
includes support for control-plane/management-plane hand-off support for control-plane/management-plane hand-off for LSP
for LSP setup/maintenance, the MPLS-TP NE MUST support setup/maintenance, the MPLS-TP NE MUST support management of the
management of the hand-off of Path control. See, for hand-off of Path control. For example, see RFCs 5943 [19] and
example, references [19] and [20]. 5852 [20].
4) Further detailed requirements SHALL be provided along with 4) Further detailed requirements SHALL be provided along with
progress in defining the MPLS-TP control plane in progress in defining the MPLS-TP control plane in appropriate
appropriate specifications. specifications.
5) If MPLS-TP transport paths cannot be statically provisioned 5) If MPLS-TP transport paths cannot be statically provisioned using
using MPLS LSP and pseudo-wire management tools (either MPLS LSP and pseudowire management tools (either already defined
already defined in standards or under development), further in standards or under development), further management
management specifications MUST be provided as needed. specifications MUST be provided as needed.
6.4. Protection Configuration 6.4. Protection Configuration
1) The MPLS-TP NE MUST support configuration of required path 1) The MPLS-TP NE MUST support configuration of required path
protection information as follows: protection information as follows:
. designate specifically identified LSPs as working or o designate specifically identified LSPs as working or protecting
protecting LSPs; LSPs;
. define associations of working and protecting paths; o define associations of working and protecting paths;
. operate/release manual protection switching; o operate/release manual protection switching;
. operate/release force protection switching; o operate/release force protection switching;
. operate/release protection lockout; o operate/release protection lockout;
. set/retrieve Automatic Protection Switching (APS) o set/retrieve Automatic Protection Switching (APS) parameters,
parameters, including - including
o Wait to Restore time, o Wait to Restore time,
o Protection Switching threshold information. o Protection Switching threshold information.
6.5. OAM Configuration 6.5. OAM Configuration
1) The MPLS-TP NE MUST support configuration of the OAM
entities and functions specified in [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.
6) The MPLS-TP NE MUST support configuration of OAM parameters
to meet their specific operational requirements, such as
whether -
a) one-time on-demand immediately or
b) one-time on-demand pre-scheduled or 1) The MPLS-TP NE MUST support configuration of the OAM entities and
functions specified in RFC 5860 [3].
c) on-demand periodically based on a specified schedule or 2) The MPLS-TP NE MUST support the capability to choose which OAM
functions are enabled.
d) proactive on-going. 3) For enabled OAM functions, the MPLS-TP NE MUST support the ability
to associate OAM functions with specific maintenance entities.
7) The MPLS-TP NE MUST support the enabling/disabling of the 4) The MPLS-TP NE MUST support the capability to configure the OAM
connectivity check processing. The connectivity check entities/functions as part of LSP setup and tear-down, including
process of the MPLS-TP NE MUST support provisioning of the co-routed bidirectional point-to-point, associated bidirectional
identifiers to be transmitted and the expected identifiers. point-to-point, and uni-directional (both point-to-point and
point-to-multipoint) connections.
7. Performance Management Requirements 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.
Performance Management provides functions for the purpose of 6) The MPLS-TP NE MUST support configuration of OAM parameters to
Maintenance, Bring-into-service, Quality of service, and meet their specific operational requirements, such as
statistics gathering.
This information could be used, for example, to compare behavior a) one-time on-demand immediately or
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 b) one-time on-demand pre-scheduled or
monitoring requirements for packet-switched and circuit-switched
transport networks with the objective of providing 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 c) on-demand periodically based on a specified schedule or
1) It MUST be possible to determine when an MPLS-TP based d) proactive on-going.
transport service is available and when it is unavailable.
From a performance perspective, a service is unavailable if there 7) The MPLS-TP NE MUST support the enabling/disabling of the
is an indication that performance has degraded to the extent that connectivity check processing. The connectivity check process of
a configurable performance threshold has been crossed and the the MPLS-TP NE MUST support provisioning of the identifiers to be
degradation persists long enough (i.e. - the indication persists transmitted and the expected identifiers.
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 7. Performance Management Requirements
is to be determined - based on collection of raw performance data
- are out of scope for this document.
2) The MPLS-TP NE MUST support collection and reporting of raw Performance Management provides functions for the purpose of
performance data that MAY be used in determining the maintenance, bring-into-service, quality of service, and statistics
unavailability of a transport service. gathering.
3) MPLS-TP MUST support the determination of the unavailability This information could be used, for example, to compare behavior of
of the transport service. The result of this determination the equipment, MPLS-TP NE, or network at different moments in time to
MUST be available via the MPLS-TP NE (at service termination evaluate changes in network performance.
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 availability-state of
services.
Transport network unavailability is based on Severely Errored ITU-T Recommendation G.7710 [1] provides transport performance
Seconds (SES) and Unavailable Seconds (UAS). ITU-T is monitoring requirements for packet-switched and circuit-switched
establishing definitions of unavailability generically applicable transport networks with the objective of providing a coherent and
to packet transport technologies, including MPLS-TP, based on SES consistent interpretation of the network behavior in a multi-
and UAS. Note that SES and UAS are already defined for Ethernet technology environment. The performance management requirements
transport networks in ITU-T Recommendation Y.1563 [25]. specified in this document are driven by such an objective.
4) The MPLS-TP NE MUST support collection of loss measurement 7.1. Path Characterization Performance Metrics
(LM) statistics.
5) The MPLS-TP NE MUST support collection of delay measurement 1) It MUST be possible to determine when an MPLS-TP-based transport
(DM) statistics. service is available and when it is unavailable.
6) The MPLS-TP NE MUST support reporting of Performance From a performance perspective, a service is unavailable if there is
degradation via fault management for corrective actions. 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.
"Reporting" in this context could mean: 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.
. reporting to an autonomous protection component to 2) The MPLS-TP NE MUST support collection and reporting of raw
trigger protection switching, performance data that MAY be used in determining the
unavailability of a transport service.
. reporting via a craft interface to allow replacement of a 3) MPLS-TP MUST support the determination of the unavailability of
faulty component (or similar manual intervention), 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.
. etc. 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].
7) The MPLS-TP NE MUST support reporting of performance 4) The MPLS-TP NE MUST support collection of loss measurement (LM)
statistics on request from a management system. statistics.
7.2. Performance Measurement Instrumentation 5) The MPLS-TP NE MUST support collection of delay measurement (DM)
statistics.
7.2.1. Measurement Frequency 6) The MPLS-TP NE MUST support reporting of performance degradation
via fault management for corrective actions.
1) For performance measurement mechanisms that support both "Reporting" in this context could mean:
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 o reporting to an autonomous protection component to trigger
protection switching,
On measurement of packet loss and loss ratio: o reporting via a craft interface to allow replacement of a
faulty component (or similar manual intervention),
1) For bidirectional (both co-routed and associated) P2P o etc.
connections -
a) on-demand measurement of single-ended packet loss, and 7) The MPLS-TP NE MUST support reporting of performance statistics on
loss ratio, measurement is REQUIRED; request from a management system.
b) proactive measurement of packet loss, and loss ratio, 7.2. Performance Measurement Instrumentation
measurement for each direction is REQUIRED.
2) For unidirectional (P2P and P2MP) connection, proactive 7.2.1. Measurement Frequency
measurement of packet loss, and loss ratio, is REQUIRED.
On Delay measurement: 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.
3) For unidirectional (P2P and P2MP) connection, on-demand 7.2.2. Measurement Scope
measurement of delay measurement is REQUIRED.
4) For co-routed bidirectional (P2P) connection, on-demand On measurement of packet loss and loss ratio:
measurement of one-way and two-way delay is REQUIRED.
5) For associated bidirectional (P2P) connection, on-demand 1) For bidirectional (both co-routed and associated) point-to-point
measurement of one-way delay is REQUIRED. (P2P) connections
8. Security Management Requirements a) on-demand measurement of single-ended packet loss and loss
ratio measurement is REQUIRED;
1) The MPLS-TP NE MUST support secure management and control b) proactive measurement of packet loss and loss ratio measurement
planes. for each direction is REQUIRED.
8.1. Management Communication Channel Security 2) For unidirectional (P2P and point-to-multipoint (P2MP))
connection, proactive measurement of packet loss and loss ratio is
REQUIRED.
1) Secure communication channels MUST be supported for all On Delay measurement:
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 3) For a unidirectional (P2P and P2MP) connection, on-demand
confidentiality and data integrity protection. measurement of delay measurement is REQUIRED.
3) The MPLS-TP NE MUST support the following: 4) For a co-routed bidirectional (P2P) connection, on-demand
measurement of one-way and two-way delay is REQUIRED.
a) Use of open cryptographic algorithms (See RFC 3871 [4]) 5) For an associated bidirectional (P2P) connection, on-demand
measurement of one-way delay is REQUIRED.
b) Authentication - allow management connectivity only from 8. Security Management Requirements
authenticated entities.
c) Authorization - allow management activity originated by an 1) The MPLS-TP NE MUST support secure management and control planes.
authorized entity, using (for example) an Access Control
List (ACL).
d) Port Access Control - allow management activity received 8.1. Management Communication Channel Security
on an authorized (management) port.
8.2. Signaling 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.
Security requirements for the SCC are driven by considerations 2) The MCC MUST support application protocols that provide
similar to MCC requirements described in section 8.1. confidentiality and data-integrity protection.
Security Requirements for the control plane are out of scope for 3) The MPLS-TP NE MUST support the following:
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 a) Use of open cryptographic algorithms (see RFC 3871 [4]).
appropriate control plane specifications..
8.3. Distributed Denial of Service b) Authentication - allow management connectivity only from
authenticated entities.
A Denial of Service (DoS) attack is an attack that tries to c) Authorization - allow management activity originated by an
prevent a target from performing an assigned task, or providing authorized entity, using (for example) an Access Control List
its intended service(s), through any means. A Distributed DoS (ACL).
(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 d) Port Access Control - allow management activity received on an
SHOULD do so in a manner that reduces potential impact of a authorized (management) port.
DoS attack.
2) An MPLS-TP NE SHOULD support additional mechanisms that 8.2. Signaling Communication Channel Security
mitigate a DoS (or DDoS) attack against the management
component while allowing the NE to continue to meet its
primary functions.
9. Security Considerations Security requirements for the SCC are driven by considerations
similar to MCC requirements described in Section 8.1.
Section 8 includes a set of security requirements that apply to Security Requirements for the control plane are out of scope for this
MPLS-TP network management. document and are expected to be defined in the appropriate control
plane specifications.
1) Solutions MUST provide mechanisms to prevent unauthorized 1) Management of control plane security MUST be defined in the
and/or unauthenticated access to management capabilities and appropriate control plane specifications.
private information by network elements, systems or users.
Performance of diagnostic functions and path characterization 8.3. Distributed Denial of Service
involves extracting a significant amount of information about
network construction that the network operator might consider
private.
10. IANA Considerations 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.
There are no IANA actions associated with this document. 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.
11. Acknowledgments 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.
The authors/editors gratefully acknowledge the thoughtful review, 9. Security Considerations
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.
12. References Section 8 includes a set of security requirements that apply to MPLS-
TP network management.
12.1. Normative References 1) Solutions MUST provide mechanisms to prevent unauthorized and/or
unauthenticated access to management capabilities and private
information by network elements, systems, or users.
[1] ITU-T Recommendation G.7710/Y.1701, "Common equipment Performance of diagnostic functions and path characterization
management function requirements", July, 2007. involves extracting a significant amount of information about network
construction that the network operator might consider private.
[2] Nadeau, T., et al, "Operations and Management (OAM) 10. Acknowledgments
Requirements for Multi-Protocol Label Switched (MPLS)
Networks", RFC 4377, February 2006.
[3] Vigoureux, M., et al, "Requirements for OAM in MPLS The authors/editors gratefully acknowledge the thoughtful review,
Transport Networks", draft-ietf-mpls-tp-oam-requirements, comments, and explanations provided by Adrian Farrel, Alexander
work in progress. 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.
[4] Jones, G., "Operational Security Requirements for Large 11. References
Internet Service Provider (ISP) IP Network Infrastructure",
RFC 3871, September 2004.
[5] Bradner, S., "Key words for use in RFCs to Indicate 11.1. Normative References
Requirement Levels", RFC 2119, March 1997.
[6] ITU-T Recommendation G.7712/Y.1703, "Architecture and [1] ITU-T Recommendation G.7710/Y.1701, "Common equipment
specification of data communication network", June 2008. management function requirements", July, 2007.
[7] Niven-Jenkins, B. et al, "MPLS-TP Requirements", draft- [2] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S.
ietf-mpls-tp-requirements, work in progress. Matsushima, "Operations and Management (OAM) Requirements for
Multi-Protocol Label Switched (MPLS) Networks", RFC 4377,
February 2006.
[8] Bocci, M. et al, "A Framework for MPLS in Transport [3] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
Networks", draft-ietf-mpls-tp-framework, work in progress. "Requirements for Operations, Administration, and Maintenance
(OAM) in MPLS Transport Networks", RFC 5860, May 2010.
[9] Mansfield, S. et al, "MPLS-TP Network Management [4] Jones, G., Ed., "Operational Security Requirements for Large
Framework", draft-ietf-mpls-tp-nm-framework, work in Internet Service Provider (ISP) IP Network Infrastructure", RFC
progress. 3871, September 2004.
12.2. Informative References [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[10] Beller, D., et al, "An Inband Data Communication Network [6] ITU-T Recommendation G.7712/Y.1703, "Architecture and
For the MPLS Transport Profile", draft-ietf-mpls-tp-gach- specification of data communication network", June 2008.
dcn, work in progress.
[11] Chisholm, S. and D. Romascanu, "Alarm Management [7] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
Information Base (MIB)", RFC 3877, September 2004. Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport
Profile", RFC 5654, September 2009.
[12] ITU-T Recommendation M.20, "Maintenance philosophy for [8] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L.,
telecommunication networks", October 1992. and L. Berger, "A Framework for MPLS in Transport Networks",
RFC 5921, July 2010.
[13] Telcordia, "Network Maintenance: Network Element and [9] Mansfield, S. Ed., Gray, E., Ed., and K. Lam, Ed., "Network
Transport Surveillance Messages" (GR-833-CORE), Issue 5, Management Framework for MPLS-based Transport Networks", RFC
August 2004. 5950, September 2010.
[14] Bocci, M. et al, "MPLS Generic Associated Channel", RFC 12.2. Informative References
5586, June 2009.
[15] Harrington, D., "Guidelines for Considering Operations and [10] Beller, D. and A. Farrel, "An In-Band Data Communication
Management of New Protocols and Protocol Extensions", Network For the MPLS Transport Profile", RFC 5718, January
draft-ietf-opsawg-operations-and-management, work in 2010.
progress.
[16] Enns, R. et al, "NETCONF Configuration Protocol", draft- [11] Chisholm, S. and D. Romascanu, "Alarm Management Information
ietf-netconf-4741bis, work in progress. Base (MIB)", RFC 3877, September 2004.
[17] Presuhn, R. et al, "Version 2 of the Protocol Operations [12] ITU-T Recommendation M.20, "Maintenance philosophy for
for the Simple Network Management Protocol (SNMP)", RFC telecommunication networks", October 1992.
3416, December 2002.
[18] OMG Document formal/04-03-12, "The Common Object Request [13] Telcordia, "Network Maintenance: Network Element and Transport
Broker: Architecture and Specification", Revision 3.0.3. Surveillance Messages" (GR-833-CORE), Issue 5, August 2004.
March 12, 2004.
[19] Caviglia, D. et al, "Requirements for the Conversion [14] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS
between Permanent Connections and Switched Connections in a Generic Associated Channel", RFC 5586, June 2009.
Generalized Multiprotocol Label Switching (GMPLS) Network",
RFC 5493, April 2009.
[20] Caviglia, D. et al, "RSVP-TE Signaling Extension For The [15] Harrington, D., "Guidelines for Considering Operations and
Conversion Between Permanent Connections And Soft Permanent Management of New Protocols and Protocol Extensions", RFC 5706,
Connections In A GMPLS Enabled Transport Network", draft- November 2009.
ietf-ccamp-pc-spc-rsvpte-ext, work in progress.
[21] ITU-T Recommendation G.806, "Characteristics of transport [16] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and
equipment - Description methodology and generic A. Bierman, Ed., "Network Configuration Protocol (NETCONF)",
functionality", January, 2009. Work in Progress, July 2010.
[22] ITU-T Recommendation Y.1731, "OAM functions and mechanisms [17] Presuhn, R., Ed., "Version 2 of the Protocol Operations for the
for Ethernet based networks", February, 2008. Simple Network Management Protocol (SNMP)", STD 62, RFC 3416,
December 2002.
[23] ITU-T Recommendation G.8601, "Architecture of service [18] OMG Document formal/04-03-12, "The Common Object Request
management in multi bearer, multi carrier environment", Broker: Architecture and Specification", Revision 3.0.3. March
June 2006. 12, 2004.
[24] Lam, H., et al, "Alarm Reporting Control Management [19] Caviglia, D., Bramanti, D., Li, D., and D. McDysan,
Information Base (MIB)", RFC 3878, September 2004. "Requirements for the Conversion between Permanent Connections
and Switched Connections in a Generalized Multiprotocol Label
Switching (GMPLS) Network", RFC 5493, April 2009.
[25] ITU-T Recommendation Y.1563, "Ethernet frame transfer and [20] Caviglia, D., Ceccarelli, D., Bramanti, D., Li, D., and S.
availability performance", January 2009. 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.
[26] Handley, M., et al, "Internet Denial-of-Service [21] ITU-T Recommendation G.806, "Characteristics of transport
Considerations", RFC 4732, November 2006. equipment - Description methodology and generic functionality",
January, 2009.
Authors' Addresses [22] ITU-T Recommendation Y.1731, "OAM functions and mechanisms for
Ethernet based networks", February, 2008.
Eric Gray [23] ITU-T Recommendation G.8601, "Architecture of service
Ericsson management in multi bearer, multi carrier environment", June
900 Chelmsford Street 2006.
Lowell, MA, 01851
Phone: +1 978 275 7470
Email: Eric.Gray@Ericsson.com
Scott Mansfield [24] Lam, H., Huynh, A., and D. Perkins, "Alarm Reporting Control
Ericsson Management Information Base (MIB)", RFC 3878, September 2004.
250 Holger Way
San Jose CA, 95134
+1 724 931 9316
EMail: Scott.Mansfield@Ericsson.com
Hing-Kam (Kam) Lam [25] ITU-T Recommendation Y.1563, "Ethernet frame transfer and
Alcatel-Lucent availability performance", January 2009.
600-700 Mountain Ave
Murray Hill, NJ, 07974
Phone: +1 908 582 0672
Email: hklam@Alcatel-Lucent.com
Contributor's Address [26] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-
of-Service Considerations", RFC 4732, December 2006.
Adrian Farrel Appendix A. Communication Channel (CCh) Examples
Old Dog Consulting
Email: adrian@olddog.co.uk
Copyright Statement A CCh can be realized in a number of ways.
Copyright (c) 2009 IETF Trust and the persons identified as the 1. The CCh can be provided by a link in a physically distinct
document authors. All rights reserved. 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 document is subject to BCP 78 and the IETF Trust's Legal This is a "physically distinct out-of-band CCh".
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-
info). Please review these documents carefully, as they describe
your rights and restrictions with respect to this document.
Acknowledgment 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.
Funding for the RFC Editor function is currently provided by the This is a "physically shared out-of-band CCh."
Internet Society.
Appendix A- Communication Channel (CCh) Examples 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.
A CCh can be realized in a number of ways. This is a "shared interface out-of-band CCh".
1. The CCh can be provided by a link in a physically distinct 4. The CCh can use overhead bytes available on a transport
network. That is, a link that is not part of the transport connection. For example, in TDM networks there are overhead bytes
network that is being managed. For example, the nodes in the associated with a data channel, and these can be used to provide a
transport network can be interconnected in two distinct physical CCh. It is important to note that the use of overhead bytes does
networks: the transport network and the DCN. not reduce the capacity of the associated data channel.
This is a "physically distinct out-of-band CCh". This is an "overhead-based CCh".
2. The CCh can be provided by a link in the transport network This alternative is not available in MPLS-TP because there is no
that is terminated at the ends of the DCC and which is capable of overhead available.
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." 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.
3. The CCh can be supported as its native protocol on the This is a "data link associated CCh".
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". It is very similar to case 2, and by its nature can only span a
single hop in the transport network.
4. The CCh can use overhead bytes available on a transport 6. The CCh can be provided by a dedicated channel associated with a
connection. For example, in TDM networks there are overhead bytes data channel. For example, in MPLS-TP, the GAL [14] can be
associated with a data channel, and these can be used to provide imposed under the top label in the label stack for an MPLS-TP LSP
a CCh. It is important to note that the use of overhead bytes to create a channel associated with the LSP that can carry
does not reduce the capacity of the associated data channel. 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 an "overhead-based CCh". This is a "data channel associated CCh".
This alternative is not available in MPLS-TP because there is no 7. The CCh can be provided by mixing the management traffic with the
overhead available. 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.
5. The CCh can provided by a dedicated channel associated with This is an "in-band CCh".
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". These realizations can be categorized as:
It is very similar to case 2, and by its nature can only span a A. Out-of-fiber, out-of-band (types 1 and 2)
single hop in the transport network. B. In-fiber, out-of-band (types 2, 3, 4, and 5)
C. In-band (types 6 and 7)
6. The CCh can be provided by a dedicated channel associated with The MCN and SCN are logically separate networks and can be realized
a data channel. For example, in MPLS-TP the GAL [14] can be by the same DCN or as separate networks. In practice, that means
imposed under the top label in the label stack for an MPLS-TP LSP that, between any pair of nodes, the MCC and SCC can be the same link
to create a channel associated with the LSP that can carry or separate links.
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". 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.
7. The CCh can be provided by mixing the management traffic with Lastly, note that the division of DCN traffic between links between a
the user traffic such that is indistinguishable on the link pair of adjacent nodes is purely an implementation choice. Parallel
without deep-packet inspection. In MPLS-TP this could arise if links can be deployed for DCN resilience or load sharing. Links can
there is a data-carrying LSP between two nodes, and management be designated for specific use. For example, so that some links
traffic is inserted into that LSP. This approach requires that carry management traffic and some carry control plane traffic, or so
the termination point of the LSP is able to demultiplex the that some links carry signaling protocol traffic while others carry
management and user traffic. Such might be possible in MPLS-TP if routing protocol traffic.
the MPLS-TP LSP was carrying IP user traffic.
This is an "in-band CCh". 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.
These realizations can be categorized as: See also RFC 3877 [11], ITU-T M.20 [12], and Telcordia document
GR-833-CORE [13] for further information.
A. Out-of-fiber, out-of-band (types 1 and 2) Contributor's Address
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 Adrian Farrel
realized by the same DCN or as separate networks. In practice, Old Dog Consulting
that means that, between any pair of nodes, the MCC and SCC can EMail: adrian@olddog.co.uk
be the same link or separate links.
It is also important to note that the MCN and SCN do not need to Authors' Addresses
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 Eric Gray
between a pair of adjacent nodes is purely an implementation Ericsson
choice. Parallel links can be deployed for DCN resilience or load 900 Chelmsford Street
sharing. Links can be designated for specific use. For example, Lowell, MA, 01851
so that some links carry management traffic and some carry Phone: +1 978 275 7470
control plane traffic, or so that some links carry signaling EMail: Eric.Gray@Ericsson.com
protocol traffic while others carry routing protocol traffic.
It is important to note that the DCN can be a routed network with Scott Mansfield
forwarding capabilities, but that this is not a requirement. The Ericsson
ability to support forwarding of management or control traffic 250 Holger Way
within the DCN can substantially simplify the topology of the DCN San Jose CA, 95134
and improve its resilience, but does increase the complexity of +1 724 931 9316
operating the DCN. EMail: Scott.Mansfield@Ericsson.com
See also RFC 3877 [11], ITU-T M.20 [12], and Telcordia document Hing-Kam (Kam) Lam
GR-833-CORE [13] for further information. Alcatel-Lucent
600-700 Mountain Ave
Murray Hill, NJ, 07974
Phone: +1 908 582 0672
EMail: Kam.Lam@Alcatel-Lucent.com
 End of changes. 264 change blocks. 
823 lines changed or deleted 783 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/