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

Versions: (draft-takacs-ccamp-oam-configuration-fwk) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 RFC 7260

Network Working Group                                          A. Takacs
Internet-Draft                                                  Ericsson
Intended status: Standards Track                                D. Fedyk
Expires: June 26, 2009                                            Nortel
                                                                  H. Jia
                                                                  Huawei
                                                       December 23, 2008


     OAM Configuration Framework and Requirements for GMPLS RSVP-TE
               draft-ietf-ccamp-oam-configuration-fwk-00

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 June 26, 2009.

Copyright Notice

   Copyright (c) 2008 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.





Takacs, et al.            Expires June 26, 2009                 [Page 1]

Internet-Draft         OAM Configuration Framework         December 2008


Abstract

   OAM functions are essential to ensure that the desired service level
   of traffic engineered connections are met.  In certain technologies
   OAM entities are inherently established once the connection is set
   up.  However other technologies, especially OAM for packet switched
   networks, require an extra configuration step after connection
   establishment to setup OAM entities.  This document specifies
   extensions to RSVP-TE to support the establishment and configuration
   of OAM entities along with LSP signalling.









































Takacs, et al.            Expires June 26, 2009                 [Page 2]

Internet-Draft         OAM Configuration Framework         December 2008


Requirements Language

   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


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  GMPLS RSVP-TE Extensions . . . . . . . . . . . . . . . . . . .  9
     3.1.  Operation overview . . . . . . . . . . . . . . . . . . . .  9
     3.2.  OAM entities desired -- LSP Attributes flag  . . . . . . . 10
     3.3.  OAM Configuration TLV  . . . . . . . . . . . . . . . . . . 11
     3.4.  Monitoring Disabled - Admin_Status bit . . . . . . . . . . 11
     3.5.  OAM configuration errors . . . . . . . . . . . . . . . . . 12
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   Appendix A.  Discussion on alternatives  . . . . . . . . . . . . . 16
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19




























Takacs, et al.            Expires June 26, 2009                 [Page 3]

Internet-Draft         OAM Configuration Framework         December 2008


1.  Introduction

   Operations and Management (OAM) functions are essential to ensure
   that the desired service level of traffic engineered connections are
   met.  OAM functions ease network operation by reducing complexity,
   enhance network survivability, verify network performance, and in
   turn reduce operational costs.

   In certain technologies OAM entities are inherently established once
   the connection is set up.  However other technologies, especially OAM
   for packet switched networks, require an extra configuration step
   after connection establishment to setup OAM entities.

   In some situations the use of OAM functions, like those of Fault-
   (FM) and Performance Management (PM), may be optional confirming to
   actual network management policies.  Hence the network operator must
   be able to choose which kind of OAM functions to apply to specific
   connections and with what parameters the selected OAM functions
   should be configured and operated.  To achieve this objective OAM
   entities and specific functions must be selectively configurable.

   The GMPLS control plane consists of a set of protocols: OSPF-TE,
   RSVP-TE and LMP. which are used to reduce manual configuration and
   improve management efficiency.  RSVP-TE is used to setup and
   configure end-to-end connections.  A new useful application of
   RSVP-TE is OAM configuration and control for transport networks.

   When RSVP-TE is used for LSP establishment it is desirable to bind
   OAM setup to connection establishment signalling to avoid two
   separate management/configuration steps (connection setup followed by
   OAM configuration) which increases delay, processing and more
   importantly may be prune to misconfiguration errors.

   The mechansim described in this document provides an additional
   option for bootstrapping OAM that is not intended to replace or
   deprecate the use of other OAM bootstrapping techniques such as LSP
   Ping [RFC4379].  The procedures specified in this document are
   intended only for use in environments where RSVP-TE signaling is
   already in use to set up the LSPs that are to be monitored using OAM.

   This document describes requirements on OAM configuration and control
   via RSVP-TE, and specifies extensions to the RSVP-TE protocol
   providing a framework to configure and control OAM entities along
   with capability to carry technology specific information.  Extensions
   can be grouped into generic elements that are applicable to any OAM
   solution and technology specific elements that provide additional
   configuration parameters only needed for a specific OAM technology.
   This document specifies the technology agnostic elements that alone



Takacs, et al.            Expires June 26, 2009                 [Page 4]

Internet-Draft         OAM Configuration Framework         December 2008


   can be used to establish OAM entities in the case no technology
   specific information is needed, and specifies the way additional
   technology specific OAM parameters are provided.
















































Takacs, et al.            Expires June 26, 2009                 [Page 5]

Internet-Draft         OAM Configuration Framework         December 2008


2.  Requirements

   MPLS OAM requirements are described in [RFC4377].  It provides
   requirements to create consistent OAM functionality for MPLS
   networks.  GMPLS OAM requirements are described in [GMPLS-OAM].  The
   GMPLS OAM requirements are based on the MPLS OAM requirements
   [RFC4377], in addition it also considers the existing OAM techniques
   in non-packet networks.

   The following list is an excerpt of MPLS OAM requirements documented
   in [RFC4377].  Only a few requirements are discussed that bear a
   direct relevance to the discussion set forth in this document.

   o  It is desired to support the automation of LSP defect detection.
      It is especially important in cases where large numbers of LSPs
      might be tested.

   o  In particular some LSPs may require automated ingress-LSR to
      egress-LSR testing functionality, while others may not.

   o  Mechanisms are required to coordinate network responses to
      defects.  Such mechanisms may include alarm suppression,
      translating defect signals at technology boundaries, and
      synchronising defect detection times by setting appropriately
      bounded detection timeframes.

   MPLS-TP defines a profile of MPLS targeted at transport applications
   [MPLS-TP-FWK].  This profile specifies the specific MPLS
   characteristics and extensions required to meet transport
   requirements, including providing additional OAM, survivability and
   other maintenance functions not currently supported by MPLS.
   Specific OAM requirements for MPLS-TP are specified in
   [MPLS-TP-OAM-REQ].  MPLS-TP poses requirements on the control plane
   to configure and control OAM entities.

   o  The use of OAM functions SHOULD be optional for the operator.  A
      network operator SHOULD be able to choose which OAM functions to
      use and which Maintenance Entity to apply them to.

   o  The MPLS-TP control pane MUST support the configuration and
      modification of OAM maintenance points as well as the activation/
      deactivation of OAM when the transport path is established or
      modified.  OAM functions SHOULD be configurable as part of
      connectivity (LSP or PW) management.

   Ethernet Connectivity Fault Management (CFM) defines an adjunct
   connectivity monitoring OAM flow to check the liveliness of Ethernet
   networks [IEEE-CFM].  With PBB-TE [IEEE-PBBTE] Ethernet networks will



Takacs, et al.            Expires June 26, 2009                 [Page 6]

Internet-Draft         OAM Configuration Framework         December 2008


   support explicitly-routed Ethernet connections.  CFM can be used to
   track the liveliness of PBB-TE connections and detect data plane
   failures.  In IETF the GMPLS controlled Ethernet Label Switching
   (GELS) [GELS-Framework] work is extending the GMPLS control plane to
   support the establishment of point-to-point PBB-TE data plane
   connections.  Without control plane support separate management
   commands would be needed to configure and start CFM.

   GMPLS based OAM configuration and control should be general to be
   applicable to a wide range of data plane technologies and OAM
   solution.  There are three typical data plane technologies used for
   transport application, which are wavelength based such as WSON, TDM
   based such as SDH/SONET, packet based such as MPLS-TP [MPLS-TP-FWK]
   and Ethernet PBB-TE [IEEE-PBBTE].  In all these data planes, the
   operator MUST be able to configure and control the following OAM
   functions.

   o  It MUST be possible to explicitly request the setup of OAM
      entities for the signalled LSP and provide specific information
      for the setup if this is required by the technology.

   o  When periodic messages are used for liveliness check (continuity
      check) of LSPs it MUST be possible to set the frequency of
      messages allowing proper configuration for fulfilling the
      requirements of the service and/or meeting the detection time
      boundaries posed by possible congruent connectivity check
      operations of higher layer applications.  For a network operator
      to be able to balance the trade-off in fast failure detection and
      overhead it is beneficial to configure the frequency of continuity
      check messages on a per LSP basis.

   o  Control of alarms is important to avoid false alarm indications
      and reporting to the management system.  It MUST be possible to
      enable/disable alarms generated by OAM functions.  In some cases
      selective alarm control may be desirable when, for instance, the
      operator is only concerned about critical alarms thus the non-
      service affecting alarms should be inhibited.

   o  Performance Monitoring (PM) is continuously collecting information
      about specific characteristics of the connection.  It MUST be
      possible to configure PM functions, e.g., set monitoring intervals
      and thresholds for PM initiated alarms.  For consistent
      measurement of Service Level Agreements (SLAs) it may be required
      that measurement points agree on a common probing rate to avoid
      measurement problems.

   o  The extensions must allow the operator to use only a minimal set
      of OAM configuration and control features if the data plane



Takacs, et al.            Expires June 26, 2009                 [Page 7]

Internet-Draft         OAM Configuration Framework         December 2008


      technology, the OAM solution or network management policy allows.
      The extensions must be reusable as much as reasonably possible.
      That is generic OAM parameters and data plane or OAM technology
      specific parameters must be separated.















































Takacs, et al.            Expires June 26, 2009                 [Page 8]

Internet-Draft         OAM Configuration Framework         December 2008


3.  GMPLS RSVP-TE Extensions

3.1.  Operation overview

   Two types of Maintenance Poits (MPs) are distinguished: Maintenance
   End Points (MEPs) and Maintenance Intermediate Points (MIPs).  MEPs
   are located at the ends of an LSP and are capable of initiating and
   terminating OAM packets for Fault Management (FM) and Performance
   Monitoring (PM).  MIPs on the other hand are located at transit nodes
   of an LSP and are capable of reacting to some OAM packets but
   otherwise do not initiate packets.  Maintenance Entity (ME) refers to
   an association of MEPs and MIPs that are provisioned to monitor an
   LSP.  The ME association is achieved by configuring MPs of an ME with
   the same unique ME ID.  Each MEP must have unique identification (MEP
   ID) within the ME.

   When an LSP is signalled forwarding association is established
   between endpoints and transit nodes via label bindings.  This
   association creates a context for the OAM entities monitoring the
   LSP.  On top of this association OAM entities may be configured with
   an ME ID and MEP IDs.  The ME ID may be used to detect
   misconfiguration errors and leacking OAM traffic.  Within the ME the
   MEP ID can be used to demultiplex and identify the originating MEP of
   OAM packets.  Since MIPs do not originate OAM packets no specific
   configuration is required for them.

   In addition to the ME and MEP identification parameters pro-active
   OAM functions (e.g., Continuity Check (CC), Performance Monitoring)
   may have specific parameters requiring configuration as well.  In
   particular, the frequency of periodic CC packets and the measurement
   interval for loss and delay measurements may need to be configured.


                                 MEP
                           +-------------+
                           |OAM Functions|
                           | FM   |   PM |
                           +------+------+
                           |    MEP ID   |
                           +-------------+
                           |    ME ID    |
                           +-------------+
                           +-------------+
                           |     LSP     |
                           +-------------+

   In some cases all the above parameters may be either derived form
   some exiting information or pre-configured default values can be



Takacs, et al.            Expires June 26, 2009                 [Page 9]

Internet-Draft         OAM Configuration Framework         December 2008


   used.  In the simplest case the control plane needs to provide
   information whether or not a ME with MPs need to be setup for the
   signalled LSP.  If OAM entities are created signalling must provide
   means to activate/deactivate OAM message flows and associated alarms.

   ME and MEP IDs as well as configuration of OAM functions are
   technology specific, i.e., vary depending on the data plane
   technology and the chosen OAM solution.  In addition for any given
   data plane technology a set of OAM solutions may be applicable.  The
   OAM configuration framework allows selecting a specific OAM solution
   to be used for the signalled LSP and provides technology specific
   TLVs to carry further detailed configuration information.

3.2.  OAM entities desired -- LSP Attributes flag

   In RSVP-TE the Flags field of the SESSION_ATTRIBUTE object is used to
   indicate options and attributes of the LSP.  The Flags field has 8
   bits and hence is limited to differentiate only 8 options.  [RFC4420]
   defines a new object for RSVP-TE messages to allow the signalling of
   arbitrary attribute parameters making RSVP-TE easily extensible to
   support new applications.  Furthermore, [RFC4420] allows options and
   attributes that do not need to be acted on by all Label Switched
   Routers (LSRs) along the path of the LSP.  In particular, these
   options and attributes may apply only to key LSRs on the path such as
   the ingress LSR and egress LSR.  Options and attributes can be
   signalled transparently, and only examined at those points that need
   to act on them.  The LSP_ATTRIBUTES object and the
   LSP_REQUIRED_ATTRIBUTES objects are defined in [RFC4420] to provide
   means to signal LSP attributes and options in the form of TLVs.
   Options and attributes signalled in the LSP_ATTRIBUTES object can be
   passed transparently through LSRs not supporting a particular option
   or attribute, while the contents of the LSP_REQUIRED_ATTRIBUTES
   object must be examined and processed by each LSR.  One TLV is
   defined in [RFC4420]: the Attributes Flags TLV.

   A new bit (10 IANA to assign): "OAM entities desired" is allocated in
   the LSP Attributes Flags TLV.  If the "OAM entities desired" bit is
   set it is indicating that the establishment of OAM entities are
   required at the endpoints of the signalled LSP.  If the establishment
   of OAM entities is not supported an error must be generated: "OAM
   Problem/OAM establishment not supported".

   If the "OAM entities desired" bit is set and additional parameters
   are needed to configure the OAM entities an OAM Configuration TLV may
   be included in the LSP_ATTRIBUTES object.






Takacs, et al.            Expires June 26, 2009                [Page 10]

Internet-Draft         OAM Configuration Framework         December 2008


3.3.  OAM Configuration TLV

   This TLV specifies which OAM technology/method should be used for the
   LSP.  The OAM Configuration TLV is carried in the LSP_ATTRIBUTES
   object in Path messages.


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type (2) (IANA)     |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    OAM Type   | OAM Function  |   Reserved (set to all 0s)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type: indicates a new type: the OAM Configuration TLV (2) (IANA to
   assign).

   OAM Type: specifies the technology specify OAM method.  If the
   requested OAM method is not supported an error must be generated:
   "OAM Problem/Unsupported OAM Type".

   This document defines no types.  The receiving node based on the OAM
   Type will check if a corresponding technology specific OAM
   configuration TLV is included.

   OAM Function Flags: specifies proactive OAM functions (e.g.,
   connectivity monitoring, loss and delay measurement) that should be
   established and configured.  If the selected OAM Function(s) is(are)
   not supported an error must be generated: "OAM Problem/Unsupported
   OAM Function".

   This document defines the following flags.


       OAM Function Flag                Description
     ---------------------      ---------------------------
             0                    Connectivity Monitoring
             1-7                         Reserved

3.4.  Monitoring Disabled - Admin_Status bit

   Administrative Status Information is carried in the ADMIN_STATUS
   Object.  The Administrative Status Information is described in
   [RFC3471], the ADMIN_STATUS Object is specified for RSVP-TE in
   [RFC3473].

   One bit is allocated for the administrative control of OAM



Takacs, et al.            Expires June 26, 2009                [Page 11]

Internet-Draft         OAM Configuration Framework         December 2008


   monitoring.  In addition to the Reflect (R) bit, 7 bits are currently
   occupied (assigned by IANA or temporarily blocked by work in progress
   Internet drafts).  As the 24th bit (IANA to assign) this draft
   introduces the Monitoring Disabled (M) bit.  When this bit is set the
   monitoring and OAM triggered alarms of the LSP are disabled (e.g., no
   continuity check messages are sent).

3.5.  OAM configuration errors

   To handle OAM configuration errors a new Error Code (IANA to assign)
   "OAM Problem" is introduced.  To refer to specific problems a set of
   Error Values is defined.

   If a node does not support the establishment of OAM entities via
   RSVP-TE signalling it must use the error value (IANA to assign): "OAM
   establishment not supported" in the PathErr message.

   If a node does not support a specific OAM technology/solution it must
   use the error value (IANA to assign): "Unsupported OAM Type" in the
   PathErr message.

   If a node does not support a specific OAM Function it must use the
   error value (IANA to assign): "Unsupported OAM Function" in the
   PathErr message.



























Takacs, et al.            Expires June 26, 2009                [Page 12]

Internet-Draft         OAM Configuration Framework         December 2008


4.  IANA Considerations

   One bit (Monitoring Disabled (M)) needs to be allocated in the
   ADMIN_STATUS Object.

   One bit ("OAM entities desired") needs to be allocated in the LSP
   Attributes Flag Registry.

   This document specifies one new TLVs to be carried in the
   LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects in Path messages:
   OAM Configuration TLV.

   One new Error Code: "OAM Problem" and three new values: "OAM
   establishment not supported", "Unsupported OAM Type" and "Unsupported
   OAM Function" needs to be assigned.




































Takacs, et al.            Expires June 26, 2009                [Page 13]

Internet-Draft         OAM Configuration Framework         December 2008


5.  Security Considerations

   The signalling of OAM related parameters and the automatic
   establishment of OAM entities introduces additional security
   considerations to those discussed in [RFC3473].  In particular, a
   network element could be overloaded, if an attacker would request
   liveliness monitoring, with frequent periodic messages, for a high
   number of LSPs, targeting a single network element.

   Security aspects will be covered in more detailed in subsequent
   versions of this document.








































Takacs, et al.            Expires June 26, 2009                [Page 14]

Internet-Draft         OAM Configuration Framework         December 2008


6.  Acknowledgements

   The authors would like to thank Francesco Fondelli, Adrian Farrel,
   Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful
   comments.














































Takacs, et al.            Expires June 26, 2009                [Page 15]

Internet-Draft         OAM Configuration Framework         December 2008


Appendix A.  Discussion on alternatives

   This appendix summarises the discussions after IETF-71 about the way
   OAM configuration information should be carried in RSVP-TE.

   The first question is how the requirement for OAM establishment is
   signalled and how the operation of OAM is controlled.  There is a
   straightforward way to achieve these using existing objects and
   fields:

   o  Use one or more OAM flags in the LSP Attributes Flag TLV within
      the LSP_ATTRIBUTES/LSP_REQUIRED_ATTRIBUTES object to signal that
      OAM entities for the LSP need to be established.  If for any
      reason this cannot be done a notification is sent or an error is
      raised.

   o  Once the LSP with the desired OAM entities is established OAM
      operation may be controlled using one or more flags in the
      ADMIN_STATUS object.  For instance, the generation of connectivity
      monitoring messages can be disabled/enabled by setting/clearing a
      flag in the ADMIN_STATUS object.

   However, there are two alternatives when it comes to signalling the
   actual configuration parameters of OAM entities.

   o  Extension of the LSP_ATTRIBUTES object with new TLVs.

   o  Definition of a new RSVP-TE object to carry OAM information.

   In the first case, a new OAM configuration TLV is defined in the
   LSP_ATTRIBUTES object.  This TLV would provide the detailed
   information needed for LSPs with a set OAM flag in the LSP Attributes
   Flag TLV.  The rationale for this approach is that in addition to
   setting flags the LSP_ATTRIBUTES object may carry complementary
   information for all or some of the flags set.  Furthermore, as top
   level RSVP-TE objects may become scarce resources, it seems to be
   beneficial not to allocate new RSVP-TE objects for the purpose of
   providing detailed information for new LSP Attribute Flags.
   Currently there is only one TLV, the Attributes Flag TLV, defined in
   the LSP_ATTRIBUTES object.  Defining a new TLV associated with one of
   the flags would make a precedence and possibly be a guideline for
   similar future extensions.

   The other alternative would be to allocate a dedicated object for OAM
   configuration information.  The rationale for this is that the
   complex information that may be required for OAM configuration would
   unnecessarily add complexity to LSP_ATTRIBUTES/
   LSP_REQUIRED_ATTRIBUTES objects and their processing mechanisms.



Takacs, et al.            Expires June 26, 2009                [Page 16]

Internet-Draft         OAM Configuration Framework         December 2008


   Furthermore, traditionally RSVP uses dedicated objects (*_SPECs) to
   carry configuration information of data plane entities, thus a new
   object like an "OAM_SPEC" may be a better fit to existing protocol
   elements.

   The authors of this document favour the first alternative (adding new
   TLVs to LSP_ATTRIBTES/LSP_REQUIRED_ATTRIBUTES.  However, which
   alternative to select for standardisation is up for the working group
   to decide.  In any case, the information to be carried would be the
   same or very similar for both alternatives.









































Takacs, et al.            Expires June 26, 2009                [Page 17]

Internet-Draft         OAM Configuration Framework         December 2008


7.  References

   [GELS-Framework]
              "GMPLS Ethernet Label Switching Architecture and
              Framework", Internet Draft, work in progress.

   [GMPLS-OAM]
              "OAM Requirements for Generalized Multi-Protocol Label
              Switching (GMPLS) Networks", Internet Draft, work in
              progress.

   [IEEE-CFM]
              "IEEE 802.1ag, Draft Standard for Connectivity Fault
              Management",  work in progress.

   [IEEE-PBBTE]
              "IEEE 802.1Qay Draft Standard for Provider Backbone
              Bridging Traffic Engineering",  work in progress.

   [MPLS-TP-FWK]
              "A Framework for MPLS in Transport Networks", Internet
              Draft, work in progress.

   [MPLS-TP-OAM-REQ]
              "Requirements for OAM in MPLS Transport Networks",
              Internet Draft, work in progress.

   [RFC3469]  "Framework for Multi-Protocol Label Switching (MPLS)-based
              Recovery", RFC 3469, February 2003.

   [RFC3471]  "Generalized Multi-Protocol Label Switching (GMPLS)
              Signaling Functional Description", RFC 3471, January 2003.

   [RFC3473]  "Generalized Multi-Protocol Label Switching (GMPLS)
              Signaling Resource ReserVation Protocol-Traffic
              Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

   [RFC4377]  "Operations and Management (OAM) Requirements for Multi-
              Protocol Label Switched (MPLS) Networks", RFC 4377,
              February 2006.

   [RFC4420]  "Encoding of Attributes for Multiprotocol Label Switching
              (MPLS) Label Switched Path (LSP) Establishment Using
              Resource ReserVation Protocol-Traffic Engineering
              (RSVP-TE)", RFC 4420, February 2006.






Takacs, et al.            Expires June 26, 2009                [Page 18]

Internet-Draft         OAM Configuration Framework         December 2008


Authors' Addresses

   Attila Takacs
   Ericsson
   Laborc u. 1.
   Budapest,   1037
   Hungary

   Email: attila.takacs@ericsson.com


   Don Fedyk
   Nortel
   600 Technology Park Drive
   Billerica, MA  01821
   USA

   Email: dwfedyk@nortel.com


   He Jia
   Huawei


   Email: hejia@huawei.com


























Takacs, et al.            Expires June 26, 2009                [Page 19]


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