draft-ietf-mpls-tp-nm-req-04.txt   draft-ietf-mpls-tp-nm-req-05.txt 
Network Working Group Hing-Kam Lam Network Working Group Hing-Kam Lam
Internet Draft Alcatel-Lucent Internet Draft Alcatel-Lucent
Expires: March, 2010 Scott Mansfield Expires: March 18, 2010 Scott Mansfield
Intended Status: Standards Track Eric Gray Intended Status: Standards Track Eric Gray
Ericsson Ericsson
September 1, 2009 September 18, 2009
MPLS TP Network Management Requirements MPLS TP Network Management Requirements
draft-ietf-mpls-tp-nm-req-04.txt draft-ietf-mpls-tp-nm-req-05.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 March 1, 2010. This Internet-Draft will expire on March 14, 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
skipping to change at page 4, line 7 skipping to change at page 4, line 7
cover fault, configuration, performance, and security management cover fault, configuration, performance, and security management
for MPLS-TP networks, and the requirements for object and for MPLS-TP networks, and the requirements for object and
information models needed to manage MPLS-TP Networks and Network information 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 [12] and [15].
1.1. Terminology 1.1. Terminology
Although this document is not a protocol specification, the key The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in document are to be interpreted as described in RFC 2119 [5]. Although
this document are to be interpreted as described in RFC 2119 [5] this document is not a protocol specification, the use of this
and are to be interpreted as instructions to protocol designers language clarifies the instructions to protocol designers producing
producing solutions that satisfy the requirements set out in solutions that satisfy the requirements set out in this document.
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
skipping to change at page 5, line 22 skipping to change at page 5, line 22
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 MPLS necessary to participate in an MPLS-TP based transport of MPLS necessary to participate in an MPLS-TP based transport
service. See [8] 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 modes of OAM mechanism operation defined - for example - in are 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
skipping to change at page 7, line 7 skipping to change at page 7, line 5
provide the connection to an OS. provide the connection to an OS.
4. Management Communication Network (MCN) Requirements 4. Management Communication Network (MCN) Requirements
Entities of the MPLS-TP management plane communicate via a DCN, Entities of the MPLS-TP management plane communicate via a DCN,
or more specifically via the MCN. The MCN connects management or more specifically via the MCN. The MCN connects management
systems with management systems, management systems with MPLS-TP systems with management systems, management systems with MPLS-TP
NEs, and (in the indirect connectivity case discussed in section NEs, and (in the indirect connectivity case discussed in section
3) MPLS-TP NEs with MPLS-TP NEs. 3) MPLS-TP NEs with MPLS-TP NEs.
RFC 5586 (Error! Reference source not found.) defines a Generic RFC 5586 [13] defines a Generic Associated Channel (G-ACh) to
Associated Channel (G-ACh) to enable the realization of a enable the realization of a communication channel (CCh) between
communication channel (CCh) between adjacent MPLS-TP NEs for adjacent MPLS-TP NEs for management and control. Reference [8]
management and control. Reference [7] describes how the G-ACh describes how the G-ACh may be used to provide infrastructure
may be used to provide infrastructure that forms part of the MCN that forms part of the MCN and SCN. It also explains how MCN and
and SCN. It also explains how MCN and SCN messages are SCN messages are encapsulated, carried on the G-ACh, and
encapsulated, carried on the G-ACh, and decapsulated for decapsulated for delivery to management or signaling/routing
delivery to management or signaling/routing control plane control plane components on a label switching router (LSR).
components on a label switching router (LSR).
ITU-T G.7712/Y.1703 [6], section 7, describes the transport DCN ITU-T G.7712/Y.1703 [6], section 7, describes the transport DCN
architecture and requirements. The MPLS-TP MCN MUST support the architecture and requirements. The MPLS-TP MCN MUST support the
requirements (in reference [6]) for: requirements (in reference [6]) for:
- CCh access functions specified in section 7.1.1; - CCh access functions specified in section 7.1.1;
- MPLS-TP SCC data-link layer termination functions specified - MPLS-TP SCC data-link layer termination functions specified
in section 7.1.2.3; in section 7.1.2.3;
skipping to change at page 8, line 4 skipping to change at page 7, line 47
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 needed, including: management functions for the MCN are needed, 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;
. Capability to enable/disable access by an NE to the DCN. . Capability to enable/disable access by an NE to the DCN.
Note that this is to allow isolating a malfunctioning NE Note that this is to allow isolating a malfunctioning NE
from impacting the rest of the network. from impacting the rest of the network.
5. Fault Management Requirements 5. Fault Management Requirements
The Fault Management functions within an MPLS-TP NE enable the The Fault Management functions within an MPLS-TP NE enable the
supervision, detection, validation, isolation, correction, and supervision, detection, validation, isolation, correction, and
reporting of abnormal operation of the MPLS-TP network and its reporting of abnormal operation of the MPLS-TP network and its
environment. environment.
skipping to change at page 12, line 36 skipping to change at page 12, line 36
If a control plane is supported in an implementation of MPLS-TP, If a control plane is supported in an implementation of MPLS-TP,
the MPLS-TP NE MUST support the configuration of MPLS-TP control the MPLS-TP NE MUST support the configuration of MPLS-TP control
plane functions by the management plane. Further detailed plane functions by the management plane. Further detailed
requirements will be provided along with progress in defining requirements will be provided along with progress in defining
the MPLS-TP control plane in appropriate specifications. the MPLS-TP control plane in appropriate specifications.
6.3. Path Configuration 6.3. Path Configuration
In addition to the requirement to support static provisioning of In addition to the requirement to support static provisioning of
transport paths (defined in [8], section 2.1 - General transport paths (defined in [7], section 2.1 - General
Requirements - requirement 18), an MPLS-TP NE MUST support the Requirements - requirement 18), an MPLS-TP NE MUST support the
configuration of required path performance characteristic configuration of required path performance characteristic
thresholds (e.g. - Loss Measurement [LM], Delay Measurement [DM] thresholds (e.g. - Loss Measurement <LM>, Delay Measurement <DM>
thresholds) necessary to support performance monitoring of the thresholds) necessary to support performance monitoring of the
MPLS-TP service(s). MPLS-TP service(s).
In order to accomplish this, an MPLS-TP NE MUST support In order to accomplish this, an MPLS-TP NE MUST support
configuration of LSP information (such as an LSP identifier of configuration of LSP information (such as an LSP identifier of
some kind) and/or any other information needed to retrieve LSP some kind) and/or any other information needed to retrieve LSP
status information, performance attributes, etc. status information, performance attributes, etc.
If a control plane is supported, and that control plane includes If a control plane is supported, and that control plane includes
support for control-plane/management-plane hand-off for LSP support for control-plane/management-plane hand-off for LSP
skipping to change at page 16, line 23 skipping to change at page 16, line 23
For performance measurement mechanisms that support both For performance measurement mechanisms that support both
proactive and on-demand modes, the MPLS-TP NE MUST support the proactive and on-demand modes, the MPLS-TP NE MUST support the
capability to be configured to operate on-demand or proactively. capability to be configured to operate on-demand or proactively.
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 (both co-routed and associated) P2P . For bidirectional (both co-routed and associated) P2P
connections - connections:
o on-demand measurement of single-ended packet loss, and o on-demand measurement of single-ended packet loss, and
loss ratio, measurement is REQUIRED; loss ratio, measurement is REQUIRED;
o proactive measurement of packet loss, and loss ratio, o proactive measurement of packet loss, and loss ratio,
measurement for each direction is REQUIRED. measurement for each direction is REQUIRED.
. for unidirectional (P2P and P2MP) connection, proactive . for unidirectional (P2P and P2MP) connection, proactive
measurement of packet loss, and loss ratio, is REQUIRED. measurement of packet loss, and loss ratio, is REQUIRED.
skipping to change at page 19, line 10 skipping to change at page 19, line 10
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] Vigoureux, M., et al, "Requirements for OAM in MPLS [3] Vigoureux, M., et al, "Requirements for OAM in MPLS
Transport Networks", work in progress. Transport Networks", draft-ietf-mpls-tp-oam-requirements,
work in progress.
[4] Jones, G., "Operational Security Requirements for Large [4] 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.
[5] Bradner, S., "Key words for use in RFCs to Indicate [5] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[6] ITU-T Recommendation G.7712/Y.1703, "Architecture and [6] ITU-T Recommendation G.7712/Y.1703, "Architecture and
specification of data communication network", June 2008. specification of data communication network", June 2008.
[7] Beller, D., et al, "An Inband Data Communication Network [7] Niven-Jenkins, B. et al, "MPLS-TP Requirements", draft-
For the MPLS Transport Profile", draft-ietf-mpls-tp-gach-
dcn, work in progress.
[8] Niven-Jenkins, B. et al, "MPLS-TP Requirements", draft-
ietf-mpls-tp-requirements, work in progress. ietf-mpls-tp-requirements, work in progress.
12.2. Informative References 12.2. Informative References
[8] Beller, D., et al, "An Inband Data Communication Network
For the MPLS Transport Profile", draft-ietf-mpls-tp-gach-
dcn, work in progress.
[9] Chisholm, S. and D. Romascanu, "Alarm Management [9] Chisholm, S. and D. Romascanu, "Alarm Management
Information Base (MIB)", RFC 3877, September 2004. Information Base (MIB)", RFC 3877, September 2004.
[10] ITU-T Recommendation M.20, "Maintenance philosophy for [10] ITU-T Recommendation M.20, "Maintenance philosophy for
telecommunication networks", October 1992. telecommunication networks", October 1992.
[11] Telcordia, "Network Maintenance: Network Element and [11] 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.
skipping to change at page 20, line 9 skipping to change at page 20, line 9
[14] Harrington, D., "Guidelines for Considering Operations and [14] Harrington, D., "Guidelines for Considering Operations and
Management of New Protocols and Protocol Extensions", Management of New Protocols and Protocol Extensions",
draft-ietf-opsawg-operations-and-management, work in draft-ietf-opsawg-operations-and-management, work in
progress. progress.
[15] Mansfield, S. et al, "MPLS-TP Network Management [15] Mansfield, S. et al, "MPLS-TP Network Management
Framework", draft-ietf-mpls-tp-nm-framework, work in Framework", draft-ietf-mpls-tp-nm-framework, work in
progress. progress.
[16] Enns, R. et al, "NETCONF Configuration Protocol", draft- [16] Enns, R. et al, "NETCONF Configuration Protocol",
ietf-netconf-4741bis, work in progress. draft-ietf-netconf-4741bis, work in progress.
[17] McCloghrie, K. et al, "Structure of Management Information [17] McCloghrie, K. et al, "Structure of Management Information
Version 2 (SMIv2)", RFC 2578, April 1999. Version 2 (SMIv2)", RFC 2578, April 1999.
[18] OMG Document formal/04-03-12, "The Common Object Request [18] OMG Document formal/04-03-12, "The Common Object Request
Broker: Architecture and Specification", Revision 3.0.3. Broker: Architecture and Specification", Revision 3.0.3.
March 12, 2004. March 12, 2004.
[19] Caviglia, D. et al, "Requirements for the Conversion [19] Caviglia, D. et al, "Requirements for the Conversion
between Permanent Connections and Switched Connections in between Permanent Connections and Switched Connections in
skipping to change at page 21, line 5 skipping to change at page 21, line 5
[24] Lam, H., et al, "Alarm Reporting Control Management [24] Lam, H., et al, "Alarm Reporting Control Management
Information Base (MIB)", RFC 3878, September 2004. Information Base (MIB)", RFC 3878, September 2004.
[25] ITU-T Recommendation Y.1563, "Ethernet frame transfer and [25] ITU-T Recommendation Y.1563, "Ethernet frame transfer and
availability performance", January 2009. availability performance", January 2009.
[26] Handley, M., et al, "Internet Denial-of-Service [26] Handley, M., et al, "Internet Denial-of-Service
Considerations", RFC 4732, November 2006. Considerations", RFC 4732, November 2006.
Author's Addresses Editors' Addresses
Editors:
Eric Gray Eric Gray
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
Scott Mansfield Scott Mansfield
Ericsson Ericsson
skipping to change at page 21, line 30 skipping to change at page 21, line 28
+1 724 931 9316 +1 724 931 9316
EMail: Scott.Mansfield@Ericsson.com EMail: Scott.Mansfield@Ericsson.com
Hing-Kam (Kam) Lam Hing-Kam (Kam) Lam
Alcatel-Lucent Alcatel-Lucent
600-700 Mountain Ave 600-700 Mountain Ave
Murray Hill, NJ, 07974 Murray Hill, NJ, 07974
Phone: +1 908 582 0672 Phone: +1 908 582 0672
Email: hklam@Alcatel-Lucent.com Email: hklam@Alcatel-Lucent.com
Author(s): Contributor's Address
Contributor(s):
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
Email: adrian@olddog.co.uk 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.
 End of changes. 18 change blocks. 
39 lines changed or deleted 34 lines changed or added

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