[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 draft-ietf-mpls-tp-nm-req

   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]
   

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/