One document matched: draft-gray-mpls-tp-nm-req-02.txt
Differences from draft-gray-mpls-tp-nm-req-01.txt
Network Working Group Hing-Kam Lam
Internet Draft Alcatel-Lucent
Expires: April, 2009 Scott Mansfield
Intended Status: Informational Eric Gray
Ericsson
January 16, 2009
MPLS TP Network Management Requirements
draft-gray-mpls-tp-nm-req-02.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance
with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on July 16, 2009.
Abstract
This document specifies the requirements necessary to manage the
elements and networks that support an MPLS Transport Profile
(MPLS-TP). This document is a product of a joint International
Telecommunications Union - Telecommunications Standardization
Sector (ITU-T) and Internet Engineering Task Force (IETF) effort
to include a MPLS Transport Profile within the IETF MPLS
architecture. The requirements are driven by the management
functionality needs defined by ITU-T for packet transport
networks.
Gray, et al Expires July, 2009 [Page 1]
Internet-Draft MPLS-TP NM Requirements January, 2009
Table of Contents
1. Introduction................................................3
1.1. Terminology............................................3
2. Management Interface Requirements...........................4
3. Management Communication Channel (MCC) Requirements.........4
4. Management Communication Network (MCN) Requirements.........5
5. Fault Management Requirements...............................5
5.1. Supervision Function...................................5
5.2. Validation Function....................................6
5.3. Alarm Handling Function................................7
5.3.1. Alarm Severity Assignment.........................7
5.3.2. Alarm Suppression.................................8
5.3.3. Alarm Reporting Control...........................8
5.3.4. Alarm Reporting...................................8
6. Configuration Management Requirements.......................9
6.1. Hardware/Software Configuration........................9
6.2. Path Configuration.....................................9
6.3. OAM Configuration......................................9
7. Performance Management Requirements........................10
7.1. Path Characterization Performance Metrics.............10
7.2. Performance Collection Instrumentation................11
7.2.1. Collection Frequency.............................11
7.2.2. Collection Granularity...........................11
8. Security Management Requirements...........................12
8.1. Management Communication Channel Security.............12
8.1.1. In-Band management security......................12
8.1.2. Out-of-Band management security..................12
8.2. Signaling Communication Channel Security..............13
8.3. Distributed Denial of Service.........................13
9. Security Considerations....................................13
10. IANA Considerations.......................................13
11. Acknowledgments...........................................14
12. References................................................14
12.1. Normative References.................................14
12.2. Informative References...............................14
13. Author's Addresses........................................15
Intellectual Property Statement...............................15
Disclaimer of Validity........................................16
Copyright Statement...........................................16
Acknowledgment................................................16
Gray, et al Expires July, 2009 [Page 2]
Internet-Draft MPLS-TP NM Requirements January, 2009
1. Introduction
This document describes the requirements necessary to manage the
elements and networks that support an MPLS Transport Profile
(MPLS-TP). It leverages on the management requirements
specified 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 (including packet-based and circuit-based) networks.
RFC 4377 specifies the OAM requirements, including OAM-related
network management requirements, for MPLS networks. This
document expands on the requirements in [1] and [2] to cover
fault, configuration, performance, and security management for
MPLS-TP networks.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC 2119 [6].
Editor's Note: Do we need the bulk of this section, since it
will be in the NM-FRAME document? Should we have the acronyms
spelled out in both documents?
MPLS-TP NE: a network element (NE) that supports MPLS-TP
functions
MPLS-TP network: a network in which MPLS-TP NEs are deployed
Data Communication Network (DCN): a network that supports Layer
1 (physical layer), Layer 2 (data-link layer), and Layer 3
(network layer) functionality for distributed management
communications related to the management plane, for distributed
signaling communications related to the control plane, and other
operations communications (e.g., order-wire/voice
communications, software downloads, etc.).
Management Communication Network (MCN): A DCN supporting
management plane communication is referred to as a Management
Communication Network (MCN).
Signaling Communication Network (SCN): A DCN supporting control
plane communication is referred to as a Signaling Communication
Network (SCN).
Gray, et al Expires July, 2009 [Page 3]
Internet-Draft MPLS-TP NM Requirements January, 2009
Embedded Communication Channel (ECC): a logical channel between
network elements (NEs) that can be used - e.g. - for management
plane application or control plane applications. The physical
channel supporting the ECC is technology specific. An example of
physical channels supporting the ECC is a DCC channel within
SDH.
Management Communication Channel (MCC): an ECC dedicated for
management plane communications.
Signaling Communication Channel (SCC): an ECC dedicated for
control plane communications. The SCC MAY be used for GMPLS/ASON
signaling and/or other control plane messages like e.g., routing
messages.
2.Management Interface Requirements
This document does not specify which management interface
protocol should be the standard protocol for managing MPLS-TP
networks. Managing an end-to-end connection across multiple
operator domains where one domain is managed (for example) via
NETCONF/XML or SNMP/SMI, and another domain via CORBA/IDL, is
allowed.
For the management interface to the management system, an MPLS-
TP NE is not expected to actively support more than one
management protocol in any given deployment. The protocol to be
supported is at the discretion of the operator.
3. Management Communication Channel (MCC) Requirements
The MPLS-TP management network SHOULD support seamless management
connectivity with remote MPLS-TP domains and NEs as specified
generically in ITU-T G.8601 [8] as well as with termination points
located in NEs under control by a third party network operator as
specified in G.8601.
For management purpose, every MPLS-TP NE MUST connect to an OS
either directly or indirectly via another MPLS-TP NE. When an
MPLS-TP NE is connected indirectly to an OS, an MCC MUST be
supported between the MPLS-TP NE and the other MPLS-TP NE.
Gray, et al Expires July, 2009 [Page 4]
Internet-Draft MPLS-TP NM Requirements January, 2009
4.Management Communication Network (MCN) Requirements
Entities of the MPLS-TP management plane communicate via the
DCN, or more specifically via the MCN. The MCN connects MPLS-TP
NEs with management systems, NEs with NEs, and management
systems with management systems. Transport DCN architecture and
requirements are specified in ITU-T G.7712/Y.1703 [7], including
network layer protocols and their interworking.
In order to have the MCN operate properly, a number of
management functions for the MCN are required:
. Retrieval of DCN network parameters to ensure compatible
functioning, e.g. packet size, timeouts, quality of
service, window size, etc.;
. Establishment of message routing between DCN nodes;
. Management of DCN network addresses;
. Retrieval of operational status of the DCN at a given node;
. Capability to enable/disable access to the DCN.
5.Fault Management Requirements
The Fault Management functions within an MPLS-TP NE enable the
supervision, detection, validation, isolation, correction, and
reporting of abnormal operation of the MPLS-TP network and its
environment.
5.1. Supervision Function
The supervision function analyses the actual occurrence of a
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 the following transmission
supervision functions:
. Supervision of continuity check functions used to detect a
broken connection;
. Supervision of connectivity check functions used to detect
misconnection;
Gray, et al Expires July, 2009 [Page 5]
Internet-Draft MPLS-TP NM Requirements January, 2009
. Supervision of looping check functions used to detect
unintended self-replication;
. Supervision of Alarms based on native OAM, e.g., AIS (Alarm
Indication Signal) and FDI (Forward Defect Indication)
. Supervision of Lock indication;
. Supervision of Packet 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 tracing;
. Supervision of Remote defect indication;
. Supervision of the detection of failure in the sequence of
a protocol exchange (e.g. automatic protection switching
protocol);
The MPLS-TP NE transmission-related supervision mechanisms MUST
support the flexibility to be configured to perform on-demand or
proactively.
The MPLS-TP NE MUST support supervision for software processing
e.g., processing fault, storage capacity problem, version
mismatch, Corrupted data, Out of memory, etc.
The MPLS-TP NE MUST support hardware-related supervision for
interchangeable and non-interchangeable units, cable, and power
problem.
The MPLS-TP NE SHOULD support environment-related supervision
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
Validation is concerned with the integration of Fault Causes
into Failures. A Fault Cause indicates a limited interruption of
Gray, et al Expires July, 2009 [Page 6]
Internet-Draft MPLS-TP NM Requirements January, 2009
the required transport function. A Fault Cause is not reported
to maintenance personnel because it could exist only for a very
short time. Note that some of these events however are summed up
in the Performance Monitoring process, and when this sum exceeds
a certain value, a Threshold Report can be generated.
When the Fault Cause lasts long enough, an inability to perform
the required transport function arises. This Failure condition
is subject to reporting to maintenance personnel and/or OS
because corrective action might be required. Conversely, when
the Fault Cause ceases after a certain time, clearing of the
Failure condition also subject to reporting.
The MPLS-TP NE MUST perform persistency check on fault causes
before it declares a fault cause a failure.
A transmission failure SHALL be declared if the fault cause
persists continuously for a configurable time (Time-D). The
failure SHALL be cleared if the fault cause is absent
continuously for a configurable time (Time-C). Typically the
default time values would be as follows:
Time-D = 2.5 +/- 0.5 seconds
Time-C = 10 +/- 0.5 seconds
These time values are as defined in G.7710 [1].
The failure declaration and clearing MUST be time stamped. The
time-stamp SHALL 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.3.1. Alarm Severity Assignment
Failures might be categorized to indicate the severity or
urgency of the fault.
An MPLS-TP NE SHOULD support the flexibility of assignment of
severity (e.g., Critical, Major, Minor, Warning) by the
management system.
Gray, et al Expires July, 2009 [Page 7]
Internet-Draft MPLS-TP NM Requirements January, 2009
See G.7710 [1] for more description about alarm severity
assignment.
5.3.2. Alarm Suppression
An MPLS-TP NE MUST provide alarm suppression functionality that
prevents the generation of a superfluous generation of alarms.
Examples of alarm suppression mechanism include simply
discarding the alarms (or not generating them in the first
place), or aggregating the alarms together, thereby greatly
reducing the number of alarm notifications to be emitted.
An MPLS-TP NE supporting the inter-working of one or more
networking technologies (e.g., Ethernet, SDH/SONET, OTN, MPLS)
with MPLS-TP MUST be able to translate an MPLS-TP defect into
the native technology's error condition.
See RFC 4377 [2] for more description.
5.3.3. Alarm Reporting Control
Alarm Reporting Control (ARC) supports an automatic in-service
provisioning capability. Alarm reporting MAY 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.
An MPLS-TP NE SHOULD support the Alarm Reporting Control
function for controlling the reporting of alarm conditions.
See G.7710 [1] and RFC 3878 [1] for more description of ARC.
5.3.4. Alarm Reporting
Alarm Reporting is concerned with the reporting of relevant
events and conditions, which occur in the network (including the
NE, incoming signal, and external environment).
Local reporting is concerned with automatic alarming by means of
audible and visual indicators near the failed equipment.
An MPLS-TP NE MUST support local reporting of alarms.
The MPLS-TP NE MUST support reporting of alarms to an OS. These
reports are either autonomous reports (notifications) or reports
Gray, et al Expires July, 2009 [Page 8]
Internet-Draft MPLS-TP NM Requirements January, 2009
on request by maintenance personnel. The MPLS-TP ME SHOULD
report local (environmental) alarms to a network management
system.
6. Configuration Management Requirements
Configuration Management provides functions to identify, collect
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).
6.1. Hardware/Software Configuration
The MPLS-TP NE MUST support the configuration requirements
specified in G.7710 [1] for hardware, software, and date/time.
6.2. Path Configuration
The MPLS-TP NE MUST support the capability of configuring
required working and/or protection paths.
The MPLS-TP NE MUST support the capability of configuring
required path performance characteristic thresholds (e.g. - Loss
Measurement [LM], Delay Measurement [DM] thresholds).
The MPLS-TP NE MUST support the capability of configuring
required path protection as follows:
. configure some paths as working and others as protection;
. retrieve the status of these paths;
. configure the wait to restore time;
. operate/release manual protection switching;
. operate/release force protection switching;
. operate/release protection lockout;
. request/set automatic protection switching (APS)
parameters.
6.3. OAM Configuration
The MPLS-TP NE MUST provide the capability of configuring the
OAM functions specified in [3].
The MPLS-TP NE MUST support the capability to choose which OAM
functions to use and which maintenance entity to apply them.
Gray, et al Expires July, 2009 [Page 9]
Internet-Draft MPLS-TP NM Requirements January, 2009
The MPLS-TP NE MUST support the capability of configuring the
OAM functions as part of connectivity management, including
bidirectional point-to-point connection, uni-directional point-
to-point connection, and uni-directional point-to-multipoint
connection.
The MPLS-TP NE MUST support the configuration of maintenance
entity identifiers (e.g. MEP ID and MIP ID) for the purpose of
connection connectivity checking.
The MPLS-TP NE MUST have the flexibility to configure OAM
parameters to meet their specific operational requirements, such
as whether (1) one-time on-demand immediately or (2) one-time
on-demand pre-scheduled or (3) on-demand periodically based on a
specified schedule or (4) proactive on-going.
The MPLS-TP NE MUST support the enabling/disabling of the
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
Performance Management provides functions to evaluate and report
upon the behavior of the equipment, NE, and network for the
purpose of Maintenance, Bring-into-service, Quality of service,
and Performance monitoring for signal degradation. ITU-T
Recommendation G.7710 [1] provides transport performance
monitoring requirements for packet-switched and circuit-switched
transport networks with the objective of providing coherent and
consistent interpretation of the network behavior, in particular
for hybrid network which consists of multiple transport
technologies. The performance management requirements specified
in this document are driven by such an objective.
7.1. Path Characterization Performance Metrics
The MPLS-TP NE MUST support collection of loss measurement (LM)
so that they can be used to detect performance degradation.
The MPLS-TP NE MUST support collection of delay measurement (DM)
so that they can be used to detect performance degradation.
The MPLS-TP NE MUST support reporting of Performance degradation
via fault management for corrective actions (e.g. protection
switching).
Gray, et al Expires July, 2009 [Page 10]
Internet-Draft MPLS-TP NM Requirements January, 2009
The MPLS-TP NE MUST support collection of loss ratio measurement
so that they can be used to determine Severely Errored Second
(SES).
A SES is declared for a one second interval when the ratio of
lost packets to total transmitted packets in that one second
interval exceeds a predetermined threshold.
The packet lost threshold for declaring SES MUST be
configurable.
The number of SESs MUST be collected per configurable intervals
(e.g. 15-minute and 24-hour).
The MPLS-TP NE MUST support collection of SES measurement so
that they can be used to determine service unavailable time.
A period of unavailable time (UAT) begins at the onset of 10
consecutive SES events. These 10 seconds are considered to be
part of unavailable time. A new period of available time begins
at the onset of 10 consecutive non-SES events. These 10 seconds
are considered to be part of available time.
The MPLS-TP NE MUST support collection of UAS so that they can
be used to determine service availability.
The number of unavailable time in seconds (UAS) MUST be
collected per configurable intervals (e.g. 15-minute and 24-
hour).
7.2.Performance Collection Instrumentation
7.2.1. Collection Frequency
The performance collection mechanisms MUST support the
flexibility to be configured to operate on-demand or proactively
(i.e. continuously).
7.2.2. Collection Granularity
On Packet loss measurement:
- For bidirectional (P2P) connection, collection of on-demand
single-ended packet loss measurement is required.
- For bidirectional (P2P) connection, collection of proactive
packet loss measurements for both directions is required.
Gray, et al Expires July, 2009 [Page 11]
Internet-Draft MPLS-TP NM Requirements January, 2009
- For unidirectional (P2P and P2MP) connection, collection of
proactive packet loss measurement is required.
On Delay measurement:
- For unidirectional (P2P and P2MP) connection, collection of
on-demand delay measurement is required.
- For bidirectional (P2P) connection, collection of on-demand
one-way and two-way delay measurement is required.
8. Security Management Requirements
The MPLS-TP NE MUST be able to secure the transport plane and
control plane.
8.1. Management Communication Channel Security
Secure channels MUST be provided for all network traffic and
protocols used to support management functions. This MUST
include, at least, protocols used for configuration, monitoring,
configuration backup, logging, time synchronization,
authentication, and routing. The MCC MUST support application
protocols that provide confidentiality and data integrity
protection.
8.1.1. In-Band management security
If in-band management is provided, the MCC MUST support the
following:
- Use of open cryptographic algorithms (See RFC 3871 [5]
section 4.5)
- Authentication
- Allow management connectivity only from authorized IP
addresses or MAC Addresses.
8.1.2. Out-of-Band management security
The MPLS TP NE MUST support an out-of-band management console
port. The management traffic MUST remain separate from the data
and control plane traffic (no routing or forwarding between the
management plane and the data/control plane).
Gray, et al Expires July, 2009 [Page 12]
Internet-Draft MPLS-TP NM Requirements January, 2009
8.2. Signaling Communication Channel Security
Secure control plane protocols MAY be used in place of their
insecure counterparts. If an insecure protocol is used, the
transport layer protocol MAY be used to secure the SCC.
8.3. Distributed Denial of Service
Denial of Service (DoS) attack is an attack which tries to
prevent a target from performing an assigned task, or providing
its intended service(s), through any means. A Distributed DoS
(DDoS) can multiply attack severity (possibly by an arbitrary
amount) by using multiple (potentially compromised) systems to
act as topologically (and potentially geographically)
distributed attack sources. It is possible to lessen the impact
and potential for DDOS by using secure protocols, turning off
unnecessary processes, logging and monitoring, and ingress
filtering. RFC 4732 [4] provides background on DOS in the
context of the Internet.
9. Security Considerations
Section 8 lists a set of security requirements that apply to
MPLS-TP network management.
Provisions to any of the network mechanisms designed to satisfy
the requirements described herein are required to prevent their
unauthorized use. Likewise, these network mechanisms MUST
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
involves extracting a significant amount of information about
network construction that the network operator MAY consider
private.
10. IANA Considerations
<insert IANA considerations, if any, here)
Gray, et al Expires July, 2009 [Page 13]
Internet-Draft MPLS-TP NM Requirements January, 2009
11. Acknowledgments
The authors/editors gratefully acknowledge the thoughtful
review, comments and explanations provided by Andrea Maria
Mazzini, Ben Niven-Jenkins, Bernd Zeuner, Diego Caviglia, Dieter
Beller, He Jia, Leo Xiao, Maarten Vissers.
12.References
12.1. Normative References
[1] ITU-T Recommendation G.7710/Y.1701, "Common equipment
management function requirements", July, 2007.
[2] Nadeau, T., et al., "Operations and Management (OAM)
Requirements for Multi-Protocol Label Switched (MPLS)
Networks", RFC 4377, February 2006.
[3] Vigoureus, M., et al., "Requirements for OAM in MPLS
Transport Networks", work in progress.
[4] Handley, M., et al., "Internet Denial-of-Service
Considerations", RFC 4732, November 2006.
[5] Jones, G., "Operational Security Requirements for Large
Internet Service Provider (ISP) IP Network
Infrastructure", RFC 3871, September 2004.
[6] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[7] ITU-T Recommendation G.7712/Y.1703, "Architecture and
Specification of Data Communication Network", June 2008.
[8] ITU-T Recommendation G.8601, "Architecture of service
management in multi bearer, multi carrier environment",
June 2006.
12.2. Informative References
None
Gray, et al Expires July, 2009 [Page 14]
Internet-Draft MPLS-TP NM Requirements January, 2009
13. Author's Addresses
Editors:
Scott Mansfield
Ericsson
5000 Ericsson Drive
Warrendale, PA, 15086
Phone: +1 724 742 6726
EMail: Scott.Mansfield@Ericsson.com
Hing-Kam (Kam) Lam
Alcatel-Lucent
600-700 Mountain Ave
Murray Hill, NJ, 07974
Phone: +1 908 582 0672
Email: hklam@Alcatel-Lucent.com
Eric Gray
Ericsson
900 Chelmsford Street
Lowell, MA, 01851
Phone: +1 978 275 7470
Email: Eric.Gray@Ericsson.com
Author(s):
Contributor(s):
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Gray, et al Expires July, 2009 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-22 06:11:13 |