Network Working Group                                  Hing-Kam Lam
     Internet Draft                                       Alcatel-Lucent
     Expires: January, 2009                              Scott Mansfield
     Intended Status: Informational                            Eric Gray
                                                            July 3, 2008
                    MPLS TP Network Management Requirements
     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
        The list of Internet-Draft Shadow Directories can be accessed at
        This Internet-Draft will expire on January 3, 2009.
        This document specifies the network management requirements for
        supporting the Transport Profile for Multi-Protocol Label
        Switching (MPLS-TP).
     Gray, et al             Expires January, 2009              [Page 1]

     Internet-Draft         MPLS-TP NM Requirements           July, 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
        3. Management Channel Requirements.............................5
        4. OAM Management Requirements.................................6
           4.1. Standard Management Interfaces.........................7
        5. Fault Management Requirements...............................7
           5.1. Supervision Function...................................8
           5.2. Validation Function....................................9
           5.3. Alarm Handling Function...............................10
              5.3.1. Alarm Severity Assignment........................10
              5.3.2. Alarm Suppression................................10
              5.3.3. Alarm Reporting Control..........................11
              5.3.4. Alarm Reporting..................................11
        6. Configuration Requirements.................................11
        7. Performance Requirements...................................12
           7.1. Path Characterization Performance Metrics.............12
           7.2. SLA Performance Metrics...............................13
           7.3. ATM/Ethernet/MPLS OAM Based Performance Metrics.......13
           7.4. Performance Collection Instrumentation................13
              7.4.1. Collection Frequency.............................13
              7.4.2. Collection Granularity...........................13
        8. Security Requirements......................................14
           8.1. Management Communication Channel Security.............14
              8.1.1. In-Band management security......................14
              8.1.2. Out-of-Band management security..................15
           8.2. Signaling Communication Channel Security..............15
           8.3. Distributed Denial of Service.........................15
        9. Accounting Requirements....................................15
        10. Security Considerations...................................15
        11. IANA Considerations.......................................15
        12. Acknowledgments...........................................16
        13. References................................................16
           13.1. Normative References.................................16
           13.2. Informative References...............................17
        14. Author's Addresses........................................18
        Intellectual Property Statement...............................18
        Disclaimer of Validity........................................19
        Copyright Statement...........................................19
     Gray, et al             Expires January, 2009              [Page 2]

     Internet-Draft         MPLS-TP NM Requirements           July, 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
        "OPTIONAL" in this document are to be interpreted as described
        in RFC 2119 [18].
        MPLS-TP NE: a network element (NE) that supports MPLS-TP
        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.).
        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
        Management Communication Channel (MCC): a dedicated logical
        operations channel between NEs for management communications.
        The physical channel supporting the MCC is technology specific.
     Gray, et al             Expires January, 2009              [Page 3]

     Internet-Draft         MPLS-TP NM Requirements           July, 2008
        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 [20]
        and M.3060 [21]. 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. Entities that include managers are capable of managing
        other entities.
        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. The
        management of the MPLS-TP network shall be separable from the
        management of the other technology-specific networks.
        A MPLS-TP Management Network MAY be partitioned into Management
        SubNetworks (MSN).
        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
        [20]). The MCF of an MPLS-TP NE initiates/terminates, routes, or
     Gray, et al             Expires January, 2009              [Page 4]

     Internet-Draft         MPLS-TP NM Requirements           July, 2008
        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 contains 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
        operations on 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.
     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
     Gray, et al             Expires January, 2009              [Page 5]

     Internet-Draft         MPLS-TP NM Requirements           July, 2008
        Signaling (SCC). In this document, whenever the generic term ECC
        is used, it mainly focuses on the utilization of the ECC for
        Management (i.e., MCC only).
        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 [22] as well as
        with termination points located in NEs under control by a third
        party network operator as specified in G.8601.
        See ITU-T G.7712/Y.1703 [19] for management DCN's architecture
        and specifications, including network layer protocol.
        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
        the subnetwork are routed through the GNE and, in general, other
        intermediate systems.
        MPLS-TP NEs communicate via the DCN. 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
        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).
     Gray, et al             Expires January, 2009              [Page 6]

     Internet-Draft         MPLS-TP NM Requirements           July, 2008
        [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
        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.
     4.1. Standard Management Interfaces
        This document places no restriction on which management
        interface to be used for managing an MPLS-TP network. It is
        allowed to provision and manage an end-to-end connection across
        a network where some segments are created/managed/deleted, for
        examples by netconf or snmp and other segments by XML or CORBA
        interfaces. It is allowed to run maintenance on a connection
        independent of the mechanism used to establish the connection.
        An MPLS-TP NE is not required to offer more than one standard
        management interface.
     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.
     Gray, et al             Expires January, 2009              [Page 7]

     Internet-Draft         MPLS-TP NM Requirements           July, 2008
     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
             . Connectivity supervision for the detection of a
             . 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;
             . Misinsertion supervision for misinserted packet in the
             . 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
          B) Software Processing Supervision for software or software
             processing fault, such as storage capacity problem, version
             mismatch, Corrupted data, Out of memory, etc.
     Gray, et al             Expires January, 2009              [Page 8]

     Internet-Draft         MPLS-TP NM Requirements           July, 2008
          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.
           . 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
           . 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
     Gray, et al             Expires January, 2009              [Page 9]

     Internet-Draft         MPLS-TP NM Requirements           July, 2008
        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
        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 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.
     Gray, et al             Expires January, 2009             [Page 10]

     Internet-Draft         MPLS-TP NM Requirements           July, 2008
     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.
        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
        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.
     Gray, et al             Expires January, 2009             [Page 11]

     Internet-Draft         MPLS-TP NM Requirements           July, 2008
        The EMF of the MPLS-TP NE MUST support the capability to choose
        which OAM functions to use and which maintenance entity to apply
        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
     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,
        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
     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
     Gray, et al             Expires January, 2009             [Page 12]

     Internet-Draft         MPLS-TP NM Requirements           July, 2008
        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.
     7.2. SLA Performance Metrics
     7.3. ATM/Ethernet/MPLS OAM Based Performance Metrics
     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
     7.4.2. Collection Granularity
        On Packet loss measurement:
          - For bidirectional (P2P) connection, collection of on-demand
             single-ended packet loss measurement is required.
     Gray, et al             Expires January, 2009             [Page 13]

     Internet-Draft         MPLS-TP NM Requirements           July, 2008
          - 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 support the ability to detect
        denial of service (DoS) attacks against 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.  IPsec and IKE protocols according to RFC 2403 [4],
        RFC 2405 [5], RFC 4301-4309 ([6], [7], [8], [9], [10], [11],
        [12], [13], [14]), and RFC 4312 [15] MUST be supported for IPv6.
        For IPv4, IPsec MUST be supported.
     8.1.1. In-Band management security
        If in-band management is provided, the MCC MUST require the
          - Use of open cryptographic algorithms (See RFC 3871 [17]
             section 4.5)
          - Authentication
          - Allow management connectivity only from authorized IP
             addresses or MAC Addresses.
     Gray, et al             Expires January, 2009             [Page 14]

     Internet-Draft         MPLS-TP NM Requirements           July, 2008
     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
        A Distributed Denial of Service (DDOS) attack is an attempt to
        hinder the target from performing its assigned task by
        overloading the target with spurious requests.  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 [16] provides
        background on DOS in the context of the Internet.
     9. Accounting Requirements
     10. Security Considerations
        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
        The performance of diagnostic functions and path
        characterization involve extracting a significant amount of
        information about network construction that the network operator
        MAY consider private.
     11. IANA Considerations
        <insert IANA considerations, if any, here)
     Gray, et al             Expires January, 2009             [Page 15]

     Internet-Draft         MPLS-TP NM Requirements           July, 2008
     12. Acknowledgments
     13.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]   Madson, C., Glenn, R., "The Use of HMAC-MD5-96 within ESP
              and AH", RFC 2403, November 1998.
        [5]   Madson, C., Doraswamy, N., "The ESP DES-CBC Cipher
              Algorithm with Explicit IV", RFC 2405, November 1998.
        [6]   Kent, S., Seo, K., "Security Architecture of the Internet
              Protocol", RFC 4301, December 2005.
        [7]   Kent, S., "IP Authentication Header", RFC 4302, December
        [8]   Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
              4303, December 2005.
        [9]   Kent, S., "Extended Sequence Number (ESN) Addendum to
              IPsec Domain of Interpretation (DOI) for Internet Security
              Association and Key Management Protocol (ISAKMP)", RFC
              4304, December 2005.
        [10]  Manral, V., "Cryptographic Algorithm Implementation
              Requirements for Encapsulating Security Payload (ESP) and
              Authentication Header (AH)", RFC 4835, April 2007.
        [11]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
              4306, December 2005.
     Gray, et al             Expires January, 2009             [Page 16]

     Internet-Draft         MPLS-TP NM Requirements           July, 2008
        [12]  Schiller, J., "Cryptographic Algorithms for Use in the
              Internet Key Exchange Version 2 (IKEv2)" RFC 4307,
              December 2005.
        [13]  Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308,
              December 2005.
        [14]  Housley, R., "Using Advanced Encryption Standard (AES) CCM
              Mode with IPsec Encapsulating Security Payload (ESP)", RFC
              4309, December 2005.
        [15]  Kato, A., et al., "The Camellia Cipher Algorithm and Its
              Use with IPsec", RFC 4312, December 2005.
        [16]  Handley, M., et al., "Internet Denial-of-Service
              Considerations", RFC 4732, November 2006.
        [17]  Jones, G., "Operational Security Requirements for Large
              Internet Service Provider (ISP) IP Network
              Infrastructure", RFC 3871, September 2004.
        [18]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, March 1997.
        [19]  ITU-T Recommendation G.7712/Y.1703, "Architecture and
              Specification of Data Communication Network", June 2008.
     13.2. Informative References
        [20]  ITU-T Recommendation M.3010, "Principles for a
              telecommunication management network", April 2005.
        [21]  ITU-T Recommendation M.3060/Y.2401, "Principles for the
              Management of Next Generation Networks", March 2006.
        [22]  ITU-T Recommendation G.8601, "Architecture of service
              management in multi bearer, multi carrier environment",
              June 2006.
     Gray, et al             Expires January, 2009             [Page 17]

     Internet-Draft         MPLS-TP NM Requirements           July, 2008
     14. Author's Addresses
        Scott Mansfield
        5000 Ericsson Drive
        Warrendale, PA, 15086
        Phone: +1 724 742 6726
        Hing-Kam (Kam) Lam
        600-700 Mountain Ave
        Murray Hill, NJ, 07974
        Phone: +1 908 582 0672
        Eric Gray
        900 Chelmsford Street
        Lowell, MA, 01851
        Phone: +1 978 275 7470
     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
     Gray, et al             Expires January, 2009             [Page 18]

     Internet-Draft         MPLS-TP NM Requirements           July, 2008
        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
     Disclaimer of Validity
        This document and the information contained herein are provided
     Copyright Statement
        Copyright (C) The IETF Trust (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.
        Funding for the RFC Editor function is currently provided by the
        Internet Society.
     Gray, et al             Expires January, 2009             [Page 19]