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