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

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