draft-ietf-mpls-tp-nm-req-00.txt   draft-ietf-mpls-tp-nm-req-01.txt 
Network Working Group Hing-Kam Lam Network Working Group Hing-Kam Lam
Internet Draft Alcatel-Lucent Internet Draft Alcatel-Lucent
Expires: August, 2009 Scott Mansfield Expires: October, 2009 Scott Mansfield
Intended Status: Informational Eric Gray Intended Status: Informational Eric Gray
Ericsson Ericsson
February 23, 2009 April 15, 2009
MPLS TP Network Management Requirements MPLS TP Network Management Requirements
draft-ietf-mpls-tp-nm-req-00.txt draft-ietf-mpls-tp-nm-req-01.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 the provisions of BCP 78 and BCP 79. with 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 Task Force (IETF), its areas, and its working Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 August 23, 2009. This Internet-Draft will expire on October 15, 2009.
Abstract Abstract
This document specifies the requirements necessary to manage the This document specifies the requirements necessary to manage the
elements and networks that support an MPLS Transport Profile elements and networks that support an MPLS Transport Profile
(MPLS-TP). This document is a product of a joint International (MPLS-TP). This document is a product of a joint International
Telecommunications Union - Telecommunications Standardization Telecommunications Union - Telecommunications Standardization
Sector (ITU-T) and Internet Engineering Task Force (IETF) effort Sector (ITU-T) and Internet Engineering Task Force (IETF) effort
to include a MPLS Transport Profile within the IETF MPLS to include a MPLS Transport Profile within the IETF MPLS
architecture. The requirements are driven by the management architecture. The requirements are driven by the management
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Introduction................................................3 1. Introduction................................................3
1.1. Terminology............................................3 1.1. Terminology............................................3
2. Management Interface Requirements...........................4 2. Management Interface Requirements...........................4
3. Management Communication Channel (MCC) Requirements.........4 3. Management Communication Channel (MCC) Requirements.........4
4. Management Communication Network (MCN) Requirements.........5 4. Management Communication Network (MCN) Requirements.........5
5. Fault Management Requirements...............................5 5. Fault Management Requirements...............................5
5.1. Supervision Function...................................5 5.1. Supervision Function...................................5
5.2. Validation Function....................................7 5.2. Validation Function....................................6
5.3. Alarm Handling Function................................7 5.3. Alarm Handling Function................................7
5.3.1. Alarm Severity Assignment.........................7 5.3.1. Alarm Severity Assignment.........................7
5.3.2. Alarm Suppression.................................8 5.3.2. Alarm Suppression.................................7
5.3.3. Alarm Reporting Control...........................8 5.3.3. Alarm Reporting Control...........................8
5.3.4. Alarm Reporting...................................8 5.3.4. Alarm Reporting...................................8
6. Configuration Management Requirements.......................9 6. Configuration Management Requirements.......................8
6.1. System Configuration...................................9 6.1. System Configuration...................................9
6.2. Control Plane Configuration............................9 6.2. Control Plane Configuration............................9
6.3. Path Configuration.....................................9 6.3. Path Configuration.....................................9
6.4. Protection Configuration..............................10 6.4. Protection Configuration...............................9
6.5. OAM Configuration.....................................10 6.5. OAM Configuration.....................................10
7. Performance Management Requirements........................11 7. Performance Management Requirements........................10
7.1. Path Characterization Performance Metrics.............11 7.1. Path Characterization Performance Metrics.............10
7.2. Performance Measurement Instrumentation..............12 7.2. Performance Measurement Instrumentation..............12
7.2.1. Measurement Frequency............................12 7.2.1. Measurement Frequency............................12
7.2.2. Measurement Scope................................12 7.2.2. Measurement Scope................................12
8. Security Management Requirements...........................13 8. Security Management Requirements...........................13
8.1. Management Communication Channel Security.............13 8.1. Management Communication Channel Security.............13
8.1.1. Security of Management Communications............13 8.2. Signaling Communication Channel Security..............13
8.2. Signaling Communication Channel Security..............14 8.3. Distributed Denial of Service.........................13
8.3. Data Channel Security.................................14
8.4. Distributed Denial of Service.........................14
9. Security Considerations....................................14 9. Security Considerations....................................14
10. IANA Considerations.......................................15 10. IANA Considerations......................................14
11. Acknowledgments...........................................15 11. Acknowledgments...........................................14
12. References................................................15 12. References................................................14
12.1. Normative References.................................15 12.1. Normative References.................................14
12.2. Informative References...............................16 12.2. Informative References...............................15
13. Author's Addresses........................................16 13. Author's Addresses........................................16
Copyright Statement...........................................17 Copyright Statement...........................................16
Acknowledgment................................................17 Acknowledgment................................................17
APPENDIX A: Communication Channel (CC) Examples...............18 APPENDIX A: Communication Channel (CC) Examples...............18
1. Introduction 1. Introduction
This document describes the requirements necessary to manage the This document describes the requirements necessary to manage the
elements and networks that support an MPLS Transport Profile elements and networks that support an MPLS Transport Profile
(MPLS-TP). It leverages the management requirements specified (MPLS-TP). It leverages the management requirements specified
in ITU-T G.7710/Y.1701 [1] and RFC 4377 [2]. ITU-T G.7710/Y.1701 in ITU-T G.7710/Y.1701 [1] and RFC 4377 [2]. ITU-T G.7710/Y.1701
[1] specifies generic management requirements for transport [1] specifies generic management requirements for transport
(including packet-based and circuit-based) networks. RFC 4377 (including packet-based and circuit-based) networks. RFC 4377
skipping to change at page 4, line 34 skipping to change at page 4, line 34
2. Management Interface Requirements 2. Management Interface Requirements
This document does not specify which management interface This document does not specify which management interface
protocol should be the standard protocol for managing MPLS-TP protocol should be the standard protocol for managing MPLS-TP
networks. Managing an end-to-end connection across multiple networks. Managing an end-to-end connection across multiple
operator domains where one domain is managed (for example) via operator domains where one domain is managed (for example) via
NETCONF/XML or SNMP/SMI, and another domain via CORBA/IDL, is NETCONF/XML or SNMP/SMI, and another domain via CORBA/IDL, is
allowed. allowed.
For the management interface to the management system, an MPLS- For the management interface to the management system, an MPLS-
TP NE is not expected to actively support more than one TP NE MAY actively support more than one management protocol in
management protocol in any given deployment. The protocol to be any given deployment. For example, an MPLS-TP NE may use one
supported is at the discretion of the operator. 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 3. Management Communication Channel (MCC) Requirements
An MPLS-TP management network SHOULD support seamless management An MPLS-TP management network SHOULD support seamless management
connectivity with remote MPLS-TP domains and NEs as well as with connectivity with remote MPLS-TP domains and NEs as well as with
termination points located in NEs under control by a third party termination points located in NEs under control by a third party
network operator. See ITU-T G.8601 [8] for example scenarios in network operator. See ITU-T G.8601 [8] for example scenarios in
multi-carrier multi-transport-technology environments. multi-carrier multi-transport-technology environments.
For management purpose, every MPLS-TP NE MUST connect to an OS For management purpose, every MPLS-TP NE MUST connect to an OS
skipping to change at page 5, line 18 skipping to change at page 5, line 18
or more specifically via the MCN. The MCN connects MPLS-TP NEs or more specifically via the MCN. The MCN connects MPLS-TP NEs
with management systems, NEs with NEs, and management systems with management systems, NEs with NEs, and management systems
with management systems. Transport DCN architecture and with management systems. Transport DCN architecture and
requirements are specified in ITU-T G.7712/Y.1703 [7], including requirements are specified in ITU-T G.7712/Y.1703 [7], including
network layer protocols and their interworking. network layer protocols and their interworking.
As a practical requirement, MCN connections require addressing. As a practical requirement, MCN connections require addressing.
See the section on addressing in [13] for further information. See the section on addressing in [13] for further information.
In order to have the MCN operate properly, a number of In order to have the MCN operate properly, a number of
management functions for the MCN are required: management functions for the MCN are required, including:
. Retrieval of DCN network parameters to ensure compatible . Retrieval of DCN network parameters to ensure compatible
functioning, e.g. packet size, timeouts, quality of functioning, e.g. packet size, timeouts, quality of
service, window size, etc.; service, window size, etc.;
. Establishment of message routing between DCN nodes; . Establishment of message routing between DCN nodes;
. Management of DCN network addresses; . Management of DCN network addresses;
. Retrieval of operational status of the DCN at a given node; . Retrieval of operational status of the DCN at a given node;
skipping to change at page 5, line 46 skipping to change at page 5, line 46
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 analyses 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.
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 following transmission The MPLS-TP NE MUST support the following transmission
supervision functions: supervision functions:
. Supervision of continuity check functions used to detect a
broken connection;
. Supervision of connectivity check functions used to detect
misconnection;
. Supervision of looping check functions used to detect loops . Supervision of looping check functions used to detect loops
in the data-plane forwarding path (which result in non- in the data-plane forwarding path (which result in non-
delivery of traffic, wasting of forwarding resources and delivery of traffic, wasting of forwarding resources and
unintended self-replication of traffic); unintended self-replication of traffic);
. Supervision of Alarms based on native OAM, e.g., AIS (Alarm
Indication Signal) and FDI (Forward Defect Indication)
. Supervision of traffic loss measurement in both directions
of the bidirectional connection;
. Supervision of Misinsertion check function used to detect
misinserted packet in the connection
. Supervision of Diagnostic test;
. Supervision of Route determination;
. Supervision of Remote defect indication;
. Supervision of the detection of failure in the sequence of . Supervision of the detection of failure in the sequence of
a protocol exchange (e.g. automatic protection switching a protocol exchange (e.g. automatic protection switching
protocol); protocol);
. Supervision of client failure indication.
The MPLS-TP NE transmission-related supervision mechanisms MUST The MPLS-TP NE transmission-related supervision mechanisms MUST
support the flexibility to be configured to perform on-demand or support the flexibility to be configured to perform on-demand or
proactively. proactively.
The MPLS-TP NE MUST support supervision for software processing The MPLS-TP NE MUST support supervision for software processing
e.g., processing fault, storage capacity problem, version e.g., processing fault, storage capacity problem, version
mismatch, Corrupted data, Out of memory, etc. mismatch, corrupted data, out of memory, etc.
The MPLS-TP NE MUST support hardware-related supervision for The MPLS-TP NE MUST support hardware-related supervision for
interchangeable and non-interchangeable units, cable, and power interchangeable and non-interchangeable units, cable, and power
problem. problem.
The MPLS-TP NE SHOULD support environment-related supervision The MPLS-TP NE SHOULD support environment-related supervision
for temperature, humidity, etc. for temperature, humidity, etc.
The MPLS-TP NE MUST support supervision of the OAM mechanisms
that are deployed for supporting the OAM requirements defined in
[3].
5.2. Validation Function 5.2. Validation Function
Validation is concerned with the integration of Fault Causes Validation is concerned with the integration of Fault Causes
into Failures. A Fault Cause indicates a limited interruption of into Failures. A Fault Cause indicates a limited interruption of
the required transport function. A Fault Cause is not reported the required transport function. A Fault Cause is not reported
to maintenance personnel because it could exist only for a very to maintenance personnel because it could exist only for a very
short time. Note that some of these events however are summed up short time. Note that some of these events however are summed up
in the Performance Monitoring process, and when this sum exceeds in the Performance Monitoring process, and when this sum exceeds
a certain value, a Threshold Report can be generated. a certain value, a Threshold Report can be generated.
skipping to change at page 8, line 18 skipping to change at page 7, line 44
See G.7710 [1] for more description about alarm severity See G.7710 [1] for more description about alarm severity
assignment. assignment.
5.3.2. Alarm Suppression 5.3.2. Alarm Suppression
Alarms may be generated from many sources, including OAM, device Alarms may be generated from many sources, including OAM, device
status, etc. status, etc.
An MPLS-TP NE MUST provide alarm suppression functionality that An MPLS-TP NE MUST provide alarm suppression functionality that
prevents the generation of a superfluous alarms. prevents the generation of superfluous alarms.
Examples of alarm suppression mechanisms include simply Examples of alarm suppression mechanisms include simply
discarding the alarms (or not generating them in the first discarding the alarms (or not generating them in the first
place), or aggregating the alarms together, thereby greatly place), or aggregating the alarms together, thereby greatly
reducing the number of alarm notifications to be emitted. reducing the number of alarm notifications to be emitted.
Note: An MPLS-TP NE supporting the inter-working of one or more Note: An MPLS-TP NE supporting the inter-working of one or more
networking technologies (e.g., Ethernet, SDH/SONET, MPLS) with networking technologies (e.g., Ethernet, SDH/SONET, MPLS) with
MPLS-TP needs to translate an MPLS-TP fault into an existing MPLS-TP needs to translate an MPLS-TP fault into an existing
transport technology failure condition for reporting to the transport technology failure condition for reporting to the
skipping to change at page 9, line 12 skipping to change at page 8, line 40
events and conditions, which occur in the network (including the events and conditions, which occur in the network (including the
NE, incoming signal, and external environment). NE, 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.
An MPLS-TP NE MUST support local reporting of alarms. An MPLS-TP NE MUST support local reporting of alarms.
The MPLS-TP NE MUST support reporting of alarms to an OS. These The MPLS-TP NE MUST support reporting of alarms to an OS. These
reports are either autonomous reports (notifications) or reports reports are either autonomous reports (notifications) or reports
on request by maintenance personnel. The MPLS-TP ME SHOULD on request by maintenance personnel. The MPLS-TP NE SHOULD
report local (environmental) alarms to a network management report local (environmental) alarms to a network management
system. system.
6. Configuration Management Requirements 6. Configuration Management Requirements
Configuration Management provides functions to identify, collect Configuration Management provides functions to identify, collect
data from, provide data to and control NEs. Specific data from, provide data to and control NEs. Specific
configuration tasks requiring network management support include configuration tasks requiring network management support include
hardware and software configuration, configuration of NEs to hardware and software configuration, configuration of NEs to
support transport paths (including required working and support transport paths (including required working and
skipping to change at page 10, line 30 skipping to change at page 10, line 14
6.5. OAM Configuration 6.5. OAM Configuration
The MPLS-TP NE MUST provide the capability to configure the OAM The MPLS-TP NE MUST provide the capability to configure the OAM
entities and functions specified in [3]. entities and functions specified in [3].
The MPLS-TP NE MUST support the capability to choose which OAM The MPLS-TP NE MUST support the capability to choose which OAM
functions to use and which maintenance entity to apply them. functions to use and which maintenance entity to apply them.
The MPLS-TP NE MUST support the capability to configure the OAM The MPLS-TP NE MUST support the capability to configure the OAM
entities/functions as part of LSP setup, including bidirectional entities/functions as part of LSP setup and tear-down, including
point-to-point connections, associated uni-directional point-to- co-routed bidirectional point-to-point, associated bidirectional
point connections, and uni-directional point-to-multipoint point-to-point, and uni-directional (both point-to-point and
connections. point-to-multipoint) connections.
The MPLS-TP NE MUST support the configuration of maintenance The MPLS-TP NE MUST support the configuration of maintenance
entity identifiers (e.g. MEP ID and MIP ID) for the purpose of entity identifiers (e.g. MEP ID and MIP ID) for the purpose of
LSP connectivity checking. LSP connectivity checking.
The MPLS-TP NE MUST have the flexibility to configure OAM The MPLS-TP NE MUST have the flexibility to configure OAM
parameters to meet their specific operational requirements, such parameters to meet their specific operational requirements, such
as whether (1) one-time on-demand immediately or (2) one-time as whether (1) one-time on-demand immediately or (2) one-time
on-demand pre-scheduled or (3) on-demand periodically based on a on-demand pre-scheduled or (3) on-demand periodically based on a
specified schedule or (4) proactive on-going. specified schedule or (4) proactive on-going.
skipping to change at page 12, line 44 skipping to change at page 12, line 24
7.2.1. Measurement Frequency 7.2.1. Measurement Frequency
The performance measurement mechanisms MUST support the The performance measurement mechanisms MUST support the
flexibility to be configured to operate on-demand or proactively flexibility to be configured to operate on-demand or proactively
(i.e. continuously over a period of time). (i.e. continuously over a period of time).
7.2.2. Measurement Scope 7.2.2. Measurement Scope
On measurement of packet loss and loss ratio: On measurement of packet loss and loss ratio:
- For bidirectional P2P connections - - For bidirectional (both co-routed and associated) P2P
connections -
. on-demand measurement of single-ended packet loss,
and loss ratio, measurement are required;
. proactive measurement of packet loss, and loss
ratio, measurement for each direction are required.
- For associated unidirectional P2P connections -
. on-demand measurement of single-ended packet loss, . on-demand measurement of single-ended packet loss,
and loss ratio, measurement are required; and loss ratio, measurement are required;
. proactive measurement of packet loss, and loss . proactive measurement of packet loss, and loss
ratio, measurement for each direction are required. ratio, measurement for each direction are required.
Note: for associated unidirectional P2P connections, this data Note: for associated bidirectional P2P connections, this data
can only be measured at end-points. can only be measured at end-points.
- For unidirectional (P2P and P2MP) connection, proactive - For unidirectional (P2P and P2MP) connection, proactive
measurement of packet loss, and loss ratio, are required. measurement of packet loss, and loss ratio, are required.
On Delay measurement: On Delay measurement:
- For unidirectional (P2P and P2MP) connection, on-demand - For unidirectional (P2P and P2MP) connection, on-demand
measurement of delay measurement is required. measurement of delay measurement is required.
- For bidirectional (P2P) connection, on-demand measurement - For co-routed bidirectional (P2P) connection, on-demand
of one-way and two-way delay are required. measurement of one-way and two-way delay are required.
- For associated bidirectional (P2P) connection, on-demand
measurement of one-way delay is required.
8. Security Management Requirements 8. Security Management Requirements
The MPLS-TP NE MUST support secure management and control The MPLS-TP NE MUST support secure management and control
planes. planes.
8.1. Management Communication Channel Security 8.1. Management Communication Channel Security
Secure channels MUST be provided for all network traffic and Secure channels MUST be provided for all network traffic and
protocols used to support management functions. This MUST protocols used to support management functions. This MUST
include, at least, protocols used for configuration, monitoring, include, at least, protocols used for configuration, monitoring,
configuration backup, logging, time synchronization, configuration backup, logging, time synchronization,
authentication, and routing. The MCC MUST support application authentication, and routing. The MCC MUST support application
protocols that provide confidentiality and data integrity protocols that provide confidentiality and data integrity
protection. protection.
8.1.1. Security of Management Communications
If management communication security is provided, the MPLS-TP NE If management communication security is provided, the MPLS-TP NE
MUST support the following: MUST support the following:
- Use of open cryptographic algorithms (See RFC 3871 [5]) - Use of open cryptographic algorithms (See RFC 3871 [5])
- Authentication - allow management connectivity only from - Authentication - allow management connectivity only from
authenticated entities. authenticated entities.
- Authorization - allow management activity originated by an - Authorization - allow management activity originated by an
authorized entity, using (for example) an Access Control authorized entity, using (for example) an Access Control
skipping to change at page 14, line 21 skipping to change at page 13, line 44
8.2.Signaling Communication Channel Security 8.2.Signaling Communication Channel Security
Security considerations for the SCC are similar to the Security considerations for the SCC are similar to the
considerations driving the requirements described in section considerations driving the requirements described in section
8.1. Security Requirements for the control plane are out of 8.1. Security Requirements for the control plane are out of
scope for this document and are expected to be defined in the scope for this document and are expected to be defined in the
appropriate control plane specifications. Management of the appropriate control plane specifications. Management of the
control plane security must also be defined at that time. control plane security must also be defined at that time.
8.3. Data Channel Security 8.3. Distributed Denial of Service
8.4.Distributed Denial of Service
Denial of Service (DoS) attack is an attack which tries to Denial of Service (DoS) attack is an attack which tries to
prevent a target from performing an assigned task, or providing prevent a target from performing an assigned task, or providing
its intended service(s), through any means. A Distributed DoS its intended service(s), through any means. A Distributed DoS
(DDoS) can multiply attack severity (possibly by an arbitrary (DDoS) can multiply attack severity (possibly by an arbitrary
amount) by using multiple (potentially compromised) systems to amount) by using multiple (potentially compromised) systems to
act as topologically (and potentially geographically) act as topologically (and potentially geographically)
distributed attack sources. It is possible to lessen the impact distributed attack sources. It is possible to lessen the impact
and potential for DDOS by using secure protocols, turning off and potential for DDOS by using secure protocols, turning off
unnecessary processes, logging and monitoring, and ingress unnecessary processes, logging and monitoring, and ingress
filtering. RFC 4732 [4] provides background on DOS in the filtering. RFC 4732 [4] provides background on DOS in the
context of the Internet. context of the Internet.
9. Security Considerations 9. Security Considerations
Section 8 lists a set of security requirements that apply to Section 8 includes a set of security requirements that apply to
MPLS-TP network management. MPLS-TP network management.
Provisions to any of the network mechanisms designed to satisfy Solutions MUST provide mechanisms to prevent unauthorized and/or
the requirements described herein are required to prevent their unauthenticated access to private information by network
unauthorized use. Likewise, these network mechanisms MUST elements, systems or users.
provide a means by which an operator can prevent denial of
service attacks if those network mechanisms are used in such an
attack.
Solutions MUST provide mechanisms to prevent this private
information from being accessed by unauthorized eavesdropping,
or being directly obtained by an unauthenticated network
element, system or user.
Performance of diagnostic functions and path characterization Performance of diagnostic functions and path characterization
involves extracting a significant amount of information about involves extracting a significant amount of information about
network construction that the network operator MAY consider network construction that the network operator MAY consider
private. private.
10. IANA Considerations 10. IANA Considerations
<insert IANA considerations, if any, here) There are no IANA actions associated with this document.
11. Acknowledgments 11. Acknowledgments
The authors/editors gratefully acknowledge the thoughtful The authors/editors gratefully acknowledge the thoughtful
review, comments and explanations provided by Adrian Farrel, review, comments and explanations provided by Adrian Farrel,
Andrea Maria Mazzini, Ben Niven-Jenkins, Bernd Zeuner, Diego Andrea Maria Mazzini, Ben Niven-Jenkins, Bernd Zeuner, Diego
Caviglia, Dieter Beller, He Jia, Leo Xiao and Maarten Vissers. Caviglia, Dieter Beller, He Jia, Leo Xiao, Maarten Vissers, Neil
Harrison and Rolf Winter.
12. References 12. References
12.1. Normative References 12.1. Normative References
[1] ITU-T Recommendation G.7710/Y.1701, "Common equipment [1] ITU-T Recommendation G.7710/Y.1701, "Common equipment
management function requirements", July, 2007. management function requirements", July, 2007.
[2] Nadeau, T., et al., "Operations and Management (OAM) [2] Nadeau, T., et al, "Operations and Management (OAM)
Requirements for Multi-Protocol Label Switched (MPLS) Requirements for Multi-Protocol Label Switched (MPLS)
Networks", RFC 4377, February 2006. Networks", RFC 4377, February 2006.
[3] Vigoureus, M., et al., "Requirements for OAM in MPLS [3] Vigoureus, M., et al, "Requirements for OAM in MPLS
Transport Networks", work in progress. Transport Networks", work in progress.
[4] Handley, M., et al., "Internet Denial-of-Service [4] Handley, M., et al, "Internet Denial-of-Service
Considerations", RFC 4732, November 2006. Considerations", RFC 4732, November 2006.
[5] Jones, G., "Operational Security Requirements for Large [5] Jones, G., "Operational Security Requirements for Large
Internet Service Provider (ISP) IP Network Internet Service Provider (ISP) IP Network
Infrastructure", RFC 3871, September 2004. Infrastructure", RFC 3871, September 2004.
[6] Bradner, S., "Key words for use in RFCs to Indicate [6] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[7] ITU-T Recommendation G.7712/Y.1703, "Architecture and [7] ITU-T Recommendation G.7712/Y.1703, "Architecture and
Specification of Data Communication Network", June 2008. Specification of Data Communication Network", June 2008.
[8] ITU-T Recommendation G.8601, "Architecture of service [8] ITU-T Recommendation G.8601, "Architecture of service
management in multi bearer, multi carrier environment", management in multi bearer, multi carrier environment",
June 2006. June 2006.
[9] Lam, H., et al., "Alarm Reporting Control Management [9] Lam, H., et al, "Alarm Reporting Control Management
Information Base (MIB)", RFC 3878, September 2004. Information Base (MIB)", RFC 3878, September 2004.
12.2. Informative References 12.2. Informative References
[10] Chisholm, S. and D. Romascanu, "Alarm Management [10] Chisholm, S. and D. Romascanu, "Alarm Management
Information Base (MIB)", RFC 3877, September 2004. Information Base (MIB)", RFC 3877, September 2004.
[11] ITU-T Recommendation M.20, "Maintenance Philosophy for [11] ITU-T Recommendation M.20, "Maintenance Philosophy for
Telecommunication Networks", October 1992. Telecommunication Networks", October 1992.
[12] Telcordia, "Network Maintenance: Network Element and [12] Telcordia, "Network Maintenance: Network Element and
Transport Surveillance Messages" (GR-833-CORE), Issue 5, Transport Surveillance Messages" (GR-833-CORE), Issue 5,
August 2004. August 2004.
[13] Bocci, M. et al., "A Framework for MPLS in Transport [13] Bocci, M. et al, "A Framework for MPLS in Transport
Networks", Work in Progress, November 27, 2008. Networks", Work in Progress, November 27, 2008.
[14] ANSI T1.231-2003, "Layer 1 In-Service Transmission [14] ANSI T1.231-2003, "Layer 1 In-Service Transmission
Performance Monitoring", American National Standards Performance Monitoring", American National Standards
Institute, 2003. Institute, 2003.
[15] Vigoureux, M. et al, "MPLS Generic Associated Channel",
draft-ietf-mpls-tp-gach-gal, work in progress.
13. Author's Addresses 13. Author's Addresses
Editors: Editors:
Scott Mansfield Scott Mansfield
Ericsson Ericsson
5000 Ericsson Drive 5000 Ericsson Drive
Warrendale, PA, 15086 Warrendale, PA, 15086
Phone: +1 724 742 6726 Phone: +1 724 742 6726
EMail: Scott.Mansfield@Ericsson.com EMail: Scott.Mansfield@Ericsson.com
skipping to change at page 17, line 12 skipping to change at page 16, line 34
Ericsson Ericsson
900 Chelmsford Street 900 Chelmsford Street
Lowell, MA, 01851 Lowell, MA, 01851
Phone: +1 978 275 7470 Phone: +1 978 275 7470
Email: Eric.Gray@Ericsson.com Email: Eric.Gray@Ericsson.com
Author(s): Author(s):
Contributor(s): Contributor(s):
Adrian Farrel
Old Dog Consulting
Email: adrian@olddog.co.uk
Copyright Statement Copyright Statement
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-
publication of this document. Please review these documents info). Please review these documents carefully, as they
carefully, as they describe your rights and restrictions with describe your rights and restrictions with respect to this
respect to this document. document.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
APPENDIX A: Communication Channel (CC) Examples APPENDIX A: Communication Channel (CC) Examples
A CC may be realized in a number of ways. A CC may be realized in a number of ways.
skipping to change at page 18, line 50 skipping to change at page 18, line 50
bytes does not reduce the capacity of the associated data bytes does not reduce the capacity of the associated data
channel. channel.
This is an "overhead-based CC". This is an "overhead-based CC".
This alternative is not available in MPLS-TP because there is no This alternative is not available in MPLS-TP because there is no
overhead available. overhead available.
5. The CC may provided by a dedicated channel associated with 5. The CC may provided by a dedicated channel associated with
the data link. For example, the generic associated label (GAL) the data link. For example, the generic associated label (GAL)
[GAL-GACH] may be used to label DCC traffic being exchanged on a [15] may be used to label DCC traffic being exchanged on a data
data link between adjacent transport nodes, potentially in the link between adjacent transport nodes, potentially in the
absence of any data LSP between those nodes. absence of any data LSP between those nodes.
This is a "data link associated CC". This is a "data link associated CC".
It is very similar to case 2, and by its nature can only span a It is very similar to case 2, and by its nature can only span a
single hop in the transport network. single hop in the transport network.
6. The CC may be provided by a dedicated channel associated with 6. The CC may be provided by a dedicated channel associated with
a data channel. For example, in MPLS-TP the GAL [GAL-GACH] may a data channel. For example, in MPLS-TP the GAL [15] may be
be imposed under the top label in the label stack for an MPLS-TP 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 LSP to create a channel associated with the LSP that may carry
management traffic. This CC requires the receiver to be capable management traffic. This CC requires the receiver to be capable
of demultiplexing management traffic from user traffic carried of demultiplexing management traffic from user traffic carried
on the same LSP by use of the GAL. on the same LSP by use of the GAL.
This is a "data channel associated CC". This is a "data channel associated CC".
7. The CC may be provided by mixing the management traffic with 7. The CC may be provided by mixing the management traffic with
the user traffic such that is indistinguishable on the link the user traffic such that is indistinguishable on the link
without deep-packet inspection. In MPLS-TP this could arise if without deep-packet inspection. In MPLS-TP this could arise if
 End of changes. 42 change blocks. 
102 lines changed or deleted 71 lines changed or added

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