Network Working Group Hing-Kam Lam
Internet Draft Alcatel-Lucent
Expires: April, 2009 Scott Mansfield
Intended Status: Informational Eric Gray
Ericsson
October 8, 2008
MPLS TP Network Management Requirements
draft-gray-mpls-tp-nm-req-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
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 January 8, 2009.
Abstract
This document specifies the network management requirements for
supporting the Transport Profile for Multi-Protocol Label
Switching (MPLS-TP).
Gray, et al Expires April, 2009 [Page 1]
Internet-Draft MPLS-TP NM Requirements October, 2008
Table of Contents
1. Introduction................................................3
1.1. Terminology............................................3
2. Management Architecture.....................................4
2.1. Network Management Architecture........................4
2.2. Element Management Architecture........................5
2.3. Standard Management Interfaces.........................6
3. Management Channel Requirements.............................6
4. OAM Management Requirements.................................7
5. Fault Management Requirements...............................8
5.1. Supervision Function...................................8
5.2. Validation Function...................................10
5.3. Alarm Handling Function...............................11
5.3.1. Alarm Severity Assignment........................11
5.3.2. Alarm Suppression................................11
5.3.3. Alarm Reporting Control..........................11
5.3.4. Alarm Reporting..................................11
6. Configuration Requirements.................................12
7. Performance Requirements...................................12
7.1. Path Characterization Performance Metrics.............13
7.2. SLA Performance Metrics...............................14
7.3. ATM/Ethernet/MPLS OAM Based Performance Metrics.......14
7.4. Performance Collection Instrumentation................14
7.4.1. Collection Frequency.............................14
7.4.2. Collection Granularity...........................14
8. Security Requirements......................................14
8.1. Management Communication Channel Security.............14
8.1.1. In-Band management security......................15
8.1.2. Out-of-Band management security..................15
8.2. Signaling Communication Channel Security..............15
8.3. Distributed Denial of Service.........................15
9. Security Considerations....................................16
10. IANA Considerations.......................................16
11. Acknowledgments...........................................16
12. References................................................16
12.1. Normative References.................................16
12.2. Informative References...............................17
13. Author's Addresses........................................17
Intellectual Property Statement...............................18
Disclaimer of Validity........................................18
Copyright Statement...........................................18
Acknowledgment................................................19
Gray, et al Expires April, 2009 [Page 2]
Internet-Draft MPLS-TP NM Requirements October, 2008
1. Introduction
This document describes the requirements necessary to manage the
elements and networks that support a Transport Profile for MPLS.
These requirements are derived from the set of requirements
specified in ITU-T G.7710/Y.1701 [1], which addresses generic
management requirements for transport networks (including
packet-based and circuit-based). This document also leverages
the OAM requirements for MPLS Networks (RFC4377)[2] and MPLS-TP
Networks [3] documents and expands on the requirements to cover
the modifications necessary for configuration, performance,
fault, and security for the Transport Profile.
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].
MPLS-TP NE: a network element (NE) that supports MPLS-TP
functions
MPLS-TP network: a network in which MPLS-TP NEs are deployed
Equipment Management Function (EMF): the management functions
within an NE. See ITU-T G.7710 [1].
Data Communication Network (DCN): a network that supports Layer
1 (physical), Layer 2 (data-link), and Layer 3 (network)
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.). A DCN supporting
management communication is referred to as a Management
Communication Network (MCN). A DCN supporting signaling
communication is referred to as a Signaling Communication
Network (SCN).
Embedded Communication Channel (ECC): a logical operations
channel between network elements (NEs) that can be utilized by
multiple applications (e.g., management plane applications,
control plane applications, etc.). The physical channel
supporting the ECC is technology specific. An example of
physical channels supporting the ECC is a DCC channel within
SDH.
Gray, et al Expires April, 2009 [Page 3]
Internet-Draft MPLS-TP NM Requirements October, 2008
Management Communication Channel (MCC): a dedicated logical
operations channel between NEs for management plane
communications. The physical channel supporting the MCC is
technology specific.
Signaling Communication Channel (SCC): a dedicated logical
operations channel between NEs for control plane communications.
This SCC MAY be used for GMPLS/ASON signaling and/or other
control plane messages like e.g., routing messages. The physical
channel supporting the SCC is technology specific.
Management Application Function (MAF): an application process
that participates in system management. Each NE and Operations
System (OS) MUST support a MAF. A MAF is the origin and
termination for all TMN messages.
2. Management Architecture
The management of the MPLS-TP network is based on a multi-tiered
distributed management systems as described in ITU-T M.3010 [8]
and M.3060 [9]. Each tier provides a predefined level of network
management capabilities. The lowest tier of this organization
model includes the MPLS-TP Network Element Functions (NEFs) that
provides the transport service and the Operations System
Functions (OSFs) at the Element Management Level. The Management
Application Function (MAF) within the NEFs and OSFs provides the
management support. The MAF at each entity can include agents
only, managers only, or both agents and managers. MAFs that
include managers are capable of managing an agent included in
other MAFs.
The management communication to peer NEFs and/or Operations
System Functions (OSFs) is provided via the Message
Communication Function (MCF) within each entity (e.g. NEF and
OSF). The user can access the management of the MPLS-TP
transport network via a Local Craft Terminal (LCT) attached to
the NEF or via a Work Station (WS) attached to the OSF.
2.1. Network Management Architecture
A transport Management Network (MN) MAY consist of several
transport-technology-specific Management Networks. Notation used
in G.7710 ([1]) for a transport-technology-specific MN is x.MN,
where x is the transport specific technology. For example, a
MPLS-TP specific MN might be MPLS-TP.MN (this was previously TM-
MN for T-MPLS specific MN). Where there is no ambiguity, we
Gray, et al Expires April, 2009 [Page 4]
Internet-Draft MPLS-TP NM Requirements October, 2008
will use "MN" for an MPLS-TP specific MN, and "MPLS-TP.MN" (or
"MPLS-TP MN") and "MN" where both are used in a given context.
The management of the MPLS-TP network SHALL be separable from
the management of the other technology-specific networks, and
operate independently of any particular client or server layer
management plane.
A MPLS-TP Management Network MAY be partitioned into MPLS-TP
Management SubNetworks ("MPLS-TP.MSN" or "MPLS-TP MSN", or just
"MSN" where usage is unambiguous).
The MPLS-TP MSN MAY be connected to other parts of the MN
through one or more Local Craft Terminals (via F-interface, see
M.3010) and/or Operations Systems (via Q-interface, see M.3010
[8]). The MCF of an MPLS-TP NE initiates/terminates, routes, or
otherwise processes management messages over ECCs or via an
external Q-interface or F-interface.
Multiple addressable MPLS-TP NEs MAY be present at a single
physical location (i.e. site or office). The inter-site
communications link between the MPLS-TP NEs will normally be
provided by the ECCs. Within a particular site, the NEs MAY
communicate via an intra-site ECC or via a LAN.
2.2. Element Management Architecture
The Equipment Management Function (EMF) of a MPLS-TP NE provides
the means through which a management system manages the NE.
Figure 5/G.7710 [1] illustrates examples of EMF components
within an NE.
The EMF interacts with the NE's transport functions and control
functions (i.e., control plane functions that reside in the NE)
by exchanging Management Information (MI) across the Management
Point (MP) Reference Points. The EMF MAY contain a number of
functions that provide a data reduction mechanism on the
information received across the MP Reference Points.
The EMF includes functions such as Date & Time and the FCAPS
(Fault, Configuration, Accounting, Performance and Security)
management functions. The EMF provides event message processing,
data storage and logging. The management Agent, a component of
the EMF, converts internal management information (MI signals)
into Management Application messages and vice versa. The Agent
responds to Management Application messages from the Message
Communications Function (MCF) by performing the appropriate
Gray, et al Expires April, 2009 [Page 5]
Internet-Draft MPLS-TP NM Requirements October, 2008
operations on (for example) the Managed Objects in a Management
Information Base (MIB), as necessary. The MCF contains
communications functions related to the outside world of the NE
(i.e. Date & Time source, Management Plane, Control Plane, Local
Craft Terminal and Local Alarms).
The Date & Time functions keep track of the NE's date/time which
is used by the FCAPS management functions to e.g. time stamp
event reports.
2.3. Standard Management Interfaces
This document places no restriction on which management
interface to be used for managing an MPLS-TP network. It is
possible to provision and manage an end-to-end connection
across a network where some segments are
created/managed/deleted, for example by netconf/XML or snmp/smi
and other segments by CORBA/IDL interfaces. Use of any network
management interface for one management related purpose does
not preclude use of another network management interface for
other management related purposes, or the same purpose at
another time However, an MPLS-TP NE is not required to offer
more than one standard management interface.
3. Management Channel Requirements
The Embedded Communication Channel (ECC) provides a logical
operations channel between NEs for transferring Management
and/or Signaling information. Note that some technologies
provide separate communication channels for Management (MCC) and
Signaling (SCC).
This document places no restriction on the physical topology of
the MN to support management communications. However, the MPLS-
TP MN SHOULD support seamless connectivity with remote transport
domains and NEs as specified in ITU-T G.8601 [10] as well as
with termination points located in NEs under control by a third
party network operator as specified in G.8601.
Each MPLS-TP MSN MUST have at least one MPLS-TP NE which is
connected to an OS (possibly via a Mediation Device). This NE is
called a Gateway Network Element (GNE). The GNE SHOULD be able
to perform an intermediate system network layer routing function
for ECC messages destined for any end system in the MSN.
Messages passing between the OS and any of the end systems in
Gray, et al Expires April, 2009 [Page 6]
Internet-Draft MPLS-TP NM Requirements October, 2008
the subnetwork are routed through the GNE and, in general, other
intermediate systems.
MPLS-TP NEs communicate via the DCN. The DCN connects NEs with
management systems, NEs with NEs, and management systems with
management systems. 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 DCN
operate properly, a number of management functions are required.
Examples are:
. Retrieval of 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 network addresses;
. Retrieval of operational status of the DCN at a given node;
. Capability to enable/disable access to the DCN.
4. OAM Management Requirements
<This section will be aligned with the OAM terminology document>
The purpose of the Operation and Maintenance (OAM) functionality
is to maintain the integrity of the network and to ensure that
the transport service is compliant with the committed Service
Level Agreement (SLA).
[3] specifies the requirements for the OAM functionality that
are deployed in the transport plane to maintain the integrity of
the client signal between ingress and egress ports of the MPLS-
TP network. These OAM functionalities are sometimes called
"Horizontal OAM".
There are OAM functionalities that are deployed in the
management plane to support maintaining the overall network
integrity and achieving the SLA. These OAM functionalities are
sometimes called "Vertical OAM" or OAM&P (Operation,
Administration, Maintenance, & Provisioning), in the sense that
they involves higher level systems, such as element management
systems (EMS), network management systems (NMS), and/or service
Gray, et al Expires April, 2009 [Page 7]
Internet-Draft MPLS-TP NM Requirements October, 2008
management systems (SMS). Examples of vertical OAM functions
include hardware provisioning, software configuration, alarm
notification/retrieval, performance monitoring (PM) data
collection & reporting.
Note that management of horizontal OAM parameters is also part
of the vertical OAM function. Regardless what specific
horizontal OAM mechanisms (tools) will be deployed in the
transport plane, these mechanisms (tools) need to be managed
(e.g. configured and monitored) to ensure their proper
functioning. The management requirements for the horizontal OAM
mechanisms will be specified in the subsequence sections, along
with the vertical OAM management requirements.
5.Fault Management Requirements
The Fault Management functions within the EMF of 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 shall support the following types of supervision:
A) Transmission supervision:
. Continuity supervision for the detection of a broken
connection;
. Connectivity supervision for the detection of a
misconnection;
. Looping supervision for unintended self-replication;
. Alarm suppression based on native OAM, e.g., AIS (Alarm
Indication Signal) and FDI (Forward Defect Indication)
. Lock indication supervision;
. Packet loss measurement in both directions of the
bidirectional connection;
Gray, et al Expires April, 2009 [Page 8]
Internet-Draft MPLS-TP NM Requirements October, 2008
. Misinsertion supervision for misinserted packet in the
connection
. Diagnostic test supervision;
. Route trace supervision;
. Remote defect indication supervision;
. Protocol supervision for the detection of failure in
the sequence of a protocol exchange (e.g. automatic
protection switching protocol);
The transmission supervision mechanisms MUST support the
flexibility to be configured to perform on-demand or
proactively.
B) Software Processing Supervision for software or software
processing fault, such as storage capacity problem, version
mismatch, Corrupted data, Out of memory, etc.
C) Hardware Supervision for interchangeable and non-
interchangeable units, cable, and power problem.
D) Environment Supervision for temperature, humidity, etc.
The following requirements related to defect detection specified
in RFC 4377 [2] are applicable for MPLS-TP NE.
. The ability to detect defects in a broken connection
(LSP, PW) MUST NOT require manual hop-by-hop
troubleshooting of each node used to switch traffic for
that connection.
. The automation of path liveliness is desired in cases
where large numbers of connections might be tested.
. Synchronization of detection time bounds by tools used to
detect broken connections is required.
. Any detection mechanisms that depend on receiving the
status via a return path SHOULD provide multiple return
options with the expectation that one of them will not be
impacted by the original defect.
Gray, et al Expires April, 2009 [Page 9]
Internet-Draft MPLS-TP NM Requirements October, 2008
. The OAM packet for defect detection MUST follow the
customer data path exactly in order to reflect path
liveliness used by customer data.
. Defect SHOULD be detected by the network operator prior
to the customers of the service in question detecting
them.
. Recovery of service from faults MAY be automatically
taken according to the type of fault.
5.2. Validation Function
Validation is concerned with the integration of Fault Causes
into Failures. A Fault Cause indicates a limited interruption of
the required function. A Fault Cause is not reported to
maintenance personnel because it could exist only for a very
short time. 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 function arises. This Failure condition is subject
to be alarmed to maintenance personnel because corrective action
might be required. Conversely, when the Fault Cause ceases after
a certain time, the Failure condition MUST disappear.
The EMF within the MPLS-TP NE MUST perform a persistency check
on the fault causes before it declares a fault cause a failure.
A transmission failure shall be declared if the fault cause
persists continuously for 2.5 +/- 0.5 sec. The failure shall be
cleared if the fault cause is absent continuously for 10 +/- 0.5
sec.
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.
Gray, et al Expires April, 2009 [Page 10]
Internet-Draft MPLS-TP NM Requirements October, 2008
5.3. Alarm Handling Function
5.3.1. Alarm Severity Assignment
Failures MAY have been categorized to indicate the severity or
urgency of the fault. The MPLS-TP NE SHOULD support the
flexibility of assignment of severity (e.g., Critical, Major,
Minor, Warning) by the management system.
See G.7710 [1] for more description.
5.3.2. Alarm Suppression
An MPLS-TP NE MUST provide alarm suppression functionality that
prevents the generation of a superfluous generation of alarms,
e.g., by simply discarding them (or not generating them in the
first place), or by aggregating them together, thereby greatly
reducing the number of notifications emitted.
An MPLS-TP NE supporting the inter-working of one or more
networking technologies (e.g., Ethernet, SDH/SONET, OTN, MPLS)
over 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 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 (to ALM).
See G.7710 [1] for more description.
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).
The MPLS-TP NE MUST support local reporting of alarms. Local
reporting is concerned with automatic alarming by means of
audible and visual indicators near the failed equipment.
Gray, et al Expires April, 2009 [Page 11]
Internet-Draft MPLS-TP NM Requirements October, 2008
The MPLS-TP NE MUST support reporting of alarms to an OS. These
reports are either autonomous reports (notifications) or reports
on request by maintenance personnel.
6. Configuration Requirements
Configuration Management provides functions to exercise control
over, identify, collect data from, and provide data to NEs.
Generic configuration management requirements for transport
network are specified in G.7710 [1], for examples hardware,
software, protection switching, alarm reporting control, and
date/time.
The EMF of 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 EMF of 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 or (2) periodically based
on a specified frequency.
The EMF of the MPLS-TP NE MUST support the capability to choose
which OAM functions to use and which maintenance entity to apply
them.
The EMF of 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 connectivity
check process of the MPLS-TP NE needs to be provisioned with the
identifiers to transmit, the expected identifiers, and
enable/disable the connectivity check processing.
The EMF of the MPLS-TP NE MUST support retrieval of the details
of the NE's path forwarding operations. These details can then
be compared during subsequent testing relevant to OAM
functionality.
7. Performance 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,
Gray, et al Expires April, 2009 [Page 12]
Internet-Draft MPLS-TP NM Requirements October, 2008
and Performance monitoring for signal degradation. Generic
requirements for packet-switched and circuit-switched transport
networks are specified in G.7710 [1] 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
Packet loss measurement and delay measurement MUST be collected
so that they can be used to detect performance degradation.
Performance degradation MUST be reported via fault management
for corrective actions (e.g. protection switch).
Performance degradation MUST be reported via performance
monitoring, e.g. as Errored Second (ES), Severely Errored Second
(SES), and Unavailable Second (UAS), for Service Level Agreement
(SLA) verification and billing.
An ES is declared when, during one second period, there is one
or more Errored Blocks (EBs) detected, or when a defect is
declared. In a packet layer, a block is a packet. An EB is an
indication of a lost packet.
A SES is declared when, during one second, the number of EBs
exceeds a threshold, or when a defect is declared.
The number of SESs (and ESs) is summed over 15-minute and 24-
hour intervals.
A Background Block Error (BBE) is an EB not occurring as part of
a SES.
The number of BBEs is summed over 15-minute and 24-hour
intervals, over which the trend analysis is performed.
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 number of unavailable time in seconds (UAS) is summed over
15-minute and 24-hour intervals.
Gray, et al Expires April, 2009 [Page 13]
Internet-Draft MPLS-TP NM Requirements October, 2008
7.2. SLA Performance Metrics
TBD
7.3. ATM/Ethernet/MPLS OAM Based Performance Metrics
TBD
7.4. Performance Collection Instrumentation
7.4.1. Collection Frequency
The performance collection mechanisms MUST support the
flexibility to be configured to operate on-demand or
proactively.
7.4.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.
- 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 Requirements
The EMF of 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,
Gray, et al Expires April, 2009 [Page 14]
Internet-Draft MPLS-TP NM Requirements October, 2008
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 require 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).
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.
Gray, et al Expires April, 2009 [Page 15]
Internet-Draft MPLS-TP NM Requirements October, 2008
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)
11. Acknowledgments
The authors/editors gratefully acknowledge the thoughtful
review, comments and explanations provided by 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.
Gray, et al Expires April, 2009 [Page 16]
Internet-Draft MPLS-TP NM Requirements October, 2008
[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.
12.2. Informative References
[8] ITU-T Recommendation M.3010, "Principles for a
telecommunication management network", April 2005.
[9] ITU-T Recommendation M.3060/Y.2401, "Principles for the
Management of Next Generation Networks", March 2006.
[10] ITU-T Recommendation G.8601, "Architecture of service
management in multi bearer, multi carrier environment",
June 2006.
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
Gray, et al Expires April, 2009 [Page 17]
Internet-Draft MPLS-TP NM Requirements October, 2008
Phone: +1 978 275 7470
Email: Eric.Gray@Ericsson.com
Author(s):
Contributor(s):
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the
technology described in this document or the extent to which any
license under such rights might or might not be available; nor
does it represent that it has made any independent effort to
identify any such rights. Information on the procedures with
respect to rights in RFC documents can be found in BCP 78 and
BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the
use of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be
required to implement this standard. Please address the
information to the IETF at ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY,
THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM
ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008).
Gray, et al Expires April, 2009 [Page 18]
Internet-Draft MPLS-TP NM Requirements October, 2008
This document is subject to the rights, licenses and
restrictions contained in BCP 78, and except as set forth
therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Gray, et al Expires April, 2009 [Page 19]