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/ |